ChatGPT Sites让AI生成网页、报告页、看板和轻量应用变得更容易但“能生成页面”不等于“能上线系统”。对程序员来说真正重要的是上线前检查数据、权限、安全、性能、部署、日志、可维护性和业务边界。本文整理一份AI生成网页后的8项检查清单避免把原型误当成正式系统。这两天我们连续看了 ChatGPT Work 和 ChatGPT Sites。Work 的变化是让 ChatGPT 从普通聊天走向任务工作台。Sites 的变化是让 AI 不只是写文档、写代码而是开始生成可预览、可分享的网页和轻量应用。这听起来很兴奋。但站在程序员角度我反而想先泼一点冷水AI生成网页只是第一步。真正难的是这个页面能不能安全、稳定、长期地用。很多人看到 AI 生成出一个页面就会觉得“网站已经做好了”。但程序员都知道页面能打开只代表它完成了最表层的展示。一个真正可上线的系统还要过很多关。下面这8件事是我建议程序员在接手AI生成网页、原型或轻量应用时必须检查的清单。一、先判断这是原型还是正式系统第一件事不是看代码而是先确认性质。AI生成的东西通常更接近原型能展示页面能模拟交互能说明业务流程能让团队快速讨论能验证想法是否成立但正式系统还要满足有真实数据有权限控制有错误处理有安全策略有部署环境有日志监控有后续维护方案如果业务方拿着一个AI生成页面说“这个已经差不多了”程序员要先把边界说清楚。原型是为了讨论。正式系统是为了长期运行。这两个不是一回事。二、检查数据来源页面里的数据是真的吗AI生成网页时最常见的问题是页面看起来很完整但数据是假的。比如仪表盘上有销售额项目看板里有进度用户列表里有头像和状态报告里有图表产品页里有价格和库存这些数据可能只是AI为了展示效果生成的示例。上线前必须确认数据来自哪里是静态写死还是接口返回接口失败时怎么办数据为空时页面怎么显示数据过多时是否分页或懒加载数据是否需要缓存数据更新频率是多少如果这些问题没想清楚页面越漂亮误导性越强。程序员接手时第一步应该把“假数据”和“真实数据”标出来。三、检查权限谁能看谁能改AI生成页面时通常不会真正理解你的权限体系。它可能会直接生成管理后台用户列表编辑按钮删除按钮导出按钮设置入口但这些按钮能不能出现不是UI问题而是权限问题。上线前要确认是否需要登录不同角色看到的内容是否不同普通用户能不能访问管理页面编辑、删除、导出是否需要权限前端隐藏按钮是否足够后端接口是否也做了权限校验这里有一个常见误区“前端不显示按钮就算控制权限了。”这是不够的。真正的权限控制必须在后端做。前端隐藏只是体验优化不是安全措施。如果AI只生成了前端页面一定不能直接当作完整权限系统使用。四、检查安全有没有把敏感信息暴露出去AI生成代码时有时会为了方便把一些配置写得很随意。比如把API Key写在前端代码里把接口地址直接暴露把测试Token写进页面把管理员入口写死把错误堆栈直接展示给用户把内部字段原样返回这些都可能成为安全问题。上线前至少检查前端代码里有没有密钥页面是否暴露内部接口错误信息是否泄露服务端细节表单输入是否做校验是否存在明显XSS风险上传文件是否限制类型和大小导出数据是否受权限控制尤其是涉及登录、支付、用户资料、订单、内部数据的页面不能只看页面能不能跑。AI生成的代码可以作为草稿但安全不能靠感觉。五、检查异常处理出错时用户看到什么很多AI生成页面只处理了“正常情况”。数据加载成功页面很好看。表单提交成功提示也很完整。按钮点击后流程看起来很顺。但真实系统里异常才是常态。可能出现接口超时网络断开数据为空登录过期权限不足表单校验失败服务端返回错误第三方服务不可用上线前要检查每个关键流程的异常状态加载中显示什么加载失败显示什么空数据怎么显示提交失败怎么提示用户能不能重试错误是否会重复提交是否会出现按钮多次点击一个页面是否成熟不是看正常流程而是看异常流程。AI生成页面通常能把正常流程做得很像样但异常处理经常缺失。六、检查性能数据一多会不会卡AI生成的页面展示几十条示例数据通常没问题。但真实上线后可能会遇到几千条列表大量图片多个图表复杂筛选高频刷新多端访问慢接口返回这时页面可能会明显变慢。上线前要检查列表是否分页图片是否压缩首屏是否加载过多资源图表是否一次性渲染太多数据搜索和筛选是否会频繁请求大文件是否影响页面打开移动端性能是否可接受很多页面在演示时很流畅是因为数据太少。上线后性能问题暴露用户不会说“AI生成得不错”只会觉得系统不好用。七、检查部署能本地跑不等于能线上跑AI生成代码后常见情况是本地看起来能运行但部署时问题一堆。可能包括环境变量没配置依赖版本不一致构建命令缺失路由刷新404静态资源路径错误跨域配置不正确接口地址写死为本地地址HTTPS下资源加载失败上线前至少要确认构建命令是什么运行环境是什么环境变量有哪些接口地址如何区分开发和生产前端路由是否支持刷新静态资源路径是否正确是否支持HTTPS部署失败如何回滚如果AI生成的是一个纯前端原型这些问题可能不明显。但只要进入真实部署就必须处理。八、检查日志和监控出问题后怎么知道很多人只关心上线前能不能跑很少关心上线后怎么发现问题。但正式系统必须回答页面报错有没有记录接口失败有没有日志用户操作有没有关键事件记录性能变慢能不能发现部署后有没有健康检查出问题时谁负责处理有没有回滚方案没有日志和监控系统就像黑盒。用户说“打不开”你只能猜。用户说“提交失败”你也不知道失败在哪一步。AI生成网页时通常不会主动帮你设计完整监控体系。这部分必须由程序员补上。九、检查可维护性下个月谁来改AI生成的代码还有一个容易被忽略的问题可维护性。它可能会生成一个页面短期看能跑但代码结构很混乱。比如一个文件几百上千行样式和逻辑混在一起变量命名随意组件没有拆分重复代码很多没有注释没有类型约束没有测试上线前要问代码结构是否清晰后续修改是否容易组件是否能复用样式是否可维护是否需要补类型定义是否需要补测试是否需要重构后再上线如果只是临时演示可以接受粗糙一点。如果要长期使用就不能只追求“能跑”。AI让从0到1更快但从1到长期维护还是要靠工程能力。十、给程序员的一份接手清单如果你接到一个AI生成的网页或轻量应用可以按这个顺序检查明确它是原型还是正式系统标记所有假数据和真实数据确认登录、角色和权限边界检查前端是否暴露敏感信息补齐加载、失败、空状态和重试逻辑检查列表、图片、图表和首屏性能梳理部署命令、环境变量和生产配置加上必要日志、监控和回滚方案评估代码结构是否适合长期维护把不能上线的风险写进交付说明这份清单的目的不是反对AI生成网页。恰恰相反AI生成网页很有价值。它能快速把想法变成可见结果降低原型成本提高沟通效率。但程序员要做的是把“能看”变成“能用”再把“能用”变成“可长期维护”。十一、最后总结ChatGPT Sites这类能力的出现说明AI正在从内容生成走向结果交付。这对程序员不是坏事。以后很多页面原型、看板、报告页、内部工具草稿可能都会先由AI生成。程序员不一定要从空白文件开始写但需要承担更重要的工作判断边界。补齐工程能力。识别安全风险。处理真实数据。保证长期维护。AI生成网页只是第一步。上线前的检查才决定它到底是一个漂亮演示还是一个可靠系统。