SocratiCode：用苏格拉底式提问重塑AI编程思考方式

最近我在折腾 AI 编程助手的时候，注意到一个有意思的开源项目：SocratiCode。名字很直白，Socrates 加上 Code，就是把苏格拉底那套“只提问、不直接给答案”的对话方式搬到了编程场景里。市面上大部分 AI 编程工具都在想尽办法帮你把代码写出来，SocratiCode 反着来，它宁可憋着不写代码，也要靠一连串问题把你问明白。

这篇文章我会从使用者的角度聊聊 SocratiCode 在解决什么问题、它的核心思路是什么、我实际拿它做了哪些事，以及过程中踩过的坑和整理出来的工作流。如果你写了一阵代码、开始发现自己越来越依赖 AI 补全、但越来越说不清自己的设计逻辑，那这篇文章应该对你有参考价值。

1. SocratiCode 到底在治什么病

1.1 我用 AI 写代码，写到最后发现自己“虚”了

先说个我自己的体会。前两年 AI 补全工具刚火起来的时候，我属于重度用户。需求拆完，直接丢给 Copilot 或者 Cursor，它能像变魔术一样把代码补出来，我负责 review。一开始感觉很爽，效率确实翻倍，但时间久了问题来了：代码能跑，可如果有人在 Code Review 时多问几句“为什么这样处理”“这个分支什么时候会进”“如果这里失败了会怎样”，我经常要想很久，甚至答不上来。

后来我带实习生的时候也发现了同样的现象。实习生用 AI 工具写接口，写得又快又像样，但问到他“这个状态什么时候会变成 CANCELLED”“你这个幂等键是怎么生成的”，他就开始支支吾吾。代码确实是他的，但代码背后的逻辑，他并没有完全吃透。

SocratiCode 就是冲着这个问题来的。它不帮你跳过思考，而是反过来逼你思考。它的核心逻辑不是“你要什么，我给你什么”，而是“你想做这件事，先回答我几个问题再说”。

1.2 苏格拉底式提问怎么落到代码里

苏格拉底方法的本质，是通过连续反问让对方自己发现认知漏洞。放在编程里就是：你告诉它“我要做一个订单超时关闭功能”，它不会马上甩给你一段定时任务代码，而是抛出问题——“订单在什么状态下需要超时关闭？”“如果支付回调正好在这个时刻进来，两个任务同时操作订单状态怎么办？”“关闭失败之后有没有补偿机制？”

你仔细品一下，这些问题其实全是你写代码之前本来就应该想清楚的。只是很多时候我们赶进度，或者依赖 AI 补全，把这些思考过程悄悄绕过去了。SocratiCode 做的事情，本质上就是把“先想清楚再写代码”这套方法论，强行通过对话流程注入到你的工作习惯里。

我后来查了一下它的命名逻辑，这个思路其实参考了认知科学里的“生成效应”：同样是学一个知识点，自己费力回忆出来的内容，比直接看答案记住得更牢。写代码也是一样，你自己在追问下想出来的方案，比 AI 直接给你的方案理解深得多。

1.3 先立个预期：它不是给所有人准备的

我在试用的时候就想，这个工具口碑一定会两极分化。喜欢的人会很喜欢，因为它某种意义上是一个“思考教练”；讨厌的人会非常讨厌，因为“我找你就是要你写代码，你给我搞一堆问题，烦不烦”。

我自己总结了一下适合用这类工具的人群：

• 有 1~3 年经验的开发，想突破“只会拼代码”的瓶颈，建立系统性的设计意识。
• 承担 Code Review 任务的技术骨干，需要快速发现设计盲区。
• 带新人的导师，想培养新人的独立思考能力，而不是手把手喂答案。
• 对 AI 编程有好奇心，愿意实验不同协作方式的折腾党。

反过来，如果你正在赶 deadline，需求今天提明天上线，那你大概率没耐心陪它玩一问一答的游戏。这个时间点硬上 SocratiCode，只会让你血压升高。

2. 机制拆解：它是怎么把 AI 调教成“提问狂魔”的

2.1 它跟普通补全助手到底差在哪

我画了个对比表，你可以快速感受一下它的定位差异。

注意我说的是“SocratiCode 式的引导工具”，因为这类理念的工具以后可能会越来越多。它的核心价值不在于让你写得快，而在于让你写之前先想清楚。

这种差异在代码审查场景里特别明显。普通助手拿到一段有问题的代码，它会直接说“把这里的 if 改成这样”，然后你照着改完就完了，为什么改？下次还会不会踩？未必记得住。SocratiCode 拿到同样一段代码，它会问“你觉得这条分支在什么情况下会被触发？如果触发之后执行到一半抛异常，外层怎么处理？”当你开始回答这些问题，你就已经主动把代码的执行路径在脑子里过了一遍，问题出在哪，你自己就找到了。

2.2 “连续追问”的会话机制是怎么工作的

这类引导式工具最常见的实现方式，是依赖多轮对话的上下文管理。你把一段代码或一个需求扔给它，它会记住你后续的每一次回答，再把你的回答作为下一轮追问的依据。这样一轮一轮下来，它不是随机提问，而是一层层往核心风险处挖。

我拿一段真实工作里的简化代码来模拟一下这种感觉。比如我贴了一段支付回调处理的逻辑：

用户：这是我写的支付回调处理，帮我看看有没有问题。

SocratiCode 的反应不是“这里有 bug，请修复”，而是：

SocratiCode：如果支付平台因为网络超时对同一笔订单重试了两次，你的回调入口对这两次通知分别会怎么处理？

我一开始没意识到这里可能有问题，回答“应该是更新订单状态为已支付”。

SocratiCode 继续追问：那第二次通知进来的时候，订单已经变成已支付了，你的代码还会再更新一次吗？这次更新有没有可能把其他状态覆盖掉？

看到没有，它不是一下子把所有问题都甩给你，而是根据你的回答，一步一步把你引到“幂等”“状态覆盖”这些关键问题上。每组对话都在训练你一种反射习惯：写代码先想边界条件、重复调用、并发冲突。

2.3 一套可以抄作业的 Prompt 配置思路

SocratiCode 这类项目通常是作为 IDE 插件或命令行工具出现的，底层接的还是大模型 API。很多情况下你自己的模型 Key 和系统 Prompt 是可以自定义的。如果你不想用现成工具，想自己在 Cluade 或者 GPT 里复现一套“苏格拉底式编程教练”，我分享一个我实验过一段时间的 Prompt 配置思路。

你是一个苏格拉底式编程教练。你的目标不是替用户写代码，而是通过提问帮助用户自己发现答案。 规则： 1. 每轮对话最多提出一个问题，不要一次性抛出完整问题清单。 2. 优先追问边界条件、异常分支、并发冲突、重复调用、状态一致性和可维护性。 3. 用户回答后，用一句话简短确认，然后提出下一个更深入的问题。 4. 不要直接输出实现代码，除非用户连续两次明确请求给出具体方案。 5. 如果用户明显偏离上下文，提醒他回到当前代码片段。

为什么“每轮最多提一个问题”？我试过一次性甩 5 个问题出去，效果很差。人面对问题清单的第一反应是挑最简单的一个回答，剩下的自动忽略。一次只问一个，用户就没办法躲，只能正面回答，这才能逼出真正的思考。

“连续两次明确请求才给方案”也是一条很有用的护栏。用户偶尔会偷懒，说“你直接告诉我该怎么写”，第一次请求时你给提示、给方向，但不给代码；如果他坚持要，说明他确实卡住了，这时候再给方案，既保住了思考过程，也避免了把人逼疯。

3. 实操记录：我拿 SocratiCode 做的三件正事

3.1 用它做了一次真实 Code Review

上个月我们组处理一个支付回调接口，组里同事写完代码之后我看了一眼，隐约觉得逻辑有点问题，但说不清楚具体哪不对。我顺手把这段代码丢进用 SocratiCode 配置好的会话里，让它来当“审查官”。

代码大概逻辑是：接收支付回调 -> 校验签名 -> 更新订单状态 -> 返回成功。表面上看很干净，但 SocratiCode 第一轮就问了：回调处理有没有对“重复通知”做幂等处理？我看到这个问题的时候愣了一下，因为我真的没检查这一点。同事说他当时想过，觉得重复通知概率低，就没加。

SocratiCode 接着追问：如果支付平台对同一笔订单推送了两次成功通知，你这里会执行两次“更新订单为已支付”，第一次把状态从“待支付”改成“已支付”，第二次进来的时候状态已经结束了，你的代码会不会抛异常？或者更隐蔽一点，如果你后续加了“已支付订单不允许修改”的防护逻辑，第二次通知是不是会导致回调处理失败，然后触发平台的重推机制，再进第三次、第四次？

它这一个问题串把同事问沉默了。那天的最终结果是补了一段幂等判断。整个过程 SocratiCode 没写一行修复代码，但它把问题和后果全给聊出来了。

这类提问对做 Code Review 的人特别有价值。平时我 review 同事代码，直接说“加个幂等”当然也可以，但同事不知道必要性，下次照样会漏。换成引导式问答，对方是自己想明白的，印象会深得多。

3.2 用一连串问题推演新项目架构

还有一次，我要设计一个订单系统的方案。按我以往的习惯，大概理一下需求就开始写表结构了。这次我尝试先用 SocratiCode 把方案“过一遍脑子”。

我刚把我的粗略想法发给它，它就开始提问了。第一轮比较常规：订单状态机里有哪些状态？哪些操作会引起状态流转？每个流转由哪个角色触发？

我回答完，它接着问：库存是放在下单时锁定，还是放在支付后锁定？如果用户下单后 15 分钟未支付，锁定的库存什么时候释放？释放失败怎么办？

这几个问题直接戳到方案设计的核心争议点。我之前其实都没想好，因为原型阶段嘛，能跑就行。但这些问题不回答清楚，写代码的时候迟早要回头改。

然后它又追了一轮：支付回调和其他操作并发发生时，订单状态怎么保证一致？比如用户看到“已支付”，但系统因为回调延迟还是“待支付”，这时候用户申请退款，要怎么办？

三轮问答下来，我手里多了一张 A4 纸的问题记录。我照着这些问题把答案一个个补上，一份方案文档的骨架已经自然成形了。整个过程它都是在提问，答案全是我自己写的，但出来之后我明显感觉脑子里对这个项目的设计清晰度，比之前任何时候都高。

3.3 拿它带新人，少了很多无效评审

带新人这件事，我一直觉得最累的地方不在于解释代码，而在于让他形成“自问自答”的习惯。新人交上来的代码经常是能跑的，但问两句就露馅。以前我要在 Code Review 会议上逐条问，既费时间又容易打击新人自信。

后来我试了一个办法：要求新人在提交代码之前，先把 SocratiCode 的“教练模式”跑一轮，把问题和自己的回答整理到提交说明里。这个习惯刚开始很痛苦，新人觉得“我找个代码写完就不错了，你还让我答题”。但坚持了大概三周，效果慢慢出来了。

最明显的变化是，他开始主动在代码里处理重复提交和并发问题了。有一回他给自己写的接口加上了防重的逻辑，我问他怎么想到的，他说 SocratiCode 之前问过他“用户手快点两次提交会怎样”，他想起来那段对话，顺手就补上了。

这其实比我们开十次评审会都有效。评审会上的问题是导师给的，他回答完就忘了；对话过程中的问题是 AI 一个个问出来的，他的参与感强很多，记的也牢。

4. 常见问题与排查技巧实录

4.1 AI 提问跑偏了，开始问“哲学问题”

我遇到的最常见问题是，某些模型配置下，AI 会从“编程教练”滑向“人生导师”。比如它会突然问：“你觉得什么样的代码才是好代码？”“你写这个功能的初衷是什么？”这种问题不是说没有价值，但在调试代码的语境里，它只会让人分心。

解决办法是在 Prompt 里加一条明确的上下文边界：只针对当前代码片段或当前需求提问，范围限定在技术实现、质量风险、可维护性上。如果对话已经跑偏，直接输入“回到代码片段，重新提问”，通常就能拉回来。

4.2 被连续追问搞到效率崩溃

SocratiCode 的模式天然比“问一句给一段代码”慢。我试过在赶项目的时候硬用它，结果一个函数讲了二十多轮还没到代码实现，心态直接崩了。

现在我的做法是给对话设置一个轮数上限。比如重逻辑的代码，我允许它问五轮；五轮之后它还没收敛，我就会打断它，让它把剩下所有问题一次性列出来，我挑优先级最高的两三个想清楚，剩下的按默认方案处理。

本质上，SocratiCode 是一个思考工具，不应该把它当成唯一的编码入口。如果你今天赶时间，就用常规 AI 助手快速出活；如果你写的是核心模块、做方案评审、或者提交前过一遍代码，才值得打开引导式对话。

4.3 跨文件多模块审查时，上下文不够用

有一次我想让它帮我审查一个跨三个文件的功能改动。我把三个文件的代码都贴进对话里，结果它的回答开始混乱，问题也变得前后矛盾。原因是它的上下文窗口装不下那么多代码，它自己都记不清前面的内容了。

这种情况我的处理方式是把大模块拆成单文件、单函数来审。一次只贴一段核心函数，让它围绕这一段连续提问。如果想让它理解整体结构，我会先贴一段精简的伪代码或者状态流转描述，然后再继续问。

4.4 和其他 AI 工具的工作流搭配

用过一段时间之后，我自己整理了一套判断标准：什么时候用普通 AI 助手，什么时候用引导式对话。

简单逻辑、CRUD、通用代码片段，直接让补全工具生成就行，不需要过脑子。但凡是涉及异步、并发、状态流转、资金或库存这种敏感操作，或者是你觉得“这块以后可能会出问题”的代码，就值得开一轮 SocratiCode 式对话。

我现在的固定习惯是：新功能写完，提交 PR 之前，自己先用引导模式过一轮核心逻辑。这不是额外的负担，而是替代了以前“自己看一遍代码”的环节，效果甚至更好。

5. 使用心态与我的真实体会

5.1 不要让它变成新的“答辩官”

SocratiCode 用的是苏格拉底式提问，但苏格拉底当年在雅典街头问别人问题，也不是为了把人问倒。这套理念的最终目的是帮你把思路理顺，而不是让你觉得自己什么都不懂。

我第一次用的时候就有过这种挫败感：问什么答什么，答完它还接着问，好像我的设计全是漏洞。后来我调整了心态：被问住的地方，恰恰是我没想清楚的地方，这不是丢人的事，而是提前发现问题的机会。

想通这一点之后，我开始主动把它当作“设计草稿的试金石”。写方案之前先和它聊一轮，把回答记录当作文档的第一版素材。这样一来，方案写的效率反而更高了。

5.2 我自己的判断标准，和一句想分享的话

我现在只要遇到核心逻辑超过五十行、或者涉及异步处理、并发更新、状态机这类场景，就会先让 SocratiCode 式对话过一遍脑子。简单代码一律不用，因为它确实是需要耐心的工具，没必要拿它折腾人。

最后说一桩我自己的事。有一回我赶进度，让常规 AI 助手帮我生成一个调度任务，代码顺利上线，能跑。但过了两周，业务方反映某些任务重复执行了。我打开代码，想了很久才回忆起当时为什么要那样写。后来我用 SocratiCode 的思路把这段逻辑重新梳理了一遍，不是它告诉我要怎么改，而是我在它的追问下，自己说出了当初设计的漏洞在哪里。

从那以后我养成了一个看起来有点反效率的习惯：关键代码不急着让 AI 替我写，先让自己被问住几轮。这个习惯未必适合所有人，但我个人体会是，它比任何代码审查工具都能帮我保持对代码的掌控感。编程这一行，工具永远在变，但“想清楚再动手”这件事，什么时候都不过时。