夜雨聆风点击上方 程序员成长指北，关注公众号
回复1，加入高级Node交流群
前言
AI 编程演示看似高效，实则在训练被动性。苏格拉底提示法以辩论、凝练、测试先行、引导实现、双重验证、持续集成六个阶段，将 AI 从听命的神谕变成需要追问的协作者。别告诉模型该做什么，追问它，直到你理解每一行代码。今日文章由 @Jason Mars 分享，前端早读课@飘飘编译。
译文从这开始～～
你所看过的每一场模型演示 —— 无论来自 Anthropic、OpenAI 还是其他任何公司 —— 都遵循着同一套剧本。有人输入一个请求，模型生成一段令人惊艳的结果，观众报以掌声。作为模型的展示，这无可挑剔。但对工程师来说却是个糟糕的工作流程。
我在编译器、语言运行时和分布式系统领域深耕多年 —— 在这些领域里，含糊其辞的东西一碰到现实就会土崩瓦解。当 AI 编程助手横空出世时，我也和所有人一样一头扎了进去。毕竟演示看起来干净利落，赏心悦目。
花了比我愿意承认的更长时间，我才认清这个模式：这和开发者从 Stack Overflow 上照搬代码却不求甚解，本质上如出一辙。演示的形式在训练人的被动性。它以牺牲理解为代价，换取产出效率的最大化。这种取舍在生产环境中根本站不住脚。
于是我探索出了一套不同的路径。我称之为苏格拉底提示法 —— 一套结构化的工作流程，将 AI 视为需要反复追问的协作者，而非言听计从的神谕。其核心原则是：不要告诉模型该做什么，而是不断追问，直到双方达成共识，然后用测试来验证它的交付。 这不是一堆提示词技巧的合集，而是一套完整的开发方法论 —— 而且它会产生复利效应。每一次对话都在打磨设计、暴露隐含假设，并沉淀出一套能够证明实现正确性的测试用例。
完整工作流程一览
发现问题 ↓ 1. 苏格拉底式辩论 ↓ 2. 方案凝练 ↓ 3. 测试先行锚定 ↓ 4. 引导式实现 ↓ 5. 双重上下文验证 ↓ 6. 持续集成与文档沉淀以下是每个阶段的详细阐述，以及其背后的工程考量。
第一阶段：苏格拉底式辩论
人的本能反应是上来就发号施令。但经验告诉我，抵住这个冲动是值得的。不妨用一个问题来开场：
"如果你想实现 [具体需求]，你会怎么做？"
我心里早已有了自己的思路 —— 这恰恰是关键所在。我提问不是因为毫无头绪，而是在探测模型的推理路径，找出它的理解与我的理解之间的偏差。有时候，这个偏差暴露的是模型的盲区；有时候，暴露的是我自己的。两者都值得发现。
你： "如果你想实现X，你会怎么做？" 模型：提出方案A 你： "关注点分离怎么考虑？这部分应该放到一个独立的处理阶段里。" 模型：重新审视，阐释不同方案的权衡取舍 你： "为什么选这个方案，而不是沿用模块Y中已有的模式？" 模型：给出更深层的推理，可能会浮现新的洞察 你： "带我过一遍这个方案的失败场景。" 模型：调整方案，或给出充分的理由为原方案辩护 ↻ 反复迭代，直到双方对齐苏格拉底式提问的艺术
有几类问题总能引出最有价值的对话：
关键在于引导而非指令。通常我心里已经有了想要的修正方向 —— 但通过提问而非直接告知，我迫使模型自己推演整个问题，这往往会浮现出我未曾想到的考量。不止一次，模型反驳了我的直觉判断，而且它是对的。如果你只是发号施令，这种事永远不会发生。
留意你的上下文窗口
苏格拉底式辩论价值极高，但也极其消耗 token。务必把控节奏。
0-30% 开放式辩论 30-50% 开始收敛 50-60% 锁定方案 60-80% 测试策略 80%+ 压缩上下文或开启新会话在上下文消耗达到 50-60% 时就应完成收敛。我有过好几次惨痛教训 —— 整个窗口都烧在了一个精彩但跑偏的讨论上，最后一无所获。辩论是为方案服务的 —— 而不是反过来。
第二阶段：方案凝练
一旦达成共识，就让模型把方案写下来。这一步没有商量余地。上下文中留存的方案是一份持久化的参照物，它让双方都无法糊弄 —— 而且在上下文压缩时，它的存活率远高于一场冗长散漫的对话。
方案必须涵盖以下内容：
改了什么，改在哪里 为什么选择这个方案（辩论阶段应该已经充分讨论过了） 实现顺序与依赖关系 关键风险及应对策略
这与你在和另一位工程师进行设计评审时产出的文档别无二致。模型需要一份规格说明来指导执行，而你需要一份规格说明来追踪问责。
第三阶段：测试先行锚定
方法论到这里才真正亮出了獠牙。在任何实现代码之前，先把测试写出来：
"针对这个方案，测试用例应该长什么样？"
然后围绕测试策略展开辩论。追问覆盖率的盲区，质疑隐含假设，探查边界情况。如果讨论溢出到了下一个上下文窗口也无妨 —— 测试已经存在于代码仓库中，任何上下文重置都不会让它们消失。
铁律：每一条测试都必须失败
起草测试用例 ↓ 所有测试都失败了吗？ ↓ ↓ 是 有的通过了 ↓ ↓ 提交测试到分支 追问：为什么这条测试会通过？ ↓ 修正测试，或者更新你自己的认知这就是经典的 "红 - 绿 - 重构" 循环，移植到了人机协作的语境中。在实现代码动笔之前，每一条测试都必须是失败的。如果某条测试在没有任何实现的情况下就通过了，只有三种可能：
测试是恒真的 —— 它什么都没测 这个行为已经存在于你不知道的某个角落 测试本身有 bug，导致它空洞地通过了
遇到这种情况，我会追问模型："这条测试为什么通过了？实现代码还一行都没写呢。" 我不止一次通过这种方式捕捉到了微妙的架构误解 —— 模型可能会揭示 "这个行为其实已经存在于模块 X 中了"，而我忽然对系统的理解就比五分钟前更深了一层。
当所有测试都如预期般失败，且与方案保持一致时，只提交测试，不提交任何实现代码。这就是契约。从这一刻起，一切工作只有一个目标 —— 让它们变绿。
第四阶段：引导式实现
驱动模型按照方案逐步推进。这里的关键词是驱动。
模型开始实现 ↓ 审读模型的产出 ↓ 是否符合方案？ ↓ ↓ 是 否 ↓ ↓ 让它继续 叫停模型 ↓ 讨论偏差 ↓ 有新收获吗？ ↓ ↓ 是 否 ↓ ↓ 更新方案 拉回正轨 ↓ 所有测试通过了吗？ ↓ ↓ 是 否（继续迭代） ↓ 进入验证阶段别把它当老虎机玩
当模型做出了意料之外的事情，立刻叫停。不要放任它继续跑，指望它自己兜回来 —— 那是演示驱动的被动心态在作祟。每一次偏离都应该是一次对话：
"你为什么改了这个文件？这不在方案里。" "这个做法和我们之前讨论的不一样。带我过一遍你的思路。" "这看起来像是绕过了问题。真正该怎么修？"
这个阶段之所以能产出成果而不令人抓狂，原因在于：你有测试作为安全网。 测试定义了 "完成" 的标准。所以你可以放心地探索。我有过好几次这样的经历：一个二十分钟的 "跑题" 让我对问题域的理解，比原本那个任务本身带来的还要多。这不是浪费时间 —— 这是对深入理解系统所产生的复利回报。
探索完毕后，把模型拉回方案 —— 或者根据新的认知修订方案。
上下文策略
在实现阶段不必纠结上下文的消耗。测试已经提交了 —— 无论怎么重置它们都还在。如果上下文耗尽，直接开一个新会话：
"这是方案：[方案内容]。这是当前失败的测试：[测试文件]。请继续实现。"
测试就是锚。其他一切都可以恢复。
第五阶段：双重上下文验证
所有测试通过了。现在来验证成果 —— 这个技巧值得你细细品味。
用两个独立的上下文对实现进行交叉审查：
上下文一：构建者 上下文二：全新的审阅者 （写代码的那个模型） （一个全新的模型，没有任何历史） ↓ ↓ 追问："你做的所有改动 追问："请对这个分支中的 都是真正的长期修复， 实现做一次深度审查。" 还是有些只是权宜之计？" ↓ ↓ └──────── 对比与推敲 ────────┘ ↓ 满意 ←→ 发现问题 ↓ ↓ 推送并进入CI 回退 / 修复 / 重新迭代为什么需要两个上下文？
写代码的那个模型，其上下文中天然带有沉没成本偏差。它花了整整一个会话来构建这些东西 —— 它会倾向于维护自己的决策。而一个全新的上下文没有这种包袱，它纯粹基于代码本身的质量来评判。
在构建者上下文中，问它：
"你做的所有改动都是真正的长期修复，还是其中有些只是权宜之计？"
这充分利用了模型完整的会话历史。它知道自己在哪里偷了工 —— 因为做决定的时候它就在场。直接问它的时候，它的坦诚程度令人意外。
在全新上下文中，问它：
"请对这个分支中的实现做一次深度审查。"
这是不带偏见的第二意见。重点关注两份审查之间的分歧 —— 那些分歧恰恰就是需要关注的地方。必要时回退到任意历史状态，反复迭代，直到这个分支达到你的标准。
第六阶段：持续集成与文档沉淀
推送代码，迎战 CI 的失败。CI 是最终的裁判 —— 没有捷径，不接受 "在我机器上是好的"。
至于文档，在 PR 变绿之后，让模型充当分析师：
"分析这个分支中的所有变更，排查文档中所有需要更新的地方，然后完成这些改进。"
把这作为一个独立的环节来做效果很好。模型能够追踪整个代码库的完整 diff，找出过时的文档 —— 在这件事上，它往往比人工排查更加彻底。
完整流程总览
开始 ↓ 第一阶段：苏格拉底式辩论 · 提问："如果你想实现X，你会怎么做？" · 质疑、探查、辩论 · 在上下文消耗50%时完成收敛 ↓ 第二阶段：方案凝练 · 让模型把方案写下来 · 审查：改什么、改哪里、为什么、顺序、风险 ↓ 第三阶段：测试先行 · 根据方案起草测试用例 · 围绕测试策略展开辩论 · 确认所有测试都失败 · 只提交测试 ↓ 第四阶段：引导式实现 · 驱动模型按方案推进 · 逐行审读，偏离即叫停 · 探索、学习、调整 · 所有测试变绿 ↓ 第五阶段：双重上下文验证 · 构建者上下文：有没有权宜之计？ · 全新上下文：深度审查 · 对比、推敲、修复 ↓ 第六阶段：交付 · 推送代码，迎战CI · 生成文档更新 ↓ 完成为什么这套方法行得通
一、你始终掌控全局
模型是协作者，不是自动驾驶。每一步你都在追问、引导、学习。提交的每一行代码你都心中有数，因为你亲历了产出它的那场对话。不会出现 "我不知道这段代码干嘛的，反正是 AI 写的" 这种情况。
二、测试即契约
先提交测试，意味着 "完成" 有了客观的定义 —— 它经得起上下文重置，扛得住模型幻觉，也不怕你自己的理解在过程中不断演变。测试不关心对话内容 —— 它只关心行为。这就是让其他一切成为可能的那根锚。
三、每一次交互都在积累复利
多数 AI 工作流追求的是速度。而这套方法追求的是理解。苏格拉底式的追问、对测试的审讯、双重上下文的审查 —— 这些环节都在制造学习的契机，让你获得此前不曾拥有的认知。
演示驱动的方式单次会话更快。但这套方法会产生复利。每一次会话都在磨砺架构直觉，每一场辩论都在加深对代码库的理解。假以时日，"借助 AI 思考" 和 "把思考交给 AI" 之间的分野，将成为这个领域中最重要的能力分水岭。
速查卡片
关于本文译者：@飘飘作者：@Jason Mars原文：https://blogs.jaseci.org/blog/2026/03/10/socratic-prompt-method/
我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。
“分享、点赞、在看” 支持一波👍
