章 01
宣言
Deep Work Plan（DWP）是一套仅基于 Markdown 的方法论，用于让 AI 编码代理实现结构化、自主的执行。它把一个含糊的目标转化为一份可审阅的计划——一份规范——代理可以执行、暂停、恢复并报告其进展，而不会丢失上下文，也不会一路即兴发挥而落入前后不一的结果。
面向代理的深度工作
这个名字描述了它所产生的实践：在认知要求很高的工作上投入专注而持续的努力，靠的是结构而非意志力。让深度工作对人有价值的那种特质——不受干扰的专注，在长周期内持续维持——正是 AI 编码代理完成横跨数小时乃至数天的工作所需要的。Deep Work Plan 提供了这种结构，并在此过程中把代码仓库转化为 AI-first、可被代理驾驭的代码库。
一个没有计划的代理，其行为就像一位从不为工作留出整块时间、从不记下任何东西、每被打断一次就切换上下文的知识工作者。Deep Work Plan 为代理提供了相当于一份排满的日程与一份书面简报的东西：一个有界的范围、一条清晰的顺序，以及一个记录进展的持久之地。
方向才是放大器
AI 编码代理的能力，与其说取决于模型，不如说取决于它所获方向的质量。一个能力强的模型若被指向一个含糊的请求，只会放大含糊；同一个模型若被指向一份精确的规范，则会放大精确。随着模型不断进步，这一差距是在拉大而非缩小——瓶颈向上游移动，从编写代码转向定义工作。如今真正关键的技能不再是执行，而是方向。
这重新界定了“善于委派”的含义。良好的委派不是向代理索要工作——而是把工作定义得足够清晰，使其能够被正确执行：目标、约束、代理原本缺失的上下文，以及裁定它是否成功的标准。大部分价值是在执行开始之前就被创造出来的。
Deep Work Plan 正是把这项上游工作以一种持久、可复用的形式完成的纪律。它的两大支柱正是良好方向的两半：一份规范陈述“正确”是什么样子，而一套**harness（运行支架）**则为代理提供抵达那里所需的上下文与工具。两者合力，把模型的原始能力转化为可靠的工程——在一项运行数小时的任务中持续维持，并在会话之间更替的代理之间得以保全。
设计上即规范驱动
这是方法论的第一根支柱，与“harness”一样，它值得被平实地定义。
什么是规范驱动的开发。 在普通的提示驱动工作中，事实来源是一段对话：你向代理索要某样东西，它编辑文件，而意图唯一的记录是一份不断滚走、再也不会被重看的聊天记录。规范驱动的开发（SDD）把这一切颠倒过来。你首先写下什么应当为真——目标、范围、验收标准、证明其完成的核查项——而那份书面规范，而非那段对话，才是事实来源。代理随后依据规范来执行，而不是从一句话的提示即兴发挥。
DWP 如何体现这一点。 在 Deep Work Plan 中，计划就是规范。一个目标变成一份可审阅的计划；计划分解为原子化任务；每项任务都带有明确的验收标准与验证关卡；一套完成协议则据此确认工作。计划 → 任务 → 关卡 → 完成，正是被具体化、可执行的 SDD。
它为何重要。 先写规范会从三个方面带来回报：它减少漂移，因为代理是依据陈述的标准来衡量，而非依据对请求渐渐淡去的记忆；它让工作可验证，因为每一道关卡非通过即失败；它让工作可恢复，因为规范比任何单次会话或单个代理都更长久——另一个代理明天可以接手，并确切知道“完成”意味着什么。
DWP 有何不同。 围绕这一理念已形成了一场更广泛的规范驱动运动，其中包括 GitHub Spec Kit、Amazon Kiro 与 Tessl。这些做法往往绑定于某一特定工具或平台。DWP 刻意有所不同：它是工具无关、仓库原生的。规范以纯 Markdown 的形式存在于代码仓库中，因此它随代码一同传递，而非随某个供应商的产品；并且它直接与第二根支柱相组合，因为规范本身就是代码仓库所携带的那套 harness 的一部分。
代码仓库成为 harness
这是方法论的第二根支柱，它理应得到一个平实的定义——“harness”已成为一个含义沉重的词，业内许多人在使用它时却不说明其所指。
什么是代理的 harness。 一个大型语言模型，单凭自身，不过是一个文本预测器。把它转化为可靠工程师的，是环绕在它周围的一切：它所获得的上下文、它能调用的工具、决定下一步做什么的控制循环、捕捉错误的防护栏，以及让它得以停下并恢复的持久状态。那套环绕其外的脚手架，就是 harness。模型是引擎；harness 则是让引擎可以安全驾驶的底盘、转向与制动。
什么是 harness 工程。 大多数团队都是在单一工具内部隐式地构建那套脚手架——某个特定的 IDE、某款代理产品，或某个定制框架——于是它只在那里有效，并在你切换工具的那一刻消失。Harness 工程则是把那套脚手架作为一等产物、刻意加以设计的纪律。Deep Work Plan 对它应当存在于何处持有一个鲜明立场：不在工具中，而在代码仓库本身。
为何代码仓库是正确的归处。 当 harness 存在于仓库中时，它随代码一同传递，每个打开该仓库的代理都会继承它，并且它像其他任何代码一样被版本化、被审阅、被改进。DWP 把 harness 的每一部分都安装为一份具体、持久的产物：
| harness 要素 | 它提供什么 | DWP 在你的仓库中把它放在何处 |
|---|---|---|
| 上下文 | 代理需要知道什么 | AGENTS.md、docs/ 与各模块的 README |
| 工具 | 代理能做什么 | .agents/ 中的技能、代理与 dwp-* 命令 |
| 控制循环 | 工作如何推进 | Deep Work Plan：计划 → 原子化任务 → 关卡 → 完成 |
| 防护栏 | 是什么保持其正确 | 明确的验收标准与验证关卡 |
| 状态 | 它如何在中断中存续 | 被 gitignore 的 .dwp/ 计划、草稿与进展日志 |
- Context
- Tools
- Control loop
- Guardrails
- State / Resumability
由于每一个要素都是代码仓库中的一份文件，而非某个工具的一项功能，这套 harness 在构造上就是可移植的。这正是方法论其余部分赖以成立的那句一行断言：代码仓库本身成为 harness，于是任意代理都能驾驭任意仓库——无需任何定制的逐工具框架。
为何结构化的自主执行至关重要
现代 AI 编码代理能力出众,却缺乏方向。把一个代理指向一项并不简单的任务，它往往会立刻开始编辑文件，弄丢自己改动过什么的踪迹，并产出难以审阅、无法恢复的工作。
DWP 施加了一种轻量的结构，直接应对每一种失败：
- 可审阅的任务 —— 工作被分解为一系列连续的单元，每个单元都有明确的范围与验收标准。
- 持久化的状态 —— 进展被写下来，于是工作能在中断中存续，并可跨会话、跨代理恢复。
- 标准化的文档 —— 人类与代理通过一套共同的格式共享同一套心智模型。
- 代理可移植性 —— 这套方法论通过轻量适配器与任意代理协作，而非逐一重新实现。
一路到底，皆为 Markdown
DWP 定义的是结构，而非软件。没有需要安装的运行时，没有依赖树，也没有锁定。计划、任务与运行日志全都是纯 Markdown，任意代理都能读取，任何人都能审阅，任何版本控制系统都能干净地追踪。其结果，是一种你可以读懂、可以审计、可以信任的执行。