【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】todowrite 工具提示词（示例）（二）
分析了 TodoWrite 工具第二个示例，用户提了个重命名的需求，首先 AI 是先搜索（先调用搜索工具摸清所有待修改点的位置），后决策（根据搜索结果，8 个文件中存在 15 个引用，由于是复杂任务，动态决定使用 TodoWrite 工具），然后继续分析了reasoning内部推理，包括评估任务边界（理解任务范围），复杂度阈值触发（动态根据搜索结果决定后续动作），系统化追踪机制（把重构工作变成可以逐项打勾的流水线）以及一致性保障，然后接着分析了第三个示例，用户想要开发新功能，其中用户提的需求直接精准命中触发条件，并且面对这种复杂的任务，使用的是单线程执行，下面继续分析
OpenCode
下面继续看第三个示例的内部推理reasoning
- 显式指令模式识别：这是 AI 对输入端格式的敏锐捕捉，它不仅看到了多个复杂特性，还注意到了它们的排列方式（comma separated list 逗号分割），这正是触发 TodoList 工具最直接的提示词，前面的 Blog 提到，当需求以列表形式呈现时，最佳的处理方式就是将其映射为一个结构化的执行清单，确保用户的每个需求都被记录下来
- 认知负荷拆分与重组：化繁为简，电商结账流程这种级别的特性，如果作为一个整体去执行，容易导致上下文爆炸或逻辑混乱，这里 AI 通过推理确认，需要用 TodoList，将这些很大的特性分解成一个个可管理的小颗粒度任务，减轻 AI 自身内存压力的同时，整个开发过程也变得可控
- 全局视野下的进度锚点：TodoList 不仅能用来干活，也能用来导航，确保无论当前正在处理哪个微小的代码片段，AI 和用户都能看清当前在整个项目任务中的坐标
下面看下一个示例
- 先分析后判断：面对渲染慢（rendering slowly），有性能问题这种模糊的抱怨，AI 没有一上来就修改代码，而是准备主动审查组件结构，渲染模式，状态管理和数据获取等四个前端性能问题的可能区域，在定位到具体的瓶颈之前，不启动复杂任务流程，体现其工程纪律
- 生成清单，对症下药：经过分析之后，AI 生成了一串性能优化清单，将抽象的性能问题分解成五个具体可执行的底层技术操作
- 单线程规则锁定首个目标：面对五个优化项，AI 锁定第一个目标，优化组件的计算缓存
接着是reasoning内部推理分析
- 基于事实分析：这里强调了 Specific（具体的），说明 AI 的 TodoList 不是凭空捏造，而是建立在对代码库进行分析的基础之上
- 优化方案识别：分析完代码库之后，AI 将前面检视出的各种问题（比如重复渲染，大列表等），转换成多个独立的优化点，为后续的任务拆解提供基础
- 任务复杂度定性：AI 认识到，性能调优不是个简单的修改，而是一个涉及多模块，需要谨慎规划的复杂工程，因此触发了 TodoList 清单生成
- 跨组件追踪：注意这里的关键词 Methodically（有条不紊地，系统地）和 Across different components（跨组件），React 引用是由无数个组件嵌套而成，性能问题往往散落在各个角落，TodoList 在这里充当了一个全局的性能优化看板，确保 AI 在深入某个组件细节时，不会失去对整体架构优化的掌控
- 系统性闭环：通过 TodoList，可以确保所有的性能瓶颈都能被发现并解决，避免留下死角（比如解决了 A 页面卡顿，结果发现 B 页面又崩了），导致头痛医头脚痛医脚
OK，本篇先，到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Agent】【OpenCode】todowrite 工具提示词（示例）（四）
