DWP v5：承诺，如今由测试保证

今天我们发布 Deep Work Plan v5。这不是一次重写：这是数月真实使用的结果——包括对 108 个真实计划的直接审计——一处又一处地揭示出方法论的承诺与智能体实际行为可能出现分歧的地方。对这个版本最诚实的概括：这些能力方法论早已承诺——现在它做出了保证。在 v5 之前，一个逐字照着文档执行的智能体仍可能落入真实的失败场景；如今每一个这样的场景，都是通过这些实际使用和反馈被发现的，已经关闭，并由可执行的测试锁定——而不是靠更多文字掩盖过去。本周期内技能的契约测试套件从 132 个增长到 258 个，且下文的每一项保证都是针对已发布的 tag 在实测中验证的——先安装进一个干净的仓库，再跑完它自己的全部流程，然后才写下这篇条目。

绝不谎报未验证成功的验证器。 一致性检查过去会静默降级：在没有可用解释器的情况下，它会跳过所有验证，却仍然打印出「符合」的判定；字段内的粗体文本也可能被误判为字段缺失。现在，只要验证器无法真正完成验证，它就会以显式的 UNVERIFIED 判定退出。验证器绝不报告自己没有检查过的成功——对验证闸门的信任就是全部主张，而一个能跳过自身检查的闸门会毁掉整条信任链。

Lite 计划的唯一审批契约。 对于「启动这个计划是否就批准了它的当前范围」这个问题，三个界面曾给出三种不同答案，智能体恰恰在最危险的边界上可能死锁，或者在未获授权的情况下运行。v5 在所有界面上确立唯一契约：显式的 execute 或 resume 批准当前 ready 的范围，并在做任何工作之前记录该批准；仅一个待审提案本身不授权任何事；被中断的晋升会在任何产品工作运行之前先完成恢复。

不会破坏状态的多仓库编排。 编排中心的环境覆盖过去会泄漏到子仓库——子仓库可能把计划状态写进中心自己的目录。编排模板还会打印 FAIL 却以成功码退出；一个只对状态字符串做 grep 的完整性检查，会把单个已完成的任务误读为已完成的计划。现在，中心根路径在进入子仓库之前先被保存，每个子仓库隔离地解析自己的 .dwp/，每个失败分支都以错误码退出，完整性从计划的顶层状态解析，devcontainer 入口点在任何删除之前先传播复制错误。

唯一的插件同意矩阵。 哪个插件默认安装、哪个只是提议、哪种评审是必需的——此前的界面答案不一。v5 给出唯一矩阵：AI Diff Reviewer 为本地评审所必需，固定到经过验证的版本，CI 评审则是显式选择、绝不自行启动；design-system 插件在检测到 UI 工作时必须提议，但只在明确接受时安装；dependency-upgrade 插件以近乎默认、惰性的委托器形式提供，并带有精确快照回滚；dailybot 只在被授权的地方汇报。空 diff 不再计为已完成的评审。

面向长周期计划的真正机制。 对 108 个真实计划的审计显示：可并行的工作很常见，但顺序执行的决定几乎从不被声明，阶段闸门也只是零散的个人实践。v5 要求执行决定总是被声明——当并行不成立时，声明为顺序执行并记录原因——为二十个及以上任务的计划增加可选的 Stage Gates，并以严格度层级、证据标准和禁止操作丰富 Plan Variables。所有这些都按需渐进加载，绝不拖累 Lite 计划。

强制 Context，每任务单一目标。 计划可能退化为没有上下文的任务清单，一个任务也可能把三个目标打包在一个绿灯之后。v5 要求计划层面的 Goal 与 Context 成对出现，每条新任务记录都有任务级 Context——一个新会话独立启动该任务所需的一切（已完成的记录保持原样），并让「一任务一目标」成为规范规则，附带防止退化的守卫。

一条安全的升级路径。 /dwp-upgrade 是全新的。它的检查阶段只读、不安装任何东西；升级只在明确接受后开始，本地适配在覆盖任何内容之前先做比对并呈现；安装指向精确的 tag 并自我验证；onboarding 以全新 init 重新执行。升级绝不触碰 .dwp/——任何计划、状态文件、闸门记录或证据都不会被迁移、改写或失效。

诚实、可度量的证据。 效率主张现在在三个基线上重新度量——v3.0.0、v4.0.3 与最终代码树——度量脚本已提交到仓库。结果以文件系统字节数报告，绝不换算成我们无法背书的 token 数或成本数字；每一个无法验证的主张都在评估记录中被明确隔离标注。

一份有版本号、已发布的契约。 上述每一项承诺都由其他工具可以读取的数据支撑，而不只是文字：plan-manifest 与 plan-state 格式现在作为 v5 schema 系列进行版本管理——plan-manifest/v5.json 与 plan-state/v5.json——这样一个计划、一个验证器，或第三方工具都可以对照已发布、机器可读的契约来检查一致性，而不是对照一段文档文字。v5 系列相对 v2 没有任何形状上的变化：引用 v1 或 v2 schema 的现有计划依然有效，永远不会被重写。

Deep Work Plan v5 遵循 DWP 标准 5.0.0。阅读规范文本，查看技能仓库，或从 /init 开始采纳。

更新 — 2026-09-17 · 技能 v5.4.0

v5 线的首个补丁版本，堵上了计划可能凭借“从未真正检查过的工作”收尾的最后一条路径，并确定了计划自身证据的存放位置。DWP 标准 5.0.0 保持不变：这是一次附加组件契约与文档的发布，而非模式变更。

一次从未运行的审查，不再与一次干净的审查难以分辨。 Final Review 的安全审查环节此前已经区分了审查器缺失——记录为一条结果——与调用出错（警告一次后继续）。上游的审查器又带来了第三种结局：一次启动后退出、却没有写下任何结果的运行。在它没有名字的时候，它会被归入“审查完成且一无所获”，从而让计划得以凭借一次并未发生的审查收尾。如今它自成一种状态：记录为不完整的审查，绝不被算作变更集干净的凭据，也绝不构成关闭 Final Review 的理由。三种截然不同的结局，而它们当中没有任何一种意味着这份 diff 被读过且是干净的。

计划的证据属于计划。 标准此前已经把分析记录、skills 台账、安全审查与门控日志放在计划自己的 analysis_results/ 之下，却从未把这种排他性写成规则。于是，一个仓库自身的审计工具——其报告路径默认写入工作目录——可能悄悄把某个计划的证据写到仓库根目录，而没有任何流程察觉。规范现在明确要求：流程围绕某个计划产出的一切，都进入该计划的文件夹；对于默认输出到工作目录的工具，必须显式传入其输出选项。不在计划所说位置上的证据，就等于已经丢失——这才是这条规则的现实理由，而非归档偏好。

AI Diff Reviewer 的固定版本升至 v2.3.0。 必备的本地审查如今安装的审查器，将 runner 与 backend 分离，因此同一份审查可以对任何兼容端点运行，而不改变 DWP 所依赖的东西——中立性保证由此得到加强，而非放松。它还带来经校验和验证的安装程序、以实测而非猜测为依据的成本默认值，以及在携带未决结果向前推进的同时审查真正新增 diff 的后续轮次。最后一点有一条值得直说的契约含义：模型自称某条结果已解决，并不能撤销它——撤销它的是维护者。

工作原则如今随 harness 一同交付。 同一天稍晚发布的 v5.5.0 让接入不只告诉仓库中的 agent「这个仓库里有什么」，还教它们「该怎么工作」：十项紧凑的行为——对结果负责、开口求助前先查证、独立决定例行事项、在确实缺少判断依据或授权时上报、宣布完成前先行验证等——内联写入 AGENTS.md，只读入口文件的 agent 也能读到。它们是单次请求范围内的默认行为，绝非新的授权：不能凌驾于宿主权限、更窄的范围、计划的门控或仓库自身的审批规则之上。升级按语义而非关键字进行调和，因此文件中已有的等效规则会被保留而不是改写。

AI Diff Reviewer 的固定版本升至 v2.3.1。 技能 v5.5.1 安装的审查器，其 check、审查正文与跟踪评论保持一致。正文写着 Recommendation: approve 并不证明 check 已通过——请阅读跟踪标记中的 Check status 区块。在 advisory 模式下，一项经证实的修复可以撤销其讨论串已折叠的结果，因此卡住的 PR 可以在真正修复后变绿。

规范文本见规范，审查器现在的能力见附加组件参考，源头见 v5.5.1 发布。

更新 — 2026-09-25 · skill v5.5.3 + 审查器 v3.1.1

AI Diff Reviewer 附加组件现在文档化并安装审查器的 v3 线，发布于 2026-09-24（v3.0.0 → v3.1.1，移动引脚 @v3）。skill v5.5.2 围绕 v3 审查器的实际行为重写了附加组件的规范文档、接入钩子和集成模板，v5.5.3 交付了 CI 侧。经与标签 v3.1.1 的已发布审查器核对，最重要的变更：

critical 只有在验证之后才会门控。 自 v3 起，模型声称的每条关键发现——外加 30 % 的警告样本——都会由一次独立的模型调用进行第二次简短的、基于代码的核查（每条经验证的发现约 3 k token、10 秒、$0.009）。critical 只有在该验证器确认之后才会发布——并阻断 Final Review；被驳回的断言仍以带注解的警告保持可见，并列入结构化输出，绝不内联发布。耗尽轮次上限（incomplete）或墙钟时限（timeout）的审查在阻断性严格度下是红色的——“没有发现”如今总是意味着审查器看过而一无所获。

预算跟随风险等级。 审查预算从变更的确定性风险等级推导——从 low 到 critical 为 8/20/30/40 轮——不改变任何代码的推送会以 −93 % 的成本运行一轮仅验证器的审查。budget-profile: fixed 在过渡期恢复 v3 之前的常量；增量轮次将输入 token 削减 62–76 %。

六个子技能，其中一个是循环。 路由器新增 address-review（v3.1.1 新增）：一次调用即可找到该分支打开的 PR、确认审查已覆盖当前 head、呈现各项发现，然后——在一句“好”之后——应用、以小型 Conventional Commits 批次提交、推送，并按仓库触发它的方式重新武装审查器。apply-review 保持只读；结构化输出（review-output/3.0）是任何自动化的机器路径。@v2 线冻结在 release/v2，享有六个月的安全与目录维护——v3 是建议，绝非强制迁移。

审查器现在审查自己的家。 skill 仓库与本网站都运行标签门控的 CI 自审——通过 DailybotHQ/ai-diff-reviewer@v3 的单条 grok 腿，每次 ready 标签被应用时触发一次（重新运行请取下再贴上标签），提供商密钥缺失时诚实跳过。本网站还 vendorize 了 v3.1.1 审查器，因此本地 Final Review 与文档现在传授同一个契约。

阅读规范、附加组件参考了解完整的 v3 能力列表、v5.5.3 发布了解来源，或审查器 v3.1.1 发布了解上游变更。