常见错误与演进路线

11 常见错误与演进路线

标题备选

• ACW 看起来简单，但最容易踩这 6 个坑
• AI 工作区别变成形式主义
• 从最小工作区到团队协作，ACW 怎么演进

开场钩子

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

有些人把它做成一个超长入口文件，有些人只建目录不写规则，还有些人把每个小任务都搞成重流程。

这些都不是 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 不是目录，而是协作协议。

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

下一集是这个系列的尾声，我们讲最后一个转变：从说清楚，到沉淀清楚。