AI 时代，工具链性能变得前所未有的重要
AI 编程真正改变的不是“写代码更快”这么简单，而是开发进入了 agentic loop：AI 写代码、跑验证、读错误、再修复。这个循环里，test、lint、build 的耗时会直接决定整体吞吐。
D2 现场听尤雨溪分享时，有一张图让我印象很深。
它不是那种靠视觉效果取胜的发布会大图，更像是把一个大家已经隐约感觉到的变化，直接摆到了台面上：AI 把写代码这件事加速以后，开发循环里最慢的地方变了。
图里有三个阶段。
AI 之前，大部分时间都花在 writing code 上，waiting for tools 只是下面一小块。人写代码本来就慢，工具链慢一些，当然烦，但不一定是最刺眼的问题。
AI 之后，writing code 被压缩了。代码出来得很快，waiting for tools 那一块反而变得很显眼。
再往后，是 AI + better tools：更快的基本错误反馈，更快的行为验证，更快的迭代速度。
这张图讲中的不是“开发者等命令很烦”这种老问题，而是一个新的工程事实：AI 时代，工具链性能会直接决定 AI 编程的循环速度。
English version: Toolchain Performance Matters More Than Ever in the AI Era
不是人在等，是循环在等
过去说工具链慢，通常是在说人等得烦。
跑测试，去喝水；跑构建，切出去看一眼消息；lint 卡一下，顺手打开别的窗口。慢当然不舒服，但它很多时候只是人的工作流里一段空白。
现在 Codex、Claude Code、Cursor 这类工具把开发方式改成了另一种形态。
它们不是只生成一段代码就结束。更典型的过程是：读上下文，改代码，跑测试或 lint，读取错误，再改，再跑。这个过程越来越像一个 agentic loop。
在这个循环里，工具链不是“人类开发者旁边的辅助命令”，而是 AI 判断下一步的输入来源。测试、lint、构建给出的反馈，正在变成它的感官系统。
测试结果返回慢，AI 就慢。
lint 返回慢，AI 就慢。
构建返回慢，AI 也慢。
所以问题不再是“人有没有耐心等 10 分钟”。问题变成了：一次自动开发循环的反馈延迟是多少？一个 agent 在同样时间里能完成多少轮验证和修正？
以前工具链慢，是人在等。
现在工具链慢，是整个开发循环在等。
为什么以前没这么痛
以前人写代码，慢是默认值。
一个功能从理解需求到写完，可能要半小时、两小时，甚至一天。中间跑几次测试，每次慢一点，当然烦，但总耗时里还有大量人工思考、查资料、改代码、对齐上下文。
工具链的慢，被人的慢盖住了。
这不是说工具链性能以前不重要。只是它没有那么容易成为主要矛盾。
AI 把这个比例改了。
当一个改动可以很快被生成出来，真正决定节奏的就不是“代码出现得快不快”，而是“代码被验证得快不快”。如果 AI 30 秒写完，测试要跑 10 分钟，那么整个循环的速度并不由 AI 决定，而由测试决定。
这有点像把工厂里最慢的一段传送带暴露出来。
以前前面的工人动作慢，后面的传送带慢一点没人注意。现在前面换成了高速机械臂，传送带的速度就成了产线速度。
统一工具链为什么变得更有意义
尤雨溪在 D2 上讲 Oxc、Rolldown、Vite、Vitest，我理解它不只是“新工具更快”。
更重要的是，JS 工具链过去太碎了。这种碎，在人类开发节奏下可以忍；在 agentic loop 里，会被放大成系统成本。
parser、transformer、test runner、linter、formatter、bundler，各自有各自的实现，各自 parse 一遍，各自 transform 一遍，各自配置一遍。很多时间不是花在业务验证上，而是花在重复处理同一批代码上。
AI 时代，这种重复开销会被放大。
因为 AI 不会像人一样一天只认真跑几次验证。一个 agent 在修一个问题时，可能会非常自然地多次跑测试、多次跑 lint、多次做局部验证。它不觉得“麻烦”，它只是按循环推进。
如果工具链足够快，这种频繁验证会带来更高质量的代码。
如果工具链很慢，频繁验证就会把循环拖死。
所以 Oxc、Rolldown、Vite、Vitest 这类工具链的意义，不只是 benchmark 数字漂亮。它们是在把 AI 编程所需的反馈回路变短。
这也是为什么前端工具链的变化，对后端项目同样有启发。
语言、框架、业务形态可以不同，但 agentic loop 的结构是一样的：改代码，验证行为，读反馈，继续修正。慢的验证链路，会限制整个系统。
一个后端项目里的数据点
观点说到这里，需要一个足够具体的数字。
手边有个中等规模的 NestJS 后端项目，测试文件已经积累到 200 个左右。
迁移前，单测跑在 Jest 上。Jest 成熟、稳定、资料多，很多 NestJS 项目默认就是它。但随着测试数量增加，反馈时间开始变得很难忍。
一次完整单测跑到 580 多秒还没有结束。
这里要说清楚：不是 580 秒跑完，而是超过 580 秒仍未完成。所以这个数字只能作为旧流程耗时的下界。
迁到 Vitest + SWC 后，当时同一批单测完整通过：
Test Files 200 passed (200)
Tests 1299 passed (1299)
Duration 34.73s
只按这个下界算，也至少是 16.7 倍差距。真实差距大概率更高，因为旧流程没有等到结束。
后来项目又多了一些测试，当前版本复跑结果是：
Test Files 206 passed (206)
Tests 1314 passed (1314)
Duration 37.27s
shell total 38.345s
这个变化对 agentic loop 很关键。它不是一次工具迁移的“成绩单”，而是一个反馈回路变短后的样子。
30 多秒跑完整单测，AI 可以把它当成常规验证步骤。超过 10 分钟还没结束，AI 每一轮修正都会被迫停在原地。
为什么我会先动 test
如果只能先优化一个环节，我会先看 test。
原因不是 lint 不重要，而是 test 在 agentic loop 里提供的信息密度更高。
lint 主要告诉你规则、格式、一部分静态问题有没有踩线。test 更接近行为验证：service 的分支有没有断，controller 的返回有没有变，guard 的边界有没有破，provider 之间的契约还能不能成立。
AI 写代码时，最需要的不是“看起来格式正确”，而是“这个改动有没有破坏已有行为”。
所以单测如果很慢，AI 的修复循环会明显变钝。它可能能改，但每一次判断都要等很久。等得久，循环次数就少；循环次数少，能自我修正的空间就小。
Vitest + SWC 的收益就在这里。
它不是把命令名字从 jest 换成 vitest。它把“完整验证”从一个需要斟酌的动作，变成了循环里可以频繁发生的动作。
Oxlint 也是同一个方向。
lint 切到 Oxlint 后，日常 pnpm lint 基本进入秒级，甚至有时亚秒级完成。这里我不硬写倍数，因为没有保留迁移前 ESLint 的严谨基线。可以确定的是，它从“需要等一下”变成了“可以顺手跑一下”。
在 AI 编程里，这个差别很大。
快不是为了爽，是为了多跑几轮
工具链性能经常被说成“开发体验”。
这当然没错。命令快一点，开发者舒服一点，没人反对。
但在 AI 时代，只把它理解成体验还不够。
更快的工具链会改变开发策略。
测试跑 30 秒，你会倾向于让 AI 改完就跑完整测试。测试跑 10 分钟，你会倾向于只跑相关文件，甚至先不跑。lint 亚秒级结束，它就会变成每次修改后的自然步骤。lint 要等很久，它就会被推迟。
工具链慢，会让正确动作变贵。
工具链快，会让正确动作重新便宜。
对 agentic loop 来说，“便宜”很重要。因为 agent 不怕重复，它怕反馈慢。反馈越快，它越能多尝试、多修正、多收敛。反馈越慢，它越容易卡在单轮修改里。
这也是我现在看工具链性能的方式。
它不是锦上添花，而是在决定 AI 编程的吞吐上限。
不要把迁移写成追新工具
迁 Vitest、Oxlint，或者将来看 Oxc、Rolldown，不应该只是因为它们新。
追新工具很容易变成另一种折腾。
真正值得迁的理由，是它们能不能缩短反馈回路，能不能减少重复工作，能不能让 agentic loop 更稳定地跑起来。
这也是“一刀切”有时反而更合理的原因。
如果 Jest 和 Vitest 长期并存，短期看起来温和，长期会变成两套心智负担。mock API、globals、配置、覆盖率、watch 行为、类型声明，都可能出现微妙差异。AI 修改测试时，也更容易混用两套写法。
工具链基础设施最怕半迁移。
半迁移不是保守，很多时候只是把判断成本留给未来每一次修改。人要判断，AI 也要判断。判断多了，循环就慢，错误也会变多。
当然，一刀切不是闭眼替换。常用 mock、fake timers、覆盖率、e2e、integration 的边界都要确认。但确认之后，统一工具链本身就是收益。
最后的判断
AI 时代，工具链性能变得前所未有的重要。
不是因为大家突然都成了性能洁癖，也不是因为新工具名字更酷。真正的原因很朴素：AI 把代码生成速度大幅提高以后，验证链路就成了新的主要矛盾。
更准确地说，是 agentic loop 的主要矛盾。
AI 写代码，跑验证，读错误，再修代码。这个循环能不能快，取决于每一轮反馈能不能快。test、lint、build 不再只是命令行里的几条命令。
从 Jest 迁到 Vitest + SWC 的数据只是一个佐证：一个超过 580 秒仍未完成的单测流程，变成了 34.73 秒完整通过 200 个测试文件、1299 个测试用例。这个变化真正改变的，是循环速度。
工具链不应该成为 AI 编程里的红灯。
它应该是一条短而清楚的反馈回路：改一点，验一下，错了马上修，对了继续走。
写代码只是开始。
能快速验证代码还对，才是 AI 时代工程效率的底座。