“先写代码，问题以后再说！”AI初创CTO戳破氛围编程陷阱：快速出原型还可以，复杂度一上来就失灵！ 原创

编辑  | 云昭

出品 | 51CTO技术栈（微信号：blog51cto）

“氛围编码剥夺了你对其生成的代码的深入理解！”

近期，关于讨论氛围编程的讨论多得一塌糊涂。随着各种编程代理产品的使用增多，越来越多有关“AI编码导致人类程序员思维惰性”的讨论引起了业内关注。

近期，英国一位初创企业的CTO和联合创始人，认真对比了传统编程和AI辅助编程的流程变化，同时警告，AI编码存在一个魔力陷阱：

AI 编码代理的确效率惊人，但他们对你的业务、代码库或路线图一无所知。

这位大牛认为，归根结底，还是人们如何看待“写代码” 。他认为，软件开发，其实大部分时间是在思考，然后小部分时间是coding。而现在的AI辅助编程工具则是反过来的，“先写代码，问题以后再说！”这就导致了一种怪象：

大模型飞快地完成了有趣的coding环节，而程序员则开始处理AI留给的、无穷无尽的“烂摊子”。

这一点也引起了圈内人士的热烈讨论。一位网友表示非常认同——

在大多数领域里，代码并不是最终产品，数据才是。代码只是记录、修改和删除数据的方式。但最终有意义、有价值的是数据。

这就是为什么有句话说：“别告诉我代码写了什么——把数据给我看，我就能告诉你代码在做什么。”

也有网友表示反对：

大模型生成的代码跟上一任已离职的代码作者所写的混乱代码有什么区别呢？

很快就有人回应了：区别大了！区别在于心智模型的建立！

区别在于摆脱困境的希望。如果你接手了一个混乱不连贯的代码库，你会意识到这是一个问题，并努力修复它。你可以通过先阅读代码，然后可能重写其中的一部分来建立对代码的理解。随着时间的推移，这会提高你对代码的推理能力。

如果你不断地把自己置于那种境地，把代码推理交给代码代理，那么你就无法建立起心智模型。你总是回到必须“拥有”别人代码的第一天。

这一点，小编非常认同。

话说回来，那么我们如何避免AI编程陷阱呢？如何让AI在处理高复杂度的软件交付过程中，能够实现高效、高质的人机合作？

这位CTO给出了自己的一个方案：在开发生命周期的每个环节引入 AI，并建立一套团队实践，让AI这位初级工程师在最小化返工的框架下高效协作，同时获得成长与学习机会。

逻辑非常顺畅，分析得非常到位，值得大家收藏细看。

软件开发的本质，不是写代码

如果你曾经看过有人在“写代码”，你可能会发现他们花在发呆上的时间远比敲键盘多。别误会，他们（大概率）不是在摸鱼。

软件开发本质上是一种解决问题的实践，就像解复杂的填字游戏一样，大部分工作其实都发生在脑子里。

在软件开发生命周期中，编码就像是把填字游戏的答案填到格子里——它只占据了很小一部分精力，真正的工作往往伴随着编码展开：开发者要熟悉领域知识、细化需求、构建合适的抽象、考虑副作用、逐步测试功能，并最终修复那些在严格流程中漏网的 bug。

流程大概是这样的：

图片

但在 AI 驱动的编码里，情况完全不一样。

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

像 Claude Code 这样的 AI 编码代理，可以在孤立场景中惊人地快地写出代码。但绝大多数软件都存在于复杂系统中，而大模型还无法一次性记住整个应用的上下文，所以人工的审查、测试和集成仍然不可或缺。

可问题是，当代码是 AI 写的，而人类并没有在写之前思考过，那么后续理解就会变得异常困难。结果就是，在复杂软件开发中，开发者会花大量时间事后搞清楚 AI 究竟写了些什么。

图片

这就是 AI 写代码的宣传话术（号称“10 倍提速”）与真实交付可用软件时的效率提升（通常只有 10% 左右）的差别所在。

图片

更令人沮丧的是，开发者会发现自己花在“修 AI 烂摊子”上的时间越来越多。大模型飞快搞定了有趣、轻松的部分，我们却被留给了那些吃力不讨好的任务：测试以确保旧功能没被破坏、清理重复代码、写文档、处理部署和基础设施等等。真正能沉浸在写代码本身的时间反而越来越少。

不过，别急——这并不是一个全新的问题。事实上，它不过是一个老掉牙难题的极端版本：

技术负责人的两难

当工程师的职业生涯发展到一定阶段，就会进入 tech lead（技术负责人）的角色。他们可能要管理团队，也可能只是作为首席工程师推动技术交付。但无论哪种情况，他们既要为团队交付负责，又往往是团队里经验最丰富的人。

软件交付是团队合作，但经验差异会极大拉开成员的产出效率。因此，tech lead 常常在两种交付方式中挣扎：

• 公平分工：把任务平均分配给所有人，让新人有学习和成长机会，但交付速度会受限于最慢的成员。
• 包办大部分核心任务：把简单或无关痛痒的工作丢给新人，自己扛起最难的部分，以此保证交付速度。

可惜的是，虽然“包办”模式对团队长期健康运作极其有害，却在短期内确实能显著提速。于是，经验被集中在 tech lead 一人身上，结果就是：团队变脆弱、支持成本增加、负责人压力倍增，最终的结局可想而知：倦怠、离职、团队危机。

图片

解决办法通常在第三种路径里：既避免极端分工，又兼顾交付与成长。换句话说：

建立一套团队实践，让工程师在最小化返工的框架下高效协作，同时获得成长与学习机会。

图片

在我担任 Datasine CTO 时，我们团队的座右铭是：

学习、交付、享受过程。

优秀的 tech lead 会让工程师不断触碰自己能力的边界，同时用合理的流程和实践来降低风险、确保交付。这正是优秀技术领导力的本质。

常见的方法包括：

代码评审、增量交付、模块化设计、测试驱动开发、结对编程、高质量文档、持续集成

问题是：在 AI 驱动的编码世界里，如何把这些实践延续下去？

闪电般的“初级工程师”

到了 2025 年，许多工程师第一次体会到 tech lead 的感受：你要带的是一个聪明绝顶但不可预测的“新人”。不同的是，AI 的生产力和成长方式与人类完全不同。

人类工程师随着经验积累，会在两个维度同时提升：

• 质量：能写出更复杂、更高性能、更易维护的代码
• 速度：能更快写出 bug 更少的可用代码

图片

早期的大模型写代码很快，但 bug 一堆，修复拖慢了进度。现在的 AI 编码代理通过更强的模型和上下文技巧，已经能“一次写对”不少代码，甚至能媲美中级工程师。但他们依旧无法达到高级工程师的水平。

所以我们可以把 AI 编码代理类比为初级工程师，但有两点重大差异：

1. 他们写代码的速度远超人类新人；
2. 他们没有真正的学习能力，只能靠更好的上下文工程或更强的新模型升级。

于是，AI 的使用方式也分两种：

• AI 驱动工程：重视实践与理解，慢速推进，确保可持续开发；
• “Vibe Coding”：靠直觉乱冲，追求短期速度，牺牲理解，最终撞上混乱不堪的墙。

图片

短期来看，“Vibe Coding”很适合小项目或一次性原型。它能够交付足够简单的应用程序，而无需任何人工思考。通过限制项目的复杂性并充分利用工具的功能，我们可以立即交付端到端的可运行软件。

但一旦复杂度上来，AI 就会失灵。

如果我们想要有效地利用 LLM 来加速交付真实、复杂、安全且可运行的软件，并实现超越边际的效率提升，我们就需要编写一套全新的工程实践手册，以最大限度地促进包括人类和 LLM 在内的工程团队之间的协作。

图片

如何避免 AI 编码陷阱

AI 编码代理的确效率惊人，但他们对你的业务、代码库或路线图一无所知。如果没人约束，他们会毫无顾忌地产出成千上万行缺乏设计感、风格一致性和可维护性的代码。

这时候，工程师的工作，就像是这些“天才新兵”的技术负责人：提供结构、标准和流程，把原始的速度转化为可持续的交付能力。

所以，我们需要一本全新的行动手册，来指导如何高效交付可用软件。而要做到这一点，回顾过去的经验同样有价值。

把大模型当作“闪电般高效的初级工程师”，我们就能借鉴软件开发生命周期的最佳实践，来构建可扩展的系统。

通过结构、标准和流程，把原始的速度优势转化为可持续的交付。

图片

这意味着要在开发生命周期的每个环节引入 AI：

• 需求：探索、分析和细化需求，覆盖边界情况。
• 文档：提前生成和审查文档，作为复用和证据。
• 模块化设计：搭建可扩展架构，缩小上下文范围。
• 测试驱动开发：在实现前生成测试用例，防止回归。
• 编码规范：通过上下文工程让代码符合团队标准。
• 监控与分析：利用 AI 快速分析日志并提炼洞察。

只有认识到“写代码 ≠ 软件交付”，我们才能避免 AI 编码陷阱，让人机协作真正放大交付能力。

参考链接：https://news.ycombinator.com/item?id=45405177

本文转载自​​51CTO技术栈​​，作者：云昭