如何搭建和迁移第一个 ACW

父级：ACW 导读 · 支柱页面：从 AI 入门到 AI Context Workspace。

先给出答案

第一个 ACW 不需要复杂平台。选一个会持续推进的项目，把稳定背景、规则、当前任务和产物分开，再提供一个简短阅读入口。最后用新会话检查：没有旧聊天记录，工作能否继续。

本篇给出手工搭建方法，不依赖某个 AI 产品，也不假定应用会自动识别特定文件名。按照下面的步骤，你会在一次真实任务中走完“建结构、写入口、做任务、验交接”的全过程。

关键要点

• 只围绕一个项目开始，不要一开始混入所有工作、生活和客户资料。
• 最小结构只有四类：背景、约定、过程与产物，入口负责路由。
• 目录命名是示例，不是标准；复杂配置不是 ACW 成立的前提。
• 交接验收看的是 AI 能否依据实际文件说明状态，而不是能否复述目录。
• 迁移看的是资料能否独立保存、读取和重用，而不是输出一字不差。

第一步：只围绕一个项目

以个人技术博客为例，先明确读者是 AI 初学者，当前目标是完成一篇上下文入门文章。不要一开始混入所有工作、生活和客户资料，否则访问边界和信息相关性都会变得难以管理。

选择第一个项目的标准可以概括为三条：任务会持续推进、结果需要人工判断是否正确、已经存在可复用的规则或资料。满足这三条，沉淀一次就能反复受益；不满足，工作区可能只是摆设。

第二步：建立最小目录

my-blog--acw/
  README.md
  background/
    读者与定位.md
  conventions/
    写作与审核规范.md
  artifacts/
    当前任务.md
    决策记录.md
  projects/
    上下文入门文章.md

background/ 保存长期背景，conventions/ 保存规则，artifacts/ 保存过程与状态，projects/ 承载实际交付物。整个 my-blog--acw/ 才是工作上下文环境，projects/ 只是其中一部分。

这套命名是示例，不是必需标准。它对应 ACW 参考结构的简化版本：稳定背景、长期约定、任务状态与检查证据、实际产物各有归属。只有需要脚本或工具专属能力时，再增加对应配置；不要把复杂配置当作 ACW 成立的前提。

第三步：写一个短入口

在 README.md 中描述阅读顺序，例如：

# 博客工作入口

- 了解项目：[读者与定位](background/读者与定位.md)
- 开始写作前：[写作与审核规范](conventions/写作与审核规范.md)
- 接续任务：[当前任务](artifacts/当前任务.md)
- 核查已确认决定：[决策记录](artifacts/决策记录.md)
- 编辑文章：[上下文入门文章](projects/上下文入门文章.md)

资料冲突时先列出冲突；未经确认，不公开发布文章。

入口只负责路由，具体内容放在对应文档。例如，“当前任务”写清楚目标、已完成事项、待办与验收条件，“决策记录”区分确认结论和待确认问题。一个好的入口，应该让新读者（包括一个全新的 AI 会话）读完后知道：这项工作是什么、要遵守什么、现在做到哪里、下一步做什么。

第四步：完成一次真实任务

先确认 AI 工具有访问该目录的能力和权限，然后明确要求它读取入口与相关文档，再起草文章提纲。若工具不能访问本地文件，就手动提供必要正文，不要以为发送本地路径就完成了读取。

核查输出是否符合定位、是否使用正确来源。任务结束后，经确认再更新状态，避免让未经审核的草稿自动成为下一轮的背景事实。这一步与如何完成第一个可验收的 AI 任务的思路一致：任务要小到你能独立判断结果是否正确。

第五步：检查交接和迁移

开启不含旧对话的新会话，提供同一套资料，请 AI 说明当前目标、写作限制、已完成事项和下一步，并列出对应文件依据。逐项对照原文，不只看它能否复述目录。

换工具时，先备份核心资料，再确认文件格式、相对链接、访问权限和专属规则是否兼容。若新工具不能写文件，仍可以读取后给出建议，由人完成保存。

“去中心化”的验收重点是资料能否独立保存、读取和重用，不是迁移后输出一字不差。关于去中心化的含义与边界，见什么是 ACW：作用、原理与适用边界。

常见误区对照

把方法对应到六类上下文

回顾什么是 ACW：作用、原理与适用边界里的划分，这套最小结构其实已经覆盖了六类上下文：读者与定位是背景，写作与审核规范是约定，当前任务与决策记录承担任务过程和检查证据，文章本身是工作产物，任务完成后的状态标记属于归档。你不需要一次写全，只要每类内容有明确的唯一位置即可。

维护与安全

资料变动时更新唯一权威位置，定期备份。不要在共享工作区中存放 API Key、密码和未经授权的客户原文。本地保存也不等于本地处理；使用云端模型前，仍要确认传输范围和服务的数据政策。

维护的关键是“唯一权威”：同一事实只在一个位置维护，其他地方引用它，而不是复制它。复制出来的副本越多，冲突和过期信息就越多，AI 读到旧版本的几率也越高。整理上下文的筛选与分层原则见如何整理有效上下文：筛选、分层与更新。

常见问题

第一个 ACW 需要专门的软件或平台吗？

不需要。一个入口文件和几个目录即可开始。工具只是读取和写入资料的方式，手工结构同样可以工作。

目录名称必须和示例一致吗？

不必。示例命名只是为了说明四类内容的分工：背景、约定、过程与产物。真正重要的是每类内容回答什么问题、何时更新。

怎么判断第一个 ACW 算搭建完成？

用不含旧对话的新会话做一次交接测试：提供入口后，AI 能依据实际文件说明当前目标、限制、进度与下一步，并能指出对应文件依据。如果它只能复述目录，却说不清限制和下一步，说明资料还没有真正进入可用状态，需要补写关键文档。

工作区可以放多少资料？

以任务相关性为准，不是越多越好。有效上下文是为当前任务提供足够、相关、可信且不冲突的信息；全量输入反而带来噪声。先放已经反复使用的资料，再在遇到具体困难时增补。