批量拷问

设计决策散落在对话里

工程师在做方案设计时，常陷入这样的困境：需求讨论到一半，发现某个基础决策还没定论，但后续讨论早已基于某个假设展开。团队里没人专门负责“把决策串起来”，于是文档越改越乱，关键假设被沉默地埋进代码里。

用设计树和轮次收敛

批量拷问把这个过程结构化。它维护一棵设计树——每个决策是一个节点，节点之间用依赖关系连接。每轮只问前沿问题：那些前提已定、现在就该问的决策。每个问题都附推荐答案，减少用户的思考负担。

工作流很直接：

• 第一轮列出所有没有前置依赖的问题
• 用户作答后，已定决策把前沿向外推，解锁依赖它们的问题
• 某个问题的答案是另一问题的前置，那它自动排到后续轮次
• 当所有决策的支路都走过，设计树里没有沉默假设时，会话结束

事实归我查，决策归你定

这里有两个边界要说清楚：

• 找事实是技能的事：如果某个前沿问题需要文件系统或工具来确认，技能会派子agent去查，而不是问你“文件里是不是这样写的”。
• 决策是你的事：每一条决策都会问到，并且等你给出明确答案。技能不会自作主张替你拍板，也不会把决策藏在推荐答案里蒙混过关。

适用场景：你需要就某个设计或计划被系统拷问，快速收敛到共识。
不适用场景：这个技能只访谈不定实现，如果你需要的是直接生成代码或文档，它不是合适的选择。

输出是一个DesignTree工件，包含节点列表、依赖关系和轮次记录，可以交给to-spec合成规格，或继续用batch-grill-me续轮。