最近我在折腾 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 它跟普通补全助手到底差在哪我画了个对比表你可以快速感受一下它的定位差异。对比维度常规 AI 编程助手SocratiCode 式的引导工具输出形式直接给代码补全、片段、修复建议问题清单、连续追问、启发式提示对使用者的要求能读懂代码就能用要能回答、能反思、能做决策典型场景写 CRUD、自动补全、生成测试、快速原型需求澄清、方案评审、Bug 定位、代码审查时间成本快分钟级完成偏慢一次对话可能持续十几轮核心价值提升编码速度提升思考质量和代码可解释性注意我说的是“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 替我写先让自己被问住几轮。这个习惯未必适合所有人但我个人体会是它比任何代码审查工具都能帮我保持对代码的掌控感。编程这一行工具永远在变但“想清楚再动手”这件事什么时候都不过时。
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 它跟普通补全助手到底差在哪我画了个对比表你可以快速感受一下它的定位差异。对比维度常规 AI 编程助手SocratiCode 式的引导工具输出形式直接给代码补全、片段、修复建议问题清单、连续追问、启发式提示对使用者的要求能读懂代码就能用要能回答、能反思、能做决策典型场景写 CRUD、自动补全、生成测试、快速原型需求澄清、方案评审、Bug 定位、代码审查时间成本快分钟级完成偏慢一次对话可能持续十几轮核心价值提升编码速度提升思考质量和代码可解释性注意我说的是“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 替我写先让自己被问住几轮。这个习惯未必适合所有人但我个人体会是它比任何代码审查工具都能帮我保持对代码的掌控感。编程这一行工具永远在变但“想清楚再动手”这件事什么时候都不过时。
