关键在于结构化模板、绑定真实接口路径与注入可检索关键词：强制JSON字段、路径字符串须与代码完全一致、code加业务前缀、message_zh用具体描述。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
让codeium在生成api错误码说明时输出更易被团队成员快速定位、检索和复用的内容，关键在于引导模型聚焦结构化字段、统一命名习惯与上下文锚点。定义错误码结构化模板
在提示词开头明确要求使用固定字段格式，避免自由发挥导致字段缺失或命名混乱。例如强制包含：code、http_status、level、message_zh、message_en、cause、solution、example_call。
这一步必须写死字段名，【Codeium不会自动补全你没写的字段，漏一个就少一类信息】。
直接复制粘贴以下模板到提示词最前面：
“请严格按如下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接口路径
不写明接口路径的错误码说明等于无锚点文档，搜索时无法关联到调用位置。
方法一：在提示词中嵌入真实接口路径
在错误码描述前加一句：“该错误码出现在 POST /v2/transaction/submit 接口响应体中”。
方法二：用占位符引导用户替换
写成：“（请将此处替换为实际接口路径，如 GET /api/v1/users/{id}）”，这样既保留提示作用，又避免生成虚构路径。
注意：不要只写“用户创建接口”，Codeium可能生成 /users/create 或 /api/user/new 等多种变体，【路径字符串必须与代码中curl、OpenAPI或日志里完全一致】。
注入可检索的上下文关键词
第一步：列出3个该错误码最常触发的真实场景关键词，用英文逗号分隔，插入到prompt末尾。
例如：“常见触发场景：insufficient_balance, expired_token, invalid_signature”
第二步：把业务系统缩写作为前缀加入code字段值（如果原code是4001，改为PAY_4001）。
第三步：在message_zh中避免用“参数错误”这种泛称，改用“user_id格式非法（非16位十六进制字符串）”。
这三步叠加后，团队成员在IDE里搜 PAY_4001、搜 insufficient_balance、甚至搜 “十六进制字符串”，都能命中同一段说明。
