从Vibe Coding到Harness×SDD：AI全栈开发的范式跃迁与工程化落地

当AI出码率达到90%却没有真正提效，当Vibe Coding的代码如野马般难以驾驭，我们面临的核心问题不再是“AI能不能写代码”，而是“如何让AI在复杂工程中持续、可靠地写出对的代码”。SDD规范驱动开发与Harness驾驭工程的结合，正是这道题的完整答案。

一、Vibe Coding的浪漫与残酷

1.1 什么是Vibe Coding

2025年初，Andrej Karpathy提出了一个引爆技术圈的概念——Vibe Coding（氛围编程）。它的本质是：你不再逐行写代码，而是描述你想要什么，让AI去写，你只看效果不看实现。

在原型验证、一次性脚本、个人小工具这些低风险场景中，Vibe Coding确实好用——简单、快、几乎没有认知负担。你只需要沉浸在“氛围”里，AI就能帮你把想法变成可运行的程序。

1.2 浪漫褪去后的残酷现实

当Vibe Coding被引入生产级代码库，三个结构性缺陷会迅速暴露：

更扎心的一组数据来自高德大模型应用平台：出码率从53%提升到80%-90%，但项目交付周期没有明显缩短。编码快了，但Review慢了；出码多了，但返工也多了。出码率≠交付率——AI编程的瓶颈，已经不再是模型本身的智力，而是工程化能力。

1.3 两次范式跃迁

行业对“AI究竟怎么写代码才靠谱”这个问题的认知，经历了清晰的演进：

Vibe Coding（凭感觉写）→ SDD（规范驱动）→ Harness Engineering（工程化体系）

这不是三个并列选项，而是三个递进阶段。Vibe Coding教会了我们“AI能写代码”，但也暴露了“光让AI写代码不够”的残酷事实。接下来的问题顺理成章：如何让AI“写对代码”，并且在长期、复杂、团队协作的环境里持续写对？

二、SDD：让规范成为AI的“唯一事实来源”

2.1 SDD解决什么

Vibe Coding的根本问题是：人的意图表达太模糊，AI只能瞎猜。你说“做一个待办事项应用”，AI脑补了一堆假设——用什么框架？数据存哪？要不要登录？每次脑补都是一次赌博。

SDD（Spec-Driven Development，规范驱动开发） 的核心思路是：在AI写代码之前，先把“你想要什么”严格地、结构化地写下来，再让AI去实现。

2.2 SDD的核心流程

SDD的工作流包含四个阶段：

1. 写Spec（规范）→ 描述“要做什么、满足什么约束”
        ↓
2. 写Plan（计划）→ 拆成具体任务、定义验收标准
        ↓
3. 生成代码 → AI按Spec和Plan实现
        ↓
4. 验证 → 用Spec里定义的验收标准对照验收

验收标准是SDD的灵魂。它必须是可测试的、无歧义的。比如“用户登录成功后跳转到首页”是模糊描述，而“用户登录成功后，3秒内跳转到首页，并在首页显示用户昵称”才是可测试的验收标准。

2.3 SDD的局限

SDD解决了“一次任务怎么做对”的问题，但还没解决：

• 怎么让AI在长期复杂项目里保持一致？
• 怎么管理多个Agent并行工作？
• AI写的代码怎么自动测试、审查、部署？

这就引出了Harness Engineering。

三、Harness：为野马设计缰绳

3.1 Harness是什么

“Harness”原意是马具/挽具——把一匹力大无穷但方向不定的野马，变成能拉动真实生产载荷的可靠劳动力的那套装置。

在AI工程语境下，Harness指的是包裹在模型外层的一切工程化基础设施：上下文管理、工具调度、状态持久化、验证门禁、反馈循环。

一个核心公式正在成为行业共识：

Agent = Model + Harness

多组实测数据印证了这个公式的力量：

• 同一模型在不同Harness下的表现差异，远大于不同模型在同一Harness下的差距
• 在TerminalBench基准测试中，仅通过对Harness层的优化，就使同一个模型的能力从基线以下跃升至Top 5
• Vercel团队发现，主动剔除80%的Agent工具后，流程更精简，Token消耗骤降，响应速度反而更快

调教Harness，才是释放AI真实工程效能的真正变量。

3.2 Harness的四大核心支柱

一个成熟的Harness工程体系包含四大支柱：

支柱一：上下文架构（Context Architecture）

Agent应当恰好获得当前任务所需的上下文——不多不少。OpenAI团队早期犯过一个典型错误：将AGENTS.md写成了百科全书，结果“所有内容都重要=没有内容重要”。后来他们将其控制在约100行，作为索引和地图，指向更深层的Design Docs和Architecture Specs。

企业级实践中，推荐建立五层记忆体系：

• Enterprise级：企业全局安全与合规策略（不可绕过）
• User级：个人编码偏好
• Project级：团队共享项目规范（Anthropic要求控制在200-300行以内）
• Rules级：细分领域规范，按Glob模式条件化加载
• Local级：个人临时备忘，不提交代码库

支柱二：Agent专业化（Agent Specialization）

拥有受限工具集的专业Agent，优于拥有全部权限的通用Agent。Anthropic明确分离了三种角色：

• Planner：负责规划
• Generator：负责实现
• Evaluator：负责验证

核心发现：“将做事的Agent和评判的Agent分开，是一个强有力的杠杆。 ”

支柱三：持久化记忆（Persistent Memory）

进度持久化在文件系统上，而非上下文窗口中。标准化启动序列：检查当前工作目录→读取Git Log和进度文件→定位优先级最高的未完成任务→开始工作。这使得跨越数十个会话的长时间任务成为可能。

支柱四：结构化执行（Structured Execution）

永远不让Agent在未经审查和批准书面计划之前写代码。理想执行流：理解→规划→执行→验证，每个阶段之间有明确的质量门禁。

3.3 一个真实的Harness目录结构

来自企业级Java应用（10万+行代码）的实战案例：

.harness/
├── agents/              # Agent角色定义
├── rules/               # 规则体系
│   ├── 工程结构.md       # 分层架构约束
│   ├── 开发流程规范.md   # 10阶段流程定义
│   └── 项目编码规范.md   # 硬性编码约束
├── skills/              # 技能体系（9个Skill）
│   ├── request-analysis/    # 需求分析
│   ├── coding-skill/        # 编码实现
│   ├── expert-reviewer/     # 专家评审
│   ├── unit-test-write/     # 单元测试编写
│   ├── unit-test-ci/        # CI流水线验证
│   ├── deploy-verify/       # 部署验证
│   └── code-review/         # 代码检查
├── changes/             # 变更管理目录（完整Audit Trail）
└── mcp/                 # 外部工具集成配置

四要素各有明确职责：Rules告诉Agent“标准是什么”，Skills告诉Agent“应该怎么做”，Wiki告诉Agent“系统是什么样的”，Changes记录Agent“做了什么”。

四、SDD×Harness：为什么两者是共生关系

4.1 常见疑问：有了Harness，SDD还重要吗？

随着Harness Engineering概念的升温，一个自然的疑问出现了：如果Harness已经提供了上下文管理、工具调度、验证门禁，那花精力写Spec还有意义吗？

答案是：Harness和SDD不是竞争关系，而是同一件事的两个层面。

4.2 三个角色看清SDD在Harness中的位置

角色一：Agent推理的地图

OpenAI有一条实践原则：“要给Agent的是一张地图，而不是一本1000页的说明书。”

Spec就是这张地图——有目录，有指针，Agent从高层概览出发，按需深入到具体节点。没有这张地图，Agent的起点是代码——而代码只告诉它“系统现在是什么样”，不告诉它“为什么是这样”“哪些不该改”。Agent看不到的，就不存在。

角色二：约束生效的语义基础

Linter和结构测试可以强制执行“格式”层面的约束——层间依赖方向、命名规范。但Linter检查不了语义：某个错误码在跨服务场景下应该怎么处理？某个接口字段在特定场景下的业务含义是什么？

这些语义必须被显式写进Spec，Agent才能正确推理。AI不会告诉你“这里我猜了”——它只是生成了一段看起来合理的代码，上线后才发现行为不符合预期。这不是模型能力不够，是语义没有被写进Spec。

角色三：反馈回路的正确性判据

Harness工程的核心飞轮是：Agent犯错→诊断原因→工程化修复→Agent不再重犯。

但飞轮的第一步“Agent犯错”，需要一个前提：你知道Agent犯错了。而知道，需要有一个“正确性的判据”——对照什么来判断Agent的输出是对是错？

Spec的验收标准层（WHEN/THEN场景）提供的，正是这个判据。有了判据，反馈回路才能闭合；没有判据，“发现错误”这一步只能靠运气。

4.3 Harness是放大器，Spec是被放大的内容

OpenAI工程团队在官方博客中总结：

“工程纪律没有消失，只是从‘写好代码’转移到了‘构建好让Agent工作的scaffolding’。而Spec——写进仓库的意图、契约和规范——正是这个scaffolding的核心内容之一。Harness越强，Spec的质量对最终结果的影响就越大。 ”

Harness是放大器，Spec是被放大的内容。 Harness让AI的执行能力更强、更快，但如果Spec写错了，AI只是更快地做错事。

五、实战落地：从零构建SDD×Harness体系

5.1 完整工作流速览

一个真实的SDD×Harness工作流包含四个Phase：

Phase A — 任务开始
  → 读PROGRESS.md（进度跟踪）
  → 读Spec（理解WHY/WHAT/HOW + 验收标准）
  → 读MEMORY.md（加载历史决策和踩过的坑）

Phase B — 任务进行中
  → 更新进度状态为“进行中”
  → 按Spec实现；Spec有缺陷先更新Spec
  → 新决策/新坑→暂停实现，先沉淀到memory/

Phase C — 任务完成等待验证
  → 输出验证清单（需求驱动，不是读实现反推）
  → 更新进度状态为“待验证”，停下等人工/自动测试

Phase D — 测试通过三向同步
  → 更新进度状态为“已完成”
  → Spec文件中任务项打勾，更新元数据
  → Memory三步同步：草稿定稿→索引追加→推翻处理

5.2 三层落地路线

企业级落地通常采用三步走策略：

5.3 Skills：将好Prompt封装为可复用资产

在Harness体系中，一个好用的Prompt应该被封装为Skill并通过Git版本控制。新人克隆代码库时就能瞬间继承整个团队沉淀的AI编程能力。

一个Skill采用渐进式披露设计：

• 启动阶段：仅加载name和description元数据（约100 tokens）
• 匹配阶段：用户输入命中语义时，展开完整SKILL.md
• 执行阶段：真正需要动作时，动态调用挂载的外部资源

这种设计在运行多Skill系统时，Token空间可节省约98%。

六、总结：范式跃迁的本质

从Vibe Coding到SDD，再到Harness Engineering，本质上是将AI从“随机文本生成器”转化为“可靠的软件工程师” 的过程：

• Vibe Coding回答的是：AI能写代码吗？ → 能。
• SDD回答的是：AI怎么写对代码？ → 用规范驱动，让AI有据可依。
• Harness Engineering回答的是：AI怎么持续、规模化地写对代码？ → 用上下文架构、专业化Agent、持久化记忆、结构化执行和反馈循环，构建完整的工程化支撑体系。

在AI工程化时代，工程师的核心竞争力不再是“手写代码”，而是设计AI的运行环境——这份能力，正是SDD×Harness实践者的使命所在。