AI 生成的代码上线前，需要同时检查功能正确性、权限与数据安全、故障发现和恢复能力。下面六项是检查起点，不能替代针对实际系统的审查。
能跑只证明主路径通了。上线后等着你的是空数据、超长输入、重复点击、断网重试——这些你在对话里几乎没提过，模型也就没写。
结论先给：判断标准是「出错时你能不能发现」
一个功能上线前，问自己两句：它错了，我多久能知道？知道了，我多久能退回去？
两个问题都答不上来，代码写得再干净也不能发。正确性、可发现性和可恢复性都需要检查；能回退不能抵消权限错误或数据泄露。
这条标准还有个实际好处：它不要求你读懂每一行。你可以不懂那段正则，但你必须知道它错了会在哪里显形。
至于「AI 写的代码能直接用吗」，答案落在这一句上：不能只根据代码由谁生成来判断。要按真实输入、身份、依赖和失败条件验证，再决定是否适合发布。
第一项：错误处理与边界输入
怎么查：固定五类输入，各手动走一次——空值、超长、格式错、重复提交、未登录。五类都试过，才算查过这一项。
再补三问：接口返回 500 时页面显示什么？请求超时呢？第三方服务挂了，是报错，还是假装成功？
不过怎么办：先保证错误可见。提示、兜底值、拒绝写入，三种都行；唯一不能接受的是静默失败——看着像成功，实际没写成。
时间不够时，先加输入限制（长度、格式、必填）再补异常处理。加一条校验是几行的事，补整套异常处理是一轮改动。
最常见的漏洞是把「成功」当成默认路径。生成的代码常常只写了 try，catch 里什么也没做。
第二项：鉴权与权限
怎么查：三个身份各走一遍——未登录、普通用户、另一个普通用户。第三种最容易漏：把 URL 里的 id 换成一个不属于自己的值，看能不能打开。
再查一处：接口能不能被直接调用。前端藏起来的按钮不构成权限。
不过怎么办：所有判断放服务端，前端只负责显示。如系统支持数据库层面的行级限制，可作为补充，但仍需验证配置与业务层权限一致。
AI 代码在这一项上错得很集中：它会在页面组件里判断「有没有登录」，然后接口完全不校验。页面是给人看的，接口是给所有人看的。
第三项：数据写入与幂等
怎么查：同一件事做三遍——连点两次按钮、刷新后再提交一次、断网后重试一次。然后回去数记录条数。
计数、余额、次数、库存这类字段是重灾区。少一条没人注意，多一条要人工清。
不过怎么办：按业务操作设计幂等键、数据库唯一约束和事务边界，并明确失败后的结果查询。仅禁用按钮、加一个未受并发保护的“处理中”标记，或短时间拦相同请求，都不能保证幂等。外部服务调用也要核对其幂等与重试合同；状态不明时先查结果，避免重复执行。
这一项性价比最高，也最容易被跳过。重复数据的清理时间，通常比当初加一次检查多得多。
第四项：日志与可观测
怎么查：故意制造一个错误，然后计时——你花多久能说出「哪个用户、哪一步、什么参数、什么错误」。
超过五分钟找不出来，说明日志不够用。上线后用户只会说「不好使了」，剩下全靠日志。
不过怎么办：至少记三样：时间、动作、结果（含错误码）。不要记密码、token、完整手机号。
还有一个很便宜的做法：给关键失败加一条通知。宁可多收几条，也别等用户来告诉你。
第五项：依赖与密钥
怎么查：先检查这些位置：密钥有没有出现在代码仓库里、有没有被打进前端包、依赖有没有锁版本。
再扫一遍来源不明的包。AI 代码有时会写出一个看起来正规、实际并不存在的依赖名，装进去的东西不是你选的。
不过怎么办：密钥挪到环境变量，然后立刻轮换——它已经进过仓库，就当它已经泄漏。依赖锁版本；不确定的包先删，再找替代。
具体工具支持什么、怎么配，以官方文档为准，不要照抄某篇文章里的配置片段。
第六项：回滚与备份
怎么查：假装线上已经坏了，演练一次退回上一版，计时，看能不能在十分钟内完成。
再确认一件事：这次改动动了数据结构没有。动了就要有对应备份——AI 代码能退回去，数据不一定能。
不过怎么办：发布前保留可部署的旧产物和配置；Git 标签能定位源代码，但不能替代可用的部署包。数据库和必要文件按影响范围备份，并验证能够恢复。没有回滚方案的上线，本质是赌一次。
顺序上，回滚排在最后查，但要最先准备。对无法通过回退撤销的影响，还需要事先设置权限、验证和停止机制。
什么项目必须人工 review
有些项目不适合「AI 写完直接发」，这跟代码质量无关，跟责任归属有关：
- 涉及钱：支付、计费、退款、结算
- 涉及他人数据：能看、能导出、能删
- 涉及对外承诺：报价、合同、交付时间
- 有合规要求：金融、医疗、教育等资质相关
这几类需要的不是更细的清单，是一个能对结果负责的人。人工审查应同时覆盖改动差异、实际行为和关键失败路径，只跑一遍主路径并不足够。
反过来，可以快一点的场景也很明确：内部工具、活动页、自己的原型、不接触真实用户数据的功能。可以按实际影响缩小检查深度，但不能默认跳过依赖、密钥或恢复检查。内部工具同样可能连接真实数据、外部接口或生产账号。
不适用边界
这份清单只管「上线前」，不管「该不该做」。性能、架构、长期维护都不在这六项里。
强性能要求的场景先要 profiling 和真实数据，模型看不到你的数据，也给不出瓶颈判断。多人长期维护的系统，风格与异常处理需要人兜底，AI 代码质量过关不代表系统可维护。
每项具体怎么实现、工具支持到什么程度，以官方文档为准；本文只给检查顺序和判断标准。
查完要留下一句话
检查最容易变成形式：六项都打了勾，问起来一条结论也说不出。
改成写结论，每项三选一：通过、不通过、没测到。「没测到」必须单独标，不能混进「通过」——它下次还是同一个坑。
这套判断和从需求到上线是同一件事的两头：那边定义什么算对，这边确认错了能不能发现。团队协作时谁该看 diff、谁该跑代理，两个工具的分工里有更细的划分。
六项查完再发。把查出来的问题、没测到的项写成一条构建记录，下次上线照着看；具体报错拿不准，去技术求助问，也可以先在广场翻同类记录。
社区讨论 0 条观点