AI 编码代理跑长任务, 最大的问题往往不是模型不够强, 而是做到一半就跑偏——上下文被冲掉, 计划断掉, 最后交付的东西和最初设想对不上。Deep Work Plan 想解决的正是这件事。它不是又一个聊天窗口, 而是一套写进仓库里的规范。
项目本身是一个开源方法论, 附带一个入口文件 init.md。把那个文件的地址交给任意 AI 代理, 代理会先读完整个提示, 然后把当前仓库改造成"AI 优先、规范驱动、可自动驾驶"的状态。官方称它为 executable onboarding prompt——一个可执行的入职引导。听起来有点玄, 但实际逻辑很直接: 先把方法论装进仓库, 再让代理按照这套标准干活。
把计划变成仓库的一部分
Deep Work Plan 的核心主张是 Context matters more than models。与其不断换更强的模型, 不如把上下文结构化。具体做法是把任务拆成原子任务, 每个任务带验收标准和校验门, 同时保留可恢复状态。这样即使一次长时间运行中途上下文被重置, 新的代理实例也能从上一次结束的地方继续, 而不是从头再来。
网站上的方法论部分提到几个操作原则, 对实际使用很有参考价值。比如它要求代理先了解当前仓库, 不套模板; 如果仓库里已经有 AGENTS.md、CLAUDE.md 或类似约定, 不要直接覆盖, 而是先检测、阅读, 再合并改进; 大改动前先提出计划等用户确认; 按安全、可审查的增量推进; 失败或状态模糊时停下来报告。这些原则让它在面对已有工程惯例时表现得更像一个谨慎的协作者, 而不是莽撞的重写者。
还有一个细节值得注意: 它明确要求代理把 init.md 视为不可信输入, 确认来自官方源后评估再行动, 并验证技能的完整性。这种 trust-but-verify 的姿态在 AI 代理工具里不算常见, 倒是更像安全工程师会写的东西。
对谁有用, 怎么用
对经常让 AI 代理处理跨多文件、需要多步骤完成的开发任务的团队, Deep Work Plan 提供了一个低成本的规范化入口。你不需要换工具, 也不用绑定某家代理——官方强调 agent-agnostic 和 no lock-in, 任何代理都可以被指到这个 init.md, 任何仓库都能采用这套规范。
使用方法也简单: 在支持的代理里粘贴 https://deepworkplan.com/init.md 这个地址, 代理会获取内容并开始执行。官方还说明, 给 URL 加上 Accept: text/markdown 头就能拿到 Markdown 版本, 而不是 HTML。
- 原子任务: 每个小步骤可独立验证, 避免大而全的模糊指令。
- 验收标准与校验门: 每阶段有明确的完成定义, 不过门槛不进入下一步。
- 可恢复状态: 长任务不怕上下文重置, 后续代理能接续。
- 开源 MIT: 整个方法论和规范文本开源, 可以自由采用和修改。
一些务实的提醒
这套方案的效果高度依赖代理对 init.md 的遵从度。如果底层模型不擅长严格遵循多步指令, 或者没有工具调用能力来读写文件, 那么再好的计划也只是纸上谈兵。另外, 把现有仓库改成规范驱动需要代理先做侦察并与用户确认, 这个过程本身会消耗一些时间和 token, 不是零成本的。
官方公开的技术细节目前并不多——没有性能数字, 也没有大规模案例库, 主要是方法论文档和几个示例。对这种开源项目, 最靠谱的验证方式是自己跑一次: 拿一个真实仓库, 让代理走一遍 init.md, 看看产出的结构和后续任务的稳定性是否符合预期。
如果你正在被 AI 代理"半途而废"困扰, 又不想被某家厂商绑定, Deep Work Plan 是值得试用的一套轻量方案。它不替代模型, 也不替代工具, 而是给代理一副看得懂的地图。反正开源, 试错的成本很低。
评论
暂无评论
成为第一个评论的人