4.3 每个阶段的翻译损耗

一个"传话游戏"的拆解

你有没有玩过"传话游戏"？一排人站成一列，第一个人想一句话，悄悄传给下一个人，一个一个传下去，最后一个人把听到的话说出来——结果通常和最开始的那句话差了十万八千里。

传统软件开发的过程，本质上就是一场传话游戏。

用户的需求从终点到终点，经过了多少次翻译？我们从 2.3 节的翻译链继续深入。

第一层翻译：用户的需求 → 用户的表达。 用户知道自己想要什么吗？不一定。很多时候用户说的是"我想要一个更快的搜索"，但真正的问题是数据量大了，不是搜索慢了。用户描述的问题和真正的问题之间，本身就有一层偏差。这是第一层"损耗"——还不是正式的开发流程中发生的，是需求还没进入开发链路就已经失真了。

第二层翻译：用户的表达 → 产品经理的理解。 产品经理听了用户的反馈，结合自己的经验，形成了一版理解。这一层损耗的典型问题是"确认偏误"——产品经理倾向于把用户说的内容理解成自己熟悉的模式。用户说"搜索不够快"，产品经理脑子里出现的是"加缓存"的方案，于是他把需求记录成了"优化搜索性能，增加缓存层"。但用户可能根本不在乎缓存，他说的"不够快"指的是"搜索结果不精准，要翻很多页"——这是两个完全不同的问题。

第三层翻译：产品经理的理解 → 需求文档。 产品经理把脑子的理解写成文档。这一层损耗最隐蔽——文字无法记录语境。需求文档里写的"搜索结果要更智能"，不同的人有不同的解读。对产品经理来说是"提升搜索排序的相关性"，对开发来说是"用 Elasearch 的 MLT（More Like This）"，对测试来说是"和竞品做对比"。同一段话，三个角色看到了三个不同的任务。

第四层翻译：需求文档 → 技术设计。 开发团队读需求文档，把它翻译成技术方案。这一层的问题是"技术偏好"——开发者倾向于选择自己熟悉的技术。如果需求"要更快"，擅长数据库的开发者会想"优化 SQL 查询"，擅长缓存的开发者会想"加 Redis"，擅长架构的开发者会想"做读写分离"——每个人选的方案都不同。

第五层翻译：技术设计 → 代码。 开发者把设计变成具体代码。这一层的损耗来自于"实现细节的差异"。"按发布时间排序"这个看似明确的需求，在实际编码中涉及到：发布时间是哪个字段？是以首次发布时间为准还是以最后修改时间为准？时区怎么处理？如果没有创建时间的记录，历史数据怎么补？每一个小问题都可能导致代码行为和原始需求之间的偏差。

第六层翻译：代码 → 测试用例。 测试人员根据需求文档（而不是原始用户需求）写测试用例。如果开发者误解了需求，测试人员基于同一个文档写的测试也会错过这个误解。这就是"同源偏差"——文档错了，开发和测试会一起错，谁也发现不了对方的问题。

第七层翻译：测试验证 → 上线交付。 最终上线的功能和用户最开始的需求之间，可能已经隔着七层翻译。每一层都引入了一些偏差，偏差叠加偏差，最终的结果和原始需求之间的距离，很多时候已经不是"一点点差异"，而是"方向性的偏离"。

需求层层耗损（金字塔模型）

我想用一个金字塔模型来展示这个耗损过程：

用户真实需求（100%）

↓

用户表达出来的（70%）

↓

产品经理理解的（60%）

↓

需求文档写下的（50%）

↓

技术设计的实现（40%）

↓

最终编码完成（35%）

↓

测试验证通过的（30%）

↓

上线后用户用到的（25%）

你可能觉得这个数字太夸张了。不夸张。这还是一个"做得不错"的项目——有专职产品经理、有评审流程、有测试团队。如果项目做得粗糙，最后一层可能只剩下 10%。

每一次"↓"都是一次翻译。每经过一阵翻译，信息都会损耗，而且这种损耗不是线性的——后面每一层的损耗都比前面更大，因为前面已经遗漏的信息不会在后面被找回来。

这个金字塔模型解释了软件行业一个普遍的现象：用户抱怨产品"不是他们想要的"，产品团队抱怨"需求文档已经写得很清楚了，是开发没做对"，开发团队抱怨"需求文档有歧义，我们按自己的理解做了"。 三方可能都没错——他们只是站在翻译链的不同节点上，各自看到了信息损耗的结果。

为什么 Vibe Coding 能打破这个循环

Vibe Coding 不是从"提升某一次翻译的质量"入手的——它是从"去掉翻译环节"入手的。

传统的翻译链是：用户 → 产品经理 → 需求文档 → 技术设计 → 代码。Vibe Coding 的翻译链是：用户（你）→ AI → 代码。

中间的所有角色——产品经理、需求文档、技术设计——在 Vibe Coding 的工作流中要么被压缩要么被 AI 替代了。你不需要把需求写成一个标准文档再交给另一个人去翻译，你直接用自然语言告诉 AI，AI 生成代码，你看了之后直接调整。

这个"直接"两个字的背后，省掉了三四层翻译，每一层节省下来的信息损耗，都以产品的准确性和开发效率的形式还给了你。

但这里有一个容易被忽略的前提：你自己就是产品经理。 在传统开发中，你有一个专门的产品经理来理解用户需求。在 Vibe Coding 中，没有人替你干这件事——你就是那个"理解用户需求"的人。如果你自己做不好"理解需求"这一步，AI 也无法帮你弥补，因为你描述给 AI 的需求本身就是失真的。

所以 Vibe Coding 并没有消除"用户→开发者"之间的翻译，它只是把翻译的过程从"多个角色接力翻译"变成了"你一个人翻译"。你不再需要把需求翻译成文档再交给别人了，但仍然需要把自己的想法翻译成 AI 能理解的提示词。这个翻译能力——你能不能把一个模糊的需求变成一个清晰的 AI 提示——成了新的关键技能。

翻译损耗在实践中的成本

我们来看一个具体的例子，把翻译损耗的"成本"用数字量化。

假设你的团队做一个"用户注册功能"。用户的需求是："我想用手机号注册，收验证码。"

在传统开发中：

• 产品经理写了 5 页的需求文档，包括异常流程：手机号格式验证、验证码发送频率限制、验证码过期时间、换绑手机号流程。——这些翻译耗时约 3 天。
• 开发读文档理解需求，画技术方案：用什么短信服务商、验证码存 Redis 还是数据库、验证码生成逻辑。——翻译耗时约 2 天。
• 开发写代码：前端页面、后端 API、数据库表结构。——编码 3 天（这已经是标准功能的速度了）。
• 测试验证：写测试用例、手动测试边界情况、发现文档没写清楚的"用户换了手机号但旧手机号还能不能收验证码"——重新确认需求。——测试 2 天，其中 0.5 天用于回去澄清需求。
• 总耗时：约 10 天，其中 20% 的时间花在"翻译"（沟通、写文档、澄清）上，20% 的时间花在"返工"（因为翻译不准导致的修改）上。

在 Vibe Coding 中：

• 你直接对 AI 说："帮我做一个手机号注册功能，用户输入手机号，点获取验证码，输入验证码完成注册。"
• AI 生成代码，你审查后确认可以。
• 总耗时：约 1 小时，其中你的主要精力花在"审查 AI 生成的代码是否安全"上。

两种方式的成果质量可能差不多（甚至 AI 生成的代码更标准），但前者花了 10 天，后者花了 1 小时。这 99% 的时间差异，几乎全部来自"翻译环节"的取消。

当然，这个极端的对比省略了一些细节（比如传统开发中你要考虑更复杂的异常场景），但要点已经很清楚了：翻译链上的每一环都在消耗时间，而且每一环的消耗不是加法，是乘法——因为你翻译错了后面还要返工。

"翻译损耗"其实是组织成本的体现

一个更深层的观察是："翻译损耗"不只是"某个人没表达清楚"——它是组织成本的体现。每一层翻译之间的"墙"，本质上是由团队的职责分工造成的——产品经理只负责需求，开发只负责实现，测试只负责验证。每个人职责明确，但没有一个人对整个链条的完整性负责。而链条的完整性，恰好是 Vibe Coding 中唯一负责的人——你自己。

当你是产品的唯一创造者（从需求到代码到部署都是你），翻译链的长度就自然缩短到了极限——从你的脑子到 AI 到你手上的产品，中间没有第二个人需要"理解"你的意图。信息损耗理论上可以降到最低。

但这里有一个反向的风险：没有第二个人，意味着没有人能帮你发现你的盲区。 在传统开发中，产品经理的盲区可能被开发发现，开发的盲区可能被测试发现——多人协作在某种程度上是一个"交叉验证"的过程。在 Vibe Coding 中，你一个人承担了所有角色，你的盲区会因为没有人交叉验证而"隐藏得更深"——AI 不会纠正你的需求误判，它只会忠实地翻译你的误判变成了代码。这一点是你在 Vibe Coding 中必须时刻提醒自己的。