代码能跑，就算接好支付了吗？Alipay-PIBench 给开发者的三条建议
摘要：代码生成不等于支付接入完成。Alipay-PIBench 用真实项目观察 Coding Agent 能否建立支付闭环并处理异常；最新在线结果显示，加载官方支付 Skill 后，7 个模型配置的平均完成度提升 9.87 个百分点，新增的 Cost 指标让开发者能够同时评估完成质量与运行成本。
在 Coding Agent 里输入一句“帮我接入支付”，几分钟后，页面上可能已经出现支付按钮，后端也多了创建订单的接口。看起来，任务完成了。但如果用户重复点击支付会怎样？支付通知到达两次，会不会重复发货或重复开通会员？客户端显示“支付成功”时，服务端是否真正确认了交易？通知里的订单号或金额不一致，业务状态还会不会继续向前推进？
支付接入真正困难的地方，往往不在第一次成功，而在第二次、失败时和异常边界中。
这也是我们构建并开源 Alipay-PIBench 的原因：希望用更接近真实开发过程的方式，回答一个实际问题——Coding Agent 写出的支付代码，距离一次可信交付还有多远？
Benchmark 是什么：把“接好支付”变成可以检查的任务
Alipay-PIBench 不是让模型补全一个函数，而是让 Coding Agent 在 Claude Code 框架中直接修改真实项目。
当前 Benchmark 覆盖 9 类支付产品和 8 个真实项目，共形成 18 个任务。每类产品包含两个递进、但独立初始化和评测的场景：
- Basic：把支付闭环接通。 包括创建交易、发起支付、由服务端确认结果，以及更新本地订单或权益状态。
- Advanced：让支付链路经得住异常。 包括通知验签、重复通知、幂等处理、异常交易状态、退款边界和资金安全等要求。
图 1：Alipay-PIBench 把支付产品、真实项目和业务要求组合成 Basic 与 Advanced 两类任务，并比较同一条件下加载与未加载官方支付 Skill 的表现。
以健身会员项目为例，Agent 不能只创建一个待支付订单并拉起收银台。它还需要由服务端创建并确认交易，在可信结果到达后更新订单、开通会员；客户端回调不能直接决定最终支付状态，重复通知也不能导致权益被重复发放。
带着这个标准，我们再看三个对开发者最直接的发现。
发现一：选 Agent 配置，不能只看总分，也不能只看价格
为了便于阅读，本文把 RPR（Rubric Pass Rate）称为“任务要求完成度”，也就是评测要求被满足的比例。它用于比较本次 Benchmark 中的配置，不代表生产交易成功率、资金安全率或上线结论。
在线 Benchmark 统一采用 Claude Code 框架 + 官方支付 Skill。在综合完成度上，Kimi K3 为 92.90%，Claude Opus 4.8 为 91.37%，GLM-5.2 为 87.12%。
但总分只是第一层信息。同一个模型在不同支付产品、Basic 和 Advanced 场景中的表现并不完全相同。论文中的六模型实验已经能看到这种差异：有些模型整体稳定，有些模型在个别产品上更突出，也有些场景对所有模型都更难。
图 2：论文中的六模型实验结果。每个格子对应一个模型在某类支付产品和 Basic / Advanced 场景下的完成度；在线榜单现已新增 Kimi K3。
因此，“榜单第一”不能直接翻译成“适合所有支付场景”。特别是 App 支付、预授权等波动较大的场景，更需要用相似项目做小规模复测。
在线 Benchmark 新增的 Cost 视角，让选型多了一个现实维度。它根据每次任务运行的 Token 使用量，按统一价格快照折算平均每次评测任务运行的模型 API 费用。例如，Kimi K3 的平均费用约为 2.45 美元，GLM-5.2 约为 1.07 美元；费用最低的 DeepSeek-V4-Pro 约为 0.15 美元，但完成度为 75.23%。
图 3：在线 Benchmark 中，7 个“模型 × Claude Code × 官方支付 Skill”配置的综合完成度与平均每次评测任务运行的模型 API 费用。完成度高不等于费用最高，费用最低也不等于更适合支付接入。
这里的 Cost 只代表评测中的模型 API 运行费用，不包含人工审核、人工返工、线下测试、基础设施、部署和生产运维成本；具体数值也会随模型价格、上下文长度和 Token 使用量变化。
给开发者的建议：截至 2026 年 8 月 18 日、在本次“模型 × Claude Code × 官方支付 Skill”配置下，若优先看综合完成度，可先把 Kimi K3 与 Claude Opus 4.8 纳入首轮验证；若同时重视预算，GLM-5.2 可作为候选。先按目标产品和 Basic / Advanced 阶段设定完成度与安全门槛，再比较费用；最终选择仍应在自己的代码库和关键支付场景中复测。
发现二：先给 Agent 一份支付 Skill，通常比让它自己猜更有效
开发者不会只让 Coding Agent 依靠模型参数里的通用知识工作。产品文档、代码示例、接入步骤、团队规范和风险要求，都会影响它最终写出的方案。
Alipay-PIBench 为每个任务设置成对实验：模型、Claude Code 框架、项目、任务说明、运行环境和评测方式保持一致，只改变 Agent 是否加载官方支付 Skill。
最新七组模型结果显示，加载 Skill 后，综合完成度平均提升 9.87 个百分点。在 126 组“模型 × 产品 × 场景”的成对比较中，113 组提升、8 组下降、5 组不变；Basic 平均提升 11.65 个百分点，Advanced 平均提升 8.09 个百分点。
图 4：同一模型、项目与任务条件下，加载官方支付 Skill 前后的完成度对比。最新结果覆盖 7 个模型、126 组成对实验。
Skill 的价值，不是给 Agent 一份标准答案，而是把产品选择、接入步骤、服务端确认、通知处理、幂等和常见风险，变成编码时可以直接使用的结构化上下文。
但完成度提升，并不意味着每次运行都会更便宜。最新结果中，使用 Skill 后 7 个配置的完成度都提升，只有 2 个配置的平均单次任务费用下降。也就是说，Skill 首先改善的是支付接入完成度、减少对产品规则的猜测，而不是承诺降低每次调用的账单。
给开发者的建议：
- 先加载 Skill：让 Coding Agent 在修改代码前加载与目标产品匹配的官方支付 Skill。
- 再说清目标：把业务目标、现有项目状态和验收要求一次交代清楚，至少覆盖服务端确认、通知验签、订单与金额匹配、幂等和异常状态。
- 最后做验证：对生成结果继续进行代码审查、集成测试和安全检查。
发现三：流程跑通，不代表已经可以放心交付
支付代码是否可信，不能只用一种检查方法判断。
论文中的六模型诊断显示，在 Basic 任务中，代码结构相关检查的平均完成度为 92.79%，但集成测试和端到端测试分别为 73.16% 和 78.24%。SDK、接口、字段和状态模型都可能已经出现在代码里，但它们未必真正连接成可以执行的支付闭环。
Advanced 任务中则出现了另一种差距：端到端路径的平均完成度达到 97.03%，支付领域要求的评估结果为 61.05%。一条测试路径能够执行，不代表实现已经充分处理验签、重复通知、异常状态、退款边界和支付—业务状态一致性。
图 5：Basic 结果说明“代码看起来完整”不等于“实际流程已经跑通”；Advanced 结果说明“测试路径能够执行”不等于“安全与业务一致性要求已经满足”。不同方法覆盖的要求不同，数值不能直接相减。
给开发者的建议：把验收设成三道门。
- 代码存在：检查 SDK、接口、配置和状态模型是否完整。
- 流程可执行：运行集成与端到端测试，验证交易创建、支付确认、异步通知和业务状态更新。
- 支付可信：专项检查服务端验签、订单与金额一致性、重复通知幂等、异常状态和退款边界；客户端回调不能作为最终支付结果。
任何一层没有通过，都不要把这次支付接入视为完成。
开源，让支付接入有一把可以复现的尺子
支付评测离不开具体产品和业务语义。支付宝可以把开放平台的产品规范、沙箱能力和风险边界，转化为真实项目任务、清晰要求和可执行验证；开源则让开发者、模型团队和 Agent 团队可以用同一把尺子复现实验、比较配置，并继续补充新的项目与异常场景。
面向全球研究者、开发者，459 条 Rubric 本身就是一份现成的避坑清单。哪些通知必须验签、金额为什么要和订单绑定、已支付状态为什么不能回退——这些过去要靠踩坑才换来的经验，现在每一条都能拿来就用。
对 AI 生成的支付代码，判断标准可以很明确：先看代码有没有写，再看链路能不能跑，最后确认异常发生时支付与业务状态是否仍然正确。
