To Postmortem

To Postmortem

知识注入入口与诊断工具解耦——无论问题在哪儿定位的，都能在这里沉淀。这是 ascend-sleuth 体系里最重要的动作：不沉淀，团队下次还得重新踩坑。

输入方式

接受四种输入：

1. 内联粘贴（单条，最常用）：

/skill:to-postmortem "[把 Kimi/DeepSeek 对话、或手工排查笔记粘进来]"

2. 单个文件路径（大文档，免复制粘贴）：

/skill:to-postmortem ~/cases/custA/notes.md

agent 读取文件，后续流程同内联。

3. 多个文件（一次沉淀几条相关 case，各自独立成文）：

/skill:to-postmortem ~/cases/custA/notes.md ~/cases/custB/hang.md

4. 目录（批量导入历史案例，如内网 wiki 导出）：

/skill:to-postmortem ~/cases/wiki-export/

扫描目录下 .md/.txt，每个文件各成一条。大文件逐个处理，不全量载入 context。目录模式就是批量导入历史案例的入口——不需要单独的批量导入 skill。

二进制文档（.docx/.doc/.pptx/.xlsx/.rtf/.epub）预处理：客户报告、排查记录、汇报材料常是这些格式，先取到文本再走上面四种输入。约束是不变量，不是工具——只要满足三条：①文本取自原文件（不凭标题或上下文编造）②出处可核验 ③材料不外传（客户/内部文档不上传第三方服务）。工具怎么选、能不能装，都是这三条之下的实现细节。

省事的首选（装得上就用，装不上别卡死）：

npx -y @firecrawl/anydoc <file> -o <file>.md     # Node ≥ 20，首次自动下载，保留表格/公式/脚注
# 无 Node 但有 Python ≥ 3.10：
pip install firecrawl-anydoc
python -c "import anydoc,sys; print(anydoc.to_markdown(sys.argv[1]))" <file>

anydoc 或任何库都装不上（离线、无 Node/Python、版本冲突）→ 先自己找路，不要直接判失败。 已知可行的零依赖路线（这些格式本质都是 zip + XML）：

• .docx：python -m zipfile -e <file> out/（Windows 无 Python 时用 [System.IO.Compression.ZipFile]::ExtractToDirectory）后读 out/word/document.xml，按 <w:p> 段落取 <w:t> 文本拼回；out/word/media/ 是内嵌图片。
• .pptx：ppt/slides/slide*.xml（备注在 ppt/notesSlides/）；.xlsx：xl/sharedStrings.xml + xl/worksheets/sheet*.xml；.odt/.ods/.odp：content.xml。
• 这条路拿到的文本通常够沉淀（case 要的是症状/命令/根因，不是版式）；丢掉的表格结构/排版如实记进 postmortem，别假装完整。
• 探索出的新路线跑通了，值得固化 → 收尾的伴随演进评估会看到"重复手动动作"信号并决定是否写成步骤（见 /skill:evolve-check），不要在这里自己加卡。
• 真的都抽不出来 → 明确告诉用户"这份文件抽不出来，请转成 md 或贴文本"，不静默跳过附件——附件里的报错原文正是 case 的 symptoms 证据。
• 目录模式的扫描范围随之扩展到上述扩展名，逐份取到文本后再成条。
• 截图：纯文本通道（anydoc 或 XML 提取）都只出文字，文档里的定位截图会被丢掉（anydoc 无占位、无告警）。.docx/.pptx/.xlsx/.odt 都是 zip，用 python -m zipfile -e <file> out/ 取 word/media/（pptx 为 ppt/media/，xlsx 为 xl/media/），再用自己的图片识别能力直接读图（模型支持图片输入时）。
• 读不了图就如实记缺口：在 postmortem 里列「未提取的证据」清单（文件名 + 所在段落上下文 + 未识别原因），草稿标 needs-human-review。不要拿截图的标题或上下文推测报错原文——symptoms 只写文本里确有的内容。
• 不外传：不要用 --ocr hosted（把整份文档上传第三方服务）；客户材料一律本地处理。

流程

1. 提取：从输入中抽出——
   • 症状、执行的命令和输出、排除的假设、root cause、fix
   • 级联噪声：文档中标注了“次级现象”“不需要单独分析”“误导”的症状——提取为 case 的忽略项（diagnosis 里加一条“忽略 X 级联报错，都是根因后的 noise”）。昇腾调试里极常见——一个根因级联出几十条 secondary error
   • code-patch 的 file:line：如果 fix 涉及代码改动，提取精确的 file:line（如 conn.py:31-41）。code-patch 的 file:line = env-var fix 的 export X=Y——是 fix 的可执行部分
2. 命名空间建议：agent 检测或推断框架，给选项，人输入数字确认（约 5 秒）：

   [1] training/mindspeed-llm/   （检测到 mindspeed-llm）
   [2] training/verl/            （检测到 verl）
   [3] common/                   （跨框架，或不确定）
   

   • 完全没涉及框架（纯硬件/CANN/驱动报错）→ 选项变为 [1] common/，人按回车
   • 检测到多个框架 → 按置信度排序，第一项标 (most likely)
   • 这个确认本身就是质量检查：人在 mindspeed-llm 和 common 间选，本质在自问“这问题是框架特有的还是通用的”
   • 批量模式（多个文件/目录输入时）：命名空间确认改为一次批量——agent 按检测到的框架分组报告（如“12 个 mindspeed-llm、5 个 verl、3 个 common”），人一次确认或调整。语义校验仍逐个跑，失败的标 needs-structurer-review。批量模式不逐个 30 秒确认，改成抽审。
3. 输出结构化 YAML 草稿 + postmortem.md：
   • postmortem 策略：源是混乱对话/手工笔记 → 写完整 postmortem.md（提炼+结构化）；源已经是结构化文档（调查报告/issue/wiki）→ postmortem.md 只写指针（# 原文见：<source-url/path>），不重写。YAML case 草稿两种情况都照常产出。
   • 标 confidence: high | medium | low——人的调查质量判断（五天详查 vs 随手记录），不是来源验证
   • 标 verification: {source: <档>, detail: <引用>}——来源验证状态（与 confidence 区分：confidence=内容判断质量，verification=外部证据强度）。档位按「来源形态」分，不按 issue 分——issue 只是外部来源之一，官方案例文档与本地闭环同样是来源：
     • upstream-fix-merged：来源是上游 issue 且关联 fix PR 已合入（references 含 pull/<n> 或确认 merged）——内容被外部验证（根因+修复代码合入），最强档；
     • upstream-official-doc：来源是上游官方发布的案例/指南文档（如框架仓库 best_practices/ 下的定位实践、官方 troubleshooting 指南），含完整定位链与验证结论——内容被上游发布验证，但无指向本问题的 fix PR；
     • upstream-maintainer-confirmed：上游 issue 维护者确认 resolution 但无 fix PR 引用；
     • investigation：本地深度排查/源码分析定位（source_ref 佐证），无上游确认；
     • engineer-report：工程师现场回报验证过（最强现场证据，rare）。 detail 记 issue/PR 号、文档路径或来源路径。无明确外部验证 → 不填 verification（如实：仅调查级）
   • 标 novelty: new_pattern | variant | covered（pre-triage，对比现有 case 判定）：用 knowledge/_index.yaml 按 symptoms/tags 定位候选，全量读比对 root_cause/fix——无重叠 → new_pattern；同主题不同形态 → variant（注明 variant_of:<case-id>）；已有 case 覆盖 → covered（注明 covered_by:<case-id>）。给出证据（如"同算子×同网络，增量=升级修复"），groom 复核该标签而非重判
   • 标 category: interrupt | precision | performance 三选一，无 other（按症状判断——interrupt 是 hang/crash/OOM/启动失败、precision 是 NaN/数值发散/输出错误/乱码、performance 是吞吐/延迟）。分不进去 → 由人确认归入最接近的分类，不设 other
   • 标 tags（sub-type，如 oom、kv-cache、precision.convergence）
   • 根因定位到源码时（如 vllm-ascend 某文件某行），标 source_ref: {repo, ref, file, line}——ref 用触发版本对应的 commit/tag，line 可选。源码不落库，只记代码指针（诊断按需取该版本片段） 3.5. triage 路由同步（知识增长自动补全路由）：产出 case 草稿后，检查该 case 的 symptoms 关键词能否被 triage-tree.yaml 正则路由到正确 namespace：
   • 能 → 无需动作（路由已覆盖）；
   • 不能（新形态 OOD，正则没识别）→ 在产出报告里给出路由症状建议（新正则追加到对应分支的 symptoms，如 "过度思考" → inference_precision），随 case PR 一并提交（structure 部分，人审确认）——triage 随知识入库增长，不靠手工补；拿不准放哪个分支 → 建议标 needs-review，groom 定夺。
4. 语义校验（关键，区别于格式校验）：
   • regex 在输入附的真实日志片段上能否匹配
   • expected 值类型/数量级合理性
   • command_template 里的路径在已知部署模板里是否存在
   • 校验失败 → 标 needs-structurer-review（与 needs-human-review 区分：前者是格式/语义可疑，后者是语义不明）
5. 脱敏：扫描 Bearer ...、sk-...、password=、内网 IP 段 → 替换 [REDACTED]。在人确认前，不是事后补救。这是 KB 进私有的第二道防线，第一道是 repo 可见性（见 README）
6. 人扫一眼确认 root cause 和 fix → done（30 秒内）

产出落点

• postmortems/inbox/<case-id>.md（postmortem 或指针）
• postmortems/inbox/<case-id>.case.yaml（YAML 草稿）
• inbox 是待审队列（见 postmortems/inbox/README.md）：每周 /skill:knowledge-groom 批处理三分类（new_pattern / variant_of / covered_by）后人审。审完：postmortem 转正 ../YYYY-QN/（covered 也转正——Tier 3 语料，不是丢弃）、new 的草稿升格 knowledge/<ns>/

生成后明确告诉用户存哪了——报出具体路径（如 postmortems/inbox/custA-ep-hang.md）和 YAML 草稿位置，说明"周审后转正"，别让工程师去找自己的产出。

回写来源 trace 的沉淀状态（诊断闭环）：若本次沉淀来源是一个诊断 trace（输入提到 traces/<session_id>.yaml，或用户从诊断面板"沉淀此案例"触发），产出草稿落 inbox 后回写该 trace 的 sedimented.state: submitted（动作发生时写，零推断）——诊断面板据此显示"已提交沉淀待审"，不再重复提示沉淀。转正（knowledge/archived）由用户在面板/对话确认时更新，本 skill 不写。

收尾 evolve-check（伴随演进评估，默认执行）

先落执行记录（evolve-check 读它作现场）： python3 scripts/log_skill_exec.py --skill to-postmortem --products "<case-id>(submitted),..." --reason "<一句话根因/来源>" --source <来源 skill> --tokens <估算>

草稿产出、出最终报告前，执行一次伴随演进评估（read skills/evolve-check/SKILL.md 遵循）：本轮沉淀 ≥3 条同根因/同族 case（T1 → 归纳 reference 候选）、replay/Tier 3 暴露覆盖缺口（T2）、或提取/校验环节有重复手动动作与流程摩擦（T3/T4）时，agent 自动产 idea 卡并自行验证执行（ev_proposal 产卡 → golden/S2 验证 → 进攒批）；无 信号则报告加一行"evolve-check：无演进信号"。这是流程默认收尾，不需要用户另说 "改进系统"——演进由数据触发，像人学习。产出与流程报告一并给出。

为什么是这个体系的核心

团队不能统一 agent 时，知识注入入口必须与诊断工具解耦。/to-postmortem 是这个解耦的实现——任何工具的对话都能沉淀。别期望团队成员额外写文档，agent 提取、人审批，成本从 20 分钟降到 30 秒。