第 1 步：构建一切
我们这代开发者，人人继承了一套铁律：小批量推进、PR 保持精简、频繁合并。发布那些你自己都觉得拿不出手的东西，再一步步迭代到答案。这套纪律很重要，它保证了评审顺畅、工作方向一致。但它也折射出过去的现实：当“构建”本身就是最昂贵的动作——每尝试一次就要烧掉几个月的工程时间——搞砸一个大项目无异于灾难。解法就是持续、可控的小步评审，相应地也就要求小步构建。小步构建不只是正统教条，它是软件开发成本结构推导出的必然结果。
今天，正确的构建步长恰恰是我们都被教导说“错”的那一种。但成本结构已经反转，大多数人却还在信奉旧福音。今天正确的构建步长，恰恰是我们都被教过说那是错的：第一步就做整个事情。当智能体在写代码时，写下一千行的边际成本，跟描述这一千行是什么的成本已经相差无几。可代码编写速度爆炸式增长之后，评审环节的工作量还是那么多：判断工作是否正确、是否安全、是否切题。相比之下，这意味着评审——即使有智能体评审和测试套件加持——已经变得昂贵得多。感谢阅读 Inside AI Native！免费订阅即可收到新文章推送。
在我自己的工作流里，一晚上无人值守的智能体任务，经常能完成过去要几周才能做完的工作，但我早上的评审时长一点都没变。Vishal Misra 把这种现象的普遍形态称为“验证瓶颈”：算力买到的是提案，验证买到的是知识。我想把这个框架再推进一步：瓶颈是可以绕过去的，但当某种资源变得稀缺时，你要做的是预算。评审时间在墙钟上没变，但相比之下已经变得极其稀缺。意识到稀缺，就意味着要承认你再也负担不起旧的模式了。把这一点计入评审成本来看，原来的做法就没那么精益了。想想“先发布个简单的版本”——这曾是精益且审慎地使用工程资源的方式。
第 1 步：构建一切
把评审成本算进去，精简方案就没那么省了：先评审一个简化版，再评审正式版，等于评审做两遍——因为评审最终版的时候，简化版已经覆盖过的内容还要再走一遍。而且第一次评审评估的决策，本来就是你打算扔掉的。如果构建本身很贵，中间那个版本确实能让你在投入大笔方向性投资之前，提前买到信息；可如果贵的是评审，那就等于为同样一份信息付了双倍价钱。这让我们在工作中立了一条新规矩：只发布那个“评审收获最大”的版本。如果先做一个半步版本，而评审它并不会改变我们接下来要建什么，那就直接跳过它去建完整的。这样一次评审评的是整个功能，而不是那个过渡版本。
举个例子：我做一个移动端功能时，最初计划只在本地网络测试——把手机浏览器指向一个局域网 IP，就能开始操作移动端界面。这是个精简方案：不考虑联网、不涉及 App，只有最基础的东西。但“任何地方都能用”的完整版其实是同一个晚上就能做出来的；先评审那个小版本，只会让创始人多搭上一个上午，却换不来任何新信息——评审花的时间一样，产品进度却一次就走出了两倍远。
类似的情况出现在“共享实时 Agent 会话”上：半步方案（把链接粘给队友）和完整版（一键邀请，直接落到队友收件箱）的构建工作量基本一样。既然都是让 Agent 跑一个通宵的活，不如直接做完整版，这样一次评审就能覆盖整个功能，而不是只评一个中间态。
当然，“构建一切”确实有点夸张。我们仍然会保留一些能回答关键问题的步骤，而且这类步骤的分量反而更重了——因为它们往往跑起来很便宜，某些情况根本不需要正式评审。比如，我们最近为一个框架选型做了一轮调研，下午开始，收工时得出结论“不要引入框架”：零构建、一个决策，这种便宜的步骤，现在做起来比以前任何时候都便宜。
感谢阅读 Inside AI Native！免费订阅可获取最新文章。
那些守住信任边界的步骤也要保留。我们的邮件功能先以只读形式上线，在验证可靠性之后，才敢去碰更冒险的方向：让智能体起草邮件、甚至发送邮件。所以，我们要跳过的是中间版本，不是信任建设。这两者的区别，正在成为新一代高级工程师的核心素养。
而那些暗地里其实是新产品、或是在探索新方向的“步骤”，根本不叫步骤。步长是一个决策——决定在一批工作中，朝着你已经决定要做的事情走多远。
这一切有个前提：只有当你的流程能让人一次性审查完整成果时，“第一步就构建所有”才是合理的。这意味着，动手之前要有决策完整的规格说明，工作过程中要有对抗性检查，合并代码时要有一个独立的怀疑者，审查者拿到的报告也必须可信。
严谨并不与速度对立；恰恰是严谨让大步幅变得可审查，从而让速度产生复利，而不是陷入混乱。那些只学步幅、却丢掉纪律的团队，会付出高昂代价，重新理解“精益”到底为什么存在。
我们遇到过最陌生的约束，根本不在构建这一侧。在机器运行最紧张的那个夜晚——十几个并行工作流要在清晨前全部落地——瓶颈不是构建，甚至不是集成，而是我们已经没有“已决策”的工作可以喂给它了。现在，机器的上限取决于你能否把决策清晰到可以交给它。这恰恰指向了审查环节需要如何演进，才能支撑更大规模。
每一个写入书面标准的决策，都是一次你不需要重复的审查，而且它可以直接吸收进构建流程本身。从意图出发——先定义什么算“好”、什么算“有效”——你就能持续削减审查成本：不再反复解释意图，而是直接批准那些对“好”的定义所做的修改。审查越稀缺，书面化的公司就越有价值。