【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】todowrite 工具提示词（示例）（四）
分析了不推荐使用 TodoWrite 工具的场景，首先是极简示例 Hello World，面对这种最经典的启蒙级问题，AI 表现得干脆利落，没有废话，也没有调用工具，而是直接给出了核心代码，体现了大模型在处理低认知负荷任务时的敏捷性，其 reasoning 内部推理中，这里用户的需求精准命中了之前提到的规则（When not to use），给任务定了性，并且 TodoList 存在的意义是防漏与统筹，当用户请求极其直白，且不存在多个步骤时，其追踪价值就为零，并且这样做也是为了防止过度设计，然后接着分析了另一个知识检索与科普式输出的示例，用户提问 git status 命令的作用，面对这种纯粹的名词解释，AI 也表现得很干脆利落，其内部推理 reasoning 和上一个示例大同小异，下面继续分析
OpenCode
下面看下一个示例，加注释
单点操作与工具调用：面对这种目标极其明确，指向性极强的微观修改需求，AI 选择了直接调用 Edit 工具进行了原地修改，这种任务不需要 TodoWrite
接下来是 reasoning 内部推理
- 任务单一：和上一个示例一样，这里的任务被认为是单一且直接的，用户的诉求只有一个目标（给特定函数加注释），没有任何分支或者依赖关系，不存在需要统筹规划的复杂性，另外，
- 位置单一：相比于前面那个重命名函数涉及到 8 个文件 15 处引用的例子，这里的修改范围被限制在一个特定的函数体内，既然影响范围这么小，就完全不需要用 TodoList 来进行全局追踪和防漏管理了
接下来看下一个例子，用户请求帮忙跑一下 npm install 命令
指令执行与反馈 ：这里 AI 直接调用了终端工具执行命令，并输出命令执行结果，可以看出来大模型在处理即时反馈型任务时的敏捷性，同样，在 reasoning 内部推理中，这里只是单条简单的命令，并且要求的是即时反馈，所以不需要 TodoList 清单
接下来看 TodoWrite 工具必须遵守的规则
首先是 Task States 任务状态机，这里定义了一个严谨的状态流转系统，有四个合法状态
pending（待办）：还没开始，这是任务的初始态，相当于排队等候执行in_progress（进行中）：当前正在执行的任务，这里括号强调了单线程原则，不能同时作业completed（已完成）：任务成功完成，代表一个闭环的结束cancelled（已取消） ：在实际工程中，需求是会变的，如果中途发现某个步骤没意义了，AI 不需要强行做完，而是可以将其标记为cancelled，保证效率
接着是 Task Management 任务管理规则：
- 实时同步：AI 不能等执行完所有任务再回来改状态，而是要在执行的过程中实时更新，确保用户看到的是实时进度
- 立刻打勾，严禁批量 ：不能一口气执行完多个任务，然后一次性把这些任务批量标记为
completed，这条规则强制要求 AI 做一个就结项一个 - 全局唯一进行中：无论清单多长，同一时间只能有一个任务在执行
- 执行完当前任务后，才允许开启下一新任务，遵守串行规则
- 及时止损：如果任务是无用的，尽快取消
最后是 Task Breakdown 任务拆解规则，有了状态和管理，还得有高质量的任务内容本身：
- 具体且可执行：任务不能是抽象的废话（比如优化代码），而必须是具体的动作（比如给 ProductList 组件加上 memorization 记忆功能）
- 复杂任务拆解：遇到复杂的难题，必须将其拆解成具体可执行的步骤
- 任务名清晰没有歧义
这里最后提醒 AI，当遇到犹豫不决的任务（处于灰色地带，不确定任务算不算复杂时），默认响应应该是建立清单防患于未然，而不是因为盲目自信而导致漏掉关键步骤
OK，本篇先，到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog