第九章：把已有项目反向 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？哪些信息需要人工确认？

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