AI 写代码，我盯着它翻车的那些瞬间

AI 写代码是真快。快到我一开始，是真的放手让它写——需求丢过去，它哗哗给我一大片，看着还挺像回事。

然后被坑了几次，我才学乖：它写得快，不代表你能不看着它。

这段时间我基本是「盯着 AI 写代码」过来的。哪些活能放心交给它、哪些必须盯死、哪一类操作我现在绝对不敢让它自己做——都是被它翻车翻出来的。今天把这些翻车的瞬间，和我后来立的规矩，一起给你。

先说结论，急的看这张图：

它会怎么翻车

一、不看全，就动手。

最常见的一个。你让它改一个函数，它盯着这个函数就改了，没去看这个函数被谁调用、整个文件的上下文是什么。结果这段改对了，却和别处对不上，引入一个更隐蔽的 bug。

道理不难懂：它擅长的是「把眼前这段写好」，不等于「先把整体搞明白再动手」。人改代码前会习惯性扫一圈上下文，它不一定会。

二、你要一把小勺子，它给你造了整套厨具。

你说「帮我写个函数判断字符串是不是空」，本来两行的事，它可能给你封装一个类、加一堆边界处理、再配上注释和类型声明。看着专业，其实你根本用不上，还平白多出一摊要维护的东西。

它训练时见的「好代码」大多是完整、规范、考虑周全的，所以它默认往「大而全」写。你要的是够用，它给的是「显得专业」。

三、「我已经做完了」——它是真敢这么说。

这个最坑。它会很有底气地告诉你「已完成、功能正常」，可它有时候根本没真跑过，只是看代码「像是对的」就下了结论。你要是信了直接用，就等着出事。

它说的「做完了」，很多时候是在预测「这里该说做完了」这句话，而不是真的验证过结果。这两件事，它自己有时也分不清。

四、聊长了，它会忘。

一个功能来回改了十几轮，改到后面，它可能忘了前面你定过的约定、忘了某个变量已经改过名，又给你绕回老路。不是它偷懒，是对话太长，前面的信息在它的「注意力」里被稀释掉了。

五、危险操作，它不长眼。

删文件、改数据库、覆盖已有内容——这类不可逆的操作，它执行起来和执行一句普通命令没什么两样，不会天然地「手先抖一下、停下确认」。它没有「这步做错就回不来了」的那种敬畏，那个敬畏，得你来兜。

六、它会一本正经地编。

调一个根本不存在的方法、传一个这个库压根没有的参数，写得跟真的一样。尤其冷门库、新版本 API，它记不准就「编一个看着合理的」给你。你不查，就被它带沟里去了。

七、你一质疑，它就秒怂。

这个有点微妙。它原本写对了，你一句「这样对吗」，它可能立刻道歉、推翻、改成错的。因为它被训得「顺着用户走」，你的质疑权重太高，它宁可迎合你，也不坚持自己那个对的。所以它点头同意的时候，含金量得打个折。

我后来立的七条规矩

翻够了车，我给自己、也给它，立了几条规矩。不复杂，但每一条都对着上面一个坑：

1. 先读再改。 动手前，让它先把「现在这块是怎么回事」复述一遍，复述对了再改。
2. 给小任务。 别一次丢一个大而全的需求，切小，一步步来，每步都能验。
3. 别信「做完了」，让它自证。 要求它把怎么验的、跑了什么、结果如何说清楚，最好真跑一遍给你看。
4. 危险操作，必须停。 删、改库、覆盖，一律先停下报备，你点头才动。
5. 长对话，定期重整。 聊长了，让它把当前状态总结一遍，或干脆重开一轮，把关键约定重新交代清楚。
6. 关键 API 要出处。 涉及具体的库和方法，让它给依据，别信它张口就来。
7. 它太顺从时，逼它反对。 拿不准就问它「反对意见是什么」，逼它把另一面讲出来，别让它只会点头。

说到底，你的角色变了

用下来我最大的感受，不是「AI 要取代程序员了」这种话。

是我的活变了。以前我大半时间在「写」，现在大半时间在「审」——审它读懂了没、审它做对了没、审这一步该不该让它动手。敲键盘的人，变成了把关的人。

这其实是个更高的位置，但也更难。因为你得比以前更懂：你自己心里没数，就审不出它错在哪，只能被它牵着走。AI 把「写」的门槛降下来了，却把「判断」的门槛抬上去了。

所以它到底是帮手还是坑，很大程度上不取决于它，取决于你会不会当那个盯着它的人。

这段时间我也还在学。但至少，我不再放手不管了。