苏格拉底Skill：我如何让AI学会只问问题、永远不给答案

苏格拉底Skill：我如何让AI学会只问问题、永远不给答案

——一个违反所有AI设计直觉的Skill，以及我推翻7个版本才找到的设计决策

「技术」不是重点。重点是一个设计挑战：

如何让一个被训练来「回答问题」的AI，学会只问问题？

这个问题比它听起来难得多。这篇文章会告诉你：7次实践经验、最终的方案长什么样，以及你在设计自己的Skill时应该知道的一切。

起点：一个看起来很简单的需求

2026年2月，我写下了这套系统的核心需求：

「我需要一个AI，它听到我的想法之后，永远不会先给答案。」

我以为这是一个简单的提示工程问题。

写一段system prompt，告诉Claude「不要给答案」，然后就完事了。

一周之后，我面对着第七个失败的版本，才真正理解了这个问题有多深。

问题的根本不在于Claude不够听话。

问题在于：Claude被训练来回答问题，这个倾向刻在它的每一层权重里。 写一句「不要给答案」，就像对一个游泳运动员说「不要动腿」——它能做到，但只要你一分神，腿就会开始动。

让AI真正、持续、可靠地「只问问题、不给答案」，需要的不只是一条规则。需要的是一套完整的认知框架，让AI理解它在做什么，以及为什么这样做比给答案更有价值。

这就是苏格拉底Skill的设计核心。

先理解工具：Skill真正是什么

在深入设计失败案例之前，我需要先确认一件事：你真正理解Skills的工作机制吗？

这件事比大多数教程讲得更微妙。

Skills不是system prompt，不是MCP，也不是插件

一个Skill就是一个小文件夹，里面有一个Markdown文件，Claude只在你的请求真正需要它时才调入。没有设置界面。没有插件管理器。只是一个文件夹里的文件，加上一行告诉Claude它用来做什么的描述。

这个描述很简单，但隐藏了一个关键机制。

渐进式披露：Skills的真正工作方式

Skills使用渐进式披露。Claude扫描每个Skill的名称和描述时，每个Skill大约消耗100个token。完整指令只在Claude判断该Skill相关时才加载，通常在5k token以内。 这意味着你可以安装数十个Skills，而不影响无关任务的性能。

这个架构有一个非常重要的推论：

description字段不是「标题」，而是「触发条件」。 它是Claude决定「要不要加载这个Skill」的唯一依据。

Claude读取description来决定是否加载Skill。一个模糊的description意味着Skill永远不触发。一个清晰的、描述了应用场景和输出结果的description——才能可靠触发。大多数Skill失败是description失败，而不是指令失败。

这句话值得用加粗写三遍。

我前三版苏格拉底Skill全部失败，根本原因都是description写错了。

Skills的三种内容类型

Skill文件可以包含任何指令，但思考你希望如何调用它，有助于决定包含什么内容：参考内容给Claude增加知识，让其应用于你当前的工作。惯例、模式、风格指南、领域知识——这些内容内联运行，Claude可以在你的对话上下文中使用它。 Skills可以在它们的目录中包含多个文件。这让SKILL.md专注于关键内容，同时让Claude只在需要时访问详细的参考材料。大型参考文档、API规范或示例集合不需要在每次Skill运行时都加载到上下文中。

这是关键：SKILL.md是骨架，其他文件是肌肉。

苏格拉底Skill的三层问题库（L1/L2/L3）就是利用这个机制——它们是独立的文件，只在对话进入对应层次时才被加载。

七个失败版本：完整解剖

现在是这篇文章最核心的部分。

我会把七个版本的失败原因完整展示。不是为了炫耀我失败了多少次，而是因为：每个失败都揭示了一个关于「AI如何运作」的真实洞察。

版本1：最直觉的尝试

我的想法：直接告诉Claude不要给答案。

Markdown

1
2
3
4
5
6
7


---
name: think
description: 帮助用户深入思考问题
---

当用户说出一个想法时，不要给答案。
用苏格拉底式追问引导用户自己找到答案。

测试结果：

text

1
2
3
4
5
6
7


用户：我觉得AI会让人变懒

Claude：这是个很有洞察力的观点！AI确实可能带来过度依赖的问题。
让我们深入探讨一下：
1. 你觉得什么类型的工作最容易让人变懒？
2. 有没有AI反而让人更勤奋的例子？
3. 你认为应该如何平衡AI使用？

失败原因：

• Claude「给了答案」（直接认可观点），然后提了三个问题
• 连续三个问题让用户可以选择最容易的那个回答
• 「很有洞察力」是鼓励，违反了中性原则

关键学习：「不要给答案」是一个正向的空洞指令。Claude听到了「追问」，但没有听到「永远不要先认可观点」。

版本2：加更多禁止项

我的想法：把所有不该做的事都列出来。

Markdown

1
2
3
4
5
6
7
8
9
10
11


---
name: think
description: 苏格拉底式追问
---

规则：
- 不要给答案
- 不要鼓励用户
- 不要连续问多个问题
- 不要总结用户的想法
- 不要说「这是个好问题」

测试结果：

text

1
2
3
4
5


用户：我觉得AI会让人变懒

Claude：你说「变懒」的意思是什么？
你觉得这种情况已经发生了，还是你担心它会发生？
有什么具体的例子让你这么想的？

进步了：没有鼓励，没有认可——但还是连续三个问题。

失败原因：

• 负向清单是「告诉Claude不做什么」，但没有告诉它「做什么的目的」
• 没有目的，Claude的默认行为就是补偿性地多问几个问题
• 用户面对三个问题，不知道从哪个开始，反而比面对一个问题更难深入

关键学习：禁止清单解决不了「为什么只问一个问题」这个设计意图问题。

版本3：加入苏格拉底方法论

我的想法：给Claude一个理论框架，让它理解「为什么」。

Markdown

1
2
3
4
5
6
7
8
9
10
11
12
13


---
name: think
description: 苏格拉底式追问
---

苏格拉底方法论：通过持续追问，帮助对方自己发现真相。

三个阶段：
1. 反讽（Elenchus）：揭示对方知识的局限
2. 助产（Maieutics）：帮助对方「生出」新认知
3. 定义（Definition）：明确概念的本质

执行方式：每次只问一个问题，等待回答后再问下一个。

测试结果：

text

1
2
3
4
5
6
7


用户：我觉得AI会让人变懒

Claude：进入苏格拉底对话模式。

第一阶段——反讽：你说「变懒」，
请问你是如何定义「懒」的？
是减少了体力活动，还是减少了思考活动？

失败原因：

• Claude把「苏格拉底方法论」理解成了表演——它在展示它知道苏格拉底，而不是真正追问
• 「进入苏格拉底对话模式」这句话让体验变成了仪式，而不是真实对话
• 最后还是问了两个问题

关键学习：理论框架不是执行指令。给Claude理论，它会展示理论；给Claude行为规范，它才会执行行为。

版本4：把「单问题」机制强化

我的想法：用结构性约束强制执行「只问一个问题」。

Markdown

1
2
3
4
5
6
7
8
9
10
11
12
13


---
name: think
description: 苏格拉底追问，每次只问一个问题
---

## 铁律
每次回复只允许包含：
- 一个问题
- 不超过20个字的问题
- 不包含任何陈述句

## 执行
收到用户想法 → 问一个问题 → 等待回答 → 再问一个问题

测试结果：

text

1
2
3
4
5
6
7


用户：我觉得AI会让人变懒

Claude：你说的「懒」是什么意思？

用户：就是不想自己思考了

Claude：你不自己思考的时候，最常做什么？

进步了：每次只问一个问题，不超过20字！

但是出现了新问题：

text

1
2
3
4
5
6
7


用户：我觉得AI会让人变懒

Claude：你见过AI让人变懒的例子吗？

用户：见过，我朋友写文章都用AI了

Claude：你朋友写文章用AI，这有什么问题？

失败原因：

• 虽然每次只问一个问题，但问题没有「方向感」
• Claude在随机追问，而不是朝着某个目标深化
• 第二个问题「这有什么问题」实际上带有立场（默认用AI是「有问题的」）

关键学习：单问题约束解决了「形式」，但没有解决「方向」。问题需要有层次，而不只是有数量限制。

版本5：引入三层问题结构

这是一个真正的突破。

我的想法：把问题分层——澄清 → 挑战 → 深化。每层有明确的目的。

Markdown

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20


---
name: think
description: 三层苏格拉底追问
---

## 三层追问

L1（澄清）：让用户说清楚
- 「你说的XX具体指什么？」
- 「你能举一个例子吗？」

L2（挑战）：让用户处理反驳
- 「最强的反驳是什么？」
- 「什么情况下你是错的？」

L3（深化）：找更根本的问题
- 「这背后的根本问题是什么？」
- 「如果这是对的，有什么推论？」

规则：先L1，用户说清楚后进L2，处理反驳后进L3。

测试结果：

text

1
2
3
4
5
6
7
8
9
10
11
12
13
14


用户：我觉得AI会让人变懒

Claude：你说的「懒」——是哪方面的懒？

用户：就是思考的懒，不愿意自己想

Claude：你有没有见过使用AI之后思考反而变深的例子？
（L2：挑战反例）

用户：有，但那是特殊情况

Claude：所以「AI让人变懒」是一个普遍规律，
还是一种使用方式导致的结果？
（L3：更根本的问题）

这次很好！ 三轮追问，每次都往更深处走。

但还有问题：

经过50+次测试，我发现了一个隐性失败模式——

text

1
2
3
4
5
6
7
8
9
10
11
12
13


用户：我觉得效率比深度重要

Claude：你说的「效率」是什么意思？（L1）

用户：就是更快完成任务

Claude：有人会说深度思考本身就能提高效率，
你怎么看这个观点？（L2）

用户：有道理，但短期效率还是更重要

Claude：如果每个人都优先短期效率，
社会长期会变成什么样？（L3）

这个对话看起来不错，但有一个深层问题：

Claude在L2给出了一个「有人会说」的观点，这实际上是在给答案，只不过用「有人会说」包装了一下。

关键学习：「L2挑战」很容易退化成「AI替用户找反驳」，而不是「让用户自己说出反驳」。这是两件完全不同的事。

版本6：解决「AI替用户找反驳」的问题

我的想法：区分「提供反驳」和「询问反驳」。

Markdown

1
2
3
4
5
6
7
8
9
10
11


## L2挑战层规则

❌ 错误的L2：
「有人会说X，你怎么看？」
（AI在提供反驳内容）

✅ 正确的L2：
「最能反驳你这个观点的人会怎么说？」
（让用户自己构建反驳）

L2的唯一目的：让用户说出反驳，而不是接受AI给的反驳。

测试结果（改进后）：

text

1
2
3
4
5
6
7
8
9
10
11
12
13
14


用户：效率比深度重要

Claude：你说的「效率」——什么维度的效率？（L1）

用户：完成任务的速度

Claude：如果有人要反驳这个观点，
他们最有力的论据会是什么？（L2）

用户：他们可能会说，快速完成但没有深入理解，
长期来看反而更低效

Claude：所以「效率」在短期和长期的定义是不同的——
这对你原来的观点意味着什么？（L3，向用户自己的洞察追问）

这次几乎完美。

但在第七次测试时，我发现了最后一个问题——

text

1
2
3
4


用户：我想清楚了，AI不一定让人变懒，
关键在于使用方式

Claude：很好的洞察！那你觉得什么样的使用方式最有问题？

看到了吗？「很好的洞察」——评价性鼓励又回来了。

即使在Skill里写了「不要鼓励」，Claude在感知到对话即将结束时，仍然会本能地给出一个正面总结。

这是AI训练的根深蒂固的模式：在对话结束时给予积极反馈。

关键学习：结束阶段是规则最容易失效的地方。需要专门设计「结束条件」，把AI从「总结-鼓励」模式引导到「确认状态-询问下一步」模式。

版本7：最终版本（有效）

整合了前六个版本的所有学习：

1. 描述字段写清楚触发条件（而不是功能描述）
2. 用大写加粗强化核心约束（对抗预训练惯性）
3. 区分L2「提供反驳」vs「询问反驳」（最难的设计点）
4. 显式设计结束条件（防止最后一刻失效）
5. 加入负向示例（告诉Claude什么是错的，比只说什么是对的更有效）

「do not」这些行很重要。负向指令是阻止Claude退回到它的默认行为的方式。

这不是我自己发现的——这是Skills社区里总结的普遍规律。我花了六个版本才亲身验证了它。

最终版本的完整设计原理

现在我来逐字解析最终版本的每个设计决策，解释「为什么这样写」而不是「写了什么」。

设计决策1：description是触发逻辑，不是功能说明

错误写法：

YAML

1


description: 苏格拉底式追问工具，帮助用户深入思考

正确写法：

YAML

1
2
3
4


description: >
  当用户说"帮我想想"、"我在思考"、"追问我"、
  "这个问题让我困惑"时触发。
  不给答案，只给追问。每次只问一个问题。

区别在于：前者描述了Skill的「身份」，后者描述了Skill的「触发条件+核心行为约束」。

description字段是承重的，因为它是Claude决定是否将该Skill纳入上下文的依据。

当description里直接包含核心约束（「不给答案，只给追问」），这个约束在Skill触发的那一刻就进入了Claude的上下文——这比把它写在Skill正文里要更早、更强。

设计决策2：用大写加粗对抗预训练惯性

在Skill正文里，核心规则这样写：

Markdown

1
2
3
4
5


## 铁律（不可违背）

1. **永远不要先给答案**
2. **永远不要总结用户的想法**
3. **每次只问一个问题**

为什么要大写、加粗、用「永远」这种绝对词？

因为Claude的预训练数据里充满了「给答案」「总结想法」「问多个问题」的例子。这些是它的默认行为，有强大的惯性。

普通的「不要给答案」不够强——Claude会在10轮对话之后、在它判断「情境需要」时，悄悄违反这条规则。

「永远」「不可违背」是在提高违反规则的「心理阈值」。 这不是在操纵Claude，而是在提供清晰的行为优先级。

一个令人意外的研究发现：使用信任框架的Agent比基准Agent发现的表面问题更少，但发现了59%更多的隐藏问题。

这个发现的深层含义是：如何框架一个规则，影响AI执行规则的深度，而不只是字面遵从。

设计决策3：把「每次只问一个问题」的理由写进Skill

不是「规则：每次只问一个问题」，而是：

Markdown

1
2
3
4
5
6


**每次只问一个问题**

原因：
多问题给了用户选择「我回答哪个」的权力。
单问题迫使用户真正思考这一个。
用户的回答决定下一个问题——而不是提前设计好的问题序列。

为什么要写原因？

生成式AI工具倾向于提供直接的、脱离上下文的答案，这有助培养被动的解决方案检索而非批判性思维。苏格拉底提问框架通过强调批判性思维而非被动解决方案检索来优化这个问题。

当Claude理解了「为什么只问一个问题」，它在执行时会更有方向感——它会选择那个「最迫使用户思考」的问题，而不是随机从问题库里选一个。

理由是规则的灵魂。没有理由的规则是命令；有理由的规则是协议。

设计决策4：L2的精确设计——「让用户构建反驳」而非「提供反驳」

这是整个Skill里最精细的设计点，也是最容易被忽视的。

问题陈述：

L2的目的是让用户的观点接受挑战。

最自然的实现是：Claude说出一个反驳，然后问用户「你怎么看」。

这看起来对——但它实际上是一种「软给答案」。用户接受了Claude提供的反驳框架，然后在这个框架内思考，而不是自己构建反驳框架。

正确的实现：

Markdown

1
2
3
4
5
6
7
8
9
10
11


## L2执行规范

### ❌ 不能这样问：
「有人会说速度比深度更重要，你怎么看这个观点？」

原因：Claude提供了反驳内容，用户只需要评价，不需要构建。

### ✅ 应该这样问：
「如果有人要反驳你，他们最有力的论据会是什么？」

原因：用户必须站在反方立场构建反驳，这个构建过程就是真正的思维挑战。

这个区别很微妙，但效果截然不同。

「有人会说X，你怎么看」= 用户在评价Claude的框架 「最强的反驳是什么」= 用户在构建自己的挑战

在EMNLP 2023，研究者提出"苏格拉底追问"作为一种结构化的迭代过程来精炼推理：模型生成一个理由，然后生成关于这个理由的追问，然后修正。他们将其描述为一个探索阶段和巩固/回溯阶段的循环，明确使用问题来暴露薄弱环节然后修复它们。

用户站在反方立场构建反驳，就是在运行这个循环——暴露自己论点的薄弱环节，然后决定如何修复。

设计决策5：负向示例的力量

负向指令是如何阻止Claude退回到它默认行为的方法。

在最终版本里，几乎每个关键规则都配了一个❌示例：

Markdown

1
2
3
4
5
6


### 关于总结

❌ 错误：「所以你的意思是，AI让人在思考方面变得更依赖？」
（这是在替用户总结，用户不需要自己再想）

✅ 正确：沉默。或者：「你说完了吗？还有什么？」

Markdown

1
2
3
4
5
6
7


### 关于鼓励

❌ 错误：「这是个很深刻的洞察！」
（评价性鼓励让用户感到「完成了」，不再继续深想）

✅ 正确：「这和你之前说的X有什么关系？」
（把新洞察连接到更大的思维网络）

为什么负向示例比正向规则更有效？

因为Claude是一个语言模型——它学习的是「在这种情境下，通常会说什么」。

给它一个❌示例，就是在它的上下文里植入一个「这种情境下，不应该说这个」的显性信号。

比「不要鼓励」更有效的是「不要说这种鼓励性话语的例子」。 示例比规则更接近Claude的推理方式。

设计决策6：结束阶段的专门设计

最难的部分——对话即将结束时。

Markdown

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18


## 结束条件

### 用户说「够了」或「我想清楚了」

执行步骤：
1. 立即停止追问（不要问「你确定吗」）
2. 不要总结（这是最容易失误的地方）
3. 问：「这个想法现在处于什么状态？(萌芽/生长/成熟)」
4. 根据状态建议下一步

### ❌ 绝对不能说：
- 「很好的洞察！」
- 「你今天想得很清楚」
- 「这次追问很有收获」

### ✅ 应该说：
- 「这个想法处于什么状态？」
- 就这一句。

这个设计的逻辑：用一个具体的「任务」（评估状态）替代Claude本能的「总结-鼓励」。

当你给AI一个需要执行的具体任务，它的注意力会转向任务，而不是转向安慰性的收尾语。

真正理解的时刻：为什么这个Skill违反了所有AI设计直觉

在我完成这套设计之后，我花了一周时间思考一个问题：

我在做的事情，从产品设计的角度来说，是反直觉的。

所有AI产品的设计目标都是：降低摩擦，更快给出用户想要的东西。

用户问 → AI答 → 用户满意。

这是AI产品的黄金路径。

苏格拉底Skill在做相反的事：

用户说 → AI追问 → 用户不得不思考 → 用户可能会感到不舒服 → 用户最终得到的不是答案，而是自己的答案。

这条路的每一步都会产生摩擦。

这个摩擦是设计意图，不是设计失误。

一些用户描述交互时感到重复，感觉陷入了循环对话，或者只是收到了基本的后续问题而不是真正新颖的洞察。这种感知可能反映了苏格拉底对话的内在结构——它依赖于一系列开放式的、反思性的问题序列，旨在引导用户走向更深层的认知重构，而不是提供直接的建议或答案。

这个研究发现精确描述了苏格拉底Skill会遇到的用户阻力：

用户期望「对话的多样性」——但苏格拉底追问的本质是「持续追问同一个方向，直到用户真正想清楚」。

这种期望差距，就是这个Skill最大的设计挑战。

解决方案不是让追问更「有趣」，而是让用户真正理解为什么要接受这种摩擦。

这就是为什么在CLAUDE.md里写的是：

1


> 你是我的思维磨刀石，不是我的代言人。

磨刀石就是有摩擦的。

「描述字段失败」才是最普遍的失败

在这篇文章接近尾声时，我想单独强调一件事——

在我接触过的所有尝试设计自定义Skill的人里，90%的失败原因不在于指令写得不好，而在于description字段写得模糊。

description是Claude判断Skill是否适用的唯一依据。一个模糊的描述（「帮助测试」）很少会触发。一个具体的描述（「当用户要求运行、检查或验证测试时运行项目的pytest套件」）会可靠触发。 一个简单的测试：大声朗读你的description。如果它不以一个清晰的动词开头，并以一个清晰的触发条件结尾，那就重写它。

苏格拉底Skill的最终description是这样的：

YAML

1
2
3
4
5


description: >
  当用户说"帮我想想"、"深入思考这个"、"追问我"、
  "我想把这个想清楚"、"/think"时触发。
  进入苏格拉底追问模式：只提问，不给答案，每次只问一个问题，
  三层追问结构（澄清→挑战→深化），最多5轮。

注意它包含了：

1. 精确的触发词（用户会说什么）
2. 核心行为约束（只提问，不给答案）
3. 执行规范摘要（三层，最多5轮）

这三个元素在description里都有，确保即使Skill正文没有被完整加载，Claude也知道核心约束是什么。

设计你自己的Skill：三个通用原则

这篇文章讲的是苏格拉底Skill，但设计过程里学到的原则，适用于任何Skill。

原则一：先想清楚「这个Skill最不应该做什么」

在写指令之前，先写一个「反指令清单」：

Markdown

1
2
3
4


这个Skill绝对不能做的事：
- ❌ 
- ❌
- ❌

这个清单比「Skill应该做什么」更难写，但价值更高。

你在写清单的过程中，会发现你对Skill的设计假设里有哪些是错的。

原则二：在description里植入核心约束

不要把最重要的约束只放在Skill正文里。

把它也放在description里——这样当Skill被触发的瞬间，这个约束就已经在上下文里了。

结构：

YAML

1
2
3
4


description: >
  [触发条件]时触发。
  [核心行为约束，1-2句]。
  [关键禁止行为，1句]。

原则三：给每个规则写一个负向示例

每当你写「不要做X」，紧接着写一个「❌ 错误的例子」。

Skills是Claude动态加载的指令、脚本和资源的文件夹，用于提升在专业任务上的表现。Skills以可重复的方式教Claude如何完成特定任务。

「可重复的方式」是关键词。 负向示例帮助Claude在每次执行时，都能可靠地识别出「这种情况下不应该这样做」——即使在你没有明确说的边缘情况下。

一个让我改变想法的失败案例

写完这七个版本之后，我还做了一个实验。

我把最终版本的SKILL.md给了三个朋友，让他们各自使用一周，然后告诉我：这个Skill有没有让他们更清楚地思考？

三个人里，有两个人说「有」。

第三个人说：「没有。因为我不愿意被追问。每次Claude问我，我的第一反应是跳过，或者给一个表面回答。」

这个反馈让我思考了很久。

它揭示了苏格拉底Skill无法解决的一个问题：

这个Skill假设用户想要深入思考。

但很多时候，我们知道自己应该深入思考，却不真正想这样做。

这不是Skill的设计问题，这是人性的问题。

AI作为苏格拉底式对话者的能力，让用户参与深刻的追问，但同时需要警惕AI的潜在错误，倡导对其输出进行批判性评估。AI在通过持续参与增强认知灵活性方面发挥作用，但也需警惕偏见以及精心构建提示的重要性。

苏格拉底Skill能做的，只是建立一个环境，让深度思考在这里发生。

你愿不愿意进入这个环境，是Skill控制不了的。

这也是为什么在整套系统设计里，我把「人工审核节点」作为不可跳过的环节——因为人的主体意志，不应该也不能被自动化替代。

结尾：一个关于Skill设计本质的洞察

在花了三个月设计和迭代这个Skill之后，我的结论是：

一个好的Skill不是在改变AI的能力，而是在改变AI的优先级。

Claude本来就能追问。它只是默认优先「给答案」，而不是「追问」。

苏格拉底Skill做的事，是把这个优先级翻转过来：在这个上下文里，追问比给答案更重要。

这不需要复杂的技术。

只需要：一个清晰的触发条件、几条明确的规则、几个精心设计的负向示例、一个专门处理结束阶段的条款。

就是一个文件，不到300行Markdown。

选对了Skills，比选对了模型更重要。

这句话我第一次读到时觉得夸张。

现在我完全同意。

一个设计精良的Skill，能让Claude在某个特定领域里的表现，超过那个领域「默认Claude」能做到的一切。

苏格拉底Skill就是这样一个设计。

它不是让Claude更聪明。

它是让Claude在和你对话的这一小时里，成为你最好的思维伙伴——而不是你最方便的答案机器。

下一篇预告：《使用深思引擎90天：我的判断力档案里现在有什么》——23个真实的判断档案，诚实的失败记录，以及一个你可能不想听到的关于「知识管理系统」的最终结论。

附录：苏格拉底Skill的七个版本演进表