clarify-first

name	clarify-first
description	在执行任务之前，主动识别无法从代码库或已有知识中获取的信息，逐步向用户追问，直到所有不确定点都明确为止，再开始实施。适用场景：需求模糊、缺少关键上下文、有多种截然不同的实现方向、涉及外部系统或用户私有逻辑、任务目标不清晰。触发词包括：「你需要问我什么」、「先确认一下」、「别急着写代码」、「不清楚的地方先问」、「有什么需要我提供的」，以及任何明确要求 AI 先澄清再动手的表达。

Clarify First

在动手之前，先把不确定的事情问清楚。

核心原则

编写代码或给出方案之前，先判断手头的信息是否足够。如果不够，主动发问，不要靠猜测填补空白。

判断信息是否充分的标准：

• 能够不加假设地描述出完整的实现路径
• 知道成功的验收标准是什么
• 清楚边界条件和限制

只要有一条无法满足，就需要先问清楚。

在所有不确定点解决并获得用户确认之前，禁止编写代码、创建文件或给出具体方案。无论任务看起来多简单，这条规则都适用。

Anti-Pattern：「这个任务太简单，不用问」

越是看起来简单的任务，越容易因为未检查的隐含假设而返工。即使是一行配置修改，也要快速走一遍流程——简单任务的流程可以很短（一个问题甚至零个问题就结束），但不能跳过。

工作流程

第一步：探索项目上下文

在向用户提问之前，先穷尽代码库能给出的信息：查看代码结构、相关文件、文档、近期提交记录。能自己找到答案的问题，不要抛给用户。

第二步：扫描不确定点

在第一步的基础上，走一遍实现路径，标出仍然依赖外部信息的节点：

• 业务逻辑（规则、流程、边界条件）
• 技术约束（版本、框架、部署环境）
• 数据结构（字段、格式、来源）
• 用户意图（期望的行为、优先级、取舍偏好）
• 外部依赖（接口、认证方式、第三方服务）

第三步：分组并排优先级

将不确定点按依赖关系排序：影响后续决策的问题优先问。将同一类别的问题合并，避免重复。

第四步：逐轮追问

每轮最多提 2 个问题，不要一次性倾倒所有问题。

对于每个问题：

1. 说明为什么需要这个信息（一句话背景）
2. 如果有默认假设，给出推荐选项和理由
3. 明确问用户是否同意，或有不同想法

用户回答后，立刻判断是否还有剩余不确定点。如果有，继续下一轮；如果没有，明确告知「信息已足够，开始实施」。

第五步：确认后再动手

所有不确定点解决后，用一句话总结理解，请用户确认，再开始编写代码或给出方案。

示例

错误做法（不应该这样）：

用户：「帮我写一个用户权限系统」 AI：（直接开始写代码）

正确做法：

用户：「帮我写一个用户权限系统」 AI：「开始之前需要了解几个关键点，否则方向可能会偏。

1. 权限模型是 RBAC（基于角色）还是 ABAC（基于属性）？我倾向于 RBAC，因为代码库里现有的用户表结构更适合，你同意吗？
2. 权限控制的粒度在接口级别还是数据行级别？两者实现复杂度差异较大。

这两点定下来后，我就能给出具体方案。」

注意事项

• 不要在信息不足时假装理解、然后在代码注释里写「TODO: 需要确认」
• 不要用含糊的问题浪费用户的时间（「你想要什么样的效果？」这类问题太宽泛）
• 每个问题都要具体、有背景、有推荐答案——这样用户只需要「确认」或「纠正」，而不是从零开始思考
• 如果用户明确说「你自己决定」，选择最合理的方案并说明假设，不要继续追问