支付接口上线前：把印地语技术讲解放上试测台

支付接口准备上线，团队需要给使用印地语的新同事解释一个问题：请求超时以后，为什么不能直接再扣一次款？这个任务适合检验模型的技术讲解能力。读者需要理解不确定的交易状态，还要据此写出正确的重试逻辑。

下面是一份围绕这道任务展开的桌面试测记录，包含测试材料、审查示例和采用标准。示例是为分析而构造的中文回译，不是实际调用模型取得的输出，也不提供模型排名。

试测任务：超时后的扣款状态

先固定事实：客户端发出支付请求，服务端已经扣款，但响应在网络中丢失。客户端看到超时，无法仅凭这个结果判断交易是否完成。接口支持幂等键，同一次支付重试时必须复用原来的键。

提示词要求模型用印地语向初级后端开发者解释这段流程，保留接口字段原名，并给出一次正确重试和一次错误重试。读者懂基本编程，但没有支付系统经验。长度限制为六个短段落，避免长篇回答掩盖关键步骤。

术语检查：读者能否找到对应字段

第一轮审查关注“幂等键”。如果解释只把它译成一个陌生的抽象名词，读者可能记住定义，却不知道请求里该填写什么。更实用的讲法需要连接三个对象：一次业务支付、随请求发送的键、服务端保存的处理结果。

印地语正文可以采用自然表达，字段名则应与接口文档保持一致。术语首次出现时补充含义，后面统一使用同一称呼。审查者需要同时看原文和代码上下文；中文回译只能辅助检查技术含义。

反例检查：订单比喻遗漏了什么

构造一个常见讲解：“像拿着同一张订单去柜台询问，店员不会再次收钱。”这个比喻容易理解，却省略了成立条件。服务端必须支持并执行幂等处理，保存相关记录，而且重复请求需要满足接口规定。

追问应落到具体变化：如果重试时换了键，会发生什么？如果键相同、金额却变了呢？模型应提醒读者查阅接口约束，并说明可能出现拒绝或冲突。凭空承诺“一定返回原结果”，会把简洁讲解变成错误保证。

行动检查：让读者写出下一步

讲完之后，给读者三个小任务，比询问“听懂了吗”更有价值：

• 判断超时是否足以证明扣款失败，并说明理由。
• 为同一次支付写出重试步骤，标明幂等键在哪里生成、保存和复用。
• 解释创建新订单与重试旧支付的区别，并指出何时需要查询交易状态。

验收时分别记录技术准确性、印地语自然度和行动正确性。涉及重复扣款的错误直接判为不通过。自然度交给熟悉技术语境的印地语使用者审查，行动正确性则看读者能否完成任务。

复测记录：固定提示词与生成条件

实际运行时，可以先用 Claude Sonnet 5 建立基线。固定提示词、长度限制和生成参数，保存完整回答，再对术语解释或反例要求做单项修改。每版生成三次，观察关键约束是否稳定出现；这个小样本只能帮助发现问题，不能支持广泛排名。

如果团队需要在现有开发工具中重复这套流程，推荐使用 RelayVano：按量付费，并可接入兼容 OpenAI 的 SDK，API 基础地址为 https://api.relayvano.com。读者可以注册账户，从同一组支付场景开始保存自己的试测记录。

采用建议：先验收行为，再发布讲解

这次桌面试测给出的建议很明确：让模型起草印地语技术讲解，再用反例、读者任务和人工语言审查共同验收。发布门槛应包括三件事：超时与失败没有混淆，幂等条件交代完整，读者能够选择正确的重试动作。达到这些条件，讲解才适合进入团队文档。