✦
nickmu.com/cuneflow
⌘K

Cuneflow - 极简采集，全流转上下文

把 Cuneflow 从 AI 硬件与会议记录工具，理解为一个简单易用但可结构化接入 AI 工作流的会议上下文入口。

7 分钟阅读·2026年4月
演示

1. 核心判断

Cuneflow 不应该被定义成“带 AI Copilot 的电子笔记本”，而应该被定义成：

一个对普通用户来说像纸一样简单、可靠、低干扰的会议记录工具；同时，对 AI-native 用户来说，它是可结构化接入工作流的真实世界上下文入口。

这个判断的重点不是“多加 AI 功能”，而是重新理解硬件、Transfer、AI 和后续工作流之间的关系。

默认用户看到的是一张有魔法的纸；高级用户拿到的是一个可以进入 API、CLI、MCP 和知识系统的上下文入口。

2. 强调全程工作流与最终产出

如果 AI 只是会议后的 Copilot，它会很容易变成一个附属功能，无法形成体验闭环。

真正的 AI-native 应该关注全程工作流与最终产出（Artifact），让产品围绕结构化上下文运转：

  • 硬件低摩擦采集会议上下文
  • Transfer 组织、同步与管理数据
  • AI 将零散会议转化为结构化最终产出
  • 将 Artifact 顺畅接入用户的后续工作流

3. “有魔法的纸”原则

面向普通用户，Cuneflow 首先应该是一张有魔法的纸。

它的体验应该是：

  • 拿起来就能写，会议中不打扰
  • 录音和同步稳定可靠
  • 会后自动生成结构化产物
  • 支持一键导出至现有工具

4. 用户光谱

4.1 默认用户：资深商务与专业人士

这类用户重视稳定性和隐私，不希望被复杂软件打扰。他们不需要看到复杂的 Prompt 配置或 Token 消耗，而是需要明确：

  • 设备是否连接与同步
  • 录音和转写状态是否正常
  • AI 产出结果是否清晰
  • 导出与分享选项是否便捷

默认路径必须极简，AI 能力通过最终结果来体现。

4.2 高级用户：AI-native 工作者

另一端是开发者、研究员和 PM。他们关心的是：

  • 会议能否变成结构化 Markdown 或 JSON
  • Action Item 是否有明确的上下文和责任人
  • 关键节点能否被其他系统引用
  • 能否通过接口接入自动化工作流

高级能力应当存在，但不应污染默认的极简路径。

5. 产品分层

5.1 硬件端

硬件端职责应保持克制：

  • 书写与标记
  • 稳定录音
  • 显示基础状态
  • 保持极低干扰

5.2 Transfer / Web 端

已有基础能力，主要作为“会议上下文进入工作流”的控制层，承载同步、管理及基础导出等功能。

5.3 Cloud AI / Workflow 层

这是连接未来的核心层，重点在于将会议转化为可流转的结构化产物。同时，Web 与 AI 的结合不仅限于当前硬件，未来可以作为中枢连接并处理其他设备的上下文数据。云端 AI 负责：

  • 提取结构化内容（行动项、决策等）
  • 关联可追溯的证据来源
  • 生成模板化 Artifact
  • 支撑跨设备协同与自动化工作流

6. 全程工作流定义

AI-native 工作流应围绕结构化上下文设计，明确边界与顺序：

  1. 采集与组织：硬件端记录，云端结构化多模态数据。
  2. 产物生成：AI 输出可编辑、可追溯的最终产物。
  3. 确认与导出：用户审核后，输出至现有工作流系统。
  4. 机器可读：保留上下文结构，供未来 AI Agent 读取。

7. 关键功能落脚点

7.1 以 Artifact 为核心产出

会议纪要只是中间态，系统应直接生成可执行的产物，例如：

  • Action Items 与核心决策
  • Project Updates 与跟进问题
  • 结构化的 Markdown 或 JSON 数据

7.2 可追溯的 AI

AI 输出必须能快速回溯至原始上下文，以建立信任：

  • 语音片段与精准时间戳
  • 发言人标识
  • 对应的手写标注区域

7.3 隐形的工作流引擎

系统设置应作为工作流引擎，主要定义：

  • 数据的处理方式与隐私边界
  • AI 的默认生成目标
  • 产出的默认流转与导出路径

8. 竞争视角

很多公司都在抢夺“上下文入口”：

  • 眼镜与耳机
  • 智能摄像头
  • 桌面与浏览器 Agent

Cuneflow 的切入点非常务实：

  • 会议场景具有天然的记录需求
  • 墨水屏带来极低干扰的书写体验
  • 会议语料具有极高的商业价值
  • Web 端足以承载复杂的工作流分发

9. Roadmap：从 Magic Paper 到 Context Engine

Stage 0：当前锚点

目标：让一场会议可靠地从硬件采集进入 Web 端。

  • 设备状态与同步可见
  • 转写状态清晰
  • 基础的会议列表与详情页

Stage 1：Magic Paper

目标：无需学习 AI 即可感受产品价值。

  • 稳定的录音与极简设置
  • 自动生成结构化的 Brief 与决策
  • 支持 Markdown 或 PDF 一键导出
  • 结果允许用户自由编辑

Stage 2：Structured Meeting Artifact

目标：每场会议都成为高可信度的结构化产物。

  • AI 产出与原始语音片段强制绑定
  • 支持手写标记与结论的联动
  • 提供场景化的会议模板
  • 支持系统级 JSON 数据导出

Stage 3：Workflow Integrations

目标：高级用户可将上下文无缝接入自有系统。

  • 提供开放 API 与 Webhook
  • 支持任务系统对接
  • 提供机器可读的上下文包
  • 支撑自动化触发流

Stage 4 & 5：MCP 与多端生态

目标：成为 AI Workspace 的核心上下文来源。

  • 开放 MCP Server 供 Agent 检索
  • 支持基于权限的上下文检索
  • 跨会议记录与项目级上下文关联
  • 接入并处理多设备的外部上下文数据

10. 产品边界

默认产品必须保持简单，复杂能力应在极简表面之下生长。 硬件端保持低干扰，Web 端承载流转控制，云端负责结构化与智能处理，深层能力（API、Agent 接入）仅向高级用户逐步开放。

11. 核心产品原则

  1. 默认用户体验必须像纸一样简单可靠。
  2. AI 能力通过最终产出体现，而非复杂的配置项。
  3. 复杂度交由云端和 Web 端，硬件保持绝对克制。
  4. 确保所有 AI 输出可编辑、可追溯、可流转。