Skip to content
Deep Work Plan 今天登陆 Product Hunt 去支持

对比

Deep Work Plan 与替代方案

根据你的处境选择合适的层。每个替代方案都按其自身定位来描述，每项事实都可追溯到其官方文档，页面也标明最近一次复核的时间。这是一张地图，不是一份排名。

如何阅读本页

三个取值描述每项能力。它们说明的是一项能力位于工具中的何处，而不是工具的好坏。

  • 内置
  • 可选或通过扩展
  • 不在范围内

最近复核:

替代方案，按各自定位呈现

规范驱动开发工具

  • 规范驱动开发工具

    GitHub Spec Kit

    通过一部宪章、一份规范、一份计划和一份任务清单，把一个功能转变为可执行的规范，由与五十余个编码代理集成的斜杠命令驱动，并能在开始实现前检查各产出物之间是否保持一致。

    希望在自己已在使用的代理内部获得可复用的“规范、计划、任务、实现”工作流的团队。

    查看比较 官方网站

  • 规范驱动开发工具

    OpenSpec

    把每次变更捕捉为一份提案，带增量规范（新增、修改、移除）与含场景的 RFC 2119 需求，随后将它们归档为不断生长的活规范，并配有验证器在变更被接受前检查提案完整性与场景覆盖度。

    在存量系统上工作、希望规范随每次变更逐步生长的团队。

    查看比较 官方网站

  • 规范驱动开发工具

    Amazon Kiro

    一款代理式 IDE 与 CLI，其规范从 EARS 风格需求推进到设计再到任务，并带有在编辑器事件上运行的引导文件与钩子，还能为已有代码库生成规范，在设计开始前发现需求缺口。

    希望规范驱动开发内置于编辑器、并配有 AWS 支撑工具链的开发者。

    查看比较 官方网站

代理工作流框架

  • 代理工作流框架

    BMAD Method

    一套由专业化代理角色（分析、产品、架构、开发、质量）组成的敏捷框架，产出简报、需求、架构文档与故事文件，其完成定义要求每个故事在被视为完成前必须经过队友或 AI 同行评审代理的审查。

    偏好角色化仪式、并希望代理工作拥有完整敏捷生命周期的团队。

    查看比较 官方网站

  • 代理工作流框架

    Superpowers

    一套技能库与工作流，用于头脑风暴、以测试先行的小步骤规划、用子代理执行，并在完成前审查，其支持的编码代理宿主数量超过本页任何其他方案，并对每个任务执行两阶段子代理审查（先检查是否符合规范，再检查代码质量）。

    希望在编码代理内部获得纪律化测试驱动执行的开发者。

    查看比较 官方网站

  • 代理工作流框架

    GSD Core

    一套计划系统，带有 .planning 目录、需求编号、阶段计划、全新上下文执行，以及针对从每份计划摘要中提取的、用户可观察交付物的验证环节；它专为对抗“上下文腐化”而设计——在一次性子代理中运行调研、规划与执行，并通过内容指纹检查发现已过时的验证结果。

    想要上下文工程与验证、又不想有太多仪式的独立开发者与小团队。

    查看比较 官方网站

  • 代理工作流框架

    Gentle-AI

    为你已经在使用的编码代理配置持久记忆（同时可跨会话、跨模型进行路由）、精选技能、MCP 服务器、人设，以及可选的 Spec-Driven Development 或 Receipt-Driven Development。其配置默认写入代理的全局设置；按工作区范围安装则是可选项。

    面向希望拥有一个能跨会话记住工作、并可按需生成证据的已配置代理生态系统的开发者。

    查看比较 官方网站

AI-native SDLC

  • AI-native SDLC

    Claude's AI-native SDLC

    一个从 Plan、Design 到 Build、Test、Deploy、Maintain 的六阶段循环，每个阶段都设有人工批准关卡，各阶段之间把持久产出物提交到仓库，在部署前设有专门的安全审查环节，并通过持续评估发布领先与滞后的交付指标。

    面向正在评估 Claude Code 端到端软件交付手册及其生产反馈循环的团队。

    查看比较 官方网站

厂商原生计划模式

  • 厂商原生计划模式

    厂商原生计划模式

    代理产品可能提供计划模式、指令文件与技能，它们建立在开放、跨厂商的 AGENTS.md 与 Agent Skills 标准之上，但计划模式的具体行为仍取决于厂商、客户端与版本。其中 Agent Skills 在启动时只加载简短摘要，仅在被激活时才加载完整指令，从而把未使用的能力留在上下文之外。

    希望在单个代理内部获得规划能力、而无需采纳一套方法论的人。

    查看比较 官方网站

Deep Work Plan 带来什么

  • 工具无关、仓库原生

    harness（运行支架）与计划都是你仓库中的文件，任何遵循 AGENTS.md 与 Agent Skills 标准的代理都能读取。更换代理不会丢失计划。

  • 从每项任务触及的内容中选择的验证

    每项任务声明其触及面，并运行被改行为及其消费方的测试，当影响无法界定时，扩大到完整的测试套件。选出的测试数量为零永远不算通过。

  • 一次带安全审查环节的 Final Review

    计划以对累计变更集的安全审查收尾，其中包括对 diff 的必备本地审查，以及对最终状态的验证。critical 发现会阻止完成。

  • 跨会话、跨代理存续的状态

    README 复选框、任务日志、有界的进行中索引与可机器读取的状态文件在每个边界写入，因此另一个会话或另一个代理都能从磁盘接续。即使计划创建被中断，也是可恢复的。

  • 针对仓库本身的符合性检查器

    一个只读脚本依据规范核验 harness 与每份计划，理解两种计划生命周期，并以对 CI 友好的退出码退出。

  • 指令加载的测量与发布

    一个已提交的脚本为每个流程发布两项测量——会话开始时加载的入口包，以及其真实触发条件启动后的端到端路径——并说明各自的排除范围，因此入口数字本身从不会被当作一次运行的总成本。结果——包括增长——以字节数发布，从不用 token 或成本百分比表示。

诚实的局限

Deep Work Plan 没有活规范或增量规范机制；OpenSpec 及类似工具在那一面更强。该方法论尚无独立基准测试；一项第一方新代理评估已在冻结协议下执行，规模较小——单一工作负载、每种配置两个功能、一台机器——其结果双向公布：带 harness 的代理在两项任务中读取字节更少，本版本的会话消耗的由 harness 报告的模型输入与输出少于上一大版本，同时每个工作负载的 token 净方向结果不一，且不主张任何时钟时间优势。指令加载台账测量的是加载的字节数，而非 token、成本或结果，其入口包数字也并非一次运行的上限。DWP 有意将范围限定在仓库之内：它不是跨项目记忆系统，不是基于角色的代理框架，也不是一款 IDE，因此它也不在这些维度上参与竞争——当工作确实需要这些能力时，请将它与覆盖该能力的工具搭配使用。

帮助我们保持准确

帮助我们保持准确

本页在所示日期复核，并按请求更正。如果你所用工具的描述已过时或不完整，请提交一个 issue，我们会修正。

提交 issue