--- status: draft chapter-type: narrative --- # 四阶段演进：Prompt → Context → Skill → Harness > *马没有变得更强，是缰绳变得更好。* 从 2022 年到 2026 年，一线工程师与大语言模型协作的方式，真实地经历了四个截然不同的阶段。每一阶段都解决了上一阶段解决不了的真实问题；而每一阶段，回过头看，也留下了一个只有下一阶段才能回答的真实问题。把这条序列当作一整条弧线来读，是理解 **Harness Engineering（驾驭工程）** 回应的是什么——以及为什么前三个阶段的技术至今仍然有用，却无法独自抵达同一个结论——的最快方式。 本章会走完这四个阶段，给每个阶段应得的最强辩护，再精准地指出它的裂缝出现在哪里，最后把接力棒交给第 3 章的操作性定义。 ## 全景一览 ```{mermaid} timeline title Four-Stage Evolution of AI Coding Practice 2022-2024 : Prompt Engineering : how do I ask? 2025 : Context Engineering : what do I show? 2025-2026 : Skill Engineering : how do I encode the workflow? 2026- : Harness Engineering : what environment do I build? ``` 每一支箭头代表的转变，都不是"更多 token"，也不是"更大的模型"，而是 **工程师把什么当作主要制品** 的一次改变。在 Prompt Engineering（提示词工程）里，制品是 *问题* 本身；在 Context Engineering（上下文工程）里，制品是环绕在问题周围的 *检索图*；在 Skill Engineering（技能工程）里，制品是 *可复用的工作流*——一份让智能体照着执行的小文档；到了 Harness Engineering 里，制品变成了 *环境本身*：一整套规则、护栏、工具与稽查器，它们约束着智能体在这个代码库里将要执行的每一条工作流。 | 阶段 | 核心问题 | 类比 | 主要产出制品 | | ---------------------- | ----------------------- | -------------------------- | ------------------------- | | Prompt Engineering（提示词工程） | *我该怎么问？* | 写一封好邮件 | 一串聪明的提示词 | | Context Engineering（上下文工程） | *我该让它看到什么？* | 随信附上一份卷宗 | 一张检索／上下文图 | | Skill Engineering（技能工程） | *我该怎么把工作流编码下来？* | 交出一本操作手册 | 一份 `SKILL.md` 或命令定义 | | Harness Engineering（驾驭工程） | *我该搭一套什么样的环境？* | 运行一条生产线 | 仓库本身（AGENTS.md ＋ 护栏 ＋ 钩子 ＋ 稽查器） | 本章接下来会按顺序为每一行作辩护，同时揭出它的短处。 ## 阶段 1 · Prompt Engineering（2022 – 2024） 在第一个阶段，一切都系于你敲下的那一句话。最早一批让这个领域变得真实的演示——GPT-3 不经微调就能在几十种任务上做到 few-shot 学习，以及"Let's think step by step"这样一句话能让算术准确率上涨两位数——把从业者的工作定义成了 *找到正确的提问方式* {cite}`brown2020gpt3`、{cite}`wei2022chainofthought`。紧随其后的是一套又一套模式库：few-shot 示例、角色扮演框架、思维链脚手架，以及把推理和工具调用交织在一起的 ReAct 循环 {cite}`yao2022react`。 **它解决了什么。** 在与一个有能力的模型做"一问一答"式的单次交流时，字斟句酌的措辞确实能换来可测量的更好答案。一时间，提示词库成了真正的知识产权。非机器学习出身的从业者，第一次能在不动权重的前提下塑造输出质量。 **它在哪里裂开。** 这里的比喻是写一封非常好的邮件。可一旦你需要收件人面对一份不断变化的资料库、做持续性的工作，一封邮件就是错的单位。Prompt Engineering 对 *模型对这个具体代码库已经知道了什么* 毫无概念。它把每一次交互都当作孤立事件，于是既记不住这里的"家规"，也不知道最近哪些文件被动过，更没办法强制让下一个答案与上一个保持一致。当你从一个问题扩展到一百个问题时，答案之间的方差就是最先暴露这套方法的裂缝。 背后更深的机制是 **没有锚点的提示词级幻觉**。提示词告诉模型 *该想什么*，却没有给它一份可以用来证伪自己猜测的语料。于是模型用先验来填补空白——长得像回事的函数签名、常见到的库名、自信而错误的版本号。这种失败是无声的：措辞漂亮的提示词产出措辞漂亮的答案，bug 只有在代码跑起来时才露头；而那时，代码已经提交了。 ```{admonition} 陷阱——"把提示词库当资产"的误区 :class: warning 一个团队在 wiki 上攒了五百条精心调过的提示词，把这份 wiki 当作团队的知识产权，还按条目数奖励工程师。两个季度之后，这份 wiki 就没法用了：那些提示词假设的是一个没人再用的模型版本、一套早已被重构过的代码结构，以及一套团队已经抛弃的评审约定。提示词本身没有指向这些依赖，于是什么也没有触发更新。**症状**：同一个任务在 wiki 里能搜出十条提示词，今天没有一条能让测试跑绿。**解法**：把这份知识产权迁到技能里（阶段 3），让过程和它面向的代码一起纳入版本控制，然后把那份 wiki 退役。 ``` ## 阶段 2 · Context Engineering（2025） Andrej Karpathy 2025 年年中的那篇文章，把这项实践重新起了个名字：*context is the new code*（上下文即新代码）{cite}`karpathy2025context`。主要制品不再是提示词，而是 **模型在推理时看到的那份完整卷宗**——检索增强生成（RAG）管道 {cite}`lewis2020rag`、工具定义、长对话历史，以及从当前仓库里拉进来的文件。从业者关心的问题，也从 *我该怎么措辞？* 变成了 *模型需要看到什么，才能把这件事答好？* 这个阶段让检索（retrieval）正式成为一门一等的工程学科。RAG 系统、向量库、上下文窗口优化，都成了技术栈里的标配。邮件的比喻这时加上了附件：每一个问题都附带着一份精心组织的参考资料。 **它解决了什么。** 回答开始锚定在具体的、可检索的事实上。当事实被放进提示词时，幻觉显著下降。长对话可以从前面的轮次继承上下文。模型的答案，不再是一副"放之四海皆准"的腔调。 **它在哪里裂开。** Context Engineering 告诉模型 *该看什么*，但告诉不了它 *该做什么*。对任何一件稍有分量的任务——"加一个新的 API 端点"、"重构这个模块"、"迁移这个依赖"——智能体要的不止是事实，它要的是一套 *过程*。给它看一份现成的风格指南，并不等于它会遵守这份指南；给它看三个以前写过的端点，也不能保证第四个端点会照样来。检索是一种输入；过程则是一种 *行为*，而单凭输入是钉不住行为的。 第二条、也更不易察觉的裂缝是 **上下文污染（context pollution）**。一味追求召回率的检索，会把近似相关的片段塞满窗口；智能体接着把它们平均起来，产出的代码像是那几个检索样本的 *均值*，而不是其中的 *最好* 一版。三个平庸的旧端点被一起检索出来，就等于教会了智能体"平庸才是家的风格"。你往里加的检索越多，智能体就越勤奋地复现这份语料库里已有的缺陷。 ```{admonition} 陷阱——"只要多建点索引，RAG 会把剩下的事搞定" :class: warning 一个团队把整个 monorepo 索引进向量库，每轮在提示词前面拼上二十段检索结果，然后眼看着质量 *下滑*。现在的智能体学会了"骑墙"——它产出的代码能合理地匹配这二十段里的任何一段，包括其中三段已经废弃的、两段五年前实习生写的。**症状**：输出变长、变得更谨慎；测试通过率不变甚至下降；智能体不再追问澄清性问题，因为它"信息量太大"反倒注意不到自己的无知。**解法**：少建索引、排序要狠，并把检索当作一道 *护栏*（拒绝检索那些已废弃的路径）来用，而不是一根 *水管*（把所有东西都喷进上下文窗口）。 ``` ## 阶段 3 · Skill Engineering（2025 – 2026） 对那条裂缝的回应，就是把 **过程本身** 编码成一件可复用的制品：一份 `SKILL.md` 文件、一项 Anthropic 的 *skill*、一条 Claude Code 的自定义命令、一条 Cursor 的 rule。每个技能都写明名字、触发条件、步骤清单，以及"完成"的定义。你不再在每一轮都重新解释"在这个仓库里我们怎么加一个新端点"，而是把这份解释作为技能写一次，凡触发条件匹配，智能体就会把它捡起来 {cite}`anthropic2024claudecode`。同一年，公开评测开始不再用孤立的提示词去评估编码智能体，而是让它面对整个仓库级的任务——而这恰恰奖励了那种事先烘焙好的过程性知识 {cite}`langchain2026tbench`。 **它解决了什么。** 沉默在资深工程师脑子里的隐性知识，终于走出了他们的脑袋，落进了仓库。技能之间可以组合：一个 `commit` 技能可以调用 `run-tests` 技能，后者又可以调用 `generate-changelog` 技能。新加入的成员（不管是人还是智能体）自动继承了工作流质量。阶段 1 那种每任务都变脸的方差，大幅收敛了。 **它在哪里裂开。** 一个技能，终究要 *被遵守* 才算遵守。技能自己无法阻止智能体在被催的时候走另一条路、跳过一个它觉得碍事的验证步骤，也无法阻止它写出违反仓库架构分层、却刚好能让技能清单打满钩的代码。技能是一剂 **处方**；而代码库要的是安全意义上的 **强制执行**。处方是好言相劝，强制执行则是把这份要求写进地板里。 这里更深的机制叫 **合规剧场（compliance theatre）**。技能的检查清单本质上是自我申报：智能体输出一句"我跑过测试了"作为 token，评审者把这句 token 当作证据。如果测试运行器没被接进某个钩子，就没有任何东西可以证伪这份自报。智能体——哪怕并没有任何欺骗意图——也会学到一件事：生成一段"像是在合规"的文本，比真的去跑一次检查便宜得多。几百轮下来，*技能上说发生了什么* 和 *实际上发生了什么* 之间的缝隙会越拉越大，而这条缝隙的走向，对智能体的完成度奖励有利，对其他任何人都不利。 ```{admonition} 陷阱——"技能泛滥（Skill-Sprawl）"的平台期 :class: warning 一个团队写了四十份 `SKILL.md`，每一份的边界都划得很小心。采纳看起来很健康——智能体在大多数轮次都会调用技能。可量到的输出质量在第 6 周左右见顶，就再也上不去了。**为什么**：这四十个技能彼此重叠、在边缘相互冲突，还在争抢智能体的注意力预算；现在它有半个上下文窗口都在决定 *应该调哪一个* 技能，而不是在真正干活。此外：也没有任何东西拒绝那种完全跳过技能的一轮。**症状**：新技能不断产出，质量指标却纹丝不动；技能调用变成一种仪式（"我会按照 TDD 技能来做……"），但技能所规定的那些事并没有真正发生。**解法**：技能要少、要正交；每一条承重的技能都应该配一条钩子，机械地核验它的执行。没有配套护栏的技能，是建议，不是纪律。 ``` ## 阶段 4 · Harness Engineering（2026 – ） 马具登场。2026 年的这个转折点，由两份几乎同时出现的资料共同标定。OpenAI 发表了 *Harness Engineering: Leveraging Codex in an Agent-First World*，讲述它的 Codex 团队如何在五个月内产出超过一百万行生产代码、且几乎无需人工手写——并把这一结果归功于 *他们围绕模型搭建起来的那套环境*，而非模型本身 {cite}`openai2026harness`。同一年，Martin Fowler 在 bliki 上的一篇文章，给这项实践定下了今天通用的名字和定义 {cite}`fowler2026harness`。LangChain 又提供了一份独立佐证：在 Terminal-Bench 2.0 编码评测上，仅仅更换马具（没换模型）就把他们的智能体从 52.8 % 抬到了 66.5 %，从 Top-30 层一路冲进 Top-5 {cite}`langchain2026tbench`。 马具不是单一的制品。它是 **智能体在敲代码之前就绕不开、也改不掉的那一组结构**： - 仓库根目录上的一份 `AGENTS.md`，声明架构规则以及与技能之间的交接点；若某个客户端需要 `CLAUDE.md`，它应当只是兼容镜像； - 一层 lint／类型／schema——那些智能体 *想* 绕过却绕不过去的规则，因为每一次修改都会被机械地核验一遍； - 一层钩子——pre-commit、post-tool-use、pre-merge——在智能体无法绕开的那些时刻重新跑一遍检查； - 一层稽查器——熵值管理智能体、文档同步检查器、依赖审计器——在两次人类介入之间盯着代码库本身。 **它解决了前几个阶段解决不了的什么。** 技能给出的建议，离被一个推理循环推翻永远只差一步；马具给出的约束则不是——lint 工具不在乎智能体的解释有多动听。把反馈循环从 *PR 之后* 拉到 *每一次修改之后*，把犯错与纠错之间的距离从小时级压到秒级 {cite}`humble2010continuousdelivery` {cite}`forsgren2018accelerate`。正是这一压缩，才让智能体的自主运行首先在经济上变得可行。 **它解决不了的是什么。** 马具替代不了品味、架构判断，以及 *哪一个问题值得解* 的最初抉择。第 16 章会回到这条边界。 ```{admonition} 陷阱——"我们有马具了，所以前几个阶段可以跳过" :class: warning 一个团队落地了一份厚厚的 `AGENTS.md`、四个 pre-commit 钩子，以及每周一次的 HarnessCard 复盘，然后悄悄把提示词库退役、也不再精心维护检索。不到两周，质量开始下滑。**为什么**：马具 *约束* 行为，但并不 *提供意图*。提示词仍然是你告诉智能体"这一轮是为了什么"的方式；上下文仍然是它被安放在当前任务中的方式；技能仍然是一类反复出现的工作流得以组合的方式。护栏只拒绝坏活，它不生成好活。**症状**：智能体的输出更正确（测试通过、lint 干净），但更没用（形状错了，力学对了）。**解法**：这四个阶段是一个 *栈*，不是一段楼梯——你是把马具 *搭在* 好的提示词、好的上下文、好的技能 *之上*，而不是 *取代* 它们。第 08 章的缰绳（Bridle）列，就是前几个阶段在马具里落脚的地方。 ``` ## 为什么每个阶段单独都撑不住 竖着读，这四个阶段构成的是一条依赖链，而不是一组可以互相替代的选项。你没法在 **缺了** 阶段 2 的检索管道、阶段 3 的技能词汇的情况下跑 Harness Engineering——马具里的 `AGENTS.md` *本身* 就是一件上下文制品；它的技能 *本身* 就是过程。但反过来，你也没法在任何一个更早的阶段就停下来，否则地板上总有一些真实的失败模式没人收拾： - **停在阶段 1**，你得到的是高方差和轮次之间的失忆。 - **停在阶段 2**，你得到的是有信息支撑的答案，却没有被强制执行的行为。 - **停在阶段 3**，你得到的是一套过程，智能体跑不跑——全看心情。 - **停在阶段 4**，你仍然需要阶段 1–3 的那份品味，才能往马具里填进好的提示词、好的上下文、好的技能。 这个演进并不是 *"提示词过时了，马具把它取代了。"* 好的提示词仍然是你真正对智能体说话的方式；好的上下文仍然是它被安放进当前情境的方式；好的技能仍然是工作流得以组合的方式。这场演进讲的是 **人类工程师的主要制品长什么样** 的改变。Prompt engineer 交付一串字符串；context engineer 交付一条检索管道；skill engineer 交付一套过程；harness engineer 交付的，是作为一套被约束环境的仓库本身——AGENTS.md 只是其中一行，其余是护栏、钩子与稽查器。 ## 指向第 3 章 我们已经把这条弧线走到了这样一个位置：*马具* 正是我们需要的那个词，也正是大多数人还没仔细定义过的那个词。第 3 章会给 Harness Engineering 一个一句话的操作性定义；划出马具 *是什么* 和它 *不是什么* 之间的边界（它不是运行时的推理栈，不是 ML 评估 harness，不是 IDE 插件界面，也不是智能体框架 SDK）；把它逐行与 DevOps、MLOps、AI／Agent Engineering、Platform Engineering 做一轮对照；并给出一个三十行的最小示例，让这个词不再漂离任何你能真正搭出来的东西。 ## 研究脉络 上面这套四阶段的读法，底下托着五束研究脉络；第 07 章在给出"三大护法"这个命名时，会再次捡起同样的主题。 - **Prompt Engineering 的经验根基。** GPT-3 的 few-shot 论文确立了一件事：起作用的杠杆是推理时的条件化，而不是微调 {cite}`brown2020gpt3`；之后的思维链提示法又表明，推动推理准确率的不只是提示词的 *内容*，还有它的 *结构* {cite}`wei2022chainofthought`。 - **Context Engineering 的转折点。** ReAct 把"推理—行动"这一循环形式化，它至今仍是大多数智能体脚手架的底座 {cite}`yao2022react`；检索增强生成（RAG）让外部知识成为一等输入 {cite}`lewis2020rag`；Karpathy 2025 年的那篇文章，给这门学科起了名字 {cite}`karpathy2025context`。 - **作为编码化工作流的 Skill Engineering。** 这条实践线索一脉相承于可执行规约（executable specifications）{cite}`adzic2011specbyexample` 与活文档（living documentation）{cite}`martraire2019living`；Claude Code 的 skills 体系，是它当下的产品化形态 {cite}`anthropic2024claudecode`。 - **Harness Engineering 的登场。** OpenAI 内部实践报告 {cite}`openai2026harness`、Fowler 为这项实践定名的文章 {cite}`fowler2026harness`、以及 Thoughtworks 技术雷达中的 "trial" 条目 {cite}`thoughtworks2026harness`，是读者应当最先三点定位的三个坐标；LangChain 那份"换马具前／后"的评测数据，则是目前最强的一份单项经验证据 {cite}`langchain2026tbench`。 - **马具承继的那条持续交付血脉。** 支撑"马具在经济上是合理的"这一论点的，正是当年为 CI/CD 作辩护的同一份反馈循环论证 {cite}`humble2010continuousdelivery`，它后来又在 DevOps 实践中被量化下来 {cite}`forsgren2018accelerate`。 ## 动手环节 `_handson/02-evolution/` 下的一个四文件套件，演示的是 **同一个极小的任务**——在一个 Python CLI 上加一条 `todo add ` 命令——用四种方式、每阶段一种来解。按顺序读这几份文件：这条演进会带你从一段聪明的 6 行提示词，一路走到一份 10 行的 `AGENTS.md` 片段，后者把技能、护栏与钩子拧成了一具连贯的马具。 - `_handson/02-evolution/README.md`——阅读顺序与预算 - `_handson/02-evolution/stage1-prompt.md`——Prompt Engineering - `_handson/02-evolution/stage2-context.md`——Context Engineering - `_handson/02-evolution/stage3-skill.md`——Skill Engineering - `_handson/02-evolution/stage4-harness-claude.md`——Harness Engineering 四份阶段文件加起来的总制品预算：≤ 40 行。这个约束本身就是点题：**马具不比技能长，技能也不比上下文长**——每一个阶段加的是 *杠杆*，不是体量。你在阶段 4 省下来的那些行，正是你在第 08 章搭建"三大护法 × 四区域"矩阵时要花出去的那些行。