Repository navigation
Proposal: Dashboard 统一承载 Team Execution / Team Context / Team Improvement #407
Description
背景
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，展示最后同步时间
当前架构不能提供真正的跨成员实时状态，因此第一阶段不得把团队快照标记为实时。跨机器实时心跳需要认证、中心服务和隐私策略，应作为后续独立阶段。
隐私原则
建议划分三层：
- 本机敏感数据：原始 prompt、AI output、完整事件时间线
- 团队脱敏数据：任务摘要、状态、计数、仓库、工具、知识 ID
- 团队聚合数据：趋势、覆盖率、采用率、摩擦模式
默认不上传原始 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 使用量等同于生产力
- 不建设竞争性个人排行榜
- 不要求第一阶段迁移到大型前端框架
相关方向
- Skills 可视化控制台：发现、安装、启停与按 Skill 配置模型 #17 Skills 可视化控制台，可逐步整合进 Team Context
- Proposal: 基于 Go 的 TeamAI 管理后端（零 Git 接入与多项目管理） #341 管理后端可作为未来跨机器实时与统一权限的数据基础，但不应阻塞 Phase 1
Activity