problem-summary

name	problem-summary
description	在日志分析或技术排查对话结束时，按固定模板将本次排查沉淀为可复用的故障知识库条目。当用户说"总结一下这个问题"、"把这次排查沉淀下来"、"写个复盘/故障报告"、"归纳根因和验证步骤"、或对话涉及问题收尾归档时主动触发。也适用于用户想把排查结论整理成团队知识库、可复用排查路径、故障单摘要的场景。

问题分析知识库（排查沉淀）

在 日志分析过程中 已完成或阶段性完成排查时，将 证据 → 推断 → 验证 → 结论 → 修复 整理成结构化条目，写入团队 问题分析知识库（便于检索与复用）。模板侧重故障机理与排查链路，不是 会务类纪要。

触发时机

用户在如下意图（含同义表述）时使用本 Skill：

• 总结 本次/本轮 日志分析与排查；归纳结论与仍待验证项。
• 把本次问题 沉淀成知识库条目、复盘卡、故障单摘要。
• 提炼根因、影响面、修复与 可复用排查路径（经验总结）。

若用户 仅 要求对日志文件做扫描/统计而无「收尾沉淀为条目」的意图，优先使用日志分析类 Skill；待分析告一段落再调用本 Skill。

调用前必须提示用户

在套用模板输出正文 之前，先用简短回复完成确认或告知（3～6 句内），例如：

1. 范围：将基于「当前会话中与该问题相关的分析/排查内容」总结；若需粘贴外部片段或限定某一时间段日志结论，请用户说明或粘贴。
2. 缺口：若会话未交代「是否已解决」「最终采纳方案」「影响面」，说明将在对应小节标注 「待补充」，并请用户一句确认或补充。
3. 下一步：说明即将按下方 七段固定模板 输出，且每项控制在 1～2 句话。

用户明确表示「直接总结、不用多问」时，可压缩为一句范围声明。

输出格式（严禁缺项）

严格遵守以下模板，七项缺一不可；每项 1～2 句话，专业、客观、不赘述代码细节。

【问题名称】：简要命名该问题。

【问题表象】：描述观察到的异常状态。

【原因解析】：说明导致该问题的根本原因。

【影响范围】：评估受此问题影响的功能、模块或用户群。

【修改方式】：概述采取的修复方案或代码变更。

【排查过程】：梳理本次分析中出现的 日志/证据线索、假设与验证、对应结论（按时间或逻辑顺序）。

【经验总结】：提出预防类似问题再次发生的建议，或可复用的排查要点。

内容规则

• 仅概括逻辑与过程；技术名词与模块级指代即可，避免大段堆栈或冗长实现描述。
• 结论须 锚定会话中已有信息与日志结论；无依据时不臆测，在该项内写明 「待补充：…」。
• 中文撰写，必要处保留英文术语。