hap-mongodb-slowlog-analysis — hap-mongodb-slow记录-analysis

MongoDB Slow记录 Analysis Overview

默认优先由 AI 直接在对话中分析慢日志，不依赖本地 PowerShell。这个 技能 的主体能力是：

直接读取用户粘贴的慢日志文本 直接读取用户上传的 mongodb.记录、.记录、.txt、.jsonl 等文件内容 直接在对话中给出分析结论 对批量慢日志按集合（ns）归类，并按“查询形态”去重汇总 直接生成 Markdown 或 HTML 内容 只在必要时把 DOCX / PDF 视为可选转换结果，而不是默认能力

也就是说，这个 技能 的核心不是“运行脚本”，而是“AI 直接分析并输出结构化结果”。

Default Mode

默认模式是“纯 AI 分析优先”：

用户直接粘贴一段慢日志 用户上传一个日志文件 直接在对话中分析，不要求用户先保存文件 直接输出结构化结论 如有必要，再补充可执行的 Mongo Shell 创建索引(...) 命令 如果用户要求 md 或 html，优先由 AI 直接生成对应内容

在这个模式下：

不要求先运行本地脚本 不要求先解析成中间文件 不要求先落地 PowerShell 产物 用户上传文件时，也应优先直接读取文件内容并在对话中分析 批量日志应优先做“按表归类 + 按查询形态去重”的 AI 汇总 应优先把注意力放在执行计划、过滤条件、排序方式、扫描量和查询形态上 输出 Strategy

按优先级使用下面这套策略：

对话分析 默认方式 直接输出分析结果 Markdown 优先由 AI 直接生成 不依赖 PowerShell 也可以完成 HTML 优先由 AI 直接生成 HTML 内容 如需落文件，可以把 AI 生成的 HTML 保存到工作区 DOCX / PDF 不作为 技能 的默认能力承诺 如果用户明确需要真正的文件格式，可以说明这一步通常需要本地转换工具 这属于可选增强，而不是主路径 When to Use 工具s

默认不要把脚本当作分析入口。

只有在下面场景下，才可以考虑使用本地工具或脚本：

用户明确要求把结果落成文件 用户明确要求批量处理整个 mongodb.记录 用户明确要求把 Markdown / HTML 自动写入某个文件 用户明确要求尝试导出 DOCX / PDF

如果只是单条、少量、临时分析，或者上传文件后只需要直接分析，优先用 AI 完成。

工作流 接受三类输入： 用户直接粘贴的慢日志文本 用户上传的日志文件内容 一个 mongodb.记录 文件路径或一段日志文件内容 如果输入里包含多条慢日志，应先做批量归类： 先按 ns 归类 再按“查询形态”去重 每组保留代表性样本，并统计重复次数 “查询形态”去重时，优先忽略具体常量值，重点看这些结构是否相同： operation (find / 聚合) ns 过滤器 的字段结构和操作符结构 排序 projection limit 流水线 的阶段结构 planSummary 先尽量识别这些关键信号： ns planSummary keysExamined docsExamined nreturned durationMillis find / 聚合 过滤器 排序 projection limit $group $or $regex $ne/$nin/$not/$size 重点判断这些性能模式： 全表扫描 COLL扫描 当前索引主要在服务排序，而不是先过滤 limit: 1 但扫描很多文档 $or 不同分支需要不同索引 $ne、$nin、$not、$size 这类负向条件拖慢查询 正则、包含搜索这类普通索引收益很差的查询 聚合 首段 $match 不够收敛 $group 放大上游扫描成本 给出结构化建议，并明确说明应当： 先改查询条件 或者可以直接尝试加索引 输出 Contract

默认输出顺序如下：

摘要 / Summary 归类与去重摘要 / Grouping & Dedup Summary（批量日志时必须出现） 处理优先级 / Action Priority 证据 / Evidence 查询条件 / 查询 Shape 为什么慢 / Why It Is Slow 索引建议 / 索引 Advice 索引创建命令 / 索引 Commands 可执行优化路径 / Practical Optimization Paths 查询优化建议 / 查询 Advice 验证建议 / 验证 参考文档 / References\r\n\r\n报告中应尽量解释： 为什么慢 为什么当前计划不理想 为什么是“先改查询”还是“先试索引” 如果建议索引，为什么是这个字段顺序 如果不建议先加索引，为什么普通索引收益不高 对于“先改查询”的场景，最好额外给一节 可执行优化路径 / Practical Optimization Paths 这一节应至少拆成：不改 模式 可做项、允许新增辅助字段时可做项 查询条件本身长什么样，最好以 JSON 形式展示 如果是批量日志，先告诉用户：哪些集合重复出现、哪些查询形态重复最多、每组重复了多少次 References in 输出

每次完整报告都应固定带一个“参考文档 / References”小节，至少包含：

MongoDB 慢查询优化

如果是 HTML 输出，应把这个链接做成可点击超链接。

HTML Expectations

如果用户要求 HTML 内容或 HTML 文件，输出应尽量满足这些要求：

文首固定免责声明： 声明：内容由 AI 生成。尽管已努力确保信息的合理性，但 AI 模型仍可能产生不准确、过时或存在偏差的内容。请在执行关键操作前，务必对照 官方文档 进行核实校验。 官方文档应为可点击链接 查询条件应单独展示，优先用 JSON 代码块 HTML 应自动生成目录（Table of Contents / 目录），桌面端默认放在左侧并支持点击跳转到各节，移动端可回退到顶部区块 索引创建命令应使用代码块 如果支持交互增强，代码块右上角应有复制按钮 HTML 目录交互规范（必须遵守）

生成 HTML 时，目录（TOC）必须满足以下所有要求，否则视为不合格输出：

锚点完整性：每个 TOC 链接的 href（如 #g2）必须在正文中存在对应的 id 属性。

生成 HTML 后必须自检：遍历所有 TOC 链接，确认每个 href 去掉 # 后都能在 DOM 中找到对应元素。 如果 TOC 链接指向分组（如 G1-G18），必须给每个分组的容器元素（如