追问式计划拆解

解决的问题

当一个计划只停留在脑子里或会议纪要里时，最容易出问题的不是缺少热情，而是分支没展开、依赖没暴露、关键假设没人确认。例如“做一个内部报表工具”这句话，看起来清楚，实际会牵出权限模型、数据源、刷新频率、失败补偿、使用方、迁移节奏等一串决策。如果不逐项收敛，开发到中途才发现目标不一致，返工成本会很高。

grill-me-skill 要处理的就是这种计划模糊度：把用户或团队的初步想法放进一次持续访谈里，沿着设计树往下走，直到每个分支的依赖关系和最终选择都被明确。

工作方式

它的工作方式可以概括为：一次问一个，每问必走工具，答完立刻承接下一个分支。

• 每个问题都必须通过 AskUserQuestion 发起，而不是把问题直接写成普通文本。这样用户可以在弹窗里快速选择，也可以补充自定义输入。
• 一次只问一个。收到回答后，先用 1–2 句确认这个决策，再继续下一个问题。这样能避免信息同时涌入，也能让用户保持上下文。
• 每个问题尽量给出 2–4 个具体选项，选项应当描述真实可行的方向，而不是用“是 / 否”敷衍。只有在问题本身真的是二元选择时，简单选项才合理。
• 如果某个问题可以通过查看代码库、文件或现有文档回答，技能应优先自行探索，而不是把能查到的事情再问一遍。
• 访谈持续到设计树的每个分支都被解决为止。结束时输出一份简洁的决策汇总，把已经做出的选择和由此形成的共同理解记录下来。

适用边界与注意点

适合的场景是：需求边界不清、技术方案有多个分支、产品方向存在明显假设、需要先形成一致再动手。比如选型前的架构梳理、复杂流程的规则确认、任务拆分前的优先级盘点。

不适合用来处理已经非常确定、没有多个合理分支的问题，也不适合在用户明显需要立刻执行时继续追问。如果答案已经在代码或文件里，就不应该再问用户。还要注意控制节奏：虽然要求“relentlessly”，但不等于啰嗦；每个问题都应该推动一个尚未解决的分支，否则会变成重复确认。