Harness Engineering 的概念已经火了有一阵了，全网很多文章基本都是在讲理念，讲为什么今天做 AI 开发，不能只靠一段提示词，也不能把模型当一个“更聪明的代码补全”。但与此同时，一个问题也在持续地发酵：
理念我理解了，可是真正落到工程里，我第一步到底该做什么？
这个问题特别重要。因为 Harness 这个词听上去很大，很像一个抽象的方法论，但它如果不能落到工程、目录、文档、脚本、工作流里，那它最后就只是一句漂亮的话。事实上，不同项目落地出来的 Harness，表面上可能完全不一样。有的项目是 CI 很强，有的项目是规范很强，有的项目是多 Agent 很强，有的项目甚至只是把几个脚本和模板整理得非常扎实。但如果你往下挖，会发现它们解决的其实都是同一个问题：
如何让 AI 在你的项目里，持续、稳定、规范、顺畅地做出你真正想要的结果。
这一篇我就不再谈泛泛而论的“AI 很重要”“工程化很重要”。我只做一件事：拿 JK Launcher 这个真实工程做例子，把我们这一路是怎么一步一步把 Harness 搭出来的，原原本本讲清楚。哪些地方有效，哪些地方踩坑，哪些东西一开始以为够用，后来发现完全不够，都会写出来。你看完以后，不一定要完全照抄，但至少会知道：如果你也想在自己的项目里从 0 开始搭 Harness Engineering，第一步该做什么，后面又该按什么顺序逐步补齐。
我将整个搭建流程细细拆解，每一个步骤都拆散揉碎了，尽可能的将所有内容都明明白白的写出来，本篇我保证一定值得大家反复细读，当然，以下所有论点都是我的一家之言，不一定对，抛出来也是希望大家一起讨论。
为方便大家阅读，在此提前预警一下，本篇文章字数非常多，一共分为12章，要想细读建议留足至少半小时的时间，建议大家时间不够的话可以先收藏。
很多人一上来就开始写 Rule、搞 Agent、接 MCP，最后越做越乱，根本原因不是执行力不够，而是概念没分清楚。下面这些词，在我们这个工程里都会反复出现。如果这几个概念混在一起，后面就很难搭得稳。
先把这几个概念压成一张速览表，会更容易建立整体印象：
1.1 Rule 是什么
Rule 可以理解成你给 AI 写的一套“工程规矩”。
它不是需求文档，也不是设计方案，更不是脚本。它更像是你在带一个新人开发时，先告诉他的那些基础原则： 什么能做，什么不能做； 什么做完必须验证； 什么约定绝对不能绕过去。
比如在我们工程里，有一类专门约束“改完代码以后必须完成编译、测试和事后验证”的 Rule，本质上就是在告诉 AI：
你改完代码以后，不能只说“我改好了” | 你必须去编译 |
你必须去跑测试 | 你必须去做事后验证 |
三步不全过，这次开发就不算完成 |
所以 Rule 的核心作用，不是帮助 AI “变聪明”，而是帮助 AI 少犯一些本来不该反复犯的低级错误。
Rule 更像一个团队的“研发制度”。制度不是拿来创造价值的，制度是拿来减少混乱的。
但这里有个很重要的前提：Rule 只是软约束，不是硬门禁。
什么意思？就是 AI 理论上应该遵守它，但它并不一定真的每次都遵守。尤其当 Rule 越来越多、需求越来越复杂的时候，模型会出现三种典型情况：
它忘了某条 Rule
它觉得某条 Rule 和这次需求“无关”
它知道这条 Rule，但偷懒没做，还给自己找理由
所以 Rule 非常重要，但 Rule 不能解决所有问题。
1.2 MCP 是什么
MCP（Model Context Protocol）本质上是一种标准方式：把「仓库之外的能力」接进 AI 的工作链路里——既能拉取信息，也能在明确边界内触发外部系统的动作。
你可以把它理解成一层可编排的接口：AI 不再只依赖当前对话和本地代码，还能对接 Wiki、知识库、表格、各类平台 API；在 Unity 工程这类场景里，还可以对接 Unity Editor / 工程宿主里的工具能力（例如编译、场景与资产、日志与状态、受控命令等），把「写出来的代码」和「编辑器里正在发生的事」对齐起来。
这也就解释了，为什么当你想把 Harness 从「开发闭环」推到「工程交付闭环」时，MCP 往往会变得关键：交付链路里大量是 CI、签名、制品、发布、回写状态 等系统能力，它们都不是「只在仓库里多写几行脚本」就能替代的。
先看能力边界。没有 MCP 时，AI 通常仍被锁在：
本地代码仓库
本地脚本
当前对话上下文
它能分析、能改代码、能跑本地验证，但很难安全、结构化、可审计地接入更外层的工程系统。
反过来，如果你要把闭环做完整，迟早会碰到下面这类动作（只列常见的几种）：
调用 CI 平台发起构建
读取构建日志和构建结果
调用签名服务给安装包或可执行文件签名
上传制品到制品库或发布平台
调用发布系统做灰度、提审、发布
回写发布状态、版本号、交付记录
它们的共性是：需要让 AI 在可控边界里调用系统能力，而不是把凭据和即兴命令散落在对话里。MCP 正是这类能力的连接层：把外部系统以 Tool / 资源的形式暴露给 AI，便于被 Rule、Workflow、Scripts 一起约束。
所以在我们的整体拼图里，MCP 不是 Harness 的主体，而是 Harness 的外接能力接口——接什么、接到多细、何时允许接，本身也要被制度与门禁管住。
如果 Rule 像制度，Skill 像操作手册，Scripts 像闸机，那么 MCP 更像把 AI 接进更大工程系统的标准插座。在当前阶段它也许还是辅助；但当你希望 AI 不只改代码，还要稳定参与构建、签名、制品、发布、回写状态时，这一层往往会越来越「决定性」。
1.3 Skill 是什么
Skill 是我特别推荐所有团队早点引入的东西。
它本质上是在告诉 AI：有些事情你不要临场发挥，不要每次重新理解，也不要自己“猜一个大概的流程”，而是严格按照这套固定步骤执行。
比如编译这件事。你说“你去编译一下”，AI 可能自己拼一条命令。表面看没问题，但实际工程里，编译往往不是一句 dotnet build 那么简单，可能涉及：
要找对 MSBuild | 要用固定的配置 |
要先还原 | 要把日志输出到指定文件 |
编译完以后还要看错误模式 |
这些东西如果每次都让 AI 自由发挥，迟早出问题。
所以我们把编译做成了 Skill，把测试做成了 Skill，把事后验证也做成了 Skill。这样每次 AI 走到这一环，它不是“想办法完成”，而是“按剧本完成”。
它很像给 AI 写的一份标准操作手册。Rule 告诉 AI “这件事必须做”，Skill 告诉 AI “这件事具体应该怎么做”。
1.4 Sub Agent 是什么
Sub Agent 就是多个“分工明确的 AI 角色”。
很多人一开始用 AI，默认是一个 Agent 干到底：分析需求、设计方案、写代码、审代码、写测试、做总结全都它来。短任务时这没问题，但只要任务一复杂，问题马上就会出现：
它会自己给自己做需求解释 | 它会自己给自己的方案打分 |
它会自己写代码、自己说自己没问题 | 它会天然更倾向于“推进任务继续进行”，而不是“停下来承认当前有问题” |
这和真实的软件研发其实完全一样。一个人既做产品、又做架构、又做开发、又做 QA，最后质量一定很难收口。
所以我们后来引入了多个 Sub Agent，把不同阶段拆开。每个 Agent 只负责自己那一段，把产出写进文档，然后交给下一个 Agent。
放到真实研发里，Sub Agent 就像项目组里的一组人：
需求分析的人只管把需求说清楚 | 方案设计的人只管把技术方案做完整 | 闸门的人专门负责判断“这东西能不能进开发” |
开发的人只管实现 | 代码审查和测试的人负责收口 | PM 只负责流程 |
这个思路其实非常朴素，不是什么新发明，但它对 AI 特别有效。
1.5 Workflow 是什么
Workflow 不是“写了几个 Agent”那么简单。 如果只写了几个 Agent，而没有 Workflow，那其实只是“有几个人在干活”，还谈不上“有一套稳定可复用的协作方式”。
我觉得 Workflow 最形象的理解方式，不是流程图，而是接力赛规则。
接力赛最重要的，不是有四个跑得快的人，而是下面这些事情必须先说清楚：
第一棒是谁跑 | 第二棒什么时候能接棒 |
接棒的时候必须交什么 | 哪种情况算犯规 |
犯规以后是重跑、罚时，还是直接取消成绩 |
放到工程里其实一模一样。 你有需求分析、方案设计、开发、测试这些角色，只代表你“有人”。 但只有当你把下面这些东西明确下来，Workflow 才真正成立：
当前任务现在处于哪个阶段 | 这个阶段的产出是什么 | 谁可以接下一棒 |
下一棒接手前必须看到什么文档 | 哪些问题一旦出现，流程必须打回 | 打回以后回到谁那里，改完以后从哪一棒重新开始 |
如果没有 Workflow，工程现场通常会变成下面这种状态：
需求不清楚，方案设计直接自己改需求 | 方案有问题，开发硬着头皮继续做 |
测试发现阻塞问题，PM 为了赶进度想办法往下推 | 某个阶段明明应该打回，但没人说得清到底该打回给谁 |
大家都在做事，但最后没人能说清楚“这件事现在到底算做到哪了” |
所以 Workflow 的核心不是“有一张图”，而是让每一次前进、暂停、打回、重跑都有明确依据。
在我们工程里，这套 Workflow 最后被拆成了三层：
一层写给人看，告诉大家这条研发链路整体怎么走
一层写给系统看，把阶段和迁移边固定下来 一层写给具体角色看，明确每个角色接棒时该读什么、交棒时该写什么
这三层合起来，才构成一个真正能长期维护的 Workflow。 否则你以为你搭的是流程，实际上搭出来的往往只是几段漂亮的提示词。
和「接力」配套的还有一条上下文纪律：每一棒只给当前该看的那一份材料。不是要瞒信息，而是避免一上来把规则、地图、任务历史全堆给 AI——上下文越长，重点反而越散。所以我们会有意让 Rule 慢慢长、让 dev-map 与任务看板等「项目级视野」晚一点再上；这和 Workflow 拆阶段、Sub Agent 各看一截文档，其实是同一条思路。
1.6 Scripts 是什么
Scripts 是整个 Harness 里最“硬”的东西。
如果说 Rule 只是告诉 AI 应该怎么做，Skill 只是给 AI 标准步骤，那 Scripts 就是在说： 你说你做完了没用，得跑过我这关才算。
这也是为什么我越来越觉得，真正成熟的 Harness，最后一定会越来越依赖脚本，而不是越来越依赖提示词。
在我们工程里，就有一个典型的“总门禁脚本”。它把很多原本散落在 Rule 里的东西，真正落到了可执行的检查上。比如：
XAML 里有没有中文 | 有没有 Emoji | 有没有用 C# 8 以上语法 |
有没有直接写 | 有没有硬编码 UI 文案 | 日志格式对不对 |
有没有直接访问 | SVN 认证参数是不是合规 | 文件是不是超长 |
本地化有没有违规 | 主工程编译是否通过 | 测试是否通过 |
测试数量有没有异常减少 | 规则文件是不是四处同步 |
|
当这些东西被做成脚本以后，AI 就很难再拿“我觉得没问题”来糊弄过去了。
1.7 先把前面的几个概念串起来
前面这一章其实已经把后面会反复出现的几个核心零件都讲完了。 如果你是第一次接触这套东西，先不要急着往下看，最好先在脑子里把它们快速过一遍：
Rule：告诉 AI 什么是规矩 | Skill：告诉 AI 规矩里的固定动作怎么做 | Scripts：不是告诉 AI，而是直接检查它做没做到 |
MCP：让 AI 接上外部知识和工具 | Sub Agent：把一个大任务拆成多个角色协作 | Workflow：规定这些角色在什么阶段、按照什么顺序协作 |
这几个东西不是互相替代的，而是逐层叠加的。
你也可以这样理解：
Rule 负责告诉 AI 什么是底线 | Skill 负责把高频动作标准化 | Scripts 负责判断结果到底对不对 |
Sub Agent 负责把复杂任务拆成多个专业角色 | Workflow 负责让这些角色能按顺序接力 | MCP 负责把这套系统继续往外部工程系统延伸 |
也就是说，到这里为止，你看到的还只是 Harness 的一堆“零件”。 而接下来要讲的，才是最关键的一步：
这些零件为什么拼在一起以后，会变成一整套 Harness Engineering。
1.8 什么是 Harness Engineering，以及它在我们工程里的全貌
如果前面那些概念你都看完了，这里其实就可以把它们串起来了。
我自己现在对 Harness Engineering 的理解很简单：
它不是某一个工具，也不是某一条提示词技巧，而是一整套让 AI 在工程里稳定产出正确结果的工程系统。
注意这里有三个关键词：
稳定 不是这次运气好做对了，而是下次、下下次、换个需求、换个维护人，它仍然能比较稳定地工作 | 产出 不只是写代码，还包括需求、方案、验证、交付等完整过程产物 | 正确结果 不是“做完了就算”，而是最终要有办法判断它到底做得对不对 |
所以在我看来，Harness Engineering 真正解决的不是“怎么让 AI 更聪明”，而是下面这件事：
怎么把 AI 从一个会临场发挥的模型，变成一个在工程里可约束、可协作、可校验、可持续维护的执行系统。
如果把我们当前工程里的 Harness 全貌摊开来看，它大致已经长成了下面这样：
1 设计规格文档 先把需求目标、边界、版本意图说透。它解决的是“AI 到底要做什么”。 | 2 Rule 把基础规矩和底线写死。它解决的是“哪些事情绝对不能乱来”。 | 3 Skill 把编译、测试、验证这类固定动作标准化。它解决的是“关键流程不要靠临场发挥”。 |
4 Sub Agent 把不同阶段拆成不同角色。它解决的是“不要让一个 Agent 既做需求、又做方案、又做开发、还自己审自己”。 | 5 Workflow 把这些角色怎么接力、什么时候前进、什么时候打回说清楚。它解决的是“多人格协作不能靠现场拍脑袋”。 | 6 Scripts / 事后验证 把很多约束真正落成可执行检查。它解决的是“不是做完了就行，而是要知道做得对不对”。 |
7 开发导航地图（dev-map） 让 AI 快速理解项目结构和既有模式。它解决的是“不要一进项目就重复造轮子”。 | 8 任务看板 让 PM 和需求分析知道项目历史和当前进展。它解决的是“不要只盯当前需求，忽略整个项目上下文”。 | 9 MCP 它现在还不是我们这套 Harness 的主干，但如果将来要把闭环延伸到构建、签名、制品、发布这些外部工程系统，MCP 会成为非常关键的一层连接能力。 |
如果非要打个比方，我会说：
Harness Engineering 就像是在给 AI 搭一整套“工程作战系统”。 规格设计文档（SPEC）是作战目标，Rule 是纪律，Skill 是标准动作，Sub Agent 是兵种分工，Workflow 是指挥链，Scripts 是验收和反馈闭环，开发导航地图（dev-map） 和任务看板则提供地图和战场态势（这两个概念将会在第九章进行详细的阐述）。
这些东西单独看都不稀奇，真正有价值的是：它们组合起来以后，AI 才第一次像是在一个真实工程里工作，而不是只是在聊天窗口里表现得很聪明。