AI 写的代码怎么上线？发布前必查的 6 项

AI 代码能不能上线，不看它跑没跑通，看它出错时你能不能发现。能发现、能退回，才叫可上线。下面 6 项都按这个标准排。

能跑只证明主路径通了。上线后等着你的是空数据、超长输入、重复点击、断网重试——这些你在对话里几乎没提过，模型也就没写。

结论先给：判断标准是「出错时你能不能发现」

一个功能上线前，问自己两句：它错了，我多久能知道？知道了，我多久能退回去？

两个问题都答不上来，代码写得再干净也不能发。AI 代码上线的门槛不在正确性，在可发现性和可逆性——正确性是目标，后两样才是保底。

这条标准还有个实际好处：它不要求你读懂每一行。你可以不懂那段正则，但你必须知道它错了会在哪里显形。

至于「AI 写的代码能直接用吗」，答案落在这一句上：主路径上常常能直接用，边界上基本不能。差的不是模型能力，就是下面这六项有没有人查过。

第一项：错误处理与边界输入

怎么查：固定五类输入，各手动走一次——空值、超长、格式错、重复提交、未登录。五类都试过，才算查过这一项。

再补三问：接口返回 500 时页面显示什么？请求超时呢？第三方服务挂了，是报错，还是假装成功？

不过怎么办：先保证错误可见。提示、兜底值、拒绝写入，三种都行；唯一不能接受的是静默失败——看着像成功，实际没写成。

时间不够时，先加输入限制（长度、格式、必填）再补异常处理。加一条校验是几行的事，补整套异常处理是一轮改动。

最常见的漏洞是把「成功」当成默认路径。生成的代码常常只写了 try，catch 里什么也没做。

第二项：鉴权与权限

怎么查：三个身份各走一遍——未登录、普通用户、另一个普通用户。第三种最容易漏：把 URL 里的 id 换成一个不属于自己的值，看能不能打开。

再查一处：接口能不能被直接调用。前端藏起来的按钮不构成权限。

不过怎么办：所有判断放服务端，前端只负责显示。数据库层面的行级限制能开就开，它比业务代码里堆 if 更难写错。

AI 代码在这一项上错得很集中：它会在页面组件里判断「有没有登录」，然后接口完全不校验。页面是给人看的，接口是给所有人看的。

第三项：数据写入与幂等

怎么查：同一件事做三遍——连点两次按钮、刷新后再提交一次、断网后重试一次。然后回去数记录条数。

计数、余额、次数、库存这类字段是重灾区。少一条没人注意，多一条要人工清。

不过怎么办：写入前用唯一键去重，或者加一个「处理中」状态挡住重复请求。改不动表结构时，至少在服务端拦掉短时间内的相同请求。

这一项性价比最高，也最容易被跳过。重复数据的清理时间，通常比当初加一次检查多得多。

第四项：日志与可观测

怎么查：故意制造一个错误，然后计时——你花多久能说出「哪个用户、哪一步、什么参数、什么错误」。

超过五分钟找不出来，说明日志不够用。上线后用户只会说「不好使了」，剩下全靠日志。

不过怎么办：至少记三样：时间、动作、结果（含错误码）。不要记密码、token、完整手机号。

还有一个很便宜的做法：给关键失败加一条通知。宁可多收几条，也别等用户来告诉你。

第五项：依赖与密钥

怎么查：三个搜索就够——密钥有没有出现在代码仓库里、有没有被打进前端包、依赖有没有锁版本。

再扫一遍来源不明的包。AI 代码有时会写出一个看起来正规、实际并不存在的依赖名，装进去的东西不是你选的。

不过怎么办：密钥挪到环境变量，然后立刻轮换——它已经进过仓库，就当它已经泄漏。依赖锁版本；不确定的包先删，再找替代。

具体工具支持什么、怎么配，以官方文档为准，不要照抄某篇文章里的配置片段。

第六项：回滚与备份

怎么查：假装线上已经坏了，演练一次退回上一版，计时，看能不能在十分钟内完成。

再确认一件事：这次改动动了数据结构没有。动了就要有对应备份——AI 代码能退回去，数据不一定能。

不过怎么办：发布前留一个可部署的旧版本，打标签也算；数据库改动先导出。没有回滚方案的上线，本质是赌一次。

顺序上，回滚排在最后查，但要最先准备。它是其他五项全部失手时唯一的出口。

什么项目必须人工 review

有些项目不适合「AI 写完直接发」，这跟代码质量无关，跟责任归属有关：

• 涉及钱：支付、计费、退款、结算
• 涉及他人数据：能看、能导出、能删
• 涉及对外承诺：报价、合同、交付时间
• 有合规要求：金融、医疗、教育等资质相关

这几类需要的不是更细的清单，是一个能对结果负责的人。人工 review 看的是 diff，不是把功能再跑一遍——跑一遍只证明主路径还在。

反过来，可以快一点的场景也很明确：内部工具、活动页、自己的原型、不接触真实用户数据的功能。这些错了代价可控，前四项做到就够。

不适用边界

这份清单只管「上线前」，不管「该不该做」。性能、架构、长期维护都不在这六项里。

强性能要求的场景先要 profiling 和真实数据，模型看不到你的数据，也给不出瓶颈判断。多人长期维护的系统，风格与异常处理需要人兜底，AI 代码质量过关不代表系统可维护。

每项具体怎么实现、工具支持到什么程度，以官方文档为准；本文只给检查顺序和判断标准。

查完要留下一句话

检查最容易变成形式：六项都打了勾，问起来一条结论也说不出。

改成写结论，每项三选一：通过、不通过、没测到。「没测到」必须单独标，不能混进「通过」——它下次还是同一个坑。

这套判断和从需求到上线是同一件事的两头：那边定义什么算对，这边确认错了能不能发现。团队协作时谁该看 diff、谁该跑代理，两个工具的分工里有更细的划分。

六项查完再发。把查出来的问题、没测到的项写成一条构建记录，下次上线照着看；具体报错拿不准，去技术求助问，也可以先在广场翻同类记录。