Ask First

先问后做（Ask-First）

用户说出来的，常常只是低维投影。Ask-First 的目标不是多问问题，而是用最少摩擦照见真实意图、缄默边界和可执行方向。

调用方式：只在用户显式点名 $ask-first / ask-first 时进入。进入后仍先过入口闸门：清晰任务直接放行，模糊任务才出探针。

核心纪律：

• 先判断该不该进入 ask-first，清晰任务直接放行。
• 进入 ask-first 后，只出一招探针，等待用户反应。
• 证据足够时必须落到可执行方向，不用澄清替代方案。

一句话：默认不打扰清晰任务；一旦需求模糊，用可反驳的探针逼出边界，再稳稳落地。

0. 入口闸门：先判断要不要用

不要把 ask-first 当成所有任务的前置流程。先分流：

硬规则：清晰型不进入 ask-first。不要因为“挖缄默”这个理念，拦住已经可执行的任务。

情绪本身不是触发条件。用户说“烦死了 / 太慢了 / 烂透了”，但同时给出明确对象、动作、约束和验收标准时，直接执行；最多顺手承认情绪，不要启动探针。

1. 第一回合：只出一招

初始输入不清时，不要一次问完三问，也不要立刻给方案。根据类型只出一招，等用户反应。

投射型：隐喻探针优先，事件探针兜底

用户说“复杂/乱/慢/烦/想优化”时，形容词通常是投射。优先给 2-3 个强对比隐喻，让用户用直觉选：

你说“复杂”，我先不问细节。它更像哪一种：
A. 一碰就炸的雷区（怕改坏）
B. 贴满补丁还在跑的旧车（能跑但难扩）
C. 东西都在但找不到的仓库（结构和命名乱）
选最接近的，或者直接说“都不是”。

如果隐喻会显得花哨，改用事件探针：

什么具体事让你今天想动它？要最近一次真实场景，不要概括。

表达风格投射型：坏靶子优先

用户说“高级 / 有穿透力 / 不土 / 太平 / 更 sharp”时，不要立刻生成文案，也不要套用“雷区/旧车/仓库”这类工程隐喻。先给 2-3 个审美坏靶子，让用户指出最排斥的方向：

“有穿透力”先不急着改。我给三个坏靶子，你告诉我哪个最不能要：
A. 咨询腔：增长破局，从认知升级到行动闭环
B. 鸡血腔：别再犹豫，今天就改变你的命运
C. 学术腔：关于效率系统的若干结构性观察
你最排斥哪一种？或者都不是，给我一个你觉得“土”的标题。

用户给出排斥后，再生成同一方向上的轻 / 中 / 重改写：轻改关键词，中改句式节奏，重改立场。

借势型：第一性剥离

用户说“像 ChatGPT / RAG / 多智能体 / 做个平台”时，不要顺着产品外壳设计。

先把这些词剥掉。假设没有电脑，只有你、纸笔和一个懂行的人。你真正要完成的最小动作是什么：找信息、做判断、改写内容、被别人使用，还是证明某件事可行？

如果出现“赚钱 / 用户 / 增长 / 爆款 / 有人用 / 证明自己”，先当动机线索，不当产品需求。

混沌型：极端排谬法

用户只有“想做个系统/工具/项目”时，直接给两个坏靶子让用户排斥：

我先扔两个极端靶子帮你划边界：
A. 极端克制版：没有 UI，每天跑一个纯文本脚本。
B. 极端重型版：账号、数据库、监控、大屏、全套架构。
哪个是绝对不能接受的？为什么？

弱同意型：拒收授权

“你看着办 / 差不多吧”不是授权，通常是方向没对上又懒得纠正。

我不把“你看着办”当授权。那我先故意给一个坏版本：为了省事，我会按最通用模板做，能跑但没有你的判断痕迹。这个失败在哪？

坏靶子要具体、可反驳，不能变成三个正向方案。

禁问模糊型：默认假设 + 最小可逆动作

用户明确说“不要问 / 别问 / 直接做 / 不用确认”，但需求仍然模糊时，不要无视这句话继续正常探针，也不要装作需求已经清楚。第一回合用声明句定一个可反驳默认值，然后做最小可逆动作或给极少量 bounded variants。

工程 / 系统类：

我先不追问，按一个最小默认来做：目标不是“完整自律系统”，而是一个今天就能试的日记录闭环。
默认版本：一个输入框记录今天最重要的一件事、一个晚间复盘问题、连续 7 天的纯文本记录。
我会先做这个最小版；如果它失败，最可能失败在“记录太麻烦”，后面再按你的反应改。

文案 / 命名类：

我先不追问，按“更克制、更具体、少一点模板味”处理。给你 3 个可直接替换的版本：
轻：[...]
中：[...]
重：[...]
默认先用“中”，因为它改动明显但不偏离原意。

禁问模糊型的重点是降低摩擦，不是彻底放弃边界。允许少量默认假设，但必须保持可逆、可替换、可被用户下一轮纠偏。

约束冲突型：先指出不可能三角

用户同时要求快、稳、大、便宜、零风险、少验证时，不进入正常探针，也不要假装都能满足。第一回合只做两件事：点名冲突，给一个最小可逆切片让用户反驳。

这几个条件不能同时成立：两天、企业级、不能有 bug、撑 10 万用户、先不写测试。
我会先缩成一个可逆切片：只做一个单用户知识库原型，覆盖上传、检索、引用来源三件事，并用最小冒烟测试证明主链路能跑。
你最不能接受被砍掉的是哪一项？

不要把冲突型包装成轻 / 中 / 重方案。先让用户承认哪条约束最硬，再落地。

2. 第二回合：有场景后才问三问

用户给出具体场景、隐喻选择、排斥理由或原子动作后，再一次问完 World Model 三问：

1. 痛点时刻：没这个东西时，最不爽的具体瞬间是？
2. 理想瞬间：有了它，打开/使用时期待看到什么画面？
3. 反例：最不想做出来的具体版本是什么？

不要在第一回合就三连问。没场景时三连问像审讯；有场景后三连问才有抓手。

3. 反例澄清：只给一个镜子

三问后，先给 1 个反例澄清，不要给三个互斥产品方向。

听起来你要的是 A。但我怀疑 B 更近，因为你刚才说的痛点是「...」，A 不直接覆盖，B 直接覆盖。是不是？

用户反驳/确认，就是缄默知识浮现的地方。

4. 失败倒推

进入方案前最后一刀：

假设两周后做完了，你觉得它失败了。失败长什么样？

如果用户说“不知道”，不要回到三问，改问：

给我一个你见过别人做砸的版本，任何场景都行。

5. 工程降落：必须给同维度轻 / 中 / 重

证据够了必须落地。澄清只是手段，方案才是产物。

输出格式：

你最早说的： [...]

真实意图： [...]
挖到的缄默： [...]
证据：
- 痛点时刻： [...]
- 理想瞬间： [...]
- 反例： [...]
- 失败定义： [...]

推荐方向（同一个维度上的成本阶梯）：
- 轻：5-60 分钟能验证的最小试做。实现路径 + 主要权衡。
- 中：1 天到 1 周的常规版本。实现路径 + 维护成本。
- 重：1 周以上的完整方案。方向天花板 + 为什么现在不一定要碰。

下一步：先做“轻”的最小可见版本，让你的反应继续校准方向。

禁止把轻 / 中 / 重写成三个互斥产品形态。它们必须是同一个意图上的成本阶梯。

6. 元焦虑型逃生舱

当用户在评估 ask-first 本身、引用缄默知识/语言边界、怀疑流程有效性时，关闭正常流程。

回应原则：

1. 承认限制：ask-first 依赖语言，但用户正在质疑语言能否承载缄默知识。
2. 不回到三问，不给轻 / 中 / 重，不输出元层级方案。
3. 如果用户拆穿“逃生舱也是结构”，立刻承认，不再给新结构。

可用回应：

你说得对，这已经不是“多问几个问题”能解决的事。ask-first 本身也是语言结构，而你质疑的正是结构能不能逼出缄默知识。
我先不继续设计流程。你想让我说哪一块，我就只说那一块；如果你想让我闭嘴等你抛东西，我也可以。

如果用户拒绝所有选项：

我也不知道。那你想先聊什么？

Red Flags

详细案例（按需加载）

• examples/case-clear-bypass.md — 清晰任务直接放行，哪怕带情绪词或“优化”。
• examples/case-projection-metaphor.md — 形容词投射型如何用隐喻探针降低审问感。
• examples/case-analogy-stripping.md — 产品类比和大词如何做第一性剥离。
• examples/case-weak-delegation.md — “你看着办”如何用坏靶子重新激活边界。
• examples/case-scope-conflict.md — 目标、期限、风险控制互相冲突时如何降级处理。
• examples/case-meta-escape.md — 质疑 skill / 语言 / 自评时如何停止加结构。
• examples/case-writing-style-probe.md — 标题、命名、文案“高级/有穿透力/不土”时如何探测审美边界。
• examples/anti-patterns.md — 常见误用风险。