AI 协作场景
介绍
agent-context 最有价值的地方，不是"多了几个协议名"，而是把一类常见协作场景固定成统一流程。
如果你不确定什么时候该 plan、什么时候该 patch，这页给出按任务类型划分的具体工作流。
快速使用
先按任务类型判断：
- 新需求且需要拆解：
plan - 计划还没执行，但方案要变：
replan - 当前计划已经执行过，还要继续改：
patch - 任务很小且边界清楚：
rush - 想在实施前或实施后做一次独立把关：
review（对话中直接说review，不加额外描述）
核心规则：
text
已执行计划上的任何增量需求，都优先走 patch，不要重新 plan。API参考
场景 1：开发一个中等复杂度的新功能
适用情况：涉及多个文件，需要先拆步骤，可能持续几轮对话。
推荐流程：
为"新增 Excel 导出功能"出计划- 审阅
plan.md是否合理 按当前计划开始实现- 如果实现后又发现一个小问题：
给当前计划补一个 patch，... - 全部完成后：
当前计划已经真正完成，归档它
为什么这样做：
plan负责把复杂任务结构化implement保证 AI 不会偏离计划patch保留增量修改记录，不污染主计划
场景 2：原计划还没开始，但方案推翻重来
适用情况：计划还处于 未执行，你想改技术路线、拆分方式或验收思路。
推荐指令：
text
重做当前计划，不再引入第三方库，改成基于现有 core 能力实现为什么这样做：
- 这是典型的
replan - 还没实施就不要用
patch - 也不应该让 AI 一边改代码一边偷偷改计划
场景 3：需求非常明确，直接做完更高效
适用情况：目标只有一件事，验收标准清楚，不值得先单独做计划确认。
推荐指令：
text
rush 一下，把 agent-context 文档中的 protocol 说明补全为什么这样做：
rush会先创建单计划，再直接实施- 适合文档修订、单测修复、小脚本调整
- 不适合模糊需求或大范围重构
场景 4：主任务做完了，但上线前又冒出一个小问题
适用情况：当前计划已经是 已执行，新问题仍属于同一任务上下文。
推荐指令：
text
给当前计划补一个 patch，修复 Windows 下路径分隔符导致的失败为什么这样做：
- 继续
plan会打断上下文连续性 patch会把增量改动留在当前计划下面- 主计划的影响范围和补丁历史会保持完整
场景 5：正式收尾并推进到下一个计划
适用情况：当前计划及相关 patch 都完成了，需要开始下一个 preparing 计划或清空上下文。
推荐指令：
text
当前计划已经真正完成，归档它为什么这样做：
done会把当前计划归档到done/- 如果有准备中的计划，下一个计划会被晋升
- 自动更新计划索引，保持
index.md与实际状态同步 - 下一次对话时，AI 不会继续把旧计划当成活跃任务
场景 6：多人在同一项目中独立工作
适用情况：团队成员各自有独立的任务线，不想互相干扰。
工作方式：
- 每位协作者拥有独立的作用域目录（
{scope}/） - SCOPE 名称自动取自 git
user.name - 计划编号在各 SCOPE 内独立递增
- 首次使用时运行
agent-context init初始化
text
.agent-context/
├── alice/ # Alice 的计划
│ ├── index.md
│ ├── plan-1/
│ └── done/
├── bob/ # Bob 的计划
│ ├── index.md
│ ├── plan-3/
│ └── done/
└── .env # 当前用户的 SCOPE每个人的 index.md 独立维护，互不影响。
场景 7：实施前或实施后做独立审查
适用情况：你希望 AI 以「第三方审查员」身份通读计划或对照 diff 检查实现，而不是在同一条实施对话里顺带看一眼。
推荐指令：
text
review为什么这样做：
review协议要求子代理隔离，减少「自己审自己」的盲区- 计划仍是
未执行时，审查意见通常对应replan或继续implement - 计划已
已执行时，审查意见通常对应patch或确认归档