用途：把描述不清的请求先转成（1）一段问题陈述、（2）有边界的规格、（3）分阶段实施计划，每一步都展示给用户确认后再继续，避免从模糊提示直接跳到写代码。
适用场景：请求是目标而非规格（如“做个仪表盘”“加认证”）；缺少或隐含需求、约束、成功标准；用户在探索某件事是否值得做。不适用于已明确规格的任务、有清晰复现步骤的缺陷修复或机械性改动，这些应直接实施。
主要流程：
- 先复述问题：用一段话写清谁有什么问题、为何现在做、什么算“解决”，展示出来；写不出说明理解不足，这即是第一个问题。
- 只问会改变决策的问题：批量提3至6个若答案不同会改变设计的问题，跳过有安全默认值的项，直接说明默认值继续。重点包括范围边界（明确排除什么）、硬约束（技术栈、期限、数据、合规）、成功标准、以及一旦错误最浪费工作的假设。
- 写规格：包含问题、目标/非目标、约束、方法（1至3句）、待解决问题，控制在一屏内；在规划前先就目标/非目标获得明确“是”。
- 写分阶段计划：每阶段交付可验证成果，如“阶段1：证明方法的最小端到端切片——用X验证”，并列出具体交付物、涉及文件/区域、验证方式，标注依赖与风险最高的阶段，风险前置。
- 交接：输出规格与计划作为最终产物，推荐第一阶段后停止，实施由用户另行触发。
质量要求：问题陈述一段话且指向真实用户；非目标明确；每阶段可独立验证；不问有明显默认值的问题；规格确认前不写任何代码。
反模式：4个问题能定设计却问15个；阶段1只写“搭建项目”而无验证结果；把用户提示原样复述当规格；在核心切入点达成一致前先设计镀金版本。
限制：资料未提供具体安装命令、平台支持、收费或价格信息。