第十章：常见错误与演进路线

ACW 看起来简单，但实践中很容易走偏。

第一个常见错误，是把所有东西塞进一个文件。

这通常发生在入口文件上。用户希望 AI 一进来就知道全部内容，于是把背景、规则、历史、任务、模板、示例都写进 AGENTS.md。短期看似方便，长期一定混乱。

解决方法是分层。入口文件只做定位、路由和最高优先级约束。背景进 background/，规则进 conventions/，过程进 artifacts/，成果进 projects/。

第二个错误，是只建目录不写规则。

目录本身不会自动产生秩序。AI 需要知道目录的用途、文件的优先级、任务的流程和输出标准。如果没有规则，工作区只是一个空壳。

解决方法是从最小规则开始。先写清楚成果放哪里、过程放哪里、哪些事实不能编、任务前要读什么、完成后要检查什么。之后随着错误和返工继续补充。

第三个错误，是过程产物和最终成果混放。

这会让 AI 无法判断哪一版有效。尤其在写作、设计、代码生成中，草稿、废弃方案和正式成果混在一起，会造成严重污染。

解决方法是坚持 projects/ 和 artifacts/ 分工。最终产物在项目层，过程记录在 artifact 层。

第四个错误，是过度流程化。

有些人理解 ACW 后，会把所有任务都套完整流程。改一个标点也要建 artifact，润色一句话也要写需求文档。这会让工作区变慢，用户也会很快放弃。

解决方法是任务分级。小任务直接做，中等任务轻量留痕，大任务完整流程。工程化不是繁琐化，工程化是让复杂任务可控。

第五个错误，是没有验证闭环。

AI 输出一段内容，不代表任务完成。复杂任务必须检查。写作要审校，代码要测试，方案要核对约束，研究要检查来源。

解决方法是在 conventions/ 中写明各类任务的验收标准，并在 artifact 中保留 review。验证不是最后的附加动作，而是任务流程的一部分。

第六个错误，是把 ACW 当成一次性模板。

很多人希望找到一个完美目录，复制后永远使用。但真正的 ACW 一定会随着项目演进。初期结构应该简单，中期根据任务沉淀规则，后期再考虑自动化和团队协作。

一个可行的演进路线是：

第一阶段，最小工作区。

创建入口文件、projects/、background/、conventions/、artifacts/、tmp/。只写最关键规则，先让 AI 能正确区分成果、背景、规则和过程。

第二阶段，任务流程化。

当任务变复杂，引入 raw-input、requirements、structure、writing-spec、drafting、review 等过程。让 AI 的工作可追溯、可审查。

第三阶段，规则沉淀。

每次返工后更新 conventions/。把常见错误、格式要求、质量标准、禁区和流程分流写清楚。此时 ACW 会开始显著降低重复沟通成本。

第四阶段，领域模板化。

把稳定流程抽象成模板。写作模板、软件开发模板、研究模板、运营模板、咨询模板都可以逐渐形成。模板不是一开始设计出来的，而是从多次任务中提炼出来的。

第五阶段，团队化。

当多人使用同一个 ACW 时，需要更明确的权限、事实来源、审查责任和版本管理。团队化 ACW 不能只依赖个人习惯，必须有共享规范。

第六阶段，自动化。

当流程稳定后，可以接入脚本、检查命令、导出工具、测试工具、发布工具。自动化应该服务成熟流程，而不是掩盖混乱流程。

从个人到团队，ACW 的难点会变化。

个人工作区最重要的是减少重复解释。团队工作区最重要的是统一事实来源和协作规则。个人可以靠习惯弥补模糊，团队不行。团队 ACW 必须更重视权限、版本、审查和责任边界。

这也是为什么本书一直强调：ACW 不是目录，而是协作协议。

目录只是协议的载体。真正有价值的是：人和 AI 都知道如何进入项目、如何找到上下文、如何执行任务、如何检查结果、如何把经验沉淀回工作区。