字段解释必须包含【业务含义】、【取值范围/示例值】、【是否必填及校验规则】三要素，严格按模板分行输出，禁用“相关”“可能”等模糊词，且所有解释须基于真实或模拟的完整请求/响应样例反向推导。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
通义千问生成的接口文档字段说明模糊、缺少业务含义或数据约束，导致开发人员反复确认细节，拖慢联调进度。
明确要求字段解释必须包含三要素
在提示词开头直接定义输出规范：字段解释必须同时写出【业务含义】、【取值范围/示例值】、【是否必填及校验规则】。缺一不可。
例如：“user_id 字段不是‘用户唯一标识’这种空泛描述，要写成：用户在本系统的全局唯一ID，64位字符串，由雪花算法生成，示例值：'1872634901234567890'；必填，后端校验非空且符合正则 ^[0-9]{19,20}$。”
用结构化模板锁定字段描述格式
在提示词中嵌入强制格式模板，要求每个字段严格按以下顺序分行输出：
字段名：【user_status】
业务含义：账户当前激活状态，影响登录、下单等核心流程
取值范围：0（未激活）、1（已激活）、2（已冻结）、9（已注销）；默认值为0
是否必填：是，前端提交时不可省略，后端拒绝接收 null 或空字符串
不接受任何变体格式，如合并成一段、颠倒顺序、用括号简写。
禁止使用模糊词汇的负面清单
在提示词末尾添加硬性禁令：生成内容中不得出现以下词汇，一旦出现即视为不合格——“相关”“某些情况”“一般”“可能”“通常”“视业务而定”“详见其他接口”。
这些词会立刻让字段失去可执行性。比如“status 字段含义与业务状态相关”，等于没说。
绑定真实请求/响应样例驱动生成
方法一：把实际抓包得到的完整 JSON 请求体和响应体粘贴进提示词，标注“以此为准生成文档”，并强调：“所有字段解释必须能反向推导出该样例中的每个键值对，不能凭空补充未出现的字段。”
方法二：若无真实样例，提供最小可行模拟数据，例如：
请求体：{"order_amount": 299.00, "pay_channel": "alipay", "expire_minutes": 15}
响应体：{"code": 0, "data": {"order_no": "ORD202405211122334455", "qrcode_url": "https://..."}，"msg": "success"}
然后指令：“按上述字段逐个解释，未出现的字段不准编造。”
【关键前提：样例必须包含至少一个数值型、一个字符串型、一个枚举型、一个嵌套对象字段，否则生成结果仍会漏约束】
