codeium生成的故障影响说明必须严格保留原始日志中的四类关键信息：①毫秒级时间戳（如2026-07-12t14:23:18.456z）；②带版本/环境/分片的服务边界标识（如payment-gateway-v3）；③用户感知层具体动词（如“无法提交订单”）；④完整关联链路id（如trace_id=abc123-def456）。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Codeium生成的故障影响说明不丢失原始日志里的关键约束、时间锚点、服务边界和用户感知层信息，避免AI把“支付网关超时导致订单创建失败”压缩成“部分功能异常”这种无指向性描述。
锁定原始日志中不可删减的四类信息
打开VS Code，确保光标位于原始故障日志文本末尾 → 按 Ctrl+I 弹出指令框 → 粘贴以下提示词：
「请严格保留以下四类原始信息，不得概括、转述或替换：① 时间戳精度（如2026-07-12T14:23:18.456Z必须保留毫秒级，不能简化为“昨日下午”）；② 服务边界标识（如payment-gateway-v3、order-service-prod-2a等带版本/环境/分片的完整名称）；③ 用户感知层动词（如“无法提交订单”“收不到短信验证码”“页面白屏卡在加载图标”，禁用“体验下降”“响应变慢”等模糊表述）；④ 关联链路ID（如trace_id=abc123-def456、span_id=xyz789，必须原样保留，不可省略前缀或截断）。」
【这四类信息一旦被AI泛化，下游告警聚合、根因定位、SLA扣罚都会失效】。
强制输出分层影响范围
方法一：用符号锚点定义三层影响域
▶ 直接用户层：列出原始日志中明确提到的终端行为，例如“iOS端用户点击‘立即支付’按钮后无响应”。
▶ 服务依赖层：提取日志里出现的上游调用路径，例如“payment-gateway-v3 → auth-service-staging → redis-cluster-shard-02”。
▶ 系统资源层：只写日志中已观测到的指标异常，例如“redis-cluster-shard-02内存使用率98%（阈值95%）”。
方法二：用数字序号绑定验证动作
① 用户层影响必须对应可复现操作步骤（如“双击支付按钮→等待3秒→界面无跳转”）→ 若日志未提具体操作，留空不编造。
② 依赖层影响必须标注调用方向箭头（→）和版本号（如auth-service-staging），【漏掉版本号等于失去灰度判断依据】。
③ 资源层影响必须带单位与阈值比（如CPU 92%/85%），禁止只写“过高”“飙升”。
过滤AI惯用模糊词与冗余修饰
在提示词末尾追加否定指令：
「禁止出现以下词汇：可能、大概、疑似、一般、通常、往往、某种程度、一定范围内、相关、有关、涉及、属于、表现为。」
「禁止添加任何未在原始日志中出现的模块名、错误码、时间区间或用户角色（如不能自行加入‘VIP用户’‘小程序端’等未提及信息）」。
这一步直接砍掉Codeium默认输出中约60%的无效修饰，它会立刻放弃“综合来看…推测原因…”这类发散段落，老老实实只处理日志里白纸黑字的内容。
绑定真实业务场景防止语义漂移
在提示词最开头插入角色与上下文锚点：
「你是一名SRE值班工程师，正在编写支付中台P0级故障的内部通告，当前时间为2026-07-12 14:23 UTC，故障仍在持续，所有信息必须来自下方粘贴的日志原文，不补充、不推理、不跨日志关联。」
这句话强制Codeium放弃通用文案思维，进入真实作战状态——它会自动屏蔽“建议后续加强监控”这类事后建议，也不会把“订单创建失败”升格为“核心交易链路中断”（除非日志原文真这么写）。
校验输出是否保留有效信息
生成结果后立刻执行三查：
查时间戳：对比原始日志，毫秒位、时区标识（Z）、日期格式是否一字不差。
查服务名：逐字核对payment-gateway-v3这类字符串，包括连字符、大小写、数字位置。
查用户动词：确认“无法提交订单”没被改成“下单流程受阻”——后者丢失了“提交”这个关键动作节点。
【只要任一检查项不符，整段说明即判定为无效，必须重新触发】。
