SDD + Harness：把 Vibe Coding 从"氛围编码"升级为可控的 AI 原生软件工程

一、开篇：AI 写得快，为什么交付不动？

过去两年，几乎每个工程团队都经历过类似的场景：把一段需求描述丢给 AI 编码智能体，几分钟后得到一个"看起来能跑"的实现；接着是漫长的对齐、返工、补测试、改架构，最终上线周期并没有因为编码提速而缩短多少。

先看一个典型场景合成案例（为说明问题而构造，不对应任何真实企业事故）：

如果只看 Day 1，这是一次漂亮的提效；拉通七天看，编码环节的收益被后续环节吃掉了大半。问题不在模型不够聪明，而在于交付链条上缺少可执行的契约与门禁：需求意图只存在于对话上下文里，架构约束没有被声明，验收标准没有被前置。

这也解释了行业观察中反复出现的一个判断：编码智能体的竞争重心正在从"会写代码"挪到"会编排、会验收"，评审与验证反而成为新的瓶颈 [5]。

本文的目标很明确：不讨论"AI 靠不靠谱"，而是给出一套可复制的工程方案——用 SDD（Spec-Driven Development，规范驱动开发）立顶层契约，用 Harness 工程约束体系设控制闸门，再把"禁止事项"写成机器可检查的红线。文中所有代码与配置均为示意实现，需按团队工具链改造；涉及 Star、项目数量、客户数量的数字一律标注"来源自述"，并注明"截至来源发布时"。

二、Vibe Coding 的四个真实缺陷（而不是"AI 不行"）

Vibe Coding（氛围编码）已经被不少团队当作标准化开发方式，广泛用于原型验证、MVP 落地与中小项目迭代 [4]。它在探索性场景里确实高效，但一旦进入需要长期演进、多人协作、合规审计的生产系统，就会暴露出结构性缺陷。

2.1 依赖对话上下文：契约存在聊天记录里

对话上下文是易失的隐式契约。它没有版本号，没有评审记录，无法被 diff，也无法在三个月后被复现。同一段需求换一个会话、换一个模型，产出的实现路径可能完全不同——因为"上下文里发生过什么"本身就不可追溯。

更麻烦的是上下文窗口有容量上限：长对话中早期的关键约束会被截断、被稀释，AI 只能基于"最近在聊什么"做局部判断。这意味着需求最重要的那句话，可能在第十轮对话时已经不在模型的有效注意力范围内了。

2.2 需求理解漂移：从"我说的"到"它做的"的衰减

漂移不是一次性发生的，而是沿着"需求 → 设计 → 代码 → 测试"逐层放大：

• 需求层：口语表达天然含糊，"支持退款"没有说明按整单还是按商品行；
• 设计层：AI 需要补全大量未言明的假设，补全结果未必与业务一致；
• 代码层：局部优化会让实现偏离原始意图，例如把异步退款写成同步阻塞；
• 测试层：如果测试也由 AI 按同样模糊的理解生成，错误会被"自洽地验证通过"。

多轮对话常常不收敛反而放大漂移，因为每一轮都在前一轮的补全结果上继续补全，误差层层累积。根治办法不是让 AI"更听话"，而是把意图写成可判定的陈述，并在每一层留下人工确认点。

2.3 架构随意变更：AI 的"局部最优"陷阱

AI 生成代码时的优化目标是单次生成的质量与顺畅度，而不是系统长期的一致性与可维护性。因此它倾向于为一个函数的方便去替换 ORM、引入重型第三方库、改变缓存策略，因为这些改动能让当前任务"更好写"。

这类行为在单次会话里几乎不可见，却会在半年后累积成架构熵增：依赖清单膨胀、存储层出现两套访问方式、新人无法判断哪个才是"正统实现"。架构决策属于系统级不变量，必须在任务开始前被锁定，而不是在实现过程中被顺手优化掉。

2.4 缺乏统一验收基准："看起来能跑"不是验收

没有验收契约时，人和 AI 只能用"跑起来了"作为完成标准。于是验收退化为一次演示，而非性能阈值、边界条件、回滚预案的核对。行业侧的观察也印证了这一点：当 IDE 逐渐变成多智能体调度台，评审与验证成为新的瓶颈 [5]；业界在评测真实业务场景的 Agent 时，也越来越依赖带评估器（evaluator）的基准框架，而不是靠人工看结果 [9]。

2.5 四个缺陷的根因与对策映射

对照一下"对话式需求"与"落盘契约"的差别：

# 对话式（隐式契约，易漂移） "帮我加一个退款功能，和现有订单流程对齐。" # 落盘契约片段（示意结构，非某框架标准 schema） 需求编号: REQ-014 订单退款申请 目标: 支持按商品行发起部分退款 Given 订单状态为"已支付"且商品行未退款 When 用户提交指定商品行的退款申请 Then 生成退款单，订单总退款金额不得超过实付金额 非目标: 不支持整单自动退款；不处理跨境结算；不在本期做退款审批流 验收: 见 acceptance.md#REQ-014

差别不在于文字多少，而在于后者可判定、可版本化、可被测试引用。

三、行业信号：编码提效 ≠ 交付提效

3.1 AIIA"银弹"实践评选给出的定性

中国人工智能产业发展联盟（AIIA）软件智能化委员会发布了 2026 AI+软件"银弹"实践评选结果，共评出 16 项标杆实践、14 项优秀实践，征集工作于 2026 年 5 月启动（数量信息为来源自述，截至来源发布时）[2]。

在相关报道中，被反复强调的一个核心论断是：“AI Coding 提升了编码效率，却没有解决交付问题”[2]。需要注意的是，这句表述来自媒体报道中的行业评述语境，本文引用它作为现象归纳，而不是作为某家机构的正式标准结论。它与本文开篇的合成案例指向同一个事实：编码只是交付链条的一个环节，环节提速不等于链条提速。

3.2 网易智企 SDD 实践：规范驱动进入标杆案例

同一批"银弹"标杆实践中，网易智企的 SDD 实践以"重塑 AI 软件工程"为主题入选 [2]。从公开报道能确认的层面是：规范驱动开发（SDD）已经从个人开发者的方法论，进入国内企业级实践的评选视野。

由于现有资料未给出可核验的量化指标（如缺陷率、交付周期变化），本文不做任何指标推断。可以确认的是趋势本身：当编码效率不再是瓶颈，工程界开始把注意力投向"如何让需求、架构、验收三者形成可信契约"。开源社区的侧信号也支持这一判断，例如公开的提示词合集中已经出现基于"spec-driven development 最佳实践"的条目 [7]，技能包式的 AI 能力分发也在向索引化、可安装化演进 [8]。

3.3 中电金信 AI 原生软件工厂与央企联合筑基工程

中电金信在《企业级智能化软件工厂方案及最佳实践》分享中梳理了智能软件工程的演进脉络：从"平台化与自动化"、“AI 辅助”，迈入"AI 自主协同"阶段，SDD（规格驱动开发）、Harness（驾驭工程）与智能体端到端协作成为行业能力建设的焦点 [3]。

更具信号意义的是组织层动作：2026 年 7 月，国务院国资委在世界人工智能大会期间启动国资央企智能软件工厂联合筑基工程，聚合首批 13 家央企研发力量（数量信息为来源自述，截至来源发布时），中电金信作为核心技术支撑单位提供智能软件研发工具链与工程化实施支撑 [3]。

这说明 SDD + Harness 已经不只是个人技巧，而是被当作组织级软件生产基础设施来建设。对一线团队的启示是：与其等组织层规范下发，不如先把本团队的契约与门禁跑通，未来与更上层的工程体系对接时才有落点。

四、SDD：给 AI 立一份"顶层契约"

SDD 的核心思想是：先写规范，再让 AI 实现；规范是交付物，代码是规范的执行结果。需要说明的是，SDD 目前并没有统一的权威标准目录约定，下面给出的结构是示意组织方式，可按团队习惯调整。

4.1 规范的三层结构

specs/ └── 014-order-refund/ ├── requirements.md # 需求契约：做什么、不做什么、谁签字 ├── architecture.md # 架构契约：不变量与可变量边界 └── acceptance.md # 验收契约：怎么算过、由谁验证

三层各有主要读者：

4.2 需求契约：把"对话里的意图"变成可判定的陈述

改写的关键有三点：使用 Given/When/Then 式验收句式、显式列出非目标（Non-goals）、把模糊量词换成可测量条件。

# 改写前 "退款要快，体验要好，别影响正常订单。" # 改写后（示意，通用句式，不绑定测试框架） REQ-014 订单退款申请 - Given 用户持有状态为"已支付"的订单 When 选择未退款的商品行提交退款申请 Then 3 秒内返回退款单号，且不阻塞其他订单操作 - 非目标：本期不实现退款审批流、不支持跨境结算 - 性能约束：退款接口 P95 响应时间 < 800ms（测试环境） - 异常约束：金额校验失败必须返回明确错误码，不得静默部分退款

非目标清单的价值常被低估：它明确了 AI 的"自由发挥禁区"，避免模型出于讨好心理把范围悄悄扩大。

4.3 架构契约：锁定不变量，释放可变量

架构契约要回答的是：哪些决策必须前置固化，哪些留给 AI 自由发挥。可以用三层同心圆来组织：

• 锁定区（禁止变更）：技术栈、存储组件、通信协议、鉴权方式、数据表结构的破坏性变更；
• 沙盒区（可改但需校验）：模块间接口签名、错误码体系、日志规范、公共工具函数；
• 自由区（无需审批）：函数内部实现、局部命名、非破坏性重构、测试用例的组织方式。

把这个分层写进architecture.md，就是后文门禁分级的依据。架构契约的意义不在于写得多么完备，而在于明确"谁可以改什么、改动需要什么级别的确认"。

4.4 验收契约：先写"怎么算过"，再让 AI 写代码

验收契约必须同时包含机器可执行项与人工可判定项：

验收基准的层次可以概括为：单元测试 → 契约测试 → 集成测试 → 人工评审，越靠下成本越低、越应前置。把"怎么算过"写在实现之前，AI 才有明确的收敛目标，而不是生成一堆需要人来判断是否合格的代码。

五、Harness：让契约被执行的控制体系

5.1 术语澄清：本文的"Harness"指什么

本文中的 Harness 指驾驭 AI 编码体的工程约束体系，是"控制循环、工具沙箱、自动校验、审批门禁"四要素的统称，属于概念性术语，与任何同名商业产品或 CI/CD 厂商无关。请读者在团队沟通时也做同样澄清，避免概念混淆。

SDD 回答"约束是什么"，Harness 回答"约束如何被执行"。前者是纸面契约，后者是运行时的强制力。

5.2 控制循环：感知 → 规划 → 执行 → 校验 → 反馈

AI 的每一次动作都应纳入闭环：

感知(读取 spec/代码上下文) → 规划(产出变更计划) → 执行(沙箱内修改) ↑ ↓ └──────── 反馈(失败原因、修正建议) ←── 校验(自动检查) ↓ 失败 连续 N 次失败 → 升级人工审批

关键设计点有三个：

1. 规划先于执行：AI 必须先产出变更计划（改哪些文件、为什么改、影响哪些验收条目），计划通过后才允许动代码；
2. 校验失败必须回流到规划，而不是让 AI 在原地反复"试到通过"，否则会掩盖真实问题；
3. 连续失败自动升级为人工审批，避免无限消耗算力与时间。

5.3 工具沙箱：限制 AI 的"手"能伸到哪里

沙箱按最小权限原则约束四类资源：文件系统范围、网络出口、命令白名单、密钥与凭据。以下为示意配置，字段名非任何真实工具的 API：

# sandbox-policy.yaml —— 示意配置，需按团队工具链改造workspace:allow_paths:-"./src/**"-"./tests/**"-"./specs/**"deny_paths:-"./infra/terraform/**"# 基础设施定义禁止改动-"**/.env*"-"**/secrets/**"network:default:denyallow_hosts:-"registry.npmjs.org"# 仅允许依赖安装源commands:allow:-"pnpm test"-"pnpm lint"-"pnpm typecheck"deny:-"rm -rf"-"git push --force"-"kubectl apply"secrets:inject:none# 任务执行期不注入任何生产凭据approval_required_for:-"读取 staging 配置"

配套的运行时要点：执行环境用一次性容器，任务结束即销毁；所有工具调用写入审计日志，可回放；沙箱内的网络默认拒绝，AI 无法把代码或数据外发。

5.4 自动校验：把"人肉评审"前置为机器门禁

校验分层执行，前一层不过不进入下一层：

# ci-gate.sh —— 通用流水线骨架示意，非某平台配置语法set-euopipefailecho"[1/5] 静态检查"pnpmlintecho"[2/5] 类型检查"pnpmtypecheckecho"[3/5] 单元与契约测试（覆盖率阈值自定）"pnpmtest--coverageecho"[4/5] 架构约束扫描"nodetools/check-arch-constraints.mjs# 校验依赖与目录边界echo"[5/5] 依赖与安全审计"pnpmaudit--prodnodetools/check-lockfile-diff.mjs# lockfile 新增依赖告警echo"全部通过，允许进入人工评审"

这里有一个容易被忽视的原则：门禁对人和对 AI 必须一视同仁。如果人类提交可以绕过检查而 AI 提交不行，团队很快会找到"用人工提交绕开 AI 门禁"的土办法，整套约束体系随即失效。

5.5 审批门禁：按风险分级，而不是一刀切

分级的依据来自 4.3 的架构分层：锁定区对应 L3，沙盒区对应 L2，自由区对应 L1。这样规范与流程是同一套语言，不需要在两处重复定义。

六、工程红线示例：把"禁止"写成可检查的规则

6.1 红线一：限定技术栈

一句"别乱换技术栈"没有执行力。可执行的写法是"允许清单 + 版本范围 + 例外申请流程"：

## 技术栈红线（示例红线，按团队实际栈调整） - 前端：允许 React 19.x；禁止引入其他 UI 框架 - 后端：允许 Elysia + Bun 运行时；禁止引入 NestJS/Express 并存 - 包管理：仅允许 pnpm；禁止 npm/yarn 生成的 lockfile 提交 - 例外流程：提交 <tech-stack-exception> 变更单，说明收益、迁移成本、 回滚方案，由技术负责人签字后方可生效，有效期不超过一个季度

示例中的 React 19 与 Elysia + Bun 只是说明写法的载体，真实团队应替换为自己的技术栈，并把版本范围写死，防止 AI 顺手升级大版本。

6.2 红线二：禁止随意替换存储组件 / 引入重型第三方库

存储层是架构漂移的高发区。规则要写清触发动作、违反后果与检测方式：

6.3 红线的可执行化：从文档到门禁

一条红线只有在 CI 里会红才算落地。下面是一段示意实现，具体校验工具按团队选型：

// tools/check-lockfile-diff.mjs —— 示意脚本// 思路：对比基线 lockfile 与当前 lockfile 的依赖集合差异import{execSync}from"node:child_process";constbase=JSON.parse(execSync("git show origin/main:pnpm-lock.yaml",{encoding:"utf8"}));// 实际实现应使用 lockfile 解析库，此处仅示意逻辑constadded=diffAddedPackages(base,current());if(added.length>0){console.error("检测到新增依赖，需人工审批：");for(constpkgofadded){constheavy=pkg.unpackedSize>500*1024;// 阈值按团队标准设定console.error(`-${pkg.name}@${pkg.version}${heavy?" [体积超阈值]":""}`);}process.exit(1);// 阻断合入，转 L2 审批}

红线的三层防线可以概括为：预防（规范文档）→ 阻断（CI 门禁）→ 补救（审批与回滚）。只做第一层是纸上谈兵，只做第二层会误伤正常开发，三层齐备才是可运营的约束体系。

值得一提的是，工程约束本身也要定期审计。开源社区已出现反面教材：有项目 README 提示安装0.0.3版本，而仓库最新 release 是0.0.4-rc[10]；GitHub Trending 的排名只反映页面当时的热度，不代表项目质量、稳定性或适用范围 [11]。同理，热榜工具不能直接当红线依据，引入前需二次验证。

七、端到端走查：一个需求从 spec 到合入

7.1 场景设定

以通用功能"订单退款申请"为例（合成案例），第一步产出的不是代码，而是三个契约文件：

• requirements.md：REQ-014 需求条目、非目标、性能约束；
• architecture.md：声明存储组件、鉴权方式属锁定区，退款单状态机属沙盒区；
• acceptance.md：金额校验用例、状态机契约测试、可观测性检查项。

7.2 六步流程

1. 编写契约：人完成三份契约并签字，AI 此阶段只做提问澄清，不写代码；
2. 生成计划：AI 读取契约，产出变更计划（文件清单、影响的验收条目、风险点），人确认；
3. 沙箱执行：AI 在工具沙箱内实现，越权操作直接被拒绝；
4. 自动校验：CI 依次执行 lint → typecheck → test → 架构约束扫描 → 依赖审计；
5. 门禁审批：本次改动触及存储层边界，触发 L2 门禁，一名评审人 + 依赖审计确认；
6. 合入归档：合入后把契约文件、校验输出、审批记录一并归档，形成可追溯凭证。

失败回路同样重要：校验不过 → 退回 AI 重新规划（记录失败原因）；连续两次不过 → 升级人工；红线违规 → 直接拒绝并要求架构师介入。

7.3 反例对照：去掉契约与门禁会发生什么

• 去掉需求契约 → Day 3 的"整单退款 vs 按行退款"分歧必然出现；
• 去掉架构契约 → Day 5 的存储组件被替换将无人拦截，直到线上事故才暴露；
• 去掉验收契约 → Day 7 的"算不算完成"没有客观标准，评审变成主观辩论；
• 去掉沙箱与门禁 → 所有约束都依赖人的自觉，一次疏忽就可能把密钥文件或基础设施定义提交上去。

八、落地路线图与常见坑

8.1 三阶段渐进落地

不必追求一步到位。小团队的第一步可以只是：所有 AI 任务必须关联一个 spec 文件，没有 spec 的改动不予评审。

8.2 度量：用交付指标而非编码指标

验证效果时不要只统计"AI 生成了多少代码"。建议团队自选以下指标组合（不给行业基准数字，避免误导）：

• 返工率：合入后一周内被修改的代码占比；
• 需求变更后的一次通过率：改需求后 CI 一次通过的比例；
• 门禁拦截数与拦截原因分布：拦截过多说明红线过严，过少说明形同虚设；
• 评审时长：从提交 PR 到批准的耗时，衡量"评审瓶颈"是否缓解；
• 架构漂移事件数：因依赖/存储/接口变更引发的回滚次数。

8.3 常见坑

九、总结

回到开头的问题：AI 写得快，为什么交付不动？因为编码提速没有自动转化为交付提速，缺口出在契约与验收上——这正是 AIIA"银弹"相关报道中"AI Coding 提升了编码效率，却没有解决交付问题"这句话的工程含义 [2]。

可以把全文压成一张速查卡：

三条红线底线：技术栈锁定（允许清单 + 版本范围 + 例外流程）、存储组件禁换（lockfile diff + 架构扫描）、重型依赖需审批（体积与许可证阈值）。

SDD 立契约，Harness 设闸门，红线作底线。当这三者形成闭环，AI 编码才从即兴创作变成可审计、可复现、可治理的工程流水线——这也正是行业从"AI 辅助"走向"AI 自主协同"时，组织级软件工厂正在建设的能力 [3]。

参考资料

[1] SDD 规范驱动 + Harness 驾驭工程 AI：把"氛围编码"升级为可控的 AI 原生软件工程，掘金，https://juejin.cn/post/7689838796083675178

[2] 重塑 AI 软件工程：网易智企 SDD 实践入选"银弹"标杆案例，CSDN，https://blog.csdn.net/Sharn0718/article/details/165749892

[3] 中电金信以 AI 原生软件工厂开发模式助推产业智能升级，CSDN，https://blog.csdn.net/zhongdianjinxin/article/details/166362559

[4] 13. Vibe Coding 全新 AI 编程范式详解与生产级环境搭建指南，CSDN，https://blog.csdn.net/weixin_48204292/article/details/167279903

[5] AI 新闻日报 2026-10-04：IDE 变成多智能体调度台 / 评审成新瓶颈 / 全栈开源人形与"大脑"融资同周出现，CSDN，https://blog.csdn.net/qq_39427511/article/details/167072184

[6] AI 资讯日报｜2026-10-06：开源大模型密集上新，Reflection 与 Mistral 同日发布；DeepSeek 融资 120 亿美元，智能体基建成企业落地主线，CSDN，https://blog.csdn.net/IT_ORACLE/article/details/167210150

[7] ai-boost/awesome-prompts：Curated list of chatgpt prompts（含 prompt attack & prompt protect、spec-driven development 相关条目），GitHub，https://github.com/ai-boost/awesome-prompts

[8] 给 AI 编码智能体装"技能包"：GitHub 热榜揭示的技能化/流程化新赛道，CSDN，https://blog.csdn.net/m0_74899094/article/details/167130168

[9] meituan-longcat/vitabench：[ICLR 2026] VitaBench: Benchmarking LLM Agents with Versatile Interactive Tasks in Real-world Applications，GitHub，https://github.com/meituan-longcat/vitabench

[10] 2026 GitHub Trending 解读：开发者工具聚焦降本增效与自托管，CSDN，https://blog.csdn.net/weixin_27918373/article/details/167434080

[11] GitHub 月榜甄选 9 个项目：AI Agent 工具与工作流方向，掘金，https://juejin.cn/post/7674970633500426275

数据口径说明：本文涉及的 Star 数、项目数量、客户数量、参与企业数量等均为来源自述或来源转引，截至来源发布时，未做第三方核验；相关表述已在正文相应位置标注。文中代码、配置、目录结构与案例均为示意或合成示例，需按团队实际工具链与业务场景改造。