第五章：conventions/ 为什么是中后期最重要的目录

很多人搭工作区时，最重视 background/。

这很自然。背景资料最容易被看见，也最像“知识”。写小说要有世界观，做产品要有用户画像，写方案要有客户资料，写代码要有业务背景。没有背景，AI 很难理解任务。

但当一个 ACW 进入中后期，真正决定质量稳定性的，往往是 conventions/。

background/ 告诉 AI：“这个项目是什么。”

conventions/ 告诉 AI：“你应该怎么做。”

这两句话的差别非常大。

一个 AI 可能知道项目背景，却仍然用错格式、改错文件、跳过验证、编造事实、忽略风格、把过程稿当成终稿。它不是缺少背景，而是缺少规则。人类协作也是一样。一个新人读完公司介绍，并不意味着他知道如何提交代码、如何写会议纪要、如何处理客户投诉、如何做质量检查。

conventions/ 的价值，是把隐含经验变成显性规则。

比如写作工作区里，你可能逐渐发现一些问题：AI 喜欢把摘要写得像广告；喜欢在纪实内容里补细节；喜欢把审校意见写得很泛；喜欢直接输出长文而没有先确认结构；喜欢把最终正文放错目录。每次问题出现时，你当然可以在对话里说：“下次不要这样。”但如果这句话只停留在当前对话，它很快就会消失。

更好的做法是，把它写进 conventions/。

例如：

纪实类内容不得补写用户未确认的真实经历。
最终正文必须写入 projects/{project}/manuscript/。
artifacts/ 只保存过程产物，不保存最终正文。
全篇起草前必须先形成结构或目录。
审校报告必须列出具体问题、位置和修改建议。

这些规则不只是限制 AI。它们也在帮助人类减少重复管理成本。

当规则沉淀下来，下一次任务就不需要重新解释。AI 可以读取规则后直接遵守。团队成员也可以看到同一套标准，不必依赖某个人在对话里反复提醒。

conventions/ 通常可以包含几类文件。

第一类是原则文件。

它写工作区最重要的价值判断。例如：事实边界优先于表达流畅；小任务不套重流程；过程产物和最终产物必须分离；用户最新输入优先于旧文档；不确定时标注待确认。

第二类是流程文件。

它写不同任务如何推进。例如写作任务可以分为 raw-input、requirements、structure、writing-spec、drafting、review、submission。软件任务可以分为需求确认、影响范围、实现、测试、审查、提交。研究任务可以分为资料收集、来源评估、观点提炼、报告起草、引用检查。

第三类是质量标准。

它写什么叫做好。对写作来说，可能包括入题速度、结构完整性、风格一致性、事实边界、敏感风险。对代码来说，可能包括测试通过、类型检查、边界情况、性能影响、向后兼容。对方案来说，可能包括目标清晰、约束明确、成本可估、风险可控。

第四类是长期记忆。

这里不是保存所有聊天记录，而是保存真正会影响后续协作的规则性经验。比如：“用户偏好中文文档”“ACW 概念以当前项目设定为准”“projects/ 既是最终产物目录，也是已有项目进入点”。这些内容如果长期有效，就应该变成可读取的规则。

第五类是模板。

模板是规则的结构化表达。需求模板、审校模板、项目模板、提交模板、章节模板，都可以减少 AI 临场发挥的空间。模板越清晰，产出越容易被检查。

不过，conventions/ 也有一个风险：过度规则化。

规则不是越多越好。如果每个小任务都必须走十几个步骤，ACW 会变成负担。好的规则应该让复杂任务更稳定，让简单任务更轻，不应该把所有任务都拖进同一套重流程。

因此，conventions/ 里最好有任务分流原则。比如把任务分成 L0、L1、L2、L3：

L0 是直接处理。错字、标点、单句修改，不需要创建 artifact。

L1 是快速修订。单段润色、标题优化、转场补写，可以直接完成，必要时留简短说明。

L2 是标准写作或标准开发。需要记录需求、结构、规格和审校。

L3 是完整创作或复杂工程。需要完整流程、过程留痕和最终验证。

这个分级的意义，不是制造仪式感，而是让工作区能根据风险选择流程重量。小任务轻处理，大任务重管理，才是真正可持续的协作。

当你搭建自己的 ACW 时，请特别重视 conventions/。它可能一开始很薄，但会越来越重要。每一次返工、每一次误解、每一次审校发现的问题，都是给它增加一条高价值规则的机会。

AI 犯错并不一定是坏事。

如果错误只在当前对话里被纠正，它就是成本。如果错误被转化为规则、模板和验证流程，它就变成资产。

这就是 conventions/ 的意义。