从写作工作区看通用结构

09 从写作工作区看通用结构

标题备选

• 用写一本书，讲清楚 ACW 的通用结构
• AI 写作工作区怎么搭？其实能迁移到所有复杂任务
• ACW 的通用性，来自职责分离

开场钩子

写作是理解 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 写风格和术语。

一本书最怕前后语气不一致，术语不断漂移。

比如在 ACW 里，artifacts 必须指过程产物，projects 必须指成果层和项目层，conventions 必须指协作规则和流程标准。

如果这些术语不稳定，读者会被带乱，AI 也会被带乱。

manuscript 放正式正文。

这是最终产物所在的位置。正文可以是一个文件，也可以按章节拆分。

关键是让 AI 和人类都知道：这里是当前有效书稿，不是过程草稿。

materials 放长期素材。

它可以保存观点、案例、术语表、待确认事项、读者问题、后续扩写方向。

references 放参考资料入口。

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

submission 放交付信息。

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

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

比如一次起草任务，可以有 raw-input、requirements、structure、writing-spec、drafting、review。

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

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

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

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

再迁移到研究项目。

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

再迁移到运营账号。

projects 放内容日历、已发布稿件、选题库。

background 放账号定位、受众画像、平台规则。

conventions 放标题规则、内容禁区、审核流程。

artifacts 放每次选题会、脚本草稿、复盘报告。

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

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

最终成果是什么？

稳定背景是什么？

协作规则是什么？

过程如何留痕？

临时材料如何处理？

新任务如何接续旧任务？

结尾引导

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

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

下一集，我们讲一个更常见的情况：已经有一堆旧项目了，怎么反向 ACW 化？