定位并修复问题
修复问题的关键不是尽快改文件，而是建立一条从现象、根因到验证的证据链。
描述可观察现象
首次消息尽量包含：
- 用户做了什么；
- 预期结果和实际结果；
- 是否稳定复现；
- 相关日志、截图或错误；
- 哪些行为必须保持不变。
示例：
text
History 搜索在输入第二个关键词后偶尔保留上一次结果。
请先复现并定位权威状态来源，再修复。不要通过延长固定等待时间掩盖问题。
补一个能稳定覆盖请求乱序的测试，并运行聚焦验证。先复现
让 Agent 找到最小复现路径。复现失败时，不应凭猜测直接修改最可疑的文件。
好的复现会明确：
- 触发条件；
- 当前状态；
- 错误输出或错误 UI；
- 成功与失败之间的差异。
收窄根因
使用 Files 搜索状态所有者、请求入口和已有测试。要求 Agent 区分：
- 症状出现的位置；
- 真正写入错误状态的位置；
- 负责并发、取消或恢复的边界。
实施最小修复
修复应直接对应根因，并保持无关行为不变。对并发、超时、重连等问题，同时检查安全性和活性：非法状态要被拒绝，临时状态也要有明确的结束路径。
证明修复
至少运行：
- 新增或修改的回归测试；
- 受影响模块的聚焦检查；
- 风险需要时的生产形状场景。
要求 Agent 报告精确命令、结果和未覆盖内容。最后用 Files 或 Git 状态确认没有无关修改。