豆包接口文档提示词进阶推荐：普通版到进阶版写法全攻略

这里的核心在于，需要用角色设定和模板框架来管住AI的输出结构，用反例压缩幻觉空间，用字段映射关系强化约束，再配合自检清单逐项补全。做到这几点，才能生成一份可以直接交给开发的标准接口文档。

不过在此之前，先聊聊很多人踩过的坑。

普通版提示词：让AI知道"这是接口文档"

很多人上来就写："写一个用户登录接口的文档。"

这句话太模糊了。AI根本不知道你指的是REST还是GraphQL，不清楚是否需要状态码、请求头、错误示例。更糟糕的是，它可能把返回字段写成"返回成功或失败"，这种描述开发根本没法落地。

更好的写法是："请用标准Markdown格式，写一份用户登录接口的RESTful文档，包含接口路径、请求方式、请求头、请求参数（含必填/选填说明）、成功响应字段、常见错误码及含义。"

关键诀窍在于必须明确指定输出格式和核心模块。否则AI默认按自由文本组织内容，不会主动分栏、加粗字段名、标注required。

进阶版提示词：控制结构、约束边界、注入业务语义

掌握了基础写法，再来看看进阶技巧。

方法一：用角色+模板锚点锁定输出结构

给AI一个明确的角色定位和输出模板，它就会乖乖按你的框架输出。比如："你是一名后端API文档工程师，请严格按以下结构输出：# 接口名称｜# 请求地址｜# 请求方式｜# 请求头｜# 请求参数（表格：字段名｜类型｜是否必填｜说明）｜# 响应示例（JSON格式，缩进2空格）｜# 错误码表（状态码｜错误码｜说明）。现在生成「手机号一键登录」接口文档，其中信息验证码需校验5分钟有效期，token有效期为7天，且返回的user_info中必须包含a vatar_url、nickname、bind_status（0-未绑定微信，1-已绑定）。"

方法二：用反例排除法压缩幻觉空间

AI特别喜欢偷懒，常见的模糊表述包括"详见后端代码""具体逻辑由服务端决定"等。需要明确告诉它："不要写'详见后端代码'这类无效描述；不要省略Content-Type示例；不要把error_code写成字符串如'invalid_phone'而不给出数字码（如40012）；不要在响应字段里出现'等等''其他字段略'。"

必须禁用模糊表述，否则AI会用概括性语言绕开细节，输出根本不可用。

方法三：带字段映射关系的强约束

直接像填表一样把字段规则列清楚。比如："请求参数中phone字段类型为string，长度11，需符合中国大陆手机号正则^1[3-9]\\d{9}$；code字段为6位纯数字string；返回字段login_token类型为string，长度≥32；refresh_token同样为string，但须注明'仅首次登录返回，后续调用refresh接口获取新token'。"

这一步很简单，但漏掉正则或token生效条件，开发联调时就会卡在"为什么我传了11位号还报错"这类问题上。

终极校验：用"文档自检清单"倒逼提示词补全

方法有了，怎么确保没有遗漏？

第一步：列出你实际需要交付给前端/测试的最小可用项。比如"必须能复制粘贴进Swagger导入""错误码表要能直接转成枚举类""所有字段名必须和Ja va DTO字段名完全一致"。

第二步：对照清单，检查当前提示词是否覆盖每一项。缺哪条就补哪条。比如发现没提DTO字段名一致性，就加一句："所有请求参数名与响应字段名，须与Spring Boot控制器中@RequestBody和@ResponseBody对应的Ja va Bean字段名严格一致，包括大小写和下划线/驼峰风格。"

第三步：把最终提示词粘贴进豆包，立刻看它输出的第一行是不是"# 接口名称"。如果不是，说明结构锚点失效，需要回到方法一强化标题符号或加"请勿添加额外解释性文字"。

这套流程走下来，AI生成的接口文档基本可以直接交付开发，省去大量手动调整的时间。

来源：互联网