大多数团队连让AI写个函数都要review三遍，DoorDash直接把整个iOS测试套件扔给了Copilot。更离谱的是，他们还真做成了——而且没翻车。
DoorDash工程师Matheus Gois最近分享了这套操作：用AI把基于XCTest的老测试框架，整体迁移到苹果新一代的Swift Testing。不是小打小闹，是涉及数万行测试代码、跨数十个团队的大规模工程。关键是，他们没靠堆人，靠的是一套"AI+规则+可靠性闸门"的组合拳。
老框架有多拖后腿？CI管道快被撑爆了
Gois的描述很直白：随着App和共享包膨胀，iOS CI的测试环节已经拖到"两位数分钟"。XCTest的致命伤是串行执行——测试一个个排队跑，资源吃得多，工程师迭代慢。
Swift Testing的并行能力把执行速度拉高了4到7倍，同步和异步代码都能并行跑。另一个隐形收益是#expect宏（宏是一种代码生成机制），失败信息比XCTest的XCTAssert丰富得多，Debug时间直接压缩。
但迁移本身是个苦活。XCTest和Swift Testing的语法差异不算巨大，却足够繁琐：改import语句、换断言宏、插@Test装饰器、处理async/await转换——全是机械劳动，但量大到让人绝望。
DoorDash的解法不是招人，而是造工具。
工具链设计：让AI待在舒适区里干活
他们搭了一套开发者环境，核心三件套：Cursor（AI编程助手）、SweetPad（Visual Studio Code与Xcode的桥接插件）、以及一个定制的MCP服务器。
MCP服务器的作用是把构建和测试动作暴露给AI。Gois解释：「主工具是execute_vscode_command，接收sweetpad.build.build或sweetpad.build.test这类命令ID，直接执行。」服务器随SweetPad扩展自动启停，工程师不用离开编辑器就能完成"改代码→构建→测试"闭环。
这步设计很关键。很多团队用AI写代码，最大的摩擦是让AI理解项目结构和构建流程。DoorDash把这部分能力封装成可调用的工具，AI只需要关注"改什么"，不需要懂"怎么跑"。
迁移规则被写成明确的指令集：自动替换import、断言宏转换、插入@Test、处理异步语法。Gois说，这让工程师能把精力放在"正确性验证"上，而不是纠结语法细节。
可靠性闸门：10次连续通过才算数
AI改代码最怕什么？ flaky test（不稳定测试）——今天过、明天挂，查半天发现是时间敏感或状态污染。DoorDash的应对简单粗暴：每条迁移后的测试必须连续通过10次，才能进代码库。
这个门槛过滤掉了绝大多数隐性Bug。Gois强调，团队把Bazel（构建工具）放在可靠性故事的中心：「无论从本地终端触发，还是通过SweetPad和Cursor跑，目标相同、10次通过的规则相同。」
迁移中途，DoorDash切到了Bazel构建系统。这要求他们扩展Agent工作流——把bazel test命令直接写进Prompt，让Agent能本地自动跑测试。更激进的是迭代循环设计：Agent跑测试、修报错、再跑、再修，直到干净执行。
这种"无人值守"的修复循环，依赖的是Bazel的可复现构建和测试能力。换作其他构建系统，同样的Agent可能陷入"修A坏B"的无限循环。
组织设计：谁的地盘谁负责
技术方案再顺，跨团队执行都是坑。DoorDash定了三条原则：
第一，团队自治。每个团队负责自己模块的测试迁移，用同一套工具和共享指南，但节奏自己把控。
第二，工具优先。Workflow必须一致、可重复，不能这个团队用脚本、那个团队手工改。
第三，可靠性硬门槛。10次连续通过是铁律，没商量。
Gois没提具体人数和工期，但从"规模化迁移"的表述看，这绝不是小范围试点。更值得关注的是时机：迁移中途切Bazel，说明工程决策是动态调整的，而非一次性规划。
这件事的真正价值在哪
DoorDash的案例给了一个反直觉的启示：AI代码迁移的瓶颈不是AI能力，而是工程基础设施。
Cursor本身不会知道你的构建命令、测试目标、项目结构。DoorDash花的力气，是把这些东西封装成AI可调用的工具——MCP服务器、SweetPad集成、Bazel命令注入。AI只是执行层，真正的工程智慧在"怎么让AI能安全地执行"。
10次连续通过的可靠性闸门，看似保守，实则是对AI输出的不信任投票。这种"不信任但善用"的态度，可能是大规模AI工程化的正确姿势。
另一个细节：迁移规则是人工定义的，不是让AI自己摸索。这说明当前AI更适合"有明确规则的转换"，而非"理解业务逻辑的重构"。XCTest到Swift Testing的语法映射是确定的，所以能自动化；如果是架构层面的测试策略调整，AI可能帮不上忙。
对于正在考虑类似迁移的团队，DoorDash的路径可复制性取决于三点：你的构建系统是否支持可复现测试？能否把测试执行封装成AI可调用的工具？有没有硬性的可靠性闸门过滤AI的失误？
如果答案都是Yes，或许你也能让AI吃掉那些没人愿意碰的技术债。
热门跟贴