来看一个真实的API调用场景：

curl -X POST https://api.example.com/v3/order --header "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" --data '{"sku":"A102","qty":2}'Content-Type: application/jsonHTTP/1.1 201 Created{"id":"ord_7f3a9b","status":"created","created_at":"2026-06-17T09:28:41Z"}

2026-06-17T09:28:41Z 线上验证通过，响应耗时127ms

用通义千问生成接口调用示例时，最头疼的是输出始终逃不出“调用接口→传入参数→返回结果”的循环。字段名僵死在固定模板里，JSON体堆满无意义占位符，生成的示例根本没法直接粘贴到Postman或curl里验证。下面这套方法专治这种重复表达问题。

锁定真实调用链路，禁用泛化动词

直接丢掉抽象描述，一上来就给终端可执行的命令链：【curl -X POST https://api.example.com/v3/order --header "Authorization: Bearer xxx" --data '{"sku":"A102","qty":2}' → 等待HTTP 201 → 响应体含"id":"ord_7f3a9b"和"status":"created"】。模型一旦看到具体协议、状态码和字段值，就不会再编出“接口返回成功信息”这种空话。后续输出必须遵守一条硬线：全文只能出现一次“curl”，其余涉及网络操作的地方必须绑定具体工具行为——比如“Postman导入Collection后点击Send”或“Python requests.post()返回Response对象”。简单归结，四个动词“调用”“请求”“发送”“获取”不能同时出现两个以上。

参数必须带真实约束与错误反馈

每个参数不能只当占位符，必须贴上真实校验边界。例如“page_size=50”要写成“page_size为整数，取值范围1–100，超出返回400+Error: 'page_size must be between 1 and 100'”；“timestamp=1718615760”则改成“timestamp为秒级Unix时间戳，误差超±30秒则拒绝，返回401+Error: 'timestamp expired'”。另外，错误响应和成功响应必须字段结构一一映射——成功返回{"order_id":"ord_7f3a9b","items":[{"sku":"A102","price":299}]}，失败则必须返回{"error_code":"INVALID_SKU","message":"SKU A102 is discontinued"}，而且【error_code必须与文档枚举值完全一致，严禁用“错误代码”“报错信息”这类泛称替代】。

强制格式分层，切断句式复刻

所有示例输出必须遵循三层结构，缺一不可：
① 工具命令行（curl / Postman / Python requests）
② 请求头与Body（JSON格式，字段值全部真实可测）
③ 响应快照（HTTP状态码 + 响应体，含至少1个可验证字段）

相邻两行不能以相同单词开头——如果①以“curl”起头，那么②必须以“Content-Type”或“Authorization”开头，③必须以“HTTP/1.1 201”或“{”开头。最后，每个示例末尾必须附带一条实测调试记录：# 2026-06-17T09:28:41Z 线上验证通过，响应耗时127ms。