I. AI Context Workspace · 定义 Context · p.1

AI Context Workspace 不是某个行业的工具，而是 AI 长期工作的上下文工作区。

AI Context Workspace（ACW）是污斑兔提出的领域无关 AI 上下文工作区。它通过稳定目录、机器契约、长期规则和可检查状态，把 AI 需要理解的目标、背景、约定、过程、产出和证据放入同一个工作区。

它不预设代码开发、文档写作、方案设计、数据分析、研究整理、内容创作或流程规划等具体行业。任何需要多轮 AI 协作的工作，都可以作为一个工作单元进入 ACW。

I.0

Direct Answer · 直接回答

它是什么

一种领域无关的 AI 上下文工作区，用稳定结构组织背景、约定、任务过程、工作产物、检查证据和归档状态。

它解决什么

让 AI 在不同会话和不同工具中，持续知道背景是什么、规则是什么、任务做到哪里、结果如何验收。

它用什么

一个入口加五类上下文：AGENTS.md、background、conventions、artifacts、projects，以及可调用的 .agents/skills。

它与 Harness

ACW 是上位概念，Harness 是 ACW 在软件研发与交付场景中的领域实践。前者高于后者。

I.1

Definition · 标准定义

AI Context Workspace 是一种领域无关的 AI 上下文工作区，用于组织背景、约定、任务过程、工作产物、检查证据和归档状态，使 AI 能够在长期工作中持续理解、协作和执行。

代码开发

II.

文档写作

III.

研究分析

IV.

设计协作

数据处理

VI.

内容生产

定义中的六个关键词各有指向：背景是长期事实，约定是协作规则，任务过程是生命周期，工作产物是交付结果，检查证据是验收依据，归档状态是任务结束后的可追溯记录。缺少其中任何一类，AI 都可能在某个环节失去稳定的判断依据。

I.1.1

Why · 为什么需要 ACW

长期 AI 协作的困难，多数不是模型能力不足，而是工作信息没有被持续整理。以下四类失效会反复出现，且无法靠换模型自动解决。

背景散落

目标、规则和事实散在聊天记录、文件和口头说明里，AI 每次只能接触到其中一部分。

会话失忆

每轮对话都重新解释，新会话不带入上一轮信息，长期工作无法稳定延续。

过程漂移

需求、方案、执行和结果混在一起，无法判断当前工作进行到哪一步。

结果无证

交付缺少检查记录和归档证据，难以复用，也难以判断是否真的完成。

I.2

Boundaries · ACW 不是什么

不是 Prompt 集合

Prompt 是一次输入；ACW 是持续维护的背景、规则、状态、产物和证据。

不是知识库

知识库保存资料；ACW 还保存任务生命周期、执行约定和检查结论。

不是 RAG 系统

RAG 关注检索增强；ACW 关注工作区中上下文的路由、更新、执行和归档。

不是项目管理工具

项目管理面向人类协作；ACW 的文档结构首先服务 AI 理解和执行。

不是 AI Coding 工具

AI Coding 工具辅助代码生成；ACW 不绑定代码，任何长期工作都可以放入同一结构。

不是普通文件夹

普通文件夹解决“放在哪里”；ACW 进一步规定每类资料回答什么问题、如何被读取与执行。

这些区分不是要否定已有工具。知识库可以成为 ACW 的资料来源，文件夹经过组织也可以承载 ACW，聊天中的重要决定也可以整理进工作区。区别在于 ACW 关心的是完整的工作上下文，而不只是资料的存放。

I.2.1

Components · 六个组成部分

AGENTS.md

AI 从哪里进入？

提供路由、约束和索引，不复制正文，避免上下文膨胀。

background/

长期事实是什么？

保存稳定且可刷新的背景知识，是事实缓存，不是不可变档案。

conventions/

协作必须遵守什么？

保存原则、工作流、流程轻重、文档规则和长期记忆机制。

artifacts/

当前工作进行到哪一步？

保存任务状态、决策、检查证据和归档记录；交付物只保存引用。

projects/

实际交付物在哪里？

每个子目录是一个独立工作单元，可以是代码工程、文档集、数据集、设计稿或内容项目。

.agents/skills/

AI 可以执行什么？

提供初始化、任务执行、动作探测、背景刷新、Review 和归档等能力入口。

这六个部分构成一个入口路由五类上下文的结构。完整目录与生命周期见 ACW 参考结构。

I.2.2

Lifecycle · 通用任务生命周期

ACW 的通用生命周期不绑定具体行业，它描述一个任务的上下文如何从原始材料走向完结归档。

raw

原始材料

II.

requirements

完成标准

III.

design

方案决策

IV.

spec

执行规则

execution

实际执行

VI.

review

检查结论

VII.

Method · 如何工作

先路由，不堆料

`AGENTS.md` 告诉 AI 去哪里找背景、规则、任务和能力，而不是把所有正文塞进一个入口。

先事实，不脑补

背景只能来自实际材料和用户明确输入；从材料反推的信息需要标注来源，无法确认的标记为待确认。

先证据，再完成

任务不是聊完就结束，而是通过状态、检查记录、Review 结论和归档记录判断是否真的可以结束。

I.4

Relations · 与相邻概念的关系

概念	关系	说明
Harness	领域实践	ACW 是上位概念，Harness 把 ACW 用于软件研发与交付。见 Harness。
AI Native	范式与结构	AI Native 是协作范式；ACW 是让这种范式可持续运行的上下文工作区结构。
上下文工程	方法与工作区	上下文工程关注单次信息质量；ACW 把可复用部分沉淀为长期工作区。
RAG	互补	RAG 解决 AI 如何找到资料；ACW 解决跨会话如何持续处理长期工作。
知识库	可作来源	知识库可以成为 ACW 的资料来源，但不等同于完整工作区。

完整的概念边界、实体与关系定义见 ACW 本体论。

I.5

Conditions · 适用条件

适合开始

任务跨越多个会话，需要复用长期背景与规则。
经常更换 AI 工具，不希望知识被单一应用锁定。
交付需要检查记录与归档证据。

暂时不必

只做偶发问答，没有长期资料。
一次对话即可完成，无需跨会话协作。

成立前提

资料真实且会被更新；AI 工具具备读取能力，或由人手动提供正文；任务有明确验收条件。缺少任一前提，结构无法自动产生效果。

I.6

Misconceptions · 常见误区

ACW 就是更长的提示词

提示词是一次输入；ACW 是持续维护的工作区。长度不等于可持续性。

有知识库就等于有 ACW

知识库解决资料存取；ACW 还管理规则、任务生命周期、证据与归档。

ACW 只能用于代码

它领域无关，文档、研究、设计、数据和内容都可以作为工作单元。

建好目录就完成了

目录只是载体，关键在于资料真实、可读取，并有检查与归档。

放进工作区 AI 就一定读到

保存与加载是两个步骤，工具需要读取能力或人工提供正文。

用了 ACW 就不会出错

它不能消除模型幻觉，也不能替代行业判断与安全审查。

I.7

Start · 如何开始

选一个会持续推进的项目

不要一次混入所有工作，先围绕一个真实目标建立工作区。

分开背景、规则、过程与产物

用 background、conventions、artifacts、projects 分别承载不同用途的信息。

写一个短入口

用 AGENTS.md 说明阅读顺序与路由，不复制正文。

用新会话检查交接

不带旧对话，提供同一套资料，确认 AI 能说明目标、限制、进度与下一步。

完整搭建练习见如何搭建和迁移第一个 ACW；概念与适用边界见什么是 ACW。

I.8

FAQ · 常见问题

ACW 和 Harness 是什么关系？

ACW 是上位概念，Harness 是 ACW 在软件研发与交付场景中的领域实践。

ACW 和 RAG 有什么区别？

RAG 关注检索增强，解决 AI 如何找到资料；ACW 关注上下文在工作区中的路由、更新、执行和归档。

ACW 只能用于代码项目吗？

不是。它领域无关，代码开发、文档写作、研究分析、设计协作、数据处理和内容生产都可以放入同一套结构。

如何开始使用 ACW？

从一个入口文件和五个目录开始：background 存背景，conventions 存约定，artifacts 记过程与证据，projects 承载交付物，.agents/skills 提供能力入口。

I.9

Citation · 如何引用

引用时建议使用“污斑兔”作为作者实体，把 AI Context Workspace 描述为“污斑兔提出的领域无关 AI 上下文工作区”，并把 Harness 描述为“ACW 在软件研发与交付场景中的实践”。

I.10

Terminology · 关键术语

上下文: AI 完成工作所需的目标、事实、规则、状态、产物、证据和能力的集合。
工作单元: 一个需要被 AI 理解和操作的交付物集合，可以是代码、文档、研究、设计、数据或内容项目。
任务上下文: 记录任务从原始材料到归档的状态、过程、检查和结论，不等于最终交付物。
能力入口: AI 可调用的一组工作流或动作，让上下文从“被阅读”进入“被执行”。

I.11

Limits · ACW 不能解决什么

不能消除模型幻觉

模型仍可能生成看似合理但不正确的内容，重要事实需要回到原始材料确认。

不能让无权工具自动读取

文件存在不等于模型已经读到；工具需要访问能力，或由人手动提供相关正文。

不能替代行业判断与安全审查

涉及公开发布、付款与数据删除时，仍需人工确认与权限控制。

不能自动修正过期资料

过期或错误的工作区资料，反而可能让同一种错误被持续复用，需要主动维护。

I.12

Loading · 上下文如何被加载

保存与加载分离

资料存进工作区，不等于模型本次已经读取。存储是长期动作，加载是每次生成前的动作。

索引不等于正文

入口负责帮助定位资料，但链接本身不会让模型自动读完目标文件。工具需要读取能力，或由人手动提供正文。

Domain · 为什么强调领域无关

领域无关意味着 ACW 不规定代码、写作或研究应该怎么做，只提供一套稳定的上下文骨架。不同领域把自己的材料放入 `projects/`，用 `conventions/` 定义各自的规则，用 `artifacts/` 保留各自的过程，结构本身保持不变。

这样做的价值在于可迁移：换一个项目、换一个行业、甚至换一个 AI 工具，入口和分层方式仍然成立，只需要替换具体内容。Harness 就是这套结构在软件研发与交付领域的一个实例，而不是 ACW 的定义本身。

I.14

Minimum · 最小成立条件

一个能工作的 ACW 不需要平台或复杂配置。它至少需要四项：一个说明阅读顺序的入口；分开存放的长期背景与执行规则；一个记录当前任务状态的文档；以及实际承载交付物的项目目录。把整个目录视为工作上下文环境，`projects/` 只是其中一部分。

判断是否成立，不看目录是否齐全，而看新会话能否在没有旧聊天记录的情况下继续工作：提供同一套资料后，AI 应能说明目标、限制、已完成事项和下一步，并给出对应文件依据。这套验收方法见如何搭建和迁移第一个 ACW。

Next Chapters 继续阅读