Harness Engineering 入门概览
上一篇我们拆解了 Harness Engineering 的知识图谱，建立了全局框架。今天这篇是整个系列真正的起点——如果你只能读一篇，读这篇。
它不是手册，不是教程。它是一张鸟瞰图：让你站在高处，看清楚这个领域的来龙去脉、核心问题、解决思路和工具生态。读完之后，你再去看任何具体内容，都能知道它在整张图上的位置。
01 | 起源：从 Vibe Coding 到 Spec Coding
要理解 Harness Engineering 为什么出现，先要理解它在反对什么。
Vibe Coding 时代（2023-2024）
ChatGPT 引爆 AI 编程后的两年，大家都在搞「氛围编程」——打开聊天框，凭直觉描述需求，AI 凭直觉生成代码，开发者凭感觉判断对错。
这种方式有它的魔力：启动成本极低，简单需求几分钟出结果，原型验证效率极高。
但当你试图用它做真正的工程时，五个问题接连暴露：
| 问题 | 典型表现 |
|---|---|
| 不可控 | 同样的需求，AI 每次生成的代码都不一样 |
| 不一致 | 同类规范在不同会话中产生分歧 |
| 不可重现 | 出 bug 后无法复盘「AI 当时是怎么想的」 |
| 不可协作 | 多人各自和 AI 对话，方案五花八门 |
| 不可演进 | 一段时间后，连 AI 自己都不认识自己写的代码 |
更深层的问题是：AI 生成的代码看起来像工程产物，但创造它的过程不是工程过程。
业界的选择
2024 年底，业界开始问一个根本问题：我们要的是 AI替代软件工程师，还是 AI增强软件工程师？
「增强」路线赢了。理由很现实：企业合规审计是硬条件，多人协作不可能各自 vibe，生产系统不允许「运气好」。
于是从 2025 年开始，业界系统性地在 AI 周围搭建工程化基础设施：
- 2025 年初：GitHub 发布 Spec-Kit
- 2025 年中：fission-ai 发布 OpenSpec，Anthropic 发布原生支持 Sub-Agent 的 Claude Code
- 2025 年下半年：GSD、ECC、Trellis 等工具方法论涌现
这个潮流有三个名字：Spec-Driven Development（规范驱动开发）、Spec Coding、Harness Engineering（最广义的称呼）。
02 | 什么是 Harness Engineering？
Harness 这个词本意是「缰绳/挽具」——用来约束和引导马的工具。约束不是为了削弱，而是为了聚焦。河水四处流动什么都干不了，修了堤坝才能发电。
完整定义：
Harness Engineering 是一种 AI 编程时代的工程方法论，通过结构化文档、阶段化流程、原子化任务三大策略，约束和引导 AI 编码代理的行为，使其产出符合软件工程标准的可靠成果。
与传统工程的本质区别，一张表说清楚：
| 维度 | 传统软件工程 | Harness Engineering |
|---|---|---|
| 协作主体 | 人 ↔ 人 | 人 ↔ AI ↔ 人 |
| 真相源 | 代码 + 文档 | 代码 + 文档 + AI 上下文 |
| 决策载体 | 会议 + 评审 + ADR | 文件 + 流程 + 命令 |
| 核心矛盾 | 复杂度管理 | 复杂度管理 + AI 不可控性 |
最关键的差异：传统工程只面对人的不可靠，Harness 同时面对人和 AI 的不可靠——而且两者的不可靠模式完全不同。
03 | 核心问题：Context Rot 深度解析
Harness Engineering 要解决的核心问题叫Context Rot（上下文腐烂）：
LLM 在长上下文或多轮对话中，输出质量随时间和信息累积而退化的现象。
三大成因：
成因一：上下文窗口有限
Claude Sonnet 200K tokens、GPT-4 128K tokens——这不是核心问题，核心问题在后两条。
成因二：注意力机制稀释
Transformer 的 self-attention 是 O(n²) 复杂度。上下文越长，每对 token 间的注意力权重越小，关键信息被淹没。
Stanford/Berkeley 2023 年论文《Lost in the Middle》证明：模型对长上下文中部信息的召回率呈 U 型分布——开头和结尾召回率高，中间显著低。
成因三：累积污染
多轮对话中，每轮的错误尝试、中间产物、推翻重来的内容都留在上下文里，挤占关键信息的注意力空间。
症状都很隐蔽：「明明说过用 PostgreSQL，怎么写出 MongoDB 代码了？」「明明已经实现的功能又实现了一次。」「会话前期质量很高，后期突然变差。」——这些不是 AI 今天状态不好，是 Context Rot 的标准症状。
为什么「更长上下文」不是解药？
窗口从 200K 变成 1M，注意力稀释依然存在；推理成本随 token 数超线性增长；信息越多未必决策越好，给 AI 100 份 spec，效果可能不如精选的 5 份。
Harness 的解法不是扩大上下文，而是绕过这个问题：
- 决策外化为文件（空间维度）：信息存在文件系统，按需加载
- 流程结构化为阶段（时间维度）：每阶段聚焦单一决策，避免多目标污染
- 任务原子化为单元（资源维度）：每个任务在干净上下文中独立执行
04 | 核心概念速查
这里列出整个系列里最常出现的 10 个概念，先有印象，后续文章会逐一深入：
Spec-Driven Development（SDD，规范驱动开发）：先写规范再写代码。规范不是事后注释，而是事前约束——AI 必须严格按规范实现。代表框架：Spec-Kit、OpenSpec。
Context Engineering（上下文工程）：主动管理 LLM 上下文窗口的技术，决定什么信息进入、何时清理、如何在多个实例间分配。区别于 Prompt Engineering：前者关注「怎么问」，后者关注「AI 知道什么」。
Constitution（项目宪法）：项目级不可妥协的全局约束文件，每个新会话开始时自动加载，包含技术栈规定、编码规范、安全底线。
Delta Spec（增量规范）：OpenSpec 的核心概念，每次变更只描述差异（ADDED / MODIFIED / REMOVED），而非重新描述完整状态。类比：需求层级的 Git diff。
Sub-Agent（子代理）：主代理启动的、运行在独立上下文中的子任务执行单元。价值：上下文隔离 + 单一职责 + 可并行。
Wave Execution（波次执行）：GSD 的核心调度模型，把任务依赖图（DAG）分析后，无依赖的任务分波次并行执行。理论上把 O(N) 串行时间压缩到关键路径长度。
Hooks（钩子）：事件驱动的自动化触发器。PreCommit、PostEdit、SessionStart 等事件发生时自动执行预定脚本，把「应该做但容易忘」的事变成自动化。
ADR（架构决策记录）：把每个架构决策的动机、选项、影响记录为独立文档。Harness 里的 proposal.md 本质是 AI 时代的 ADR。
Lost in the Middle：LLM 对长上下文中部信息召回率显著下降的现象，Context Rot 的核心理论根源。
Goal-Backward Verification（目标倒推验证）：GSD 的验证方法，从用户视角倒推，而非从实现细节验证。区别：「登录函数返回了 token」✅ vs「用户能否登录后访问主页」❌（发现 token 没存到 cookie）。
05 | 框架生态全景
四大框架家族，每个解决不同维度的问题：
规范驱动（SDD）— 决策外化的主战场
- Spec-Kit：五阶段、Constitution + 全量 Spec、绿地项目首选
- OpenSpec：三阶段、Delta Spec 增量规范、棕地项目首选 ⭐
- Kiro（AWS）：IDE 原生集成
上下文工程— 对抗 Context Rot 的极致代表
- GSD：波次执行 + Goal-Backward 验证，任务原子化的最佳实践 ⭐
能力增强— 给 AI 装「外挂」
- ECC：48 个 Agents + 182 个 Skills + 红蓝队审计机制 ⭐
- OMC：19 个团队代理，零配置开箱即用
编排协作— 多框架协同
经典组合：规范层（OpenSpec）+ 执行层（GSD）+ 能力层（ECC）= 做什么 + 怎么做 + 用什么做
06 | 演进史：从 Prompt Engineering 到 Harness Engineering
理解 Harness 最好的方式，是把它放进演进史里：
阶段一：Prompt Engineering（2022-2023）——怎么问
Few-shot、思维链、角色扮演……聚焦单轮交互，不解决多人长期协作问题。
阶段二：Context Engineering（2024）——AI 知道什么
动态上下文加载（RAG）、上下文压缩、Multi-Agent……把「上下文」作为第一类对象设计，但仍不关注与人类工程实践（Git、CI、Code Review）的整合。
阶段三：Harness Engineering（2025 至今）——AI 怎么工作
决策外化 + 流程阶段化 + 任务原子化，与 Git/CI 深度集成，形成完整方法论体系。
每个阶段都包含前一个阶段。学 Harness 不意味着抛弃 Prompt Engineering——你仍然需要会写好的 prompt。但只会写 prompt，解决不了多人长期项目的协作问题。
总结
- Harness Engineering 的诞生是必然：Vibe Coding 的五大问题（不可控、不一致、不可重现、不可协作、不可演进）推动业界转向工程化路线
- Context Rot 是核心矛盾：不是 AI 不够聪明，是长上下文下的注意力稀释和累积污染——更长的窗口解决不了这个问题
- 三大原理是解法基石：决策外化（空间）+ 流程阶段化（时间）+ 任务原子化（资源），三者协同才是完整的 Harness
- 四大框架家族各司其职：SDD 管规范、上下文工程管执行、能力增强管工具、编排框架管协同，经典组合是 OpenSpec + GSD + ECC
- 这是一个演进中的领域：Prompt Engineering → Context Engineering → Harness Engineering，每一步都是对前一步的包含和超越
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
