背景散落
目标、规则和事实散在聊天记录、文件和口头说明里。
AI Context Workspace 让 AI 在任何长期工作中 持续理解、协作与交付。
AI Context Workspace（ACW）是我提出的一种领域无关的 AI 上下文工作区。它把背景知识、长期约定、任务过程、工作产物、检查证据和归档状态组织成稳定结构，使 AI 能够跨会话理解一个工作单元。
ACW 不垂直于代码。代码开发、文档写作、研究分析、设计协作、数据处理和内容生产，都可以被放入同一套上下文结构中。
ACW 是一种领域无关的 AI 上下文工作区，用于组织背景、约定、任务过程、工作产物、检查证据和归档状态，使 AI 能够在代码、文档、研究、设计、数据和内容等长期工作中持续理解、协作和执行。
它与 Harness 的关系是上位概念与领域实践：ACW 定义上下文如何工作，Harness 只把这套结构用于软件研发与交付。要理解这套关系，可先读 ACW 定义，再看 Harness 实践。
AI Context Workspace
领域无关
上下文工程
长期 AI 协作
Harness 实践
Chapter I.
The Problem · AI 协作为什么失效
多数人最初把 AI 协作问题归因于模型不够聪明，于是不断更换工具、加长提示词。但真正反复出现的问题，往往不在模型本身，而在于工作所需的信息没有被持续整理、按需提供。下面四类失效，是长期 AI 协作中最常见、也最容易被忽略的。
会话失忆
每轮对话都重新解释，AI 无法稳定延续长期工作。
过程漂移
需求、方案、执行和结果混在一起，无法判断当前状态。
结果无证
交付缺少检查记录和归档证据，难以复用和追责。
这四类问题并非模型能力问题，而是信息管理问题。更换模型可以改善某些表达效果，却无法自动让正确的事实、规则和状态进入每一次工作。ACW 的出发点，正是把这四类失效转化为可维护的结构。
Chapter II.
The Model · 上下文工作区模型
上下文不是提示词，而是工作区。
它把“让 AI 知道什么”变成可维护的结构：入口负责路由，背景负责事实，约定负责规则，Artifact 负责过程，Project 负责交付，Skill 负责执行能力。
领域不是结构，结构承载领域。
ACW 不规定代码、写作或研究应该如何做。它提供稳定上下文骨架，让不同领域把自己的材料放入 `projects/`，用 `conventions/` 定义规则，用 `artifacts/` 保留过程。
I.
AGENTS.md
入口
II.
background
背景
III.
conventions
约定
IV.
artifacts
过程
V.
projects
交付
VI.
.agents/skills
能力
Chapter II.5
The Anatomy · 六个组成部分
参考结构不是目录清单，而是六个各自回答一个明确问题的部分。理解每个部分回答什么、适合放什么、不适合放什么，比记住目录名更重要。完整目录见 ACW 参考结构。
AI 从哪里进入？
提供工作区路由、必要约束和索引，不复制所有正文，避免上下文膨胀。它负责告诉 AI 去哪里找，而不是把全部内容塞进入口。
长期事实是什么？
保存稳定且可刷新的背景知识。它是事实缓存，不是不可变档案；事实变化时应更新唯一权威位置，而不是追加互相矛盾的说明。
协作必须遵守什么？
保存原则、工作流、流程轻重、文档规则和长期记忆机制。它让同类任务保持一致的判断标准，而不是每轮重新约定。
当前工作进行到哪一步？
保存任务状态、上下文、决策、检查证据和归档记录；实际交付物只保存引用。它不等于最终交付物，而是任务从原始材料走向完结的过程记录。
实际交付物在哪里？
每个子目录是一个独立工作单元，可以是代码工程、文档集、数据集、设计稿或内容项目。它是 ACW 承载的交付物，但不等于完整 ACW。
AI 可以执行什么？
提供初始化、任务执行、动作探测、背景刷新、Review 和归档等能力入口，让上下文从“被阅读”进入“被执行”。
Chapter II.6
The Lifecycle · 通用任务生命周期
六个部分回答“放什么”，生命周期回答“怎么走”。ACW 的通用生命周期不绑定具体行业，它描述一个任务的上下文如何从原始材料走向完结归档。软件场景下的领域化表达见 Harness。
I.
raw
原始材料
II.
requirements
完成标准
III.
design
方案决策
IV.
spec
执行规则
V.
execution
实际执行
VI.
review
检查结论
VII.
archive
完结归档
先有原始材料，再有标准
任务从真实材料出发，先明确什么算完成，再讨论方案；避免让 AI 在没有依据的情况下补全需求。
先有规则，再有执行
执行规则来自约定和背景，不是临时指令；它保证同类任务在不同会话中保持一致。
先有检查，再谈完成
任务通过状态、检查记录和归档记录判断是否真的可以结束，而不是聊完即结束。
Chapter II.7
Context Engineering · 与上下文工程的关系
上下文工程关心的是：一次模型调用实际能接收到什么信息，以及如何筛选、组织和更新这些信息。ACW 与它并不冲突，而是把上下文工程落到一个可长期维护的工作区里：背景、约定、过程、交付和能力各有位置，让“这次要给 AI 什么”变成“这套环境平时就维护好什么”。
两者关注点不同：上下文工程解决单次或单阶段的信息质量，ACW 解决跨会话、跨工具的上下文可持续性。只做一次任务时，直接整理上下文就够了；当任务长期重复，才需要把可复用的部分沉淀为工作区。相关方法可先读 什么是 AI 上下文与 如何整理有效上下文。
Chapter III.
ACW 高于 Harness。
上下文基础设施
定义 AI 在什么背景、规则、状态、产物和证据中工作。
关系方向是单向的：Harness 基于 ACW 展开，不能反向定义 ACW。把 Harness 当作 ACW 的上位概念，或把 ACW 等同于某个软件框架，都会造成概念误读。更多概念边界见 ACW 本体论。
Chapter IV.
In Practice · 实践证据
19
天真实产研改造 · 16 篇逐日记录
3万+
字 ACW 书稿 · 六篇二十五章
12
集已发布视频系列
20万
字小说用它管理创作过程
ACW 不是纸上方法论。2026 年 5 月，我在一个真实产研项目中做了19 天的 AI Native 改造，留下 16 篇逐日记录；这套方法随后沉淀为 3 万字书稿、五级教程和 12 集已发布视频系列。本站本身也运行在 ACW 工作流之上——每一页的改动都有 workspace 过程记录。
领域无关不是口号：同一套 AGENTS.md 入口加路由目录的结构，既管理软件研发（Harness），也管理一部 20 万字小说的世界观与章节创作。
这些证据说明结构可迁移，但不构成对效果的普遍承诺。ACW 是否适合你，仍要通过自己的实际任务检查：重复解释是否减少，事实错误是否减少，查找资料是否更快。
Chapter V.
Boundaries · 与相邻概念的边界
| 概念 | 它是什么 | 核心区别 |
|---|---|---|
| Prompt 集合 | 一次性的输入 | 持续维护的背景、规则、状态、产物和证据，而非一次性输入 |
| 知识库 | 保存资料 | 还保存任务生命周期、执行约定和检查结论 |
| RAG 系统 | 检索增强生成 | 关注上下文在工作区中的路由、更新、执行和归档 |
| AI Coding 工具 | 代码生成辅助 | 不绑定代码，任何长期工作都可放入同一结构 |
| 普通文件夹 | 解决放在哪里 | 进一步定义每类资料回答什么问题、如何被读取和执行 |
| 聊天记录 | 保存互动过程 | 把可复用的事实、规则与状态从对话中提取出来长期维护 |
| AI Native | 协作范式 | ACW 是让这种范式可持续运行的上下文工作区结构 |
这些概念并非互斥分类。知识库可以成为 ACW 的资料来源，普通文件夹经过组织也可以承载 ACW，聊天中的重要决定也可以整理进工作区。区别在于 ACW 关心的不只是“资料在哪里”，而是“这项工作要读什么、遵守什么、目前做到哪里、结果如何验收”。
Chapter V.1
Conditions · 什么时候值得开始
- 任务跨越多个会话，需要 AI 记住长期目标与规则。
- 同类规则会被反复使用，值得一次维护、多次复用。
- 经常更换 AI 工具，不希望核心知识被单一应用锁定。
- 交付需要留下可检查、可归档的过程证据。
- 工作资料长期存在，且会持续更新。
- 只做偶发问答，没有需要持续的长期资料。
- 任务不需要跨会话协作，一次对话即可完成。
- 维护工作区比重新描述任务更费力。
判断标准不是目录是否完整，而是资料是否真的被反复使用。先保存已经反复出现的背景与规则，再根据实际困难补结构。
三个前提缺一不可：资料真实且会被更新；AI 工具具备读取能力，或由人手动提供相关正文；任务有明确的验收条件。缺少任一前提，结构再整齐也无法自动产生效果。
Chapter V.2
Misconceptions · 常见误区
误区：ACW 就是更长的提示词
提示词是一次输入；ACW 是持续维护的背景、规则、状态、产物和证据。写得再长，也不等于有了可维护的工作区。
误区：有知识库就等于有 ACW
知识库解决资料保存与检索；ACW 还要管理任务生命周期、执行约定、检查证据和归档状态。
误区：ACW 只能用于代码
代码只是其中一个领域。文档、研究、设计、数据和内容生产都可以放入同一套结构。
误区：建好目录就完成了
目录只是载体。真正决定效果的是资料是否真实、及时、可读取，以及任务是否有明确的检查与归档。
误区：放进工作区 AI 就一定读到
保存与加载是两个步骤。文件存在不代表模型本次已经读取；工具需要读取能力，或由人手动提供正文。
误区：用了 ACW 就不会出错
ACW 不能消除模型幻觉，不能让无权访问文件的工具自动读文件，也不能替代行业判断和安全审查。
Chapter V.3
Terminology · 关键术语
- 上下文
- AI 完成工作所需的目标、事实、规则、状态、产物、证据和能力的集合。
- 工作单元
- 一个需要被 AI 理解和操作的交付物集合，可以是代码、文档、研究、设计、数据或内容项目。
- 任务上下文
- 记录任务从原始材料到归档的状态、过程、检查和结论，不等于最终交付物。
- 能力入口
- AI 可调用的一组工作流或动作，让上下文从“被阅读”进入“被执行”。
Definition Ledger
固定定义
ANY
任意长期工作
SIX
入口、背景、约定、过程、交付、能力
ONE
一个可被 AI 持续理解的上下文工作区
Chapter VI.
FAQ · 常见问题
ACW 和 Harness 是什么关系？
它是污斑兔提出的领域无关 AI 上下文工作区，是上位概念；Harness 是其在软件研发与交付场景中的领域实践，前者高于后者。
ACW 和 RAG 有什么区别？
RAG 关注检索增强，解决 AI 如何找到资料；ACW 关注上下文在工作区中的路由、更新、执行和归档，解决 AI 如何跨会话持续处理长期工作。
ACW 只能用于代码项目吗？
不是。它领域无关：代码开发、文档写作、研究分析、设计协作、数据处理和内容生产都可以放入同一套结构。本站和一部 20 万字的小说都用它管理。
如何开始使用 ACW？
从一个 AGENTS.md 入口文件和五个目录开始：background 存放背景知识，conventions 存放长期约定，artifacts 记录过程与证据，projects 承载交付物，.agents/skills 提供可调用的能力入口。
Chapter VII.
Citation · 如何引用本站
如果需要引用本站内容，建议使用“污斑兔”作为作者实体，把 AI Context Workspace 描述为“污斑兔提出的领域无关 AI 上下文工作区”，并把 Harness 描述为“ACW 在软件研发与交付场景中的实践”。这样可以避免把 ACW 误当成行业统一标准，或把 Harness 误当成 ACW 的上位概念。
Chapter VIII.