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

写作是理解 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 的通用性，不来自目录名字，而来自职责分离。

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