“10倍速度，0倍理解？”AI代写代码的那些坑

see122

2025 年，AI 编程助手已经能在几秒钟内写出成百上千行代码，看起来好像能把开发效率提升好几倍。但真实情况并没有那么简单——写代码只是软件开发的一小部分，理解需求、设计架构、测试验证、团队协作才是大头。而 AI 的加入，让这些环节既更快，也更容易出问题。本文作者将探讨，如何把这些“超高速的初级工程师”用得聪明，让速度真正转化为能用、靠谱的软件。

如果你观察过别人“写代码”的过程，可能就会发现他们花在“发呆”上的时间比敲键盘的时间还多。当然，也不要想太多，这些程序员大概率不是在偷懒。毕竟软件开发本质上就是一种解决问题的过程，就像解复杂的填字游戏一样，真正的工作大多发生在脑子里。

在整个软件开发生命周期中，写代码只是往填字游戏里填字母——相对来说只是很小的一部分。更多的精力其实用在周边工作上：开发者需要先理解业务领域，逐步明确需求，设计合适的抽象结构，思考各种副作用，一点点测试新功能，最后还要消灭在过程中漏网的 bug。

日常来看，写代码的实际情况就是这样的：

但是，当 AI 介入写代码时，情况就完全不一样了。

“先写代码，问题以后再说”

像 Claude Code 这样的 AI 编程助手，可以非常快地单独生成代码。但大多数软件并不是孤立存在的，而是运行在复杂系统中。由于大模型（LLM）还没法一次性记住一个应用的全部上下文，因此，人工的审查、测试和集成仍然不可或缺。问题在于，当代码是 AI 写出来而不是人边思考边写时，这些后续工作会变得更难。结果就是，在复杂软件里，开发者常常要花更多时间去“事后理解”AI 写出来的代码。

换句话说，是“先写代码，再去理解”。

这也正是为什么营销宣传里常说 AI 编程能“使得编码速度提升 10 倍”，但现实中开发者真正交付可用软件时，效率提升往往只有 10% 左右。

更让人沮丧的是，开发者花的时间越来越多是在“善后”。AI 可以飞快地生成那些有趣、简单的部分，而留给人的则是那些又繁琐又不讨喜的工作：测试保证旧功能没被破坏、清理重复代码、写文档、搞部署和运维……真正能用来写代码的时间反而更少了。

不过，好消息是：虽然 AI 让这个问题更明显，但它本质上并不罕见。事实上，这只是一个老问题的新说法，我称之为：“技术负责人的两难”。

“技术负责人的两难”

随着工程师资历增长，很多人会成为技术负责人。有的会带团队，有的则是资深工程师，不管有没有管理职责，他们的任务都是确保团队的技术交付。通常来说，他们也是团队里经验最丰富的人——无论是职业年限、专业领域，还是两者兼具。

软件交付需要团队协作，但“经验差距”会让不同成员的产出效率相差很大。于是，技术负责人在交付中往往面临两种选择：

公平分工——把任务合理分给团队成员，让新人有学习和成长的机会，但这样进度可能会被最慢的人拖住。

自己兜底——把难活、关键任务都揽下来，让新人只做简单部分。这样交付速度确实快，但相当于把团队“惯坏”了。

虽然第二种做法（自己兜底）对长期团队发展非常有害，但短期内确实能提升交付速度。因为资深工程师的产出效率就是更高。

我在职业生涯中无数次看到这种情况。但代价也很明显：经验和知识过度集中在 Tech Lead 身上，团队变得脆弱、支持难度加大，最后 Tech Lead 压力爆棚，不是倦怠就是离职，结果团队陷入危机。

短期收益，长期失败。

所以，真正的解法往往不是这两个极端，而是找到平衡点：既保证交付，又让团队成长。可以用一句话来总结：

通过合理的团队实践，让每位工程师都能在可控框架里写出能运行的代码，减少返工、提升协作，同时获得学习和成长的机会。

在我担任 Datasine 的 CTO 时，我们甚至把这种理念提炼成了一个团队口号：

学习。交付。享受过程。

一个好的 Tech Lead，会让工程师接触到足够有挑战的工作，同时通过合适的流程和实践来降低交付风险，让每个人都能在实战中成长。这其实就是优秀技术领导力的本质。

要做到这一点，有很多方法：既可以是严格的规则体系（比如极限编程 XP），也可以是更灵活的“最佳实践”，比如：

• 代码评审
  
• 小步快跑，逐步交付
  
• 模块化设计
  
• 测试驱动开发（TDD）
  
• 结对编程
  
• 高质量文档
  
• 持续集成
  

那么，对于今天的资深工程师来说，一个迫切的问题就是：如何把这些行之有效的实践方法带入 AI 编程的新时代？

LLM 就像“闪电般的初级工程师”

到了 2025 年，很多工程师首次面临每位技术主管常遇到的挑战：如何管理一位聪明但难以预测的初级工程师。如何让这样的“天才”融入团队合作、发挥价值，是技术领导者的一大挑战。不过，AI 编程助手和新人工程师不一样，它们的产出方式、成长模式有着本质差异。

对人类工程师来说，经验的积累往往带来多方面的提升：写出更健壮的代码，使用更合理的抽象，更少花时间修 bug，更快理解复杂架构，更好覆盖边界情况，更早发现重复模式……简而言之，既提高了质量，也提高了速度。一个优秀的工程师，往往会在这两个方向上同时进步。

早期的大模型（LLM）写代码很快，但因为 bug 多、容易“胡编”，要花很多时间去修复，整体交付反而慢。随着模型更智能、上下文管理和工具更完善，如今的 AI 编程助手能“一次写对”的几率提升。它们能非常快地产出一些中级工程师都要费力才能解决的代码，但距离资深工程师的水平还有差距。

所以，我们可以把现在的 AI 编程助手看作“超高速的初级工程师”，但有两个关键不同点：

速度远超新人——AI 生成代码不受思考或打字速度的限制。

不会真正学习——它们不会像人类一样逐渐成长，只能靠更好的提示工程或新模型来提升。

就像带新人一样，我们对待 AI 也有两种用法，取决于是看重短期还是长期：

AI 驱动的工程实践：遵循最佳实践，确保人类对代码的理解，放慢一点节奏，追求长期可持续的开发。

“Vibe coding”式快写：完全不管三七二十一，快速写出代码，牺牲理解来换速度，最后不可避免地陷入一团乱麻。

结果可想而知：Vibe coding 的结局就和团队里“自己兜底”的做法一样——短期有用，长期必然失败。

因此，Vibe coding 适合小项目或一次性原型。这类应用足够简单，可以不用太多思考就让 AI 独立完成。但一旦遇到更复杂的软件，AI 就无法单独应对了。做原型比以往任何时候都容易。

但如果我们想让 LLM 真正帮助交付复杂、安全、稳定的软件，而不是只带来有限的效率提升，就需要一本新的“工程手册”，专门指导如何让人类和 AI 团队协同合作。

如何避免 AI 编程陷阱

AI 编程工具的使用确实有利于程序员高产，但是它们对你的业务、代码库或产品规划一无所知。倘若没人对这些进行把关，AI 工具绝对会毫不犹豫地生成成千上万行代码，却不顾设计一致性或可维护性。

工程师的任务，就是当好这些“神速新人”的技术负责人：提供结构、标准和流程，把原始速度转化为可持续的交付能力。

我们需要一套全新的工程实践，来高效交付可运行的软件。而回顾过去的经验，能帮助我们找到答案。只要把 LLM 当作“闪电般的初级工程师”，我们就能借鉴软件开发生命周期里的最佳实践，构建真正可扩展的系统。

AI 可以融入开发生命周期的每一个阶段：

• 需求：帮助探索、分析和细化需求，覆盖边界情况，聚焦核心功能。
  
• 文档：提前生成并审查文档，提供可复用的约束和持久的记录。
  
• 模块化设计：搭建模块化架构，控制上下文范围，提升可理解性。
  
• 测试驱动开发（TDD）：先生成大量测试用例，引导实现并防止回归。
  
• 编码规范：通过上下文提示，让代码生成遵循团队风格和最佳实践。
  
• 监控与分析：AI 能比人更快分析日志、提取洞察。
  

只要我们明白，写代码只是软件交付的一部分，就能避免掉进“AI 编程陷阱”，真正放大我们的能力，打造高效、可扩展的软件。


来源：36kr