代码越快,交付越慢:把AI编程还给软件工程

悖论：代码越快，交付越慢

AI 让代码生成得越来越快，团队的交付效率未见提高，甚至还会下降。这是这一轮 AI 狂热里最反直觉的一个悖论。

如果站在软件开发生命周期的角度看，这个悖论的形成就很好理解。

代码生成快了，但设计没快、测试没快、运维没快、售后支持没快。AI编程 解决的是”代码环节”的降本增效，但没解决全软件生命周期（SDLC）的顺畅流转，由vibe coding或者AI自动开发而引入的缺陷，最终都可能带来需要持续付出的新的成本。

由编码阶段引入的技术债，在SDLC循环中积累的总拥有成本（TCO:  Total Cost of Ownership)反而是不断累积增加的。

设计上的偷懒，被代码生成的速度掩盖过去；质量上的隐患，被挤压到测试和运维环节延宕爆发。软件工程过程中的问题没有消失，只是从上游被推到了下游——而因缺陷延迟爆发而给下游带来的修复和维护成本，可能是上游注入缺陷时的几何倍数。

更有意思的是，当下AI万能论的基础，全部建立在一个虚幻叙事之上：AI 可以快速理解系统工程，并快速修复生产现场的 bug。

我必须提醒一句——你的 AI God，并不会从虚空中天然得到解决这些问题的上下文。

软件工程的上下文，要么来自设计文档，要么来自测试用例，要么来自研发过程中每一轮迭代的决策论证记录。如果你的AI原生工程从一开始就没去记录这些上下文，下一轮迭代终的 AI 拿到的就是一坨失去现场上下文的代码屎山。

等你让 AI 去阅读、去解释、去重构，它连这一坨当初为什么写成这样都不知道，凭什么去fix？凭幻觉吗？

最终你会发现，AI编程通常只是带来局部环节的降本增效，未见得会降低SDLC的TCO。

随着代码工程终不可解释的技术债持续累积，总有一天，你会发现自己那看起来壮美的几十万行代码工程，已经积重难返。

当公司的核心业务已经跑在这座失控的工程之上，你能轻易说——”这个项目算是废了，咱们推倒重写吧~”

AI原生工程的管理判据

古法编程时代，工程写得再烂，owner 至少知道哪里烂、坑在哪儿，心里有张粗略的地图。AI 编程时代，AI 是执行利器，也隔绝了人对代码的直接体验。

vibe coding 一句话生成一个工程，yolo mode 一把梭，你对手下 AI 写出来的代码毫无印象——它对你来说就是个黑盒，黑盒怎么管？

所谓屎山代码，本质上就是无法理解、无法管理的代码工程。

判断你的AI原生工程是否”可管理”，依据很简单就三条：

• 你不能理解 AI coding 的内容，就是不可管理的。

• 你不能验证 AI coding 的内容，就是不可管理的。

• 你不能管控 AI coding 的方向，就是不可管理的。

不可管理的代码，是技术债，不是技术资产。技术资产能给你持续产生现金流，技术债则会持续从团队身上抽利息，随着压力积累迟早会爆发。

屎山一旦形成，常见的屎山治理策略是“封装”——对既有的屎山逻辑进行隔离封装，仅暴露接口，你不需要知道屎山内部的原理，只需要知道如何使用屎山即可。

但是这种治理的本质是锯箭法：外面的箭杆锯掉了，里面的箭头还在肉里。

锯箭法治理屎山代码治标不治本，屎山的复杂性会让越来越多相互重复、彼此矛盾的设计意图在代码工程里堆叠，而你不见得能真正理解”屎山分层隔离”的正确边界，用上AI也很难正确处置。

解决之道：慢即是快，少即是多

于是我有问若干——

为什么要等屎山形成再补锅？

为什么要让 AI 像刷老虎机一样反复重做？

为什么不能从一开始就每一步都做对？哪怕慢一点。

对一个需要持续迭代持续的维护的工程而言，代码并非越多越好，改动并非越快越好。

如无必要，勿增实体。

生成可控、可靠、可持续迭代的代码才是一个严肃项目需要的能力。

慢即是快，少即是多。

代码实现阶段，人 AI 共建的过程不可省略。AI 犯大错，人一般一眼能看出来——意图开始漂移、决策开始分叉，第一时间纠偏，后面就不会越走越远。等到积重难返再回头，综合治理成本是最高的；从一开始就做对，成本是最低的。

这里有一个反直觉的点：在 AI 编程时代，你的设计文档、代码、测试用例，第一读者已经不是人类，而是 AI。

古法时代大家不愿意写 doc，也懒得看 doc；AI 时代，写和读都交给 AI，doc 这件事反而轻减了。一个维护良好的 doc-tree，能让项目三个月之后哪怕 owner 忘了细节，AI 重新读一遍就能兴致勃勃地接手维护——这本身就是项目”不死”的关键。

设计文档和测试用例在 SDLC 里扮演的，是”上下文记录器”的角色。它们不是为了走流程，而是为了让每一轮迭代的”设计决策”和”验证更新”都被沉淀下来，更新系统级的上下文。

agent team：可落地的AI-native工程范式

我在这里提供一个参考实现——agent team。

agent team 是基于角色（role based）的 AI-native 工程范式，本质上复刻了一整个软件研发团队的人员配置、工作规范和工作流程。

• Arch 管理概要设计；

• PM 识别意图、拆 Epic/Story、定义验收标准；

• Dev/UED 按 Story 实现；

• QA 按 AC 分层验证 UT/API/SIT/E2E/UAT；

• Spec XChecker 检查 Design ↔ Scrum ↔ Code ↔ Tests 是否一致；

• DevOps 管 CI/CD、部署、环境验证。

PM 不越俎代庖去写代码、不代替 QA 测试，只做协调者。

agent team 协作链路图          

你能照搬人类社会里的团队协作和管理经验去驱动它——见过一个软件团队怎么工作，就能驱动 agent team 做研发。

没经验也不慌，”万事不决问 /pm”，多跟项目经理沟通就行。

效果是直接的：发布上线之后碰到疑难杂症，在掌握项目的上下文的基础上，agent team排查问题会非常精准，因为整个项目生命周期的上下文，在 agent team 工作的同时就被记录下来了。

举个真实的例子。我的 /sentinel 在巡检中发现聚合查询的性能越来越慢——最近三天从 800ms 增到 1400ms。凭直觉我猜是记录增长叠加索引设计不合理，但是我相信agent team可以基于完整的工程文档可以自行找到答案，于是我只是简单要求/pm 组织 agent team 排查。

很快，它给出了一份完整的 RCA 报告。

RCA 报告输出          

基于完整系统级上下文的RCA报告条理就很清晰：收益是释放约 200MB 磁盘空间、减少 INSERT/UPDATE 开销、简化索引维护；风险是需要验证其他查询是否依赖单字段索引、建议先建组合索引再删除；

同时还附上 RCA 报告路径、测试代码路径、表结构 DDL、索引 DDL 路径；下一步是等 Phase 1 执行决策。

在这种可以托付agent team自主完成任务的工作方式下，人类的心智负担很低。让 AI 做后续的 RCA、fix solution，我就很信任它的输出——因为它需要的上下文，随着工程的迭代而不断积累，AI需要了解的项目信息在代码库里全都有。

agent team的规模杠杆：One Person, One Team

AI-native 工程范式，主要目标还包括解放人类的”身心”。

Vibe Coding 看着炫，本质上是在用有限的 token budget 做系统级的盲目试错。如果引入AI编程不能解放人的双手、减轻人的心智负担，那这种 AI-native 转型就是失败的。

如果你的研发方式是”相信AI比人更懂业务和工程，人只需提出需求，剩下的就让AI agent 经由/loop , /goal 自由开发即可”这种模式，那么”通过20轮迭代完成一个功能交付”这种场景就是你研发的常态，而且很难维护连续可靠的项目级上下文。

这种情况下，你的 token budget真的扛得住吗？最初引入AI编程的意义又在哪里呢？

但 Vibe Coding 更大的损耗还不止于此。前面这一长串批判都还只停在”单项目内盲走”——你在 token 上赌博、在屎山上盖楼。

真正的牢笼是：Vibe Coding不是让你一个项目失败，是把你整个人锁死在”一个项目”里。

古法编程时代，一个 owner 心智带宽有限，最多同时盯一两个项目——人脑就那么多线程。

vibe coding 把这个限制又往内收紧了一圈：你不再是指挥者，你是亲手盯着 AI 一行行写的人，每一漂移要纠偏。一个项目就把你的心智带宽吃满，第二个项目根本进不来。

agent team 把”上下文记录”和”角色协作”工程化之后，人类作为虚拟团队的 team lead， 对项目迭代的上下文掌控从”全背会”切换到”监督好”。

项目上下文被 agent team 自己沉淀成文档、测试、决策记录，你随时可以把这个项目放下，切到下一个，再切回来，AI 重新读一遍就能接上。释放出来的心智带宽，就去了第二个、第三个、第 N 个项目。

基于agent team的多项目同步管理

这才是”解放身心”的真正落点：不是让你写一个项目更轻松，是让你一个人活成一支队伍。

vibe coding 让你写一个项目却要承担不断累积的心智负担，agent team 让你写十个项目心不累——规模杠杆根本不在一个量级。

代码工程可以再多一点，人类的对工程的理解不能少一点。

慢即是快，少即是多。

参考实现：

• github.com/linview/agent-team-archetype