---
name: plan-for-agents
description: 创建、修订或检查供 agent 执行的完整 plan，将需求和已确认决策落实为方案、步骤、产物与验收证据。适用于实施、调研、创作、数据处理等任务的执行计划；单纯总结讨论或解释现有方案时不自动触发。
---

# 面向 agent 的完整 plan

让未参与前期讨论的 agent 读完计划及明确引用的材料后，能知道目标、依据、执行方式、决策权限和完成判据，无需从聊天记录中猜测关键约定。

完整性按有效要求与执行边界判断，不以篇幅、章节数量或模型意见一致为依据。保留执行所需的信息，合并重复表达；简单任务可以用短计划覆盖全部必要内容。

## 1. 确定本次工作和依据

先区分用户要求的是创建计划、修订已有计划，还是只检查完整性。只检查时交付问题与依据；创建或修订时交付可独立使用的当前方案。编写计划本身不授权实施、发布或启动其他 agent；沿用会话中已有的授权。

读取用户指定的需求、已确认决定、现有 plan 和与执行相关的事实材料。明确权威来源及适用范围；需要固定版本时记录 commit、文档版本、数据时间范围等可复核标识。“最新”应核实后指向具体版本。

- 区分当前事实、目标要求、已确认决策、实现建议、假设和待决项。现状不能替代目标，助手建议不能自动升级为用户决定。
- 用户已裁决的事项直接承接。常规执行细节可由 agent 根据约束选择，避免把命名、文件划分等都变成用户问题。
- 材料冲突或缺口会改变范围、结果或重要取舍时，先查可取得的证据；仍无法确定的，列出影响和最小必要问题，并继续不受阻塞的部分。

完成条件：能说明本次计划的范围、依据和确认状态，并识别哪些工作受未决项阻塞。

## 2. 写清通用核心内容

以下是内容要求，不是固定九章模板。沿用合适的已有结构，按任务规模合并章节；不适用的内容无需空占标题。关键规则在正文说明，来源链接用于核实，不能代替规则本身。

| 内容 | 必须明确的信息 |
|---|---|
| 目标与完成标准 | 预期结果、交付对象，以及可观察、可检查的完成条件。 |
| 范围与约束 | 本次包含和排除的工作；用户要求、资源限制、权限边界和必须保持的行为。 |
| 输入与事实依据 | 所需材料、已核实的当前状态、可复用能力、目标差距；来源版本、冲突处理依据和未核实信息。 |
| 决策与待决事项 | 已确认选择及必要理由、接受的代价、可调整的执行细节；未决问题、决定者及受阻塞的步骤。 |
| 总体方案 | 从当前状态到目标状态的方法；组成部分的职责、输入输出与协作关系；关键选择的理由。 |
| 执行步骤与依赖 | 具体行动、前置条件、顺序、产物与完成判据；可独立推进的工作及交接条件。 |
| 边界与异常处理 | 与任务相关的输入缺失、失败、冲突、打断等场景；重试、停止、回退、恢复或请求裁决的条件。 |
| 验证与验收 | 各项要求对应的验证方法、预期结果、证据位置、失败处置，以及无法验证的范围。 |
| 交付与接续 | 产物位置、格式、交付状态；发生中断或交接时，如何识别有效成果并继续剩余工作。 |

待决项存在时可以交付待确认稿，但受影响步骤必须保持阻塞状态。不得为了让 plan 看起来完整而填造事实、默选重要取舍或宣称已验证。

## 3. 把方案展开到可执行粒度

按“可以独立执行并判断完成”的单元拆分步骤，给需要依赖或交接的步骤稳定标识。避免只有“分析、实现、测试”这样的阶段名称，也无需逐条预写普通机械操作。

每个实质步骤写清以下信息，简单步骤可以合并成一段：

```text
步骤 ID 与目标：
前置条件 / 依赖：
具体行动：
预期产物：
完成判据：
异常或阻塞时的处理：
```

粒度是否足够，用这个问题判断：执行者是否仍需自行决定会改变目标行为、跨环节约定或正确性的事项？如果需要，就补足相关规则或标明待决；仅剩符合约束的常规实现选择时，留给执行者。

标明可并行不等于授权创建多 agent。只有任务需要时才指定执行角色；存在多人或多 agent 协作时，明确产物归属、共享修改边界和汇合条件，不预设模型或调度工具。

按任务补充会影响执行正确性的专业细节：

- **软件开发：** 改动与复用范围、接口与数据约定、状态和关键时序；涉及迁移、并发、幂等、兼容或恢复时展开对应语义及验证。无需预写全部函数和代码。
- **调研分析：** 问题范围、资料获取方式、来源可信度、比较方法、证据冲突与不足时的结论边界。
- **文档或内容创作：** 受众、结构、事实来源、表达要求、审阅方式和成品格式。
- **数据处理：** 输入输出、转换规则、质量标准、异常数据处理；存在覆盖或损失风险时说明恢复方式。
- **外部操作：** 目标对象、执行权限、预览与提交边界；按实际风险确定结果核验及撤销或补救方式。

只写任务实际需要的内容，不为凑齐清单引入新机制、额外平台或假想风险。

## 4. 修订时保持完整方案

以已有完整 plan 为修订对象，结合新的事实、用户裁决和有效 review 意见更新相关部分。用户只改变一个决定时，先检查该决定及其依赖，不把它解释为授权重写或压缩整份计划。

- 仍然有效的要求、接口约定、边界、步骤和验收细节保留。
- 被新结论推翻的设计，在对应位置替换，并同步依赖步骤、异常处理和验证要求。
- 重复内容合并到一个权威位置；读者通过明确引用找到它。
- 删除或合并实质内容时，在修订核对中记录原内容、处置理由和替代位置；确实不再需要时说明依据。记录默认留在工作过程中，有审阅或交接需要时另行交付。

摘要可以单独提供，不能替换完整正文。方案简化时写清取消哪些工作、为什么可以取消、留下什么代价，以及其余要求如何继续满足。原稿更长不是全部恢复的理由，但“保持精炼”也不是删除必要细节的理由。

已有评审流程时，评审对象应是实际修订后的完整文件与差异。对建议达成一致不代表修改后的文档已通过检查；修改发生在确认之后时，重新检查受影响部分并明确确认对应的版本。计划正文呈现当前有效方案，历史争论与 review 记录按需另存。

## 5. 核对覆盖、可执行性和交付状态

对照原始有效要求与最终裁决，在工作过程中逐项建立：

**要求 → 方案位置 → 执行步骤 → 产物 → 验收方式与预期证据。**

简单任务可逐项核对；复杂或跨环节任务可用映射表。只在交接或审阅确有需要时交付独立台账。

- **正向覆盖：** 每项有效要求、条件、例外和已接受代价都有落点；不能只核对主题标题或关键词。
- **反向核对：** 每项计划工作都服务于目标、要求或必要依赖；无依据的扩展删除或明确作为待选建议。
- **执行闭合：** 每个步骤具备输入、依赖、行动、产物和完成判据；关键交接没有缺失责任或互相等待。
- **边界一致：** 总体方案、具体步骤、异常处理和验收要求相互一致。检查是否存在符合计划文字却违反已确认要求的合理执行方式。
- **验证诚实：** 计划中的验证方法与执行后的证据分开。“待验证、已通过、失败、受阻”按事实记录；不能通过降低验收标准宣称完成。

执行中发现事实与计划不符时，记录差异、影响和调整理由。符合既定目标与约束的细节自行调整；超出已有授权、改变用户已确认决定或需要新的重要取舍时，请求最小必要裁决，同时推进不受影响的工作。

交付前回读最终产物。通过条件是：在声明的来源范围内，影响执行的遗漏、矛盾和歧义已解决，未决项及其阻塞范围清楚，执行者能定位所需信息。关键来源缺失时说明完整性检查的限制。

默认交付一份完整计划，使用用户指定路径或项目已有惯例。进度与执行证据放在明确区分的状态区或已有记录中；只在实际交接时记录当前成果、失败尝试、剩余工作和继续执行的入口。最终回复给出产物位置、核对范围与尚未解决的事项；计划通过检查不代表实际工作已经完成。