3.1 七阶段工作流

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 阶段"，别人就知道你在做方案设计，还没开始写代码。你说"这个任务 blocked 在 review 阶段"，别人就知道交付物已经完成，但检查没通过。

共同语言的价值在于：不需要解释，不需要同步，看一眼就知道上下文在什么程度。