更快行动

你可能太慢了。我可能也太慢了。

我们倾向于把 AI 速度当作一种虚荣指标——一种用来在无聊的事情上少花点时间，或者在路线图中塞进更多工作的方式。但速度不仅仅是做更多同样的事情。当你跨越某个速度阈值时，你构建事物的基本物理规律就改变了。它改变了你做决策的方式、你看待代码的方式，以及你把心智能量花在哪里。

这不是魔法；在 100 英里的时速下保持品味和质量仍然需要技巧。但一旦你养成了“思考 → 自动化”的习惯，你就不再只是问“我怎样才能用更少的时间完成这件事？”，而是开始问“这改变了什么值得去做？”。

在这篇文章中，我想收集一些关于为什么速度很重要1以及持续有效的自动化的二阶后果的思考。

有了速度……

你可以做更少的决策。

你不再争论要构建哪个功能，因为预测是昂贵的，但验证是廉价的。在旧世界，你必须在会议室里猜测赢家。在新世界，你同时构建三种不同的方法，让结果来决定。争论工作的成本变得比直接去做它的成本还高。

速度还消除了对小任务令人痛苦的优先级排序。每个人心中都有一个“值得修复”的心理阈值——我们会忽略那些需要数小时修复但价值不大的 bug。当执行成本崩塌到接近零时，这个阈值就消失了。你不再根据工作量来管理待办事项列表，而是纯粹根据影响来修复问题。

你可以用消耗品来交换资产。

软件或其他资产的投资回报率（ROI）阈值崩塌了。你开始构建“一次性软件”（一个在 Q4 规划期间使用一周的仪表板，或者一个为单个客户编写的复杂脚本），然后将其删除。代码不再是一种资产（你维护、重构并珍视的东西），而变成了一种消耗品（你生成、使用并丢弃的东西）。这种逻辑延伸到角色和系统，你用瞬时解决方案来交换永久设施。在慢速世界中，分析师是一个永久角色，因为回答复杂的问题是困难且持续的；在快速世界中，你不会雇佣一名“分析师”2，而是维护一个系统（上下文和基础设施）来即时回答问题。只要问题存在，这个角色或专业领域就存在。

（另见大多数代码只是缓存）

你可以用掌舵代替绘图。

当执行需要数月时，你需要一张地图。你需要告诉高层你在 Q4 将要做什么，以便你在 Q1 招聘相关人员。但如果你能在一周内构建任何东西，那么 X 个月的路线图就是一种负债，它会将你锁定在 X 天后就会过时的假设中。在慢速世界里，我们编写 PRD 和原型图，因为它们比代码更便宜。我们试图在 Google 文档中模拟未来，以避免构建错误的东西。有了速度，“想象鸿沟”就消失了。你不再争论一个功能可能如何运作，而是开始争论实际运行的功能。

你可以处理导数。

你今天花时间做的大部分事情，五年后你将不再做。当一项任务需要 4 小时时，你的大脑被执行——即“速度”——所占据。当同一项任务被自动化到只需 4 秒时，你的大脑被迫转向“加速度”。你不再修复那个特定的 bug；你修复的是允许该 bug 存在的规则。

借助通用智能，你可以更进一层：加速加速本身。你不仅编写修复代码的提示词，还构建能够自动优化提示词的评估流水线。你不再从事工作本身，而是开始从事工作的优化。你从一阶执行（做这件事），转向二阶自动化（改进系统），再转向三阶元优化（自动化系统的改进）。AI 吞噬了低阶导数，不断将你推向技术栈的更高层，让你成为构建机器的机器的架构师。

你的学习速度可以快于衰减速度。

在旧世界，'三思而后行'之所以是美德，是因为建造成本高昂。在新世界，错误假设的成本近乎为零，但过时的成本却高得惊人。如果一个项目需要六个月才能发布，你冒着用已经过时的工具去解决一个已不复存在的问题的风险。这种速度还能改变概率。即使你才华横溢，由于隐藏变量的存在，你也有一定比例的决策注定是错误的。通过快速行动，你可以增加你的“运气表面积”3。你射门的次数更多，测试的假设更多，撞上的意外之喜也更多。

感谢阅读 Shrivu 的 Substack！免费订阅以接收新文章并支持我的工作。

那么……

寻找导数型思考者

寻找那些身份不与特定任务绑定，而与他们产出的变化率绑定的人。他们从不做六个月前在做的同一件事，因为他们早已将那个角色系统化地消除了。“懂的人”与“不懂的人”之间的鸿沟正在扩大4；前者是自身过时的架构师，而后者则不断重复同样的循环，直到 AI 替他们自动化。前者将重复性努力视为个人失败，愿意花时间去自动化一项一小时的任务，只为确保只有他们、而没有别人需要再做一遍。

自动化一切

你不能留下任何未利用的余地。这是 AI 转型的阿姆达尔定律：当“核心”工作的耗时趋近于零时，你所忽视的“琐碎”手动步骤——10 分钟的部署、UI 上的手动数据录入、等待 CI——就变成了整个瓶颈。你系统的速度不再取决于你写代码有多快，而取决于你没有自动化的那件事5。如果一个智能体能在 5 分钟内修复一个 bug，但安全团队需要 3 天来审查文本，或者设计团队需要 2 天来批准内边距，那么这个组织本身就变成了那个 bug。你需要以对待服务器延迟同样的严肃态度来对待组织延迟。

练习破坏

当创造是免费的，平庸“作品”的数量将趋近于无穷。为了生存，你必须同时提升你的品味并降低你的情感依恋。你需要品味，能看着十个 AI 生成的方案，直觉地知道其中九个是精妙的垃圾。你还需要破坏性的纪律，去删除你上周生成的代码，因为它已经完成了使命。从生物学上讲，我们天生倾向于囤积我们建造的东西（参见宜家效应），但在无限生成的时代，囤积导致复杂性，而复杂性扼杀速度。如果你自动化了构建却没有自动化修剪，你不会变得更快；你只会淹没在自己制造的 AI 垃圾沼泽中。

对辩论和审查征税

多元化的观点至关重要。但我们需要改变分歧发生的地方。在旧世界里，我们在房间里争论预测（“我认为用户会想要 X”），并进行冗长的评审以捕捉错误。在新世界里，人工评审只是创作缺乏自动化的一种表现。你不应该评审产出，而应该争论产生它的系统。如果你不断评审同一类错误，就停止评审代码，转而修复生成它的上下文。停止争论哪个决策能预测未来，转而争论系统及其实际产出。将专业知识从流程末端（批评）转移到开端（系统设计）。

我们习惯于预期摩擦，等待构建，安排会议，“再考虑考虑”。当智能唾手可得、启动近乎即时时，等待开始变成一种选择，而非必需。在缓慢的世界里，我们利用流程的“等待时间”来弥补自身的不清晰。在快速的世界里，这种补贴不复存在。如果你没有行动，那不是因为系统正在编译，而是因为你不知道下一步该做什么。

感谢阅读 Shrivu 的 Substack！免费订阅以接收新文章并支持我的工作。

我原本打算将这篇文章命名为“为什么速度很重要”，但在定稿时，我实际上发现了另一篇很棒的文章：Daniel Lemire 的“为什么速度很重要”，它提出了类似的关于速度的论点（尤其是“你可以比衰减学得更快”这一节）。

需要明确的是，那些曾经是“分析师”的人最适合构建和维护这个新系统。他们现在将在不参与循环的情况下，从事让系统更好地进行“分析”的‘衍生’工作。

我非常认同 Zara 在“如何在你的职业生涯中获得好运”中对运气的讨论。你可以说 Luck = surface area × probability = the number of opportunities you (or AI) create × the likelihood of any one opportunity paying off。

参见 Geoffrey Huntley 的NGMI。

Rahul 关于CI 时间成为软件工程师瓶颈的推文对此有字面上的例证。