to-postmortemlisted

# 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。 ## 流程 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 草稿 + po