宣言

Deep Work Plan（DWP）是一套仅基于 Markdown 的方法论，用于让 AI 编码代理实现结构化、自主的执行。它把一个含糊的目标转化为一份可审阅的计划——一份规范——代理可以执行、暂停、恢复并报告其进展，而不会丢失上下文，也不会一路即兴发挥而落入前后不一的结果。

面向代理的深度工作

这个名字描述了它所产生的实践：在认知要求很高的工作上投入专注而持续的努力，靠的是结构而非意志力。让深度工作对人有价值的那种特质——不受干扰的专注，在长周期内持续维持——正是 AI 编码代理完成横跨数小时乃至数天的工作所需要的。Deep Work Plan 提供了这种结构，并在此过程中把代码仓库转化为 AI-first、可被代理驾驭的代码库。

一个没有计划的代理，其行为就像一位从不为工作留出整块时间、从不记下任何东西、每被打断一次就切换上下文的知识工作者。Deep Work Plan 为代理提供了相当于一份排满的日程与一份书面简报的东西：一个有界的范围、一条清晰的顺序，以及一个记录进展的持久之地。

方向才是放大器

AI 编码代理的能力，与其说取决于模型，不如说取决于它所获方向的质量。一个能力强的模型若被指向一个含糊的请求，只会放大含糊；同一个模型若被指向一份精确的规范，则会放大精确。随着模型不断进步，这一差距是在拉大而非缩小——瓶颈向上游移动，从编写代码转向定义工作。如今真正关键的技能不再是执行，而是方向。

这重新界定了“善于委派”的含义。良好的委派不是向代理索要工作——而是把工作定义得足够清晰，使其能够被正确执行：目标、约束、代理原本缺失的上下文，以及裁定它是否成功的标准。大部分价值是在执行开始之前就被创造出来的。

Deep Work Plan 正是把这项上游工作以一种持久、可复用的形式完成的纪律。它的两大奠基支柱正是良好方向的两半：一份规范陈述“正确”是什么样子，而一套**harness（运行支架）**则为代理提供抵达那里所需的上下文与工具。第三项纪律让这一组合在规模化时依然负担得起：token 效率——因为一套行之有效的 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 在构造上就是可移植的：任何能够读取 Markdown、执行 shell 命令的代理都能打开同样的文件，无需任何定制的逐工具框架。这正是方法论其余部分赖以成立的那句一行断言：代码仓库本身成为 harness。这是一项关于代码仓库携带了什么的断言，而非关于某个模型能够在面对一个全新请求时、无需协助便可靠地找到正确流程的保证——这正是为何这套套件还附带了明确的 dwp-* 入口点与一个路由用的 SKILL.md：文件的可移植性与可靠的路由是两种不同的属性，仅有前者是仅凭构造就能实现的。

构造上即高效

第一根支柱让工作正确，第二根支柱让工作可移植，第三根支柱让工作负担得起——上下文是编码代理最稀缺的资源，而一套浪费上下文的方法论，恰恰在工作变长的时候失效。

三种机制支撑起这一点：

• 渐进式披露。 代理只读一个精炼的核心，每一份指南或规范的章节都只在所属流程自身的触发条件被触发时才加载。代理携带的是它需要的那一章，而非整本书。
• 按触及面选择验证。 每项任务记录自己改动什么，并按风险级别挑选关卡——小而隔离的变更以窄范围证明自己；对共享机制的变更则以宽范围证明自己。验证按效果选择，而非按习惯。
• 任务内学习。 当一项任务产出可复用的模式时，决策就发生在那项任务内部、证据尚且新鲜的地方——而不是发生在无人阅读的回顾里。

其中没有任何一项声称构造上即无损，也没有任何一项拿凭空捏造的百分比去做营销。每个流程所需的指令字节数都经过测量并公开发布；行为层面的论断则以播种故障的回放作为支撑；此外，一项新代理评估——同样的两个功能，分别在无 harness、上一大版本与本版本下构建——已在冻结协议下执行。它测量了这些机制在陌生人第一天所能交付的：带 harness 的代理在两项任务中读取的字节都少于无 harness 对照组，且本版本的功能会话消耗的模型输入与输出均少于上一大版本，由 harness 报告，单一工作负载。同一项评估也清楚标出了边界：onboarding 是一次性成本，只有在流程被使用时才会回本；五次全新运行中，没有一个代理自行进入流程——流程是由你或知道调用它的代理执行的命令。同一棵树上的第二个功能在所有测得的配置中都花费更少，无 harness 对照组也不例外：这部分摊销属于树本身，而 harness 的存在是为了让它变成有意为之。

为何结构化的自主执行至关重要

现代 AI 编码代理能力出众,却缺乏方向。把一个代理指向一项并不简单的任务，它往往会立刻开始编辑文件，弄丢自己改动过什么的踪迹，并产出难以审阅、无法恢复的工作。

DWP 施加了一种轻量的结构，直接应对每一种失败：

• 可审阅的任务 —— 工作被分解为一系列连续的单元，每个单元都有明确的范围与验收标准。
• 持久化的状态 —— 进展被写下来，于是工作能在中断中存续，并可跨会话、跨代理恢复。
• 标准化的文档 —— 人类与代理通过一套共同的格式共享同一套心智模型。
• 代理可移植性 —— 这套方法论通过轻量适配器与任意代理协作，而非逐一重新实现。

一路到底，皆为 Markdown

DWP 定义的是结构，而非软件。没有需要安装的运行时，没有依赖树，也没有锁定。计划、任务与运行日志全都是纯 Markdown，任意代理都能读取，任何人都能审阅，任何版本控制系统都能干净地追踪。其结果，是一种你可以读懂、可以审计、可以信任的执行。