atelier-grill-me

盘问我

通过采访用户来对计划或设计进行压力测试，直到双方真正达成共识：决策树中每个重要分支都已解决，且这些决策之间的依赖关系也已按顺序理清。目的不是为了盘问而盘问，而是趁现在、在对话成本可控时，提前揭示假设、边缘情况和不同选择，而不是等到开发过程中或投入生产后才发现。

这是对“编码前先思考”的按需、彻底补充。那一习惯会在必要时请求澄清；这项技能则会在写下一行代码之前，彻底走完整棵决策树。

交互与 Agent 规范：遵循主 atelier 技能的 Interaction 部分（简洁、先回答、不使用破折号、每个问题先给出建议，访谈结束时说明后续步骤），包括其中关于提交和测试的两道关卡（规则 24-25）；单轮限制不适用于此处，多轮提问正是这项技能允许的目的。

何时使用

• 用户要求你盘问，或对计划或设计进行压力测试。
• 某项决策影响重大，且错误选择难以挽回：架构、数据模型、公共 API 形态、迁移、依赖选择、安全边界。
• 计划涉及新产品或新功能：在盘问如何构建之前，先盘问是否应该构建（参见 atelier references/product.md § Validate before you build）。除了团队内部的看法，还有哪些问题存在的证据？在构建之前，验证需求最便宜的方法是什么（落地页、人工代办服务）？哪些带日期的继续/停止标准能让人说出“不”？发布后，由什么采用率门槛决定继续还是放弃？能在访谈阶段就被放弃的想法，是这项技能最理想的结果。
• 计划含糊、范围宽泛，或隐藏了许多未明说的分支。

根据利害程度调整强度。对“重命名这个变量”进行五轮盘问只会带来噪声：对于琐碎或已明确说明的任务，跳过盘问。

如何进行访谈

1. 中立地说明问题。 用一两句话重述目标，不要倾向于某个偏好的答案；深入探讨前先确认你理解无误。
2. 先探索，再提问。 凡是代码库能回答的问题，都自己去查：阅读文件、配置和现有模式。不要问用户 grep 就能告诉你的内容。带着发现结果来，而不是把作业丢给用户。
3. 一次只问一个问题。 提出一个问题，等待回答，再问下一个。一次列出十个问题会让人应接不暇，得到的回答也会很浅。
4. 先给出你建议的答案。 每个问题都用一句话说明你的选择及理由，让用户可以回答“是”，也可以纠正你。没有建议的问题只是在把工作推回给用户。
5. 按深度优先顺序遍历决策树，依次理清依赖关系。 一项决策会限制其他决策时，先确定它，再沿着该分支继续；不要在当前分支尚未理清时开启新分支。相关时指出依赖关系（“如果保留静态导出，就不必再讨论逐请求缓存问题”）。
6. 跟踪进度。 持续记录已解决的决策和仍待回答的问题，避免长时间讨论时双方丢失脉络。
7. 在双方达成共识时停止。 每个重要分支都已解决，且你无需猜测就能开始实施时，访谈就结束了。明确说明这一点，不要在访谈中途戛然而止。

输出

当访谈收敛时，写一份简短的决策记录：目标、每项决策及其一句话理由，以及第一个具体的后续步骤。保持精简：它就是实现将遵循的规范。对于有值得记录的被否决方案和回退路径的决策，应按仓库提交的 ADR 格式编写（docs/adr/NNNN-title.md，atelier references/governance.md § 决策记录）；对于是否构建的问题，记录应是注明日期并列出明确标准的 go/no-go 检查清单（atelier references/product.md）。

引导讨论时，应朝着能经受住提问的最简单设计，而不是最复杂的设计：你建议的每个答案都应遵循 YAGNI 原则和“最省事的代码就是从未写下的代码”。

如果仓库使用 .claude/LESSONS.md 日志，应将可长期沿用的选择提议为 [decision] 条目（获批后追加），让下一个会话直接继承这些选择，而不是重新争论整个代码树。