常见问题

Deep Work Plan 将一个代码仓库转变为结构化环境，让编码代理能够在其中可靠地执行长时间的工作。它以代理技能的形式安装，对仓库做一次接入（一份 `AGENTS.md` 索引、一棵 `docs/` 树、一套由技能与命令组成的 `.agents/` 套件、一个被 gitignore 的 `.dwp/` 输出区），此后任何目标都成为一份计划：原子任务，每项都带有验收标准与验证关卡，逐项执行、通过即提交，并可由任意代理从磁盘恢复。计划以一项 Final Review 收尾——审计安全并验证最终状态。该方法论采用 MIT 许可，可与任何能读取仓库的编码代理协同工作。

阅读方法论

适合把真实的多步骤工作交给编码代理、并希望工作得以完成的开发者与团队。当一项任务跨越多个会话、多类文件或多个代理；当队友必须能从代理停下之处接手；或当“完成”必须意味着“已验证”、而非“代理说完成了”时，它尤为合适。一行代码的修复不需要计划，方法论自己也如此规定：其比例严格度规则建议改用内联的目标、标准与关卡。

快速开始

这是一种呈现形式的选择，而非严格程度的取舍。计划默认采用 Lite 形式：一份带有锚定任务记录的紧凑 README，它已经可以执行，而不是一份未完成的草稿。如果你一开始就要求 Full 计划，`create` 会直接写出 Full 任务文件；当某项任务的指令细节、依赖关系或契约不再容纳进一份可审阅的紧凑记录时，它也会把计划展开为 Full。之后的提升保留每一项已完成任务。两种格式承载着相同的验收标准、验证关卡、证据与强制性的 Final Review。

阅读方法论

一套被打包为可安装技能的方法论。没有服务器、没有账号、没有专有格式，除你已在使用的编码代理之外也没有额外的运行时。被安装的是代理阅读的指令、一小组用于上下文检测与符合性检查的 shell 脚本，以及你的仓库所采纳的约定。计划产出的一切都是你仓库中的 Markdown 与 JSON，无需任何工具即可阅读。

阅读规范

任何能读取仓库文件的代理。该技能遵循开放的 Agent Skills 标准与 `AGENTS.md` 约定，因此 Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot 等都能通过其常规的技能与指令加载机制识别它。方法论自身的评估表明，由一家厂商的代理启动、再由另一家厂商的代理恢复的计划在两个方向上都有实证。兼容性矩阵按代理分别列出安装覆盖情况与行为证据，且从不将二者混为一谈。

浏览套件

三步。首先，将 Deep Work Plan 技能安装到你的编码代理中——最快的路径是 `npx skills add DailybotHQ/deepworkplan-skill`（或克隆 skill 仓库并运行 `./setup.sh`）。其次，对仓库做一次接入，让代理根据你的技术栈适配 `AGENTS.md`、`docs/`、`.agents/` 套件和被 gitignore 的 `.dwp/` 区域：指向 https://deepworkplan.com/init.md，或运行 `/deepworkplan-onboard`。第三，用精简命令规划并执行工作：`/dwp-create <goal>` 构建计划；`/dwp-execute` 逐任务、逐关卡执行；`/dwp-refine` 编辑一份进行中的计划（范围、任务，或将 Lite 计划提升为 Full）；`/dwp-resume` 在中断后继续；`/dwp-status` 报告进度但不执行；`/dwp-verify` 产出客观的符合性报告；`/dwp-upgrade` 将已安装的技能迁移到新版本，且不触碰既有计划。会拦截 `/` 的代理通常改用 `#`（例如 `#dwp-execute`）。接入端点与快速开始以更详尽的方式走同一条路。

快速开始

代理技能会被安装到你的代理加载项目或用户技能的位置。随后，接入会适配仓库本身：创建或调和 `AGENTS.md`、`docs/`、`.agents/` 以及被 gitignore 的 `.dwp/` 工作区。技能教会代理这套方法；仓库则保存其他代理接续工作所需的上下文、套件与计划证据。

查看采用流程

对代码仓库而言推荐使用 Git，因为其历史记录是恢复与审查界面的一部分；但该方法论也可以在没有 Git 仓库的代理工作区中运行。在那种情况下，必须具备可机器读取的状态层——包括 `state.json` 检查点与关卡记录——以使恢复不依赖聊天记录。

了解仓库原型

技能描述代理如何执行一套可重复的流程。DWP 计划通过范围、验收标准、验证关卡与证据来描述一项具体的变更。产品规范描述产品当前的行为，并在实现之后通过增量持续演进；技能与计划本身也是规范，只是它们描述的是流程与变更，而非维护那份权威的产品契约。

阅读规范

它们是代理自己运行的可执行断言。人工签署位于运行的两端：一个人在执行前批准计划，并在拉取请求时审阅最终的 diff；其间的执行是自主的。每项任务都点明具体命令——通常是仓库自身的质量关卡——从任务的触及面中选择：被改行为及其消费方的测试，当改动是共享的或无法界定影响时，扩大到完整的测试套件。只有当这些命令成功退出时，任务才被标记为完成，而改变行为的任务必须扩展测试。一旦失败，代理会先修复落在任务自身范围内的问题并重新运行关卡；无法在该范围内修复的失败会把任务标记为受阻并停止运行。

核心循环

从三个方面入手。任务以行为、而非编辑动作来书写：验收标准陈述系统必须做什么，因此文件改名或实现替换都不会使其失效。每道关卡都针对仓库当前的状态重新运行，因此失实的假设会在下一次运行中响亮地失败，而非悄然偏移，而那次失败正是发起精炼的信号。保持文档同步也是工作的一部分：改变行为的任务会在自己的关卡内更新描述该行为的文档与面向代理的套件。每一次运行结束时，仓库都应比运行开始时更适于代理工作。

阅读方法论

可以；精炼一份已部分执行的计划是受完整支持的常规操作。任务定义与执行状态分开保存：计划是磁盘上的一份清单加上一个小型状态文件，因此已完成的内容独立于任务文本被记录。当某项任务被发现有误时，代理会将其标记为受阻并停下来，而不是硬闯过去。随后你可以编辑、重排、拆分或丢弃尚未运行的任务，已完成的任务保持完成。恢复时会从磁盘与仓库的实际状态重建状态，并重新运行要紧的关卡，因此底下发生的任何变动都不会漏网。

核心循环

计划是一次贯穿始终的检查。代理一次只做一项小任务，并且必须在继续之前先通过验证，因此它最多偏出一步，而不是三步。每项任务都带有验收标准以及证明它们的确切命令，进展随工作写入仓库，每项任务各有状态，因此偏移对你、对下一个会话、对下一个代理都是可见的。直到一切通过验证——包括 Final Review——计划才算完成。诚实的告诫：方法论无法阻止代理一开始就写下一条薄弱的验收标准；它做的是让偏移响亮，而非无声。

核心循环

都不是。它从一个目标一次性生成，随后作为工作的一部分被维护。计划有意不从代码 diff 重写，因为追逐代码的规范会变成一面滞后的镜子——那正是该方法论要消灭的偏移。它的演进是有意为之：关卡针对当前仓库重新运行，失败的关卡触发一次精炼，而精炼由代理在运行期间完成，你在事前批准、在事后审阅。文档与测试天然随代码一同演进，因为对它们的更新就在每项任务的关卡之内。

阅读方法论

进展存放在磁盘上，而非聊天记录里。README 复选框、每项任务的日志、一个有界的进行中索引和一个可机器读取的状态文件会在每个任务边界更新，状态文件还会在任何计划内暂停之前记录一个检查点。一个新会话或另一个代理读取那份紧凑的索引，将其与仓库及 git 历史核对，然后从第一项未完成的任务继续，不重做已完成的工作。即使计划创建被中断，也是可恢复的：计划的标识与预期任务列表先于任何任务文件写入，因此半成的计划可以被完成或丢弃，而不是靠猜。

核心循环

每份计划唯一的一项强制收尾任务。依次为：对计划完整累计变更集的安全审查——其中包括由 AI Diff Reviewer 技能对 diff 进行的必备本地审查，critical 发现会在修复或被明确接受之前阻止完成；最终状态验证——即在最终代码上运行仓库完整适用的测试、lint、类型检查与格式化套件；以及对每项任务所记录技能决策的核对。随后，代理报告交付物、证据与局限，并仅提议一次 Executive Report，只有你提出要求才会生成。

查看规范

关卡失败首先是修复信号：代理会修复落在任务自身范围内的问题并重新运行关卡。超出该范围的失败会把任务记录为受阻，代理会在宣称完成之前停下。你可以查看证据、修复代码或精炼任务，然后再恢复执行；命令失败是需要解决不一致之处的信号，而不是削弱关卡的许可。

阅读代理协议

它会大声说出来。检查器以退出码 2 结束，并给出明确的 `UNVERIFIED` 判定——它绝不会打印一个自己并未真正验证的通过结果。当环境缺少可用的解释器或某项检查无法运行时，诚实的结果是「未验证」而非「符合」；绿色结果永远意味着每项检查都已运行并通过。同样的纪律贯穿整个方法论：没有任何流程会削弱或伪造关卡来宣称完成。

符合性契约

可以，前提是该计划已提前获得批准、具备所需的状态层，并赋予代理有界的权限。当现实与计划出现分歧、关卡失败且超出其计划内的修复范围，或需要新的批准或凭据时，无人值守的运行必须停止并记录一个阻塞项。

阅读无人值守协议

可以——编排中心原型正是为此而生。中心仓库持有协调计划，每个子仓库在自己的隔离 `.dwp/` 工作区内运行自己的计划，因此子仓库绝不会写入中心的计划状态。子仓库的完成度从每个计划自身的顶层状态读取，而不是在其内部做字符串匹配；中心在跳转到任何位置之前都会先记录自己所在的位置。每个子仓库仍然是一个普通的 DWP 仓库，也可以独立驾驶。

仓库原型

它们解决的是相邻的问题。规范驱动工具擅长捕捉应当改变什么：以可复用的形态呈现规范、需求与变更提案。Deep Work Plan 关心的是代理如何连续执行数小时而不偏移：接入后的 harness（运行支架）、从触及面中选择的逐任务验证关卡、磁盘上可恢复的状态、带安全审查环节的强制 Final Review，以及针对仓库本身的符合性检查器。二者可以结合：用一份规范或变更提案喂给一份计划。对比页面按每个工具自身的定位将各项能力并排呈现。

查看对比

像 BMAD、Superpowers 和 Get Shit Done 这样的代理工作流框架带来了成熟的工作风格：角色、原则、测试先行的步骤、验证的习惯。Gentle-AI 处于相邻的类别，作为代理生态系统配置器：它为你已经在用的编码代理配备跨会话的持久记忆（Engram）、精选技能、角色设定（persona）、MCP 服务器、可选的 Spec-Driven Development 和可选的基于证据的审查（Receipt-Driven Development），并写入每个代理的配置目录。Deep Work Plan 与两者都不同：它专注于什么留在仓库里、什么可以被检查——任何代理都能冷启动读取的 harness、带验收标准与关卡（gate）的任务文件、能在会话结束后存续的状态、带有 CI 友好退出码的合规检查器，以及一份公开发布的、关于每个流程加载多少指令字节的测量。它在构造上与工具无关，不会给核心循环增加任何服务、提供方或密钥。这些层可以共存：框架和 Gentle-AI 塑造代理的工作方式；Deep Work Plan 让长期工作在仓库内变得持久且可验证。对比页面展示了每种方法在哪些方面是内置的、可选的，或不在范围内。

查看对比

内置计划模式是有用的，而 Deep Work Plan 建立在同样的基础之上——`AGENTS.md` 约定与开放的 Agent Skills 标准。区别在于计划存放在哪里、由什么来保证它被执行。原生计划通常位于仓库之外，并随会话一起失效；Deep Work Plan 把计划、其状态与其证据写进仓库，因此另一个代理或一位队友可以接续它，而且每项任务都带有一道可执行的关卡和一份留存的日志。你可以继续用代理自带的计划模式来思考；方法论补上的是持久、可验证的执行循环。

查看对比

接入是非破坏性的：它会检测已有的 `AGENTS.md`、`docs/`、`.agents/` 或 `CLAUDE.md`，采取调和而非覆盖，并在替换任何内容之前先询问。它会写入带真实命令的 `AGENTS.md` 索引、一棵经过推理的 `docs/` 树、各模块文档、带轻量 `dwp-*` 命令的 `.agents/` 套件、一个被 gitignore 的 `.dwp/` 输出区、一份经过验证的测试映射，以及必备的本地代码审查（AI Diff Reviewer 技能加一份为仓库定制的审查扩展）。随后它会运行自检与符合性检查器，让你看到产出了什么。在更早标准下接入的仓库会得到一次定向的 harness 升级，只调和缺失或过时的部分。

采用入口

这里涉及两种不同的升级，流程把它们分开对待。仓库 harness——`AGENTS.md`、`docs/`、`.agents/` 套件——通过重新运行接入来调和，只补齐缺失或过时的部分。技能本身则通过 `/dwp-upgrade` 前进：先以只读方式检查最新发布的版本，再安装你接受的那个确切标签并加以验证，然后把接入当作一次全新执行重新运行。整个流程每一步都需明确同意，本地适配会先比对再保留而不是被覆盖，`.dwp/` 绝不会被迁移——既有计划保持其记录的形态并继续运行。

采用入口

可以。附加组件是可选叠加层，未安装任何附加组件的仓库依然完全符合 DWP 规范。Devcontainer、Dailybot 报告、依赖升级、设计系统支持以及可选的 CI 审查，只有在适合你的仓库、且你明确接受时才会提供。

浏览附加组件

DWP 不会把缺少工具链当作免检的理由。在接入过程中，代理会提出与技术栈相匹配的验证方案，将相应命令记录进仓库文档，并以这些命令作为未来关卡的目标；该提案会保持可见，供你审阅。

阅读代理协议

方法论与技能均采用 MIT 许可，且完全免费；核心流程中没有服务、没有 API 密钥、也没有遥测。效率以每个流程**在入口处**加载的指令字节数来报告——即会话开始时加载的入口包——并与命名的**端到端路径**一并发布，后者加上了该流程真实触发条件在工作实际推进后所加载的内容（例如，一次进入执行阶段的 resume 通常会加载数倍于其入口包的字节）。这两个数字都不是会话的上限：一次真实运行还会读取仓库自身的文件、工具输出以及计划的工作文件，这些都不计入此账本。两个数字均由随技能一同提交的脚本测量，在各发布基线上重新测量，并发布在一本评估台账中，增长与下降同样如实呈现。它不以 token 百分比或成本节省的形式报告，因为一份字节清单无法证明这些。一项公开的新代理评估已在冻结协议下执行：同样的两个功能，分别在无 harness、上一大版本与本版本的干净克隆上构建。它发现带有 harness 的代理在两项任务中都读取了更少的字节，且本版本的功能会话在两项任务中消耗的模型输入与输出均少于上一大版本——由 harness 报告，单一工作负载。它同样给出了诚实的边界：onboarding 是一次性成本，只有在流程被使用时才会回本；每个工作负载的 token 净方向结果不一；不主张任何时钟时间优势；新代理不会自行进入流程——流程是由你或知道调用它的代理执行的命令。

信任与披露