立即开始黑客：一次价值 €XXM 的 API 迁移让我了解生产中的 AI

Source: Dev.to

概览

本周在 API Days Paris，我看到了一件罕见的事：一位客户和一位顾问一起展示了一个已经投入生产的 AI 项目。

Cyrille Martraire（Arolla 的 CTO）和 Thomas Nansot（某大型欧洲出行平台的工程总监）一起回顾了他们使用 AI 验证一次关键 API 迁移的全过程——该迁移每年处理数亿张票据。有什么不同？他们分享了所有的死胡同、失败的尝试，以及最终的解决方案与最初计划截然不同的过程。

问题

Thomas 所在的公司需要将系统从旧的 API 迁移到全新的架构。风险极高——任何回归都可能影响数百万笔交易。传统的测试方式成本高、速度慢，尤其是每一次合约变更都意味着要重新进行测试。

他们需要一种方法，在结构完全不同的两个 API 之间保证不出现回归。

6 大关键经验

1. 🔨 先黑客，永不打磨

当 Thomas 联系时，Cyrille 并没有索要需求文档。他直接搭建了一个带有假系统的临时原型，以证明概念可行。

经验： 在 AI 项目中，学习的速度胜过代码的打磨。你无法通过计划来跨越不确定性——只能通过原型来跨越。

# Quick prototype approach
legacy_response = fake_legacy_api()
new_response = fake_new_api()
ai_compares(legacy_response, new_response)
# Does it work? Kind of? Good enough to continue!

2. ⚡ AI 生成代码 > AI 执行测试

他们第一次尝试上线的方案很优雅：让 AI 代理全程完成。但它也出现了问题：

• 慢： 每个测试 2 分钟以上
• 贵： 每次运行约 $1
• 不可靠： 随机失败

突破点： 用 AI 生成测试代码，而不是让 AI 直接运行测试。

# ❌ Approach 1: Live AI (expensive, slow)
for each test:
    result = ai.compare(legacy_api(), new_api())  # $$$

# ✅ Approach 2: Generated code (cheap, fast)
test_code = ai.generate_comparison_code()  # Once
for each test:
    result = test_code.run()  # $0, deterministic

成本对比

• 实时 AI：$1 × 1000 次测试 = $1000
• 生成代码：$2 生成一次 + $0 × 1000 次 = $2

模式： AI 在“离线”状态下生成工具，真正的工作交给这些工具完成。

3. 🗄️ MCP：像查询数据库一样查询 JSON

API 的 schema 非常庞大。把所有内容塞进 LLM 的上下文会导致注意力分散——即使技术上能容纳，质量也会下降。

解决方案：模型上下文协议（MCP）

不要直接发送完整的 JSON：

prompt = f"Analyze this entire JSON: {10mb_schema}"

而是使用查询接口：

mcp = JSONMCPServer(huge_schema)
email = mcp.query_path("passenger.email")
keys = mcp.list_keys("journey.segments")

他们特别推荐 “JSON‑to‑MCP” 工具。
意义所在： MCP 就像把“这里有一本电话簿”升级为“这里有搜索接口”，从而实现可扩展的 LLM 交互。

4. 🎲 接受惊喜

“作为管理者，我原本期待能清晰预见哪种方案会成功。最后我不得不承认，最终的解决方案与我想象的完全不同——而且更好。” – Thomas

他们尝试过的方案

• 完全 AI 方案 → 太慢且成本高
• 切片对比 → 过于复杂
• 生成代码 + MCP → 成功！

获胜的方案并不在最初的计划里。短反馈循环和随时转向的意愿是关键。

思维方式： 如果你在 AI 项目中带入太多确定性，就会限制自己的可能性。让技术给你惊喜吧。

5. 💾 离线 AI > 在线 AI（有时）

核心洞见： “AI 有时在离线状态下更好。”

离线 AI 示例

• ✅ AI 生成测试套件 → 运行 1000 次
• ✅ AI 编写 Terraform 模块 → 多次 apply
• ✅ AI 创建校验规则 → 检查所有数据
• ✅ AI 生成文档模板 → 永久复用

6. 🎓 知识转移 > 专家全包

在验证技术概念后，Cyrille 的角色从“制造者”转为“教练”。

演进路径

1. 外部专家构建解决方案
2. 证明可行并获得认同
3. 专家手把手教内部团队
4. 团队独立运行
5. 学到的经验用于其他项目

影响： 即使是对 AI 持怀疑态度的工程师，也对这些技术产生了兴趣。真正的价值在于 解决问题 + 构建内部能力。

实用要点

✅ 应该做

• 从临时原型开始
• 优先使用生成的产物而非实时决策
• 对大数据结构采用 MCP 式模式
• 规划短反馈循环
• 构建内部能力，而非仅交付方案

❌ 不要做

• 等待完美需求文档
• 认为“全 AI”永远是答案
• 与上下文窗口限制硬碰硬——要想办法规避
• 事前把所有细节都计划好
• 将专业知识全部外包

“混乱的中间过程”才是重点

我最欣赏的是他们的坦诚。太多 AI 演讲只展示光鲜的最终成果，跳过了死胡同。而死胡同才是故事的核心——学习就在这里发生。他们没有完美的计划，只有假设、迭代的意愿以及被惊喜的勇气。这大概是最有价值的教训。

演示代码

我实现了这些模式的工作示例：[GitHub 链接]

仓库包含：

• 用于 JSON 查询的 MCP 服务器
• AI 代码生成示例
• 用于快速原型的假 API
• 生成式 vs. 实时 AI 对比

讨论问题

• 你在项目中尝试过 “AI 生成代码” 的模式吗？与实时 AI 相比效果如何？
• 在使用 LLM 时，你最大的上下文窗口挑战是什么？
• 在 AI 项目中，你如何平衡探索与规划？

演讲者

• Cyrille Martraire – Arolla CTO，《Living Documentation》作者
• Thomas Nansot – 工程总监，负责约 150 名工程师的出行分发平台，服务数百万欧洲用户

---

联系

• LinkedIn
• GitHub