别被 Claude Code 的生成速度骗了，AI 敲代码快不代表产品能落地

最近深度体验了 Claude Code，在开发一个内部小工具的过程中，那种代码像瀑布一样刷刷掉落的快感确实很爽。但当我把这个工具部署上线，面对真实数据跑了半天后，我突然意识到一个很残酷的现实：AI 从头到尾都没有帮我完成一个“能用的产品”，它只是帮我极速地完成了“打字”这个动作。

很多开发者现在陷入了一个误区，觉得只要提示词（Prompt）写得足够精妙，AI 就能接管整个开发流程。但实际上，AI 对“正确性”并没有任何执念。它产出的代码在语法上可能是完美的，逻辑上看起来也合理，但它根本不理解你的业务边界、历史包袱以及那些潜伏在需求深处的坑。

在这次开发过程中，我发现自己扮演的角色其实更像是一个极其严苛的审核员。虽然代码是 AI 写的，但我实际投入的精力分布在三个环节：首先，我必须把复杂的需求拆解成 AI 能理解的原子化小块，否则它很容易在长逻辑中迷失；其次，每生成一段功能代码，我都要花二十分钟进行人工 Review，确保它没有在某个边缘 case 上偷懒；最后，面对报错，我得把 Traceback 丢回去让它修改，这种“生成-报错-修正”的循环往往要跑三轮才能跑通。

最核心的问题在于架构的把控。AI 擅长在既定框架内“填砖”，但如果你让它从零规划一个可演进的系统，它给出的方案通常是“能跑但不能长久”的。比如数据库的表结构怎么拆分、服务边界在哪里、哪些模块必须异步化以保证性能——这些决定产品生死的问题，AI 无法替你思考。它会给你一份看起来专业得像教科书一样的方案，但一旦进入维护期，你会发现这种缺乏工程实践支撑的架构简直是灾难。

另外，我想打破一个关于“提示词工程”的迷信。很多人花大量时间研究怎么写 20 行的复杂提示词，试图通过指令让 AI 产出高质量代码。但我实际测试发现，同一个任务，用 20 行指令和用 3 行简单指令，结果的差距微乎其微。真正决定产出质量的不是指令的华丽程度，而是你喂给它的上下文（Context）。如果你不能提供准确的 API 文档、既有的代码风格指南以及清晰的项目结构，AI 只能在猜测中生成代码，这种猜测带来的就是所谓的“像样的垃圾”：格式完美、逻辑通顺，但一跑就崩。

现在的开发模式已经变了，AI 极大地降低了进入门槛，但它并没有提高天花板。天花板依然是你作为工程师的判断力。能区分一个资深开发者和初学者的，不再是由于谁更会写 Prompt，而是谁能一眼看出 AI 生成的代码里隐藏的 Bug，谁能判断这个方案在并发量提升后是否会崩溃。

总结来说，AI 负责快，而你必须负责“对”。这种对正确性的终极验收，是目前任何模型都无法替代的人肉环节。如果你把产品质量的希望完全寄托在 AI 的生成能力上，那么最终出问题的时候，承担责任的依然是你自己。