使用 Claude Code 进行 AI 优先集成工程：一次真实的调试会话

大多数“AI帮我写代码”的故事都是演示，提示清晰，结果也令人满意。但本文并非如此。这是一场真实的APIANT集成产品实战，包含了实际的提示、错误操作、纠正步骤，以及人类记忆力最终战胜机器的时刻。

关键不在于人工智能有多强大，而在于当你真正坐下来一起工作时，协作的实际效果如何。

设置

该产品是我们 CRMConnect 集成方案之一。 从 Mindbody 到 HubSpot一位客户反映，使用多种支付方式完成的销售交易同步出现错误。例如，一笔总额为 8,400 美元的订单，分三种方式支付，但在 HubSpot 中却显示为一笔 400 美元的交易。另外 8,000 美元则从销售流程中消失了。

我们在 GitHub Issues 中跟踪工程工作。客户对话则记录在 HubSpot Service Hub 中。会话开始时，构建者将 AI 指向了这项工作。

迅速的： “看看付款问题”

AI 搜索了代码库的 GitHub issues，找到了未解决的问题，提取了完整的问题描述，并朗读出来：这是一个多笔付款的销售漏洞，并提供了两个生产环境执行 ID 作为证据。无需任何指导。然后，它用清晰易懂的语言询问下一步操作，而不是猜测。

迅速的： “该逻辑执行什么操作以及需要执行哪些自动化操作？”

AI从平台加载了相关的自动化流程，逐步分析了其结构，并准确地解释了失败原因。该自动化流程会为每个HubSpot交易构建一个去重键。对于多方支付的销售，Mindbody会为每种支付方式返回一行数据，所有数据都共享同一个去重键，因此第二行和第三行与第一行创建的交易发生了冲突，它们的金额被静默删除。

有用。但建筑商已经占据了更明显的优势。

那个改变一切的线索

迅速的： “请将这笔交易的唯一标识符与我们在 crmconnect-mindbody-zoho 项目中的处理方式进行比较。我以为我们已经解决了这个问题。请进行一次重点对比。”

这句话改变了整个工程的走向。施工人员没有给出具体的解决方案，而是指着一个同系列产品，实际上是说，去看看说明书。

于是人工智能照做了。它打开了…… Mindbody 到 Zoho 集成程序（一个完全独立的产品）找到了处理历史销售数据的自动化程序并读取了它。然后，它找到了写入支付记录的子程序并读取了它。不是汇总数据，而是实际的自动化逻辑，一步一步地执行。

它返回了一份重点对比报告。Zoho 集成确实解决了这个问题，但采用了不同的架构：

• HubSpot 产品使用 Mindbody 的旧销售端点，为每笔销售交易编写一个固定的交易，该端点返回预先拆分的付款行。
• Zoho 产品会写入一条父级购买记录，以及单独的子级记录，分别用于记录订单项和付款，使用 Mindbody 的较新端点，其中每笔付款都有其自己的真实付款 ID。

人工智能的判断是 Zoho 在架构上更清晰，它最初建议将整个三对象模型移植到 HubSpot 中。

建造者缩小了范围

正是人类让一切脚踏实地。

迅速的： “V4.0版本还没准备好。先放一放，现在我们需要解决客户反馈的交易信息缺失问题。”

人工智能一度倾向于对架构进行令人满意的重写。但开发人员将其重新聚焦于实际问题：客户需要的是正确的交易金额，而不是新的数据模型。人工智能对此表示赞同，将重写方案列为未来事项，并将工作范围重新调整为对现有交易自动化流程进行精准修复。

这个修正很重要。人工智能擅长找到简洁的通用解决方案，但它并不总是能判断出简洁的解决方案是否超出了当前的需求。而构建者用一句话就给出了这个判断。

人工智能随后借鉴了 Zoho 的设计理念，但并未照搬其结构：每个销售明细对应一笔交易，数据来源于 Mindbody 更丰富的接口，并正确汇总不同支付方式的金额，而不是让第一笔付款覆盖其他付款。不同的平台，不同的操作，但核心理念相同。

预感

在重新设计去重密钥时，人工智能分析了密钥的一个组成部分：日期。它的推理很清晰。销售 ID 和销售明细 ID 已经足以保证密钥的唯一性，日期是多余的。因此，它建议删除日期，以简化密钥并消除两个自动化流程之间的安全隐患。

这位建筑工人没有规范依据可以争辩，但他有记忆。

迅速的： “我好像记得我添加日期是因为需要（比如同一笔交易中有两笔付款，或者类似的奇怪情况）？”

他们俩都无法从当前的自动化流程中验证这一点。于是，人工智能开始查看自动化流程的版本历史记录。该流程保存了93个版本，最早可追溯到2021年。人工智能读取了变更描述，直到找到相关的变更。

自2022年1月起：

“新增 EPOCH MILLIS 交易 ID 保存功能，以便在对同一商品进行多次付款时保持交易 ID 的唯一性。”

自2022年2月起：

“已为按自定义房产查找交易添加了销售日期，以便处理之前销售的付款”

用开发商自己的话说，那是四年前的事了。当客户之后支付之前订单的款项时，Mindbody 会根据新的日期重新生成该订单。如果密钥中缺少日期信息，后续付款就会与原始订单冲突，无法生成自己的记录。这个日期并非多余，而是至关重要的，特意添加进去是为了处理分期付款和自动付款。

人工智能的回应是立即撤回了之前的建议，并明确表示：

“相信你的记忆。如果你是特意添加的日期，它就具有承重作用，删除它是行不通的。我在版本历史记录里找到了它。”

它更进一步。由于日期必须保持不变，两个自动化流程必须生成完全相同的日期值，否则键值将不匹配，导致出现重复交易。原始自动化流程根据 Mindbody 中的一个特定字段生成日期。人工智能将新的自动化流程重新指向同一个字段，通过相同的 API 调用，并使用相同的时区转换。相同的输入，相同的输出，确保键值匹配。

原本可能悄无声息地破坏分期付款处理的退步问题最终并未发生。这并非因为人工智能足够谨慎，而是因为人类凭借直觉做出了判断，而人工智能只需几秒钟就能根据四年来的历史数据进行验证。

不那么光鲜的部分：构建、运行、读取跟踪信息、修复

设计方案确定后，便进入了迭代工程阶段。在开发环境中构建变更，运行，读取执行跟踪，找到下一个问题，修复，然后重新运行。真正的 bug 都是些普通的 bug：

• 一项促成交易的步骤失败了，共有十六人参与。 PROPERTY_DOESNT_EXIST 出现错误是因为字段绑定未包含 HubSpot 的内部属性名称。人工智能读取了跟踪信息，获取了连接器的字段架构，并使用正确的 ID 重新绑定了每个字段。
• 由于平台以源数据中最长的数组为基准计算迭代次数，而支付数组比明细数组长，因此循环执行了两次，而它本应只执行一次。人工智能插入了一个显式的迭代控制，使循环只计算明细项。
• “查找交易”步骤在尚未找到任何交易的情况下导致整个流程停止，因为其默认错误模式将“未找到”视为致命错误。人工智能将其切换为“出错时继续”，以便创建分支步骤能够运行，这与同级自动化流程的处理方式一致。

这一切都不光鲜亮丽，而是集成工作的真实面貌。改变的是循环速度。人工智能可以读取完整的逐步执行跟踪，并立即指出出错的步骤，因此每次修复周期只需几分钟。在开发测试通过之前，任何产品都不会交付给客户。

这对建筑商意味着什么

抛开叙述，这就是工作模型：

• 人工智能的优势在于阅读。 它研究了整个兄弟产品集成方案，交叉参考了我们已经解决的问题，在两个不同的平台上适配了架构，并翻阅了九十个版本的历史文档来验证一个设计决策。没有人能在一下午的时间里完成这些工作。
• 人类的优势在于记忆力和判断力。 “我觉得我添加这个是有原因的”这句话不在任何文件中。“尚未准备好发布 V4.0”这句话也不在任何文件中。这两句话都源于我对产品的使用体验。每一句都改变了最终的结果。
• 速度来自这个回路。 读取跟踪信息，修复错误步骤，重新运行。通常会拖慢调试速度、重现问题发生的阻力消失了。

AI优先的集成工程并非AI单打独斗，也并非人类工作速度更快。它指的是AI完成人类无暇顾及的读取工作，而人类则提供代码库记录之外的上下文信息。将二者结合起来，一个存在了四年之久的反复出现的bug就能在一次工作会话中被理解、修复和验证。

这才是值得努力构建的工作流程。