【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】todowrite 工具提示词（禁用场景）
分析了不推荐使用 TodoWrite 工具的场景，防止过度设计：单一且直接的任务（防范 AI 的形式主义，面对单一直接的任务时，应该保持敏捷，跳过流程直接交付结果），琐碎且无组织收益的任务（琐碎意味着任务的认知负荷低，而无组织收益意味着即使把任务放进清单里，也没任何帮助，所以 AI 必须学会权衡，调用工具本身是消耗 Token 和时间的），少于三步的简单任务（这里的规则和之前的规则形成逻辑互斥与闭环），纯对话或检索类任务（场景隔离，划清工程师模式和聊天模式的界限，TodoList 是专门为代码工程设计的状态机，而闲聊或问答是没有终点的流式交互），下面继续分析
OpenCode
下面看第一个示例
- 意图识别与触发机制：这里用户的诉求【添加 Dark 模式】触发了两个规则【三个以上独立步骤】，【复杂任务】，所以这里 AI 没有直接去写 CSS，而是意识到该任务是个需要仔细打磨的系统级功能，触发了 TodoWrite 工具
结构化拆解：AI 把一句用户的自然语言，翻译成了 5 步严密的软件工程流水线：
- UI 层：先造出用户能看到的开关按钮
- 数据层：建立全局状态管理，让全应用都能读取到当前的主题状态
- CSS 样式层：真正去编写 Dark 模式的底层样式逻辑
- 集成任务：把现有组件全部接入新的状态系统，完成闭环
- 测试验收：执行测试和构建，并处理报错
这里体现了 AI 的架构思维 ，普通程序员可能会想改一下颜色就 OK 了，但 AI 展现了资深工程师的思维（关注点分离 ），清晰地划分了 UI，State，Style，Intergration 四个维度，确保代码的高内聚低耦合 ，此外，用户在原始需求只提到了需要运行测试和构建，这里 AI 补充加上了如果出现了报错，需要主动进行定位和处理，替用户补充完善了需求，很严谨
OK，接着看 reasoning 内部推理
内部推理展现了 AI 在使用 TodoWrite 工具前的思考与原因分析，有三个推理点：
- 复杂度定性：这是 AI 对任务本质的架构级定性，AI 没有把加个 Dark 模式当成一个简单的改色需求，而是看出了其底层技术栈，明确指出需要跨越三个核心领域：UI（界面交互），State Management（状态管理）和 Styling（CSS 样式系统），这也是任务触发 TodoWrite 的原因，因为这仨领域的代码逻辑是完全不同的，如果不拆开成独立的步骤去规划，AI 就容易写出高度耦合的代码
- 用户显式指令：这是对用户原话中【Run the tests and build】的直接回应，在多步开发任务中，AI 容易沉浸在写业务代码里，而忘记用户最后附加的收尾条件，这里把显式指令单独拎出来作为推理依据，表示这是个硬性交付标准，需要绝对执行，呼应了上面 TodoList 的最后一点
- 隐式需求推演：这是整段推理中含金量最高的点，注意这个词【Inferred】（推断），用户只说了跑一下测试和构建，但作为开发者，如果跑测试报错了就不管，那等于没做，所以 AI 这里不仅识别到了用户提的显式需求，还识别了没说出来的部分，所以在 TodoList 的最后一步，主动加上了【处理任何出现的失败或错误】，主动补全闭环用户需求
从 reasoning 可以看到 AI 的内在思考引擎，其列计划并不是随意的，而是基于了技术架构分析，显式指令提取，隐式意图推断三大维度，很有逻辑
OK，本篇先，到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog