find-improvements

查找改进

范围

除非选择了其他仓库或更窄的关注范围，否则分析当前仓库。开始时不要询问参数；如果仓库不可用或存在歧义，请如实报告，不要擅自替换。

提出两个 Bug 和两个重构方案，供用户决定。仅进行只读操作： 不要编辑文件、安装依赖、切换检出版本、实施修复、创建提交/PR/工单或更改计划。

依赖项

无技能依赖

工作流

分析

• 记录开始时间、仓库、分支和 HEAD SHA。阅读仓库说明、相关架构和测试。保留本地更改；区分本地更改与已提交代码。
• 从近期提交/差异入手；如果之前报告的 SHA 是 HEAD 的祖先，则优先检查自该 SHA 以来的更改。否则说明审查的近期范围。即使没有新提交，也要继续检查相关代码。
• 恰好启动两个子 Agent：一个最多查找两个 Bug，另一个最多查找两个重构。向两者提供范围、基线、只读限制、候选标准和分析截止时间。不要为每个发现分别启动 Agent，也不要让这些 Agent 进一步委派任务。如果无法委派，应报告这一限制，不要悄悄改为独自分析。
• 主动搜索并验证至少十分钟；并行工作不缩短这一要求。即使很早就找到四个候选，也要继续审视；切勿用等待来凑时间。追踪调用方、约定、状态和数据流；优先检查回归问题，再扩大范围。只有在有证据时，才将发现归因于特定提交。
• 检查可访问的开放 PR、之前的报告和用户决定，以排查重复项、进行中工作和被否决的想法；说明无法获取的来源。验证子 Agent 提供的证据，拒绝薄弱或重复的发现，并按价值与工作量之比对各类别进行排序。如果遇到阻碍，报告实际耗时和原因。

候选项

**Bug：**具体、可触发的行为错误，每项预计需要修改 30–60 行实现代码（不含测试）。根据代码和约定推导触发条件、预期行为和后果。排除假设性风险、风格偏好和缺乏依据的产品假设。必要时使用现有测试或非变更式复现；区分实际执行验证与代码分析。

**重构：**在大约 200 行修改实现代码以内（不含测试）且保持行为不变的改进。说明简化、去重或结构调整的方式及具体维护收益。排除功能、外观调整和推测性抽象。

只有获得用户对相应类别的授权后，才能提高限制。如果证据或范围不足以支持两个提案，就减少提案数量并如实估算。不要编造发现。

结果

在此回复仓库、分支、HEAD SHA、审查范围、耗时以及覆盖范围/验证限制。保留 SHA，供后续运行使用，不要创建状态文件。

使用 Bugs（B1/B2）和 Refactors（R1/R2）。每个提案都包括：

• 触发条件和后果，或拟议的重构及其收益。
• 文件链接及行号、基于代码的理由、（如已确认）相关提交、验证方式，以及实用的复现或回归检查。
• 预计实现代码行数（不含测试）以及需要保持的行为。

说明不足之处。最后列出供用户选择的提案；不要实施，也不要逐项征求批准。