先看测试人最容易忽略的那一步
接口字段改动不会平均影响全部用例。真正危险的是：字段看似只多了一个枚举值，AI却按照旧规则批量维护断言，把“部分退款”仍当成“退款完成”。这篇把接口维护从“改脚本”改成“判影响”的流程。
为什么原来的测试直觉不够用
订单接口新增 refund_status=partial 后，客服页、对账、优惠券返还都可能变。不要让AI直接改500个断言；先让它把变更翻译成：哪些状态机迁移新增、哪些下游接口消费该字段、哪些旧断言会把部分退款误判成完成。
排查不要从模型开始
第一步，锁定业务不变量：部分退款后订单不能变成已关闭；已退金额加剩余金额必须等于原支付金额；优惠券只能按实际退货金额回补。第二步，让AI从OpenAPI、历史用例和调用关系中生成“候选影响清单”，但候选不是最终答案。第三步，测试工程师只审核高风险链路，并把确认结果沉淀成下一次可复用的规则。
可进入回归的最小验证
assert order["refund_status"] == "partial"
assert order["refunded_amount"] + order["payable_amount"] == order["paid_amount"]
assert order["status"] != "closed"
这三条断言的价值，不是证明接口有字段，而是拦住AI把业务状态压扁成“退款成功/失败”两个值。把它们放到契约回归中，后续再有类似枚举变更，AI才能先指出风险而不是安静地改绿用例。
把这件事接进日常质量门禁
最后，给每次AI维护留一份变更报告：它建议改了哪些断言、没有改哪些、依据是字段说明还是历史Trace。3人团队真正省下来的不是敲代码时间，而是不用再靠记忆排查“这个字段到底牵动了谁”。
别把“最终看起来没问题”当成通过
AI 系统的难点在于，同一个表面结果可能来自不同路径：模型可能猜中了，也可能绕开了关键工具；脚本可能跑完了，也可能把业务断言改弱了；数据可能很多，也可能根本不满足业务约束。测试时必须把“结果对不对”拆成“输入是否可信、过程是否越界、动作有没有副作用、失败时有没有停下”。
一个很实用的工作习惯是，每次只挑一条高风险链路做证据闭环：记录输入、模型或Agent的决策、工具参数、服务返回、最终状态。它不需要昂贵平台，先用JSON日志和一组pytest断言就可以。等这条链路跑稳，再把同一套证据结构扩到其他业务。
新手落地清单
- 选一个金额、权限或订单状态相关的风险，不从“让AI写更多用例”开始；
- 写清通过条件和必须失败的条件；
- 把输入、关键Trace和最终副作用保留下来；
- 模型、提示词、工具Schema或页面发生变化时，优先重跑这批高风险样本；
- 复盘失败时，先归类为数据、模型、工具、规则还是环境问题，再决定修复。
这样做的价值不是把每个AI行为都变成确定性，而是把最不能接受的不确定性提前暴露出来。
为什么“加更多测试用例”常常无效
很多团队遇到Agent事故的第一反应，是再补十条相似问法。但如果十条用例只比较最后回复，它们仍可能一起放过错误路径。真正需要增加的是分叉：订单号缺失时必须转人工；取消未成功时不得直接退款；退款工具超时后必须先查询执行结果；跨账号订单永远不能作为候选。每个分叉都对应一个必须可见的Trace事件。
把这些分叉写成状态机，比把提示词写得更长可靠。状态机的好处是，它能让产品、研发、测试同时看到：哪一步允许自动继续，哪一步必须停下，哪一步需要人工确认。Agent Harness 的价值也在这里——把原本藏在模型语言里的行为，变成能回放、能对比、能回归的工程对象。
CI里怎么设门禁
不要一上来追求“所有Agent用例100%通过”。建议先分级：金额、权限、删除类操作的行为断言零容忍；普通咨询允许措辞不同，但关键事实不能错；低置信度问题必须产生转人工事件。模型更新时先跑这批小而尖的用例；有一条高风险轨迹越界，就不让版本进入下一阶段。
这套方法也能迁移给传统自动化同学。你熟悉的接口断言、状态机、Mock和回归集都没失效，只是断言对象从HTTP响应多了一层Agent决策与工具轨迹。
