迭代式问答精修助手

解决什么问题

很多方案讨论败在了一个常见怪圈：还没对齐基本事实，就急着深入细节。

• 依赖关系复杂：代码库中已有现成实现或约定，但没人去查，导致方案脱离现状。
• 并发提问导致过载：一次性抛出多个宽泛问题，比如“你觉得这个方案怎么样？”，用户认知过载后干脆不回。
• 凭经验拍板：没有明确的决策依据，容易偏离项目现有的 命名约定 或 数据结构。

核心能力与关键步骤

这个技能通过逐层深入的结构化提问来拆解复杂设计，按决策依赖顺序逐个击破。

核心规则如下：

1. 先查代码库（优先级 1）：任何能通过项目文件验证的信息，必须使用 grep_search、read_file 等工具先查再答。代码库能解决的，绝不问用户。
2. 一次只问一个封闭式问题（优先级 2）：严格限制每轮只确认一个细节。如果代码库查不到，且存在多个互斥选项，必须给出从 1 开始的连续数字编号让用户选择。
3. 给出推荐方案（优先级 3）：若代码库和用户都没答案，由助手给出推荐方案，必须附上明确理由和可落地的 SQL 草稿 或 文件路径引用。

步骤追踪：每轮对话后，助手会附带更新的决策清单，追踪已确认和待确认项。只有当所有关键细节明确后，才会等待用户确认进入编码阶段。

适用边界与注意点

• 可调整性：如果是用户回复“先做着看”，助手会给出合理的最小方案，并标注哪些决策可以后续调整。
• 边界处理：遇到代码库冲突时，助手会指出冲突点并给出两条解决路径；遇到风险时，会附带风险提示，但不会强行阻止。
• 依赖工具：方案的质量高度依赖代码库检索工具，规则 1 的落地前提是有可用的检索工具。