Proposal: Dashboard 统一承载 Team Execution / Team Context / Team Improvement

背景

TeamAI 后续整体产品架构将围绕三项核心能力展开：

• Team Execution：团队如何使用 AI 完成任务
• Team Context：AI 如何获得团队共享的知识、规则和经验
• Team Improvement：如何从每次执行中发现问题并持续改进团队 AI 能力

目前 Dashboard 主要是本机 AI 会话监控，并提供 KB Health 入口。底层已经具备不少可复用数据：

• 本机会话事件流与 SSE 实时更新
• session、prompt、token、interrupt、tool reject、correction 等指标
• 按仓库归因和时间分布分析
• 团队 stats/*.yaml、votes/*.yaml、sessions/*/*.md 聚合数据
• KB coverage、recall trend、热门/沉默知识、维护候选

但这些能力目前缺少统一的产品叙事和操作入口。建议将 Dashboard 从“本机会话状态页”升级为三大产品模块的统一可视化和操作层。

产品定位

Dashboard 不是 TeamAI 的第四个产品模块，而是 Team Execution、Team Context、Team Improvement 的统一观察、分析和行动界面。

核心闭环：

Team Execution
  ├─ 使用 Team Context 完成任务
  └─ 产生会话、错误、纠偏和经验
            ↓
Team Improvement
  ├─ 识别高摩擦模式和上下文缺口
  ├─ 提出并应用改进
  └─ 将改进沉淀为 Skill / Rule / Doc / Learning
            ↓
Team Context
  └─ 在后续 Team Execution 中被召回并验证效果

最终需要回答一个关键问题：

某个团队 Skill、Rule 或知识上线后，是否真的改善了 AI 执行效果？

信息架构

建议主导航调整为：

TeamAI
├── Overview
├── Team Execution
├── Team Context
└── Team Improvement

1. Overview

首页按三大模块展示状态，不堆叠无明确用途的指标。

Team Execution 摘要

• 当前运行、等待确认、异常、最近完成的会话
• 时间范围内的会话数和人工对话轮数
• 活跃仓库和 AI 工具
• 干预次数/会话

Team Context 摘要

• 知识覆盖率
• Recall 渗透率
• Skill 采用率
• 沉默、过期和待维护知识数量

Team Improvement 摘要

• 新发现的改进机会
• 可晋升 Learnings
• 已应用但待验证的改进
• 最近确认有效的 Skill/Rule 变更

需要关注

首页统一展示跨模块的可行动信号，例如：

• 某类任务连续发生纠偏
• 某知识被频繁召回但伴随负反馈
• 某 Learning 已达到晋升条件
• 某 Skill/Rule 上线后干预率没有下降

每条信号必须能下钻到相关会话、知识或改进项，并提供下一步操作。

2. Team Execution

升级现有实时会话页面，分成三层：

实时状态

• AI 工作中
• 等待用户确认
• 异常
• 空闲
• 最近结束

执行分析

• 按仓库、成员、AI 工具查看会话
• 会话和人工对话趋势
• interrupt / toolReject / correction / toolError
• 长会话和重复尝试
• Token 构成仅作为成本与异常诊断信号

会话详情

任务摘要
→ 召回了哪些团队知识
→ 使用了哪些 Skill 和工具
→ 在哪里发生错误或纠偏
→ 最终结果
→ 是否产生可复用经验

3. Team Context

Team Context 不只是知识文件列表，需要展示知识从生产到消费的完整生命周期：

贡献 → 索引 → Recall → 实际使用 → 反馈 → 更新/晋升

建议包含：

• Context Inventory：Skills、Rules、Docs、Learnings 的数量与分布
• Context Coverage：哪些领域已有覆盖
• Context Usage：哪些内容实际被召回
• Context Quality：召回后是否减少错误与纠偏
• Context Gap：哪些高频任务缺少可用知识
• Context Maintenance：晋升、更新、合并和清理候选

需要严格区分：

• 知识覆盖率：至少被召回一次的知识数 / 知识总数
• Recall 渗透率：触发 Recall 的会话数 / 总会话数
• Recall 有效率：使用上下文后执行质量是否改善
• Skill 采用率：使用过某 Skill 的活跃成员数 / 活跃成员数

4. Team Improvement

新增明确的持续改进工作流：

Detected → Proposed → Applied → Validating → Verified / Rejected

改进机会的来源包括：

• 重复 correction
• 重复 toolError 或 fallback
• 高频 toolReject
• 长时间、重复尝试的会话
• 高频任务但没有 Context 命中
• 被召回后仍产生负反馈的知识
• 可晋升 Learning
• 长期未被使用或已失效的知识

建议的数据结构：

id: imp-2026-091
source:
  type: repeated-correction
  sessionIds: [session-a, session-b]
  repo: gateway
proposal:
  type: rule
  target: deployment-safety
  description: 增加发布前权限检查
status: validating
baseline:
  interventionRate: 0.42
after:
  interventionRate: 0.18

本机实时与团队数据边界

必须明确区分两种数据语义：

• 本机实时：继续使用本地 events.jsonl + SSE
• 团队最近同步：读取团队仓库中的 stats、votes、sessions，展示最后同步时间

当前架构不能提供真正的跨成员实时状态，因此第一阶段不得把团队快照标记为实时。跨机器实时心跳需要认证、中心服务和隐私策略，应作为后续独立阶段。

隐私原则

建议划分三层：

1. 本机敏感数据：原始 prompt、AI output、完整事件时间线
2. 团队脱敏数据：任务摘要、状态、计数、仓库、工具、知识 ID
3. 团队聚合数据：趋势、覆盖率、采用率、摩擦模式

默认不上传原始 prompt 和 AI output。个人数据主要用于下钻，不做竞争性成员排行榜；质量分析默认按仓库、任务类型和工具聚合。

数据模型补充

为了建立 Execution → Context → Improvement 的链路，需要贯穿以下 ID：

sessionId
knowledgeId
improvementId
repo
member
timestamp

当前 stats/<user>.yaml 以累计值为主，无法可靠展示趋势。建议向后兼容地增加最近 90 天的每日桶：

daily:
  2026-09-04:
    sessions: 18
    prompts: 62
    recalls: 13
    interventions:
      interrupt: 2
      toolReject: 1
      correction: 3
      toolError: 2
    tokens:
      input: 120000
      output: 34000
    repos:
      teamai-cli:
        sessions: 9
        prompts: 31

还需要新增三类关联事件：

• session 是否触发 Recall，以及召回的 knowledgeId
• Improvement 的创建、应用和验证状态
• Skill/Rule/Doc 变更与 Improvement 的关联

API 建议

第一阶段继续使用本地 HTTP server，由后端完成聚合，前端只负责展示：

GET /api/overview?range=7d
GET /api/execution?range=7d
GET /api/sessions
GET /api/context?range=30d
GET /api/improvements
GET /api/friction?range=30d
GET /events

同时建议逐步拆分当前大型 dashboard-html.ts，避免数据聚合、模板、样式和交互长期耦合在单个 TypeScript 字符串中。

分阶段实现

Phase 1：统一产品结构

• 新增 Overview / Execution / Context / Improvement 导航
• Overview 三模块摘要
• 重构现有会话展示
• 将 KB Health 纳入 Team Context
• 增加团队数据最后同步时间
• 支持时间、仓库和 AI 工具筛选

尽量复用现有数据，不引入中心服务。

Phase 2：补齐趋势与关联

• 每日统计桶
• Recall session 关联
• 仓库维度聚合
• Skill 采用率
• 高摩擦模式与 Context Gap
• Improvement 基础数据模型与状态流转

Phase 3：验证闭环

• Skill/Rule/Doc 变更关联 Improvement
• 改进前后指标对比
• 自动生成改进建议
• 跨机器实时心跳、认证与权限控制

验收标准

• Dashboard 一级导航体现 Team Execution、Team Context、Team Improvement
• Overview 能分别展示三大模块的核心状态与待办
• 明确区分“本机实时”和“团队最近同步”
• Execution 会话能够下钻到 Context 命中和摩擦事件
• Context 页面区分覆盖率、Recall 渗透率和采用率
• Improvement 至少支持 Detected → Applied → Validating → Verified 状态
• 每条“需要关注”信号都有可执行的下一步
• 团队侧默认不暴露原始 prompt 和 AI output
• 不使用个人 Token/干预排名作为绩效指标
• 能追踪一个 Context 变更是否改善后续 Execution 指标

非目标

• 第一阶段不实现真正的跨机器实时会话
• 不把 Token 使用量等同于生产力
• 不建设竞争性个人排行榜
• 不要求第一阶段迁移到大型前端框架

相关方向

• #17 Skills 可视化控制台，可逐步整合进 Team Context
• #341 管理后端可作为未来跨机器实时与统一权限的数据基础，但不应阻塞 Phase 1

Start by reading the existing dashboard-html.ts and the local HTTP server that provides the current session view, then compare available data with the proposed Phase 1 navigation and overview. The issue spans Overview, Execution, Context, Improvement, aggregation, synchronization labels, privacy, and API work, so it should first be split into bounded tasks. Done would require the agreed Phase 1 scope and acceptance criteria to be implemented and tested.