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

LiuMingXin2026-06-24 17:37

系列第一篇 · 总览篇 ------ 全面解读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 Spec-Driven Development Agent Harness
核心隐喻 对话即编程，"凭感觉"迭代 规格是契约，代码是规格的派生表达 Agent = Model + Harness，模型是引擎，Harness 是车身
起源 Karpathy，2025年2月 Sean Grove《The New Code》，2025；GitHub Spec Kit，2025年9月 Red Hat / Thoughtworks，2026年初
主要产出物 仅代码，意图不持久化 requirements.md / design.md / tasks.md（或 what-spec / how-spec） Guides（CLAUDE.md、skills）+ Sensors（测试、CI、linter）构成的系统
反馈机制 人工试运行 + 继续对话 阶段性人工审查批准（spec → plan → tasks 各有检查点） 系统化的自动反馈循环（编译、测试、property test、LLM-judge）
人类角色 评估结果、调整 prompt 在每个阶段审查并批准产出物 设计系统本身，定期评估 harness 是否足够健壮
适用规模 原型、探索性开发、个人小工具 中大型功能、团队协作、需要审计追溯的场景 任何规模，尤其是需要长期无人值守自主运行的场景
不适用场景 生产级系统、多人协作、合规要求高的项目 探索阶段需求不明确、简单 bug 修复、单变量改动 几乎没有不适用场景，但搭建成本不为零
典型工具 纯聊天式 Claude/Cursor/ChatGPT 对话 GitHub Spec Kit、AWS Kiro、Tessl、OpenSpec Claude Code Plan Mode + Skills + Hooks + Subagent Review；自定义 CI/CD 传感器体系
典型风险 架构漂移、安全漏洞被忽视、代码复杂度上升 文档过重导致"伪瀑布"、规格与代码逐渐脱节 搭建与维护成本高，"可挽具性"差的代码库收益有限
实证数据 未经引导的 AI 编码使代码复杂度提升 41%（arXiv 2511.04427） Red Hat 自述规格驱动方式使代码评审量减少 40% 经过 harness 强化的团队据报告达到 100% 安全规范合规率（Red Hat 案例）
安全相关数据 LLM 生成代码漏洞率 9.8%--42.1%（Yan et al., 2025） 部分团队仍报告 AI 代码中 45% 样本含 OWASP Top 10 漏洞（Cloud Security Alliance，2026年4月） 通过 Sensor（自动化安全扫描）可在合并前拦截，而非依赖人工审查
与"瀑布模型"的关系 完全不是瀑布，因为没有上游文档 表面像瀑布，但反馈循环是分钟级而非季度级，且规格随项目演进（"spec co-evolution"） 与瀑布无关,是运行时的控制系统,不是开发流程阶段划分

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 月给出了目前最常用的三级成熟度框架。

三级成熟度框架:

级别 含义
Spec-first 任务开始前写规格，用完即弃，不长期维护
Spec-anchored 规格在功能交付后继续保留，用于后续演进与维护（Spec Kit、Kiro 处于此级）
Spec-as-source 规格是人类唯一编辑的文件，代码完全由规格生成（Tessl 的目标形态）

关键特征：

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

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

为什么行业集体转向Spec Driven

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），代码只是该规范在特定技术栈下的编译产物。

核心消除的痛点：

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

Harness Engineera定位

这是 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 自我纠错"------后者的范围最大,前两者可以被它包含。

四、三者问题分析

编码/解码鸿沟（Encoding/Decoding Gap）

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

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

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

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

反馈循环周期：SDD与瀑布模型的本质区别

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

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

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

实证反面案例：

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

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

Guides 与 Sensors：Harness 的两个轴

Bockeler 区分了两类控制：

类型 时机 例子 性质
Guides（前馈） 行动前 CLAUDE.md、skills、架构文档、SDD 的规格文件、代码规范 试图提前防止错误发生
Sensors（反馈） 行动后 编译器、单元/集成测试、linter、property-based test、LLM-as-judge review 在错误发生后捕捉它

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

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

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

五、演化时间线

时间 事件
2025年2月 Andrej Karpathy 提出 "vibe coding"
2025年（春夏） Sean Grove 在 AI Engineer World's Fair 发表《The New Code》，提出规格优于代码的论点
2025年7月 AWS 发布 Kiro，落地 Requirements → Design → Tasks 三段式 SDD 工作流
2025年9月 GitHub 开源 Spec Kit
2025年10月 Birgitta Böckeler 在 martinfowler.com 发表三级 SDD 成熟度框架（spec-first / anchored / as-source）
2025年11月 Thoughtworks Technology Radar 将 SDD 评级为"Assess"（观察阶段，非推荐采用）
2025年10月 Anthropic 发布 Agent Skills 标准（SKILL.md + progressive disclosure），成为 harness 中 Guide 层的事实标准之一
2026年1月起 "harness engineering" 术语开始被 Red Hat、Thoughtworks 等独立提出并迅速趋同，"agentic engineering"（Karpathy）作为相关说法同期出现
2026年3-5月 Böckeler 发布系列文章细化 Guides/Sensors 框架，Red Hat 提出"四支柱模型"（vibes / specs / skills / agents）

六、四支柱模型

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

支柱 定位 使用场景
Vibes 对话式探索，"interacting"模式 验证想法、快速试错
Specs What/How 拆分的权威指令 精确定义功能边界与约束
Skills 模块化的"怎么做"知识包 给 agent 装配特定领域能力（如部署流程）
Agents 实际执行规格+技能的引擎 交互式 / IDE集成 / 全自主，三种自主程度可选

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

七、决策框架

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

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

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

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

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

八、参考资料

起源与理论

Harness Engineering

主流工具官方文档

批评与实证数据来源

九、其他说明

篇目 篇名
第一篇（本篇） 第一章：意图与代码之间：AI编程范式全景解读 ✅
第二篇 第二章：Vibe Coding深度实战，基于DeepSeek V4也可以跟Ops4.6掰掰手腕
第三篇 第三章：Spec-Driven Development深度实战，一份好Spec胜过十轮对话
第四篇 第四章：Harness Engineering深度实战，打造AI编码的自动驾驶系统
第五篇 第五章：决策框架与综合案例，找到属于你的AI编程范式最优解
相关推荐
用户34232323763172 小时前
边缘计算与云边协同——当采集不再只是“上传“
后端
壹方秘境2 小时前
ApiCatcher支持抓包HTTP传输大文件的实现原理分享
前端·后端·客户端
一份执念2 小时前
uni-app项目 （vue+vite + uni-UI）中引入umd格式JS文件，微信小程序中导入报错处理方案
前端·uni-app·echarts
神奇小汤圆2 小时前
2026最新·最全·最实用｜Java岗面试真题（已收录GitHub）
后端
神奇小汤圆2 小时前
面试官当场让我手写Java线程安全工具类，我写完直接拿到了35K offer
后端
ClouGence2 小时前
2026 年自动化测试工具选型指南：8 款主流工具对比
前端·测试
lichenyang4533 小时前
为什么需要双线程通信、JavaScriptProxy 和 runJavaScript 分别干什么
前端
以和为贵3 小时前
前端也能搞懂 RAG：用 JS 手写一条最小检索增强链路
前端·人工智能·面试
久美子3 小时前
Qoder 使用指南：从配置到落地
后端
热门推荐
012026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？022026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？03【AI】2026 年具身智能模型和世界模型总结042026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf05Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析06GitHub 镜像站点07【AI总结】2026年6月 主流国内外大模型总结08AI科技热点日报 | 2026年6月1日09AI科技热点日报 | 2026年6月22日10AI一周事件 · 2026-06-03 至 2026-06-09