AI等待方程

如今构建AI应用，总会伴随着一种令人不安的想法。下一代模型即将问世，随之而来的改进将使你正在构建的一切变得更好、更快、更便宜。那么，为何不从现在开始？为何不等待工具成熟，等到能力“最终到位”再动手？参见：等待方程。

让我们从当前所处的位置说起。

我们已跨越一道门槛

模型能力的提升并非平滑渐进，而是阶梯式跃升，每一代新模型都落在更高的台阶上。多年来直至今日，这些台阶始终低于某个阈值：模型能协助部分工作，但仍需有人验证并最终完成任务。你得到的是自动补全和一些可能达成目标、也可能未达成的代码输出，但你绝不会盲目信任它。

本周发布的Fable及随后的Astra，代表了迄今为止最大的能力跃升，模型如今能引导整个任务，并交付足以直接上线的成果。Lauren Tan（@poteto）最近一个月内超过2000个PR的例子，正是有人在规模化地实践这一模式，通过大量消耗token来驱动所需的验证水平，从而在极少人工干预的情况下发布商业软件。

这一切并不意味着今天的模型已接近最终形态。它们会犯错，有独特的怪癖，若放任自流，很快就会偏离正轨。关键在于，一个基础阈值已被跨越——在足够的引导下，我们能用最新模型发布真正的软件，而基础模型接下来的每一步（Opus 4.8到Fable 5是跃升，Fable 5.0到5.1则不是）都将日益缩小信任差距，拓宽我们所能创造的软件能力范围，并以更快的速度交付更高质量的成果。

这对任何正在构建软件的人来说都是个好消息。确实如此。对其他所有构建软件的人来说，同样也是好消息。

窗口每一步都在缩小

如果一个更好的模型降低了你的构建成本，它也会以完全相同的幅度降低你竞争对手的构建成本。如今，模型驱动开发中仍然存在足够的复杂性，以至于要交付任何实质性的产品都需要真正的技术人才。GitHub 上充斥着没有版本发布标签的大胆雄心，而这些仓库只代表了人们硬盘上内容的一小部分。

但随着每一次前沿模型的发布，模型和工具链的能力都在不断吸收越来越多的这种复杂性，从而削弱了以往由技术密集型团队和早期采用者所占据的优势。我们尚未达到商用级软件交付的完全民主化，但无需费力想象，就能看到那一天已在地平线上。

随着软件交付变得越来越容易，能力的扩散将大幅扩大竞争面，而前沿模型则将那些拥有最大潜在市场（TAM）的产品直接整合进它们自身的工具链中，也就是所谓的超级应用。

这时人们通常会提到护城河。分发渠道、专有数据、客户信任以及对工作流程的所有权都至关重要，它们能买到实实在在的时间。它们能改进产品，并减缓商品化的进程。但它们无法保护你免受下一个能力跃迁的冲击。领先一步就是领先一步，而如今，这种领先比以往任何时候都更不可能是永久的。

工程循环变得更加紧密

观察不同代际模型在工程工作中实际发生的变化，有助于我们理解，因为人们很容易误以为这些工作会消失。事实并非如此。工作阶段保持不变：规划、构建、审查、测试、修复、发布、学习、再循环。变化的是循环的规模以及其中发生的回溯次数。

使用当今的模型，这个循环既庞大又令人沮丧。需要更多的监督、更多的回归测试、更多的手动检查，以及发布后更多的修复工作。有两个数据可以佐证这一点。在超过500家公司中，DX的Core 4基准测试发现，约42%的工程时间仍花在维护、支持和缺陷修复上。而在2026年GitLab对1,528名开发者和技术采购者的研究中，85%的人表示，AI已将瓶颈从编写代码转移到审查和验证代码上。如果你每天都在经历这些，这些数字会显得非常真实。

下一代模型将以更少的回溯、更快的审查和更可靠的迭代来运行同样的循环。后续代际将进一步压缩这一循环，使其更接近规划、构建、验证、发布、学习的模式。用Boris Cherny的话说：编码问题已解决，缺陷问题尚未解决。修复即将到来。

有早期证据表明，循环的两端已经在发生压缩。Jellyfish分析了259家公司超过216万个合并的拉取请求，发现在2025年第二季度，重度AI辅助的拉取请求比未辅助的拉取请求快了约16%，节省的时间既来自编码也来自审查。缺陷率在不同采用水平上保持稳定。这是观察性数据，仅限于一个助手，因此应将其视为信号而非确证。但它指向了正确的方向。

Elon Musk认为，模型最终将能生成完美无缺的机器代码。在那之前，我们只是在追逐一条渐近线，循环永远不会归零。选择正确的问题、设定质量标准、从真实用户那里学习，这些都不是模型能替你完成的。真正在缩减的是每个循环中用于验证和修复构建的时间份额，这为扩展产品功能释放了更多空间。

两场比赛，两位赢家

同时进行着两场比赛，它们各有各的赢家。

工程赛比的是谁能以最少的努力构建产品。等待的团队在这场比赛中胜出。他们起步晚，但起步时循环更小、返工更少、工具更优。他们的构建成本更低，也避开了早期工具和流程带来的痛苦。典型的“等待方程”动态。

市场赛比的是谁能赢得客户，现在发货的团队在这场比赛中胜出。他们发货、学习、积累使用量、融入用户的工作流程，并根据所见不断改进。这是支持SaaS在位优势的论点。等待的团队会发现更多的构建者、更多的替代品，甚至可能是一个已经占据该品类的平台。

尽早发货买来了时间，但并不保证护城河。早期产品赢得了客户、学习、数据和在工作流程中的一席之地，而生产它的代码价值却在不断下降。这两件事同时成立。

两者兼顾

解决之道在于不再将此视为二选一。

用今天的模型发货。用明天的模型重建。

现在就利用手头的工具构建第一版。发货并从实际使用中学习。将所学转化为关于产品应如何表现的证据。当下一个模型到来时，依据这些证据重建第二版，比第一次更快、更干净。再次发货。

你现在建立的位置就是先发优势。代码只是这一代对它的实现，从第一天起就该把它视为可替换的。

最后一句话是大多数团队感到不安的地方，而且他们理应如此。重写名声不佳，这是数十年史诗级失败换来的。但更聪明的模型改变了局面，也凸显了颠覆的风险。把颠覆变成竞争优势。

AI 重写循环

从零开始的重写正变得更便宜、风险更低。拥抱成为自己最好的颠覆者。

把产品想成三层。

顶层是可能复利的东西：用户、使用量、分发、数据、信任、对客户的理解，以及对工作流程的掌控。这些是尽早发布为你赢得的。没有哪一项能保证永远稳固，但它们是能在其他一切变便宜时持续增长的东西。

中间层是必须存续的东西：你的评估、遥测、契约、必需行为、用户旅程、生产追踪、验收标准、边缘案例，以及迁移历史。它是关于你的产品应该做什么、在现实世界中实际如何表现的积累证据，也是将你与任何想在市场上取代你的新手区分开来的东西。培养将这一层规范化、分析并痴迷于它的纪律。

底层是可替换的东西：源代码、架构、框架、变通方案、样板代码，以及围绕特定模型怪癖搭建的脚手架。这一层的价值随着每次模型发布而下降，而在这里将自我蚕食制度化，能让你保持优势。

这一点值得重复：你的代码不如你的评估、遥测、契约和行为重要。守护那些。把代码视为可替换的。

如果这听起来有些反直觉，不妨想想传统重写真正丢失的是什么。那是产品经理或工程师编码但从未记录的神秘、非文档化知识：某位客户在第三个月遇到的边缘情况，某个大账户依赖的独特行为，或是某条路径故意变慢的原因。重写之所以失败，是因为这些知识只存在于实现和人们的脑海中。如果它们转而存在于评估、追踪和契约中，实现就成了最廉价的部分。

重建循环

实际中的循环是这样的。

发布v1版本，观察真实使用情况。每当现实让你意外，就更新评估、契约和文档化行为，让意外被持久地捕捉下来。然后，更好的模型出现了。

利用新模型更好地理解你的中间层。提取洞见，验证它们，并利用它们来定义下一代。借助改进的元认知，提出比前一代模型更好的问题，并坚持不懈地推动更强的评估和更完善的契约。

赋予模型推动v2设计和架构选择的自主权，因为前沿实验室正在协调它们的竞争性发布，每一步不仅意味着更多智能，还意味着更多可用于推动设计的广度。

将两个版本对照相同的评估和相同的生产追踪进行比较，当指标表明时机成熟时就发布。

尽可能基于证据构建新版本。构建v2的团队应从第一天起就针对评估套件和记录的追踪运行它。在这方面大力投入。

而随着每个重建周期，利用前一个周期的基础设施学习，将端到端编排进一步推向自动化。

这一切的总结

更好的模型让软件对你和其他所有人都更便宜。尽早发布，以便学习并占据一席之地。保留产品应如何表现的证据。然后利用每一个新模型步骤来重建、简化和扩展它。

颠覆周期正在缩短。在这种环境中表现出色的团队不会是那些猜测正确启动时机的团队，而是那些发布、学习、重建并重复这一循环的团队，并且从不将这一代的代码误认为产品本身。