Asana 使用 OpenAI Codex 重做一套过时的测试系统：原本预计需要五年的工程工作，在两周内完成，成本约为 12,000 美元。这个案例真正值得关注的，不只是代码生成速度，而是 AI 如何参与遗留系统替换、测试迁移和工程验证。
关键变化：从维护旧测试到重建测试能力
测试系统一旦过时，团队通常会陷入两难：继续维护它，工程师会不断为旧框架付出时间；直接替换它，又可能牵动大量测试用例、构建流程和发布门禁。
Asana 的做法说明，Codex 可以被用于更大范围的工程迁移，而不仅仅是生成几个函数。对于这类任务，AI 的价值通常集中在几个环节：
- 阅读旧测试代码，识别重复模式和隐含约定。
- 将测试用例映射到新系统的接口或执行模型。
- 批量生成迁移后的测试代码。
- 根据测试失败结果持续修正实现。
- 协助补齐边界条件和回归验证。
这类工作之所以适合 AI 辅助，是因为它包含大量结构相似、规则明确但人工执行成本很高的操作。不过，“两周完成”不等于可以跳过设计和审查。测试系统本身承载着质量门禁，迁移过程中最危险的情况不是代码报错，而是测试悄悄失去覆盖能力。
速度来自可验证的工程闭环
把 AI 引入遗留系统改造，不能只看生成了多少代码，还要看每一步是否可以被验证。一个实用的闭环可以是：
- 先让 Codex 分析旧测试系统的目录结构、运行命令和失败分类。
- 选取一小组代表性测试，建立新旧系统的行为对照。
- 批量迁移相似测试，并保留原测试作为参照。
- 在持续集成环境中运行新旧两套测试，比较通过率和失败原因。
- 对差异进行人工审查，确认是测试框架差异、产品行为变化，还是迁移错误。
- 逐步扩大迁移范围，直到新系统承担正式质量门禁。
这个流程的核心不是“让模型一次生成正确答案”，而是把大任务拆成许多可以运行、比较和回滚的小步骤。对于测试迁移，测试结果、覆盖率、失败日志和构建状态都可以成为反馈信号。
一个可改造的迁移脚本示例
下面是一个独立的 Python 示例，演示如何把旧测试目录中的测试文件清单生成迁移任务。它不是 Asana 内部代码，而是一个可以按实际目录结构改造的最小实践：先收集输入，再生成明确的迁移提示，避免一开始就让 AI 直接改动整个仓库。
运行前，将 OLD_TEST_ROOT 改成旧测试系统的目录。脚本只读取文件并输出任务清单，不会修改源代码。
from pathlib import Path
OLD_TEST_ROOT = Path("tests_legacy")
NEW_TEST_ROOT = "tests_modern"
def build_migration_plan(root: Path) -> list[str]:
if not root.exists():
raise FileNotFoundError(f"Test directory does not exist: {root}")
plan = []
for source in sorted(root.rglob("test_*.py")):
relative = source.relative_to(root)
target = Path(NEW_TEST_ROOT) / relative
plan.append(
"Migrate this test file while preserving behavior:\n"
f"- source: {source}\n"
f"- target: {target}\n"
"- preserve assertions and test intent\n"
"- document framework-specific changes\n"
"- do not weaken or delete assertions without evidence\n"
)
return plan
if __name__ == "__main__":
tasks = build_migration_plan(OLD_TEST_ROOT)
print(f"Generated {len(tasks)} migration tasks")
for index, task in enumerate(tasks, start=1):
print(f"\n## Task {index}\n{task}")
可以把输出任务交给 Codex，要求它一次处理一个文件，并在每次修改后运行对应测试。例如，团队可以采用类似下面的命令流程：
python build_migration_plan.py > migration_tasks.md
pytest tests_legacy/unit/test_users.py -q
pytest tests_modern/unit/test_users.py -q
pytest --cov=app --cov-report=term-missing tests_modern -q
命令中的路径需要替换成项目实际目录。关键检查点包括：新旧测试是否验证同一行为、断言数量是否异常减少、失败测试是否被正确分类，以及覆盖率是否出现无法解释的下降。
约 12,000 美元意味着什么
摘要给出的成本约为 12,000 美元。这个数字不能简单理解为“AI 以固定价格替代五年人工”，因为真实项目还包含人员监督、基础设施、代码审查和风险控制。更准确的理解是：当任务高度重复、输入输出边界清楚，并且拥有自动化验证时，AI 可能显著压缩交付周期和直接工程成本。
这也带来一个重要边界：如果旧系统没有可靠测试、构建结果不稳定，或者团队无法判断迁移前后的行为是否一致，Codex 生成得越快，错误传播得也可能越快。AI 适合加速可验证的迁移，不适合替代对系统行为的定义。
落地清单
准备使用 Codex 处理类似工程积压时，可以先确认：
- 是否能在干净环境中重复运行旧测试。
- 是否有明确的新旧系统对照指标。
- 是否可以将迁移拆成单文件或单模块任务。
- 是否保留原测试作为阶段性回归基线。
- 是否要求 AI 解释删除、放宽或重写断言的原因。
- 是否安排工程师审查测试覆盖和失败分类。
Asana 的案例给出的启发很具体：AI 编程工具的价值，不只在于写代码，而在于把大规模遗留系统工作变成一连串可执行、可观察、可审查的工程步骤。两周完成五年预期工作，依赖的不是一次神奇生成，而是任务拆解、自动验证和严格的质量边界共同发挥作用。