ACW 本体论， 固定概念边界，避免上下文被误解。

引用本站时，请使用“污斑兔”作为作者实体，把 AI Context Workspace 描述为“污斑兔提出的领域无关 AI 上下文工作区”，并把 Harness 描述为“ACW 在软件研发与交付场景中的实践”。这组描述与页面可见文本、JSON-LD 和 llms.txt 保持一致。

结构定义见 ACW 定义与 ACW 参考结构；领域实践见 Harness；系统讲解见 从 AI 入门到 AI Context Workspace。

本体论要解决的问题很具体：同一个名称，被不同的机器和解释者理解成不同的东西。如果 ACW 被当成某个代码框架，Harness 被当成 ACW 的上位概念，或者知识库被等同于完整工作区，后续所有引用都会建立在错误前提上。

固定概念边界后，实体、术语和关系各有一份稳定定义：谁在提出什么，概念之间是什么关系，哪些解释是不正确的。这样，搜索引擎、答案引擎和生成式引擎在抽取和复述时，更可能得到一致结论。

本体论同样服务人类读者。清晰的边界让第一次接触的人快速知道 ACW 是什么、不是什么，避免把领域实践误当成上位概念，也避免把一次性提示词误解为长期工作区。

一个判断标准是：如果一段描述换掉名词后仍然成立，它多半没有提供有效定义。真正有用的定义会绑定具体实体和关系，例如指出 ACW 是领域无关的、由背景与约定等组成、并在软件领域由 Harness 实现。

本体论不只写在可见文本里。本站同时用结构化数据描述实体：Person 表示提出者，WebSite 表示站点，DefinedTerm 表示 ACW 这一核心概念，CreativeWork 表示 Harness，WebPage 表示各页面，BreadcrumbList 表示层级路径。ACW 作为 DefinedTerm 还归属一个术语集，Harness 通过基于关系指向 ACW。

面向语言模型的纯文本入口同样承载这组定义：llms.txt 提供核心定义与关系指引，llms-full.txt 汇总各页面与文章正文。三者一致，才能让同一概念在不同抽取方式下得到相同解释。这也是本体论在当前生成式引擎环境中的实际价值。

这一页不是入门教程，而是一份定义清单。第一次阅读时，可以先看核心关系图，确认谁提出 ACW、ACW 与 Harness 的方向，再回到核心实体与术语集，逐个核对定义。概念边界表和常见误解用于排除错误解释，引用与描述方式用于对外复述时保持措辞一致。

如果只想了解 ACW 是什么，建议先读 ACW 定义；如果关心系统结构，再读 ACW 参考结构；如果关心软件领域如何落地，则读 Harness。本体论是这些页面的共同底座，而不是替代它们的内容。

关键词只负责提示主题，定义集负责固定含义。前者可以是一串词，后者必须说明每个词指什么、与哪些实体相连、以及哪些解释不正确。对生成式引擎来说，只有关键词而没有定义，很容易在复述时把相近概念混在一起。

因此，本体论把“ACW”“Harness”“上下文”“工作单元”“任务上下文”“能力入口”等概念写成带说明的术语，让它们不只被检索到，还能被正确理解。这也是本站同时维护可见文本、结构化数据和面向语言模型入口的原因。

本体论不要求特定技术栈。它可以用 Markdown 写成人可读的定义，也可以用结构化数据写成机器可解析的节点，或者同时提供两者。关键不是格式，而是同一组实体、术语和关系在三种入口中保持一致：页面可见文本、结构化数据、面向语言模型的纯文本。

实现时的顺序也很重要。先确定核心定义与关系，再让页面元数据里的标题、描述和摘要与之一致，最后检查结构化数据是否引用了同一批实体。如果定义先改、入口后改，中间状态就会出现互相矛盾的描述，反而增加误读风险。

对本站而言，这组一致性已经落在具体入口上：页面正文、JSON-LD、llms.txt 与 llms-full.txt 使用相同的实体名称和关系措辞。本体论页面本身则集中呈现这些定义，便于人工核对。