在使用 MarsCode 进行事故复盘时，许多用户常遇到一个棘手问题：模型生成的复盘报告往往只罗列故障现象，例如“服务超时”“数据库连接失败”。核心痛点在于——根因分析、改进措施、责任人归因全被忽略。这样的报告拿到真实复盘会议中讨论，或沉淀为标准操作流程（SOP），基本毫无价值。深入探究会发现，瓶颈并非模型能力不足，而是提示词的结构化程度和信息密度存在缺陷。

通过结构化指令明确复盘关键要素

第一步，在提示词开头强制设定规则：复盘报告必须包含四个不可省略的模块——【现象】【根因】【影响范围】【改进措施】。缺一不可，不容商量。

第二步，为每个模块附加约束说明，防止模型敷衍了事。例如，在“根因”后直接跟进：需定位到具体代码行、配置项或流程节点，严禁使用“系统不稳定”“网络波动”这类模糊表述。它想偷懒？绝无可能。

第三步，直接提供一个带占位符的模板句式，强迫模型按格式填充：【现象】{简述异常表现} → 【根因】{精确到服务名+模块+触发条件} → 【影响范围】{受影响用户量级/业务线/时段} → 【改进措施】{可执行、有时限、有负责人}。这套流程执行完毕，输出质量必然显著提升。

禁用模糊词汇并替换为可验证术语

接着，在提示词中明确列出禁用黑名单，凡倾向模糊的词汇一律禁止。例如：禁止出现“可能”“疑似”“大概率”；如果模型不得不做根因推断，必须明确标注依据来源，比如监控截图的时间戳、日志关键字、链路追踪ID。这样一来，模型就无法含糊其辞。

同时，提供一份正向词典，告知模型什么是合格表述。比如不要写“服务挂了”，而应替换为【service-auth】Pod在2024-05-12T14:23:17Z因OOM被K8s强制终止，/proc/pid/status显示MemA vailable低于50MB。够硬核、够精确，一眼就能看出可落地性。实际操作时，直接将这个正向示例粘贴到提示词末尾即可，模型会自动对齐。

注入真实日志片段引导推理深度

这一步是很多人忽略的关键环节：将从真实事故中截取的日志片段（包含时间戳、错误码、堆栈前三行）作为提示词的一部分插入，放在指令之后、模板之前。模型看到真实日志后会自动对齐上下文进行归因，而非泛泛地扯概念。

需要特别注意的是，日志必须保留原始格式，包括缩进和报错行号。因为堆栈的层级关系对模型理解问题本质至关重要，一旦格式混乱，模型就会抓不住重点。

如果你只给一句“HTTP 500错误”，它只会吐出“后端异常”这种无聊结论。但如果你贴上Caused by: ja va.sql.SQLTimeoutException: Timeout after 3000ms，它自然会沿着“数据库连接超时”这一路径深挖下去——连接池耗尽、慢查询、甚至事务锁，都会变成更清晰的推导路径。从实际效果来看，这才是将提示词效果拉到最大值的操作。