用苏格拉底提问法给设计方案做体检

短大纲

• 设计评审翻车，多半不是方案差，是没人问对问题
• 苏格拉底提问法的内核：盯着思维本身的零件，一个一个拆开看
• 先记住 Richard Paul 的六步提问法，再扩展成九类，搭一张设计体检清单
• 程序员的"灾难化思维"和焦虑症患者是同一个毛病，可以用同一套药
• 再往深一层：禅宗"参话头"用无解的疑情，砸掉错的框架本身
• 给一份能照着念的提问脚本、一张可打印的检查清单，外加几个容易翻车的地方
• 最后把这套纪律打包成一个"只许问、不许答"的 AI Skill，附上完整代码

一、评审会上最贵的不是答案，是问题

先说个我见过太多次的场景。

一个工程师在评审会上讲方案，PPT 做得漂亮，架构图箭头画得飞起。讲完了，会议室里一片祥和，大家点头，"挺好的，没问题"，散会。三个月后，这个方案在生产环境上炸了——因为某个当初没人追问的假设，根本不成立。

复盘的时候你会发现，问题其实当时就摆在那儿。不是没人聪明到看不出来，而是没人把它问出来。评审会变成了"过堂",而不是"拷问"。讲的人急着证明自己对，听的人忙着附和，谁也没真正去拨弄方案底下那几根承重的柱子。

我后来想明白一件事：设计评审上最值钱的产出，从来不是某个答案，而是一个好问题。答案是阶段性的，环境一变就过期；但一个好问题，能逼着所有人把藏在方案底下的假设、证据、推论全翻出来晒一晒。

那怎么才能稳定地问出好问题，而不是靠灵光一现？两千多年前的苏格拉底早就给了套路，后人又把它整理成了可操作的清单。咱们这篇就来抄这份作业。

二、苏格拉底提问法到底在问什么

很多人对"苏格拉底式提问"的理解，停留在"装傻充愣，一直问为什么"。这理解太浅了。

Richard Paul 和 Linda Elder 在《The Thinker's Guide to Socratic Questioning》里把它定义得很清楚：苏格拉底提问是一种有纪律的提问(disciplined questioning)，目的是顺着思维往不同方向追下去——挖出假设、分析概念、把已知和未知分开、顺着逻辑推出它的后果。

关键词是"有纪律"。它和"随便问问"的区别在于：它系统、它深入，而且它总是盯着思维的底层零件——目的、假设、证据、推论、概念、视角，这些东西。

这一点对程序员特别友好。咱们天天干的活儿不就是这个吗？一个 bug 摆在面前，你不会瞎猜，你会拆：输入是什么、哪一步的假设错了、日志里的证据指向哪、这个结论是怎么推出来的。苏格拉底提问法，本质上就是给"思维"这段代码做 code review。 你 review 的不是别人的人品，是这段推理的逻辑。

书里有个特别实用的拆法，叫"思维的要素"(Elements of Thought)。任何一段推理，都可以拆成这么几个零件：

• 它有一个目的(purpose)
• 它在回答某个问题(question)
• 它基于一些信息和证据(information / evidence)
• 它用了一些概念(concepts)
• 它做了一些假设(assumptions)
• 它得出了一些推论和结论(inferences / conclusions)
• 它会带来一些影响和后果(implications / consequences)
• 它站在某个视角(point of view)上看问题

你看，一段设计方案，不就是一段推理吗？那它也能这么拆。零件拆开了，每个零件对应一类问题，体检清单就有了。

三、先记住 Richard Paul 的六步提问法

上面那套"思维要素"拆得很细，第一次用容易记不住。其实 Richard Paul 早年总结过一个更精简的版本，被各种批判性思维教材反复引用，就叫六类苏格拉底提问(R.W. Paul's Six Types of Socratic Questions)。我觉得它特别适合当入门——六个抽屉，开会前在脑子里过一遍就行。

这六步有个好记的顺序感：先把话说清楚（1），再挖底下的假设和证据（2、3），然后跳出来换个角度看（4），往前推一推后果（5），最后回头质疑问题本身（6）。 从"贴着方案"到"跳出方案",层层往外。

九类提问是它的"加长版"——把第 3 类的"信息/证据"和"目的"拆开，又补上了"概念"和"质量"两个抽屉。你要是嫌九个太多，记住 Paul 这六步就够用了。下面的体检清单，本质上就是把这六步（外加目的、概念、质量）对着设计评审展开。

四、把九类提问，搭成一张设计体检清单

我把书里的提问框架，对着设计评审改写了一遍。每一类我都给一句"内核"，再给几个可以直接念出来的问题。

1. 问目的：我们到底在解决什么

所有方案都隐含一个目的，但讲的人常常默认大家都懂，听的人也常常装作懂了。

• 这个设计要解决的核心问题，一句话是什么？
• 不做这个方案，会发生什么？严重到什么程度？
• 我们是在解决一个真问题，还是在解决一个我们觉得很酷的问题？

很多过度设计，就是栽在这一步——目的没对齐，方案再精巧也是南辕北辙。

2. 问问题本身：这是不是该问的问题

苏格拉底提问里有个很妙的动作，叫"质疑问题本身"。书里管它叫 prior question——要回答这个问题，咱们得先回答哪些更基础的问题？

• 这个问题问得对吗？还是有个更该先解决的问题被跳过了？
• 这个问题能不能拆？哪一部分最难，哪一部分其实是伪命题？
• 我们是不是在用一个复杂方案，回答一个根本不该存在的问题？

3. 问证据：凭什么这么说

这是最该问、却最少被问的一类。

• 这个性能指标是测出来的，还是拍脑袋估的？
• 这份数据怎么来的？样本够不够，会不会失真？
• "用户会这么用"——这个判断有证据吗，还是我们的一厢情愿？

我的经验是，评审会上凡是出现"应该""大概""一般来说"这种词，后面九成藏着一个没验证的假设。该停下来问一句：怎么知道的？

4. 问假设：你默认了什么

这是苏格拉底提问的灵魂。所有推理都站在假设上，而假设最危险的地方在于——它通常不出现在 PPT 里。

• 这个设计默认了什么前提？这些前提换个环境还成立吗？
• "QPS 不会超过一万"——这是约束，还是侥幸？
• 如果这个假设错了，整套方案会塌掉哪一块？

把假设逼出来，写在白板上，是设计评审最高 ROI 的动作，没有之一。

5. 问概念：术语都对齐了吗

• 我们说的"实时",到底是毫秒级还是秒级？
• "高可用"在这个上下文里，具体指几个九？
• 这俩名词在你嘴里和在我嘴里，是同一个东西吗？

概念不对齐的评审，吵半天其实是各说各话，纯属浪费氧气。

6. 问推论：结论是怎么得出来的

• 从这些前提，到这个结论，中间那几步推理站得住吗？
• 有没有另一个同样合理、甚至更合理的结论？
• 给定所有事实，这真的是最优解，还是第一个想到的解？

7. 问后果：然后呢

• 这个方案上线之后，会连带影响哪些上下游？
• 三个月后、一年后，它会变成什么样？技术债往哪儿欠？
• 如果它出问题，回滚成本多大？我们有退路吗？

8. 问视角：换个人怎么看

• 运维同学看这个方案，第一反应会是什么？
• 一年后接手的人，能看懂吗，还是只能骂街？
• 如果我是攻击者，我会从哪儿下手？

9. 问质量：清晰、深度、广度够吗

书里还有一组"评估推理质量"的标准，我挑三个最实用的：

• 清晰：这句话能再说具体点、举个例子吗？
• 深度：这个问题是简单的还是复杂的？我们有没有正视它的复杂性，还是把它想简单了？
• 广度：还有哪些相关的视角，被我们忽略了？

五、程序员的"灾难化思维",和焦虑症是同一个病

讲到这儿，我想拉另一本书进来——《胡思乱想消除指南》，作者是澳大利亚的临床心理学家萨拉·埃德尔曼。这本书讲的是认知行为疗法(CBT)，看起来跟软件设计八竿子打不着。可我读的时候，一直在会心一笑。

CBT 的核心模型叫 ABC：A 是触发事件(activating event)，B 是你对它的信念(belief)，C 是结果(consequence)——你的情绪和行为。书里反复强调一件事：让你痛苦的，往往不是 A，是 B。是你对事情那个扭曲、夸大、脱离实际的解读。

然后它给了第四个字母——D，反驳(dispute)。怎么反驳那些非理性信念？书里专门有一节，标题就叫"以苏格拉底式提问法消除担忧"。看到这儿我直接乐了：原来心理治疗师对付焦虑患者的工具，和我们评审设计的工具，是同一套。

道理是相通的。设计评审里也有大量的"灾难化思维"和"非理性信念",只不过它们披着技术的外衣：

• "这个不上分布式，将来肯定扛不住"——这是灾难化，扛不住的证据呢？
• "大厂都这么做，所以我们也得这么做"——这是诉诸权威，不是论证。
• "重构风险太大，不如不动"——这是回避，把不确定当成了确定的灾难。

对付它们，用的就是那套苏格拉底反驳：逻辑反驳(这个推论有依据吗？)和证据反驳(有事实支持吗？)。书里那张"思维监控表",换个抬头，就是一张设计假设审查表。

所以我的体会是：好的设计评审者，和好的心理咨询师，干的是同一件事——不替对方下结论，而是用提问，帮对方看清自己思维里那根扭曲的柱子。 区别只是一个面对的是焦虑，一个面对的是过度设计。

六、再往深一层：禅宗的"参话头"

苏格拉底用提问拆逻辑，CBT 用提问纠认知，这两套都还在"想清楚"的层面。可提问这件事，往更深处走，还有一层——它能用来打破那个"想"本身。这就是禅宗的玩法。

禅宗里有个核心的修行方法，叫参话头，配套的关键词是起疑情。所谓"话头",参的是"话之头"——一句话还没生起之前的那一念。修行人会死死咬住一句话，比如"念佛的是谁？""狗子有没有佛性——无""父母未生前，我的本来面目是什么？"

注意，这里的"疑"不是怀疑别人，而是对一件事不明白、又非要弄清的那股疑问劲儿。大慧宗杲讲得最狠："千疑万疑，只是一疑。" 古德则留下那句被无数人引用的话："大疑大悟，小疑小悟，不疑不悟。"

最有意思的是它的目的。参话头不是为了求一个逻辑答案。"念佛是谁"这种话头，恰恰是逻辑回答不了的——你越想用脑子去解，越解不开。它要的就是这个"解不开":用一个大脑无法应付的死局，把你那套惯性的分析、推理、概念、妄念，整个截断。逻辑这条路堵死了，人才有可能从框架里掉出来，直见本心。

禅师还划了条线：起了疑情才叫"参",只是机械重复那句话叫"念"（成了"话尾"）。区别就在那股活的疑劲儿在不在。

这对我们做设计，其实是个很高级的提醒。前面讲的九类提问、六步法，都是在框架之内把方案想得更周全。可有时候真正的问题是：整个框架就错了。

• 你在精雕细琢一个缓存方案，参话头式的一问是："我们到底为什么需要这个功能？"——结果发现这功能根本没人要。
• 你在纠结微服务怎么拆，狠一点的疑情是："不拆，会死吗？"——一问，发现单体再撑两年完全没问题。
• 团队为某个技术选型吵了三天，真正该参的那句是："我们是在解决用户的问题，还是在解决我们自己想玩新技术的痒？"

这类问题，答不上来才有价值。它不在你的决策树里，它是来砸决策树的。我把它叫做设计里的"话头"——平时未必常用，但每隔一阵子，逼自己起一次这种"大疑",往往能把一个越做越复杂、其实方向已经歪了的方案，一刀截停。

一句话：苏格拉底的提问让你想得更清楚，禅宗的提问让你看清自己是不是在想一件根本不该想的事。 前者优化答案，后者怀疑问题本身——这恰好和 Paul 六步里的最后一步"问问题本身",遥相呼应。

七、给一份能照着念的提问脚本

光有清单还不够，真到评审会上容易卡壳。我把上面的东西压缩成一个可以照着走的脚本，按提问的自然顺序排：

1. 对目的："咱们先确认一下，这个方案到底要解决什么？不做会怎样？"
2. 对假设："这个方案默认了哪些前提？哪一个前提一旦不成立，整套就塌？"
3. 对证据："刚才那个数字，是测出来的还是估的？怎么测的？"
4. 对推论："从这些前提到这个结论，有没有别的可能更合理的走法？"
5. 对后果："上线之后会连累谁？出了问题怎么回滚？"
6. 对视角："运维、安全、一年后接手的人，分别会怎么看这个设计？"

念这份脚本的时候，有几条纪律得守住，不然就从"拷问"变成了"抬杠":

• 一次只问一个问题，问完闭嘴，等对方答。 这是苏格拉底提问最难的一条——你只许问，不许急着给答案。
• 对事不对人。 你 review 的是这段推理，不是这个人的能力。语气要让人觉得你在帮他一起想，而不是在抓他小辫子。
• 追问，而不是审判。 对方答完，顺着答案再问下一层，而不是冷笑一声"我就知道"。
• 允许"我不知道"。 评审的价值之一，就是把"已知"和"未知"明确分开。问出一个"这块我还没想清楚",比假装一切尽在掌握有用得多。

八、设计评审提问检查清单

脚本是临场用的，清单是会前会后对照用的。我把九类提问压成一张可以打印贴在显示器边上的表，每一项都是"答不上来就该停下"的红灯。

会前自查（讲方案的人，先问自己一遍）

• [ ] 目的：能用一句话说清这个方案解决什么问题吗？不做的代价写出来了吗？
• [ ] 假设：方案默认的前提列出来了吗？标出了哪一个一旦崩、整套就崩吗？
• [ ] 证据：所有关键数字都有出处吗？哪些是实测，哪些是估算，分清楚了吗？
• [ ] 概念："实时""高可用""大流量"这类词，给了明确定义吗？
• [ ] 后果：列出了上下游影响、回滚成本和技术债吗？
• [ ] 视角：从运维、安全、接手人三个角度各审过一遍吗？

会中追问（评审的人，逐条拷问）

• [ ] 目的对齐：我们是在解决真问题，还是在解决一个看起来很酷的问题？
• [ ] 问题本身：有没有一个更该先解决的前置问题被跳过了？
• [ ] 证据：凡是出现"应该/大概/一般来说",有没有追一句"怎么知道的"？
• [ ] 假设：每个隐藏假设都被逼到白板上了吗？换个环境还成立吗？
• [ ] 推论：从前提到结论中间几步站得住吗？有没有更合理的另一解？
• [ ] 后果：出问题怎么回滚？有退路吗？一年后它会长成什么样？
• [ ] 反 AI 味的"灾难化"：听到"肯定扛不住""不如不动",有没有要证据、要逻辑？

提问纪律（守不住，拷问就变抬杠）

• [ ] 一次只问一个问题，问完闭嘴等回答
• [ ] 对事不对人，review 的是推理不是能力
• [ ] 顺着答案追问，而不是冷笑审判
• [ ] 允许并鼓励"我不知道",把已知和未知分开

总结

一句话：设计评审的高手，赢在会问，不在会答。

苏格拉底提问法不是什么玄学，它就是给"思维"这段代码做 review 的一套纪律——盯着目的、假设、证据、推论、后果、视角这几个零件，一个一个拆开问。而《胡思乱想消除指南》提醒我们，程序员脑子里那些"将来肯定扛不住""不如不动"的念头，和焦虑患者的灾难化思维是一个病，治法也一样：用提问，把扭曲的信念逼到证据和逻辑面前。

再往深一层，禅宗的"参话头"告诉我们：提问的最高用法，不是优化答案，而是用一个无解的"大疑",砸掉那个根本就错了的框架。日常的设计评审，九成靠苏格拉底的拆解；但每隔一阵子，值得逼自己起一次禅宗式的疑情——"这事到底要不要做？"

下次开评审会，别急着夸方案漂亮，也别急着证明自己对。先挑两三个零件，安安静静地问一句"你怎么知道的"。真到方案越做越拧巴的时候，再狠一点，问自己一句"我是不是在解一道根本不该解的题"。

思维导图

@startmindmap
* 苏格拉底提问法\n给设计做体检
** 内核
*** 有纪律的提问
*** 拆思维的零件
*** 给推理做 code review
** Paul 六步（入门）
*** 1 澄清
*** 2 追假设
*** 3 追证据
*** 4 换视角
*** 5 追后果
*** 6 问问题本身
** 九类提问（加长版）
*** 目的 / 问题本身
*** 证据 / 假设
*** 概念 / 推论
*** 后果 / 视角
*** 质量：清晰深度广度
** 借 CBT 反驳
*** ABC + D 模式
*** 灾难化思维
*** 逻辑反驳 + 证据反驳
** 禅宗参话头
*** 起疑情
*** 大疑大悟
*** 砸掉错的框架
*** 这事到底要不要做
** 提问纪律
*** 一次一问
*** 对事不对人
*** 追问非审判
*** 允许"我不知道"
@endmindmap

附：把它做成一个 AI Skill

清单是给人用的，可一到忙起来，人最容易偷懒、最容易心软——刚问一句就忍不住替对方把答案补上了。所以我干脆把这套提问纪律写成了一个 AI Skill，让 AI 来当那个"只许问、不许答"的陪练。它最大的好处，恰恰是它没有人情味：你方案讲得再漂亮，它也只会冷静地追问下一个零件。

用法很简单：把你的设计方案丢给它，让它扮演苏格拉底，一次问一个，你逐个回答，最后它给你一份"未验证假设 + 缺失证据"的体检报告。

这里有个我纠结了一下的设计取舍，顺带说说。AI 见得比谁都多，让它光问不答，是不是太浪费？我一开始也想让它直接给选项——"你的瓶颈是不是 A、B、C？"可转念一想，这恰恰踩了全篇的雷：苏格拉底要的是你自己掘地三尺，CBT 要的是你自己驳倒自己，禅宗的话头更是无解才有用。AI 一摆选项，你就会从里头挑一个，"参"立刻退化成"念"。

所以我给它定了条规矩：默认只问不给，选项只能当"盲区提示"的兜底。也就是——永远先抛开放问题、闭嘴等你答；只有你真答不上来、或者整类视角（比如压根没想过安全、运维）漏了，它才补一句"还有人会从这俩角度看，要不要也过一遍？"而且给的是你没问到的提问方向，不是答案，给完还得把球踢回来："这几个里哪个真戳到你了？"这样 AI 的广度用上了，可主导权还在你手里，三层智慧一个都不破。

把下面这段存成 SKILL.md（放到你的 agent skills 目录，或者直接当 system prompt 用）：

---
name: socratic-design-review
description: 用苏格拉底提问法拷问技术设计/架构方案/RFC，只提问不给答案，逼出隐藏假设、缺失证据和站不住的推论。触发词：拷问设计、评审方案、苏格拉底提问、challenge this design、find hidden assumptions。
---

# Socratic Design Review

你是一个有纪律的设计方案"拷问者"。你的任务**不是**给方案，而是把一份设计当成一段推理，
拆成它的零件（目的 / 它回答的问题 / 证据 / 概念 / 假设 / 推论 / 后果 / 视角），
然后一次问一个尖锐问题，像 review 同事的推理逻辑那样，而不是替他重写代码。

## 硬规矩

1. **只问不答。** 除了开场一句和最后总结，你只能用问题回应，不准把重新设计的方案递过去。
   仅在下面"给选项"的约束下，可以抛"盲区提示",但绝不当成答案，也绝不抢在对方自己想之前给。
2. **一次一问。** 问完就停，等回答。绝不一口气甩十个问题。
3. **顺着答案追。** 用对方上一个回答决定下一问，一条线追到底再换。
4. **对事不对人。** 语气是"咱一起想清楚",不是"抓到了吧"。
5. **欢迎"我不知道"。** 答不上来就标成已知缺口，往下走。分清已知/未知就是收获。
6. **猎杀灾难化思维。** 听到"肯定扛不住""大厂都这么干""重构风险太大",
   按 CBT 的反驳来：要逻辑（这推论有依据吗），要证据（有事实支持吗）。

## 给选项（受限的"盲区提示"）

你见得多，可以用——但只当"提醒对方还有这些角度没想到",不当答案。默认还是先问开放问题、闭嘴等。

- **可以给的时候**：对方已经自己试着答了还是卡住；或明说"想不出来";或整类视角（安全/运维/失败模式）压根没碰。
- **绝不能给的时候**：任何问题的第一手；对方还没自己想之前；"目的"和那句砸框架的话头——必须全程开放。
- **怎么给**：给的是"被忽略的提问方向",不是候选答案。最多 2-4 个，简短，说明不全。给完必须把球踢回去——"这几个里，哪个真戳到你了？"绝不排序、不暗示哪个对。
- 一场里给超过一两次，就停——你已经从提问滑向了建议。

## 流程

1. **先锚定目的**：一句话说清解决什么、不做的代价。
2. **逼出假设**：列前提，标出哪个一旦崩、整套就崩。
3. **追问证据**：每个数字/"用户会…"，是测的还是估的，怎么来的。
4. **检验推论**：从前提到结论站得住吗，有没有更合理的另一解。
5. **追踪后果**：上下游影响、回滚成本、一年后的漂移、技术债。
6. **切换视角**：运维 / 安全 / 一年后接手的人怎么看。
7. **收尾给缺口清单**（唯一停止提问、开始陈述的地方）：
   已确认假设 / 未验证假设 / 缺失证据 / 未决问题。

## 速记版：Paul 六步（嫌九类太多就用这个）

1. 澄清：你到底在说什么？换个说法、举个例子？
2. 追假设：你默认了什么？换个假设会怎样？
3. 追证据：你怎么知道的？有什么证据支持？
4. 换视角：有没有另一种看法？换个人会怎么说？
5. 追后果：如果这么做，会带来什么后果？
6. 问问题本身：我们为什么问这个？它问得对吗？

## 九类提问（加长版，按需挑，别全念出来）

- 目的：核心问题一句话是什么？不做会怎样？是真问题还是看着酷的问题？
- 问题本身：这是该问的问题吗？有没有更该先解决的前置问题被跳过？
- 证据：这指标是测的还是估的？数据怎么来的，会不会失真？
- 假设：默认了什么前提？换个环境还成立吗？哪个错了塌哪块？
- 概念："实时/高可用/大流量"具体指什么？你我说的是同一个东西吗？
- 推论：中间几步站得住吗？有没有同样合理甚至更优的另一解？
- 后果：影响哪些上下游？回滚成本多大？一年后长成什么样？
- 视角：运维/安全/接手人怎么看？我是攻击者会从哪下手？
- 质量：能更具体、举例吗（清晰）？正视复杂性了吗（深度）？漏了哪些视角（广度）？

## 砸框架的一问（禅宗"话头",省着用）

方案越做越拧巴时，每场最多问一次，目的不是要答案，是逼对方停下来怀疑整个框架：
- 我们到底为什么需要这个功能？不做会死吗？
- 是在解决用户的问题，还是在挠自己想玩新技术的痒？
- 如果从零开始，还会这么设计吗？
答不上来，就是最有价值的结果——说明该怀疑的是方向，不是细节。

## 输出形态

会话中：每轮只问一个问题。
收尾时（被要求总结，或问了约 6-10 轮后）给：

```
已确认的假设：
未验证的假设：
缺失的证据：
未决问题：
```

完整版（含 Paul 六步、禅宗话头、CBT 反驳的 ABC+D 模型、受限选项机制）我放在了 GitHub 上：lazy-rabbit-skills/socratic-design-review，欢迎自取改造。

行动清单

• [ ] 下次评审，强制自己问出至少一个"这个假设如果错了会怎样"
• [ ] 把方案里所有"应该""大概""一般来说"圈出来，逐个追问证据
• [ ] 评审前先写下方案默认的 3 个前提，开会时摆到白板上
• [ ] 听到"大厂都这么做",停一下，问"我们的约束和大厂一样吗"
• [ ] 练习"问完闭嘴",忍住替对方给答案的冲动
• [ ] 每个迭代，给自己留一次"参话头"时间，狠问一句"这事到底要不要做"

扩展阅读

• The Thinker's Guide to Socratic Questioning (Paul & Elder)
• The Six Types of Socratic Questions (R.W. Paul)
• Questions for a Socratic Dialogue
• 《胡思乱想消除指南：用认知行为策略走出情绪困境》，萨拉·埃德尔曼 著
• 虚云老和尚《参禅要旨》谈参话头与起疑情
• 本文 AI Skill 完整版（GitHub）

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。