在真正讲“第一步怎么搭 Harness”之前，我觉得有必要先把 JK Launcher 这个项目本身说清楚。因为如果读者连这个项目是什么、解决什么问题、复杂度大概在哪个层级都不知道，后面就很容易把我们的方法误解成一套“只有大工程才需要”的复杂仪式。
2.1 工程画像：JK Launcher 在做什么
下面三张截屏来自真实运行中的 JK Launcher V3（小白模式），便于把「工具体长什么样、日常在管什么」落到可视层面。
项目工程：主工作台 — 快速入门与状态条、SVN/路径与平台配置、更新与打开 Unity 等主操作、底部日志区。
工程修复工具箱：按修复项展示风险等级，支持预检与执行修复，右侧为检测日志 —— 对应冲突扫描、工作副本、误改恢复等工程维护场景。（特别补充一点，这个功能是我使用完整版Harness一次就直接完成的，完成度相当高，大家也可以通过这个功能了解到本篇文章中构建的Harness究竟最终的效果是怎么样的）
设置：可开启小白模式（隐藏高级功能），以及智能建议、悬停详细说明、操作结果摘要等显示相关选项。
JK Launcher 本质上是一个面向 Unity 项目研发流程的桌面启动器工具。它不是一个单一功能的小工具，而是一整套围绕日常研发高频动作搭起来的工作台，核心在于把那些原本零散、容易出错、依赖经验的操作，统一收进一个稳定的桌面端入口里。它要处理的事情并不简单，比如：
工程更新 打开和关闭 Unity SVN 环境检测与权限检查 冲突检测与冲突修复 定时更新和批量更新 更新失败后的诊断与恢复 多语言界面 日志、遥测、状态反馈
如果你看它最近几个月的演进，会发现它已经不是“一个带按钮的启动器”这么简单了，而是一个不断往研发真实场景贴近的工程工具：有修复工具箱，有环境自检，有消息中心，有定时任务，有 Library 预热，有更细的错误分类和更完整的引导体验。这种项目特别适合作为 Harness 的样本，因为它同时具备几个特征：
功能持续迭代
既有 UI，又有服务和状态逻辑
既要工程正确性，也要用户体验
既要能改代码，也要能长期维护
技术上，它的主体是一套典型的 Windows 桌面应用技术栈：以 WPF 为界面基础，以 .NET Framework 为主要运行时，围绕本地工程管理、SVN 协作、配置、状态、更新、日志、多语言等能力不断扩展。也正因为它既有前端交互、又有工程逻辑、又有环境和流程问题，所以它特别适合拿来验证一套 Harness 到底能不能撑住复杂项目。
2.2 人搭 Harness，AI 写代码
还有一点，我觉得必须提前告诉读者： 这个工具在持续演进的过程中，真正的代码实现工作是完全由 AI 去完成的，人没有亲手写过一行代码。
人做的事情是什么？不是下场补代码，也不是在 AI 后面当“高级打字员”，而是一步一步把 Harness Engineering 搭起来：
先把需求和设计说透
再补上规则
再把固定流程做成 Skill
再拆出多 Agent
再补上脚本门禁和事后验证
再补项目地图、任务看板和流程定义文件
也就是说，这个项目不是先有一个成熟团队在写代码，再把 AI 当辅助工具接进来；恰恰相反，我们是在搭建 Harness 的过程中，逐渐让 AI 从能做小任务，走到能做复杂任务，再走到能持续维护整个项目。
2.3 从设计规格文档（SPEC）开始
所以这一章真正想回答的问题，不是“我们为什么要写设计规格文档”，而是：
当你面对的是一个真实、持续迭代、并且完全交给 AI 去实现和维护的工程时，你应该先从哪一步开始搭这个系统。
很多人一听到 Harness，就想先写 Rule、先拆 Agent、先上脚本。但如果你一开始连“这个工程到底想怎么开发、最终想交付什么样的东西”都没有说清楚，那后面所有约束都会变成无源之水。
所以我们真正的第一步，不是写 Rule，而是先把一个比较完整的设计规格文档和 AI 反复磨透。
在 JK Launcher 这个工程里，我们最早就是先磨出了一份比较完整的版本设计规格文档，它承担的就是这个作用。
这类文档的意义，不是为了“文档看起来专业”，而是为了在项目一开始就把下面这些问题谈清楚：
这个版本到底要解决什么问题
哪些问题是核心目标，哪些只是顺手优化
改动会影响哪些模块
哪些行为必须保持兼容
最终什么样才算做完
我自己在这一步通常会和 AI 来回聊很多轮，甚至聊到有点烦。因为这一轮你偷懒，后面会用十倍时间还回来。
这些来回不只是在改文档措辞，也是我们和 AI 共同加深对需求本身的理解的过程。有时一开始连自己都不确定想要什么，不妨把 AI 拉进需求讨论里，让它帮着追问、掰开选项——真正的需求常常就是在这样的来回里被挖出来的，而不是第一版就写死在纸上。
最终的SPEC长什么样？它必须清晰的写明你的所有需求，指明必要的边界条件（后面的需求分析agent会帮你补充 剩下的边界条件），必须没有任何不确定的词语，例如：建议，可以，推荐，可选等字样。
但很快我就发现，只靠这份文档，AI 还是会出问题。
问题不在于它看不懂文档，而在于：
1. 它不会百分之百按文档执行2. 它做完以后，你很难知道它现在到底做到哪了
3. 很多错误它会反复犯
比如它会：
按自己理解跳过一些看起来“没那么重要”的细节
做完之后告诉你“都完成了”，但你仔细一看其实漏了 某个以前犯过的错，下一次又犯一遍
到这里我才真正意识到： 仅有规格设计文档（SPEC），只能解决“知道做什么”的问题，解决不了“如何稳定地做到位”的问题。
于是我们才进入下一步：给 AI 上 Rule。