AI卡片式工作台

更新时间：2026-06-01

项目状态卡

字段	内容
当前阶段	方向探索
话题发起人	TranFu 团队
当前推进人	TranFu 团队
最近更新时间	2026-06-01
当前判断	这个方向有交互形态想象力，但“通用 AI Notion”过宽，且存在 thin UI 与平台替代风险。更适合收敛到一个高频工作流，例如会议纪要、团队进展、投资资讯或个人信息看板，验证卡片是否真正提升信息处理效率。
下一步	选择一个具体场景做 3-5 张可运行卡片样例，验证用户是否愿意持续使用，而不只是觉得界面新颖。

最新进展

• 2026-06-01：从未建档话题中筛选为新增项目档案。该话题已有 16 条消息、13 条人类消息、3 个资源，状态为 评估中；当前先作为“重构方向 / 内部排序”项目沉淀，不直接进入高优先级验证。

执行摘要

AI 卡片式工作台 / AI Notion 的核心设想是：用“AI 输入框 + 可编程卡片 + AI 生成 HTML 模板 + 定时或 Hook 数据更新”构建通用型信息处理软件。用户可以通过对话创建股票、资讯、会议纪要、团队进展等卡片，卡片的数据来源可以是用户提示词，也可以是 AI 定时执行代码后的结果。

该方向的吸引力在于新的交互范式：AI 不只生成文本，而是生成可视化、可更新、可组合的信息单元。但当前最大问题是范围过大，容易变成“漂亮 UI 层”，被 Notion、飞书、ChatGPT、Claude Artifacts 或浏览器 Agent 吸收。

目标用户

• 高频处理动态信息的个人：投资、资讯、研究、创作者。

• 需要看团队状态和项目进展的小团队。

• 希望把 AI 输出沉淀成可持续更新界面的知识工作者。

核心痛点

• AI 对话输出容易散落，缺少持续更新的结构化界面。

• Notion/飞书等工具可定制，但配置成本高，普通用户难以做动态卡片。

• 团队信息、会议纪要、资讯流等内容需要被压缩成可扫读、可追踪的状态块。

当前证据

• Lark 话题已有 16 条消息、13 条人类消息、3 个资源。

• 话题中已出现卡片、AI 输入框、HTML 模板、定时执行代码、会议纪要文件树、团队进展卡片、股票资讯卡片等产品元素。

• 已有外部参考资源，包括 kepo.ai 与 Lark 白板/文档链接。

评估与判断

MVP / 验证计划

1. 不要先做通用平台，先选择一个场景。

2. 做 3-5 张真实可用卡片，例如“每日投资信息卡”“项目进展卡”“会议纪要索引卡”。

3. 验证用户是否连续 7 天打开、编辑、订阅或分享这些卡片。

4. 验证 AI 生成卡片是否比人工配置 Notion/飞书明显省时间。

风险与反证

• 如果用户只觉得形式新颖，但不会持续打开，说明不是强需求。

• 如果现有 Notion/飞书/ChatGPT 已能完成核心流程，独立产品价值不足。

• 如果卡片生成不稳定，维护成本会高于收益。

数据链接

字段	内容
数据口径	16 条消息 / 13 条人类消息 / 3 条 AI 分析 / 3 个资源。

项目增强分析（2026-06-02）

口径：基于最新项目维护报告、Lark 话题真实数据与可复核公开资料整理；web_search 当前不可用，因此未二次核验的市场判断均按“趋势/假设”保守处理。

一句话机会

做一个“AI 输入框 + 可组合卡片”的个人/团队信息工作台，让用户用自然语言生成、更新和调度信息卡片，把分散的资讯、会议、项目、数据和提醒变成可操作的动态页面。

目标用户

• 小团队负责人、产品经理、投资/研究人员、运营负责人。

• 日常需要处理多来源信息：聊天、会议纪要、网页、任务、市场数据、项目进展。

• 已经使用 Notion、飞书、多维表格、Slack/飞书群、Tana/Heptabase/Obsidian，但信息仍然分散的人。

核心痛点

• Notion/飞书等通用工作台强在结构化，但用户仍需手动建库、维护字段、同步信息。

• 聊天式 AI 强在生成，但结果难以长期沉淀成可复用视图。

• 项目/研究/运营信息不是一篇文档，而是一组不断变化的状态卡片。

• 用户想要“我说一句话，系统自动生成卡片、更新卡片、提醒我下一步”。

当前证据

内部话题数据

• 话题负责人：内部成员。

• 消息/资源：16 / 3。

• 最近内部摘要：项目定位为“AI Native 信息处理软件”，用“卡片 + AI 输入框”创建和展示股票、资讯、会议纪要、团队进展等信息；数据来源既可以是用户提示词，也可以是 AI 定时执行代办。

• 维护报告提示：当前只拿到本地沉淀/日报/评估记录，未拿到完整逐条聊天原文，需要 best-effort。

外部资料与趋势

• Notion AI 官网定位为“Search, generate, analyze, and chat—right inside Notion”，说明 AI 工作台正在从文档生成走向工作空间级搜索、分析和对话。

• ClickUp Brain² 官网定位为“One AI to Replace them All”，强调工作上下文聚合和跨任务 AI。

• 市场趋势是“AI 嵌入现有工作台”与“Agent 执行任务”并行，纯新工作台必须有强差异化：更低建模成本、更强动态卡片、更适合移动端/群聊入口。

竞品 / 替代方案

• 工作空间：Notion AI、Coda AI、Airtable AI、飞书多维表格/飞书妙记/知识库。

• 项目管理 AI：ClickUp Brain、Asana AI、Monday AI。

• 知识管理：Tana、Mem、Reflect、Heptabase、Obsidian + 插件。

• AI 搜索/研究：Perplexity Spaces、Genspark、You.com、Kimi/豆包资料整理。

• 内部替代：直接用飞书 Base + Wiki + 内部助手 bot 做项目雷达。

MVP 切口

推荐切“项目/机会雷达卡片工作台”，先服务现有 内部机会库 场景：

• 用户在群里发一个想法，AI 自动生成项目卡片。

• 卡片包含：一句话机会、状态、评估、证据、下一步、风险、来源链接。

• 卡片可被自然语言更新：“把这个项目改成 内部排序”“补一个竞品”“今天有什么新信号”。

• 先不做完整 Notion，做“动态项目卡片 + 每日更新 + 评估流转”。

验证方式

• 用现有 内部机会库 做 dogfood，替代当前人工维护项目档案的部分流程。

• 指标：创建卡片耗时、项目状态更新准确率、团队查看/引用次数、每周被动维护减少时间。

• 找 3 个外部小团队试用：投资研究、产品工作室、内容团队。

• 观察用户是否愿意把真实项目数据放入卡片，而不是只当 demo 玩具。

风险与反证

• 与 Notion/飞书/ClickUp 正面竞争，独立产品壁垒不足。

• “卡片”是交互形态，不是需求本身；如果没有明确任务流，容易变成视觉包装。

• 数据接入和权限管理复杂，MVP 不能一开始就追求全连接。

• 若用户最终仍回到 Notion/飞书，只把产品当生成器，则应转向插件/工作流，而不是独立工作台。

下一步

• 进入 评估中 的正式评估，但评估对象应是“内部机会库 项目卡片工作台”，不是泛 AI Notion。

• 画 5 张核心卡片模板：项目档案、信号、竞品、实验、日报。

• 用本 workspace 的项目档案维护流程做第一个 MVP 数据源。

参考来源链接

• Notion AI：https://www.notion.com/product/ai

• ClickUp Brain²：https://clickup.com/ai

• Airtable AI：https://www.airtable.com/platform/ai

---

维护边界：本章节为 2026-06-02 增强分析受控块；后续若有新客户验证、竞品变化或 Lark 话题进展，可替换本章节，不覆盖原始档案正文。

项目质量升级（2026-06-03）

口径：本章节用于替换昨日偏模板化的增强稿表达；基于 Lark 话题真实数据、项目 mapping、既有维护报告与公开竞品格局，强调判断、边界、验证和反证。不覆盖原文其它章节。

当前判断

这个项目需要重构叙事。若叫“AI Notion”，会天然进入 Notion、飞书、ClickUp、Airtable 的正面战场，风险很高。更合理的判断是：卡片不是产品本身，卡片必须绑定具体任务流。

当前最好的 MVP 不是泛工作台，而是复用团队内部已有 内部机会库 场景，做 项目/机会雷达卡片工作台：让群聊中的想法自动沉淀成项目卡片，持续更新证据、评估、风险和下一步。

当前状态应保持为：内部排序，重构方向 / 评估中；先评估“项目卡片工作台”，不要评估“泛 AI Notion”。

真实内部话题数据

• 项目名：AI 卡片式工作台 / AI Notion

• Lark thread：[已脱敏]

• 更新策略：medium

• 负责人：内部成员

• 数据来源：snapshot

• 消息 / 资源：16 条消息 / 3 个资源

• 最近话题脉络：用户要求内部助手检查本话题讨论并总结分析；内部助手说明当前只拿到本地沉淀/日报/评估记录，未拿到完整逐条聊天原文，best-effort 总结为“AI Native 信息处理软件”：用卡片 + AI 输入框创建股票、资讯、会议纪要、团队进展等信息；数据来源可来自用户提示词或 AI 定时执行代办。

• 证据等级：L2（有内部连续讨论和概念沉淀，但原始逐条证据不完整，尚未有外部用户/付费验证）

外部竞品 / 替代方案

1. Notion AI：强在文档、数据库、知识库和 AI 搜索/生成；用户心智强，是最大正面竞品。

2. Coda AI / Airtable AI：强在结构化数据、自动化和团队工作流。

3. 飞书多维表格 / Wiki / 妙记：对国内团队是天然替代，尤其已经在飞书内办公的组织。

4. ClickUp Brain / Asana AI / Monday AI：项目管理上下文强，AI 能围绕任务、文档、进展工作。

5. Tana / Mem / Reflect / Heptabase / Obsidian 插件：知识管理和个人信息结构化替代。

6. Perplexity Spaces / Genspark / Kimi / 豆包资料整理：研究、搜索、资料问答替代。

7. 内部替代：当前 内部机会库 已经由 Lark 群 + 内部助手 bot + Wiki + Base + 项目档案维护脚本组合实现。新产品必须证明比这套拼装流程更省维护、更易查看。

MVP 做什么

MVP：内部机会库 项目卡片工作台。

围绕一个具体任务：从群聊机会到项目卡片，再到状态更新和下一步行动。

首版卡片类型只做 5 种：

1. 项目档案卡：一句话机会、状态、负责人、优先级、评估。

2. 信号卡：内部消息、外部资源、用户反馈、竞品变化。

3. 竞品卡：竞品名称、定位、差异点、来源链接。

4. 实验卡：7/14 天验证计划、指标、结果。

5. 日报卡：今日新增、状态变化、阻塞、建议。

交互：用户在群里说“把这个想法建卡”“补一个竞品”“今天有什么新信号”“把它改成 内部排序 待验证”，系统更新卡片并保留来源。

MVP 不做什么

• 不做泛 Notion 替代品。

• 不做完整数据库搭建器。

• 不做全类型卡片市场。

• 不接所有外部数据源；首版只接当前 workspace / Lark 话题 / 本地报告。

• 不做复杂权限体系；先在内部 dogfood。

• 不做移动端精美 UI 优先，先验证卡片是否减少维护成本。

• 不让“卡片视觉”掩盖任务流；每张卡必须能回答“谁下一步做什么”。

7 天验证计划

• Day 1：画出 5 张核心卡片模板：项目档案、信号、竞品、实验、日报。

• Day 2：选 4 个现有项目作为样例：GEO/AEO、AI 招聘工具、交互式知识书、AI 卡片工作台自身。

• Day 3：用本地 Markdown/JSON 生成静态卡片页面或报告，不做完整前端。

• Day 4：让团队用自然语言提出 10 条更新指令，例如“补竞品”“改状态”“生成 7 天计划”。

• Day 5：测试系统是否能正确定位卡片、保留来源、更新字段。

• Day 6：对比当前人工维护项目档案流程，记录建卡和更新耗时。

• Day 7：团队评审：是否比 Wiki 长文更适合日常项目查看。

7 天通过门槛：建一张项目卡耗时减少 ≥ 50%；10 条更新指令中 ≥ 8 条能正确落到对应卡片；团队至少 2 人认为它比当前 Wiki/报告更适合日常跟进。

14 天验证计划

• Week 2 前 3 天：接入每日项目维护 dry-run 输出，把状态、消息/资源数、门禁、最新摘要自动转成卡片。

• Week 2 第 4-5 天：让团队连续 3 天用卡片看项目进展，而不是只看长文报告。

• Week 2 第 6 天：邀请 1-2 个外部小团队看 demo，尤其是投资研究、产品工作室、内容团队。

• Week 2 第 7 天：判断产品形态：独立工作台、飞书插件、还是 内部机会库 内部能力。

14 天通过门槛：内部团队真实引用卡片做决策；项目维护时间明显下降；外部团队能理解“群聊想法 → 动态卡片”的价值，而不是只觉得 UI 好看。

风险反证

• 如果用户说“这就是 Notion/飞书多维表格换皮”，说明差异化不足。

• 如果卡片只能展示信息，不能推动更新和下一步行动，就只是可视化包装。

• 如果自然语言更新经常改错项目或丢失来源，用户会回到人工维护。

• 如果内部 内部机会库 都无法形成高频使用，外部商业化更不应推进。

• 如果真正价值来自内部助手 bot 的分析能力，而不是卡片工作台，应把它做成 bot + Wiki/Base 的增强模块，不做独立产品。

下一步

1. 将评估对象改名为“内部机会库 项目卡片工作台”。

2. 先用本地报告生成 5 类卡片，不做外部写入。

3. 用 4 个现有项目 dogfood，测建卡和更新耗时。

4. 14 天后决定：独立产品、飞书插件、还是内部运营系统能力。

---

维护边界：本章节为 2026-06-03 质量升级受控块；后续新证据出现时可整体替换本章节。

维护说明

• 本档案是项目主页，不复制每日讨论原文。

• 负责人默认取 Lark 话题 root message sender。

• 只在场景收敛、样例推进、用户反馈、竞品资料或评估变化时更新。