ov-session-report

OpenViking 会话问答周报

仅阅读用户提供的会话数据。清理并规范化数据，应用时间窗口，计算指标，分类主题，审查风险，与上一周期进行比较，并生成一个独立完整的 Markdown 文件。默认时区为 Asia/Shanghai。

交付范围

• 唯一的分析来源是 sessions_root 下的会话文件。不要获取或合并其他社区、消息流、目录或在线聊天数据。
• 只交付一个 .md 文件。分析期间允许使用临时脚本和中间文件，但报告必须在不依赖这些文件的情况下也能看懂。
• 不要调用在线文档、消息、联系人或白板 API。不要创建 XML、HTML、SVG 或 PNG 文件，也不要上传任何内容。
• 满足文档和白板数据要求。Markdown 必须包含足够的汇总数据、时间序列、排名、结论和人工消息摘录，以便下游渲染器无需重新打开会话，就能生成完整的报告正文、摘要仪表板和比较仪表板。
• 绝不要凭直觉估算数量。每个数字都必须来自解析后的数据或可复现的公式；每项重要结论都必须能追溯到具体的会话消息。
• 如果会话无法证实某项说法，应写明“截至数据截止时间，未找到支持性证据”，不要将其表述为普遍事实。

默认输出文件名：

OpenViking_Community_QA_Weekly_Report_YYYY-MM-DD_to_YYYY-MM-DD.md

输入

• sessions_root：必填。从此目录递归读取 .jsonl 会话文件。
• current_start / current_end：可选。当前报告窗口的边界。
• previous_start / previous_end：可选。上一比较窗口的边界。
• previous_report：可选。由此技能创建的 Markdown 报告。使用它来保留已发布的定义和历史数据。
• output_path：可选。若未指定，则写入当前工作区中的 reports/qa-weekly-YYYYMMDD-YYYYMMDD/。
• session_scope：可选。用户提供的子目录、文件名模式或明确指定的会话集合。
• history：可选。供下游文档渲染使用的、已核实的报告标题和链接。直接传递这些内容，不要查询。

尽可能根据目录结构、时间戳和上一份报告推断缺失值。只有在无法确定目标会话集合或报告边界，且不同选择会实质性改变结果时，才询问用户。

报告顺序

Markdown 报告必须按以下顺序组织：

1. 标题：OpenViking Community Q&A Weekly Report: YYYY-MM-DD to YYYY-MM-DD
2. 执行摘要
3. 本周发布
4. 每周主题排名
5. 待解决的高优先级问题
6. 周环比比较
7. 每周活动
8. 趋势与建议
9. 方法与数据说明
10. 往期报告
11. 附录：结构化报告数据

“本周发布”只能汇总会话中有明确证据（例如“已发布”“已部署”或“已可安装”）的版本。“计划中”“预计”或“将在下一版本中包含”等说法不代表已完成发布。如果没有符合条件的证据，应写明：“根据本周会话，无法确认有正式版本发布。”不要通过浏览网页进行确认。

时间窗口

使用左闭右开区间：

Current:  [current_start, current_end)
Previous: [previous_start, previous_end)

按以下顺序选择截止时间：

1. 用户明确指定的截止时间。
2. 对于已建立的每周系列，使用上一份报告的 current_end + 7 days。
3. 用户说“截至现在”时，使用 Asia/Shanghai 时区的当前时间。
4. 仅当用户明确说明该目录是某个时间点的导出快照时，才使用最新消息的时间戳。

比较要求：

• 当前窗口和上一窗口的时长必须相同，首尾相接且不得重叠。
• 默认使用连续的七天窗口。如果用户要求首个周期更短，请在标题和方法说明中注明实际范围。
• 时间戳大于或等于当前截止时间的消息属于下一份报告。
• 如果最早导出的消息晚于请求的开始时间，请保留请求的窗口，并说明覆盖不完整。
• 记录最早和最晚的有效消息，以及它们与请求边界的时间差。
• 如果当前目录缺少上一窗口的数据，优先使用 previous_report 中的结构化附录。如果两者都不可用，请保留比较部分，并标明上一周期数据不可用。绝不要用 0 替代未知值。

发现会话文件

首先列出候选文件：

rg --files "$SESSION_ROOT" -g '*.jsonl'

不要假定目录中的每个文件都属于目标数据集：

1. 按目录层级、文件名前缀和可用元数据对文件分组。统计每组文件数量，并确定各组的时间范围。
2. 从每组的开头、中间和结尾抽样人工消息，以确认其中包含 OpenViking 社区问答会话。
3. 排除测试对话、内部调试、机器人自测、无关产品和明显无关的数据。
4. 用户提供精确的 session_scope 时，应予以遵从，但仍需验证其中包含数据。
5. 在方法部分记录发现、纳入和排除的文件数量及排除原因。仅披露经过脱敏处理的内部标识符摘要。

不要仅因某个数据集包含的文件数量最多，就将其选为目标数据集。

解析和规范化 JSONL

对每一行使用真正的 JSON 解析器：

• 在 bad_lines 中统计格式错误的行。保留文件名和行号以供本地审计，但不要在最终报告中披露。
• 跳过 _type=metadata 等非消息行，同时仍使用其中的会话标识符和上下文元数据。
• 按以下顺序尝试时间戳字段：timestamp、created_at、create_time、time。支持以秒和毫秒表示的数值时间戳。
• 将带时区的值转换为 Asia/Shanghai。将不带时区的值视为 Asia/Shanghai，并说明这一假设。
• 优先使用纯字符串消息正文。对于结构化正文，在分析期间保留原始对象，并通过其结构化字段提取可读文本，而不要使用脆弱的字符串切片方式。
• 存储原始角色、规范化后的角色、时间戳、会话键、消息键、内部发言者键、显示名称候选项和规范化后的文本。

按以下方式规范化角色：

• user、human 及等效角色计为人工消息。
• assistant、bot 及等效角色计为助手消息。
• system、tool、metadata 及等效记录保持独立，绝不计入人工活动或主题发起者。
• 将未能确定的角色放入 unknown_role_messages，并在做出判断前人工抽样。绝不要默认将未知角色归类为人工消息。

去重与讨论单元

一个唯一会话就是一个讨论单元。

按以下顺序去重：

1. 优先使用稳定的消息 ID。
2. 如果缺少消息 ID，则对 session_key + timestamp + sender_key + normalized_text 进行哈希。
3. 对重复的会话导出文件只保留一份，优先选择消息更完整、时间覆盖范围更广的文件。
4. 如果文件中只有一部分落在时间窗口内，则只统计窗口内的消息。可以阅读相邻的窗口外消息作为上下文，但不得计入统计。
5. 仅当同一问题的文件共享根键、回复链或其他强有力的重复证据时，才合并这些文件。仅文本相似并不足以构成合并依据。

有效讨论包含真实的技术问题、故障、设计比较、使用反馈或可执行的答复。纯粹分享、状态更新、问候、机器人测试和不含实质内容的链接转发可以计入消息总数，但不计为有效讨论。

解析并屏蔽身份信息

显示名称只能来自会话文件：

1. 消息中的明确显示名称字段。
2. 与同一内部身份反复关联的稳定 [Name]: 或 [Name]： 前缀。
3. 如果两者均不可用，则使用 Name unavailable。绝不可猜测姓名或显示内部身份键。

当一个身份对应多个显示名称候选项时，应根据出现频率、时间连续性和上下文进行审查。证据不足时，应将这些身份分开处理。

屏蔽规则：

• 一个字符：显示为 *。
• 两个字符：保留第一个字符，例如 张三 -> 张*。
• 三个或更多字符：保留首尾字符，将中间的每个字符替换为 *，例如 秦浩杰 -> 秦*杰。
• 对拉丁字母、数字和混合别名应用相同的按字符处理规则，例如 darren -> d****n 和 Lin101 -> L****1。
• 用户声明的敏感姓名优先于通用规则，仅保留第一个字符，例如 胡江涛 -> 胡**。
• 在 Markdown 正文中，如果屏蔽用的星号出现在强调语法内，应对其进行转义，例如 Q\*n；在结构化 JSON 中保留原始值 Q*n。

最终的 Markdown 和结构化 JSON 不得包含完整的人名、电子邮件地址、电话号码、原始身份键、Authorization 值、API 密钥、根键、租户键或类似凭据的长字符串。

指标

两个时间窗口必须使用相同的代码和定义。至少计算：

• discussion_units：唯一会话数。
• effective_discussions：有效讨论单元数。
• participants：窗口内的唯一人类身份数。
• human_messages：人类消息数。
• assistant_messages：助手回复数。
• system_messages：系统和工具消息数。
• unknown_role_messages：角色仍未解析的消息数。
• total_messages：所有计入统计的消息数。

必须满足以下不变量：

human_messages + assistant_messages + system_messages + unknown_role_messages = total_messages

参与者数量、Top 10 用户和关键词必须仅基于人类消息。助手消息可以帮助理解问答上下文，或判断问题是否得到回复，但不得使人类排名数据增加。

主题与关键词

跨周使用稳定的主题分类。建议采用以下基准分类：

• 存储、索引与检索
• 机器人、Agent 与技能应用
• 部署、运行时与环境配置
• 记忆、压缩与归档
• 模型、解析质量与成本
• 权限、多租户与协作
• SDK、API 与工具
• 文档、示例与使用问题
• 其他

分类规则：

• 分配多标签主题前，先阅读整个会话。
• 一个讨论单元可以匹配多个主题，因此各主题的计数之和不必等于讨论单元总数。
• 对每个主题，统计讨论单元数、参与者数、人类消息数、关键词，并提炼一条简洁的洞察。
• 按讨论单元数、人类消息数、参与者数以及稳定的主题顺序排列主题。
• 计算 Top 20 前，统一关键词的大小写、全半角变体、单复数形式和常见别名。
• 删除不含主题意义的停用词、问候语、模板文本、隐去的姓名和路径片段。
• 保留可识别的技术拼写，例如 Memory、add_resource、VLM 和 MCP。

手动抽查热门主题和关键词对应的会话，发现误分类、日志噪声或由助手重复发言造成的频次虚高。

未解决的高优先级问题

仅纳入截至数据截止时间仍未解决的高优先级问题，默认最多列出四项。此处的“未解决”是指，现有会话中没有完整证据链证明在截止时间之前已明确修复、发布可用版本、恢复现有实例，并由用户验证。

候选问题必须至少满足以下一项：

• 多名互不相关的用户报告了同一问题。
• 存在具体日志、故障率或可复现步骤，并有维护者确认。
• 问题影响核心路径，例如 Session Commit、资源导入、语义索引、权限隔离或数据完整性。

排除：

• 在可用数据窗口内已修复并由用户验证的问题。
• 缺乏上下文的一次性错误、常规配置问题，或仅在助手回复中出现的假设。
• 安全测试、闲聊、机器人之间的交流，或缺乏依据的根因判断。

每个问题必须包含以下六个字段：

1. Priority / Category
2. Background
3. User Impact
4. Evidence
5. Current Assessment
6. Community Feedback

每个问题后必须紧接其对应的 Human Feedback Excerpt。仅纳入人类消息，省略助手回复和内部链接：

> **08-31 21:16 | O\*\*\*r**
> Session Commit has failed repeatedly...
>
> **08-31 21:19 | 秦\*杰**
> The current fix direction is still incorrect and needs another revision.

每条摘录都必须来自与该问题相关的会话，并保留时间戳、隐去的姓名和核心含义。长日志可以缩短，也可以省略无关文本，但绝不能编造对话，也不能混入其他问题的消息。

本周发布

仅提取会话中明确表示已完成发布的信号：版本、确认时间、主要变更、修复内容、升级警告和相关讨论。

• 仅统计“已发布”“已部署”或“新版本已可用”等表述。
• 将“正在准备发布”“预计发布”和“下个版本”视为计划，而非已完成发布。
• 如果消息相互矛盾，以较晚且有用户验证支持的表述为准，并在证据说明中保留不确定性。
• 如果证据不足，保留本节并写明：“无法从本周的会话中确认正式发布。”
• 仅保留会话中明确出现且格式基本有效的 URL。不要浏览网页或编造链接。

周同比比较

先比较规模，再比较内容：

1. 讨论单元、有效讨论、参与者、人类消息、助手消息和消息总数的前期值与当前值、绝对变化量及百分比变化。
2. 每个稳定主题类别的前期值与当前值，以及百分比变化。
3. 热门关键词和最活跃用户的变化。
4. 前期关注点、当前关注点，以及对每项重大变化的解读。
5. 给出一个总体结论，区分活动量变化与讨论内容变化。

百分比变化公式：

(current - previous) / previous * 100

当前值大于零而前期值为零时，显示 New。两者都为零时，显示 0.0%。前期值未知时，显示 Not comparable；绝不能用零替代未知值。

关注点变化必须依据人工审阅两个时间窗口中的高频会话摘要得出。不要仅根据关键词变化推断。

每周活动

包括：

• 参与者、人类消息、助手消息、系统消息和消息总数。
• 七天时间窗口内每日的人类消息、助手消息和消息总数。
• 00 至 23 点每个小时的人类消息数。
• 高峰时段、次高时段和高峰日。
• 活跃度最高的 10 位真人用户，包括排名、脱敏显示名称、消息数、讨论单元数和核心关键词。
• 可选的回答覆盖率和响应延迟。只有在消息顺序和回复关系可靠时才计算，并将其标注为启发式指标。

以 Mermaid 呈现高峰时段序列，同时保留完整的 24 小时表格：

xychart-beta
    title "Hourly Human Message Distribution (CST)"
    x-axis ["00","01","02","03","04","05","06","07","08","09","10","11","12","13","14","15","16","17","18","19","20","21","22","23"]
    y-axis "Messages" 0 --> MAX
    line [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

替换 MAX 和全部 24 个数据点。如果 Mermaid 无法渲染，完整数据表仍必须保留结果。

趋势与建议

提出三至六条可执行的建议。每条建议都必须包括：

• 观察到的事实或变化。
• 其对问答效率、产品体验或维护工作的影响。
• 涉及修复、文档、监控、发布、回归测试或沟通的具体行动。

优先处理未解决的 P1 问题、反复出现的高频问题、发布后的兼容性警告、活动变化和数据质量缺口。避免使用“继续监控”或“进一步优化”等没有明确行动的空泛表述。

文档和白板数据要求

此技能不会创建在线文档，但其 Markdown 输出必须能直接用于当前的周报版式。

摘要仪表板

结构化数据必须足以生成：

• 四项 KPI：讨论单元、有效讨论、参与者和消息总数。
• 每周排名前 6 的主题及其讨论单元条形图。
• 最多四张未解决的 P1 卡片。
• 24 小时人类消息折线图及高峰日标注。
• 活跃度最高的 10 位社区成员。
• 排名前 20 的核心关键词。紧凑版白板可显示前 12 个，但 Markdown 必须保留全部 20 个。

比较仪表板

结构化数据必须足以生成：

• 三张前期至当前的指标卡片：讨论单元、参与者和消息总数。
• 稳定主题类别排名前 6 的并列条形图。
• 关注点变化列表。
• 同时涵盖活动量和讨论内容的总体结论。

正文

• 根据结构化指标和结论撰写执行摘要。
• 根据会话中找到的明确已完成发布证据编写发布部分。
• 为每个 P1 呈现六个字段和独立的模拟真人聊天区块。
• 在正文中列出全部六项比较指标，同时在白板上仅保留三项核心指标。
• 为建议、方法说明和前期报告链接保留独立字段。

任何重要数字都不得只出现在叙述文字中，而缺失于结构化数据。

qa-report.v3 数据契约

Markdown 文档必须以一个 qa-report.v3 JSON 对象结尾。正文供阅读；JSON 是下游文档和白板渲染的权威数据源。

规则：

• JSON 必须有效，且不得包含注释、尾随逗号、NaN、省略号或占位符。
• 将其放在 和 之间，并确保它是文档中最后一个带 JSON 标记的围栏代码块。
• 使用带 +08:00 的 ISO 8601 时间戳、YYYY-MM-DD 日期，以及 0 至 23 的整数小时。
• 计数存储为整数，百分比存储为数字。未知值使用 null；不得用零代替。
• daily 必须覆盖当前窗口中的每个日期切片。hourly 必须恰好包含 24 个条目，包括无活动时段的零值。
• 写入 JSON 前，必须对所有人员显示名称进行脱敏。不得存储名称映射或内部身份键。
• 正文中的每个数值都必须能直接从此对象读取，或通过简单算术、排序或百分比变化公式复现。

必填字段：

{
  "schema_version": "qa-report.v3",
  "report": {
    "title": "OpenViking Community Q&A Weekly Report: YYYY-MM-DD to YYYY-MM-DD",
    "generated_at": "YYYY-MM-DDTHH:mm:ss+08:00",
    "timezone": "Asia/Shanghai",
    "window": {
      "current": {"start": "YYYY-MM-DDTHH:mm:ss+08:00", "end": "YYYY-MM-DDTHH:mm:ss+08:00"},
      "previous": {"start": "YYYY-MM-DDTHH:mm:ss+08:00", "end": "YYYY-MM-DDTHH:mm:ss+08:00"}
    },
    "coverage": {
      "sessions_root": "user-supplied local path",
      "discovered_files": 0,
      "included_files": 0,
      "excluded_files": 0,
      "included_sessions": 0,
      "earliest_message": null,
      "latest_message": null,
      "bad_lines": 0,
      "missing_timestamps": 0,
      "complete": true,
      "notes": []
    }
  },
  "summary": {
    "headline": "One overall conclusion",
    "top_topic_names": [],
    "peak_hour": 0,
    "peak_hour_messages": 0,
    "peak_day": "YYYY-MM-DD",
    "peak_day_messages": 0,
    "open_p1_count": 0,
    "release_versions": []
  },
  "presentation": {
    "section_order": [
      "Executive Summary",
      "Releases This Week",
      "Weekly Topic Ranking",
      "Open High-Priority Issues",
      "Week-over-Week Comparison",
      "Weekly Activity",
      "Trends and Recommendations",
      "Methodology and Data Notes",
      "Previous Reports"
    ],
    "summary_dashboard": {
      "kpi_metric_order": ["discussion_units", "effective_discussions", "participants", "total_messages"],
      "topic_limit": 6,
      "anomaly_limit": 4,
      "hourly_series": "human_messages",
      "top_user_limit": 10,
      "keyword_limit": 20,
      "compact_keyword_limit": 12
    },
    "comparison_dashboard": {
      "metric_order": ["discussion_units", "participants", "total_messages"],
      "show_topic_change": true,
      "show_focus_shift": true
    }
  },
  "metrics": {
    "current": {
      "discussion_units": 0,
      "effective_discussions": 0,
      "participants": 0,
      "human_messages": 0,
      "assistant_messages": 0,
      "system_messages": 0,
      "unknown_role_messages": 0,
      "total_messages": 0
    },
    "previous": {
      "discussion_units": 0,
      "effective_discussions": 0,
      "participants": 0,
      "human_messages": 0,
      "assistant_messages": 0,
      "system_messages": 0,
      "unknown_role_messages": 0,
      "total_messages": 0
    }
  },
  "topics": [
    {
      "rank": 1,
      "name": "Topic name",
      "current": {"discussion_units": 0, "participants": 0, "human_messages": 0},
      "previous": {"discussion_units": 0, "participants": 0, "human_messages": 0},
      "delta_pct": 0.0,
      "keywords": [],
      "insight": ""
    }
  ],
  "keywords": [
    {"rank": 1, "keyword": "Memory", "current_count": 0, "previous_count": 0, "delta_pct": 0.0}
  ],
  "activity": {
    "daily": [
      {"date": "YYYY-MM-DD", "human_messages": 0, "assistant_messages": 0, "total_messages": 0}
    ],
    "hourly": [
      {"hour": 0, "human_messages": 0}
    ],
    "peaks": {
      "top_hours": [{"hour": 0, "messages": 0}],
      "top_day": {"date": "YYYY-MM-DD", "messages": 0}
    },
    "top_users": [
      {"rank": 1, "display_name": "Q*n", "messages": 0, "discussion_units": 0, "keywords": []}
    ],
    "response_metrics": {
      "available": false,
      "answered_discussions": null,
      "answer_rate_pct": null,
      "median_latency_seconds": null,
      "p90_latency_seconds": null,
      "method": ""
    }
  },
  "releases": [
    {
      "version": "vX.Y.Z",
      "published_at": "YYYY-MM-DDTHH:mm:ss+08:00",
      "type": "main|hotfix|component",
      "url": null,
      "highlights": [],
      "reliability_fixes": [],
      "breaking_changes": [],
      "related_topics": [],
      "evidence": []
    }
  ],
  "anomalies": [
    {
      "rank": 1,
      "title": "Issue title",
      "short_label": "Short label for the dashboard risk card",
      "priority": "P1",
      "category": "Category",
      "background": "",
      "user_impact": "",
      "evidence": "",
      "current_assessment": "",
      "community_feedback": "",
      "unresolved_at_cutoff": true,
      "chat": [
        {"time": "MM-DD HH:mm", "speaker": "Q*n", "message": "Masked human message"}
      ]
    }
  ],
  "comparison": {
    "available": true,
    "metric_conclusion": "",
    "topic_conclusion": "",
    "focus_shifts": [
      {"previous_focus": "", "current_focus": "", "interpretation": ""}
    ],
    "overall_conclusion": ""
  },
  "recommendations": [
    {"rank": 1, "observation": "", "impact": "", "action": ""}
  ],
  "history": [
    {"title": "Previous report title", "url_or_path": "verified link or relative path"}
  ]
}

如果无法获取上一时段的数据，则将 metrics.previous 设为 null；将每个主题和关键词的 previous/delta_pct 值设为 null；将 comparison.available 设为 false；并在正文中说明原因。不得保留伪造的全零上一时段数据。

Markdown 模板

---
report_schema: qa-report.v3
report_type: openviking_qa_weekly
timezone: Asia/Shanghai
current_start: YYYY-MM-DDTHH:mm:ss+08:00
current_end: YYYY-MM-DDTHH:mm:ss+08:00
previous_start: YYYY-MM-DDTHH:mm:ss+08:00
previous_end: YYYY-MM-DDTHH:mm:ss+08:00
generated_at: YYYY-MM-DDTHH:mm:ss+08:00
---

# OpenViking Community Q&A Weekly Report: YYYY-MM-DD to YYYY-MM-DD

## Executive Summary

- Reporting window: ...
- Weekly volume: ...
- Participation: ...
- Leading topics: ...
- Peak period: ...
- Main conclusion: ...

## Releases This Week

| Version | Time | Type | Highlights | Upgrade Notes | Session Evidence |
| --- | --- | --- | --- | --- | --- |

## Weekly Topic Ranking

| Rank | Topic | Discussion Units | Participants | Human Messages | Keywords | Insight |
| ---: | --- | ---: | ---: | ---: | --- | --- |

### Top 20 Keywords

| Rank | Keyword | Current | Previous | Change |
| ---: | --- | ---: | ---: | ---: |

## Open High-Priority Issues

### 1. Issue Title

- **Priority / Category:** P1 / ...
- **Background:** ...
- **User Impact:** ...
- **Evidence:** ...
- **Current Assessment:** ...
- **Community Feedback:** ...

#### Human Feedback Excerpt

> **Time | Masked Name**
> Message...

## Week-over-Week Comparison

### Core Metrics

| Metric | Previous | Current | Absolute Change | Percentage Change |
| --- | ---: | ---: | ---: | ---: |

### Topic Heat Changes

| Topic | Previous | Current | Change | Interpretation |
| --- | ---: | ---: | ---: | --- |

### Focus and Discussion Shifts

| Previous Focus | Current Focus | Interpretation |
| --- | --- | --- |

## Weekly Activity

### Activity Overview
### Daily Distribution
### Peak-Time Line Chart
### 24-Hour Data
### Top 10 Active Community Members

## Trends and Recommendations

1. ...

## Methodology and Data Notes

- Data directory, discovered files, and included scope.
- Both time windows, timezone, and actual data coverage.
- Deduplication, roles, discussion units, effective discussions, and multi-label topic definitions.
- Malformed lines, missing timestamps, unknown roles, and coverage gaps.
- Display-name resolution and masking rules.

## Previous Reports

- [OpenViking Community Q&A Weekly Report: YYYY-MM-DD to YYYY-MM-DD](verified link or path)

## Appendix: Structured Report Data


```json
{complete qa-report.v3 object}
```

端到端流程

1. 扫描 sessions_root，根据目录、文件名前缀和元数据确定目标会话集合。
2. 解析每一行 JSONL，并记录格式错误的行、缺失的时间戳、未知角色和实际数据覆盖范围。
3. 确定连续且时长相同的当前窗口和上一时段窗口。若缺少上一时段的原始窗口数据，则读取 previous_report。
4. 规范化消息字段、角色和时间戳，然后对消息和重复的会话导出文件去重。
5. 仅根据会话内容解析显示名称，进行脱敏，并扫描敏感信息。
6. 计算两个窗口的讨论单元、有效讨论、参与者和消息指标。
7. 为每个会话编写摘要，使用稳定的主题分类进行归类，并对消息量最大的主题进行人工抽样。
8. 计算 Top 20 关键词、每日和每小时序列、峰值以及最活跃的 Top 10 人员。
9. 跟进每个候选问题的后续消息，只保留截止时间前没有解决证据的 P1 问题。
10. 从会话中提取明确的已完成发布信号。不得将计划中的发布计入。
11. 比较核心指标、主题、关键词和关注领域，然后撰写可执行的建议。
12. 首先组装完整的 qa-report.v3 对象，并使用同一对象生成 Markdown 正文和 Mermaid，避免数值不一致。
13. 重新解析最终 JSON，并验证表格、公式、排序、24 小时序列、脱敏情况以及所有文档和白板字段。

验收清单

• 最终交付物是一个独立完整的 .md 文件，无需临时脚本或缓存即可理解。
• 所有分析数据均来自目标会话和可选的上一份 Markdown 报告；不混入其他消息来源。
• Frontmatter 声明 report_schema: qa-report.v3，且最终 JSON 能成功解析。
• 标题中的日期与当前时间窗口一致；当前窗口和上一窗口长度相同、连续且不重叠。
• 已记录发现、纳入和排除的文件数量、格式错误的行数以及数据覆盖范围。
• 消息角色及总数相互吻合，未知角色不会被默认为人类。
• 每周排名包含讨论单元、参与者、人类消息、关键词和洞察。
• 每周活动包含每日表格、完整的 24 小时表格、折线图、峰值和 Top 10。
• 对比涵盖规模、主题和重点变化；无法获取历史数据时，明确标记为不可比较。
• 发布项仅包含会话确认已完成的状态；证据不足时须明确说明。
• 未解决问题仅包含在截止时间前没有结案证据的 P1 项；每项均包含全部六个字段及其专属的人类消息摘录。
• 人类消息摘录不含助手回复、虚构消息或内部链接。
• 所有人名均已屏蔽；报告中不得出现完整姓名、内部身份密钥或凭据。
• activity.hourly 按 0 至 23 排序，且恰好包含 24 个条目；daily 涵盖当前窗口内的每个日期切片。
• Top 10、Top 20、主题排名和所有百分比变化均可复现。
• 结构化数据足以直接生成摘要仪表板、对比仪表板、P1 正文部分和模拟聊天模块。
• 上一份报告中的条目仅可通过经过验证的链接或路径传递；绝不伪造历史 URL。