文章目录前言1 这事到底有多大1.1 83万行是什么概念1.2 一个人十四周半2 他们怎么干的原地、原子、持续发布2.1 一个PR只搬一个组件2.2 整个流程长这样2.3 边界才是真难点3 数据把 Agent 的底裤掀了3.1 63万次PowerShell3.2 读比写多十倍3.3 快是真快但别上头4 回归没有消失4.1 深拷贝260MB日志4.2 测试神谕5 我的判断6 什么系统适合什么不适合6.1 想试点先挑软柿子6.2 每个切片都要留档案7 最后问一句P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看 传送门https://blog.csdn.net/HHX_01前言先说结论免得你们往下翻半天GitHub 最近放出一份工程复盘——他们让 AI 把 Copilot 的核心运行时从 TypeScript 整体迁移成了 83 万行 Rust。听起来很猛对吧更猛的是AI 真正使劲的地方根本不是写代码是读代码。读的量大概是写的十倍。什么意思你以为雇了个打字机结果来了个质检员还是那种一天敲六十三万下 PowerShell 的质检员。1 这事到底有多大1.1 83万行是什么概念先报账83.2万行生产 Rust46.8万行 Rust 单元测试17.4万行 TypeScript 端到端测试独立的 SDK 仓库还有约13万行多语言端到端测试。83万行是什么概念我写了十年代码所有项目加起来……嗯大概也能到——如果把删掉的也算上的话那就更多了。关键是这活是 AI 干的写的还是 Rust。我写过 Rust我知道那玩意儿就像让你用文言文写周报不是不能写是每写一行都觉得自己在渡劫。1.2 一个人十四周半项目历时约十四个半星期128 个拉取请求发了 135 个 CLI 版本100 个预发布、35 个稳定版。官方说按传统方式估算这活需要一个团队一到两年这次主要由一名开发者在几个月内干完了。一个人干一个团队的活。我合理怀疑剩下那些团队成员的主要工作是鼓掌以及给鼓掌的人鼓掌。不过丑话说前头这是项目方自己的复盘不是受控实验。就好比你家孩子考了满分你发朋友圈说他全靠自学——这个结论班主任未必同意。2 他们怎么干的原地、原子、持续发布2.1 一个PR只搬一个组件没有大爆炸重写也没有长期养两套实现来回切换。每个 PR 只迁移一个组件先用一层薄适配层让 TypeScript 继续调 Rust然后删掉旧实现。翻译成人话换心脏的时候人不下手术台边跑边换还要求本人毫无感觉。// 薄适配层外面还是那副老面孔里面悄悄换了人import{bindings}from./rust_runtime;exportasyncfunctionhandleTurn(input:SessionInput):Promise{// 调用方一个字都不用改改的是它背后的世界returnbindings.runTurn(input);}所有现有端到端测试立刻跑在新组件上主干始终可发布。你的仓库永远处于能跑状态——比我们大多数人的个人项目都健康。2.2 整个流程长这样选择边界清晰的组件 → Agent 阅读代码与测试 → 建立 Rust 实现 薄适配层 → 删除对应旧实现 → 单元 端到端验证 → 行为一致 ├─ 是 → 预发布小流量验证 → 稳定发布 └─ 否 → 回到建立 Rust 实现改到一致为止① 选边界清晰的组件 → ② Agent 读代码与测试 → ③ 建 Rust 实现 薄适配层 → ④ 删旧实现 → ⑤ 单元 端到端验证 → ⑥ 行为一致是 → 预发布小流量验证 → 稳定发布否 → 回到 ③改到一致为止2.3 边界才是真难点这招的精髓是每次变化足够小出了问题能和最近版本对上号。但边界难搞。会话编排这种组件有可变状态、有双向回调、还横穿一堆子系统。你想同时跑两套实现做对比门都没有。越是耦合的组件越要先拆边界、补测试而不是让 Agent 一口吞下去。这就像让实习生去整顿一团乱麻的电线。他一口吞下去的结果大概率是大家一起跳闸。3 数据把 Agent 的底裤掀了3.1 63万次PowerShell日志显示Agent 调用 PowerShell 约63万次、查看文件约59万次、用 rg 搜索约28万次、Git 检查约30万次。63万次 PowerShell。我认识的最勤快的运维同学一年也就敲这么多。而且他敲的时候还得骂两句Agent 敲的时候一声不吭——这才是最恐怖的。测试也没少跑pnpm test 约1.38万次cargo test 约8437次。它不是在写代码它是在不断确认当前状态对不对、分支漂没漂、依赖乱没乱、测试过没过。翻译AI 的日常不是创作是查岗。3.2 读比写多十倍Agent 工具调用次数约PowerShell 调用63万次查看文件59万次Git 检查30万次rg 搜索28万次读取、搜索、诊断类活动约为编辑活动的 10 倍约一个数量级。这个结构比生成了多少行更能说明问题写代码从来不是瓶颈理解代码才是。各位回想一下自己的一天写俩小时读一天开会再读一天。AI 只不过把人类的习惯用63万次 PowerShell 合法地重复了一遍。3.3 快是真快但别上头官方测试里客户端、会话、单轮交互从 5.25 秒降到进程内 Rust 的 292 毫秒恢复 32 轮会话从 5.64 秒降到 264 毫秒。什么概念你刚端起咖啡活已经干完了。原来还能借着加载摸个鱼现在连摸鱼的机会都没了。但别急着把Rust 比 Node 快 N 倍挂嘴边。人家原话不同部署路径、硬件和测量条件都会影响数字。翻译数字很美好现实很骨感。就像你健身教练的朋友圈永远只发练得最好的那张照片。4 回归没有消失4.1 深拷贝260MB日志截至 9 月 14 日团队追踪并修复了几十个已知回归迁移不完整、状态与生命周期、行为契约不一致、宿主边界、测试神谕错误五花八门。有个实现把 260MB 的事件日志深拷贝了一份。这不是迁移这是搬家的时候把整个小区的监控录像都拷走了一份。房东看了都感动然后让你删掉。还有个实现在持续事件流里一直留着异步句柄直到 V8 堆耗尽。垃圾回收器表示我劝过它的它不听。4.2 测试神谕测试神谕这名字一听就很有排面感觉是从希腊神话里请来的高级顾问。它的工作就一件事判断输出对不对。问题来了如果旧测试把历史 Bug 当成正确答案新实现越忠实问题就被永久保留得越完整。你以为是忠实还原其实是完美复刻了一个 Bug还顺手给它上了户口。// 旧测试历史 Bug 被当成正确答案expect(res.status).toBe(200);// 当年就是 200永远都是 200expect(res.cache).toBeUndefined();// 那行 cache 逻辑早坏了别问问就是特性旧测试只看返回值还会漏掉时序、内存和取消语义。迁移前应该把协议兼容、错误类型、日志副作用、资源释放、并发顺序全部写成契约再让不同层级的测试各守一段。说白了先立规矩再动手别让测试一边当法官一边兼职当被告。5 我的判断这不是一个人干掉一个团队的通用证明而是强测试资产把 Agent 产能变成可控变更的案例。代码行数是最耀眼也最不可靠的指标。主干可发布、回归可定位、性能可比较才是迁移能落地的真正原因。给管理者的话别按 Agent 的生成量规划项目。你想啊如果按字数发工资我们这行早就有人靠写 Bug 发家致富了。应该按可验证切片的数量规划每个切片配上明确的旧行为、测试神谕、性能基线和回滚路径。没有这些资产生成越快你懂的越少——就像车越开越快但车是租的路是黑的。6 什么系统适合什么不适合适合边界能逐步隔离、已有端到端测试、能频繁发布的系统。不适合缺乏观测、数据迁移不可逆、协议里全是隐式兼容行为的核心系统。安全或财务代码还得领域专家复核不能光靠 Agent 互审。Agent 互审是什么场面两个都喝多了的人互相搀扶着过马路。勇气可嘉但建议叫代驾。6.1 想试点先挑软柿子先挑解析器、序列化、格式化、纯计算模块。步骤冻结输入输出样例让 Agent 先解释现有行为再动手同时跑基准、属性测试、模糊测试预发布后盯着真实错误渠道看。目标不是一周写十万行而是一周完成一个可证明等价的切片。翻译别追求写得快要追求改完别人看不出来。6.2 每个切片都要留档案为什么迁移、哪些行为刻意改了、哪些兼容问题先放着、发现过哪些回归——都记下来。Agent 会话可以加速调查但别让它成为唯一知识库。不然几个月后线上出事故你对着一个空会话记录发呆就像删光了聊天记录才发现要找人对账。那个场面比迁移失败本身还惨。7 最后问一句如果让 AI 来迁移你的核心系统你会先挑哪类纯逻辑组件试水反正我不会挑会话编排。我还想保住我那 260MB 的日志。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01
