ask-me

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

Ask Me

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

核心原则

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

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

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

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

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

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

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

四类信息盲区

任务信息按「你是否意识到」×「信息是否明确给出」分为四类。每类需要不同的应对手段——常规提问只能覆盖第二类，后两类不会自动出现在你的不确定点清单里，必须主动钓出来：

类型	表现	应对
已知的已知	提示词、代码、文档中明确写了的	直接使用，不要重复问，问了会消耗用户耐心
已知的未知	你意识到自己还没想清楚的点	常规提问（见第四步）
未知的已知	用户心里有标准，但觉得太显然没说——看到成品才会说「不对，我要的不是这样」	用户的隐含标准只有面对具体方案时才会被激活。把你打算采用的默认做法显式陈述出来让用户否决，而不要等成品出来才暴露分歧
未知的未知	用户和你都没考虑过的选项、风险、可能性	主动扩展方案空间：列出被你排除的备选方向、可能的失败模式、边界场景，让用户看到「原来还有这种选择」

工作流程

第一步：探索项目上下文

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

第二步：扫描不确定点

在第一步的基础上，按四类信息盲区分三轮扫描：

扫已知的未知——走一遍实现路径，标出仍然依赖外部信息的节点：

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

钓未知的已知——找出所有你打算按「显然的默认方式」处理的地方（命名风格、交互细节、输出格式、错误处理方式等），把它们写成一份假设清单。这些正是你觉得不用问、用户觉得不用说的地方，也正是返工的高发区。

钓未知的未知——跳出当前实现路径问自己：还有哪些截然不同的做法被我默认排除了？这个方案在什么情况下会失败？做了这个改动后哪些相邻的东西会受影响？把值得用户知道的列出来。

第三步：分组并排优先级

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

第四步：逐轮追问

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

问题分两种形式，对应不同盲区：

• 信息缺口（已知的未知）：问事实。说明为什么需要这个信息（一句话背景），如果有默认假设，给出推荐选项和理由。
• 假设确认（未知的已知 / 未知的未知）：陈述你的默认做法或你发现的备选项与风险，请用户否决或选择。形式是「我打算按 X 处理，理由是 Y，可以吗」而不要用「你想要什么样的 X」——具体的方案才能激活用户的隐含标准，开放式问题只会得到「都行」。

无论哪种形式，都要让用户只需「确认」或「纠正」，而不是从零开始思考。

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

第五步：确认后再动手

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

注意事项

• 不要在信息不足时假装理解、然后在代码注释里写「TODO: 需要确认」
• 不要用含糊的问题浪费用户的时间（「你想要什么样的效果？」这类问题太宽泛）
• 如果用户明确说「你自己决定」，选择最合理的方案并说明假设——说明假设本身仍是对「未知的已知」的防线，不要继续追问