豆包API错误码说明提示词：如何让AI检查遗漏信息

实际上，这个问题有章可循。核心思路可归纳为三步：先用角色指令锁死结构，再用分项反问逼出遗漏，最后通过正负例对照堵住逻辑漏洞。下面逐一展开。

先用角色+规则锚定强制结构输出

在新对话开始时，直接输入一个预先设置好的“角色+规则”指令。该指令需尽量具体，不仅限定身份，还应明确字段维度和格式要求。

例如：

“你现为某大厂API平台组资深文档工程师，负责输出符合OpenAPI 3.0规范的错误码说明。所有输出必须包含且仅包含以下5个字段：①错误码（如ERR_USER_NOT_FOUND）；②HTTP状态码（如404）；③触发条件（精确到参数校验/权限/资源状态等层级）；④错误响应示例（JSON格式，含code/message字段）；⑤客户端处理建议（动词开头，如‘重试前检查token有效期’）。”

这一步的作用在于：将模型的“自由发挥空间”压缩到最小。字段被明确锁死后，AI若要跳过一个字段，就必须强行违反指令，这在多数情况下不会发生。若后续检查发现某个字段缺失，说明角色绑定未真正生效，需要重启对话并重新输入该指令。

再用分项反问法触发自查

结构框架确定后，AI并不一定会把每个字段都写得合格。尤其是“触发条件”和“客户端处理建议”这两项，最容易被写成泛泛而谈的套话。此时需要借助“分项反问”促使其自查。

这里有两种常用的提问策略：

方法一：将AI刚生成的错误码条目粘贴回来，然后追加提问：“请逐项核对：这一条是否提供了HTTP状态码？若未提供，请补全并说明依据（如401必须对应未认证，不可填200）。” 该方法的优势在于，让AI在“自我审查”中重新关注状态码与错误场景的对应关系，而不仅仅是机械填空。

方法二：针对“客户端处理建议”容易空洞的问题，单独聚焦提问：“这条错误码的客户端处理建议是否可执行？请判断：建议是否含具体动作动词？是否指向明确对象（如‘刷新access_token’而非‘检查权限’）？若任一否，请重写。” 注意，这里不能只问“有没有建议”，而是应提供一个可供对照验证的标准。标准越清晰，AI的判断就越准确。

【关键提醒：不要只问“有没有建议”，要定义可验证标准】

最后用负向排除法堵住逻辑漏洞

即便经过结构锁定和分项自查，AI仍可能在字段内容的逻辑一致性上出现纰漏。例如，它可能写了一个HTTP 504超时错误，却未说明超时阈值或是否应降级处理。此类问题靠“正面引导”往往纠正不彻底，更有效的方法是使用“负向排除法”——即通过正反样例让AI自行发现问题。

具体操作分三步：

第一步，提供一个正确样例，并标注清楚哪些地方做对了：“正确示例→ERR_INVALID_PARAM：400；触发条件：name字段为空字符串或长度超过32字符；响应示例：{‘code’:‘ERR_INVALID_PARAM’,‘message’:‘参数name格式不合法’}；客户端处理建议：校验前端表单非空及长度限制。” 该样例的作用是让AI明确“好”的标准样式。

第二步，提供一个典型错误样例，并点明问题所在：“错误示例→ERR_TIMEOUT：504；触发条件：后端服务调用超时；响应示例：{‘code’:‘ERR_TIMEOUT’,‘message’:‘请求超时’}；客户端处理建议：稍后重试。（问题：未说明超时阈值、未区分是网关超时还是下游服务超时、建议未提示是否应降级）。” 该样例让AI看到“坏”的样子，并理解具体问题出在哪里。

第三步，将待检内容发给AI，并下达指令：“请对照以上正误样例，指出本条缺失的字段或表述缺陷，仅输出问题点，不重写全文。” 这一步的精髓在于：只让AI挑毛病，不允许其自由修改。因为一旦放开修改权限，它可能“补”出新的问题。仅输出问题点，更便于你进行下一步的定向修复。