最近钉钉内部做了一次 AI 能力摸底。结果出乎很多人意料——那些平时代码写得最溜、技术栈最广的工程师，在解决客户问题的 AI 协同效率上反而不如几个产品同学和前线服务客户的同学。
我观察了一个细节：区分高下最明显的指标，不是 prompt 写得有多长多花哨，而是他们向 AI 提出的问题本身的质量。
技术强的同学倾向于问：“帮我写一个 Python 脚本，读取 CSV 文件，按日期分组，输出统计报表。"——这是执行指令，不是提问。
而得分最高的一个产品同学问的是：“我现在有一个用户行为日志，想找出哪些功能改版后使用率下降了。你觉得我应该从哪些维度分析？有什么常见的分析陷阱？"——这是真正的提问，它打开了一个探索空间。
这个观察让我意识到一个反直觉的判断：评估一个人是否是 AI 人才，最可靠的指标不是他会用多少 AI 工具，而是他提问的能力。
一、先搞懂两个系统：你大脑里的"兔子"和"乌龟”
在讨论提问能力之前，我们需要先理解一个认知科学的基础框架。诺贝尔经济学奖得主丹尼尔·卡尼曼在《思考，快与慢》中提出，人类大脑有两套思考系统：
┌─────────────────────────────────────────────────┐
│ 你大脑里住着两只动物 │
├─────────────────────────────────────────────────┤
│ │
│ 🐰 兔子（System 1 — 快思考） │
│ ───────────────────────── │
│ • 自动、直觉、毫不费力 │
│ • 瞬间反应，并行处理 │
│ • 例子：看到 2+2 立刻知道是 4 │
│ 识别熟人的脸 │
│ 急刹车避险 │
│ │
│ 🐢 乌龟（System 2 — 慢思考） │
│ ───────────────────────── │
│ • 有意识、理性、需要集中注意力 │
│ • 缓慢、逐步推理、串行处理 │
│ • 例子：计算 17 × 24 │
│ 填写税务表格 │
│ 在嘈杂房间里专注听某人说话 │
│ │
└─────────────────────────────────────────────────┘
来做个经典测试：
球拍 + 球 = $1.10，球拍比球贵 $1.00，球多少钱？
你的兔子（System 1）会脱口而出 $0.10。
但这是错的。让你的乌龟（System 2）介入一下：
设球 = x，球拍 = x + 1.00
x + (x + 1.00) = 1.10
2x = 0.10 → x = $0.05
关键点：我们日常 95% 的行为由兔子主导，乌龟通常只是在"打补丁"或"背书”。大脑天生爱偷懒——因为乌龟模式太耗能了。
1.1 LLM 也有"兔子"和"乌龟"
有趣的是，大语言模型恰好完美映射了这个框架。
LLM 的"兔子"（基础模式）：
LLM 的底层架构 Transformer 本质上是一个超级联想引擎。它基于训练数据中的统计规律，预测下一个最可能出现的词。
输入: "天空是"
LLM (兔子模式): "蓝色的" ← 基于概率，瞬间输出
输入: "农夫有10个苹果，给邻居3个，又买5个，现在有几个？"
LLM (兔子模式): "12个" ← 可能对可能错，纯直觉
这和人类的 System 1 几乎一模一样：快速、直觉、基于模式匹配、容易出错。LLM 的"幻觉"问题，本质上就是兔子跑太快、乌龟没跟上。
LLM 的"乌龟"（推理模式）：
研究界发现，只需一句简单的提示词，就能唤醒 LLM 的"乌龟"：
输入: "农夫有10个苹果，给邻居3个，又买5个，现在有几个？
请一步一步思考。"
LLM (乌龟模式):
"让我逐步思考：
初始有 10 个苹果
给邻居 3 个 → 10 - 3 = 7 个
又买了 5 个 → 7 + 5 = 12 个
答案：12 个"
这句 “请一步一步思考”（Let’s think step by step）就是 AI 领域著名的 Chain-of-Thought（CoT） 技术。它让 LLM 从 System 1 的直觉模式切换到 System 2 的推理模式，在数学、逻辑、复杂规划等任务上准确率大幅提升。
1.2 两种模式的对比
| 维度 | LLM 兔子（System 1） | LLM 乌龟（System 2） |
|---|---|---|
| 触发方式 | 默认模式 | 需要 prompt 或专用模型引导 |
| 速度 | 毫秒~秒级 | 秒~分钟级 |
| 算力消耗 | 低 | 高（可能 10-100 倍） |
| 适用场景 | 日常问答、创意脑暴、翻译 | 数学推理、代码生成、复杂决策 |
| 典型代表 | GPT-4o、Claude 标准模式 | OpenAI o1/o3、DeepSeek-R1 |
| 弱点 | 幻觉、逻辑断裂 | 过度思考、简单问题反而答错 |
1.3 核心洞察：提问 = 系统路由
到这里你应该明白了：你向 AI 提出的问题，本质上是在决定调用它的兔子还是乌龟。
┌─────────────────────────────────────────────────┐
│ 提问 = 人机协同的"方向盘" │
├─────────────────────────────────────────────────┤
│ │
│ 你的问题 ──→ 决定 ──→ AI 激活哪个系统 │
│ 决定 ──→ 协作模式 │
│ 决定 ──→ 输出质量的上限 │
│ │
│ 好问题 = 精确的系统路由 + 高质量上下文注入 │
│ 烂问题 = 模糊的系统路由 + 噪声上下文 │
│ │
└─────────────────────────────────────────────────┘
而更进一步：你提出的问题质量，直接暴露了你自己的兔子还是乌龟在主导这次对话。
如果你的问题是 System 1 级别的（模糊、直觉、没想清楚），AI 大概率也用 System 1 回复你——两个兔子互相打太极，产出不可能好。
如果你的问题是 System 2 级别的（有背景、有约束、有目标），你实际上是在告诉 AI：“我的乌龟已经上线了，现在请你的乌龟也出来工作。”
这就是为什么提问能力是 AI 人才的试金石——它同时暴露了你的思考深度和你驾驭 AI 系统的能力。
二、为什么提问能力是 AI 人才的"试金石"？
2.1 好问题暴露了你的 System 2 是否在运行
当你向 AI 提问时，你的大脑也在同时运作。你提出的问题质量，直接反映了你自己的 System 2 是否参与了问题定义。
来看一个对比：
| 维度 | 低质量问题 | 高质量问题 |
|---|---|---|
| System 参与度 | 人 S1（直觉反应） | 人 S2（深度思考后提问） |
| 问题结构 | 单句、模糊、缺少约束 | 有背景、有约束、有目标 |
| AI 激活模式 | 不确定（AI 自己猜） | 明确指定（你控制 AI 的系统） |
| 输出质量 | 随机、泛泛而谈 | 精准、可执行 |
| 可迭代性 | 答非所问 → 放弃 | 有基线 → 追问 → 收敛 |
低质量问题的本质是：你的 System 1 直接把模糊的直觉丢给了 AI，连你自己都没想清楚要什么。 AI 收到后也只能用 System 1 给你一个模糊的回答。两个 System 1 互相打太极，产出不可能好。
高质量问题的本质是：你的 System 2 先做了功课——定义了问题边界、约束条件、成功标准——然后精准路由到 AI 的合适系统。 这就是③精密操控或④深度协同推理的起点。
2.2 提问能力 = 问题定义能力
很多人以为"会提问"就是"会写 prompt"。这是一个严重的误解。
误区: 提问能力 = Prompt Engineering 技巧
↓
本质: 提问能力 = 问题定义能力 × 系统路由能力
┌────────────────────────────────────────────┐
│ 提问能力的三个层次 │
├────────────────────────────────────────────┤
│ │
│ L1: 执行层（"帮我做 X"） │
│ → AI 是工具，你是操作员 │
│ → 天花板低，可替代性强 │
│ │
│ L2: 探索层（"X 有哪些方案？各有什么优劣？"） │
│ → AI 是顾问，你是决策者 │
│ → 中等天花板，需要领域知识判断 │
│ │
│ L3: 定义层（"我面临 Y 约束下的 X 问题， │
│ 成功标准是 Z，你认为我可能忽略了什么？"）│
│ → AI 是协作者，你是架构师 │
│ → 天花板高，不可替代 │
│ │
└────────────────────────────────────────────┘
L1 的人把 AI 当搜索引擎或代码生成器用。他们的提问是命令式的，AI 的输出是确定性的但也是平庸的。
L2 的人开始把 AI 当智库用。他们会问对比性问题、探索性问题，但往往缺少约束条件，导致 AI 给出"正确的废话"。
L3 的人把 AI 当协作者用。他们的问题包含：问题定义 + 约束条件 + 成功标准 + 盲区探测。这种提问方式要求提问者自己先有深度思考——你不可能提出 L3 级别的问题，如果你自己没在 System 2 模式下认真想过这个问题。
2.3 提问能力是"可观测"的
为什么我说提问能力是最可靠的判断指标？因为它有一个独特属性：它是可观测的，且难以伪装。
其他"AI 能力"指标的缺陷:
┌─────────────────────────────────────────┐
│ 指标 │ 问题 │
├───────────────────┼─────────────────────┤
│ 会用多少 AI 工具 │ 工具多≠用得好 │
│ Prompt 模板收藏量 │ 收藏≠理解≠会用 │
│ AI 生成内容数量 │ 数量≠质量 │
│ 技术栈广度 │ 和 AI 协同无关 │
│ 论文阅读量 │ 理论≠实践 │
└───────────────────┴─────────────────────┘
提问能力的优势:
┌─────────────────────────────────────────┐
│ ✅ 直接暴露思维深度（System 2 参与度） │
│ ✅ 反映领域知识水平（能否定义约束条件） │
│ ✅ 体现元认知能力（是否知道自己不知道什么）│
│ ✅ 实时可观测（一次对话就能判断） │
│ ✅ 难以伪装（L3 问题需要真实思考支撑） │
└─────────────────────────────────────────┘
你在面试中可以让候选人现场用 AI 解决一个开放性问题。不需要看他用了什么模型、写了多长的 prompt——只看他问了什么、怎么追问、怎么验证 AI 的回答。十分钟就能判断这个人的 AI 协同水平在哪个层级。
三、“提问能力评估模型”（QAM）
基于双系统框架，我提出一个提问能力评估模型（Questioning Ability Model, QAM），用于系统化地评估一个人的 AI 协同水平。
3.1 四个评估维度
┌──────────────────────────────────────────────────┐
│ QAM: Questioning Ability Model │
├──────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 问题定义 │→│ 系统路由 │→│ 迭代追问 │ │
│ │ (Depth) │ │ (Routing)│ │(Iteration)│ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ↑ ↓ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 元认知 │←────────────│ 验证意识 │ │
│ │(Meta) │ │(Verify) │ │
│ └──────────┘ └──────────┘ │
│ │
└──────────────────────────────────────────────────┘
| 维度 | 评估什么 | 高表现 | 低表现 |
|---|---|---|---|
| 问题定义深度 | 能否把模糊需求转化为结构化问题 | 包含背景、约束、目标、成功标准 | 一句话模糊描述 |
| 系统路由精度 | 能否判断并引导 AI 使用合适的推理模式 | 明确要求"逐步推理"/“给出多种方案”/“指出我的盲点” | 不指定，让 AI 自由发挥 |
| 迭代追问能力 | 能否基于 AI 回答进行有方向的追问 | 追问有递进、有交叉验证、有收敛 | 要么接受要么放弃，没有追问策略 |
| 验证意识 | 是否主动验证 AI 输出的正确性 | 要求来源、交叉验证、用已知事实测试 | 全盘接受或全盘否定 |
3.2 一个真实的评估案例
来看一个实际的对话序列，看看 QAM 如何工作：
场景：评估一个工程师用 AI 设计技术方案的能力。
轮次 1（问题定义）:
候选人: "我们有个微服务，QPS 从 1000 涨到 50000 了，
数据库成了瓶颈。有什么优化方案？"
评估: 问题定义 L2 — 有背景（QPS 增长）和目标（优化），
但缺少约束（预算？停机窗口？团队规模？）
轮次 2（系统路由）:
AI: "可以考虑分库分表、缓存、读写分离..."
候选人: "请从三个维度对比这些方案：实施复杂度、
对现有代码的侵入性、以及在我们这种读多写少
场景下的收益。用表格输出。"
评估: 系统路由 L3 — 明确要求对比维度、指定输出格式，
引导 AI 进入 System 2 深度分析
轮次 3（迭代追问）:
AI: [输出对比表格]
候选人: "你推荐的分库分表方案，sharding key 选用户 ID
的话，大用户倾斜问题怎么解决？"
评估: 迭代追问 L3 — 基于 AI 推荐深入追问具体技术风险
轮次 4（验证意识）:
AI: [给出解决方案]
候选人: "你说的方案在 MySQL 8.0 上实际验证过吗？
有没有已知的坑？给我找两个真实案例。"
评估: 验证意识 L2 — 有验证意识，但依赖 AI 自我验证
（更好的做法是用自己的知识或独立搜索交叉验证）
综合评分: 问题定义 L2 | 系统路由 L3 | 迭代追问 L3 | 验证意识 L2
总体水平: 中高级 AI 协同能力
这个候选人展现了很强的 System 2 驱动能力——他的追问有方向、有深度、有技术判断力。但他也有改进空间：问题定义时缺少约束条件，验证环节过度依赖 AI 自我报告。
3.3 QAM 评分矩阵
┌─────────────────────────────────────────────────────┐
│ QAM 评分矩阵（1-5 分） │
├────────┬──────────┬──────────┬──────────┬──────────┤
│ 分数 │ 问题定义 │ 系统路由 │ 迭代追问 │ 验证意识 │
├────────┼──────────┼──────────┼──────────┼──────────┤
│ 1 │ 一句话 │ 不指定 │ 不追问 │ 全盘接受 │
│ 2 │ 有背景 │ 模糊指定 │ 随机追问 │ 偶尔质疑 │
│ 3 │ 有约束 │ 明确路由 │ 有方向 │ 要求来源 │
│ 4 │ 有成功标准│ 精准路由 │ 递进追问 │ 交叉验证 │
│ 5 │ 含盲区探测│ 动态切换 │ 收敛到解 │ 独立验证 │
└────────┴──────────┴──────────┴──────────┴──────────┘
总分 4-8 分：初级（AI 当工具用） 总分 9-14 分：中级（AI 当顾问用） 总分 15-20 分：高级（AI 当协作者用）
四、总结
回到开头的那个问题：为什么技术最强的工程师反而在 AI 协同上不如产品同学？
答案现在很清楚了——技术能力解决的是"怎么做"（how），但 AI 时代更稀缺的是"问什么"（what to ask）。
产品同学的优势不在于他们更懂 AI，而在于他们更擅长定义问题。他们习惯性地问"用户真正需要什么？““有哪些可能的盲区？““这个方案的假设是什么？"——这些 System 2 级别的提问，天然就能激活 AI 的深度推理能力。
而很多工程师习惯了直接写代码解决问题，他们的 System 2 用在实现上，而不是问题定义上。当 AI 接管了实现层，真正的竞争力上移到了"提出好问题"这一层。
这里有一个更深层的洞察：提出一个好问题，意味着你已经有了这个问题一半的答案。
为什么？因为一个好问题需要你已经做过功课——你理解了问题的背景、界定了约束条件、排除了显而易见的错误方向、甚至隐约看到了答案的轮廓。你能问出 L3 级别的问题，说明你的 System 2 已经跑完了前半程，AI 只需要帮你跑完后半程。
反过来，如果你只能问出 L1 级别的问题，说明你连问题的全貌都没看清，AI 给你的答案也只能是泛泛而谈。好问题本身就是答案的一半。
好消息是：提问能力是可以训练的。理解了双系统框架，你就有了一套"元认知工具”——每次向 AI 提问前，花 3 秒问自己：
“我的兔子还是乌龟在主导这次对话？我想唤醒 AI 的兔子还是乌龟？”
这一个习惯，就能让你的 AI 协同效率上一个台阶。
你在实际工作中见过哪些"好问题"和"坏问题"的典型案例？欢迎留言讨论。