| name | clarify-first |
| description | 在执行任务之前，主动识别无法从代码库或已有知识中获取的信息，逐步向用户追问，直到所有不确定点都明确为止，再开始实施。适用场景：需求模糊、缺少关键上下文、有多种截然不同的实现方向、涉及外部系统或用户私有逻辑、任务目标不清晰。触发词包括：「你需要问我什么」、「先确认一下」、「别急着写代码」、「不清楚的地方先问」、「有什么需要我提供的」，以及任何明确要求 AI 先澄清再动手的表达。 |
Clarify First
在动手之前，先把不确定的事情问清楚。
核心原则
编写代码或给出方案之前，先判断手头的信息是否足够。如果不够，主动发问，不要靠猜测填补空白。
判断信息是否充分的标准：
- 能够不加假设地描述出完整的实现路径
- 知道成功的验收标准是什么
- 清楚边界条件和限制
只要有一条无法满足，就需要先问清楚。
在所有不确定点解决并获得用户确认之前，禁止编写代码、创建文件或给出具体方案。无论任务看起来多简单，这条规则都适用。
Anti-Pattern：「这个任务太简单，不用问」
越是看起来简单的任务，越容易因为未检查的隐含假设而返工。即使是一行配置修改，也要快速走一遍流程——简单任务的流程可以很短（一个问题甚至零个问题就结束），但不能跳过。
工作流程
第一步：探索项目上下文
在向用户提问之前，先穷尽代码库能给出的信息：查看代码结构、相关文件、文档、近期提交记录。能自己找到答案的问题，不要抛给用户。
第二步：扫描不确定点
在第一步的基础上，走一遍实现路径，标出仍然依赖外部信息的节点：
- 业务逻辑（规则、流程、边界条件）
- 技术约束（版本、框架、部署环境）
- 数据结构（字段、格式、来源）
- 用户意图（期望的行为、优先级、取舍偏好）
- 外部依赖（接口、认证方式、第三方服务）
第三步：分组并排优先级
将不确定点按依赖关系排序：影响后续决策的问题优先问。将同一类别的问题合并，避免重复。
第四步：逐轮追问
每轮最多提 2 个问题，不要一次性倾倒所有问题。
对于每个问题：
- 说明为什么需要这个信息（一句话背景）
- 如果有默认假设，给出推荐选项和理由
- 明确问用户是否同意，或有不同想法
用户回答后，立刻判断是否还有剩余不确定点。如果有，继续下一轮；如果没有，明确告知「信息已足够，开始实施」。
第五步：确认后再动手
所有不确定点解决后，用一句话总结理解，请用户确认，再开始编写代码或给出方案。
示例
错误做法（不应该这样）：
用户：「帮我写一个用户权限系统」
AI：（直接开始写代码）
正确做法：
用户：「帮我写一个用户权限系统」
AI：「开始之前需要了解几个关键点，否则方向可能会偏。
- 权限模型是 RBAC（基于角色）还是 ABAC（基于属性）？我倾向于 RBAC，因为代码库里现有的用户表结构更适合，你同意吗？
- 权限控制的粒度在接口级别还是数据行级别？两者实现复杂度差异较大。
这两点定下来后，我就能给出具体方案。」
注意事项
- 不要在信息不足时假装理解、然后在代码注释里写「TODO: 需要确认」
- 不要用含糊的问题浪费用户的时间（「你想要什么样的效果？」这类问题太宽泛）
- 每个问题都要具体、有背景、有推荐答案——这样用户只需要「确认」或「纠正」，而不是从零开始思考
- 如果用户明确说「你自己决定」，选择最合理的方案并说明假设，不要继续追问
