这半年我一直在用 Cursor 和 Claude Code 写代码。说实话单看编码速度确实比以前快了一倍不止。一个 CRUD 接口从写代码到跑通以前要半小时现在十分钟搞定。但问题来了项目整体交付速度并没有变快。不仅没变快修 bug 的时间反而多了。这不是我一个人的感受。The New Stack 最近发了篇文章标题就叫《AI coding got faster. Why didn’t engineering?》说 AI 让单个程序员变快了但工程整体没变快。我读完之后发现自己踩的坑全在里头。第一层幻觉编码速度快 ≠ 交付速度快很多人包括早期的我以为 AI 写代码 软件开发提速。这个等式只在最理想的情况下成立——当你只需要写一个独立的、没有外部依赖的函数时。现实是软件开发不是写代码是做决策。这块逻辑该放 service 层还是 controller 层这个数据模型是归一化还是反归一化这个接口要不要兼容旧版本AI 不管这些它只管按 prompt 生成代码而且是按最可能的方式生成——也就是按它见过的几百万个仓库的平均值来写。结果就是AI 生成的代码单看每段都还行但合在一起风格不一致、抽象层次混乱、依赖关系错综复杂。你花 10 分钟让 AI 写了个函数然后花 20 分钟修它和现有代码的兼容性问题再花 30 分钟补单元测试——因为 AI 不写测试或者写了也测不全。编码快了但决策和集成的时间一点没少反而因为 AI 代码的陌生感增加了。第二层幻觉AI 写代码你还是在 review有个说法我很认同用 AI 写代码就像是空降了一个技术不错但完全不了解你项目的新人。他写的代码你每行都得 review。而且这个新人不会主动说这个我没把握你帮我看一下——它自信地输出出错了也不负责。我以前用 Cursor 写一个文件处理模块AI 帮我生成了 80% 的代码看着很漂亮。结果上线后有一个边界情况没处理——AI 生成的正则表达式没考虑换行符在不同操作系统上的差异——导致服务在 Linux 服务器上崩溃了三次。这个 bug 如果是我自己写的五分钟就能定位。但因为代码不是我写的我花了两个小时才找到根因。这就是 AI 编码的隐性成本你节省了写代码的时间但付出了更多理解和调试的时间。第三层幻觉个体效率提升 ≠ 组织效率提升这是一个更宏观的问题。一个团队里如果只有一个人用 AI 写代码效率确实能提升。但如果整个团队都用麻烦就来了。每个人的代码风格都被 AI “平均化了但每个人用的 AI 工具、模型版本、prompt 习惯都不一样。A 用 Claude 生成的代码结构和 B 用 GPT-4 生成的有微妙差异。代码审查时大家都觉得这段代码看着还行但总觉得哪里不对劲”又说不出具体问题。更麻烦的是AI 生成的代码往往缺乏为什么的痕迹。人类写代码时会在注释里留下思考过程——“这里用 Map 而不是 List 因为要保证 O(1) 查找”。AI 不写这种注释它只输出结果。几个月后回来维护你根本不知道那段代码当初为什么那么写。The New Stack 文章里提到一个关键数据工程组织里 AI 工具的 seat activation 很高但实际交付指标没有明显变化。原因很简单——打字快不等于做得好写代码快不等于软件好。那 AI 到底该怎么用说了这么多我不是在否定 AI 辅助编程。相反我觉得这半年是我写代码效率提升最快的时期。关键在于知道 AI 擅长什么不擅长什么。AI 擅长的事写样板代码、生成测试用例、翻译代码、重构已知模式、写文档注释。这些事占了一个程序员 30%-40% 的时间让 AI 干省下的时间去做更有价值的事。AI 不擅长的事做架构决策、理解业务上下文、处理边界情况、维护代码一致性、写注释解释为什么。这些事才是决定软件质量的关键也是程序员不可替代的部分。我的原则是让 AI 写怎么做自己想做什么和为什么做。代码生成完逐行 review 理解改掉不符合项目风格的地方加上必要的注释。看起来是多了一步但实际上比完全自己写还是要快。结尾AI 编码工具是很好的加速器但不是魔法棒。你写代码的速度翻倍了但做决策、review、调试、集成的时间并没有减少。如果整个团队都在用还要额外花时间统一代码风格和补充为什么的注释。真正的效率提升不是让 AI 替你写代码而是让 AI 帮你把时间花在更有价值的事情上。如果你也在用 AI 写代码遇到过类似的问题欢迎留言聊聊。你踩过什么坑又是怎么解决的 AI 编码变快了，为什么工程交付反而没变快？
这半年我一直在用 Cursor 和 Claude Code 写代码。说实话单看编码速度确实比以前快了一倍不止。一个 CRUD 接口从写代码到跑通以前要半小时现在十分钟搞定。但问题来了项目整体交付速度并没有变快。不仅没变快修 bug 的时间反而多了。这不是我一个人的感受。The New Stack 最近发了篇文章标题就叫《AI coding got faster. Why didn’t engineering?》说 AI 让单个程序员变快了但工程整体没变快。我读完之后发现自己踩的坑全在里头。第一层幻觉编码速度快 ≠ 交付速度快很多人包括早期的我以为 AI 写代码 软件开发提速。这个等式只在最理想的情况下成立——当你只需要写一个独立的、没有外部依赖的函数时。现实是软件开发不是写代码是做决策。这块逻辑该放 service 层还是 controller 层这个数据模型是归一化还是反归一化这个接口要不要兼容旧版本AI 不管这些它只管按 prompt 生成代码而且是按最可能的方式生成——也就是按它见过的几百万个仓库的平均值来写。结果就是AI 生成的代码单看每段都还行但合在一起风格不一致、抽象层次混乱、依赖关系错综复杂。你花 10 分钟让 AI 写了个函数然后花 20 分钟修它和现有代码的兼容性问题再花 30 分钟补单元测试——因为 AI 不写测试或者写了也测不全。编码快了但决策和集成的时间一点没少反而因为 AI 代码的陌生感增加了。第二层幻觉AI 写代码你还是在 review有个说法我很认同用 AI 写代码就像是空降了一个技术不错但完全不了解你项目的新人。他写的代码你每行都得 review。而且这个新人不会主动说这个我没把握你帮我看一下——它自信地输出出错了也不负责。我以前用 Cursor 写一个文件处理模块AI 帮我生成了 80% 的代码看着很漂亮。结果上线后有一个边界情况没处理——AI 生成的正则表达式没考虑换行符在不同操作系统上的差异——导致服务在 Linux 服务器上崩溃了三次。这个 bug 如果是我自己写的五分钟就能定位。但因为代码不是我写的我花了两个小时才找到根因。这就是 AI 编码的隐性成本你节省了写代码的时间但付出了更多理解和调试的时间。第三层幻觉个体效率提升 ≠ 组织效率提升这是一个更宏观的问题。一个团队里如果只有一个人用 AI 写代码效率确实能提升。但如果整个团队都用麻烦就来了。每个人的代码风格都被 AI “平均化了但每个人用的 AI 工具、模型版本、prompt 习惯都不一样。A 用 Claude 生成的代码结构和 B 用 GPT-4 生成的有微妙差异。代码审查时大家都觉得这段代码看着还行但总觉得哪里不对劲”又说不出具体问题。更麻烦的是AI 生成的代码往往缺乏为什么的痕迹。人类写代码时会在注释里留下思考过程——“这里用 Map 而不是 List 因为要保证 O(1) 查找”。AI 不写这种注释它只输出结果。几个月后回来维护你根本不知道那段代码当初为什么那么写。The New Stack 文章里提到一个关键数据工程组织里 AI 工具的 seat activation 很高但实际交付指标没有明显变化。原因很简单——打字快不等于做得好写代码快不等于软件好。那 AI 到底该怎么用说了这么多我不是在否定 AI 辅助编程。相反我觉得这半年是我写代码效率提升最快的时期。关键在于知道 AI 擅长什么不擅长什么。AI 擅长的事写样板代码、生成测试用例、翻译代码、重构已知模式、写文档注释。这些事占了一个程序员 30%-40% 的时间让 AI 干省下的时间去做更有价值的事。AI 不擅长的事做架构决策、理解业务上下文、处理边界情况、维护代码一致性、写注释解释为什么。这些事才是决定软件质量的关键也是程序员不可替代的部分。我的原则是让 AI 写怎么做自己想做什么和为什么做。代码生成完逐行 review 理解改掉不符合项目风格的地方加上必要的注释。看起来是多了一步但实际上比完全自己写还是要快。结尾AI 编码工具是很好的加速器但不是魔法棒。你写代码的速度翻倍了但做决策、review、调试、集成的时间并没有减少。如果整个团队都在用还要额外花时间统一代码风格和补充为什么的注释。真正的效率提升不是让 AI 替你写代码而是让 AI 帮你把时间花在更有价值的事情上。如果你也在用 AI 写代码遇到过类似的问题欢迎留言聊聊。你踩过什么坑又是怎么解决的