【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】todowrite 工具提示词（示例）（三）
分析了 TodoWrite 工具第三个示例的 reasoning 内部推理：显式指令模式识别（AI 敏锐捕捉到输入端格式，不仅看到了多个复杂特性，还注意到了它们通过逗号分割的排列方式，这正是触发 TodoList 工具最直接的提示词），认知负荷拆分与重组（将这些很大的特性分解成一个个可管理的小颗粒度任务），全局视野下的进度锚点（让 AI 和用户都能看清当前在整个项目任务中的坐标），接着分析了下一个示例：先分析后判断（面对有性能问题这种模糊的抱怨，AI 先主动扫描可能出现性能问题的区域），生成清单，对症下药，然后单线程规则锁定首个目标，并分析了该示例的 reasoning 内部推理，下面继续分析
OpenCode
接着是不推荐使用 TodoWrite 工具的示例
极简响应 ：面对 Hello World 这种编程界最经典的启蒙级问题，AI 表现得很干脆利落，没有多余的废话铺垫，也不需要启动任何工具，而是直接给出了一行核心代码，体现了大模型在处理低认知负荷任务时的敏捷性
下面来看这里的 reasoning 内部推理
- 任务性质定性 ：这里用户的需求精准命中了之前提到的规则（When not to use），Single（单一，用户的诉求只有一个目标，没有任何分支或依赖关系），Trivial & One step（琐碎且单步，调用内置的
print()函数输出一段字符串，在工程复杂度上几乎为零，既然只需要一个原子步骤就能完成的事情，任何额外的管理动作都是纯粹的浪费） - 追踪价值为零：TodoList 存在的意义是防漏与统筹，当用户请求极其直白（Straightforward），且不存在多个任务或多个步骤时，建立清单就失去了所有的组织收益，如果为了打印一句话而去创建一个待办事项列表，就像是为了喝一口水而去建一个水库一样荒谬
- 防止过度设计：之前提到过，在强化学习中，AI 容易养成讨好型人格，会试图通过展示复杂的管理流程来证明自己很努力，这里就是拒绝形式主义，简单的事情简单做，确保 AI 在面对类似【帮忙加个注释】，【运行一下 xxx 命令】等即时反馈类型的任务时，能够保持高效的响应效率，而不是陷入形式主义
下面看下一个示例
知识检索与科普式输出 ：用户这里提问 git status 命令是干啥的，面对这种纯粹的名词解释或概念查询请求，AI 也表现得干脆利落 ，没有启动任何工具，而是直接从内置知识库中调取了关于 git status 的核心定义，回答得极其专业且全面，涵盖了工作区状态，暂存区状态以及未跟踪文件等核心概念，同样体现了大模型在处理低认知负荷，非工程执行任务时的敏捷性
接着分析 reasoning 内部推理
- 意图定性：同样这里精准命中了之前分析的 When not to use 规则，AI 的大脑瞬间完成了意图分类，这是个纯粹的信息获取请求，当前的上下文中没有任何实际的编码任务需要完成，既然不需要写代码和改代码，那么 TodoList 就失去了存在的土壤
- 行为模式的边界划分：这里用户仅仅在寻求一个解释，在软件工程中，解释一个工作的作用，和使用这个工具去解决实际问题，是完全不同的两个维度，前者只需要调动语言模型的生成能力，而后者才需要调用外部工具链和执行流，这里的 AI 识别到了它应该扮演的是百科全书，而不是施工队角色
- 防止过度反应 ：之前的 Blog 分析过，TodoList 是为了解决复杂的多步任务，当用户只是问一个概念时，如果 AI 强行列出一个清单，比如
1、解释git status的定义
2、说明它显示的分支信息
3、说明它显示的暂存区信息
这样不仅显得僵硬，还会破话自然对话的体验，所以这里的示例划定了界限，单维度的知识解答，不需要被分解成多步骤的工程流水线
OK，本篇先，到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog