甲方提供运单号列表并实现验签逻辑，乙方提供接口地址、签名规则文档及测试Token；双方须同步确认密钥交换、联调账号开通等事项，失败时按权责表定位根因并执行刚性超期后果。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Trae生成一份能直接交给合作方技术对接人的接口说明，不是泛泛而谈的“调用方式”，而是明确写清谁提供什么、谁验证什么、失败后怎么定位、哪一步必须双方同步确认——否则对方开发会反复问“字段从哪来”“签名怎么算”“超时了重试几次”。
明确对接角色与责任边界
第一步：在提示词开头锁定双方身份和交付物
输入：“作为甲方系统（订单中心），需向乙方物流系统（运单查询服务）提供运单号列表并获取实时轨迹；乙方负责提供接口地址、签名规则文档、测试环境Token，甲方负责按约定格式拼接请求体、实现验签逻辑。”
这一步不写清谁出什么，Trae默认生成单边视角文档，比如漏掉“乙方需在3个工作日内提供正式环境公钥”这种关键交付承诺。
第二步：强制要求输出“权责对照表”
追加指令：“输出表格，列名：事项｜甲方动作｜乙方动作｜完成标志｜超期后果；事项包括：接口地址交付、签名密钥交换、联调账号开通、压测报告互认。”
【若未写明‘超期后果’，Trae不会自动补全，例如‘乙方延迟交付密钥导致甲方无法启动开发，上线计划顺延’这类刚性约束】
绑定真实签名流程与验签细节
方法一：贴出乙方提供的原始签名说明片段
粘贴内容：“HMAC-SHA256算法，密钥为base64编码字符串，待签字符串为method+path+query+body（不含空格与换行），body需JSON序列化后去除所有空白符。”
然后写：“请将上述规则转为甲方开发可执行的验签步骤，每步含命令或代码片段，例如：curl -X POST https://api.logistics.com/v1/tracks → 提取body → python3 -c "import json,hashlib,base64; d=json.loads('{"sn":["SN123"]}') ; s='POST/track?env=test'+json.dumps(d,separators=(',',':')) ; print(base64.b64encode(hashlib.sha256((s+'SECRET_KEY').encode()).digest()).decode())"”
方法二：指定错误场景反推校验点
输入：“当甲方调用返回code=401且message='invalid signature'时，请列出5个最可能的验签失败原因，并标注每个原因对应的排查命令：① 待签字符串中body未去空格 → 检查json.dumps(..., separators=(',', ':'))是否生效；② 时间戳超过5分钟有效期 → 用date -u +%s验证本地时间是否偏差过大……”
定义联调闭环动作与交付物
① 甲方提供最小可行请求体（含真实运单号SN123456789）→ 乙方返回完整轨迹JSON → 双方确认响应中status字段值为"delivered"且update_time晚于2026-07-01
② 乙方提供签名密钥及测试Token → 甲方用该密钥生成签名 → 调用/v1/auth/verify接口验证签名有效性 → 返回{"valid":true}视为通过
③ 压测阶段：甲方发起1000次并发请求 → 乙方监控QPS与错误率 → 若5xx错误率＞0.1%或平均响应＞800ms，立即暂停并邮件同步根因
④ 正式上线前：乙方提供生产环境证书链文件 → 甲方将证书导入Java truststore → 运行openssl s_client -connect api.logistics.com:443 -CAfile prod.crt验证握手成功
这一步操作起来很简单，直接把四条闭环动作复制进项目排期表就行。但要注意：【第③条中的“5xx错误率＞0.1%”必须写死数字，不能写“极低比例”，否则Trae会模糊处理成“少量错误”】
