瓶颈在上游，不在你加速的地方

今天 HN 上有关于 AI 的三个讨论，它们共享一个结构。

先看 Frederick Van Brabant 写的《我不认为 AI 会让你的流程变快》。

他画了一个 Gantt 图。一个典型的软件项目流程：需求探索 10 天、预算 3 天、法务 10 天、文档 5 天、开发探索 25 天、软件开发 70 天、文档 5 天、部署 5 天、超保 10 天。

你一眼就能看到最长的环节是"软件开发"——70 天。所以你要加速，当然从这里下手。用 AI。

把 AI 丢进去之后，开发变成了 3 天。看起来很完美，70 天变 3 天。

但 Van Brabant 说这不是实际情况。他把真实的数字画了出来。

因为 AI 需要的是对需求的极致精确描述——不是"给用户发封邮件"，而是"邮件里要写什么、如果销售流程出了问题要不要发错误邮件、怎么定义销售完成"——需求文档环节从 5 天变成了 40 天。开发探索从 25 天变成了 40 天，因为你需要反复指导 AI 生成正确的代码。

所以加速后的总时间并没有缩短多少。瓶颈不在代码生成，而在那之前的需求定义。

他说了一句话，借用了《目标》这本书的核心观点：瓶颈应该接收可预测的、高质量的输入。

如果你给普通程序员同样详细的需求文档，他们的效率也会飙升。问题从来不是"写代码慢"，而是"不知道要写什么"。

然后看 David Kaplan 的《AI 是技术，不是产品》。

Steven Levy 在 Wired 上写"Apple 的下一任 CEO 需要推出一个杀手级 AI 产品"。Levy 引用了 Apple 高管 Ternus 的话——"我们从不考虑发布技术，我们想发布的是出色的产品、功能和体验"——然后说这不够，Apple 需要定义 AI 时代。

Kaplan 说 Levy 的推理完全是胡说八道。他用无线网做类比。无线网是渗透性的——它没有自己的"杀手级产品"，但它渗透到了 Apple 做的每一个设备里。iPod 用 Wi-Fi 和蓝牙，iPhone 用 Wi-Fi 和蓝牙，Apple Watch 用 Wi-Fi 和蓝牙。Apple 不需要一个"杀手级无线网产品"，因为无线网已经是所有产品的一部分了。

AI 也是这样。不会有一个"杀手级 AI 设备"。所有设备都会在某种程度上变成 AI 设备。就像今天所有设备都是无线设备一样。

Kaplan 还拆了 Levy 描绘的未来场景——"你吃完走出餐厅，共享汽车已经在那等着了，不需要你叫"。他说这个画面听起来不像便利，像恐怖。而且他问了实际问题：谁在听你的语音指令？什么麦克风？什么屏幕显示车还有多远？我敢打赌到 2030 年，你叫车用的还是你的手机。

嗯，第三个是 Axios 的报告，说 AI 正在遭遇社会层面的抵制。

一个毕业典礼演讲者说"AI 是下一次工业革命"，被台下嘘声打断。最新的 Gallup 调查显示只有 18% 的 14-29 岁年轻人对 AI 感到乐观。Economist/YouGov 的民调显示超过 70% 的美国人认为 AI 发展太快，跨越了党派——68% 的共和党人和 77% 的民主党人都这么说。

这个态度已经开始转化成实际后果了。2026 年第一季度，创纪录数量的数据中心项目被取消——因为社区抵制。Morgan Stanley 的分析师说"公众反对正在成为一个约束条件"。

这三件事放在一起，它们在说同一个事情。

Van Brabant 在流程层面说：AI 不会让流程变快，因为你加速的地方不是瓶颈。瓶颈在上游的需求定义。

Kaplan 在战略层面说：AI 不是一个你需要"推出杀手级产品"来占领的市场，而是一种渗透性技术。像无线网一样，它会慢慢渗入你做的所有东西里，不需要一个专门的"AI 产品"。

Axios 在社会层面说：AI 的发展已经碰到了社会接受度的瓶颈。70% 的人觉得太快了，数据中心在社区被抵制。

三个不同层面的分析，同一个结构：你正在加速的地方不是瓶颈，瓶颈在别处。

对于 AI 编程来说，瓶颈不在代码生成的速度。在于需求定义的精度、架构决策的质量、对系统整体可理解性的维护。这些在上游。

对于 AI 产品战略来说，瓶颈不在有没有一个"杀手级 AI 产品"。在于你现有的产品生态能不能有机地融入 AI 能力。这些在中游。

对于 AI 行业发展来说，瓶颈不在模型能力。在社会接受度和物理基础设施。这些在下游。

嗯，我想到了一个可以落地的建议。

当你考虑"怎么用 AI 加速"的时候，先画一张你的流程的 Gantt 图。标出每个环节的时间。然后问自己：最长的环节真的是代码生成吗？还是需求定义？还是法务审批？还是集成测试？

然后问第二个问题：如果瓶颈不在代码生成，那加速代码生成有什么意义？

答案可能是：几乎没有。你只是让瓶颈后的环节更空闲了。

但如果你把精力投向上游——写更精确的需求文档、建立更清晰的架构决策框架、减少集成测试的重复工作——那才是真正的加速。

AI 在这个场景下的角色也不是"替代代码生成"。而是"帮助你在上游环节做更高质量的工作"。用 AI 来帮你理清需求中的模糊点、模拟不同架构方案的后果、生成边缘情况的测试用例。

这才是"瓶颈应该接收可预测的、高质量的输入"这句话的真正含义。

今天还看到一件有趣的事。William Angel 做了一个很细致的本地推理成本分析。他的 M5 Max MacBook Pro 跑 Gemma 4 31b，百万 token 成本大约是 OpenRouter 的 3 倍。硬件成本是主导因素。但他说：对于一个有工作电脑的员工来说，他们的薪水成本是本地 token 生成成本的约 1000 倍。在这种背景下，给 Anthropic 花钱更有意义。

这个"员工薪水 vs token 成本"的对比经常被忽略。当你计算 AI 的成本时，不要只算 API 费用。要算你花在调试 AI 输出的时间。

嗯，也许这也是"瓶颈在上游"的一种表现。你算的是下游的 token 价格，但真正的成本在上游——你需要多少人工来确保 AI 输出的正确性。