Vibe Coding实战：不懂就问，和AI沟通的正确姿势

引言：不懂就问，不丢人

在Vibe Coding的实践中，很多人会遇到一个尴尬的处境：AI提出了一套技术方案，列出了一堆变量名、文件路径和英文术语，但你看不懂。怎么办？答案很简单——问。

Vibe Coding是2025年由前特斯拉AI总监Andrej Karpathy提出的编程范式，核心理念是"完全沉浸在氛围中，拥抱指数级的东西，忘记代码的存在"。开发者不再逐行编写代码，而是通过自然语言向AI描述需求，由AI生成代码实现。这种方式与传统的低代码/无代码平台有本质区别——低代码平台通过预制组件和可视化拖拽来降低门槛，开发者仍然在"搭建"的思维框架内工作；而Vibe Coding则完全跳出了代码层面，开发者只需要关注"我要什么"而非"怎么实现"。这种范式大幅降低了编程门槛，使非专业开发者也能构建软件产品，但同时对需求表达能力和方案审查能力提出了更高要求——你不需要会写代码，但你必须能判断AI给出的方案是否正确，这正是"追问能力"在Vibe Coding中如此重要的原因。

正如UP主Paul所说："毕竟AI就是AI，问他什么咱也不丢人。"这期内容展示了一个完整的案例：如何通过反复追问，把AI模糊的技术方案变成自己能理解、能把控的实施计划。

需求背景：实现台词的逐句修改

这次的需求场景是一个AI配音/剧本工具。当前的问题是：台词经过剧本分析定型后，就无法再修改了——不能改单句，不能改几个字，完全锁死。Paul希望实现一个"可以变更单句台词"的能力，同时还要处理后续的音频合成和字幕同步问题。

要理解这个需求的复杂性，需要了解AI配音工具的典型技术链路。一个完整的AI配音系统通常包含四个核心环节：首先是剧本解析（Script Parsing），将完整剧本拆分为以角色为单位的台词序列，识别说话人、台词内容和场景上下文；然后是语音指导生成（Voice Direction Generation），通过大语言模型分析每句台词的情感基调、语速节奏、重音位置、停顿时长等表演参数，生成一份类似"导演指令"的结构化数据；接着是TTS语音合成（Text-to-Speech），将文本和指导参数一起送入语音合成引擎（如ElevenLabs、Fish Audio等），生成带有情感表现力的语音片段；最后是音轨拼接与字幕同步，将所有角色的语音片段按时间线拼接成完整音频，并生成与语音精确对齐的字幕文件（通常是SRT或ASS格式）。这四个环节环环相扣，修改其中任何一个节点都可能引发连锁反应——改了台词文本，指导信息可能不再匹配；重新合成了语音，音频时长会变化；时长变了，后续所有台词的时间轴和字幕都需要重新计算。这正是Paul这次需求复杂性的根源。

他给AI的指令遵循了固定的格式：

• 扫描全局代码，收集相关信息
• 明确当前限制（台词不可变更）
• 说明目标功能（逐句修改+音频重新合成）
• 要求先调研再出方案

AI完成调研后，给出了一个涉及7个文件修改的方案。但问题来了——Paul看不懂。各种链路、变量、文件名，完全想象不出实际的用户体验是什么样的。

第一轮追问：让AI用人话解释

Paul直接说："我没看太懂，我现在想象不出来这个台词在哪改，改了之后会发生什么。"

AI随即切换到了用户视角的描述：

1. 双击台词卡片 → 变成可编辑状态
2. 保存修改 → 合成按钮亮起
3. 点击合成 → 利用现有接口重新生成音频
4. 后端自动处理 → 完成音轨拼接

这样一解释，整个流程就清晰了。这里有个关键技巧：当你看不懂技术方案时，让AI从用户操作流程的角度重新描述，比盯着代码逻辑有效得多。这种方法在软件工程中被称为"用户故事"（User Story）思维——用"作为[角色]，我想要[功能]，以便[价值]"的结构来描述需求，天然地将技术实现翻译为人人都能理解的业务语言。

第二轮追问：发现方案漏洞

理解了基本流程后，Paul立刻发现了一个严重问题：台词修改后，声音指导和表演指导去哪了？

这是一个非常关键的质疑。在现代AI语音合成系统中，单纯的文本输入只能生成机械式的朗读效果，听起来就像早期的导航语音一样生硬。为了让合成语音具有表现力，系统需要额外的"指导信息"（Guidance/Direction），这些信息构成了一个多维度的表演参数空间：情绪标签（如惊喜、愤怒、悲伤、讽刺等，有些系统支持混合情绪如"70%悲伤+30%愤怒"）、语速控制（整句或分段的语速系数）、重音标注（哪些词需要强调）、停顿位置（句中的自然停顿和戏剧性停顿）、以及音色微调（如沙哑、颤抖、低语等特殊音色效果）。这些信息通常由大语言模型根据上下文语境自动生成——模型会分析台词在剧情中的位置、角色的性格设定、前后台词的情感走向，然后输出一份结构化的"导演指令"。如果台词内容发生变化但指导信息未同步更新，就会出现"文不对情"的问题——比如原台词是"我恨你"配了愤怒的指导，改成"我原谅你"后如果指导信息不变，合成出来的语音就会用愤怒的语气说"我原谅你"，效果完全错乱。

AI承认之前没考虑到这一点，随后给出了两个路径：

• 路径A：修改台词后，通过大语言模型重新生成指导信息
• 路径B：只改台词文本，其他标注不动，用户自己手动调整

Paul果断选A——"像我这么懒的人，让我手动处理绝对不行。"

这个选择背后其实涉及一个经典的产品设计权衡：路径A的自动化程度更高，用户体验更好，但每次修改都需要调用大语言模型API，会产生额外的延迟（通常几秒到十几秒）和费用；路径B响应更快、成本更低，但把复杂度转嫁给了用户。对于面向普通用户的产品，路径A几乎总是更好的选择——用户愿意多等几秒换取"不用动脑"的体验，这也是为什么现代SaaS产品普遍追求"零配置"和"开箱即用"的设计哲学。

第三轮追问：确认技术实现方式

方案确定后，还有一个关键的实现细节需要对齐。AI说要新增一个"轻量级的tool类（工具类）"，但Paul的理解是应该新增一个agent。

在AI应用开发中，Agent（智能体）和Tool（工具）是两个容易混淆但本质不同的概念。Tool通常是一个执行特定功能的代码模块，比如调用外部API、处理数据格式转换、执行数据库查询等，它本身不具备决策能力，只是被动地接收输入、返回输出，类似于一把锤子——你告诉它敲哪里，它就敲哪里。而Agent则是一个拥有独立prompt（提示词/系统指令）的智能决策单元，它能理解上下文、做出判断、规划执行步骤，并根据需要调用多个Tool来完成复杂任务，更像是一个有自主意识的工人——你告诉它目标，它自己决定用什么工具、按什么顺序完成。在当前主流的AI应用框架（如LangChain、AutoGen等）中，一个Agent通常由三部分组成：系统prompt（定义角色和能力边界）、可调用的Tool列表、以及记忆/上下文管理机制。在Paul的项目架构中，每个Agent对应prompts目录下的一个独立prompt文件，具有特定的角色定位和能力边界——比如一个Agent负责剧本分析，一个负责语音指导生成，一个负责音频合成调度。新增一个Agent意味着引入一个新的"AI角色"，需要精心设计其prompt、定义其职责范围；而新增一个Tool只是给现有Agent多一个可调用的"工具"——两者的架构影响完全不同。

两人说的"agent"完全不是一回事。Paul赶紧澄清："我说的agent是在prompts目录里面的，一个prompt对应一个agent，目前是三个，你应该新增第四个。"

AI这才对上号："是是是，会增加第四个。"

这个例子特别典型——同一个术语，你和AI的理解可能完全不同。如果不追问清楚，AI按照它理解的"工具类"去实现，和你期望的"新增一个prompt agent"可能差了十万八千里。这种术语歧义在AI辅助开发中极为常见，因为同一个技术词汇在不同框架、不同项目中可能有完全不同的含义——"agent"在LangChain中是一种特定的抽象类，在AutoGen中是另一种，在Paul的自定义架构中又是第三种。用具体的文件路径和目录结构来锚定含义，是消除歧义最有效的方式。

实用技巧总结

语音输入的容错性

Paul提到一个有趣的细节：用语音输入和AI对话时，很多专业术语（如LLM）可能被识别成奇怪的文字。但如果你用的是DeepSeek，它对错别字的容错能力很强，基本都能理解你的意图。这背后的原理与模型的训练数据和tokenizer（分词器）设计有关。DeepSeek在中文语料上的训练更为充分，尤其是在包含大量口语化表达、网络用语和非标准文本的数据集上进行了优化，使其对拼音近似（如"模型"被识别为"魔形"）、形近字替换（如"参数"被识别为"残数"）、以及同音字混淆（如"LLM"被识别为"挨了挨木"）等常见语音识别错误建立了更强的语义映射能力。从技术角度看，这种容错能力来源于模型在预训练阶段接触了大量"带噪声"的文本——社交媒体上的错别字、方言转写、语音转文字的错误输出等，使模型学会了从不完美的输入中推断正确意图。相比之下，GPT和Claude等模型的中文训练数据中，规范文本的比例更高，对非标准输入的鲁棒性相对较弱，可能因为一个关键术语的错别字就完全误解用户意图。

三个核心原则

1. 看不懂就问：不要假装理解了就让AI开干，后面返工成本更高。在Vibe Coding中，一次沟通不清导致的错误实现，可能需要多轮对话才能修正，而且AI在修改已有代码时引入新bug的概率远高于从正确方案一次性生成。
2. 从用户视角验证：让AI描述"用户会看到什么、点击什么"，而非纯技术逻辑。这不仅帮助你理解方案，还能提前发现交互设计上的问题。
3. 确认术语一致性：同一个词你们可能说的不是同一件事，用具体的文件路径、目录结构来对齐。当你说"组件"时，指的是React组件还是系统模块？当你说"接口"时，指的是API endpoint还是TypeScript interface？越具体越好。

Token成本不值得纠结

很多人担心反复追问会浪费token。Paul算了一笔账：这些对话能浪费几个token？几分钱甚至不到一分钱。

Token是大语言模型处理和计费的基本单位，可以理解为模型"阅读"和"书写"的最小文字块。对于中文文本，大约每个汉字对应1.5-2个token（因为中文字符在大多数模型的tokenizer中会被拆分为多个子词单元）；英文则大约每个单词对应1-1.5个token。以DeepSeek为例，其2025年的API定价约为：输入token每百万1元人民币（缓存命中时低至0.1元），输出token每百万2元。一轮包含几百字的追问对话，输入输出合计通常在1000-3000个token之间，实际成本不到一分钱。即使进行五六轮深度追问，总成本也很难超过一毛钱。相比之下，如果因为沟通不清导致AI生成了错误的代码方案，开发者可能需要花费数小时排查问题、回滚代码、重新描述需求，时间成本远超几分钱的token费用。从投资回报率（ROI）的角度看，"问清楚再动手"的收益远高于"省token快速开干"——这也是为什么Paul在视频中反复强调"不要怕浪费token"。

结语

这个案例完美展示了Vibe Coding中"人"的价值所在：你不需要看懂每一行代码，但你需要能从业务逻辑层面判断方案是否合理、是否有遗漏。Paul不懂具体的代码实现，但他知道"台词改了，指导信息不能丢"——这就是领域知识的力量。

这种能力在软件工程中被称为"领域驱动设计"（Domain-Driven Design）思维的核心——真正决定软件质量的不是代码写得多漂亮，而是对业务领域的理解有多深。在Vibe Coding时代，这种能力的价值被进一步放大：AI可以替你写代码，但它无法替你理解业务。你对需求场景的每一个洞察、对边界情况的每一次质疑，都是AI无法自动生成的"人类智慧"。

和AI协作的本质，不是你懂技术，而是你懂需求、懂逻辑、敢追问。聊清楚了，心里有数了，AI干起活来才靠谱。