AI写代码比咖啡凉得还快，真正的瓶颈却换了地方

在洛美（Lomé）的办公桌前，AI编程助手让一件怪事发生了：一杯咖啡还没凉，一个Node API、一个React仪表盘和一个Flutter页面就能搭出雏形。速度已经不是问题。问题是，看起来合理的代码涌过来的速度，快过大脑产生怀疑的速度。

这不是反对AI。日常做全栈开发和GDG洛美社区的工作时，AI每天都在用。反对的是凭感觉上线。真正值得写下来的，是一套验证习惯——给那些大量生成代码、又想晚上睡得着的人。

瓶颈从敲键盘挪到了别处

几年前，卡住人的是“这条Express路由怎么写”。今天卡住人的问题变成了另一副样子：

• 这个处理函数是不是在每条路径上都真正校验了权限？
• React表单在提交途中网络断了，能不能恢复？
• Flutter页面在中端安卓机、信号飘忽的4G下还能不能用？
• 模型是不是编了一个看起来很像真的SDK方法？

生成变便宜了，成本就往后移。工作重心变成产品判断、契约清晰度，以及能抓住“自信的错误”的测试。

一套适合个人和小团队的验证循环

这套循环分五步，刻意做得很枯燥。

第一步，粘代码之前先冻结契约。在让助手动手实现之前，用大白话（或TypeScript类型、OpenAPI桩）把契约写清楚：输入输出、权限规则、失败模式（超时、空列表、部分写入）、绝对不能发生什么。比如一个聚会报名的接口，先手写请求和结果的结构，座位数限定在1到5之间，失败原因只允许“满员”“已关闭”“未授权”这几种。助手实现不出这个形状，就退回补丁，不能因为生成的代码“差不多能跑”就把契约谈没了。

第二步，只要最小的改动，然后像审查者一样重读。大段粘贴会藏雷，最好一次一个文件、一次一件事（校验、持久化、界面分开）。审查时重点找这些模式：只走顺利路径（没有catch、没有空状态）、用|| []或?? true这类静默默认值把bug盖住、你没要求却多出来的依赖、注释写的意图和代码实际行为对不上。把模型当成一个手快的新同事：有用、认真，偶尔会凭空发明API。

第三步，用“要是线上挂了会很丢脸”的测试来证明行为。不需要铺天盖地的覆盖率，只需要几个锋利的测试：缺token时拒绝访问；重复提交不会重复扣座位；超时路径返回安全错误，而不是写了一半的数据；界面显示离线或重试，而不是永远转圈。Node这边保留一个打真实路由的轻量集成测试，配测试库或内存替身；React测表单的状态机，不测CSS；Flutter测包住http和连通性判断的仓库层——“在我家光纤上能跑”的谎话就死在这一层。

第四步，用你能借到的最差网络跑一遍。如果产品面向西非或任何网络不稳的地方，就在Chrome限速到慢速3G、真机移动数据、操作中途开飞行模式这三种条件下验证。AI生成的界面特别爱用乐观更新，而乐观更新没有冲突处理，就会造出幽灵报名和重复聊天消息。乐观要配上三样东西：客户端生成幂等键、清晰的“待处理/已同步/失败”状态、冲突时以服务端规则为准。

第五步，每个PR都留一份“人来负责”的清单。哪怕单干，也假装有个审查者。清单包括：每个分支都查过认证和授权；密钥不进日志，环境变量有文档；迁移可回滚或至少注明；AI功能若调用付费API，要有功能开关或熔断；PR里写一段话说明可能出什么问题。最后这条最值钱——说不清失败模式，就说明还没看懂这个补丁。

什么交给AI，什么自己留着

适合交给AI的：根据已写好的类型生成Zod schema样板、有清晰前后对比的重构、匹配现有函数签名的测试桩、粘上真实堆栈后解释陌生报错。

不适合直接交的（除非狠狠验证）：“把整个认证系统搭出来”“做成生产可用”“给应用加AI”却不给产品边界、因为“模型说该升”就盲目接受依赖升级。

不管做什么产品，先找到那条“钱或信任”的路径——支付、报名、成绩、医疗类数据、管理员删除——优先验证它。一个可复用的报名接口结构是：先认证，再校验请求体，然后在一个事务里锁住活动行、检查容量、带幂等键插入记录，最后返回确认或带类型的失败。只让助手实现事务那一步，其余桩子自己写。合并之后手动把它弄坏：发重复的键、让会话中途过期、把活动填到满员。这些情况处理得难看，功能就没做完，生成的界面再漂亮也没用。

在GDG的活动上，最有用的演示很少是“看模型写了多少”，而是“看我们怎么抓住了坏路径”。带新人的时候，把验证和提示词一起当作一等技能来教。否则训练出来的一代人，能生成应用，却操作不了它。

AI可以起草你的功能，真相仍然由你来交付。