作为从未写过代码的人，我在“氛围编程”中踩过最大的坑

我是汽车行业的采购人员，完全没有编程背景。过去六个月，我一直在用AI（Claude、Cursor）构建一个Excel查询工具。我曾以为最困难的部分是“让AI理解我在问什么”。结果发现，真正的陷阱并不在这里。**真正的陷阱：AI每次都能“修复”一个问题，但你无法判断它是真正修复了，还是只是打了个补丁掩盖过去。** 举个例子。我系统里有一个查询——询问零件价格——陷入了死循环，一遍又一遍地给出错误答案，消耗了150万token才最终停下来。我让Cursor去修复。它确实修好了——那个特定情况不再发生了。但后来我发现它是如何“修复”的：基本上就是“如果这个零件号是X，就按这种方式处理。”换句话说，它根本没有触及最初陷入循环的*原因*。它只是为那一个特定情况开辟了一个特殊例外。 **而这才真正要命**：这种修复在短期内看起来完全有效——bug消失了，你觉得“太好了，问题解决了。”但你完全没有能力判断这次修复是堵住了真正的漏洞，还是仅仅绕开了一次。因为对于一个看不懂代码的人来说，这两种结果看起来一模一样。 所以六个月下来，我的系统里充满了这些碎片，每个看起来都是独立的，但实际上都是各自在修补同一个底层问题。然后有一天，我遇到了一个全新的、没人做过特殊处理的情况，整个系统又崩了——而这次调试起来极其痛苦，因为代码库里散落着各种一次性补丁，根本没法判断哪一个（如果有的话）与这次新故障有关。 我最终找到的解决办法，说出来简直简单得让人不好意思：**每次AI说“修好了”的时候，直接问它：“这是通用规则，还是针对这一个实例的特殊情况？”** 如果答案里包含具体的名称、具体的ID、具体的数字（“如果这个零件号等于X”）——那就是危险信号。它可能是在打补丁，而不是真正修复。 另外两个我真正坚持下来的习惯：定期让AI重新扫描整个代码库，寻找“同样的模式可能还藏在哪些地方”。这已经不止一次地发现了同一个bug真实存在但此前不可见的实例。把你在过程中得出的每一条原则都写进一份持续更新的文档里。六个月后，你会忘记自己当初为什么这样设计——这份文档能阻止一个新的建议悄悄把你带回到同一个错误中。 **对于做AI辅助编程的非工程师来说，最大的障碍从来不是“不会写代码”。而是无法判断一个给定的修复是真正解决了问题，还是只是把它埋得更深。** 短期内两者看起来完全一样——问题无论哪种方式都“消失了”。你只能在很久以后才发现到底是哪种情况，通常那时清理起来已经困难得多。