Skip to content
Deep Work Plan 今天登陆 Product Hunt 去支持
← 全部章节

章 02

核心循环

DWP 定义了一小组操作，让一份计划从目标走向完成、可审阅的工作：create → execute → refine → resume → status，并以 verify 作为确认结果的符合性核查。它们共同构成代理在一份计划的整个生命周期中所遵循的循环。代理一次执行一项任务，在继续之前验证每一步。

这个循环是规范驱动开发的运作形态。计划是代理依据其执行的规范，每项任务都带有明确的验收标准，而验证这一步则是把“声称已完成”转化为“完成之证据”的关卡。由于计划及其进展日志存在于代码仓库中，这个循环可以跨会话、跨代理恢复。

这些操作

  • create —— 从一个目标生成一份新计划。代理分析目标，将其分解为一系列连续的任务，并写出计划文件。当目标含糊时，它应当在动笔之前提出澄清性的问题。在引导模式下，代理直接物化出一份Lite 计划——一份紧凑且已可执行的提案——开发者可以选择保留它、将其晋升为按任务分文件的 Full 计划、编辑它，或就此停止；在信任模式下，代理直接物化所选的表现形式（Lite 或 Full），无需审阅步骤。两种形式参见规范。无论哪种模式，需求分析与计划质量检查都会执行。
  • execute —— 逐任务运行计划。代理在每项任务后更新进展日志，并标记该任务的完成状态。它不得在未记录原因的情况下跳过任务。
  • refine —— 修改一份现有计划。代理可以增加、删除或重排任务，但必须保全已完成的工作并更新任务表。
  • resume —— 继续一份被中断的计划。代理读取进展日志与任务文件以重建状态，然后从第一项未完成的任务继续。
  • status —— 报告进展而不执行。代理汇总已完成、进行中与待办的任务，且不改动任何东西。
  • verify —— 核查符合性而不改动任何东西。代理报告代码仓库是否达到该标准，以及一份计划是否结构良好——即每项任务都带有验收标准与验证关卡。参见规范的符合性文档。

.dwp/ 输出目录

所有 DWP 产物都存放于代码仓库根目录下一个被 gitignore 的 .dwp/ 目录中。把工作区排除在版本控制之外，意味着一份计划的工作状态绝不会污染项目历史。

.dwp/
├── plans/
│   └── PLAN_<slug>/
│       ├── README.md
│       ├── PROGRESS.md
│       └── <n>.task_<slug>.md
└── config.yaml

任务的十段式结构

每个任务文件都按顺序包含这十个段落。这一结构保证每个工作单元都自成一体且可审阅：

  1. Goal（目标） —— 用一段文字陈述该任务达成了什么。
  2. Context（上下文） —— 背景、链接，以及这项任务为何存在。
  3. Touched Surface（触及面） —— 该任务改动之物与必须验证之物之间的契约。
  4. Steps（步骤） —— 有序、具体、要执行的动作。
  5. Acceptance criteria（验收标准） —— 一份界定“完成”的条件清单。
  6. Validation（验证） —— 为核实工作而要运行的命令或测试。
  7. Files（文件） —— 预计将被创建或修改的路径。
  8. Dependencies（依赖） —— 其他任务或外部前置条件。
  9. Risks（风险） —— 可能出错之处，以及缓解措施。
  10. Completion & Log（完成与日志） —— 一个状态标记外加按时间顺序排列的记录。

验证、完成与恢复

验证是任务的一部分，而非事后补充：每项任务都点明证明其完成的命令或测试，代理在标记完成之前先运行它们。测试在此是头等大事——一项新增功能或改变行为的任务必须为该行为新增或更新自动化测试，并运行代码仓库完整的代码质量检查（测试外加 lint 与类型检查），而不仅仅是确认构建成功；现有测试必须保持通过，且应更新为预期的行为而非被跳过。安全与之同样是头等事项——任何触及认证、输入处理、机密、网络接触面或依赖的任务，都会在其验收标准中带上该变更的安全预期，并保持每次提交都不含机密，而每份计划都以 Final Review 作结——对整个变更集的安全审查、对最终状态的完整验证，以及对技能决策的核对。完成会在“完成与日志”段落中以一个明确的状态标记记录下来（[ ] 未开始、[~] 进行中、[x] 已完成、[!] 受阻）。恢复依赖于这些标记与进展日志——代理可以确切重建出计划停在何处，并从第一项未完成的任务继续，无需重做已完结的工作。