我做了一个自己的 Plan Mode：把模糊需求变成可执行任务

用 clarifier 和 todos 两个 Skill，把模糊需求变成可执行、可落盘的任务。

上一篇文章提到，很多 Agent 的官方 Plan Mode 目前还有两个问题：一是计划阶段不能主动运行命令，容易让计划建立在猜测上；二是计划文件通常只能保存在官方预设的位置，不方便和项目一起管理。详见上一篇文章《Plan Mode 已成为标配，但还有哪些问题没解决？》。

这篇文章就讲下，我如何用自己写的两个 Skills：clarifier 和 todos，在保留 Plan Mode 核心流程的同时，解决上面两个问题。

其实方法很简单：直接使用 Full Access 模式，让 Agent 保留读取文件、运行命令检查环境以及搜索的能力，再通过 Skill 约定好从澄清到落盘的完整流程。

Part 1｜clarifier 负责尽可能地收集信息

clarifier 的第一条规则，保留和 Plan Mode 的核心流程，就是先尽可能收集与任务有关的上下文。

这里的上下文包括三类：我已经提供的想法、文字、文件和链接；Agent 能够通过读取文件、运行命令、检查环境获得的基本事实；以及通过搜索和调研获得的最佳实践、基本共识与真实痛点。

比如，我想检查数据的可用性，Agent 一旦可以用命令确认，它就没有必要靠经验猜测；如果想要获取相关已有的信源，Agent 也会主动调用搜索工具进行可靠信源的获取，降低幻觉率。

这样做可以让我与 Agent 的后续讨论建立在更扎实的事实基础上。同时，尽可能让 Agent 去做探索和验证，也能保证高质量信息在决策中的比重。

收集完上下文之后，clarifier 会通过多轮讨论，逐步明确任务的背景与动机、最终目标、基本假设、实施边界以及实施细节、可接受的风险和验收标准。

如果这些内容还不完整，它就要继续提问和澄清，不能擅自补全。这里我特意要求 Agent 多和用户沟通，因为很多需求有所偏差，其实就是双方对同一句话的理解不一样。与其让 Agent 猜完再返工，不如在歧义刚出现时就把问题暴露出来。

整个过程中还设置了一个关键门控：只有当 Agent 认为信息已经足够，才向我概括各个板块的内容，并说明准备如何新建或修改任务文档；接下来，只有得到我的明确同意，它才能真正写入文件。如果我不同意，就继续讨论。

这一步是保留了对流程的控制权。什么时候结束讨论、什么时候把结论落盘，仍然由我决定。

最后，我还提前约定了任务文档的固定结构：“背景与动机”“最终目标”“基本假设”“实施边界以及实施细节”“可接受的风险”“验收标准”“更多细节”七个板块。每个板块都要求简洁、明确。

预先约定格式是为了稳定输出的下限。以后如果发现现有结构不够用，也可以直接修改 Skill，调整格式要求或增加新的板块；下一次调用时，Agent 就会遵循新的约定。

clarifier 负责把问题讨论清楚，todos 则负责把讨论结果变成可以管理的任务。任务文档直接保存在我指定的项目根目录的 todo/ 目录里，可以和代码、数据及其他项目资料一起检索和维护，不再受官方计划目录的限制。

我给 todos 设计的规则很简单：一个 Markdown 文件就是一个任务，文件所在的目录就是任务状态，文件名里的序号就是任务的执行顺序和父子关系。

整个待办系统只有三个状态目录：

todo/
  pending/
  done/
  abandon/

新任务放进 pending/，完成后移到 done/，确认不再继续的任务移到 abandon/。状态只由文件所在的位置决定，不需要额外维护数据库、看板字段或一套复杂的同步流程。

任务文件名可以使用 step01_任务名称.md、step01.01_子任务名称.md 这样的多级序号。编号既表示大致执行顺序，也能直观看出父任务和子任务之间的关系。不同项目如果已经有自己的命名习惯，也可以沿用原来的格式。

任务文档会成为我和 Agent 后续沟通的默认基线。不过，文档并不是不可推翻的“圣经”：如果实施时验证出的最新事实与原计划冲突，应当以事实为准，并要求 Agent 把偏差说清楚。

这套系统学习成本不是很高。只需要记住：

任务就是文件，目录就是状态，序号就是顺序。

平时可以直接在编辑器或文件管理器中查看，也可以让 Agent 扫描三个目录后总结一下当前项目的进展。

如果以后需要优先级、负责人、依赖关系或其他状态，直接与 Agent 沟通，根据自己的需求再增加几条约定，或者扩展任务文档的内容就行。

目前，我已经使用 clarifier 和 todos 这两个自建 Skill 有一段时间了。整体来说，它们比较容易上手和理解，没有太多复杂步骤。无论是写科研代码，还是执行一连串的操作，整个过程都更可控，也更省时间。

省时间是因为重要问题被提前讨论清楚了，这样形成的任务文档内容也足够扎实，目标和验收标准足够明确，依靠现在旗舰模型的能力，后续实施基本都能跑通主流程。

不过，这套方法仍然有几个使用前提。

优先使用当前开源或闭源的旗舰模型。无论是社区经验还是官方 benchmark，复杂计划和需求澄清都更依赖模型的推理能力、上下文理解能力和自我纠错能力。模型能力不足，流程写得再完整，也可能只是在稳定地产出一份质量一般的计划。
尽量开启 Full Access 模式，让 Agent 能在计划前读取文件、运行命令、检查数据和验证环境。否则，它仍然可能被权限卡住，只能依靠猜测写计划，也就失去了这套流程最重要的一部分价值。当然，开启完全权限也意味着风险，需要清楚安全操作边界，涉及删除、覆盖或外部发布等高风险操作时，仍然应该仔细确认，提前做好数据备份。
讨论时要大胆质疑，提出不理解的地方，大胆提出愚蠢的问题，也要大胆放弃当前阶段不重要的事情。不理解就提出质疑，而不是全盘接受。不懂就问，再愚蠢的问题也要问。不在非核心的问题上过分纠结，不要试图做一个完美的方案，而是做一个当前可行的方案，比如项目初期就是先快速跑通主流程，验证想法是否可行就够了；兼容处理、兜底方案和细节打磨，可以留到验证成功后的下一阶段。

始终以你自己的判断为主。如果 Agent 输出了与主线无关、你认为没有必要的内容，就及时通过沟通把它拉回来，避免在非主线问题上越走越远。其实，“如何避免和 AI 聊着聊着就偏离主线”本身也值得单独写一篇，后面可以再开一个坑。

其实真正花时间的，真的就是这一步了，就是“搞清楚为什么要这么做？”。

至于如何基于这份任务文档继续实施，就是下一篇文章的内容了。

下一篇会详细讲：有了扎实的任务文档之后，会面临的一些问题，比如：

clarifier 与 todos 的完整内容及后续更新统一维护在公开仓库 easy-simple-skills。

仓库保留了两个 skill 各自的 SKILL.md 路径，读者可以在线查看，并跟踪后续更新。

原文发表于微信公众号。