当软件开发变得无限快，现实世界能跟上吗？
最近经常看到一些开发者分享自己的 AI Coding 工作流。有人声称能够同时管理数百个 Coding Agents，一个月提交甚至合并数千个 PR。
先不讨论这些数字的真实性和统计口径，我并不觉得这种工程生产力在技术上完全不可想象。随着 Coding Agents 的能力提高，一个人可以同时启动大量任务，让它们并行实现功能、修复问题、修改代码。
但我一直有个疑问：如果软件开发速度提高了一百倍，一个产品、一家公司，甚至整个行业，也能以一百倍的速度向前发展吗？
对于从零开始的新项目，这种速度并不难理解。开发者可以迅速搭建系统、实现功能、调整架构。产品还没有经过现实用户的检验，也就不需要考虑已有用户如何适应这些变化。
大规模重构也类似。只要能够保持外部行为稳定，内部代码可以发生大量变化，而用户可能完全没有感觉。
但对于一个已经有真实用户、正在持续经营的产品，情况就有所不同。
即使开发团队每天都能完成几十个新需求，用户真的需要它们吗？他们能否适应如此频繁的变化？一个功能上线后的效果还没有得到充分观察，下一个功能可能就已经发布了。
如果再把视野从纯互联网产品扩展到现实业务，问题就更加明显。
软件可以一夜之间完成，但供应链需要建立，硬件需要研发和生产，客户关系需要维护，产品需要部署，服务需要持续交付。
因此，我想先作一个非常有利于 AI 的假设：Coding Agents 写出的代码完全正确，工程质量和自动化测试都不再构成瓶颈。
即使如此，软件生产能力的增长，究竟能在多大程度上转化为现实世界的进步？
一、开发吞吐量不等于产品进步速度
首先需要承认，成熟产品里确实有大量工作可以吸收新增的开发产能。
性能优化、兼容性修复、本地化、长尾场景覆盖、第三方集成，以及过去因为研发资源不足而长期积压的需求。这些工作通常不需要用户重新学习产品，也不一定改变核心使用体验。
如果开发成本突然降低一百倍，许多积压的需求就有机会被快速解决。
这会是一波真实的生产力释放。
但积压需求终究是有限的。虽然新设备、新平台、竞争和监管变化会不断产生新的需求，它们的出现速度不一定随着代码生产能力同步增长。
当容易识别、明确有价值的需求逐渐得到满足，开发团队就需要面对另一个问题：接下来究竟应该做什么？
这时，一个月完成多少 PR，与产品究竟进步了多少，开始出现明显的差异。
我们至少需要区分三个数字：
- 完成了多少代码变化。
- 有多少变化真正触达用户。
- 有多少变化最终改善了用户的体验。
前两个数字可以随着工程能力迅速增长，第三个却没有理由自动跟随。
而对于需要供应链、硬件、线下运营或者客户部署的业务，还存在第四个问题：那些已经完成、也确实有价值的变化，能否真正交付到现实世界？
软件完成只是其中一个环节。
二、用户能够承受多少变化？
我最初的一个担忧是，用户无法承受过于频繁的产品迭代。
但仔细想想，这个判断需要限定范围。
大多数软件更新并不需要用户付出多少适应成本。一个原本很慢的页面变快了，一个偶尔发生的错误被修复了，或者某项功能在用户需要时才出现，这些变化通常都是好事。
真正有明显适应成本的，是那些改变已有行为习惯的更新。
例如，一个用户每天都在使用的操作入口突然换了位置，原本熟悉的工作流程被重新设计，或者产品的主要交互模式发生改变。
2018 年 Snapchat 的大规模改版就是一个例子。Snap 在当年的财务文件中承认，改版对日活跃用户产生了负面影响，2018 年第二季度的平均 DAU 环比下降约 2%。
但用户适应成本还存在另一种形式：复杂度的累积。
假设一个产品每周增加五个新功能，每个功能都有明确的需求，也没有破坏任何原有流程。
一年之后，产品可能多出了大量入口、设置、状态和交互方式。
即使每项功能单独来看都是合理的，它们的组合也可能让产品越来越难以理解。
早在 2005 年，Thompson、Hamilton 和 Rust 就在关于 Feature Fatigue（功能疲劳）的研究中指出，消费者在选择产品时容易高估丰富功能的吸引力，而在实际使用时会更加重视易用性。
当然，复杂度也不是无法解决的问题。
通过渐进式呈现、分群、个性化，甚至未来的自然语言交互，我们可以把大量功能隐藏在用户真正需要它们的时刻。
因此，我现在不太倾向于认为用户适应能力会构成一个统一、固定的软件迭代速度上限。
它更像一种成本。产品设计能够降低这种成本，但当变化不断累积时，很难保证它永远不会出现。
三、真正难以加速的，可能是现实反馈
相比用户适应问题，我更在意另一个限制：我们需要多久，才能知道一次产品变化是否真的有价值？
微软曾经分享过大规模在线实验的经验。在 Bing 等产品中，能够改善目标指标的想法不到三分之一，而在高度优化的领域，成功比例还可能更低。
这并不意味着剩下的想法都毫无意义，也不代表所有产品都有相同的命中率。但它至少说明，开发团队认为值得做的事情，最终未必能产生预期的效果。
当开发一个功能需要几个月时，实现成本本身会迫使团队筛选需求。
如果未来只需要几分钟，我们就可以尝试更多想法。
这是一个很大的进步。便宜的试错，可能让过去因为成本太高而无法验证的想法获得机会。
但软件实现得再快，也不会自动产生更多真实用户行为。
对于短期可测量的变化，例如按钮点击率、注册转化率，大流量产品可以同时运行大量实验。只要实验设计合理，反馈能力确实可以随着流量和实验基础设施扩展。
小流量产品则困难得多。即使一天能够实现一百种方案，也可能没有足够的用户来可靠地区分它们。
更值得注意的是，很多重要的产品变化无法通过几天的数据判断。
新的推荐机制是否改变了用户长期的内容消费习惯？一个学习产品是否真的改善了学习效果？一种新的社交交互能否逐渐形成稳定的使用习惯？
这些问题都包含现实行为随时间发生变化的过程。
30 天留存至少需要观察相应的 30 天用户行为。即使计算资源和开发速度无限增加，未来的行为也不会提前发生。
当然，我们可以让不同用户群并行实验，或者每天启动新的实验，持续获得已经成熟的长期数据。
所以日历时间也不是简单地限制一年只能做几次实验。
真正的限制出现在一连串相互依赖的产品决策中：如果下一步必须依据上一步的长期结果，那么这段等待就很难完全消除。
短期代理指标可以加速决策，却又引入另一个问题：它们是否真的能代表长期价值？
一个视频 App 可能通过优化推荐，让用户停留更久。但停留时间增加，是否一定意味着用户获得了更多价值？
反过来，一个工具帮助用户把十分钟的任务缩短到一分钟，使用时长下降，用户得到的价值却可能增加。
因此，我们还需要区分用户真正获得的价值，与公司能够从中捕获的收入、时长和活跃度。
尤其当软件开发成本大幅下降、竞争对手也能轻易复制功能时，产品提供者捕获的商业价值和用户得到的价值，可能进一步分离。
开发速度的提高可以让我们更快地产生候选方案，但它不一定能够同比提高我们对现实世界的理解速度。
四、知道什么值得做，也不意味着马上能够做到
前面的讨论主要围绕纯数字产品。但现实中的许多业务，软件只是其中一部分。
想象一家把自动餐饮设备部署到写字楼的公司。
借助 Coding Agents，它可以很快完成点餐页面、支付流程、设备管理后台、库存系统，甚至针对不同客户生成不同的运营界面。
但软件准备好了，不意味着第二天就能在一百栋写字楼里稳定提供餐食。
设备需要生产，零部件需要采购，餐食需要供应，配送需要安排，现场需要具备安装条件。客户要同意进场，运营人员要知道如何补货、清洁和处理异常。
我们甚至可以进一步假设，产品方向已经明确，客户需求已经确认，软件也完全正确。
这些事情依然需要完成。
这时，限制业务推进速度的，可能根本不是不知道什么值得做，而是已经知道应该做什么，却还没有把所需的条件建齐。
硬件研发也是如此。
控制程序可以很快完成，但新的执行机构需要设计、加工、装配和测试。即使方案没有错误，实物也不会随着代码提交一起到达客户现场。
客户关系则涉及另一种时间。
假设一位客户愿意先采购几台设备。他可能需要经历一段真实运营，确认服务稳定、出现问题有人处理，才愿意把采购扩大到几十台。
在这个过程中，客户并不只是提供了一批反馈数据。双方也在积累合作经历，形成对彼此的预期，并逐步承担更大的承诺。
一个更完善的 CRM 可以减少遗漏、帮助跟进，但它不能凭空生成这段合作历史。
Dierickx 和 Cool 在 1989 年关于企业资产积累的研究中，讨论过一种现象：增加投入并不总能按比例压缩资产积累所需的时间。客户信任、合作关系和组织能力，都可能具有这样的特征。
当然，这些过程并非永远无法加速。成熟的供应商、标准化零部件、已有渠道、更好的自动化和更充分的资源，都可以缩短建设周期。
但它们需要具体的条件。
不能因为软件开发成本下降了，就默认这些条件也已经存在。
有些时间用来了解现实，有些时间则用来改变现实。后者无法仅靠更快地产出信息来替代。
五、局部速度不能直接外推到整个业务
可以用一个简单的假设说明这个问题。
某个项目必须先完成四周的软件开发，再完成八周的制造和交付。假设这些步骤确实需要顺序进行，而且其他条件不变。
即使软件开发瞬间完成，整个项目也只是从十二周缩短到八周。
这是实实在在的进步，但距离一百倍还有很远。
如果软件原本就能与硬件并行，而且一直先于硬件完成，那么进一步加快软件开发，甚至未必能提前最终交付日期。它仍然可以节省成本、增加调整余量，只是这些收益不会全部表现为业务周期缩短。
反过来，如果设备迟迟不能进场，恰恰是因为配套软件没有完成，那么软件提速就可能立即释放巨大的价值。
关键在于，软件是不是当时真正限制整个项目的环节。
这也是为什么我不赞成把现实世界的限制概括成“人跟不上 AI”。
有些问题涉及人的判断和学习，有些涉及设备、材料和场地，还有些涉及多个组织之间的依赖关系。
把某个环节推到极高的生产速度，并不会自动协调好其他环节。
而且，开发成本下降还可能让我们更容易启动那些实施成本并没有同步下降的变化。
假设一个新的设备方案只花了一晚上就完成了软件支持。团队因此决定尽快上线。
但这个决定可能要求供应商调整排产，运营人员改变补货流程，客户重新安排场地，售后准备新的备件。
从研发视角看，这是一项成本很低的修改。从整个业务看，它调动了许多尚未变便宜的资源。
代码没有写错，方案也可能确实更好，但频繁改变方向，依然会消耗制造、商务、运营和客户的时间。
因此，我们需要区分便宜的探索和昂贵的承诺。
让 Agents 生成十个原型、在内部比较，可能非常有价值。
但当原型变成对客户的承诺，进入采购、生产、培训和部署，它就不再只是一个随时可以删除的分支。
实现一项变化的成本，与兑现这项变化的成本，可能越来越不一致。
六、最大的进步，可能从来就不是高频迭代带来的
不过，如果因此得出未来软件进步的速度取决于反馈容量或业务建设周期，我觉得又过于简单了。
回顾消费互联网的发展，一些重要的产品变化，本身就不是通过对现有产品进行微小优化得到的。
2006 年，Facebook 推出 News Feed，将原本分散在用户个人主页上的动态整合为持续更新的信息流。
这次变化最初引发了用户的强烈反对。Facebook 随后增加隐私控制，但保留了 News Feed 这个方向。
这是一个有意思的案例。
如果只看发布初期的反馈，用户似乎不喜欢这样的变化。但从后来的发展来看，信息流成为社交网络最重要的交互形态之一。
类似的变化还包括 Stories、短视频信息流等。
这些产品形态改变涉及用户习惯的重新形成，很难仅仅依靠局部 A/B Test，从现有指标的微小改善中推导出来。
它们需要有人在证据还不充分时，对未来的用户行为作出判断。
当然，判断也可能失败。Snapchat 2018 年的改版说明，即使产品团队有充分的理由，也不能保证用户最终会接受新的交互方式。
这让我想到另一种可能性。
如果一个成熟产品的大部分价值增长，来自少数几次重大改变，那么真正重要的可能不是每年完成多少个改进，而是能否识别那些值得改变整个产品方向的机会。
这里隐含着一个尚未得到充分验证的假设：消费级产品的新增价值可能高度不均匀，少数改进创造了大部分价值。
即使这个假设成立，也不能直接推导出判断比实验更重要。
如果那些高价值想法可以通过大量低成本实验被发现，AI Coding 反而可能极大地提高发现它们的效率。
只有当高价值机会既难以提前识别，又无法快速通过真实行为确认时，判断质量和日历时间才会成为特别重要的约束。
但无论是重大产品创新，还是对现实业务模式的改变，最终都需要经过真实世界的检验和实施。
一次正确的判断可以改变方向，却不会自动完成后续的建设。
七、一百倍产能，未必都要用在同一个产品上
此前的讨论始终有一个默认前提：软件生产力增加之后，我们仍然在不断改进同一款成熟产品。
但为什么一定如此？
如果开发一款软件的成本下降一百倍，新增产能可能流向完全不同的地方。
例如，那些过去因为用户群太小、不值得投入研发资源的需求，突然变得有经济可行性。
一种很小众的工作流程、一项只服务特定职业的工具，甚至一个人根据自己的生活习惯定制的软件，都可能获得实现的机会。
这样一来，我们不必不断向现有产品添加功能，而是可以创造更多体量较小、针对性更强的产品。
这种变化可能会让软件从标准化、大规模分发，逐渐走向某种程度的个人化。
但我也不确定这个空间究竟有多大。
首先，用户的时间依然有限。一个人不会因为软件便宜了一百倍，就突然需要使用一百倍数量的 App。
其次，许多软件的核心价值可能本来就集中在极少数功能上。
例如，WhatsApp 在 2014 年被 Facebook 收购时，已经拥有超过 4.5 亿月活跃用户。它当时的核心体验仍然是简单、可靠的即时通讯。
这提醒我们，一款软件能创造很大的价值，不代表它需要不断扩张功能。
而且个人化软件仍然需要解决数据迁移、互通、信任，以及用户是否真正知道自己需要什么等问题。
用户可以更容易获得自己想要的功能，但用户提出的解决方案，也未必一定能解决真实问题。
不过，软件开发成本下降，仍然可能让许多过去没有得到服务的细分需求获得机会。
这种增长未必体现为同一款产品不断增加功能，也可能体现为更多独立的软件、更细分的服务，以及过去因为成本太高而无法成立的商业模式。
而且，当软件变得足够便宜，一些原本需要依赖大型标准化产品才能获得的能力，可能逐渐变成用户可以自行组合、修改甚至生成的工具。
这或许会改变我们今天理解软件产品的方式。
过去，一家公司需要把足够多用户的需求汇集起来，才能支撑一款产品的研发成本。未来，即使只有很少的人需要某项功能，也可能值得专门开发。
但软件开发成本降低，并不意味着这些新产品都能轻易建立起完整的业务。
一个面向个人的小工具，可以通过互联网直接交付；一个面向特定行业的产品，却可能仍然需要销售、培训、系统集成、客户支持和长期维护。
如果涉及实体商品或线下服务，还需要供应链、场地和交付网络。
因此，软件生产力的增长可能会让产品和服务变得更加多样化，但不同业务能够吸收这些新增产能的程度，仍然取决于它们各自的现实条件。
我认为，这也是讨论 AI Coding 生产力时容易被忽略的一点：我们不应该只问一款成熟产品还能以多快的速度迭代，也应该问，当软件开发变得足够便宜，哪些过去无法成立的产品和业务终于有机会出现。
这两种增长可能同时发生。一部分产能用于改进现有产品，一部分用于探索新的需求，还有一部分用于改善那些长期限制业务交付的环节。
它们最终能够创造多少价值，不能仅从代码生产速度推导出来。
八、当代码不再稀缺
回到最初的问题。如果未来真的有人能够同时管理数百个 Coding Agents，每个月完成数千个 PR，我并不怀疑这代表着巨大的生产力进步。
但我们需要重新思考，究竟应该用什么衡量这种进步。
对于成熟的软件产品，开发速度的提高可以让我们更快地实现需求、修复问题、尝试新的产品方向。但用户的注意力、行为习惯和真实反馈，并不会随着代码产量同比增长。
对于涉及硬件、供应链和线下运营的业务，限制又有所不同。即使产品方向完全正确，软件也已经完成，生产、交付、客户关系和组织能力仍然需要时间建立。
这些限制并非不可改变。AI 和自动化也可以改善需求判断、加快实验、优化供应链，甚至改变整个业务的组织方式。但每突破一个瓶颈，我们都需要重新找到下一个真正限制业务发展的环节。
这也是为什么我认为，未来软件行业的生产力增长，不应该只用代码数量、PR 数量或者功能发布频率来衡量。
真正值得关心的是：一个产品从想法到被用户接受需要多久？一项能力从设计完成到实际交付需要多久？一家公司能够以多快的速度发现需求、建立能力，并持续为用户创造价值？
当软件开发不再是最昂贵、最耗时的环节，我们可能会发现，过去许多被归因于研发资源不足的问题，其实还受到现实世界中其他条件的限制。
我的判断是，软件开发速度可以出现数量级的增长，但成熟产品和现实业务的进步速度，不会自动获得同样的增长。
这不意味着 AI Coding 的价值被高估了。恰恰相反，它可能让我们第一次如此清楚地看到，软件开发之外还有哪些事情决定着一个产品能走多远。
未来的竞争，可能不再主要是谁能更快地把功能写出来，而是谁能更准确地判断什么值得做，更快地从现实中获得反馈，并把正确的想法真正变成可持续交付的产品和服务。
代码可以越来越快地生成，但用户习惯需要形成，客户信任需要积累，供应链需要运转，真实的业务需要一步步建立。
软件可以无限接近即时完成，但让软件在现实世界中产生价值，仍然是一件需要时间的事。