让AI写API错误码文档，最怕什么？最怕生成一堆“参数错误”“系统异常”这种查了等于没查的废话。团队里谁遇到bug，靠关键词在全仓库里搜半天，结果啥都搜不到——这种体验，干过技术的都懂。

所以，调教Codeium输出高质量错误码说明，核心就三件事：定死字段模板、绑定真实接口路径、塞进可检索的关键词。下面一个一个说。

定义错误码结构化模板

在提示词最前面，直接把字段格式写死。别指望Codeium自己脑补——你不告诉它要哪些字段，它就给你随手丢几个名字，缺东少西。比如强制要求：code、http_status、level、message_zh、message_en、cause、solution、example_call。

这一步的关键是：漏一个字段，就少一类信息。后续无论谁用这个说明，都会因为字段不完整而反复补查。

直接把下面这段模板贴到提示词开头：

“请严格按如下JSON Schema输出错误码说明，所有字段必须存在且不可合并、不可省略：
{
code: string,
http_status: number,
level: string（取值：'fatal'/'error'/'warn'）,
message_zh: string,
message_en: string,
cause: string,
solution: string,
example_call: string
}”

绑定具体HTTP接口路径

一个错误码说明如果不关联接口路径，等于扔进大海里的漂流瓶——你知道它在哪，但谁也捞不着。

两种做法：

方法一：直接在prompt里写真实路径，比如“该错误码出现在 POST /v2/transaction/submit 接口响应体中”。

方法二：用占位符引导替换，写成“（请将此处替换为实际接口路径，如 GET /api/v1/users/{id}）”。这样既保留了提示作用，又避免了AI虚构出根本不存在的路径。

需要警惕的是：别只写“用户创建接口”这种模糊表述。Codeium可能生成 /users/create 或 /api/user/new 等各种变体，路径字符串必须与代码里curl、OpenAPI或日志里的一致，否则搜到也白搭。

注入可检索的上下文关键词

这一步是让错误码说明能被“搜索命中”的关键。三招连用：

第一招：列出3个该错误码最常触发的真实场景关键词，用英文逗号分隔，插入到prompt末尾。例如：“常见触发场景：insufficient_balance, expired_token, invalid_signature”。

第二招：把业务系统缩写作为前缀加入code字段值。比如原来code是4001，改成PAY_4001。这样全局搜时，搜PAY就能过滤出所有支付相关错误码。

第三招：在message_zh中避免用“参数错误”这种谁都能用的泛称，改用“user_id格式非法（非16位十六进制字符串）”。

这三步叠加之后，团队成员在IDE里搜PAY_4001、搜insufficient_balance、甚至搜“十六进制字符串”，都能命中同一段说明。这才是真正能被“检索复用”的文档资产。

最后补一句：这方法不仅适用于Codeium，对ChatGPT、Claude写API文档也同样好用。底层的逻辑永远是——结构化+锚定+关键词，缺一不可。