AI Agent + 自愈循环：ServiceTitan 如何将巨型遗留代码迁移从季度压缩到周
面对数百个跑在旧架构上的业务指标、背后是数万行文档不全的遗留代码，ServiceTitan 团队没有试图让 AI 变得更聪明，而是将任务分解到 AI 能独立完成并验证的粒度，再通过自动化“组装线”并行跑完。结果是 85% 的迁移工作由 AI 自主完成，项目周期从几个季度缩短到几周。本文基于 ServiceTitan 首席 AI 工程师 David Stein 在 QCon 的分享整理。
背景：被忽视行业的 AI 落地
在 QCon 上，ServiceTitan 首席 AI 工程师 David Stein 分享了一个反常识的解法：处理大规模的遗留代码迁移，不需要让 AI 变得更聪明，只需要把任务分解到它能独立完成并验证的粒度，然后用一条自动化“组装线”等待验收。实际数据显示，85% 的迁移工作能够由 AI 自主完成，剩余 15% 的复杂案例才需要人类工程师介入，整个项目周期从几个季度压缩到几周。
对于不熟悉 ServiceTitan 的读者，这里简单介绍背景。ServiceTitan 是为承包商和技工行业（住宅、商业、建筑服务、电工、管道、暖通空调等）提供端到端技术平台的厂商。技工行业长期被忽视，大部分工作仍依赖纸笔和 Excel 表格，迫切需要迁移到数字化方式。ServiceTitan 正在引领这场变革。
当前 AI 用例在很多场景中已近乎噱头——各种 demo 展示 AI 能做什么，但真正聚焦于核心业务服务的 AI 场景并不多。ServiceTitan 的 AI 实践包括工作价值预测（用于最优调度，提升效率和营收）、通话录音分析、语音 agent（7×24 小时预约服务）等。
大规模迁移如同高山
今天要聊的重点不是这些具体的 AI 产品，而是一个更普遍的挑战：当你手里有一堆跑在旧架构上的遗留代码，你知道必须动它，但你也知道动起来会非常痛苦。如果在一家公司待过超过两年，一定深有体会——遗留代码越积越多，越拖慢添加新功能和做变更的速度。
整个行业或多或少都参与过某种迁移项目。如果你在领导层或参与规划，也知道这类项目风险极高。当你决定把一大堆遗留代码迁移到新平台时，你不可能只完成 25% 或 50% 就收手，在很多情况下，你必须走完全程。这个“必须走完”本身就制造了巨大的风险——你绝对不想走到半路才发现自己卡住了，进退两难。
需要澄清的是，这里说的不是那种早就被自动化解决了的迁移（比如把数据库从一种格式迁移到另一种格式，写个脚本一键转换）。那是简单问题，早已被解决。这里讨论的是真正的硬骨头：几十万行遗留代码，有些是 5 到 10 年前写的，写代码的人早就不在公司，文档可能不全，单元测试覆盖率堪忧。把这些庞然大物搬进新的抽象层，简直是赫拉克勒斯式的任务。
案例分析：迁移 ServiceTitan 的报告指标
（本文为第一部分，后续将展开具体案例与自愈循环的实现细节）
关键要点
- 任务分解粒度：处理大型迁移时，不是让 AI 变得更聪明，而是将任务分解到 AI 能独立完成并验证的粒度。
- 验证器至关重要：当你用 agent 加速执行大型迁移项目时，验证器变得关键。尤其是在需要短时间内并行跑完大量迁移任务时，必须确保每一步运行良好，否则会很快偏离轨道。
- 复杂度隐藏：给 Cursor 等工具非常简单的事情去做，把复杂性隐藏在验证步骤和工具背后，确保它拥有解决问题所需的所有上下文。
- AI Agent 带来的变革：不只是让单个任务跑得更快，而是让你能以前所未有的速度完成曾经不可能的任务，从而去尝试新东西，做那些原本不会去做的事。
本文以ServiceTitan的报告指标迁移项目为例，展示了如何将AI与严格验证流程结合，把传统上需要数月甚至数年的遗留代码迁移任务，压缩到可管理的增量步骤中。核心在于将大问题拆解为可验证的小步骤，并利用AI加速执行与反馈。
案例：ServiceTitan 报告指标迁移
为了更具体地说明问题，我分享一个真实案例——ServiceTitan 的报告指标迁移项目。
ServiceTitan 的大部分应用都与报告相关：客户可以下载、查看并分析各种复杂的运营、财务及其他业务指标，涵盖工单、发票、技术人员、客户等。支撑这一切的底层代码是典型的遗留代码。部分技术组件连接生产数据库的方式，与我们今天从头构建时所采用的方式完全不同——这是极其常见的困境。
但真正棘手的是规模问题。在我们的场景中，有海量的业务指标，每一个指标背后都有一大块遗留代码在驱动，而每块代码又可能隐藏着大量依赖关系。有些依赖是架构层面的，有些则是隐性的——比如对数据库表结构的隐含假设，或对数据形态的默认依赖。要理清所有关系需要大量时间。按照传统方式，你会看到一个庞大的项目：需要成百上千张 Jira 工单，耗费数百个工程师周的时间，这意味着数个季度甚至数年的光景。
还有一个关键问题：在 AI 出现之前，迁移项目并不总能成功。在 ServiceTitan 的报告系统上，已不止一次尝试重构部分遗留代码并迁移到更好的架构。我们的案例正处于这种局面：团队花了一段时间试图拆解遗留代码，将其迁移到基于数据湖仓的新架构，过程中遇到了重重挑战，时间线一再挣扎。最糟糕的是，当你投入了几个月甚至几年，却发现项目进展与最初的预期完全不同。
那时你会开始质疑：这个方向真的对吗？这种处境很糟糕，会让很多人在规划这类项目时彻夜难眠。在我们的案例中，我们正盯着一个挣扎中的项目——一个团队在挖掘遗留代码时遇到了困难。于是我们开始用当时最前沿的编码 LLM 来审视他们正在处理的那些代码，想看看能否用不同、更好的方式推进，从而在迁移到新架构的过程中获得更好的进展。这就是接下来要讲的故事背景。
直面现实：AI 也无法一步到位
到了 2025 年，任何问题的默认解决方案都是：能不能直接问 AI？你有几百个指标要迁移，直接扔进 Cursor 里就行了。听起来很美好，对吧？但现实是，你不能直接让 Cursor 或 Claude Code 把你的整个遗留代码库迁移到你描述的新架构中。我确实试过，结果非常糟糕。理由和一个工程师无法独自完成这件事是一样的——这个任务太大了。
就算你是非常优秀的工程师，你也不可能直接去修复几十万行代码，把它们全部迁移到最新架构里。你可能会取得一些初步进展，但很快你就会发现自己面对着一座大山，根本无法理解所有遗留代码背后的上下文。队友离职了，文档缺失了，你只能一点一点地挖掘，进展极其缓慢。
而换成 LLM 来写代码呢？它会幻觉，会误解任务，会发明新的指标而不是迁移旧的，做了五个然后说“剩下的我会这么做：”就停了，而那做出来的五个还是错的。哪怕用上最先进的模型，你看到的全是这种问题。
关键洞察：分解与验证
所以关键洞察是什么？把问题分解成可以逐个验证的小步骤。这不是什么新想法，作为高级工程师或架构师，我们每天都在做这件事：把一个大问题拆解成可执行的子任务。但真正的新变化是：我们可以把时间线反转过来。
加速原则
几年前，规划一次大型迁移意味着要进行大量的前期调查。你得做概念验证（POC），评估可用方案，看看它们如何映射到现有技术栈，是否能满足所有需求，然后做决策，购买商业软件或选定开源方案，组建团队，再开始那个耗时极长的批量迁移过程，最终价值要到项目结束时才能完全实现。这些项目天生就极难排期。
但现在不一样了。我们可以在初期多做一些额外工作，在验证环节变得极其严格——严格到每个增量步骤都能被精确验证是否完成了该做的事。这就像并行化一样，你可以把原本需要几百个步骤的苦差事压缩到更短的时间窗口内，从而更早地实现全部价值。同时也能获得关于架构敏捷性的信号，能在几周内（而不是几个季度后）就知道新方案是否行不通。
先看迁移一个指标的场景。假设我团队里的工程师要把一个特定指标从旧系统迁移到新的指标存储系统（比如我们用的 DBT MetricFlow 和 Semantic Layer）。要完成这个任务，他需要一些上下文：需要知道旧代码在哪里，需要知道它依赖哪些数据库表，需要知道数据的真实样貌，甚至需要知道数据的分片信息。还需要了解目标模式是什么，以及架构师已经决定如何在新平台上下文中应用它。然后才能规划哪些文件需要改动、如何改动。接着才是编写代码，再验证这些代码工作良好、编写测试。最后才能发布工作成果。
如果把视野拉远到整个任务——不管它是 5 个步骤还是 500 个步骤——架构迁移的范畴其实都一样：架构目标会展开成这些子任务和子目标。这很简单，在 AI 时代之前我们也是这么做的。以前我们会用脑暴想出这些步骤，然后丢进 Jira 里（如果你喜欢 Jira 的话）。
但现在，如果你能把标准化的上下文获取、标准化的提示词以及强大的验证机制做到极致，确保每一步都能以足够高的确定性判断是否真的完成，你就可以把所有这些任务分配给机器人，然后以快得多的速度推进。
