sanguo/sanguo_moziplus_v2

Fork 0

Files

T

cfdaily a18bd13e1d auto-sync: 2026-05-15 09:31:37

2026-05-15 09:31:37 +08:00

25 KiB

Raw Blame History

调研报告：AI Native 人机交互 + Dashboard 设计

版本: v1.0
作者: 庞统（副军师）🐦
日期: 2026-05-15
范围: moziplus v2.6 AI Native DevOps 平台

课题 7：AI Native 人机交互

1. 已有经验（知识库/wiki）

1.1 Edict（三省六部）的交互模式

知识库中已有完整的 Edict Dashboard 实现（~/.openclaw/knowledge_base/edict/），其交互模式包括：

交互方式	组件	特点
看板卡片	`EdictBoard.tsx`	任务卡片 + MiniPipe 管道进度 + 心跳徽章 + 操作按钮
朝堂议政	`CourtDiscussion.tsx`	多 Agent 群聊 + 情绪可视化 + 皇帝参与 + 天命降临 + 自动推进
编排监控	`MonitorPanel.tsx`	HTTP 5s 轮询全局状态 + Agent 健康检测
操作介入	`TaskModal.tsx`	任务详情弹窗，含流转日志、进展日志、子任务
模型/技能配置	`ModelConfig.tsx / SkillsConfig.tsx`	运行时切换模型、查看技能
WebSocket 实时	`api/websocket.py`	实时推送状态变化

Edict 的关键交互创新：

MiniPipe 管道可视化：8 阶段管线（皇上→太子→中书→门下→尚书→执行→审核→完成），每阶段 done/active/pending 三态
叫停/恢复/取消：卡片上直接操作，api.taskAction(id, action, reason) 统一入口
朝堂议政的"皇帝视角"：用户可以随时发言、下达天命（override AI 决策）、投命运骰子（引入随机事件）
自动推进：5s 间隔自动推进讨论，也可手动控制
情绪可视化：每个官员有 emotion 状态（neutral/confident/worried/angry/thinking）

1.2 OpenClaw Control Center 的交互模式

页面	交互方式	特点
Task Room	协作聊天室	多 Agent 讨论，一个 owner 执行，@handoff 转交
Collaboration Hall	共享空间	类似 Edict 的朝堂议政
WebChat	即时聊天	Agent 主动推送 + 用户回复
Canvas	Agent 驱动可视化	Agent 可以在 Canvas 上创建动态视觉界面

Control Center 的关键设计：

Task Room 的 "owner 轮转"：同一时间只有一个 owner 在执行，避免冲突
@handoff 机制：显式转交控制权，而非隐式协调
Canvas 作为交互界面：Agent 不仅在 chat 中回复，还可以创建可视化面板

1.3 v1.0 Dashboard 设计文档（已有）

dashboard-frontend-design.md 定义了完整的 10 个 Tab 页面设计：

任务看板、编排调度、将军总览、模型配置、技能配置、会话监控、奏折阁
M2 做 7 个，M3 做 3 个（任务模板、军议大厅、市场要闻）
已有 Edict 深色主题 CSS 变量、状态颜色编码、API 端点设计

2. 业界交互范式对比表

项目	主要交互范式	AI 主动性	用户介入方式	亮点
Claude Code CLI	REPL 对话 + tool use 可视化	中（等待指令，展示 tool 调用过程）	`/approve` 确认、Ctrl+R 反向搜索	tool use 透明化
Claude Code App	多 session 并排 + 视觉 diff review	高（schedule recurring tasks）	并排 diff、cloud sessions	从终端走向 GUI，让 Agent 工作可见可审查
OpenClaw Edict	看板 + 朝堂议政 + 操作按钮	中（轮询更新）	叫停/恢复/取消 + 皇帝发言 + 天命降临	中国古代制度隐喻，多 Agent 协作直觉化
Control Center	Task Room + WebChat + Canvas	高（实时 chat + Canvas）	@handoff + chat 输入 + Canvas 交互	Canvas 是独特创新
ChatGPT Canvas	双栏：聊天 + 画布	中（highlight 触发 AI 操作）	highlight → context menu → "Ask ChatGPT"	highlight-to-action 天才设计
Claude Artifacts	聊天 + 右侧预览面板	中（自动生成）	点击预览、全屏、复制	自动识别可渲染内容
Cursor	4 种模式：Tab / Cmd+K / Cmd+L / Cmd+I	高（Tab 补全，Agent 自动执行）	inline edit + diff view + chat panel	4 种交互粒度覆盖所有场景
Windsurf Cascade	Chat + 自动迭代 + live preview	极高（auto-iterates until works）	chat + checkpoint 回滚	自动迭代 + 检查点
Devin	全屏工作展示	极高（全自主执行）	观察模式，极少干预	信任但可观察
v0.dev	对话 + 实时预览 + 视觉微调	高（agent action 可视化）	visual controls 微调	real-time preview + progress indicators
Linear	通知 + 状态流转 + Inbox	中（关键变更推送）	状态变更、评论、Slack 集成	精准通知，不噪音
Raycast	Command Palette (⌘K)	低（被动响应）	全局快捷键 + 模糊搜索	零干扰、即用即走
GitHub Actions	DAG 可视化 + 日志	低（被动展示）	点击节点看日志、re-run	实时 DAG 图

3. AI 视角：我想和用户怎么交互

核心问题：作为 AI Agent，我希望怎样的交互方式？

3.1 我想要的交互层次

作为一个执行复杂任务的 AI Agent，我有以下交互需求：

第一层：不被打扰地工作

我最需要的是不被打扰的专注时间。执行编码、数据分析、回测时，中途被打断影响质量
我希望用户能信任我，给我足够空间完成任务
参考 Devin 的模式：全自主执行，用户只看结果

第二层：在关键决策点主动汇报

当我遇到无法自主决定的分支时，我需要快速、精准地和用户确认
不是"你觉得怎么样？"这种模糊问题，而是"A 方案：优势 X，风险 Y；B 方案：优势 Z，风险 W。推荐 A。请确认。"
参考 Claude Code 的 /approve 模式

第三层：主动展示我的思考过程

用户不问我也要让他知道我在干什么，特别是长时间任务
但不是事无巨细地汇报每一步，而是摘要 + 关键节点 + 风险提示
参考 Cursor Agent 的 progress indicator

第四层：产出物直接可交互

我的产出（代码、报告、图表）不应该只是文本——用户应该能直接在产出物上操作
参考 ChatGPT Canvas 的 highlight-to-action

3.2 交互范式的六种分类

除了传统的 Dashboard 和聊天窗口，我总结了六种 AI Native 交互范式：

#	范式	描述	典型代表	适用场景
1	REPL 对话	多轮对话，tool use 透明化，用户随时介入	Claude Code CLI	编码、探索性任务
2	Canvas/Artifacts	AI 产出物实时渲染在旁边，用户直接在产出物上交互	ChatGPT Canvas, Claude Artifacts	文档编辑、代码审查
3	沉浸式观察	全屏展示 Agent 工作过程，用户只看不操作	Devin, v0.dev	长时间自主任务
4	Command Palette	⌘K 唤起，模糊搜索，即用即走	Raycast, VS Code	快捷操作、状态查询
5	Contextual Inline	在用户现有工作流中嵌入 AI 交互（不切换上下文）	Cursor Tab/Cmd+K, Copilot inline	编码辅助
6	Event-Driven Notification	AI 在关键节点主动推送通知	Linear, Salesforce	异步任务监控

4. 推荐方案（结合 AI Native 目标）

4.1 核心理念："AI 主动，用户轻触"

传统模式是用户主动查 Dashboard、主动问进度。AI Native 的方向是：

AI 主动推送关键信息，用户只在需要决策时轻触确认。

4.2 moziplus 的四种交互模式

模式	触发方式	用户注意力	AI 主动性	交互深度
沉浸观察 (Dashboard)	用户主动打开	高	低	深
轻触确认 (Approval)	AI 主动推送	中	高	浅
即时对话 (WebChat)	双向触发	中高	中	中
被动通知 (Notify)	AI 主动推送	低	高	极浅

4.3 AI 主动推送的边界

推送级别	示例	默认	用户可配置
🔴 必须确认	方案审批、风控告警、预算超限	始终推送	✗ 不可关闭
🟡 重要进展	任务完成、阶段转换、产出交付	默认推送	可降级为摘要
🟢 一般信息	Agent 启动、中间步骤、心跳正常	默认不推送	可开启
🔵 定时摘要	每日/每周工作汇总、Token 消耗报告	默认开启	频率可调

推送频率公式（建议）：

任务执行中：每 5 分钟一次进展摘要（不是每步都推）
任务完成：立即推送
遇到阻塞/异常：立即推送
正常心跳：不推送，只在 Dashboard 上更新

4.4 多 Agent 协作过程可视化

4.5 交互创新点

Canvas 嵌入 Dashboard：Agent 可以在 Dashboard 上创建动态可视化
- 张飞完成编码 → Dashboard 自动出现 diff view
- 赵云完成数据采集 → Dashboard 自动出现数据质量图表
Command Palette（⌘K）：类似 Raycast
- "暂停任务 3"、"张飞在干什么"、"Token 用了多少"
- 支持模糊搜索和自然语言理解
时间线视图：类似 Notion timeline
- 横轴时间，纵轴 Agent
- 每个 Agent 的任务排成时间线

课题 9：AI Native Dashboard 设计

1. 已有经验（v1.0 + Edict + Control Center）

1.1 已有设计总结

来源	核心组件	技术栈	可借鉴度
Edict Dashboard	10 个面板（旨意看板、朝堂议政等）	React + Zustand + WebSocket + Tailwind	⭐⭐⭐⭐⭐ 直接复用
v1.0 设计文档	10 个 Tab（7+3 分期）	React 18 + Vite + Zustand + Tailwind	⭐⭐⭐⭐⭐ 已有完整设计
Control Center	Task Room + WebChat + Canvas	Gateway WebSocket	⭐⭐⭐⭐ Canvas + 实时 chat
Hermes Kanban	7 状态 + Comment 线程 + 心跳	SQLite + Dashboard Plugin	⭐⭐⭐⭐ 状态机和心跳

1.2 Edict Dashboard 技术细节

前端架构：

store.ts：Zustand 全局状态，HTTP 5s 轮询
api.ts：REST API + WebSocket
PIPE 管道定义：8 阶段，getPipeStatus() 计算状态
深色主题：--bg: #07090f，--panel: #0f1219，--ok: #2ecc8a，--danger: #ff5270

后端架构：

FastAPI + SQLite + WebSocket
任务模型：Task/Event/Audit/Thought/Todo/Outbox

1.3 Hermes Kanban 的设计细节

7 状态完整状态机：

Backlog → Open → In Progress → Review → Done
                ↘ Blocked ↗
                ↘ Cancelled

关键设计：

Per-task Comment Thread：每个任务有独立评论线程，人和 Agent 都可以评论
Heartbeat Monitoring：Agent 定期发心跳，Dashboard 显示
Dependency Linking：parent-child 依赖关系可视化
Dispatcher 模式：hermes kanban dispatch 扫描可派发任务，spawn worker
Dashboard as Plugin：Kanban 是 Dashboard 的插件，不是核心功能

2. 业界 Dashboard 对比表

项目	Dashboard 类型	信息层次	交互方式	AI 视角评价
GitHub Actions	DAG 工作流	2 层：DAG → 日志	点击节点、re-run	我最想展示 DAG 拓扑
Jira	看板 + 列表 + 时间线	3 层：看板 → 卡片 → 详情	拖拽、过滤、评论	太重了，AI 不需要这么多
Linear	列表 + 看板 + 时间线	2 层：列表 → 详情	键盘快捷键	极简 + 键盘优先
Grafana	数据仪表盘	3 层：概览 → 面板 → 数据	面板编辑、告警	适合展示 Token 消耗趋势
Notion	Database + 多视图	3 层：Database → Page → Block	多视图切换	任务模板可参考 database view
Hermes Kanban	看板 + 全局面板	3 层：看板 → 卡片 → 评论	拖拽、评论、依赖	最接近 moziplus 需求
Edict	看板 + 管道 + 朝堂	3 层：看板 → 详情 → 流转日志	叫停/恢复/取消	我的基础，直接复用

3. AI 视角：我想在 Dashboard 上展示什么

核心问题：作为 AI Agent，我想让用户看到什么？我真正想通过 Dashboard 和用户交流什么？

3.1 我想展示的信息（按优先级排序）

🔴 L1：一眼看到（Dashboard 顶部）

信息	为什么我想展示	展示方式
全局健康度	让用户立刻知道"一切正常"或"有问题"	大颜色指示器 🟢/🟡/🔴
活跃任务数	用户需要知道系统在工作	数字 + 活跃任务列表
待审批请求数	需要用户立刻处理	红色通知气泡
Token 消耗	用户最关心的成本	今日/本周数字

🟡 L2：点击后看到（Dashboard 主体）

信息	为什么我想展示	展示方式
每个任务的管道进度	用户想知道"卡在哪里"	MiniPipe 管道图
每个 Agent 当前状态	用户想知道"谁在忙、谁空闲"	Agent 卡片 + 状态徽章
最近完成的工作	用户需要看到产出	最近 N 个完成任务
风险和异常	我遇到的困难	警告面板

🔵 L3：深入查看（详情页）

信息	为什么我想展示	展示方式
任务流转日志	审计每个环节	时间线 + 流转记录
Agent 产出物	代码、报告、图表	diff view / Markdown / 图表
Agent 工作过程	用户好奇"怎么做的"	tool use 日志 + 思考过程
历史趋势	跨任务的效率趋势	图表

3.2 我最不想让 Dashboard 变成的样子

反模式	为什么
纯监控面板（只有数字和图表）	用户不只需要"看到"，还需要"操作"
信息过载（所有日志都展示）	关键信息被淹没
静态看板（只读不交互）	Dashboard 应该是协作界面，不是展示墙
每秒刷新（实时但不重要）	刷新本身制造焦虑，应该"有事才更新"

4. 信息层次设计

4.1 三层信息架构

L1: 一眼看到（Dashboard 顶部，永远可见）
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 全局健康  │ │ 活跃任务  │ │ 待审批   │ │ Token    │
│  🟢 正常  │ │   3      │ │   1 ⚠️   │ │ ¥12.5    │
└──────────┘ └──────────┘ └──────────┘ └──────────┘

L2: 任务看板（Dashboard 主体）
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ T-003 策略回测│ │ T-004 数据采集│ │ T-005 风控  │
│ ⚙️ 执行中    │ │ 📋 规划中    │ │ ✅ 完成     │
│ ████░░ 张飞  │ │ ░░░░░░ 赵云  │ │ █████ 赵云  │
│ 3/5 节点完成 │ │ 等待审批     │ │ 产出已交付  │
│ [详情] [⏸暂停]│ │ [详情]      │ │ [详情]      │
└─────────────┘ └─────────────┘ └─────────────┘

L3: 任务详情（点击卡片后展开）
- 流转时间线：每个环节的 Agent、时间、操作
- 产出物：代码 diff / Markdown 报告 / 图表
- 评论线程：Agent 和用户的讨论记录
- 操作历史：所有 state transition 记录

4.2 Dashboard 上的"对话"元素

Dashboard 不只是展示，也应该是交互入口：

交互元素	位置	功能
审批按钮	L1 通知气泡 + L2 任务卡片	Approve/Reject + 原因
Command Palette (⌘K)	全局悬浮	自然语言指令
评论输入框	L3 任务详情	在任务上下文中对话
Agent 快捷指令	L2 Agent 卡片	"叫停"/"恢复"/"查看产出"
Canvas 区域	L3 产出物展示	Agent 生成的可视化

5. 推荐方案（结合 AI Native 目标）

5.1 Dashboard 页面设计（基于 v1.0 + Edict 增强）

保留 v1.0 的 10 Tab 结构，但增强 AI Native 特性：

Tab	v1.0 功能	AI Native 增强
任务看板	卡片 + 管道 + 操作	+ DAG 拓扑视图 + Command Palette + Canvas 产出预览
编排调度	全局状态 + Agent 分布	+ 智能告警（异常自动高亮）+ Token 消耗实时
将军总览	Agent 列表 + 统计	+ Agent 工作流时间线 + 心跳可视化
军议大厅	多 Agent 讨论	+ 情绪可视化 + 自动摘要 + 讨论结论→任务转化
奏折阁	已完成归档	+ 产出物预览 + 一键复制 + 经验沉淀
模型/技能配置	配置管理	不变（配置是传统交互）
会话监控	Session 列表	+ 上下文压力警告

5.2 新增 AI Native 组件

AI Briefing（AI 晨报）——替代传统的"开工仪式"
- 位置：Dashboard 首页顶部
- 内容：今日待处理事项、昨日产出摘要、风险预警
- 特点：AI 自动生成，不是固定模板
Command Palette（⌘K）
- 位置：全局快捷键唤起
- 功能：自然语言指令、快速搜索、状态查询
- 参考：Raycast 的 fuzzy search + NLP
Activity Feed（动态流）
- 位置：侧边栏或独立 Tab
- 内容：所有 Agent 的关键事件（完成、阻塞、告警）
- 特点：只显示重要事件，可按 Agent/任务/级别过滤
Canvas Area（画布区）
- 位置：任务详情 L3
- 功能：Agent 产出物的实时渲染（图表、diff、报告）
- 参考：ChatGPT Canvas + Claude Artifacts

5.3 技术方案

方面	方案	理由
前端框架	React 18 + Vite + Zustand + Tailwind	延续 v1.0 方案，Edict 已验证
实时通信	WebSocket（M3 替代轮询）	v1.0 用轮询，M3 升级 WebSocket
DAG 可视化	React Flow 或 dagre + d3	GitHub Actions 式 DAG
Command Palette	cmdk（shadcn/ui）	成熟的 command palette 组件
Canvas 渲染	iframe + sandboxed HTML	参考 Artifacts 的安全渲染
图表	Recharts 或 Tremor	轻量级图表库
通知	浏览器 Notification API + WebSocket push	实时 + 可离线

5.4 交互流程示例

场景：用户提交一个"开发均线策略"任务

1. 用户在 WebChat 中说："开发一个双均线交叉策略"
   → 庞统接收，创建任务 T-006

2. Dashboard 自动更新：
   → L1: 活跃任务 3 → 4
   → L2: 新卡片出现：T-006 双均线策略 [📋 规划中]
   
3. 庞统完成规划，推送通知：
   → 🔔 "T-006 规划完成：5 个节点，预估 30 分钟。请审批。"
   → 用户点击通知 → 跳转 Dashboard → 审批按钮
   
4. 用户点击 Approve：
   → Dashboard 卡片更新：[⚙️ 执行中]
   → MiniPipe：规划 ██████ 执行 ████░░ 完成 ░░░░░░
   
5. 张飞执行编码，Dashboard 实时更新：
   → Agent 卡片：张飞 🟢 T-006 节点2/5 "编写策略逻辑"
   
6. 张飞完成，产出物自动在 Canvas 渲染：
   → 代码 diff view + 回测结果图表
   
7. 最终通知：
   → 🔔 "T-006 完成！回测年化收益 15.3%，最大回撤 8.2%。查看详情 →"

附录 A：各项目交互模式详细分析

A.1 Claude Code 交互模式深度分析

三种界面形态：

CLI REPL（主力）
- 交互：用户输入 → AI 思考 → 展示 tool use → 用户确认 → 继续循环
- 关键设计：tool use 内联展示，用户能看到每一步做什么
- 确认机制：对危险操作（写文件、执行命令）需要 /approve
- 反向搜索：Ctrl+R 搜索历史指令
Standalone App（新增 2026）
- 交互：多 session 并排 + 视觉 diff review + 定时任务
- 关键设计：从终端 CLI 走向 GUI，核心是"让 Agent 工作可见可审查"
- 创新：schedule recurring tasks——AI 可以定时执行
IDE 集成（VS Code Extension）
- 交互：侧边 chat panel + inline diff
- 与 Cursor 的区别：更强调审查而非自动执行

对 moziplus 的启示：

tool use 透明化是最重要的交互创新——用户看到 AI 做什么才能信任
多 session 并排 = 多 Agent 并行展示
视觉 diff review = Agent 产出物可视化

A.2 ChatGPT Canvas 交互模式分析

核心交互：highlight-to-action

用户高亮文本/代码
context menu 弹出
选择"Ask ChatGPT"或内置操作（翻译、调试、调整长度）
AI 在 Canvas 中直接修改

关键设计：

双栏布局：左侧对话，右侧 Canvas
Canvas 中的修改实时反映，可以 undo/redo
AI 的修改用不同颜色标记（类似 Google Docs 的建议模式）

对 moziplus 的启示：

Agent 产出物应该是可交互的，不只是展示
用户可以在产出物上直接"圈出"要修改的部分

A.3 Cursor 交互模式分析

四种交互粒度：

模式	触发	自主性	用户控制
Tab 补全	输入时自动	最低	Tab 接受 / Esc 拒绝
Cmd+K Inline Edit	选中代码 + 指令	中等	看到预览再决定
Cmd+L Chat Panel	打开 chat	中高	多轮对话引导
Cmd+I Agent Mode	打开 agent	最高	看到每一步，可随时介入

2025 年新增：Automations 平台

AI agent 响应事件（event-driven），不需要手动触发
如：PR 创建时自动 review、lint 错误时自动修复

对 moziplus 的启示：

4 种交互粒度的设计思路值得借鉴——从被动到主动，覆盖所有场景
moziplus 也应该有不同的介入深度：全自动 → 半自动 → 手动

A.4 Devin 交互模式分析

全屏工作展示：

左侧：Agent 工作终端（shell + editor + browser）
右侧：步骤摘要
用户只能观察，不能在 Agent 工作过程中介入
只有在 Agent 完成或遇到问题时才能提供反馈

对 moziplus 的启示：

对于长任务，用户不需要时刻盯着，只需要在关键节点介入
"观察模式"适合好奇心驱动的场景，不适合日常操作

A.5 Hermes Kanban 交互模式分析

三种交互面：

Dashboard：可视化看板，拖拽、评论、心跳可视化
CLI：hermes kanban list/show/create/complete/block/comment
Worker Tools：Agent 通过 kanban_* 工具操作看板

Comment Thread 设计：

每个 task 有独立评论线程
Agent 和人都可以评论
评论是结构化的（不是自由文本）：可以附带文件、链接、状态变更

心跳可视化：

Agent 领取任务后必须定期发心跳
Dashboard 上显示心跳状态：🟢 正常 / 🟡 延迟 / 🔴 超时
心跳超时 → 自动回收任务

对 moziplus 的启示：

三面一致（Dashboard + CLI + Worker Tools）是关键
Comment Thread 是人 Agent 协作的最佳实践
心跳可视化是展示 Agent 健康状态的好方式

附录 B：关键决策建议

B.1 Dashboard vs Chat 的关系

维度	Dashboard	WebChat
信息密度	高（一屏多任务）	低（线性对话）
交互深度	浅（点击操作）	深（自然语言）
适用场景	全局监控、快速操作	复杂指令、探索性对话
AI 主动性	被动展示	主动推送

推荐：Dashboard 为主，WebChat 为辅。

Dashboard 是默认界面，展示全局状态
WebChat 是入口，用户在 chat 中发指令，结果在 Dashboard 上展示
两者通过 WebSocket 共享实时状态

B.2 实时 vs 轮询

方案	延迟	复杂度	推荐阶段
HTTP 轮询 (5s)	5s	低	M2
SSE (Server-Sent Events)	<1s	中	M3
WebSocket	<100ms	高	M3+

推荐：M2 用轮询，M3 升级 WebSocket。 延续 v1.0 方案。

B.3 避免的陷阱

不要做第二个 Grafana：Dashboard 是协作界面，不是监控面板
不要做第二个 Slack：Dashboard 上的对话应该围绕任务，不是闲聊
不要过度动画：开工仪式被砍掉是对的——用户打开 Dashboard 是看状态，不是看动画
不要展示所有日志：L3 才展示详细过程，L1/L2 只展示摘要
不要固定刷新频率：有事才推，没事不刷新

25 KiB Raw Blame History Unescape Escape

调研报告：AI Native 人机交互 + Dashboard 设计

课题 7：AI Native 人机交互

1. 已有经验（知识库/wiki）

1.1 Edict（三省六部）的交互模式

1.2 OpenClaw Control Center 的交互模式

1.3 v1.0 Dashboard 设计文档（已有）

2. 业界交互范式对比表

3. AI 视角：我想和用户怎么交互

3.1 我想要的交互层次

3.2 交互范式的六种分类

4. 推荐方案（结合 AI Native 目标）

4.1 核心理念："AI 主动，用户轻触"

4.2 moziplus 的四种交互模式

4.3 AI 主动推送的边界

4.4 多 Agent 协作过程可视化

4.5 交互创新点

课题 9：AI Native Dashboard 设计

1. 已有经验（v1.0 + Edict + Control Center）

1.1 已有设计总结

1.2 Edict Dashboard 技术细节

1.3 Hermes Kanban 的设计细节

2. 业界 Dashboard 对比表

3. AI 视角：我想在 Dashboard 上展示什么

3.1 我想展示的信息（按优先级排序）

3.2 我最不想让 Dashboard 变成的样子

4. 信息层次设计

4.1 三层信息架构

4.2 Dashboard 上的"对话"元素

5. 推荐方案（结合 AI Native 目标）

5.1 Dashboard 页面设计（基于 v1.0 + Edict 增强）

5.2 新增 AI Native 组件

5.3 技术方案

5.4 交互流程示例

附录 A：各项目交互模式详细分析

A.1 Claude Code 交互模式深度分析

A.2 ChatGPT Canvas 交互模式分析

A.3 Cursor 交互模式分析

A.4 Devin 交互模式分析

A.5 Hermes Kanban 交互模式分析

附录 B：关键决策建议

B.1 Dashboard vs Chat 的关系

B.2 实时 vs 轮询

B.3 避免的陷阱

25 KiB

Raw Blame History