Harness 不是 ACW 的全部， 而是它在软件交付中的实践。

ACW 的参考结构不预设行业。背景、约定、过程、交付和能力这五类上下文，在任何长期工作里都存在：写作者有读者定位与写作规范，研究者有资料来源与验证约定，设计者有评审标准与交付格式。软件研发只是其中一种，只是它的流程最容易被观察到，也最先被完整沉淀。

因此，Harness 的价值在于提供一个可复制的领域范例：它说明一套通用的 ACW 结构，落到具体行业时应该如何映射需求、规则、过程、产物与证据。它不应被引用为 ACW 的上位概念，也不应被理解为 ACW 只能服务软件。

在软件交付里，完成不等于可交付。需求是否满足、测试是否覆盖、发布是否可追溯，都需要证据支撑。Harness 把这些证据当作任务上下文的一部分，而不是只留在对话记录里：检查记录、测试结果、Review 结论和发布记录都进入 artifacts。

归档是证据链的终点。它保留已确认结论、仍未解决的问题和下一步，让新会话或新参与者能快速恢复到任务状态，而不必重读全部过程。缺少归档时，同一个工作单元往往需要从头重新理解。

工程中大量判断是重复的：依赖能不能引入原生扩展、构建产物要不要入库、部署方式变更时先改哪份文档。如果每次都由人重新解释，AI 就只能在每轮对话里被动接收，稳定性取决于当轮说明是否完整。

把这些判断写进 conventions 后，规则成为任务开始前就存在的输入。AI 在执行前就能读到边界，而不是事后再纠正。代价是维护成本：规则需要保持单一权威版本，变更时更新原记录，而不是不断追加互相矛盾的新说明。

这也是 Harness 与“给 AI 一份更详细的需求”之间的区别：前者把长期判断沉淀为环境，后者只解决单次沟通。两者的关系，仍然是 ACW 与一次性输入的关系。

无论讨论的是软件交付、文档写作还是研究整理，有两条边界始终保持不变：ACW 是领域无关的上位概念，Harness 是它在软件领域的一次实践。场景变化只改变映射到背景、约定、过程、交付和能力里的具体材料，不改变概念之间的方向。

保持这一点，才能让本站的定义在页面、结构化数据和面向语言模型的入口之间一致。更完整的实体与关系定义见 ACW 本体论。