1 没有 " 超级提示词 "
很多人用 AI 写东西，总想找个“超级提示词”，指望回车一敲，一篇长文或者视频脚本就直接搞定。
但做过软件工程或者写过论文的人都知道：
现实中没有单次交付的瀑布模型，持续交互和敏捷迭代才是常态。
写论文或者做软件，谁也不会一开始把参数全部定死，然后关门搞一个月直接交付。中间必须有好几轮交互和状态调整。做计划的时候，就该把它拆成几个阶段。
面对散乱的书摘和随手记的感触，直接丢给大模型，往往只能得到语言通顺、排版工整但缺乏灵魂的套话。大模型本来就是概率模型，任务越宏观，给出的越是全网平均水平的废话。深度创作里真正值钱的，是作者独特的经历、真实的踩坑和主观体会。这些隐性知识很难一开始通过一段提示词说清，需要通过具体问题一步一步逼出来。
2 从“人问 AI 答”到“AI 问人答”
常规的 AI 玩法是人问、AI 答。这种单向问答里，AI 很容易信口开河，或者顺着用户的话换个词扩写，说一堆正确的废话。
在深度创作场景下，可以反过来试一下：AI 问，人答。也就是“苏格拉底式提问法（Socratic Questioning）”。
人和 AI 的分工可以拆得很清楚：
AI 负责搭骨架与提问：检索客观背景、梳理逻辑框架，按阶段逐步追问；
人负责提供灵魂与决策：提供具体的个人经历、真实痛点，在每个关口负责确认和拍板。
它是人类沿用了几千年、最顶级的“知识重构（Knowledge Restructuring）”和“隐性知识显性化（Tacit Knowledge Extraction）”工具。只要目标是把凌乱、主观的信息变成有结构、有灵魂的输出，它几乎能用在任何领域。
3 技术落地的示例
以制作深度讲书视频或长文为例，整个流程可以拆成三轮交互：
阶段一：背景补全与痛点打捞（寻找高光交叉点）
输入：零散的书籍摘抄、阅读中记下的主观感受与思考碎片。
AI 任务：
检索作者生平、写作背景以及公认的核心观点；
对比“书的核心观点”和“个人笔记”，找出 2~3 个最具张力的碰撞点。
人类决策：
删掉无趣的泛化背景，确认或修正提取出的核心共鸣点。
阶段二：结构骨架搭建（禁止直接写正文）
输入：第一阶段确认的核心交叉点与主题范围。
AI 任务：
搭建结构大纲（开头 Hook $\rightarrow$ 核心故事/论证块 $\rightarrow$ 总结升华）；
标明每段的叙事目的、素材来源和情绪走向，坚决不写具体台词或正文。
人类决策：
调整叙事节奏和段落权重，删掉干瘪部分，强化核心重点。
阶段三：分段递进追问（一次只问一个问题）
核心约束：严禁模型一次性输出全篇，每次交互严格限制在 1~2 个具体问题。
交互逻辑：
AI 锚定具体笔记深挖。比如“习惯坚持困难”这个话题，AI 不去讲大道理，而是追问现实里具体卡在哪：定了闹钟要早睡，结果又报复性刷手机，那种纠结是什么感觉。
人用语音或大白话直接给事实和感受。
AI 吸收真实细节，润色重构为连贯段落，再由人拍板。
这样，内容骨架由逻辑驱动，填充的血肉则始终来自创作者真实的认知资产。
4 用苏格拉底做审计
除了协同创作，苏格拉底提问在日常复盘和输出中还有个关键作用：反向审计自己的观点，避免把偶发噪音当成普遍规律。
在日常总结中，很容易出现两类偏差叠加：
人喜欢上纲上线：吃了一次亏或偶然做成一件事，就急着总结一条“人生铁律”；
大模型擅长强行合理解释：哪怕塞给它一堆完全随机的事件，它也能包装出一套严密的“底层逻辑”。
两者叠加，常常是自己在骗自己。
所以在成稿或提炼规则前，可以让苏格拉底提问反过来用，让 AI 当一个唱反调的冷面审计员：
查归因：这个结果到底是方法有效，还是纯粹踩中了环境的随机运气？
找边界：这个结论在什么情况下会彻底失效？
看反例：论证时有没有选择性忽略相反的案例？
逼问两轮，把情绪和偶发噪音剔掉，最后沉淀下来的才是经得起考验的确定性经验。
5 常见应用场景
苏格拉底式提问不只用来讲书，日常很多输出都可以用：
经验复盘：把流水账变成真经验。让 AI 逼问：当时为什么选这个方案？真正起作用的是哪一步？如果换个环境，这招还灵不灵？
商业方案打磨：把脑热想法理成闭环。让 AI 泼冷水：谁真会为此买单？最卡手的一步在哪？算下来成本撑得住吗？
跨领域知识串联：把两堆死知识碰出新想法。让 AI 找交叉：这两件事底层有没有相通的逻辑？能不能用 A 的办法去解 B 的难题？
技术文档去说明书味：把冷冰冰的干货讲成好故事。让 AI 挖细节：学这个技术时踩过最大的坑是什么？当时怎么排查出来的？实际落地遇到了什么摩擦？
6 工具与参考
这套方法不依赖什么专门的工具。在 GitHub 上搜 Socratic 或者苏格拉底，能翻到一些上百 Star 的提问法项目，可以参考它们的提问清单和追问模板。
我觉得它是一个思维工具，而不是具体的某个 Skill，从上面的示例可以看到，不同的场景问题也不相同。不如把自己的场景和需求给大模型，让它帮忙写一个，可能比现成的更合适。
