workflow-visualizer

工作流可视化工具

生成一张交互式 HTML 图表，展示用户的工作实际如何流转——涵盖工具、自动化、AI Agent、定时任务，以及其中的人为步骤。目标是让用户每月打开一次，了解系统的整体形态，并决定要添加、移除或简化哪些部分。

这属于元技能范畴。只有在确实有内容可供可视化时，效果才最好——例如一个包含多个技能的文件夹、一组定时任务、一套有文档记录的工作流，或一组已知的工具栈。

开始之前

确定要可视化的内容。可以考虑：

• 用户的完整 Cowork 设置 — 技能、定时任务、连接器、Agent、内容文件夹
• 特定业务工作流 — 例如，“从获取潜在客户到收款”
• 内容管道 — 例如，“从创意到上传 YouTube，再到内容再利用”
• 团队的工具栈 — 哪些应用相互连接、谁使用什么

询问：“我们要梳理什么？”如果用户只说“我的工作流”却没有说明范围，则默认梳理：当前 Cowork 文件夹、扫描 ~/Coding/skills/，以及定时任务。

收集输入

扫描相关文件夹。若要可视化整个 Cowork，则包括：

• 所有已安装的技能（以及它们的触发条件）
• 定时任务（以及运行时间）
• 连接器列表（Gmail、Calendar、Slack 等）
• 最近的任务／聊天记录（如果可以访问，用于了解用户实际在用什么）
• 文件夹中的任何 BUSINESS_CONTEXT.md、README.md 或系统文档

若要梳理特定工作流，请用户完整描述一次流程——记录各个步骤、所用工具、每个步骤的输入和输出，以及决策点。

图表结构

使用节点与边构成的交互式图表。每个节点代表一个独立对象——技能、应用、人员、定时任务或数据存储。每条边代表一种关系——数据流、触发或依赖关系。

按阶段或领域对节点分组。常见分组包括：

• 触发器（定时任务、手动提示词、收到的邮件等）
• 输入（数据源、连接器、文件夹）
• 处理（技能、Agent、脚本）
• 输出（生成的产物——仪表板、邮件、内容）
• 存储（数据最终存放的位置）

使用清晰的视觉区分：

• 按类型着色 — 触发器一种颜色，技能另一种颜色，数据存储第三种颜色
• 按类别设置形状 — 触发器用圆形，流程用矩形，存储用圆柱体
• 设置边的样式 — 实线表示明确的流转，虚线表示可选流转，箭头表示方向

交互性

图表应支持用户：

• 点击节点 — 打开详情面板，显示：对象是什么、由什么触发、执行什么操作、会生成什么，以及相关文件
• 悬停在边上 — 查看节点之间流转的数据／事件
• 按领域筛选 — 仅显示内容管道、仅显示财务工作流等
• 缩放／平移 — 适用于较大的图表
• 搜索 — 按名称查找节点

可选但很实用：

• 活动叠加层 — 如果有使用数据，可根据节点的实际使用频率调整颜色或大小。找出“6 个月前安装后就再也没用过”的僵尸节点。
• 切换计划中与已上线 — 如果用户有计划添加的设想节点，可让用户切换其可见性。

技术实现

生成一个独立的 .html 文件，并保存为 workflow-map-YYYY-MM-DD.html。

使用力导向图表库（简单场景可用 Mermaid，交互性更强的场景可用 Cytoscape.js / vis-network）。将数据嵌入为 JS 对象。不要使用查看时需要网络连接的外部依赖。

布局建议：

• 支持手动布局——自动布局很快就会变得杂乱
• 将布局位置保存回文件，确保每次重新打开时布局一致
• 确保图表在笔记本电脑屏幕上易于浏览；复杂的图表需要支持平移／缩放

配套摘要

除 HTML 外，还要生成一份 workflow-summary.md，用文字说明图表：

# Workflow map — [date]

## What this is
One paragraph: what this diagram represents.

## The shape
3-5 paragraphs walking through the system from triggers to outputs. Not a list — a narrative. "Every morning at 7am, the morning-briefing skill fires, which pulls from Gmail and Calendar connectors, and writes both to chat (for me) and to Slack. By 9am I've usually responded to a few flagged emails, which feeds into..."

## What's working
The pieces of the system that are humming.

## What's stale
Nodes that exist but aren't used. Candidates for removal.

## What's missing
Gaps you noticed — workflows the user has alluded to but no clear node handles, or obvious next-step automations.

## Suggestions
Specific moves: add this scheduled task, retire this skill, reorganize this folder.

用户实际会阅读的是摘要。图表则能让用户产生阅读摘要的兴趣。

规则

1. 不要把想象中的内容可视化。 绘制实际存在的内容，而不是计划中的内容。可以在单独的“计划中”叠加层中添加明确标注的设想节点，但默认情况下不要把它们混在一起。
2. 少即是多。 有 60 个节点的图表难以阅读。如果系统确实很复杂，就拆分成 3-4 张子图，并在它们之间建立链接。
3. 命名很重要。 使用用户为事物取的实际名称。如果他们的技能叫 morning-briefing，那它就是节点标签，而不是“AI 驱动的每日摘要生成器”。
4. 揭露僵尸。 工作流图最有价值的见解通常是：“你 4 个月前做了这个东西，此后就再也没用过。”别顾及情面——把它们标出来。
5. 重新生成，不要修补。 用户添加新技能或任务时，重新生成整张图。试图增量维护图表是一场注定失败的战斗。