第二章：Prompt 解决一次表达，ACW 解决长期协作

Prompt 仍然重要。

没有清楚的指令，AI 很难给出稳定结果。你要告诉它目标、背景、约束、输出格式和判断标准。一个好的 Prompt，确实能显著提升单次回答质量。

但 Prompt 有一个天然限制：它是一次性的表达容器。

你可以把很多信息塞进一条 Prompt。你可以写角色、写步骤、写示例、写风格、写禁区，甚至写一大段项目背景。可是当任务需要多天、多轮、多文件、多角色、多阶段协作时，单条 Prompt 会变得越来越臃肿。它不仅难写，也难维护。更糟糕的是，Prompt 越长，越容易混入过期信息、重复要求和互相冲突的指令。

很多人使用 AI 卡住，并不是因为不会写句子，而是因为把所有协作责任都压在了 Prompt 上。

比如你正在写一本书。第一天你告诉 AI：书名、目标读者、章节结构、语气要求。第二天你让它改第一章。第三天你又让它写第五章。第四天你发现它忘了第二章已经改过的概念。第五天你补充了新的术语规则。第六天你要求全书统一风格。到这个阶段，如果所有东西都靠对话里反复提醒，协作成本会急剧上升。

软件开发也是一样。你可以让 AI 写一个函数，但如果它不知道项目架构、依赖版本、测试命令、代码风格、数据库约束、上线禁区，它就可能写出“看起来能跑、实际上不能合并”的代码。你当然可以在 Prompt 里补充这些信息，但每次都补充，既浪费，也容易漏。

ACW 的意义，就是把这些长期有效的协作信息，从 Prompt 中拿出来，放进工作区。

Prompt 变成任务入口。ACW 变成协作环境。

在 ACW 中，Prompt 不再需要承担全部记忆。你可以对 AI 说：“请按照本工作区规范，继续写第三章。”这句话之所以可行，不是因为它神奇，而是因为工作区里已经有书稿项目、目录、风格规范、既有正文和任务流程。AI 可以按需读取这些内容，再执行当前任务。

这也是为什么 ACW 不是简单的“文件夹分类法”。

如果你只是建了一堆目录，但 AI 不知道这些目录是什么意思，不知道什么时候读哪个文件，不知道哪些规则优先级更高，不知道产物应该写到哪里，那这些目录只是在硬盘上排队。ACW 真正要建立的是一种协作协议：文件结构、命名、入口、规则、流程和验证标准共同组成 AI 可以理解的行动环境。

我们可以把 ACW 拆成五类信息：

第一类是目标。这个工作区要完成什么？写书、做软件、研究主题、运营账号，还是管理一个客户项目？

第二类是背景。哪些事实长期有效？读者是谁？项目历史是什么？已有材料有哪些？哪些内容已经确认，哪些只是推测？

第三类是规则。AI 应该如何行动？输出格式是什么？哪些文件可以改？哪些事实不能编？审校标准是什么？遇到不确定信息时应该继续推断还是停下来问？

第四类是过程。每次任务的原始输入、需求拆解、结构设计、草稿、审校报告、决策记录，应该如何保存？

第五类是成果。最终交付物在哪里？书稿、代码、方案、课件、视频指令、数据分析报告，各自应该归属到哪个项目目录？

这五类信息如果全部混在一个对话里，AI 很难长期稳定。如果它们被放进清楚的工作区结构里，AI 就能更像一个项目协作者，而不是每次从零开始的临时聊天对象。

这也是 ACW 和普通知识库的区别。

知识库主要帮助人和 AI 查找信息。ACW 不只保存信息，还规定行动方式。它不仅告诉 AI“这里有什么”，还告诉 AI“遇到什么任务应该怎么做”。因此，ACW 更接近一个可执行的协作环境。

你可以把 ACW 理解成 Prompt 的上层结构。

Prompt 仍然存在，但它变短了，也更聚焦了。它不再负责携带全部上下文，而是负责启动一次任务。真正稳定的上下文，被工作区承载；真正可复用的规则，被规范文件承载；真正可审查的过程，被 artifact 承载；真正交付的成果，被项目目录承载。

当你从这个角度重新看 AI 协作，很多问题会变得清楚。

AI 为什么总是忘？因为你把应该写进工作区的内容留在了临时对话里。

AI 为什么总是犯同一个错？因为你只在对话里纠正它，却没有把纠正写进长期规则。

AI 为什么产出看似完整但无法交付？因为你没有为它提供验收标准和验证流程。

AI 为什么越聊越乱？因为稳定背景、临时假设、过程草稿和最终成果混在了一起。

ACW 不是让 AI 变得无所不能。它只是把协作从“临场发挥”变成“有工程结构的持续工作”。这已经足够改变很多任务的质量。