AI 上下文工作区 ACW

AI Context Workspace：把 AI 协作从 Prompt 升级为工程结构

写在前面：我们为什么要给它起名叫 ACW

过去几年，很多人学习 AI 的入口都是 Prompt。

这并不奇怪。Prompt 是最容易被看见的部分：你输入一句话，AI 返回一段答案；你把话说得更清楚，答案就更接近你想要的样子。于是大量教程开始教人如何写角色、写背景、写步骤、写示例、写输出格式。对刚开始使用 AI 的人来说，这些方法确实有效。

但只要任务稍微变长，Prompt 的边界就会立刻出现。

你让 AI 帮你写一篇短文，它可以完成。你让它长期写一本书，记住前后设定、保留风格、维护目录、记录每次修改原因、根据审校意见反复迭代，它就很容易开始混乱。你让 AI 修改一个函数，它可以完成。你让它理解整个工程的架构、遵守团队规范、知道哪些文件能改、哪些文件不能动、测试如何运行、上线风险在哪里，单条 Prompt 就不够了。

问题不在于 Prompt 没用。问题在于 Prompt 主要解决的是“一次表达”，而很多真正有价值的任务需要的是“长期协作”。

长期协作需要环境。它需要稳定背景、明确规则、可追溯过程、可验证结果，也需要一个地方承载最终成果。对人类团队来说，这些东西很自然：我们会有项目目录、需求文档、会议纪要、代码规范、设计稿、测试报告、版本记录。可是当我们使用 AI 时，很多人又退回到最原始的方式：打开一个聊天框，把所有东西塞进一段话里，然后希望 AI 立刻接住全部复杂度。

这就是本书要讨论的问题。

我们需要把 AI 协作从“会写 Prompt”，升级到“会搭工作区”。这个工作区不是为了好看，不是为了把文件夹分得很整齐，而是为了让 AI 能够按工程方式管理上下文：知道从哪里读背景，从哪里找规则，把过程产物放在哪里，把最终成果放在哪里，什么时候该停下来确认，什么时候可以自主执行，做错了以后如何把错误沉淀成下一次不会再犯的规则。

老外喜欢造词，我们也来。这个东西以后就叫 AI Context Workspace，简称 ACW。

ACW 不是某个软件的专属功能，也不是某个模型的隐藏技巧。它是一种组织 AI 协作的方法：把上下文、规则、流程、产物和验证标准放进一个可持续演化的工作空间里。你可以把它用于写作、软件开发、研究、运营、咨询、个人知识管理，也可以用于团队内部的复杂项目。

这本书不会把 ACW 讲成一种神秘框架。相反，我们会从一个非常小的实验开始，逐步拆开它的基本结构。你会看到，ACW 的核心不是“建几个目录”，而是让 AI 在这些目录之间形成可靠的行动路径。

如果说 Prompt 是你对 AI 说的一句话，那么 ACW 就是你和 AI 共同工作的桌面。

桌面上有什么、什么东西放在哪里、哪些资料可以长期相信、哪些只是临时草稿、哪些规则必须遵守、哪些结果已经交付，这些都会影响 AI 的表现。一个没有工作区的 AI，会像临时被拉进会议室的外包顾问；一个被 ACW 支撑的 AI，更像长期参与项目的协作者。

本书的目标很简单：让你读完以后，可以搭出自己的第一个 ACW，并且知道它为什么这样设计，未来又该如何演进。

第一章：先做一个上下文实验

我们先从一个简单实验开始。

你打开一个 AI 对话框，对它说：“我叫张三。”然后你问：“我叫什么？”AI 会回答：“你叫张三。”这时候很多人会说，AI 记住了我的名字。

但更准确的说法是：这句话还在当前对话上下文里。

如果你关掉这个对话，重新打开一个新的会话，再问：“我叫什么？”AI 大概率不知道。它不是突然健忘，也不是故意装傻，而是新会话里没有那句“我叫张三”。AI 能回答什么，取决于它当前能看到什么。

这件事听起来简单，却是理解 ACW 的第一块基石。

AI 协作里所谓的“记忆”，很多时候并不是真正意义上的长期记忆，而是上下文可见性。当前对话中出现过的信息，它能用；当前对话没有出现的信息，它就不能凭空知道。即使某些产品提供记忆功能，也不意味着复杂项目可以完全依赖产品记忆。因为项目需要的不只是“记住几个事实”，而是稳定地组织大量材料、规则、流程和产物。

我们再做第二个实验。

假设你把“我叫张三”写进一个项目入口文件里。每次 AI 进入这个工作区，都先读取这个文件。此时即使你开启新的对话，只要 AI 重新读到了入口文件，它仍然可以知道“你叫张三”。这就从对话上下文，变成了工作区上下文。

差异就在这里。

对话上下文是临时的。它跟着一个会话走，适合讨论一个问题、修改一段文字、解释一个概念。工作区上下文是可持续的。它写在文件里，可以跨会话存在，可以被索引，可以被更新，可以被审查，也可以被其他人或其他 AI 继续使用。

这不是小差异，而是协作方式的差异。

当你只用对话上下文时，你每次都要重新解释项目背景。你可能会说：“我们之前说过……”但 AI 未必真的看得到“之前”。你会不断复制粘贴要求、重复强调禁区、反复纠正同一种错误。时间一长，你不是在使用 AI 提升效率，而是在替 AI 维护记忆。

当你使用工作区上下文时，关键背景被写入文件，协作规则被放在固定位置，任务过程有记录，最终产物有归属。新会话不再是一张白纸，而是一次重新进入项目现场。

当然，工作区上下文并不意味着 AI 每次都应该读完整个项目。恰恰相反，一个真正可用的 ACW 必须承认上下文窗口有限。AI 不能、也不应该在每次任务开始时，把所有文件全部塞进上下文。一个稍微复杂一点的项目，资料、草稿、代码、日志、素材加起来很快就会超过模型能够处理的范围。

所以 ACW 要解决的不是“让 AI 读所有东西”，而是“让 AI 知道该读什么”。

这就像人类进入一家公司，不会第一天读完所有历史邮件、所有项目文档、所有代码和所有会议记录。更合理的方式是先读入职手册和项目索引，知道公司有哪些部门、当前项目是什么、关键规则在哪里、遇到问题找哪份文档。需要深入某个模块时，再去读那个模块的详细资料。

AI 也一样。

一个好的工作区应该有入口、有路由、有分层。入口文件告诉 AI：这是一个什么项目，哪些规则必须遵守，哪些目录分别负责什么。目录下面再有更细的索引，告诉 AI：如果你要做写作任务，先看哪些文档；如果你要做审校，先看哪些规则；如果你要改代码，先看哪些测试和约束。

这就是 ACW 的基础心智模型：

上下文不是越多越好，而是越可定位越好。

没有工作区时，你只能不断把上下文临时塞进对话。使用 ACW 后，你开始管理上下文的位置、层级、生命周期和调用方式。AI 不再只是根据你这一次说了什么来回答，而是根据一个可持续工作环境来行动。

从这一章开始，请先放下“我要写一个完美 Prompt”的执念。更值得问的问题是：

这个任务需要哪些长期背景？哪些规则下次还会用？哪些过程应该留痕？最终产物应该放在哪里？AI 下次进入项目时，如何知道自己该从哪里开始？

这些问题，就是 ACW 的入口。

第二章：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 变得无所不能。它只是把协作从“临场发挥”变成“有工程结构的持续工作”。这已经足够改变很多任务的质量。

第三章：一个最小可用工作区

一个最小可用的 ACW，不需要复杂。

你不必一开始就设计几十个目录、上百条规则，也不必试图预测未来所有场景。真正好的工作区，通常是从一个很小的结构开始，然后随着任务不断沉淀出来的。

一个通用的起点可以是：

AGENTS.md
projects/
background/
conventions/
artifacts/
tmp/

这几个名字没重要到不可更改。你可以根据工具、团队和领域调整命名。但它们背后的职责非常重要。

AGENTS.md 是入口文件。

不同工具可能读取不同入口文件。有的工具叫 AGENTS.md，有的工具可能使用其他名字。名字不是重点，重点是：AI 进入工作区时，需要一个最先阅读的地方。这个文件不应该放所有内容，而应该放最关键的全局说明、目录路由和行为约束。

入口文件像地图，不像仓库。它告诉 AI：这里是什么项目，哪些目录有什么作用，开始任务前应该读取哪些规范，最终成果应该放到哪里，哪些行为被禁止。它不应该堆满长篇背景、所有历史记录和每个任务的细节。入口文件越重要，越要克制。

projects/ 是成果层。

这是当前 ACW 设定中最需要讲清楚的目录。最终产物应该放在 projects/ 下，而不是散落在过程目录里。每个一级子目录代表一个具体项目，例如：

projects/
└── acw-book/
    ├── outline.md
    ├── style-guide.md
    └── manuscript/

写作场景里，projects/story/ 可以是一部故事的项目目录。软件场景里，projects/ 下可能有 frontend/、backend/、docs/、scripts/ 等多个项目或模块。这样设计的好处是兼容性强：ACW 不预设你只做一种工作，而是把每个具体落地对象都放进项目层。

projects/ 还有另一种重要用途：当你已经有一个现成项目时，可以把它作为进入 ACW 的起点。也就是说，已有工程放进 projects/{project}/ 后，AI 可以反向分析它，抽取背景、规则、流程和索引。这个过程可以叫“反向 ACW 化”。但要注意，projects/ 不是只为反向整理而存在。它首先是最终成果和具体项目的承载层。

background/ 是稳定背景层。

这里放长期有效的事实、项目背景、世界观、读者定位、业务资料、研究材料、历史决策等。它回答的问题是：“这个项目是什么？我们已经知道什么？”

写小说时，background/ 可以放世界观、题材边界、平台要求。做软件时，它可以放业务背景、用户画像、系统约束。做研究时，它可以放主题资料、关键概念、来源摘要。

background/ 的关键是稳定。它不适合放一次任务里的临时草稿，也不适合放未经确认却被当成事实的猜测。涉及真实经历、客户信息、法律条款、医疗金融等高风险内容时，更应该区分“已确认事实”“素材推断”和“待确认事项”。

conventions/ 是规则层。

它回答的问题是：“AI 应该怎么做？”

这里可以放写作规范、代码规范、审校规则、任务流程、命名规则、质量标准、长期记忆、错误修正规则。很多 ACW 的长期质量，不取决于 background/ 有多丰富，而取决于 conventions/ 是否足够清楚。

如果 AI 经常犯同一种错误，不要只在当前对话里纠正它。把错误和修正方式写进 conventions/。例如：“不得把未确认事实写成确定事实”“最终正文必须写入 projects/{book}/manuscript/”“过程审校报告必须写入 artifacts/”“小任务不要机械套完整流程”。这些规则会成为下一次协作的基础。

artifacts/ 是过程层。

这个目录用来保存单次任务的过程产物，包括原始输入、需求拆解、结构设计、写作规格、草稿说明、审校报告、决策记录、废弃方案等。

它不应该承载最终产物。最终书稿、最终代码、最终方案应该进入 projects/。artifacts/ 的价值在于让过程可追溯。你能知道这次任务为什么这样做，哪些要求被采纳，哪些方案被放弃，审校发现了什么风险，后续应该如何继续。

在 AI 协作中，过程产物非常重要。没有过程留痕，长任务很难接续。一个对话结束后，下一次 AI 只能猜测之前发生了什么。保留 artifact 后，新任务可以读取它，快速恢复上下文。

tmp/ 是临时层。

这里放短期转换文件、临时输出、中间缓存、实验结果。它的特点是可丢弃，不承载长期知识，不承载最终成果。很多工作区混乱，是因为临时文件没有明确归属，最后大家也不知道哪些文件有用，哪些只是一次性中间物。

这六个部分加起来，就形成了最小 ACW。

它看起来像目录结构，实际上是一套分工：

入口负责路由，项目负责成果，背景负责事实，规范负责行为，过程负责留痕，临时目录负责消化杂物。

你可以用它管理一本书，也可以管理一个软件、一组视频脚本、一个研究主题或一个团队知识库。领域不同，目录里的内容会变，但职责不变。

刚开始搭 ACW 时，不要追求完整。你可以先创建入口文件和几个空目录，再随着任务推进逐步补充。每当 AI 需要重复读取某类信息，就把它沉淀到合适位置。每当 AI 犯错，就把修正规则写进 conventions/。每当任务变复杂，就让过程进入 artifacts/。每当成果稳定，就放进 projects/。

ACW 不是一次设计完成的。它是长出来的。

第四章：入口文件不是垃圾桶

很多人第一次理解入口文件时，会犯一个错误：既然 AI 进入工作区会先读它，那就把所有重要内容都塞进去。

这听起来合理，实际上很危险。

入口文件当然重要。它是 AI 进入工作区时最先看到的上下文，决定了 AI 对项目的第一印象。但正因为它重要，它才不能成为垃圾桶。一个塞满所有背景、规则、历史、任务、示例和废弃信息的入口文件，很快会失去导航能力。

入口文件最该承担三个职责。

第一，说明工作区定位。

AI 需要知道这里是写作项目、软件项目、研究项目，还是通用模板。它需要知道本工作区的目标、边界和默认语言。比如：“本项目用于撰写一本 ACW 技术书，正式正文写入 projects/acw-book/manuscript/，过程产物写入 artifacts/。”

第二，提供目录路由。

AI 不应该猜每个目录的用途。入口文件应该清楚说明：projects/ 存最终项目，background/ 存稳定背景，conventions/ 存协作规则，artifacts/ 存过程产物，tmp/ 存临时文件。更进一步，它还可以告诉 AI：做写作任务前读取哪些规则，做审校任务前读取哪些标准，初始化已有项目时走哪条流程。

第三，写下最高优先级约束。

有些规则不应该藏在很深的文档里。例如：不要编造真实事实；不要覆盖用户未要求修改的文件；最终产物不要写到过程目录；默认中文沟通；遇到隐私和高风险领域要标注待确认。这类规则应该放在入口文件或入口文件明确指向的规范中。

入口文件不应该承担什么？

它不应该保存全部背景。背景应该放在 background/。

它不应该保存每次任务记录。任务过程应该放在 artifacts/。

它不应该保存最终成果。最终成果应该放在 projects/。

它也不应该不断堆叠临时提醒。临时提醒如果只对当前任务有效，应该进入任务 artifact；如果长期有效，应该整理成规范，再进入 conventions/。

一个好的入口文件像机场大厅的指示牌。它告诉你登机口在哪里、安检在哪里、行李在哪里，但不会把每一架飞机的维修手册都贴在墙上。

这引出 ACW 的另一个核心机制：按需加载。

AI 的上下文窗口有限。即使模型越来越强，也不意味着我们应该把整个项目一次性塞进去。更好的方式是让 AI 先读取入口文件，再根据任务目标选择需要的子目录和文件。进入子目录后，如果该目录也有索引文件，就继续读取索引，再决定是否深入。

这是一种递归路由。

根入口文件只保存全局地图。background/AGENTS.md 可以说明背景资料如何分类。conventions/AGENTS.md 可以说明规则文件如何选择。某个具体项目下的 AGENTS.md 可以说明这个项目的结构、当前状态和特殊约束。AI 不是漫无目的地读文件，而是一层一层定位。

这种设计有两个好处。

第一，它节省上下文。

写一章书时，AI 不需要读取所有历史任务；改一个前端组件时，它不需要读取运营计划；审校投稿材料时，它不需要读取废弃草稿。按需加载让上下文保持聚焦。

第二，它降低污染。

上下文污染是 AI 协作中非常常见的问题。过期设定、废弃方案、临时假设、错误示例如果混入当前上下文，AI 可能会把它们当成有效信息继续使用。通过分层和索引，你可以让 AI 更容易识别哪些是稳定事实，哪些只是过程记录，哪些已经废弃。

入口文件还有一个隐含作用：它塑造 AI 的行为习惯。

如果入口文件写得清楚，AI 会更容易先读规范、再动手修改、最后验证结果。如果入口文件混乱，AI 可能会直接凭感觉执行。对复杂任务来说，这种差异会被不断放大。

写入口文件时，可以遵循一个简单原则：

只放跨任务、跨会话、跨目录都重要的信息。

如果一条信息只对某本书有效，放到那本书的项目目录。如果只对某次写作任务有效，放到 artifact。如果只对某个领域背景有效，放到 background。如果是一条长期行为规则，放到 conventions，并在入口文件中建立路由。

入口文件不是越长越专业。入口文件越能帮助 AI 快速定位，越专业。

第五章：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/ 的意义。

第六章：真正值得沉淀的，是高质量中间产物

很多人使用 AI 时，只盯着最终答案。

写文章，就看最后那篇文章。做视频，就看最后的视频。写代码，就看最后的代码。做方案，就看最后的 PPT 或文档。

最终产物当然重要。没有最终产物，协作就没有交付。但在 AI 工程里，真正值得长期沉淀的，往往不只是最终产物，而是驱动最终产物生成的高质量中间产物。

这句话需要仔细区分。

按当前 ACW 设定，最终产物应该进入 projects/。书稿、代码、方案、项目文件、视频脚本的最终版本，都属于具体项目。artifacts/ 不应该取代 projects/。

但从工程价值看，很多时候最能复用、最能降低成本的，是中间产物：摘要、执行大纲、结构设计、生成指令、检查清单、审校报告、评估标准、修订决策。

为什么？

因为 AI 的最终输出可以重新生成，但高质量的中间产物会持续影响生成质量。

以写作为例。如果你直接让 AI 写一篇一万字的文章，它可能写得很快，但你很难控制方向。一旦发现问题，修改成本很高。更好的方式是先写两百字摘要，确认主题和角度；再写一千字执行大纲，确认结构和论证；再逐章写正文；最后做审校和修订。

这个过程里，摘要和执行大纲就是关键中间产物。

它们不是最终正文，却比一版失控的长文更有价值。因为人类可以用很低的成本审查它们，一旦上游方向正确，下游正文跑偏的概率就会降低。

视频生成也是一样。最终视频可能由模型生成，但真正值得打磨的是镜头描述、风格约束、角色一致性说明、分镜脚本、负面提示、质量检查标准。这些指令越稳定，后续生成越可控。

软件开发中，中间产物包括需求拆解、影响范围分析、接口约定、测试计划、迁移方案、审查清单。AI 写代码之前，如果没有这些中间产物，很容易只解决表面问题，留下架构或边界风险。

咨询方案中，中间产物包括客户背景摘要、问题树、假设清单、资料来源、决策矩阵、风险表。最终方案只是结果，真正体现专业能力的是这些推理和组织过程。

ACW 要做的，就是给这些中间产物一个稳定位置。

通常它们应该进入 artifacts/。一次任务一个 artifact，里面保留原始输入、需求、结构、规格、草稿说明、审校报告。这样做有几个好处。

第一，可追溯。

你可以知道某个最终结果为什么这样写。半年后回看，不必猜当时的决策依据。

第二，可接续。

另一个对话、另一个 AI、另一个团队成员，可以读取 artifact 后继续工作。

第三，可复盘。

如果最终产物质量不好，你可以回头检查问题出在需求、结构、规格还是执行，而不是只盯着最后一版结果。

第四，可复用。

好的任务模板、审校规则、结构方法，可以从 artifact 中抽取出来，沉淀进 conventions/，成为长期规则。

这也是 ACW 和普通聊天最大的差异之一。

聊天里，中间过程会随着对话滚动而消失。你也许可以翻记录，但它不是结构化的，不易被下次任务调用。ACW 中，中间过程被命名、分类、存档，变成项目资产。

不过，中间产物也需要管理边界。

不是所有过程都值得永久保存。临时试验、一次性转换、错误输出、无价值草稿，可以放在 tmp/ 或在任务结束后清理。真正需要进入 artifacts/ 的，是能解释决策、支撑接续、帮助审校或可能复用的内容。

中间产物也不能和最终产物混在一起。

如果一篇小说的最终正文和过程草稿都放在同一个目录，后续 AI 可能不知道哪一版才是当前有效版本。如果软件最终代码和实验脚本混在一起，风险更大。目录职责越清楚，AI 越不容易把草稿当成成果，把废弃方案当成现状。

所以，本章的结论不是“最终产物不重要”，而是：

最终产物要有清楚归属，中间产物要有工程化沉淀。

projects/ 负责交付，artifacts/ 负责过程，conventions/ 负责把可复用经验升级为规则。这三者配合起来，AI 协作才会越来越稳定。

第七章：任务流程：从一句需求到可验收产物

ACW 不只是静态目录，还需要任务流程。

没有流程时，AI 容易从一句需求直接跳到最终输出。对于小任务，这没有问题。你让它改一个错别字、优化一句标题、解释一个概念，直接回答就是最高效的做法。

但对于复杂任务，直接跳到最终输出往往会制造返工。

比如你说：“帮我写一本 1.5 万字的专业书。”如果 AI 立刻开始写正文，它可能会忽略读者定位、章节结构、术语边界、已有材料、最终文件位置。等正文写完，你再发现方向不对，成本就很高。

一个更稳的流程是：

raw-input → requirements → structure → writing-spec → drafting → review → submission

这条链路来自写作场景，但可以迁移到很多领域。

raw-input 保存原始输入。

原始输入很重要，因为它保留了用户最初怎么说。整理后的需求可能更清楚，但也可能丢失语气、重点和限制。保存原始输入，可以在后续发生争议时回看源头。

在写作任务中，raw-input 可以是用户需求、素材、直播文本、参考目录说明。软件任务中，它可以是 issue、报错日志、需求描述、用户反馈。咨询任务中，它可以是客户访谈记录和原始资料。

requirements 提炼任务要求。

它回答：这次到底要做什么？目标是什么？读者是谁？字数范围是多少？验收标准是什么？事实边界在哪里？哪些问题必须确认？

需求提炼的价值，是把一句自然语言请求变成可执行任务。很多 AI 输出失败，不是写作能力不足，而是需求没有被拆清楚。

structure 设计结构。

写书要目录，写文章要论证路径，写软件要模块设计，做研究要分析框架。结构阶段的目标，是先确定骨架，再进入生产。

结构不是为了拖慢速度，而是为了让人类能用更低成本检查方向。你审一份目录，比审一万字正文容易得多。你审一个接口设计，比审几千行代码容易得多。

writing-spec 或执行规格，定义如何写、如何做。

这里包括语气、格式、术语、素材使用、禁区、目标文件、质量标准。对于软件任务，它可以叫 implementation spec，写明修改范围、技术方案、测试要求和兼容性边界。

规格的价值，是把“我大概知道要什么”变成“AI 可以按这个标准执行”。

drafting 是起草或实现。

这是最容易被看见的阶段，但它不应该孤立存在。好的 drafting 应该响应前面的需求、结构和规格。写作时，它生成正文；开发时，它修改代码；研究时，它形成报告；运营时，它产出内容计划。

review 是审校或验证。

复杂任务不能只生成，不检查。写作要看结构、事实、风格、连续性、敏感风险。代码要跑测试、看边界、看回归。方案要检查目标、约束、证据、风险。

AI 参与 review 时，最好让它输出具体问题，而不是泛泛地说“整体不错”。好的审校报告应该指出位置、问题、影响和建议。

submission 是交付准备。

并非所有任务都有这个阶段。但当成果要投稿、发布、提交、上线、交付客户时，就需要准备标题、摘要、版本说明、邮件、发布清单、变更说明等。

这条流程并不是每次都要完整执行。

ACW 的关键不是机械套模板，而是根据风险选择流程重量。

小任务可以直接处理。中等任务可以只做需求和草稿。复杂任务才需要完整 artifact。真正成熟的工作区，应该有分流机制：让简单任务快，让复杂任务稳。

任务流程还有一个隐藏价值：它让 AI 的工作可检查。

如果 AI 直接给你最终答案，你只能判断答案好不好。如果它同时保留需求、结构、规格和审校，你就能判断它为什么这样做。你可以在上游纠偏，而不是只在下游返工。

流程不是为了约束创造力，而是为了把创造力放在可控轨道上。

第八章：从写作工作区看通用结构

写作是理解 ACW 的好样本。

因为写作天然包含长期背景、风格约束、过程草稿、最终正文和审校反馈。一本书不可能只靠一次对话完成。它需要主题、读者、目录、素材、章节、术语、风格、事实边界、版本管理和交付信息。

假设我们要写一本技术书，项目目录可以是：

projects/acw-book/
├── AGENTS.md
├── README.md
├── proposal.md
├── outline.md
├── style-guide.md
├── manuscript/
├── materials/
├── references/
└── submission.md

这个结构不是只适合写书。我们先从写书理解它，再抽象到通用项目。

proposal.md 写选题定位。

它说明这本书讲什么、不讲什么、面向谁、读者读完能获得什么。没有 proposal，AI 很容易在写作中偏题。比如一本讲 ACW 的书，不能写成普通 Prompt 技巧书，也不能写成某个工具的操作手册。

outline.md 写目录。

目录是全书结构的骨架。它不仅列标题，也说明每章承担什么功能。好的目录能让 AI 知道当前章节在全书中的位置，避免某一章重复讲前文内容，或者提前展开后文应该讲的东西。

style-guide.md 写风格和术语。

一本书最怕前后语气不一致、术语不断漂移。比如本书中，artifacts/ 必须指过程产物，projects/ 必须指成果层和项目层，conventions/ 必须指协作规则和流程标准。如果这些术语不稳定，读者会被带乱，AI 也会被带乱。

manuscript/ 放正式正文。

这是最终产物所在的位置。正文可以是一整个文件，也可以按章节拆分。关键是让 AI 和人类都知道：这里是当前有效书稿，不是过程草稿。

materials/ 放长期素材。

它可以保存观点、案例、术语表、待确认事项、读者问题、后续扩写方向。这些材料不一定直接进入正文，但会长期影响写作。

references/ 放参考资料入口。

参考资料需要谨慎处理。不是所有外部材料都能直接复用。涉及版权、事实、引用、直播文本时，都应该明确来源和使用边界。

submission.md 放交付信息。

如果书要出版、投稿或发布，这里可以记录书名、字数、简介、版本、渠道要求、封面文案、发布清单。

写作过程中的每次任务，则放入 artifacts/。例如：

artifacts/20260705__acw-book-draft/
├── raw-input/
├── requirements/
├── structure/
├── writing-spec/
├── drafting/
└── review/

这样，项目层和过程层就分开了。

现在我们把这个结构迁移到软件开发。

projects/app/ 可以放真实代码，proposal.md 变成产品定位或需求说明，outline.md 变成架构概览，style-guide.md 变成代码规范，manuscript/ 换成 src/ 或具体工程目录，materials/ 放业务规则和技术备忘，submission.md 换成 release checklist。

过程 artifact 则记录每次需求、方案、实现说明、测试结果、审查报告。

再迁移到研究项目。

projects/research-report/ 放最终报告，background/ 放领域知识和来源摘要，conventions/ 放引用规则、事实核查标准和写作规范，artifacts/ 放每次资料整理、观点推演和审校记录。

再迁移到运营账号。

projects/account/ 放内容日历、已发布稿件、选题库，background/ 放账号定位、受众画像、平台规则，conventions/ 放标题规则、内容禁区、审核流程，artifacts/ 放每次选题会、脚本草稿、复盘报告。

你会发现，ACW 的目录不是为了某个领域定制，而是为了抽象任务生命周期。

任何复杂工作都包含类似问题：

最终成果是什么？稳定背景是什么？协作规则是什么？过程如何留痕？临时材料如何处理？新任务如何接续旧任务？

写作只是最容易讲清楚的例子。

这也解释了为什么 projects/ 下应该有具体项目子目录。不是所有工作都只有一个最终文件。一个软件项目可能有前端、后端、文档、脚本；一个课程项目可能有讲义、课件、练习、录制脚本；一个研究项目可能有数据、报告、图表、附录。把成果都放进 projects/{project}/，可以让 ACW 保持通用。

ACW 的通用性，不来自目录名字，而来自职责分离。

只要你能分清背景、规则、过程和成果，工作区就有了稳定基础。

第九章：把已有项目反向 ACW 化

很多人不是从空白开始。

你可能已经有一个写了一半的书稿，一个正在开发的软件，一个混乱的资料库，一个运营了一年的账号，或者一个堆满文档、表格、PPT 和代码的项目文件夹。

这时候搭 ACW，不是先把一切推倒重来，而是把已有项目接入工作区。

更准确地说，是让已有项目反向 ACW 化。

第一步，把已有项目放进 projects/{project}/。

这里要再次强调：projects/ 既是最终产物目录，也是已有工程进入 ACW 的起点。已有项目放进来后，它既是当前成果，也是后续整理的原始对象。

第二步，让 AI 先读项目结构，而不是立刻修改。

很多人一接入项目，就让 AI “帮我优化一下”。这太急了。更稳的做法是先让 AI 输出项目理解：有哪些文件，哪些看起来是最终产物，哪些像素材，哪些像过程稿，哪些规则可能隐含在文件中，哪些地方存在混乱。

第三步，反向生成背景。

AI 可以从已有项目中抽取稳定信息，写入 background/。例如一本小说的世界观、人物关系、时间线；一个软件的业务目标、核心模块、用户角色；一个研究项目的主题、资料来源和关键概念。

这里要注意事实边界。AI 可以总结和推断，但不能把推断伪装成已确认事实。最好明确标注：“从现有材料推断”“待用户确认”“已在项目文件中明确出现”。

第四步，反向生成规则。

已有项目里往往隐藏着许多规则。代码风格、命名习惯、目录约定、写作语气、术语用法、发布流程，可能没有单独成文，但已经体现在文件中。AI 可以把这些隐含规则整理到 conventions/。

这一步很有价值。因为一旦隐含规则显性化，后续 AI 就更容易遵守项目风格，而不是每次靠猜。

第五步，建立索引和路由。

已有项目通常最缺的不是内容，而是入口。AI 不知道从哪里读起，人类也不一定清楚哪个文件代表最新状态。通过 AGENTS.md 或目录索引，可以建立清晰路由：项目总览在哪里，最终成果在哪里，素材在哪里，历史版本在哪里，哪些文件不要动。

第六步，设计后续任务流程。

反向整理完成后，才适合进入具体任务：续写、重构、审校、开发新功能、整理资料、生成发布稿。此时 AI 已经不是面对一堆陌生文件，而是面对一个有背景、有规则、有路由的工作区。

反向 ACW 化尤其适合几类场景。

第一，长期写作项目。

很多写作项目的问题不是没有正文，而是版本混乱、设定散落、风格不稳、审校记录缺失。把正文放进 projects/，把设定和长期素材整理到 background/，把写作规则放进 conventions/，后续续写和修订会稳定很多。

第二，软件工程。

AI 直接进入一个代码库修改，风险很高。它需要知道项目结构、技术栈、测试命令、代码风格、禁止修改区域、部署约束。反向 ACW 化可以先把这些信息整理出来，再让 AI 做具体开发。

第三，知识库和研究项目。

大量资料如果没有结构，AI 只能做局部总结。通过 ACW，可以把资料来源、主题分类、引用规则、观点沉淀、报告产物分开管理。

第四，内容生产流水线。

视频、图文、课程、直播、社群运营，都有可复用流程。选题、脚本、素材、发布、复盘，不应该每次从头开始。反向整理已有内容后，AI 可以更好地延续账号定位和内容风格。

反向 ACW 化的核心，不是把旧文件搬家，而是提炼项目的上下文结构。

有哪些内容是稳定背景？有哪些规则应该长期遵守？哪些文件是最终成果？哪些只是过程记录？哪些命名和目录会误导 AI？哪些信息需要人工确认？

这些问题回答清楚后，已有项目就从“文件堆”变成了“工作区”。

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

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 都知道如何进入项目、如何找到上下文、如何执行任务、如何检查结果、如何把经验沉淀回工作区。

尾声：从说清楚，到沉淀清楚

AI 时代，很多人把注意力放在“如何说清楚”上。

这当然重要。你越能清楚表达目标、背景、约束和标准，AI 越容易给出有用答案。Prompt 能力仍然是基础能力。

但只会说清楚，还不够。

复杂任务不是一次说清楚就能完成的。它会变，会返工，会积累材料，会产生版本，会遇到错误，会出现新的规则。你今天说清楚的东西，如果没有沉淀，明天还要再说一次。你这次纠正的错误，如果没有变成规则，下次还会再犯。

所以更重要的能力，是沉淀清楚。

把稳定背景沉淀到 background/。

把协作规则沉淀到 conventions/。

把任务过程沉淀到 artifacts/。

把最终成果沉淀到 projects/。

把临时材料放进 tmp/，不要污染长期上下文。

把入口文件写成地图，而不是垃圾桶。

把 AI 的错误转化为规则，把一次任务的经验转化为模板，把临时对话中的有效信息转化为可复用上下文。

这就是 ACW 的核心。

它不神秘，也不昂贵。它只是要求我们承认一件事：AI 协作不是只有“提问”和“回答”，它也需要项目管理、知识组织、流程设计和质量验证。

当你开始这样工作，AI 的角色会发生变化。

它不再只是一个聊天窗口里的回答者，而是一个能进入项目、读取背景、遵守规则、留下过程、产出成果、接受审校并持续改进的协作者。它仍然会犯错，仍然需要人类判断，仍然不能替代责任。但它可以在一个更清楚的环境里工作。

而你要做的，也不只是写出更长、更复杂、更漂亮的 Prompt。

你要搭一张桌子。

桌子上有地图，有资料，有规则，有草稿，有成品，有检查清单。每一次协作结束后，桌面不会清空，而是变得更有秩序。下一次 AI 进来时，不必从零开始。

这就是从 Prompt 到 ACW 的升级。

从说清楚，到沉淀清楚。

从一次回答，到长期协作。

从临场聊天，到工程结构。