AI 写代码最可怕的地方,不是它会出错——谁都会出错——而是它出错的时候和做对的时候,看起来一模一样。它永远自信、永远流畅、永远给你一段结构工整的代码,附一句「已经处理好了」。你没法从语气里分辨真假。
所以「什么时候信、什么时候核」不能靠感觉,得有一套判断。我的原则可以浓缩成一句:按「错了会怎样」来决定核的力度,而不是按「它看起来对不对」。
可以放心信的地方
有一大类工作,AI 又快又稳,盯着它反而是浪费时间:
- 模板化、有大量先例的代码。加一个标准的增删改查、写一个常见组件、套一个成熟框架的用法——这些它在海量代码里见过无数遍,做得比你我都熟。
- 错了会立刻、明显暴露的东西。页面布局歪了你一眼看得见,语法错了根本跑不起来。这类错误自己会喊,不用你专门盯。
- 纯机械的转换。把数据从一种格式转成另一种、重命名、批量替换——只要有测试或肉眼能核对结果,放手让它做。
这些地方过度审查,是把精力花错了地方。省下来的注意力,要留给下面这些。
必须自己核的地方
危险的不是「难」的代码,而是「错了很晚才发现、且代价很大」的代码。它们往往看起来平平无奇:
1. 和钱、和权限有关的一切
金额算错、币种搞混、本该拦住的人放进来了——这类错误不会让程序崩溃,它会安静地运行,直到你对账时发现数字不对,或者用户看到了不该看到的东西。这里必须逐行看懂,不能「看起来对就过」。
我真实踩过的一个坑:一段把订单渠道映射成数字的代码,用了
channelType === "alipay" ? 3 : 4这种二选一写法。后来新增了一个海外支付渠道,它悄无声息地落进了「4」,于是后台把一笔美元订单显示成了「微信支付 ¥128」。代码没报任何错,一切看起来都在正常运行。
2. 「批量操作」和「静默失败」
凡是「对一批东西做同一件事」的代码,都要多留个心眼:万一其中一步没成功,它是会喊出来,还是默默跳过?
另一个真实的坑:我让 AI 批量替换一个配置文件里的多处内容,它写的替换逻辑在没匹配到的时候不报错、直接跳过。结果一处该改的地方没改到,而整个流程「成功」结束,没有任何异常。直到线上功能不对,才回头发现。教训是:批量修改一定要加一句「改了几处?和预期的一样吗?」的断言——不一致就当场报错,而不是让它悄悄溜过去。
3. 它「自信地告诉你一个事实」的时候
AI 会非常笃定地陈述关于你系统的「事实」:「这个字段是这个意思」「这两个地方是一致的」「改这里不会影响那里」。这些话有时对,有时是它根据常见情况脑补的。
我有次差点被自己带偏:我一口咬定「改用户名会打断镜像站的身份识别」,听起来很合理。是使用者反问了一句「用户名和令牌不是两个东西吗」,我去翻了代码才发现——识别逻辑同时认两个字段,改名根本不影响。凡是关于系统的关键判断,别信复述,去代码里亲眼看一遍。
4. 涉及删除、覆盖、不可逆的操作
删数据、覆盖文件、改线上配置——这些错了没有撤销键。哪怕再简单,动手前也要亲眼确认目标是不是你以为的那个。如果有备份可以对照原值,那就从备份取权威数据,而不是靠推算。多花的这几分钟,是在给自己买保险。
低成本兜底的几个习惯
「自己核」不等于「每一行都逐字审」——那样就失去了用 AI 的意义。关键是用最小的成本,兜住最大的风险:
- 让它给出可验证的证据,而不是结论。别满足于「已经修好了」,让它跑一遍、把实际输出贴出来。一段真实的运行结果,胜过十句「应该没问题」。
- 关键改动,让另一个视角来挑刺。开一段新对话,只让它扮演审查者,专门找刚才那段代码的毛病。它挑自己的错不积极,挑「别人」的错却很在行。
- 把断言写进流程。「改了 N 处,和预期一致才继续」「金额必须大于 0」——这些检查一旦写进代码,就再也不用靠你每次用眼睛盯了。
- 先在能扔掉的地方试。拿不准的操作,先在临时副本、测试数据上跑一遍,确认无误再对真实数据下手。
一条底线
你可以把动手的活儿全交给 AI,但有一件事永远不能外包:为结果负责。
它不会因为把你的数据搞错而睡不着觉,你会。所以在那些「错了会真的痛」的地方,判断权必须攥在你自己手里。这不是不信任 AI——恰恰是因为你想长期、放心地用它,才需要清楚地知道该在哪里,替它、也替自己,踩一脚刹车。