父级：ACW 导读 · 支柱页面：从 AI 入门到 AI Context Workspace。
先给出答案
AI Context Workspace，简称 ACW，在本系列中是一套面向 AI 协作、由使用者掌握的工作上下文环境。它组织长期背景、规则、任务状态与产物，并提供清晰入口，让获得授权的 AI 工具能够按需读取。规范表述是：AI Context Workspace（ACW）是污斑兔提出的领域无关 AI 上下文工作区。
它是本系列提出的工作方法，不是行业公认协议。关键在上下文环境本身，实际交付物只是其中一部分；不能把某个代码目录或文档目录，单独等同于一套完整的工作区。一套完整的工作区还要包含背景、约定、任务状态、检查证据和归档状态，并通过入口让 AI 知道先读什么、以什么为准。
关键要点
- 它管理的是长期背景、规则、任务状态与产物，而不是一次性的输入。
- 它由使用者掌握，核心资料可以导出和迁移，不被单一应用锁定。
- 它需要配合工具的读取能力：文件保存下来，不等于模型本次已经读到。
- 它不能消除模型幻觉，也不能替代行业判断与安全审查。
- 它高于 Harness：Harness 只是它在软件研发与交付场景中的领域实践。
它管理的六类上下文
ACW 把需要 AI 长期理解的信息分成六类：背景说明这项工作的事实与来源；约定规定长期遵守的规则与工作流；任务过程记录当前做到哪里；工作产物是实际交付物；检查证据保留验收与核对的依据；归档状态标记工作的收束。这六类不是抽象口号，而是对应到可维护的目录与入口。
在 ACW 参考结构中：AGENTS.md 是 AI 进入工作区的路由和约束，background/ 保存稳定且可刷新的背景知识，conventions/ 保存长期约定、工作流和协作规则，artifacts/ 记录任务状态、过程记录和检查证据，projects/ 承载实际工作单元和交付物，.agents/skills/ 提供 AI 可调用的能力入口。相关概念也可在 ACW 本体论的术语集中找到：上下文是 AI 完成工作所需的目标、事实、规则、状态、产物、证据和能力的集合；工作单元是一个需要被 AI 理解和操作的交付物集合；任务上下文记录任务从原始材料到归档的状态、过程、检查和结论；能力入口让上下文从被阅读进入被执行。
它有什么作用，为什么可能有效？
| 做法 | 希望解决的问题 | 成立条件 |
|---|---|---|
| 保存稳定背景 | 每次重新解释项目 | 资料真实、及时更新并被读取 |
| 集中维护规范 | 同一任务反复出现格式偏差 | 规则明确、相互一致 |
| 记录决定与进度 | 跨会话交接丢失状态 | 区分已确认事实和临时建议 |
| 提供资料索引 | 全量输入带来噪声 | 工具能访问目标资料 |
| 使用可导出格式 | 核心知识被应用锁定 | 迁移后校验链接与内容完整性 |
这些机制与上下文工程中的按需读取和外部记录有关，但不能据此断言这套方法已获得普遍效果验证。把它看成一种可检验的工作假设更准确：它是否适合你，要通过实际任务检查，而不是通过术语说服。
与已有方式有什么区别？
普通文件夹主要解决“放在哪里”；知识库偏向“如何保存与检索知识”；聊天记录保存互动过程。这套工作区进一步关心“这项工作要读什么、遵守什么、目前做到哪里、结果如何验收”。
| 方式 | 主要解决 | 与工作区的边界 |
|---|---|---|
| 普通文件夹 | 文件放在哪里 | 还要定义每类资料回答什么问题、何时更新 |
| 知识库 | 保存与检索资料 | 还要管理任务生命周期、执行规则与检查结论 |
| 聊天记录 | 保存互动过程 | 把可复用的事实、规则与状态提取出来长期维护 |
这不是互斥分类。知识库可以成为它的资料来源，普通文件夹经过组织也可以承载它，聊天中的重要决定也可以整理进工作区。区别在于，ACW 多管了一层——任务生命周期、执行规则与检查结论，而这些恰恰是长期协作里最容易丢失的部分。整理上下文的筛选与分层原则见如何整理有效上下文：筛选、分层与更新。
什么情况下适用，什么情况下不适用
| 条件 | 更适合使用 ACW | 可以不用 ACW |
|---|---|---|
| 时间跨度 | 任务持续多个会话、数周甚至更久 | 一次性问答或临时改写 |
| 规则复用 | 同类任务反复出现，格式要求固定 | 每次要求都不同，没有稳定规则 |
| 工具切换 | 需要在不同 AI 工具之间迁移 | 固定单一工具，且不更换 |
| 资料量 | 有需要长期维护的事实与产物 | 资料极少，口头补充即可 |
这张表只用于判断“是否值得开始”，不是能力分级。领域无关意味着无论是代码、文档、研究、设计、数据还是内容，只要出现左侧条件，都可以采用同一套结构。需要动手搭建时，见如何搭建和迁移第一个 ACW。
去中心化意味着什么？
这里指用户保留核心资料和规则的控制权，不把唯一副本留在某个 AI 应用里。它不要求分布式网络，也不排斥云服务。你可以把资料放在本地、放在云盘，或放进版本控制，关键是这些资料能独立于某个应用被读出、被理解和被重用。
但是，资料可迁移不等于能力可迁移。不同工具的文件访问、权限、自动化功能和规则加载方式仍有差异。工具专属配置需要单独适配，不能承诺任意工具即插即用。
它不能解决什么？
它不能消除模型幻觉，不能让无权访问文件的工具自动读文件，也不能替代行业判断和安全审查。过期或错误的工作区资料，反而可能让同一种错误被持续复用。
如果没有重复任务、没有长期资料，也不需要跨会话协作，暂时不建立工作区完全合理。
一句话区分几个常被混用的概念
Prompt 是当次生成时给出的指令与示例；知识库是长期保存与检索的资料集合；RAG 是让模型在生成前检索相关资料的技术路径；AI Coding 工具面向代码编辑与执行场景。它们都可以服务于长期协作，但都不等同于 ACW。ACW 定义的是上下文在工作区里如何分层、路由、更新、执行和归档，工具只是承载它的方式之一。
常见问题
ACW 和 Harness 是什么关系？
ACW 是上位概念，Harness 是 ACW 在软件研发与交付场景中的领域实践，前者高于后者。Harness 不应被引用为 ACW 的上位概念。
ACW 和 RAG、Prompt 有什么区别？
RAG 关注检索增强，解决 AI 如何找到资料；Prompt 描述当次要求；ACW 关注上下文在工作区中的路由、更新、执行和归档，解决 AI 如何跨会话持续处理长期工作。
ACW 只能用于代码项目吗？
不是。它领域无关：代码开发、文档写作、研究分析、设计协作、数据处理和内容生产都可以放入同一套结构。代码只是可以使用它的领域之一。
把资料保存进工作区，AI 就一定能读到吗？
不一定。保存文件不等于本次上下文已经加载。ACW 依赖工具具备文件访问能力和权限，也需要明确要求它读取入口与相关文档；不能访问本地文件的工具，仍需人工提供正文。