意图与代码之间：AI编程范式全景解读

系列第一篇，全面解读Vibe Coding、Spec-Driven Development与Harness Engineering三大AI编程范式的起源、定位与抉择框架，为后续深入各范式的实战文章奠定理论基础，属于扫盲篇。

AI 编程现状

现状：

随着大语言模型(LLM)及智能体(AI Agent，如 Claude Code、Cursor、GitHub Copilot)全面嵌入软件工程生命周期， 软件开发的瓶颈已从 代码编写速度 转化为 人类意图传递的精确度。AI 代码编写习惯正在分化为三大核心范式： Vibe Coding(氛围感编码)、Spec-Driven Development(规范驱动开发)与Agent Harness(环境驱动开发)。

痛点：

• 其实真正的痛点是人类意图传递的精确度，即我们怎么能用更少的描述传递给 AI Agent 最准确意图，而不是意图怎么也描述不清楚。

• vibe coding 在生产级项目带来的致命缺陷: 极易崩溃、信任崩塌、技术债累加等等。

  • 范围蔓延：没有明确边界，AI 容易过度实现或遗漏关键点
  • 幻觉（Hallucination）：AI 编造不存在的 API、错误的用法
  • 不可审查：没有 spec 和 plan，团队无法在实现前对齐预期
  • 不可复现：换一个 prompt 措辞，得到完全不同的实现
  • 技术债指数级增长：每一轮「看起来能用」的修补都在累积隐患

扩展：

范式陷阱：为什么纯粹的 Vibe Coding 无法支撑生产级系统？ Vibe Coding 在开发初期由于没有文档约束，速度呈现爆发式增长。然而当项目代码量超过模型上下文窗口 (Context Window)或复杂度跨越临界点时，由于缺乏“真理源规范”，AI 在修复 A Bug 的同时会引入 B Bug。 团队将陷入无休止的“编译报错-灌入 AI-生成新错-再次调试”的死循环（即上下文幻觉陷阱）。

三种范式对比

Vibe Coding 定位

关键特征：

• 输入：自然语言对话，无结构化文档
• 循环：prompt → 生成 → 运行评估 → 继续对话调整
• 人类角色：评估行为结果，而非逐行审查代码（Simon Willison 的判断标准：如果你审查并理解 AI 写的每一行代码，那就不是 vibe coding，只是把模型当打字助手用）
• 产出物：仅有代码本身，意图不被持久化记录

Vibe Coding 并非一无是处。它的最佳场景是：

• 快速验证一个想法是否可行（Proof of Concept）
• 一次性脚本、数据处理、临时工具
• 学习新框架时的探索性编程
• 个人项目、Hackathon、Demo 展示

一句话总结：Vibe Coding 是 AI 编程的「素描」，不是「施工图」。

Spec Coding 定位

理论源头是 Sean Grove（前 OpenAI alignment 研究员）2025 年的演讲《The New Code》，

工具生态由 GitHub Spec Kit（2025-09）、AWS Kiro、Tessl、OpenSpec 等共同建立。

Thoughtworks 的 Birgitta Böckeler 在 2025 年 10 月给出了目前最常用的三级成熟度框架。

三级成熟度框架:

关键特征：

• 输入：结构化 Markdown 文档（需求/设计/任务三段式，或 What-spec / How-spec 拆分）
• 循环：Specify → Plan → Tasks → Implement，必要时回写规格（"spec co-evolution"）
• 人类角色：在每个阶段审查并批准产出物，而非审查代码本身
• 产出物：规格文档（requirements.md / design.md / tasks.md 等）+ 代码，规格是第一公民

注意：Spec Coding 是从「猜你想要什么」到「照规格施工」的进步，是 26-27 年上半年的主流路线！

为什么行业集体转向 Spec?

2025 年，一个共识浮出水面：AI Coding Agent 效果不好，往往不是因为模型太弱，而是因为指令含糊不清。

• GitHub 开源了 Spec Kit（7.7 万星），把 spec → plan → task → implement 结构化。
• OpenAI 的 Symphony 架构要求每个 issue 绑定 SPEC.md 作为契约。
• Anthropic 在 Claude Code 里内置了 Plan Mode——本质就是轻量版 spec。
• AWS 推出了 Kiro，以 spec 为核心驱动 Agent 开发。

整个生态不约而同地收敛到同一个结论：在写代码之前，先把「做什么」定义清楚，不是让 AI 去猜测！

Spec Driven Development 的核心流程

SDD 不是一个工具，而是一种方法论。核心分为四步：

• Specify（定义做什么）

  • 只写「做什么」，不写「怎么做」，Spec 是功能层描述，刻意保持技术无关。
  • 一份好的 spec 用非技术语言写清：功能目的、使用场景、需求边界、验收标准。

• Plan（规划怎么做）

  • Plan 是技术层：告诉 Agent 如何把 spec 落地。

• Tasks（拆解任务）

  • 把 Plan 拆成小而有序的任务，每个任务满足：可在一次 Agent Session 中完成、产出可验证的变更并附带测试。

• Implement（逐个实现）

  • Agent 逐个执行，Agent 按任务列表顺序实现。此时它拿到了所需的一切上下文，不需要再猜。

Spec Coding 解决了什么，没解决什么?

解决了：

• 歧义问题——Agent 不需要再猜
• 可审查性——团队可在实现前对齐预期
• 可复现性——相同 spec 产出一致结果
• 质量底线——验收标准就是测试用例

没解决：

• Agent 运行时的故障恢复
• 多 Agent 协作的编排与状态管理
• 上下文窗口的动态管理
• 安全防护与人工审批流程
• 跨会话的记忆持久化

Spec Coding 的 EARS 语法

为了让 AI 100%完美解析需求，SDD 大量采用 EARS (Easy Approach to Requirements Syntax) 符号系统，规定所有需求必须符合以下五种特定条件模式：

• [Trigger] 当特定事件发生时... (Event-driven)
• [State] 当系统处于特定状态下... (State-driven)
• [Precondition] 如果满足前提条件... (Preconditioned)
• [Optional] 在可选功能激活时... (Optional)
• 系统 [应有行为] (Expected Response)

Spec Coding 的核心

一句话：规范（Specification）是唯一的真理源（Source of Truth），代码只是该规范在特定技术栈下的编译产物。

核心消除的痛点：

• 意图漂移： 防止 AI 在多轮对话或大型重构中忘记最初的业务目标，偏离核心轨道。
• 上下文衰减： 通过将代码库规则和约束沉淀在项目根目录（如 CLAUDE.md/AGENTS.md），避免随着代码行数增加而导致 AI 准确率急剧下降。

个人观点：中小型生产级项目交付的主力阵地，既可以确保速度也能保证质量，前提是中小型和个人项目。

Harness Engineer 定位

这是 2026 年上半年才逐渐成型的术语，由 Red Hat（Rich Naszcyniec）、Thoughtworks（Birgitta Böckeler）等独立提出并很快趋同。核心隐喻：

"Agent = Model + Harness"——模型是引擎，harness 是汽车的其余部分：转向、刹车、车道线、保养计划。Harness engineering 不改变模型本身,而是构建模型运行所处的结构化环境。

Bockeler 把 harness 拆成两个控制向量：

• Guides（Feedforward / 前馈）：行动前给智能体的引导——CLAUDE.md、skills、架构文档、代码规范、类型系统
• Sensors（Feedback / 反馈）：行动后让智能体自我核验的机制——编译器、单元测试、linter、property-based testing、LLM-as-judge review

关键特征：

• 输入：不是某一种文档格式,而是整套"引导 + 传感器"系统
• 循环：Guide（行动前约束）→ Agent 自主执行 → Sensor（行动后核验）→ 自我修正 → 重复，理想情况下问题在到达人类视野前已被纠正
• 人类角色：设计系统（而非逐次介入），定期评估 harness 本身是否足够"可被挽具化"（harnessability）
• 产出物：一套可复用的工程基础设施（skills、hooks、测试套件、CI 规则），规格文档只是其中一种 guide

三者关系分析

• Harness 是容器，SDD 是容器里的一种具体填料。规格文档（requirements.md / design.md）本质上是 Guide（前馈）的一种实现形式——把"行动前应该知道什么"写成持久化的 Markdown。
• Vibe coding 是 harness 接近空的极限状态。没有持久化的 Guide，也没有系统性的 Sensor，全靠对话本身和人类的即时判断来纠偏。
• 纯 SDD 如果只做 Guide 不做 Sensor，仍然是半个 harness。这也是为什么 Kiro 要引入 property-based testing、Spec Kit 要求先写失败的契约测试再实现——它们在尝试把 Sensor 补齐。
• 反过来，好的 harness 不一定需要重型 SDD。可以用很轻的 Guide（一两个 skill 文件）+ 很强的 Sensor（CI 全覆盖 + 自动化 review）达到同样的可靠性,这正是 OpenSpec、Claude Code 原生 Plan Mode 等"轻量派"的思路。

一句话总结这三者的定位差异：Vibe coding 回答"怎么对话"；SDD 回答"行动前写什么文档"；Harness engineering 回答"整套系统怎么让 AI 自我纠错"——后者的范围最大,前两者可以被它包含。

问题深度分析

编码和解码鸿沟

Red Hat 的 Rich Naszcyniec 提出了一个很实用的框架：开发者心里想的（编码）与 AI 实际产出的（解码）之间存在鸿沟。自然语言是有损信道——你说"简洁的响应式集群健康监控面板"，AI 听到的是"差不多但不完全对"的东西：用了已废弃的库、漏了鉴权、模式与现有代码库不一致。

三种范式应对这个鸿沟的方式不同：

• Vibe coding 完全不主动缩小鸿沟，依赖事后发现问题再迭代对话；
• SDD 通过在行动前强制写清楚 what 和 how 来缩小鸿沟；
• Harness 通过行动后的传感器网络捕捉鸿沟造成的偏差，在问题到达人类之前自动纠正。

两种机制并不互斥，结合使用效果最好：规格降低"第一次猜错"的概率，传感器兜底"猜错了也能自动发现"。

反馈循环周期

对 SDD"换皮瀑布"的质疑很常见，也有一定道理——一份完整的需求文档先于实现存在，这确实和瀑布模型的形式相似。但二者的本质区别在于反馈循环的周期长度：

• 传统瀑布：写 200 页需求文档 → 交给开发团队 → 数月后才看到交付物，期间需求早已漂移，文档变成"虚构"；
• SDD：写一份 markdown 规格 → 交给 agent → 几分钟内看到产出 → 发现不对就直接改规格重跑。

这个观点的提出者（独立技术博客 Codagent newsletter）同时给出了一个清醒的提醒：SDD 的失效模式不是"写规格"本身，而是规格的范围（scope）过大。如果把整个"通知子系统"（webhook、邮件摘要、应用内提醒、用户偏好、投递追踪、重试限流等一次性全部规格化），人工审查检查点被跳过，等到全部实现完才发现一个早期假设（如数据模型）错了，所有功能都要回溯排查——这跟瀑布模型的"大批量、晚反馈"是同一种问题，只是跑在更快的硬件上。

实证反面案例：

• Marmelab 团队记录过为了实现一个简单的"显示日期"功能，被 Spec Kit 流程要求产出了 1300 行 markdown；
• "GSD"（Get Shit Done）这类多 agent 并行研究 + 验证的工作流，一次 bug 修复可消耗 100 次以上的 agent 调用。

实践建议：把规格的颗粒度控制在"一次可以单遍评估"的范围——一个功能、一个变更，而不是一整个子系统。

Harness 的两个轴

Bockeler 区分了两类控制：

这里有一个常被忽视的细分：Sensor 本身又分两类——

• Computational（计算式）：确定性、运行快、CPU 即可执行（linter、类型检查、编译）；
• Inferential（推理式）：需要另一个 LLM 来做判断（LLM-as-judge、代码评审 subagent）。

实践中的常见误区是把"在 prompt 里强调要小心"当作可靠性保障——Bockeler 的判断很直接：prompt 工程说"告诉模型要小心"，harness engineering 说"让小心的路径成为默认路径"。如果 agent 写出编译不过的代码,在 prompt 里加一句"请注意类型安全"没有用,把编译和测试做成强制循环的一部分才有用。

演化时间线

四支柱模型

Red Hat 在其 2026 年 3 月文章中提出了一个比"三分法"更细的拆解,把 SDD 和 Harness 的元素揉在一起：

这个框架的价值在于明确了 Vibe 和 Spec 不是替代关系，而是同一工作流的两个阶段：用 vibe 探索想法、用 spec 固化决策、用 skill 封装可复用能力、最后交给合适自主程度的 agent 去执行。该团队还提出了"interacting"（对话/教练模式）与"instructing"（指令/执行模式）的二分——这与本文档"三范式"的划分是兼容的不同切面。

决策框架

任务复杂度低，且不需要团队协作/审计追溯？
   └─ 是 → Vibe Coding（探索阶段，原型验证）
   └─ 否 ↓

需求/边界尚不清楚，自己也说不清楚要什么？
   └─ 是 → 先 Vibe 一版粗糙原型摸清问题,再回头写 Spec（"vibe before you spec"）
   └─ 否 ↓

任务范围是否可以一次性单遍评估完成（一个功能/一次变更）？
   └─ 否（涉及多个子系统/大型重构）→ 拆小后分别走 SDD，不要一次性规格化整个系统
   └─ 是 ↓

是否需要长期维护、多人协作、或需要给团队/审计留痕？
   └─ 是 → Spec-Driven Development（spec-anchored 级别足够，无需追求 spec-as-source）
   └─ 否 → 轻量级 Guide（一两个 skill 文件）+ 强 Sensor（测试+CI）即可，不必上重型 SDD 工具链

无论选择哪条路径，都应同步建设：
   └─ Sensor 层（自动化测试、类型检查、安全扫描）—— 这是不分范式都必须有的兜底机制

参考资料

• Andrej Karpathy 提出 vibe coding（2025 年 2 月）：https://x.com/karpathy/status/1886192184808149383
• Sean Grove《The New Code》演讲：https://my.infocaptor.com/hub/summaries/ai-engineer/the-new-code-sean-grove-openai-8rABwKRsec4
• Birgitta Böckeler，SDD 三级框架（martinfowler.com，2025 年 10 月）：https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
• arXiv 2602.00180，《Spec-Driven Development: From Code to Contract》：https://arxiv.org/abs/2602.00180
• arXiv 2505.19443，《Vibe Coding vs. Agentic Coding》：https://arxiv.org/pdf/2505.19443
• arXiv 2510.17842，Vibe Coding 学术定义：https://arxiv.org/pdf/2510.17842
• Birgitta Böckeler，《Harness engineering for coding agent users》：https://martinfowler.com/articles/harness-engineering.html
• Birgitta Böckeler & Chris Ford，《Harness engineering and agent feedback》：https://www.thoughtworks.com/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors
• Thoughtworks Podcast，《What is harness engineering?》：https://www.thoughtworks.com/insights/podcasts/technology-podcasts/what-harness-engineering
• Red Hat，《Vibes, specs, skills, and agents: The four pillars of AI coding》：https://developers.redhat.com/articles/2026/03/30/vibes-specs-skills-agents-ai-coding
• Codagent Newsletter，《Think Before You Prompt》（SDD 与瀑布模型辨析、harness 分类）：https://codagent.beehiiv.com/p/think-before-you-prompt
• awesome-harness-engineering 资源合集：https://github.com/ai-boost/awesome-harness-engineering
• GitHub Spec Kit：https://github.com/github/spec-kit
• AWS Kiro Specs 文档：https://kiro.dev/docs/specs/
• OpenSpec：https://github.com/Fission-AI/OpenSpec
• Anthropic Agent Skills 工程博客：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
• Claude Code 官方最佳实践：https://code.claude.com/docs/en/best-practices
• Marmelab，《Spec-driven development: Waterfall strikes back》：https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html
• Thoughtworks Technology Radar（SDD 评级为 Assess）：相关讨论见 vibeready.sh 文章 https://vibeready.sh/blog/what-is-spec-driven-development/

其他说明