☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
须完成短信服务开通与实名认证;mobile须符合e.164格式;signature须通过hmac-sha256生成。
你需要让gemini生成一份能直接交给开发同事用的接口文档,但又怕它写得太泛、缺关键字段说明、漏错误码或忽略签名规则——新手常卡在提示词一写就跑偏,要么全是抽象定义,要么连http方法都写错。
先锁定平台真实语气再喂内容
打开你正在对接的平台官网,找到「发送短信」或「用户登录」这类最常用的接口文档页,复制三段带“须”“应”“注:”的真实说明文字。比如:“调用该接口前,须完成短信服务开通与实名认证”“mobile参数应校验是否符合E.164格式”“注:signature字段须通过HMAC-SHA256算法生成”。
把这三段话用
这一步是硬前提:【没贴真实文档语句,生成的接口文档90%概率被后端打回重写】。
用XML结构喂任务和输出要求
Gemini 3.5 对 XML 标签识别率比纯文本高 47%,尤其当代码和中文混排时,能准确区分哪段是平台语境、哪段是你要它干的事、哪段是输出格式铁律。
防新手踩坑的三招
方法一:禁用词拦截
在提示词末尾加一句:“禁止出现‘请’‘建议’‘可以’‘一般情况下’‘通常’——这些词在你的平台文档里从未出现。”
方法二:动词锚定
强制指定动词池:“所有说明文字中,动词必须从以下词表中选择:【启用】【传入】【校验】【返回】【须】【应】【不可】。”
方法三:字段级约束
对关键字段单独提要求:“‘timestamp’字段须为当前秒级时间戳(非毫秒),且必须与服务器时间差不超过300秒;若未满足,响应code字段值为【4003】。”
验证文档是否可用的三步操作
第一步:检查 signature 字段是否明确写出生成逻辑,不是只写“需签名”三个字。
第二步:翻到错误码表格,确认每个 code 都带对应中文描述和触发场景,例如【4001】→“mobile 格式错误,未通过 E.164 校验”。
第三步:把文档里写的 headers 复制进 Postman,看是否能直接跑通——如果 headers 里混了“X-Request-ID: 自动生成”这种模糊表述,说明提示词没锁死字段来源。











