古法编程

Context Mode 的多适配器统计聚合系统通过遍历 15 个 AI 编码平台的会话数据库，用统一的 isReal 过滤器识别真实使用痕迹，并将跨平台数据汇聚为一份“叙事式”统计报告。该系统不再局限于单一平台的静态数据，而是将用户在整个开发环境中分散的上下文消耗、项目活动与记忆沉淀整合成一个连贯的使用故事。

Context Mode 的多适配器统计聚合：跨平台生命周期数据的收集与展示

传统统计功能通常只关注当前激活的单一 AI 编码助手。然而，开发者的工作往往横跨多个工具——可能在 Cursor 中进行原型设计，在 Claude Code 中处理复杂重构，又在 VS Code Copilot 中完成代码审查。Context Mode 的多适配器统计聚合系统正是为了回答“我的整体上下文使用情况如何”这一核心问题而设计。它通过统一的扫描与聚合机制，将分散在不同平台沙箱中的生命周期数据收集起来，并以一种引导用户理解自身使用模式的方式进行展示。

适配器目录遍历：统一的起点

系统的第一步是找到所有可能存储着用户数据的地方。enumerateAdapterDirs 函数承担了这一职责。它内部维护了一个硬编码的映射表，其中包含了 Context Mode 支持的全部 15 个 AI 编码平台（如 Claude Code、Gemini CLI、Cursor、VS Code Copilot 等）的会话与内容数据存储路径。

这个映射表是 src/adapters/detect.ts 中 getSessionDirSegments 函数的镜像，确保了路径定义与适配器检测逻辑保持单一数据源，避免了同步风险。对于每个平台，它会构造出两个关键目录的绝对路径：sessionsDir（用于存储会话事件数据库 SessionDB）和 contentDir（用于存储 FTS5 知识库内容）。

一个重要的设计决策是，enumerateAdapterDirs 会返回所有 15 个平台的目录条目，无论这些目录在磁盘上是否真实存在。这一“纯枚举”特性使得扫描函数（如 getMultiAdapterLifetimeStats）可以独立于文件系统状态进行单元测试，增强了系统的可测试性与鲁棒性。

isReal 使用度过滤：从噪声中识别真实活动

仅仅找到数据库文件是不够的。测试探针、开发骨架或偶然的启动都可能留下微小的、不具备统计意义的数据点。为了过滤掉这些“噪声”，系统引入了 isReal 过滤器。一个适配器目录下的数据只有在通过以下四项严格检查时，才会被标记为 isReal: true，并纳入聚合报告：

  1. 事件数量门槛：eventCount >= 100。要求有足够的活动量来反映真实使用，而非零星的探针。
  2. 项目多样性：distinctProjects >= 5。真正的开发活动会涉及多个项目，单一项目内的大量事件可能源于重复操作。
  3. 时间近因性：lastActivityWithin(30 days)。统计应反映近期的活跃状态，而非远古的历史遗留数据。
  4. 数据质量：avgEventBytes >= 50。每个事件的平均数据长度需达到一定标准，确保记录的事件包含了有意义的内容，而非空洞的元数据。

这一过滤逻辑在测试文件 multi-adapter-stats.test.ts 中得到了明确验证。例如，一个仅有 5 个事件、属于单一项目的适配器会被判定为 isReal: false；即使事件数达到 120 且跨越 6 个项目，但如果每个事件的数据过短（如 "x"），其 avgBytes 低于 50，同样会被过滤。只有同时满足所有四个条件的适配器，才会被视为“真实使用”的来源。

跨平台数据聚合与逐层扫描

getMultiAdapterLifetimeStats 是多适配器聚合的核心入口。它的工作流程如下：

  1. 调用 enumerateAdapterDirs 获得所有 15 个平台的潜在数据目录列表。
  2. 遍历目录列表，对于每个存在的 sessionsDir，扫描其下所有以 .db 结尾的数据库文件。
  3. 对每个数据库文件，以只读模式打开，聚合其中的 session_events 表，统计事件数、分类计数、最早/最晚事件时间等。同时，也会查询 session_resume 表，累加从 /compact 救援快照中恢复的字节数 (rescueBytes)。
  4. 为每个适配器计算 isReal 状态，基于上文所述的四项阈值。
  5. 汇总所有数据，生成最终的 MultiAdapterLifetimeStats 对象。该对象不仅包含 totalEvents、totalSessions、totalBytes 等全局聚合值，还包含一个 perAdapter 数组，详细列出了每个平台的独立统计结果。

getMultiAdapterRealBytesStats 函数采用类似的扫描策略，但目标不同：它专注于聚合来自所有适配器的“真实字节”数据（如 bytesAvoided、bytesReturned、snapshotBytes），用于更精确地计算上下文节省量和 token 消耗。

五段叙述式渲染器：讲述数据的故事

聚合后的原始数据本身是冰冷的。formatReport 函数（及其叙述式渲染器分支）的职责，是将这些数据转化为一份结构清晰、易于理解的报告。当检测到多适配器聚合数据 (multiAdapter) 和会话级数据 (conversation) 均存在时，渲染器会进入一种特殊的五段叙述模式，引导用户循序渐进地理解自己的使用情况。

测试文件 stats-output-format.test.ts 中通过断言严格地固定了这五个部分的标题顺序，确保了用户体验的一致性：

  1. ─── 1. Where you are now ───：当前位置。展示当前会话的基本信息，如启动时间、已存活天数，以及 /compact 救援事件。
  2. ─── 2. What this chat captured ───：本次对话捕获了什么。详细列出当前会话内按类别统计的事件（如“外部文档索引”、“文件跟踪”、“错误捕获”），让用户看到本次会话的活动全貌。
  3. ─── 3. The scope, getting wider ───：范围在扩大。这是展示跨平台统计的核心部分。它会呈现一个“收据”式的列表，对比当前会话的数据与“你所有的工作”（即跨所有适配器的聚合数据）。如果存在多个 isReal 的适配器，报告会在此列出它们的名称和关键统计；同时，被过滤掉的适配器（isReal: false）也会被单独列出，并附上“无真实聊天活动”的说明，保持透明。
  4. ─── 4. The bottom line ───：底线。用商业价值的语言总结，例如计算节省的等效 Opus 4 代币费用，给出明确的金钱价值锚点。
  5. ─── 5. What context-mode learned about how you work ───：Context Mode 学到了什么。展示从自动记忆文件中提取的用户偏好分布，使用直观的柱状图 (█) 进行可视化，让用户了解工具对其工作习惯的观察。

意义：从工具使用到习惯洞察

Context Mode 的多适配器统计聚合系统，其意义超越了简单的数据汇总。它建立了一条从原始事件数据到用户习惯洞察的完整路径。通过 isReal 过滤，它确保了分析的基石是真实的开发活动；通过跨平台扫描，它打破了单工具的信息孤岛；而通过五段叙述式渲染，它最终将数据转化为了一个用户可以反思和行动的“使用故事”。这使开发者不仅能知道“节省了多少上下文”，更能理解“我的 AI 编码模式是怎样的”，从而更好地优化工作流，真正实现“用代码思考”的理念。

FAQ

Q: 为什么要设置 isReal 过滤器？所有数据都有价值吗？ A: isReal 过滤器是为了过滤掉开发测试探针、偶然的启动检测或残留的骨架数据。这些数据量小、活动单一（如仅有一个项目），无法代表真实的开发模式，纳入统计反而会稀释核心信息。只满足阈值的数据，才被视为有意义的“使用痕迹”。

Q: 多适配器统计聚合如何保证数据的一致性？ A: 一致性通过两个机制保证。首先，enumerateAdapterDirs 的路径定义与核心的适配器检测逻辑共享同一份映射表（源码中注释为镜像关系），确保扫描目标准确。其次，对每个数据库的扫描都是独立的、只读的，原始数据不会被修改，聚合只是简单的数学累加，避免了复杂的跨数据库事务问题。