项目 Harness 的三件事：读对、拦住、接得上
把常错的地方固化成约束，而不是反复骂 AI。项目 Harness 就管三件事：读对、拦住、接得上。
同样一句需求，项目上下文配得好的人和配得差的人，甚至用同一个 AI，产出都天差地别。差距不打在模型上，打在「项目是否给 AI 搭好了底子」——这就是项目 Harness。
读完你能回答：
- 项目 Harness 到底管什么？
- 「读对」「拦住」「接得上」各指什么？
- 为什么「把 prompt 写得更严厉」不能当你拦住 AI 的方法？
什么是项目 Harness
项目 Harness，说白了是你项目里那套帮 AI「读对、拦住、接得上」的配置与工具：规则文件、目录结构、脚本、检查，以及这些是如何组织起来的。它决定 AI 在你的项目里能干多好，而不被「模型本身」限制住。
三件事拆开看
① 读对（可信上下文） 让 AI 能拿到关于你项目的可靠信息，而不是猜。
- AGENTS 规则文件：目录、结构、约定
- 相关文档 / README / 代码范例
- 别给错的：告诉它 source-of-truth 在哪、以哪个为准
② 拦住（可执行约束） 把「反复发生的问题」变成 AI 绕不过去的约束，而不是靠它记得。
- 能机械判断的，做成脚本 / 检查 / 动作前拦截
- 判据是「违反之后能不能继续」：能继续 = 提醒；不能 = 约束
- 高危动作（推保护分支、删库、动生产）直接机器拦
③ 接得上（可恢复流程） 如果中途换了个全新 AI（或新会话），靠项目里留下的东西，能不能接着干？
- 阶段产物写进文件 / 文档，而不是只留在聊天里
- 交接合同：输入来自上一步的产物，输出落到文件
- 「换 Agent 检验」：假定换个人，只剩项目状态，能不能续上
为什么「写严厉的 prompt」不够
很多人以为「把 prompt 写得更严厉」AI 就不犯浑了，但 prompt 是提醒不是约束。要拦住，就得把可机械判断的要求接到执行链上（脚本 / 检查 / 门禁），而不是依赖 AI「记得」。
- 提醒：不满足还能继续
- 约束：不满足就动不了
你的 Harness 里要的是约束，不是宣言。
三件事怎么落地
- 从实际失败里长出来：一次问题先修，反复出现的再固化成规则或脚本 anthropic-sdlc
- 别一开始就堆复杂 Harness：从最小基线起，让每一次新增都有明确的「触发它的失败」
- 能自动的判断就自动化：脚本、检查、CI 门禁，比写在文档里强
Harness 搭好，AI 就在一个「读得对、拦得住、接得上」的地盘里干活。接下来开始真正动手——小步把它做出来。