一步步教你编写高效Codeium日志排查清单提示词完全可复用版本

写过日志排查提示词的人都知道，每次在跨项目场景下重新构建“请输出包含时间戳、错误码、上下文变量、复现路径的结构化清单”这类指令时，不仅编写效率低，还容易遗漏关键字段。实际上，这类模板的底层逻辑只有三条：字段强制不可删减、结构支持跨项目复用、输出结果可自动校验。

先讲核心约束。模板内必须固化四个字段——时间戳（ISO 8601格式）、错误码来源（例如HTTP状态码或业务自定义code）、上下文变量（至少包含request_id与用户身份标识）、以及可操作的复现路径（前置操作加触发动作）。注意：禁止使用具体业务术语，比如“订单服务”应替换为“当前服务”，“支付失败”应替换为“目标异常事件”，否则模板换一个业务场景就失效。所有动态内容统一用占位符处理，例如{service_name}、{error_event}、{log_level}，实际调用时再填充。

接下来设计分支逻辑。常见场景有两种：输入原始日志，或仅有错误描述。如果输入的是多行日志，提示词开头需追加“先按时间倒序合并为单条事件”；如果仅有描述，则跳过合并步骤，直接进入字段提取。另外，输出格式需要按角色切换。在提示词末尾加入可选指令：“输出格式可选——运维版：侧重时间+错误码+request_id；开发版：额外包含堆栈关键词与影响范围推测；产品版：转译为用户可感知的行为断点。”注意，三个版本不能同时输出，用户必须显式指定，默认使用运维版。这相当于工具箱里的三把扳手，不能一次性全拧上。

最后一步，也是多数人容易忽略的——校验机制。提示词结尾必须嵌入强制检查指令：

“请严格检查输出是否完整包含以下五项：① ISO 8601 时间戳；② 错误码（不能是‘未知’或空值）；③ request_id 或等效追踪 ID；④ 用户身份标识（user_id、tenant_id、session_token 三者之一）；⑤ 可执行的复现路径（动词开头，避免‘可能’‘疑似’等模糊词汇）。任一项缺失则重新生成。”

为什么这个校验必须硬编码？实践经验表明，Codeium 这类工具在无校验时经常遗漏上下文变量。简言之，校验机制就是最后一道防线，确保每次输出的日志排查模板立即可用，而不是半成品。

来源：互联网