# 不装插件使用 HARNESS.md

写一份 `HARNESS.md` 要对照规范，读懂一份不用。
所以 [hub](https://hoshiori-dev.github.io/harness.md/zh/hub/) 里的文件，任何编码 Agent 都能用，什么都不必装。

## 存好文件，再说明目标

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

像下面这样说就够了：

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

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

## 建完之后：删掉还是留下

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

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

## 少了什么

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