Codeium提示词工程字段不清？3步精准修复

先讲三个铁律：结构化提示词不能只靠“把需求说清楚”。你必须锁死每个字段的边界，钉牢上下文锚点，再用反面案例彻底掐断AI自行发挥的可能。否则写出来的东西字段名乱飞、边界模糊、关键信息残缺——全是废品。

比如生成API错误码说明，返回的字段缺胳膊少腿，code写成status，solution变成fix——干过的人都懂。更别说堆栈分析，你期望它顺着执行流一行行拆到行号，结果它抛出一堆孤立的优化建议，完全用不上。

用固定模板强制约束字段命名

最关键的一步：在提示词最开头直接粘贴不可改动的JSON Schema。写法如下：

“严格按以下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}”

注意——Codeium不会自动补全你漏掉的字段。少写一个，输出里就真缺那个字段。如果你只写“包含code和message”，它很可能吞掉cause和solution，或者擅自改成reason、fix这类非标准命名。

这一步必须写死，不能缩写、不能换词、不能加“例如”“如”这类模糊引导词。

为每个字段绑定真实业务上下文

光有Schema不够，每个字段都要跟实际场景拧在一起。

方法一：接口路径必须与代码日志/curl/OpenAPI完全一致
在错误码描述前加一句：“该错误码出现在 POST /v2/transaction/submit 接口响应体中”。别写“支付提交接口”，否则Codeium可能生成 /api/pay/submit 或 /payment/create 这类变体，到时你得满代码库搜。

方法二：code字段追加业务前缀
原始code是4001，必须写成 PAY_4001；原始code是5003，必须写成 AUTH_5003。这样团队在IDE里搜 PAY_4001 就能直接跳到同一段说明，不用再猜是哪个模块的故障。

方法三：message_zh剔除泛称，改用具体约束描述
✘ “参数错误” → ✅ “user_id格式非法（非16位十六进制字符串）”
✘ “系统异常” → ✅ “Redis连接池耗尽（最大连接数配置为32，当前活跃连接33）”

用失败案例堵死空洞表达

在提示词末尾追加一段“以下写法不可接受”，彻底封死AI的发挥空间：

✘ “对缺失值进行处理” → 缺失值在哪列？是空字符串、NULL，还是'N/A'？处理方式是填充均值、前向填充，还是丢弃？
✘ “统一日期格式” → 原始格式是‘2026/05/30’还是‘30-May-2026’？目标格式是ISO 8601还是Unix timestamp？
✘ “检查权限” → 检查哪类资源的权限？依据RBAC还是ABAC？失败时返回403还是跳转登录页？

每条都对应真实踩坑点。Codeium看到这种明确否定，会主动规避同类表达，不会再输出看似周全实则空洞的泛泛描述。

按错误类型匹配预设排查模板

第一步：识别堆栈首行关键词，触发对应逻辑链
检测到“undefined”，启用空值溯源三步法：
① 找出调用链中最后一个非undefined值的来源
② 检查该值被赋值时的条件分支是否全部覆盖
③ 验证接口返回结构与TS类型定义是否一致

第二步：禁用模糊词，强制绑定文件与行号
在报错堆栈后立刻追加：“所有分析必须基于 /src/utils/apiClient.ts 第42行展开，忽略其他文件中的同名函数。”
——这句不能省。Codeium对模糊禁令响应敏感，你漏掉这句，它会默认启用猜测模式，跑到其他文件里乱找。

第三步：步骤动词必须锁定执行流顺序
“请严格按以下三步处理：① 定位最内层异常发生行（不是第一行堆栈）；② 找出该行直接依赖的上一层变量或函数调用；③ 检查该依赖在调用前是否被正确赋值/初始化。”

这几块组合起来，才算一份能打的结构化提示词。核心就一句话：把AI当成会偷懒的实习生，你的每条指令都必须是铁律，而不是建议。