Wubuntu Tech & Life

每个任务都有一个生命周期。AI Context Workspace 用一套简单的状态机来管理它。 六个状态： pending → in_progress ↔ paused in_progress/paused → completed completed → in_progress (返工) pending/in_progress/paused → cancelled completed/accepted-review/cancelled → archived pending（待处理） ——任务已创建，但还没开始。适用于任务拆分后等待执行的情况。 in_progress（进行中） ——正在执行。这是任务的主要状态，大部分时间都在这里。 paused（暂停） ——因为阻塞、等待外部输入或优先级调整而暂停。暂停不是放弃，是"暂时不做"。 completed（完成） ——任务执行完毕，交付物已产出。但 completed 不等于"可以归档"，还需要通过 Review 门禁。 cancelled（取消） ——任务不再需要。取消不需要 Review，但需要记录取消原因。 archived（已归档） ——最终状态。任务通过 Review（PASS 或被接受的 REVIEW）后归档，或取消后归档。归档后不再修改，只可查阅。 状态机不是为了管控，而是为了恢复上下文。 想象一下：你半年后回到一个项目，打开 artifacts/index.json ，看到： 任务 A：in_progress 任务 B：paused 任务 C：archived (completed) 三行信息，你就知道：A 正在做，B 等着继续，C 已经完成。不需要问任何人，不需要读任何文档。这就是状态机的价值—— 让 AI 和人都不需要靠记忆理解当前局面。 状态转移的门禁 不是所有转移都允许。比如： completed 不能直接变成 archived，必须通过 Review（PASS 或 REVIEW+接受） archived 不能回到 in_progress，如果需要继续，创建新任务，用 parentArtifactId 关联 paused 不能直接 completed，必须先回到 in_progress 这些门禁不是官僚主义。...

不是所有任务都需要写文档、走流程、做 Review。一个拼写错误改三秒钟的事，你非要写一份需求文档，那是浪费。但一个数据库迁移你直接上手改，那是冒险。 所以 AI Context Workspace 定义了四个流程等级，AI 根据风险自主选择最轻但足够安全的等级。 L0——直接处理。 适用场景：明显的小错误、格式调整、无行为风险的单点修改。产出：最终总结和最小检查结果。不需要 Artifact，不需要记录，改完就行。 L1——快速执行。 适用场景：目标明确、范围局部、容易撤销、有直接检查方式。产出：执行摘要和检查结果。Artifact 可选，需要留痕时创建。 L2——标准执行。 适用场景：目标明确，但涉及多个步骤、外部约定或需要完整检查。产出：Artifact、requirements、spec、execution、review。这是最常见的等级。 L3——完整流程。 适用场景：关键目标无法确定、重大结构变化、高风险或难撤销。产出：完整阶段记录和风险说明。 怎么选？ 满足任一条件，至少用 L2： 修改对外约定、长期保存的数据、自动执行规则或多个相关工作单元 需要新增外部依赖、访问外部服务或改变重要数据 目标或完成标准存在需要显式记录但可以自行消除的歧义 缺少直接检查方式，但可以设计替代证据 满足任一条件，用 L3： 目标或完成标准存在无法自行消除的歧义 涉及权限、安全边界、不可逆或破坏性操作 对外约定或跨工作区变化影响重大且难以撤销 缺少可靠检查方式，且错误结果会产生明显损失 全部满足以下条件，才可以用 L0 或 L1： 用户目标明确，没有阻塞执行的开放问题 变化局部且容易撤销 不涉及数据、安全、权限、外部约定或不可逆操作 有可执行的最小检查，或能明确说明无法检查的原因和风险 核心原则：流程为任务服务，不是反过来。 很多项目管理方法的问题在于流程太重，导致大家为了走流程而走流程。AI Context Workspace 的流程等级设计是为了防止这个问题的——最低等级从 L0 开始，只有当你确认需要更重流程时，才升级。 这就像写代码：默认用最直接的方式实现，只有当复杂度达到一定程度时，才引入设计模式。不要一开始就想着用 Visitor 模式。

AI Context Workspace 定义了一个标准工作流，用于描述任务上下文从原始材料到完结归档的完整演变。 raw → requirements → design → spec → execution → review → archive 这不是瀑布模型。它不是要求你严格按顺序走完所有阶段，它是一个 上下文成熟度的标尺 。你的任务上下文当前处于哪个阶段，它应该回答什么问题，一目了然。 每个阶段的核心问题： raw（原始材料） ——用户实际提供了什么？一段文字、一个链接、一个需求描述、一段代码。不管是什么，先把它放在这里，不做任何加工。这个阶段的核心是"忠实记录来源"。 requirements（需求） ——什么结果才算完成？目标是什么？范围多大？边界在哪？有什么约束？完成标准是什么？这个阶段把模糊的想法变成可判断的完成标准。 design（设计） ——准备怎样达到目标？方案是什么？有哪些关键决策？做了哪些取舍？为什么选 A 不选 B？这个阶段产出的不是代码，而是"怎么做"的思考过程。 spec（规范） ——具体按什么约束执行？接口定义、数据格式、检查方式、执行步骤。这个阶段把设计转化为可执行的规则。 execution（执行） ——实际完成了什么？代码、文档、配置、数据。执行阶段产出的是实际交付物，以及执行过程的记录。 review（检查） ——结果是否满足完成标准？逐项核对需求阶段定义的完成标准，给出证据，得出结论。PASS 就归档，没过就返工。 archive（归档） ——是否可以结束这个任务？记录摘要、更新状态、移入冷存储。归档不是删除，是"标记为完结，内容可查"。 不是每个任务都需要走完所有阶段 一个简单的任务，比如"修复一个拼写错误"，直接从 raw 跳到 execution，然后 review 确认就归档了。不需要 requirements、design、spec。 一个复杂的任务，比如"设计新的数据库模型"，可能需要花大量时间在 design 和 spec 上，execution 反而很简单。 工作流的作用是提供一套共同语言，不是一套流程模板。 你说"这个任务在 design 阶段"，别人就知道...

AI Context Workspace 里所有的文件只有两种格式：Markdown 和 JSON。 Markdown 写给人看，也写给 AI 看。 背景文档、约定规范、任务说明，都用 Markdown。Markdown 是人类可读的纯文本，也是 AI 理解效率最高的格式之一。没有专有格式，没有二进制，没有需要渲染才能理解的富文本。 JSON 写给脚本看。 生命周期状态、检查结论、索引记录，都用 JSON。JSON 有固定字段，可以被脚本解析和校验，可以作为机器之间的契约。 为什么分开？ 因为状态和说明是两回事。 "这个任务完成了"是一个状态，应该用 JSON 记录，因为它可以被脚本读取、校验、转换。"这个任务是怎么完成的"是一个说明，应该用 Markdown 记录，因为它需要人（和 AI）阅读和理解。 如果把状态混在 Markdown 里，脚本就得解析 Markdown 才能拿到状态，容易出错，也不稳定。如果把说明塞进 JSON，JSON 的可读性会急剧下降，不适合长篇叙述。 分开的核心原则：机器状态写入 JSON 契约，说明和证据写入 Markdown。 具体来说： 任务的 artifact.json 用 JSON 记录：ID、流程等级、生命周期状态、创建时间、更新时间、交付物列表。这些字段是固定的，脚本可以读、可以写、可以校验。 任务的执行记录用 Markdown 记录：做了什么、怎么做的、遇到了什么问题、有什么结论。这些内容不需要固定字段，需要灵活叙述。 Review 结论用 JSON 记录检查项和结果，确保"是否通过"这个判断可以被脚本自动处理。 背景和约定用 Markdown，因为它们是给人（和 AI）阅读的，不是给脚本处理的。 这套设计的实际效果是什么？ 你可以在脚本中批量检查所有活跃任务的状态，而不需要解析任何 Markdown。你可以在 CI 中配置一个检查：归档时必须有 Review 结论，且 Review 结论必须是 PASS 或被接受的 REVIEW。 同时，AI 在理解任务时，读的是 Markdown——自然的、可读的、有上下文的叙述。它不需要从 JSON 键值对中脑补故事。 机器契约保证了自动化可靠，Markdown 保证了人机可读。两者...

AI 的上下文窗口在变大，从 4K 到 8K、16K、32K、128K，甚至 1M。但上下文窗口越大，越不能啥都往里塞。 这个道理很简单：给你一百本书，让你从里面找答案，你也能找到，但效率远不如直接给你一本相关的书。AI 也一样。更大的上下文窗口解决的是"能不能装下"的问题，不是"该不该装下"的问题。 路由机制的核心思想是：AI 按需读取，只加载当前任务需要的上下文。 怎么做到？靠一个索引文件。 在 AI Context Workspace 中，根目录有一个 AGENTS.md （或类似的入口文件）。这个文件不是上下文仓库，而是 路由表 。它告诉你： 背景信息在哪里（ background/ ） 约定规范在哪里（ conventions/ ） 当前有哪些活跃任务（ artifacts/index.json ） 每个目录下有什么、是干什么用的 路由表只放路径和一句话说明，不放具体内容。具体内容存在各自的文件里，AI 在需要的时候按路径去读。 这样做的好处是什么？ 第一， 上下文精简。 入口文件只有几十行，AI 一眼就能看懂整个工作区的结构。不需要在 10 万 token 的上下文里找入口。 第二， 按需加载。 一个任务只需要读背景中和当前任务相关的部分，以及约定中适用的规范。其他内容不加载，不占上下文窗口，不产生噪音。 第三， 可扩展。 工作区可以无限增长。背景可以写一百份文档，约定可以写几十条规范，但入口文件始终保持精简。新增内容不影响已有任务的上下文质量。 路由机制在实践中怎么用？ 一个典型的工作流是这样的： AI 读入口文件，了解工作区结构 AI 读 artifacts/index.json ，了解当前任务状态 AI 根据任务需要，按路径读取 background/ 中的相关背景 AI 读取 conventions/ 中的相关规范 AI 执行任务，更新 artifacts/ 中的状态 完成后，AI 不再需要保留背景和约定的上下文，可以释放 整个过程，AI 只加载了完成任务所需的最小上下文集合。不多不少。 路由不是新技术，但很少有人把它用在 AI 协作上。 互联网用 URL 路由页面，操作系统用 PATH 路由文件，代码用 import 路由模块。路由是信息...

AI Context Workspace 有一个核心设计原则： 上下文只是文件，谁都能读，谁都能写。 这个原则听起来简单，但它推导出的结果很重要。 模型无关 意味着不依赖任何特定模型的特性。你不用因为换了一个模型就重建工作区。GPT-4 能用，Claude 能用，开源模型也能用。上下文只是文本，任何理解自然语言的模型都能处理。 Agent 无关 意味着不绑定任何 Agent 框架或编排工具。你不用装 LangChain、不用配置 AutoGPT、不用学任何框架的 DSL。工作区是一套目录结构和文件约定，不是一套软件。 为什么这很重要？ 因为 AI 领域变化太快了。今天的主流模型，六个月后可能就过时了。今天的 Agent 框架，明年可能就没人维护了。如果你把工作方式绑定在某个具体工具上，你就得跟着工具升级，永远被动。 但上下文不一样。上下文是"AI 需要知道的信息"，而不是"AI 处理信息的方式"。信息本身比处理方式稳定得多。你的项目背景半年不会变，但用哪个模型来处理这个背景，可以每周换。 那 Agent 框架的价值在哪？ Agent 框架解决的是"怎么让 AI 自动执行多步任务"的问题，不是"怎么让 AI 理解上下文"的问题。两者是正交的。你可以用一个 Agent 框架来自动路由任务，同时用 AI Context Workspace 来管理上下文。两者不冲突，可以叠加使用。 事实上，AI Context Workspace 做得越好，Agent 框架就越容易工作。因为 Agent 的核心难题之一就是"上下文怎么管理和传递"。这个难题被工作区解决了，Agent 可以专注于编排和决策。 具体来说，工作区里有什么？ 只有文件。Markdown 文件、JSON 文件、目录结构。没有二进制格式、没有专有数据库、没有需要特定软件才能读取的格式。任何文本编辑器都能打开，任何 AI 客户端都能读取。 这意味着你可以用 VS Code 查看工作区，用 Git 提交变更，用 Obsidian 链接知识，用任何 AI 工具处理任务。工作区不限制你用什么工具，它只负责组织上下文。

AI Context Workspace 的核心是一个三层结构。每一层解决一个问题，三层合起来构成完整的上下文体系。 第一层：背景。 背景是稳定的、不常变的事实。项目的定位是什么？技术栈是什么？领域知识有哪些？这些信息一旦确定，不会频繁变化。背景层的作用是让 AI 在启动时就能理解"这是一个什么样的项目"。 背景应该写在哪里？写在 background/ 目录下。每次进入工作区，AI 先读背景，建立对项目的基本认知。背景是只读的——不是说不让改，而是说不会被任务流程自动修改。改背景是一个显式操作，需要确认。 第二层：约定。 约定是做事的方式。工作流是什么？质量标准是什么？代码风格是什么？这些规则指导 AI 怎么执行任务。约定不像背景那样稳定，但也不像任务状态那样频繁变化。它随着项目演进逐步完善。 约定写在 conventions/ 目录下。每个约定是一份 Markdown 文件，按需读取。AI 不需要把所有的约定都加载到上下文里，只需要加载当前任务相关的部分。 第三层：状态。 状态是当前任务的具体进展。做到哪了？做了哪些决策？有什么证据？完成了什么？状态是高频变化的，每次任务推进都会更新。 状态写在 artifacts/ 目录下。每个任务一个 Artifact，包含生命周期状态、检查结论、交付物引用。这一层是 AI 在任务执行中主要读写的地方。 为什么是三层？ 因为这三层的更新频率和读取频率天然不同。背景一年改几次，约定一个月改几次，状态一天改几次。把它们分开，AI 就不用每次都在一堆过时的信息里找当前需要的东西。 更好的比喻是：背景是操作系统，约定是应用配置，状态是当前打开的文档。操作系统不会频繁换，配置会按需调整，文档在持续编辑。三者混在一起管理，你就没法工作了。 三层之间的交互 背景为所有任务提供基础认知。约定规定了任务该怎么执行。状态记录了任务实际执行的情况。一个任务开始时，AI 读取背景理解项目，读取约定知道怎么做，然后创建状态开始执行。任务结束时，状态归档，背景和约定保持不变。 这个结构可以逐层独立演化。你不需要因为改了一个约定而重建整个背景，也不需要因为完成一个任务而重新整理所有约定。