{"id":"mb-20260827-7c90bb","account":"mubei","brand":"","title":"硅谷一家公司开出 600 万美元的预算，打算让 4 名工程师花整整 5 年，只做一件事：重写代码库里的老旧测试","summary":"硅谷一家公司开出 600 万美元的预算，打算让 4 名工程师花整整 5 年，只做一件事：重写代码库里的老旧测试","body":"硅谷一家公司开出 600 万美元的预算，打算让 4 名工程师花整整 5 年，只做一件事：重写代码库里的老旧测试。\n两周之后，这个 5 年的项目被彻底清空。\n消耗的算力账单只有 1.2 万美元。\n这笔把成本打掉 99.8% 的账单，发生在 Asana 的真实代码库里。\n原本要耗死 4 个人 5 年青春的技术债务，在 AI 面前只撑了不到两周。\n是当初 600 万美元的工时估算在层层虚报，还是软件工程底层的某条旧规则被击穿了？\n很多人的第一反应，是工程师在故意夸大工作量。\n软件行业确实有一种防御性报价：面对没人想碰的脏活，团队会给出一个高到离谱的工期，逼管理层放弃立项。\n但如果把这次重构的代码摊开来看，那个 5 年的数字，并非凭空捏造。\nAsana 要做的，是把整个前端测试系统从过时的 Enzyme 迁移到现代的 React Testing Library。\n表面看只是换个测试库。\n底层却横跨着一条三十年来传统转换工具跨不过去的鸿沟。\n跨范式语义重构。\n过去几十年，软件工业处理大规模代码迁移，靠的是基于抽象语法树（AST）的自动化转换脚本。\n语法树脚本擅长做结构替换：把旧的变量声明换成新的，把旧的函数调用换成新的接口。\n这种工具生效的前提，是新旧两套代码遵循同一种设计范式。\nEnzyme 和 React Testing Library 的底层哲学完全对立。\nEnzyme 走的是内部状态测试路线。\n它直接刺入组件内部，检查私有状态、内部变量和组件实例。\n2018 年 Kent C. Dodds 推出 React Testing Library，立下一条新准则：测试越贴近用户的真实操作，能给你的信心就越足。\n它把内部状态全部封死，只看渲染出来的真实 DOM，模拟真实用户去点击屏幕、观察文字变化。\n两套测试在代码层面上几乎找不到一行相同的语法结构。\n语法树转换脚本在这一刻彻底失效。\n要把几千个测试文件翻新，过去只能靠人类工程师通读原来的业务逻辑，在脑子里理解测试意图，再用完全不同的哲学重新写一遍。\n枯燥、庞大、极易出错，而且对业务没有任何直接的新功能产出。\n这种跨越抽象层级的语义翻译，过去是人类独占的认知能力。\n大模型恰恰在这个能力断层上，打穿了第一道缺口。\n它不需要逐行匹配语法树规则，它能同时吃下组件源码和旧测试，理解测试的真实意图，直接吐出符合新哲学的代码。\n更关键的秘密，藏在测试重构这门任务独有的物理环境里。\n闭环确定性验证沙盒。\n大模型写全新业务功能时，常常因为幻觉而难以落地。\n但在测试迁移这个场景下，软件工程提供了一个天然的裁判系统。\n代码改得对不对，不需要产品经理去猜。\nTypeScript 编译器、代码规范检查器、自动化测试套件，每秒都在给出毫无歧义的布尔值判决。\nAirbnb 在迁移 3500 个测试文件时，同样摸清了这台机器的运作逻辑。\n他们让大模型在重试闭环里运转：生成代码，跑测试，如果报错就把错误栈直接喂回上下文重新推理，直到通过。\n最终实现了 97% 的自动化通过率，把 1.5 年的工期压缩到了 6 周。\n过去数十年，阻碍企业清理历史遗留代码的，不是重构有多深奥，是跨范式翻译的边际成本高到无法承受。\n当语义重构遇上确定性的运行沙盒，这笔沉睡了多年的技术债务税，第一次被算力直接抹平。\n软件工业里的很多顽疾，从来不是缺乏解决方案。\n当解决一件脏活的成本从几百万美元跌落到几十块电费时，旧系统赖以生存的借口，也就跟着一起瓦解了。","category":"科技","score":null,"translated_x_url":null,"translated_status_id":null,"published_at":"2026-08-27 21:12:40","created_at":"2026-08-27 21:12:40"}