夜雨聆风
AI 杀死外包,复活瀑布流:软件交付的 30 年回环
从 SDD 到 Harness——当 AI 接管执行侧，什么才是真正稀缺的？
上个月团队周会，一个同事说了句：”代码确实写快了，但我比以前更累了。”说完没人接话——因为在场每个人都有同感。
我们团队推 AI Native 转型半年了。给每个人发了 token，培训了 SDD（Spec-Driven Development）开发范式，编码速度确实上来了。但需求吞吐没怎么涨，人反而普遍更疲惫。速度上去了，交付没跟上来，「快」本身变成了负担。
Klarna 砍掉 47% 人力，Salesforce 冻结招聘，54% 工程主管减招 Junior——这些数字指向同一件事：编码正在被廉价化。但拉远三十年看，这不过是瀑布流的高速回放：架构师出方案，别人执行。只是「别人」从外包变成了 AI。
后来才想通：仅有 SDD 是不够的。 编码速度不是瓶颈，两端才是——左端有没有喂够 context，右端有没有独立的 eval。context 不够，AI 高速产出垃圾；eval 没有，垃圾高速上线。SDD 解决了「串联」，但串联之外还需要一层质量外挂——这就是 Harness。
AI 接管编码之后，人的价值退到了哪？
1. 四个工种变一根光谱：工种边界是怎么消失的
软件交付从想法到上线本来是同一条链——意图 → 设计 → 编码 → 验证 → 发布。链太长、太专，一个人扛不下来，只能按专长切成工种：架构师、开发、测试、运维，各管一段。
关键洞察：工种边界之所以存在，仅仅是因为每段都得换一个人来做。 「人的分工」才是把这条链切成四段的原因。
AI 让这个前提不成立了。编码及其右侧都能被 AI 接管，工种边界自然融化。离散的盒子，塌缩成一根「人定义 / AI 执行」的连续光谱——但这根光谱两端各有一个缺口。
但要看清「人到底退到了哪」，得把镜头拉远——放进三十年的历史里看，你会发现一个漂亮的回环。
三十年一圈：架构设计又值钱了
三十年前的瀑布 / 外包时代，架构设计是巅峰价值。架构师画 UML / ER、定方案，编码被当成可拆分工序交给外包团队。设计与编码——分离。
然后敏捷来了。ThoughtWorks 提出演进式架构（Evolutionary Architecture）与涌现式设计（Emergent Design）——反对「大而全的前期设计」，把架构决策推迟到「最后责任时刻」，让架构在迭代中涌现。架构不再是架构师前置的蓝图，而是全栈开发者的日常。设计与编码——合一。
现在 AI 来了，编码被交给 Agent，人的核心价值又回归到架构设计——只是这次不再是画静态蓝图，而是写 spec、定意图、做验收。设计与执行——再次分离。本质上，spec 就是新时代的 UML：以前你画类图和时序图交给外包团队照着写；现在你写 spec 交给 AI 照着生成。载体从图纸变成了结构化文本，读者从人变成了模型——但「架构师出方案、别人执行」的分工结构，一模一样。
AI 就是新一代离岸外包——只是反馈回路从月级压到秒级
把三个时代并排看，结论其实很直白：AI coding 在分工模型上复刻了离岸外包——设计在此岸，执行在彼岸。区别不是结构，而是介质。
数据已经摆在那里：
-
• Klarna（2022→2025）：人力从 5527 砍到 2907（-47%），AI 替代了 700 名外包客服。后来因为质量塌方又回聘了一部分——替代是真的，验收跟不上也是真的。 -
• Salesforce：Marc Benioff 公开暂停软件工程师招聘，直接说是 AI coding 带来的生产力跃升。 -
• 行业面（2026）：54% 工程主管计划减少 Junior 招聘；全球软件外包市场仍涨到 $618B，但买的不再是人头，是 outcome。
如果你在大厂做技术管理，这些数字应该已经在各种 all-hands 上听烂了。但数字背后真正在变的是什么？
外包被 AI 替代，但被替代的不是「外包」这个概念，而是「用人力套利来廉价化执行」这个模式。AI 做的是同一件事——只是把「人力套利」换成了「智力套利」：边际推理成本趋零，编码的稀缺性溢价被打掉。
三十年前架构师值钱，是因为编码贵。现在架构师值钱，是因为编码不值钱了。 价值的锚点没变，变的是哪一侧被廉价化了。
三次套利，三次价值左移：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
每一次执行侧被廉价化，价值就往意图侧退一格。 这一次退得最彻底——退到了「你到底想要什么」和「你怎么知道拿到了」。
如果你现在用 AI 写代码，不妨问自己两个问题：你的 spec 写清楚了吗？你怎么验证 AI 给的是对的？ 答不上来的那个，就是你当前最大的风险敞口。
但 AI 和离岸外包有一个根本差异：反馈回路从月级压缩到了秒级。 这不只是快了——以前 spec 写偏了，要等一个迭代才发现；现在 spec 写偏了，五分钟就能生成一堆精致的错误代码。垃圾 spec 也会被高速放大。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
最后一行是关键——T1 的瓶颈是交接，T3 的瓶颈是 context。这正是后面 Harness Knowledge 层要解决的问题。
T1 把编码交给外部人力，人守架构设计；T3 把编码交给 AI，人再次守架构设计。三十年绕一圈，核心价值兜回原点——但这次的「架构设计」和三十年前不是一回事：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
同一个位置，更高的维度。T1 的架构师只需要让人读懂蓝图；T3 的架构师需要让 AI 可执行、让 eval 可验证——spec 既是设计文档，又是驱动程序，又是验收标准。 这三件事压在一个文件上，就是 SDD 的起点。
人退守左端后，核心价值就两件事：把意图定义清楚、把结果验收住。
2. SDD：一份 spec 串起从意图到发布
人退到意图侧，第一件事是把模糊的想法变成 AI 能执行、人能复核的东西——这就是 spec（规格契约）。它同时扛三件事：
-
• 对意图：精确化为可执行契约，消除歧义； -
• 对 AI：直接驱动生成，不只是给人看的文档； -
• 对人：可审阅、可签字，人始终握着决定权。
SDD（Spec-Driven Development） 就是把 spec 摆到驱动核心：以它为中枢契约，把「意图 → 实现 → 发布」串成一条可对齐、可串联的流水线。
SDD 解决的是「串联」——让整根光谱被一份契约贯穿。 但「串得起来」不等于「串得好」——这引出它的边界。
3. spec 管得了串联，管不住质量
说到底，spec 只是一段静态文本——不会自己变准、也不会自己验对：
-
• 写好它，需要外部输入； -
• 验对它，需要独立裁判。
而 spec 自身两样都不提供。于是光谱两端各裂开一个缺口：
-
• 左端缺 context：模型不知道自己不知道——领域规则、历史决策、踩过的坑都在代码之外。我们团队早期的典型翻车就是这个：AI 写的代码语法没问题，但违反了一条三年前定下的业务规则，review 时没人看出来。 -
• 右端缺 eval：让模型自产自验，等于考生改自己的卷子。没有独立闸门，盲区系统性地看不见。
SDD 管得了「串联」，管不住两端的「质量」。 这正是 Harness 要补的两个位。
4. 反直觉：最复杂的系统，反而被 AI 放大最猛
理论到这里够了，拿个真实场景验证一下。
反直觉：强规则、强状态、强一致性的金融级系统，本该是 AI 最难啃的场景。但我观察到，恰恰是这类系统有机会被 AI 极致放大——为什么？
因为它恰好两端齐备：
-
• 右端 eval 完善：多年沉淀的测试工程 + 合规闸门，验证链路可靠——AI 写错了立刻被挡回。 -
• 左端 context 已结构化：大量 UML / ER 等设计资产，把隐性知识显性化——AI 知道规则到底长什么样。
我们团队自己的体感也验证了这一点：那些历史文档齐全、测试覆盖高的老模块，接入 AI 编码之后效率提升最明显；反而是”大家都熟，文档懒得写”的模块，AI 写出来的东西踩坑最多——因为知识全在人脑子里，模型根本拿不到。
反过来说：决定 AI 放大倍率的，不是场景简单与否，而是两端是否齐备。
但这类场景的特殊性在于：两端能力往往是多年工程实践「手工攒出来的」。手工沉淀很强，却不可复制、不可规模化。
我一直在想的问题是：能不能把「攒齐两端」变成一套谁都能用的工程能力？这就是 Harness 要做的事。
编码快了 10 倍，还缺什么？
1. Harness：SDD 管串联，它管质量
SDD 串好了光谱，也暴露了两端缺口。Harness 不是取代 SDD，而是在光谱外侧加一层质量包络：左端补 context，右端加 eval，把「能串起来」升级成「能稳定交付」。
SDD 让光谱可串联，Harness 让光谱可复制地交付。
2. 左端补知识，右端守验收
Harness 的两个抓手，与前面说的两个缺口一一对应：
-
• 左端补 context（Knowledge 层）：检索注入项目知识、把隐性约束结构化进 spec 模板——堵住「不知道自己不知道」。 -
• 右端加 eval（Delivery 层）：一条独立于生成模型的闸门管道，失败自动 escalation——堵住「考生改自己卷子」。
3. 流程和质量拆开，各自演进
Harness 还做了一件关键的事——把「怎么走流程」和「守住什么质量」拆开：
-
• Superpowers 管串联：流程编排（brainstorm → plan → TDD → verify → review）。 -
• Harness 管约束：两端的质量包络（context 充分性 + eval 独立性）。
这么拆的好处是：流程引擎、项目知识、验证闸门可以独立演进。换引擎时调整规则就行，不必推翻项目上下文和交付门禁。
4. Harness 长什么样？
还是同一根光谱：Knowledge 挂在左缺口、Delivery 挂在右缺口、Orchestrator 在上管串联——三层各就各位。
SDD 像高速公路，Harness 是护栏。没有护栏的高速公路，速度越快越危险。
落到项目里，核心就是这样一个目录：
asd/├── manifest.yaml # 唯一配置入口，换项目只改这个文件├── kernel/ # Harness 引擎（整体升级，项目不改）│ ├── orchestrator/ # 控制面：Agent 行为规则 + Spec 模板│ ├── knowledge/ # Intent → Code：按关键词检索注入上下文│ └── delivery/ # Code → Production：闸门管道 + 自动 escalation├── knowledge/ # 项目知识库（版本化，持久资产）├── specs/ # Spec 契约（审批后冻结）└── skills/ # Agent 能力声明三层各管什么，一句话：
|
|
|
|---|---|
| Orchestrator |
|
| Knowledge |
|
| Delivery |
|
你把领域知识往 knowledge/ 里填，把验收标准往 delivery/ 里写，manifest.yaml 一声明——任何 AI 编码工具都能接上这套外挂。具体怎么填、怎么写、怎么接，是 Harness 实践篇要讲的事。
三句话，带走这篇文章
-
1. 三十年前架构师值钱，是因为编码贵。现在架构师值钱，是因为编码不值钱了。 每一轮执行侧被廉价化，价值就往意图侧退一格——这一次退到了「你到底想要什么」和「你怎么知道拿到了」。 -
2. Spec 就是新时代的 UML。 以前架构师画 UML / ER / 时序图，交给外包实现；现在你写 spec，交给 AI 执行——载体变了，分工模式没变。只是反馈回路从月级压到了秒级，垃圾 spec 也会被高速放大。 -
3. SDD 是高速公路，Harness 是护栏。 没有护栏的高速公路，速度越快越危险。
📌 Spec-Driven AI 编程系列
AI 时代只有两种技术团队：一种在拼命提速，一种在提速的同时修护栏。你的团队是哪种？ 欢迎留言聊聊。
我是 dolphin，大厂技术 Leader，正在带团队从传统开发转向 AI Native。这个系列记录的都是真实踩坑——AI 把编码的苦力活干了，把判断的脑力活全推给了你，所以你更累了。如果你也是技术管理者、架构师、或正在落地 AI 编码的工程师——关注我，少走弯路。