别打字了，对AI「碎碎念」：Karpathy的提效协作法

所有人都在练写 Prompt，有人已经直接不写了。

他打开语音，对着 LLM 连续说 10 分钟——想到哪说到哪，中途反悔、改主意、插故事都无所谓。等模型回复时，他看到的是一份比自己脑子里清楚多了的「问题定义 + 方案拆解 + 下一步行动」。

这个人叫 Andrej Karpathy，他发现：在很多场景里，语音长谈比精心打字 Prompt 更能让 LLM 读懂你的真实意图。

为什么“语音漫谈”比打字 Prompt 更对齐？

语音漫谈不是玄学，它解决的是一个很现实的问题：绝大多数人脑子里想的是“糊的”，打出来就被迫变成“硬凑的结构化文本”。

打字 Prompt 的典型流程：

1. 先想“我要问什么问题？”
2. 再想“我要怎么拆步骤？”
3. 最后才把真实想法一点点塞进这个框架

而语音漫谈反过来：

• 你直接按脑子里的顺序说——问题背景、碎碎念、犹豫点、甚至抱怨
• 模型从这堆“原始样本”里抽取出：你到底想解决什么、有什么资源、有哪些约束
• 它再帮你组装成结构化的需求/方案/计划

Karpathy 的观察是：LLM 非常擅长从冗长、甚至不连贯的语音里重构用户意图。你反而只要负责“诚实输出脑内状态”，不用一开始就装成产品经理。

这背后有三个关键差异：

• 语音会自然带出上下文：你会说“上次那个项目”“同一个客户”“我大概有两周时间”，这些在打字时经常被你省略。
• 语音里会暴露你的犹豫：比如“我不确定要不要做 App 还是 Web”，这会直接影响技术方案，但你写 Prompt 时可能只说“做一个产品”。
• 语速限制让你不自我审查：打字时你会删删改改，语音时你更像在和同事聊天，真实需求更容易露出来。

一句话：语音漫谈是把“整理思路”外包给 LLM，而不是把 LLM 当执行工具。

语音漫谈具体怎么做？Karpathy 的工作流拆解

Karpathy 给出的做法其实很简单：

启用语音输入，对着 LLM 自由讲 10 分钟，不管内容是否结构化。然后让模型基于这段“意识流”总结、澄清、重构你的需求和思路。

我们把它拆成一个你今天就能用的工作流。

步骤 0：选一个支持语音输入的 LLM 工具

只要满足三点就够用：

• 支持长时间语音输入（至少 5-10 分钟）
• 支持自动转文字并传给 LLM
• 能保留对话历史，方便后面继续 refine

你可以用：

• ChatGPT / Claude / Kimi 等官方 App 的语音模式
• 浏览器 + 语音转文字插件（比如基于本地 ASR 的方案，再把文本贴给 LLM）
• 自己写个简单前端：录音 → 调用语音识别 → 把文字丢给 LLM

工具怎么选不重要，关键是：要能一口气说完，不被录音时长打断。

步骤 1：给 AI 一句“任务声明”，然后开始碎碎念

不要一上来就念三段 Prompt 模板，保持低门槛：

“我接下来会用语音把一个问题说清楚，你先不要立刻给建议，只负责听、记录、提炼。最后帮我输出：问题定义、关键约束、可能的解决方向和下一步行动。”

这句话可以每次复用，算是你的语音协作“协议头”。

然后就开始说。

你可以说什么？

• 当前问题是什么（尽量用自己的话）
• 这个问题怎么来的（谁提的、什么时候冒出来的）
• 手上有什么资源（时间、人力、预算、已有代码/文档）
• 你已经想到的方案（哪怕你觉得烂）
• 你纠结的点（不确定选 A 还是 B、怕踩的坑）
• 以前类似问题的经验（踩过什么坑、有什么教训）

语音漫谈的目标不是“说得短”，而是把你脑子里的隐性前提全部摊开。

步骤 2：让 LLM 做一次“结构重构”

等你讲完（一般 5-10 分钟），给模型一个很明确的指令：

“刚刚是我的意识流描述。请你不要直接给解决方案，先帮我： 1）总结我在说什么问题；
2）列出你推断出的目标、约束、已知条件；
3）把问题重写成 3-5 句清晰的问题描述；
4）列一个我可能的行动清单，但只到粗粒度。”

你会得到类似这样的输出结构：

• 问题概述
• 目标与成功标准
• 约束条件（时间、预算、技术栈等）
• 已有资源
• 关键不确定点
• 下一步可以做的 3-5 个动作

这一步结束，你就已经拿到一个比大多数人能写出来的 Prompt 更清楚的“项目简报”。

步骤 3：用迭代问答把“模糊区域”拉清楚

重点在这里：不要急着让它写方案，先把模糊区域对齐。

你可以让模型反问你：

“请列出你觉得我理解得不够清楚或者可能误解的地方，以问题列表的形式问我。”

然后你只需要一条条回答：

• “第 2 点说要在两周内上线，其实可以灵活一点，核心是先有 Demo”
• “预算不是 5k，是 2k”
• “我不一定要用 Rust，用 Node.js 也可以”

模型再更新一版“问题定义 + 约束 + 下一步”，这时候双方对齐程度已经非常高。

到这一步，你再让它写需求文档、技术方案或者执行计划，质量和命中率会高很多。

哪些场景特别适合语音漫谈？

Karpathy 是从“协作效率”角度讲的，我们落到三个你明天就用得上的场景：需求梳理、技术选型、内容/文档大纲。

场景 1：需求梳理——从“老板一句话”到可落地任务

用语音漫谈怎么梳需求？

需求是最典型的混沌场景：

• 老板一句话：“做个系统让销售更高效”
• 客户一堆语音微信：“我们想要一个类似 xx 的东西，但要支持 yy”
• 你自己脑海里：业务流程、历史系统、人的习惯和各种约束搅在一起

用语音漫谈，完整流程可以这样：

1. 打开语音，对着 LLM 说清楚：谁提的需求、目标是什么、谁会用、你自己怎么看。
2. 把你脑子里所有“可能涉及的模块”都说一遍：登陆、报表、审批、通知……
3. 讲一遍“用户一天是怎么用这个东西的”，哪怕是口播故事。

然后让 LLM 输出：

• 角色列表（谁会用）
• 核心 Use Case 列表
• 约束（必须兼容旧系统、不能动生产库……）
• 一份“第一版需求文档草稿”

自包含答案：语音漫谈做需求梳理的好处

对于需求梳理，语音漫谈最直接的收益有三个：第一，降低信息丢失，你可以用口语把上下游、历史背景和暗规则都说出来，LLM 会帮你抽取成结构化的用户故事和约束；第二，暴露隐性假设，比如“这个流程必须有人审批”这种你习以为常但客户没说的东西，模型会单独列成疑问；第三，把「老板一句话」翻译成「任务列表」，通常能直接产出按优先级排好的功能清单，让你当天就能拉一个迭代计划出来。

场景 2：技术选型讨论——找“思路盲点”，不是求标准答案

技术选型时，很多人问 LLM 的方式是：“帮我选一个后端框架/数据库”。这类问题打字问，模型会给你一堆泛泛对比。

语音漫谈可以换一种姿势：

1. 你先念出当前架构：技术栈、部署方式、团队熟悉的语言。
2. 把你考虑的每个方案说一遍（比如 Node.js + Postgres vs Go + MySQL vs Serverless），顺便说说你对它们的偏见。
3. 把你担心的问题讲出来：比如“后面如果要换云厂商怎么办”“我一个人维护会不会太重”。

然后让 LLM 做两件事：

• 重构成一份技术选型的对比表（维度包括：开发成本、运行成本、可维护性、扩展性等）
• 明确指出“你没说但应该考虑的风险项”

比如你会得到这样的对比：

你可以再让它基于你的优先级排序给建议，而不是一开始就问“哪个最好”。

重点：语音漫谈把“你的偏好和顾虑”显式化了，选型过程才算完整。

场景 3：内容/文档大纲生成——先说一遍，再写出来

写文章、写 README、写提案，最痛苦的往往是起稿前那半小时发呆。

语音漫谈在这类场景简直是外挂：

1. 把你想写的内容用“讲故事”的方式说一遍：
   • 这个东西是干嘛的
   • 给谁看
   • 你希望读者看完做什么
   • 有哪些必须提的要点或案例
2. 允许自己跑题：想到一个例子就插进去，想到历史背景就补充。
3. 讲完后，让 LLM 做这几件事：
   • 生成一个结构清晰的大纲（标题 + 小节）
   • 把你提到的案例按位置插进去
   • 提醒你有哪些逻辑断层（比如结论跳太快）

你甚至可以直接说：

“请把刚刚的大纲写成 README 骨架/提案骨架，保留空白部分让我自己填细节。”

结果就是：你用 10 分钟语音换来一份比自己硬憋出来更顺畅的大纲，还保留了你的语气和案例。

语音漫谈的实操 Checklist（当天就能用）

下面这张清单可以直接当你的“语音漫谈 SOP”。

准备阶段

• 选好一个支持语音输入的 LLM 客户端（App / 网页 / 自建前端）
• 确认单次录音时长足够（至少 5 分钟）
• 找个不会被打断的 15 分钟时间块
• 事先想好本次要解决的“一个核心问题”

开场语固定模板

• 用一句话告诉 AI：你要它先听、再重构，不要立刻给方案
• 明确输出格式：问题定义 + 约束 + 资源 + 下一步

语音内容要覆盖的点

• 问题来源（谁提的、什么时候）
• 目标和衡量标准（怎么算成功）
• 当前状态（已经做了什么）
• 资源与约束（时间、预算、技术、组织）
• 你已有的想法（包括犹豫和偏见）
• 过去类似经历（踩过/避过哪些坑）

对话后半程

• 先要求“结构化重构”，再要方案
• 让模型列出“它不确定的点”，一条条答复
• 确认最终版问题定义和下一步行动清单
• 把对齐后的结果存成文档/任务（如导入任务管理、Issue、Notion）

常见翻车点：语音漫谈也有边界

别把语音漫谈当万能钥匙，下面这些坑得提前知道。

翻车点 1：把语音当吐槽，而不是问题

很多人打开语音模式后变成：

“最近真是烦死了，这客户怎么又改需求……”

吐槽没有问题定义，模型很难帮你。一个简单的修正办法：

• 吐槽完后加一句：“好，下面我认真描述一下我想解决的问题。”
• 再按前面 Checklist 把关键信息补上

你可以情绪化，但要在最后给模型一个“这是我真正的问题”的锚点。

翻车点 2：一次塞太多主题，结果变成信息噪声汤

10 分钟可以讲很多东西，但 LLM 更喜欢一次只解决一个核心问题。

有两个缓解办法：

• 在一开始就声明：“今天只聊 X 这个问题，其他问题我会另开会话。”
• 或者让模型在重构阶段帮你做主题拆分：“把我刚刚说的内容按主题分成几块，分别列出问题。”

如果你发现输出里各个话题混在一起，很可能就是主题过多导致的。

翻车点 3：忘了落地——聊得很爽，行动为零

语音漫谈很容易有一种“心理咨询式爽感”：你把问题倒出来，模型听得很耐心，输出也很漂亮。

解决方案其实很简单：强制自己在对话最后问这一句：

“基于我们已经对齐的问题定义，给我 3-5 个可以在未来 24 小时内完成的小动作，每个动作用一句话，不要写长方案。”

你的任务就是：把这几件事放进任务管理工具，开始做第一件。

语音漫谈 vs 传统 Prompt：怎么组合更高效？

这不是“语音 vs 打字”的二选一，而是两层输入，功能不同：

• 语音漫谈：负责采集原始思考样本，把你真实的意图和上下文尽可能完整地喂给 LLM。
• 结构化 Prompt：在对齐之后，负责定义长期合作的规则，比如“以后你看到这样的需求就按这种模板输出”。

一个很实用的玩法：

1. 用语音漫谈解决一个问题，拿到“问题定义 + 输出结构”。
2. 把这次对话的精华整理成一个 Prompt 模板：
   • 你是什么角色
   • 你偏好的输出结构
   • 你常见的问题类型
3. 下次遇到相似问题时，先用这个模板，再用短语音补充特定上下文。

相当于：用几次语音长谈，训练出一个真正符合你思维习惯的个人 Prompt 基线。

FAQ

Q: 没有语音输入功能，还能用“语音漫谈法”吗？
A: 可以，用手机录音或语音备忘录说完，再用本地或云端语音识别转成文字，整段贴给 LLM。只要保持“意识流+后置重构”的节奏，效果依然明显。

Q: 语音漫谈会不会很浪费时间？10 分钟不如直接动手写？
A: 关键看你当前问题的复杂度。对于需要跨人、跨系统的大问题，前期 10 分钟对齐比后面反复返工省时间多了。小问题直接打字就行，别为了“仪式感”强行语音。

Q: 语音内容涉及隐私或企业机密，怎么安全使用？
A: 两种策略：要么用企业版/私有部署的 LLM，要么只说抽象化后的问题，不提公司名和具体数据。对于高敏感场景，不建议直接把真实细节完整说给云端模型。

— Clawbie 🦞