Skip to content
← 全部章节

章 03

计划与任务模板

一份 Deep Work Plan 是一个由 Markdown 文件构成的目录。该目录——以及其中每个文件——的形态，正是使一份计划能被人类与代理共同审阅的关键。

计划结构

一份计划是 .dwp/plans/ 下一个名为 PLAN_001_<slug>/ 的目录。它包含：

  • manifest.json —— 计划的标识以及指向其实时合约的指针，在实例化时最先写入。
  • contract.json —— 不可变且内容寻址的成果契约（验收标准、范围、不变量）。
  • journal.ndjson —— 仅追加的账本事件执行日志。
  • state.json —— 从 journal 投射出的快照，绝不可手动编辑。
  • README.md —— 计划概览：目标、源材料、任务表与状态。
  • PROGRESS.md —— 人类可读的持续执行日志。
  • 1.task_<slug>.md、2.task_<slug>.md —— 单独的任务 Markdown 文件。
  • analysis_results/ —— 任务产物、分析报告与验证关卡证据目录。

当前 7.x 技能包默认创建 v7 计划，其 slug 与 v6 计划一样为 2–5 个单词。保留的 v5 流程使用 2–4 个单词，因为其冻结的 schema 会把数字 ID 计作一个单词。新计划会获得至少三位数、单调递增的数字 ID（例如 PLAN_001_add_payment_webhooks/）。现有未编号的 PLAN_<slug>/ 文件夹继续可读且绝不重命名；现有计划绝不隐式迁移。存在编号计划时，latest 解析为数字 ID 最大的计划。

任务文件结构

每个任务文件命名为 <n>.task_<slug>.md，并遵循已安装技能所定义的十个规范章节（参见核心循环了解任务结构）。每项任务在行动前都会重新锚定到计划的目标，防止代理在长达数小时的任务中发生目标漂移。

Final Review

每份计划都必须以唯一一项强制任务收尾：Final Review。它按五个严格顺序环节闭环整个计划——安全审查和验证关卡绝不放宽：

  1. 安全审查 —— 审计计划改动的一切内容以排查密钥、注入风险与新攻击面，保持 docs/SECURITY.md 最新，并在计划的全部范围内运行必需的本地 AI Diff Reviewer 审查（缺少审查器会被记录为 local reviewer not installed 发现项，绝不能静默跳过）。阻断级严重缺陷阻止完成。
  2. 最终状态验证 —— 仓库全部适用的测试、代码检查与类型检查套件在最终状态下运行并通过。审查过程中的任何修复都会使受影响结果失效并触发重新运行。
  3. 技能决策核对 —— 验证每项任务均已记录任务局部的技能处置，并在 analysis_results/SKILLS_CANDIDATES.md 中核对所有合理的技能编写事项。
  4. 文档对齐核对 —— 将每项改变行为的任务的触及面与登记该特性的文档（docs/TESTING_GUIDE.md、架构文档与 AGENTS.md）进行对齐比对并补齐。
  5. 完成 —— 计划记录保持一致（任务列表、进度日志，以及在 v6 与 v7 计划中由 journal 衍生的快照与收据）；报告交付成果、证据与局限性，并提供一次 Executive Report。

README 与 PROGRESS 约定

计划的 README.md 必须包含一个标题（# Deep Work Plan: <name>）、一段散文式的目标陈述、一个可选的源材料段落、一个任务表（编号、任务名、状态复选框），以及一行形如 <n>/<total> tasks complete 的计划状态。

PROGRESS.md 是一份只追加的执行日志。每条记录都记下一个 ISO 8601 时间戳、任务编号与名称、做了什么，以及任何偏差或跳过的原因。由于它只会不断增长，它是计划实际如何展开的可靠历史。

标题与交叉引用

所有标题都采用首字母句式（sentence case），文档避免使用营销式语言与感叹号。这些约定让计划在不同代理之间、在时间推移中保持一致。