作者反思AI辅助编程的边界:AI擅长续写符合模式的代码,但不理解业务逻辑;边缘条件需要人工明确告知,否则AI会自信地填充错误假设。
有一段时间,我给 AI 输入完 prompt 就直接复制粘贴到项目中,连仔细看一遍都省了。代码跑起来,demo 很顺,老大点头认可。结果两周后,一个生产环境的 bug 让我花了一整个晚上才找出原因:一个边界条件,AI "忘记" 处理了,因为我从来没跟它明确说过。
从那以后,我用 AI 的方式变了。不是不用,而是用得更刻意了。这篇文章不是技术教程,只是我在一段足够长的时间里、热情退潮之后总结出来的几点感受。

AI 不懒,它只是不知道自己缺了什么
最让我意外的不是 AI 写错了,而是它语法写得特别自信,逻辑完全不对的情况下也写得很笃定。没有任何警示信号。一个折扣计算函数跑得顺顺当当,直到有人输入了负数的百分比。
我慢慢明白了:模型并不"理解"我的业务,它只是在根据我的描述预测下一步最可能出现的代码。如果我描述得粗糙,它就会用自己的一套假设去填补空白,而那些假设并不总是符合我的系统。
所以现在,每次让 AI 写任何涉及重要逻辑的东西之前,我会先问自己:如果一个刚入职的同事,对 codebase 一无所知,读了我刚才输入的那些内容,他们会写出我想要的东西吗?如果答案是不确定,那我的 prompt 就还不够。
最容易踩的坑:让 AI 一次性写完整功能
刚开始用的时候,我经常这样提需求:"帮我写一个完整的登录功能"。结果通常会缺其中某一块:密码哈希不规范、token 过期没处理、或者 input 校验漏了。不是因为 AI 不行,而是需求太宽泛,AI 必须自己判断什么重要,而它的选择不一定和我需要的一致。
更好的方式是拆开写。一步一步来,每一步写完先 review,再拼起来。比 10 秒内拿到一整块代码要慢,但后续 debug 的时间实实在在少了。
review AI 写的代码,就像 review 新人代码
这是我思维上最大的转变。AI 不知道项目中某段旧逻辑为什么被写成那样奇奇怪怪,不知道团队曾经踩过哪些特殊 case 并修过它。它只能看到我塞进 prompt 里的那点上下文。
所以我 review AI 代码的方式,和 review 新人代码一模一样,哪怕那段代码"看起来挺正常"。跑测试、试几个边界 case、仔细看错误处理。对于涉及安全或金钱数据的部分,我一定亲手重写校验逻辑,而不是完全信任 AI。
有一阵子我也好奇地在几个工具之间换来换去,看哪个更适合自己的 workflow,偶然读到了一篇相当详细的综合测评,关于 AI 写代码这件事,把各种类型的优劣势按照实际使用需求做了对比,省得我自己一个个装一个个测——那正是我一开始干的事。
8 个月后我依然保留的做法
我不抛弃 AI,反而用得更多了——用在重复性的事情上:写 boilerplate、为基础 case 生成单元测试、解释一段没人记得逻辑的旧代码。这些事 AI 做得快,而且相当靠谱。
但对于影响架构的决策,或者代码涉及敏感数据,我依然自己写,或者至少在 merge 之前自己一行一行读。AI 对我来说现在就像一个干活快但还不熟悉项目的同事,确实有用,只是不能把活交代出去就转身走开。
如果你也在日常工作中用 AI 写代码,我很好奇你们是怎么控制质量的,特别是 review 环节。留言说说吧。