有一段时间，我写完提示词就直接把AI生成的代码复制粘贴进项目，没有仔细阅读。代码能跑，演示流畅，老板点头认可。两周后，一个线上故障让我花了整个晚上才找到原因：一个边界条件被AI“忘记”处理了，因为我从来没有向它明确说明过这个条件。

从那以后，我开始用不同的方式使用AI。不是放弃，而是更有意识地使用。这篇文章不是技术教程，只是我在足够长的时间过去、最初的兴奋消退之后总结出的几点体会。

打开网易新闻 查看精彩图片

AI不是懒惰，它只是不知道自己缺什么

最让我意外的不是AI写错代码，而是它非常自信地写出语法正确的代码，即使逻辑完全错误。没有任何警告信号。一个计算折扣的函数运行得很顺畅，直到有人输入了负数百分比。

我逐渐明白：模型并不“理解”我的业务，它只是根据我描述的内容预测接下来最可能出现的代码。如果我描述得粗略，它就会用自己的假设填补空白，而这些假设并不总是符合我的系统。

所以现在，在让AI写任何涉及重要逻辑的代码之前，我会问自己：如果一个刚进公司、对代码库一无所知的新开发人员，只读到我刚才输入的内容，他能写出我想要的东西吗？如果答案是不确定，那我的提示词还不够充分。

最容易踩的陷阱：让AI一次性写完整个功能

刚开始用时，我经常提出“帮我写一个完整的登录功能”这样的要求。结果通常缺少其中一部分：密码哈希不符合标准、令牌过期处理缺失，或者输入验证不完整。不是因为AI差劲，而是因为需求太宽泛，AI必须自己选择什么重要，而这个选择并不总是与我需要的重合。

更好的做法是拆分成小块。一部分一部分来，每部分都先审查再拼接。比起10秒内拿到一整块代码，这样做更慢，但之后调试的总时间明显减少了。

像审查新入职的初级开发人员一样审查AI代码

这是我思维方式上最大的改变。AI不知道项目里某段旧逻辑为什么被写得那么奇怪的历史原因，不知道团队以前遇到过并修复过的特殊场景。它只能看到我放进提示词里的那部分上下文。

所以我审查AI代码时，就像审查一个新同事的代码一样，即使那段代码“看起来没问题”。运行测试，尝试几个边界情况，仔细阅读错误处理部分。对于涉及安全或资金数据的部分，我总是自己手写验证逻辑，而不是完全信任AI。

有一段时间，我也出于好奇尝试了多种不同的工具，看哪个更适合自己的工作流程，偶然读到一篇相当详细的关于AI编程工具的综述，比较了每种工具在实际使用需求下的优缺点，省去了像我最初那样自己安装并逐一测试的麻烦。

8个月后我仍然保留的做法

我没有放弃AI，反而在重复性工作上用得更多了：写样板代码、为基础场景生成单元测试、解释一段没人记得逻辑的旧代码。这些工作交给AI处理，确实能省下不少时间。

但涉及核心业务逻辑、边界条件、安全验证的部分，我仍然保持自己动手的习惯。AI可以给出建议，但最终的决定权在我手里。8个月下来，最大的收获不是代码写得有多快，而是我更清楚自己到底在写什么、为什么这样写。