大规模存量代码迁移这件事，每个工程师团队都怕：动一个函数，回归测试挂一片；不动，技术债越积越多。AI 工具确实能加速改代码，但加速"改坏代码"同样快——没有安全网的 AI 重构，是一场灾难。

Datadog 工程团队最近分享了一套很值得抄作业的实践：用 Claude + Cursor 做"测试驱动式"生产环境迁移。核心是把 TDD（测试驱动开发）从"写新代码"扩展到"大规模存量代码迁移"，借助 AI 把行为契约先固化下来，再用测试做安全网。

这篇教程拆解 Datadog 的三阶段方法，并给出可复用到你自己代码库的工作流。

方法概览：意图 → 测试 → 迁移

Datadog 的方法分三步，每一步都用到了 AI 工具，但人始终在关键节点把关：

这个顺序的关键在于：先有测试，再动代码。和传统的"先迁移、再补测试"完全相反。

第一步：用 Claude 描述意图

迁移最容易出问题的地方不是"代码改错了"，而是"代码改对了，但行为变了"——你以为某个边缘 case 是 bug，其实是上游依赖的契约。

所以在动任何代码之前，先把每个关键函数的行为意图写下来：

• 这个函数的输入应该是什么？
• 它应该返回什么？
• 有哪些边缘 case 是必须保留的？
• 有哪些副作用（写日志、调外部 API、修改全局状态）？

用 Claude 来辅助这件事，提示词大致是：

下面是我们即将迁移的函数源码：

```python
def normalize_event(raw):
    ...

请基于这段代码，为它写一份"行为意图说明"：

1. 这个函数的核心职责是什么
2. 输入参数的类型、范围、约束
3. 输出的类型、结构、约束
4. 你能从代码中识别出的所有副作用和边缘 case
5. 哪些行为是"看起来像 bug 但实际是被依赖的契约"

只输出说明，不要修改代码。

> 💡 **提示**：让 Claude 关注第 5 点非常关键——存量代码里很多"看起来像 bug"的行为，实际上是某个上游模块在依赖。改了就出事。

输出是一份自然语言的"行为契约"，作为下一步写测试的依据。

## 第二步：编写聚焦测试

有了意图说明，就可以写针对性的测试了。这一步是**人工 + AI 共同完成**：

- 人工：决定要锁住哪些行为（哪些是核心契约，哪些是边缘 case）
- AI：基于意图说明快速生成测试用例代码

测试的目标不是"覆盖率 100%"，而是**锁住关键行为**——尤其是那些迁移过程中最容易被破坏的行为。

用 Claude 生成测试草稿：

```text
基于下面这份行为意图说明，为这个函数生成针对性的 pytest 测试用例：

[贴入第一步的意图说明]

要求：
1. 覆盖所有"核心契约"行为，至少 2 个测试用例
2. 覆盖所有"边缘 case"行为，每个至少 1 个用例
3. 覆盖所有"看起来像 bug 但实际是被依赖"的行为，每个一个用例并加注释
4. 用例要能在迁移前后都通过（不依赖具体实现，只依赖行为）

人工 review 这份测试草稿，补充 AI 想不到的边界情况，删掉冗余用例。

💡 提示：这一步要"钉死"测试。迁移开始后，这些测试是安全网——任何一次改动如果让测试失败，必须停下来确认是测试过时还是代码真的出问题了。

第三步：用 Cursor 执行迁移

测试就位后，就可以放开手脚做迁移了。这里 Cursor 派上用场——它的代码库上下文能力非常适合大规模重构。

工作节奏：

1. 小步迁移：一次只迁一个模块或一组相关函数，不要一次性大改
2. 跑测试：每次小改动后立刻跑测试套件
3. 红绿循环：测试挂了 → 修代码或修测试 → 测试全绿 → 进入下一轮
4. 人审查 diff：Cursor 生成的迁移代码，必须人工 review 才能合入

在 Cursor 里，可以用这样的方式发起迁移：

@Context: 选中要迁移的模块
@Files: 引用相关测试文件

请把 @normalize_event 从旧的事件格式迁移到新的 v2 格式。
要求：
1. 保持测试 [贴入文件名] 全部通过
2. 保持行为意图说明中描述的所有契约不变
3. 输出 diff 形式的改动，并标注每一处改动的理由
4. 如果遇到测试没覆盖到的歧义行为，停下来问我，不要自己决定

关键设计是第 4 条——让 AI 在不确定时停下来问人，而不是自己决定。这是测试驱动式迁移能保住质量的根本。

把线上可观测性带进 IDE

迁移完成后，最大的风险是"测试都过了，但生产挂了"——因为有些行为是测试覆盖不到的，比如依赖真实流量模式、真实数据分布的问题。

这就是 Datadog 这套实践特别聪明的地方：Datadog 官方提供了 Cursor（和 VS Code）的 IDE 扩展，能把线上的可观测性数据（telemetry、logpoint、error tracking）直接带进编辑器。

迁移后如果某个函数在生产里出问题，你不需要切换到 Datadog 网页去翻日志——在 Cursor 里就能直接看到这个函数的真实错误率、慢请求样本、堆栈。

• Datadog Cursor 集成文档：https://docs.datadoghq.com/integrations/cursor/
• Datadog IDE 扩展文档（VS Code/Cursor）：https://docs.datadoghq.com/ide_plugins/vscode/

💡 提示：即使你不是 Datadog 用户，这个思路也可以套用——把任何形式的线上可观测性（Sentry、Grafana、自建 APM）带进 IDE，让"测试 + 线上数据"共同构成迁移后的安全网。

验证结果

一次完整的测试驱动式迁移，验证标准应该是：

1. 所有聚焦测试 100% 通过
2. 线上指标（错误率、延迟、QPS）在迁移前后无显著变化
3. 代码 review 中没有任何"行为是否变了"的悬而未决问题
4. 意图说明文档更新到位（新版本的行为契约是什么）

常见问题

• 如果存量代码本来就没测试怎么办：这正是这套方法的最大价值——用 AI 帮你"补"出测试。从行为意图说明反推测试，比从代码反推测试更可靠。
• AI 生成的测试本身错了怎么办：人审查永远是最后一道关。AI 生成测试后，至少人工跑一遍核心用例，确认它们确实在测对的东西。
• 这个方法只适合 Datadog 这种规模吗：不是。方法的本质是"先固化行为，再动代码"，对任何规模的迁移都适用。小项目甚至可以跳过 Datadog 扩展，只用 Claude + Cursor + 一份测试就够。

写在最后

Datadog 这套实践的精髓不是"用了 Claude 和 Cursor"，而是把 TDD 的思想正确地迁移到了"大规模重构"这个新场景——先用 AI 把行为契约固化下来，再用测试做安全网，最后才在保护下放手让 AI 改代码。

官方案例报道见 InfoQ： https://www.infoq.com/news/2026/07/datadog-ai-production-migration/

诚实声明：本文基于 InfoQ 对 Datadog 工程实践的公开报道撰写。具体迁移的代码量、耗时等数字，原文未给出精确值，本文不杜撰；只表述为"大规模、生产级"的工程实践案例，而非 Datadog 发布的新产品。