HARNESS.md

不装插件使用 HARNESS.md

写一份 HARNESS.md 要对照规范，读懂一份不用。 所以 hub 里的文件，任何编码 Agent 都能用，什么都不必装。

存好文件，再说明目标

  1. 在 hub 里挑一个条目，下载文件，或者复制全文。
  2. 存为项目根目录下的 HARNESS.md。
  3. 告诉编码 Agent 这个项目要做什么，让它按文件的描述把 harness 建出来。

像下面这样说就够了：

这个项目是一个命令行工具，用来在两块硬盘之间同步照片库。请阅读仓库
根目录下的 HARNESS.md，为这个项目建出它描述的 Agent harness。文件里的
Context 一节是为别的项目写的：先把它改成这个项目的情况，在创建任何文件
之前告诉我你改了什么。

最后一句不能省。hub 条目带着原作者的 Context： 改坏的代价有多大，项目要维护多久，有没有人盯着 Agent 干活。 你的项目总会有几处不一样，所以要看哪些章节的理由建立在原来的 Context 上， 把它们重新过一遍。

建完之后：删掉还是留下

harness 建好之后有两种选择，格式不偏向哪一种。

  • 删掉文件。 它是一份模板，用完了。
  • 留作锚定文档。 把它长期留在仓库里，作为项目的设计记录，很少改动。 如果 Agent 还没有按你的项目重写 Context，现在把它改过来。 Agent 几乎不应该加载这份文件； 检查 harness 有没有漂移或者打算改进 harness 的时候再打开。 产物（实现设计的文件）与设计不一致时，只要文件没有改口，错的就是产物： 要么修产物，要么修订文件。至于事实，比如一条命令实际做什么、一个路径是否存在， 以代码为准。

少了什么

不装插件，Agent 靠的是这份文件和它自己的判断。 你少了校验器，少了那些知道每一层怎样设计、怎样建、怎样检查的 skill， 也少了构建之后在干净的上下文里把新文件重读一遍这一步。 对小项目来说，这笔交换往往划算。想手工检查文件格式的话， 规范的最后一节列出了校验器会报告的全部内容。