Tana Outliner 教程：从会议记录到任务与知识库

这套教程把一场真实会议变成可追踪的决策、人物、项目、任务和来源，而不是只生成一份漂亮摘要。最终目标是：每个行动项都有负责人和日期，每个决定能回到会议，每个项目可以实时看到未完成任务，每周复盘时不用重新搜索聊天记录。

请先确认使用的是 Tana Outliner，网址为 outliner.tana.inc。2026 年官方已经把原来的 Tana 知识管理产品改名；tana.inc 的新 Tana 是独立 AI 会议平台。本文所有 Supertags、节点和 Search Nodes 步骤都针对 Tana Outliner。

开始前准备

选择一场 30 至 45 分钟、参与者不超过五人、目标明确的项目会议。首次不要使用包含医疗、法律、人事、未公开财务或高度机密客户资料的会议。先确认所有参与者同意录音和转录，并检查所在地法律和组织政策。

准备以下信息：

• 一个真实项目名称；
• 参与者姓名和角色；
• 会议日期与目标；
• 两到三个预期议题；
• 已知的截止日期；
• 一份需要引用的资料或网页；
• 20 分钟会后复核时间。

不要从导入多年旧笔记开始。先让一个小型工作流稳定运行两周，再决定是否迁移历史数据。

第一步：只建立五种 Supertags

创建五个最小对象：Person、Project、Meeting、Task 和 Source。名称可以中文化，但团队必须统一。每个 Supertag 只保留完成工作所必需的字段。

Person

建议字段：

• Role：角色或职位；
• Company：公司或团队；
• Related projects：关联项目；
• Last interaction：最近互动日期。

不要把敏感评价、健康信息或未经证实的个人判断写入人物字段。人物节点是工作上下文，不是员工画像系统。

Project

建议字段：

• Status：Planned、Active、Blocked、Done；
• Owner：项目负责人；
• Due date：目标日期；
• Meetings：相关会议；
• Open tasks：通过查询或关系展示未完成任务。

Meeting

建议字段：

• Date；
• Project；
• Participants；
• Recording consent；
• Decisions reviewed：是否完成人工复核。

Task

建议字段：

• Owner；
• Due date；
• Status；
• Project；
• Source meeting；
• Evidence or context。

Source

建议字段：

• URL 或文件位置；
• Publisher；
• Published date；
• Accessed date；
• Related project；
• Reliability note。

如果一个字段两周内从未用于筛选、回查或决策，就考虑删除。字段不是越多越专业，长期没人维护的字段只会制造错误上下文。

第二步：建立会议模板

在 Meeting Supertag 中加入固定模板，按以下顺序组织：

• Objective：本次会议要解决什么；
• Agenda：议题；
• Notes：原始笔记或转录；
• Decisions：确认后的决定；
• Action items：确认后的任务；
• Open questions：尚未解决的问题；
• Sources：引用资料；
• Review log：谁在什么时间复核。

模板中保留“原始记录”和“确认结果”的分隔。不要让 AI 摘要覆盖原始转录；后续出现争议时，团队需要回到最初证据。

第三步：录制或导入会议

根据账户能力使用会议代理、实时语音转录、移动语音备忘录，或手动粘贴已有记录。Tana Outliner 的 AI credits 会按模型和功能消耗，Plus、Pro 与免费账户的额度不同；官方页面可能调整计划和用量，不要在第一次测试中连续重复运行长转录。

录制前：

1. 明确说明正在使用转录工具；
2. 记录参与者同意；
3. 关闭不必要的屏幕、日历或第三方连接器；
4. 避免朗读密码、身份证件、支付信息和访问令牌；
5. 确认结束后谁负责复核与删除。

会议中只做轻量标记，例如 DECISION、ACTION、QUESTION。不要边听边设计复杂标签，捕捉完整上下文更重要。

第四步：先复核转录，再运行 AI

转录完成后先人工完成第一轮清理：

• 修正人名、公司名、产品名和缩写；
• 检查“不做”“取消”“尚未同意”等否定句；
• 复核金额、百分比、日期和时区；
• 删除与项目无关的敏感闲聊；
• 标出听不清的段落，不要让 AI 猜测；
• 确认每个行动项的原始语境。

只有完成这些步骤后，才让 AI 提取结构。可以使用类似提示：

从当前会议记录中提取候选 Decisions、Tasks、Open Questions 和 Sources。不要创建最终节点。对每项保留原句证据；如果负责人、日期或结论不确定，明确标记“待确认”，不要推断。

先生成候选列表，而不是直接写入图谱。这样可以在 AI 误判时阻止垃圾对象扩散。

第五步：把确认结果变成结构化节点

逐项审阅候选结果。

对每个决定：

• 用清晰陈述写出决定；
• 关联 Meeting 和 Project；
• 保留原始证据或时间位置；
• 记录确认人；
• 如果决定后来被替代，不要删除，标记状态并关联新决定。

对每个任务：

• 添加 #Task；
• Owner 必须是明确的 Person；
• Due date 必须使用绝对日期；
• 关联 Project 和 Source meeting；
• 在 Evidence or context 中保留必要背景；
• 不确定负责人或日期的任务标为待确认，不要自动补全。

对新人物和项目先搜索现有节点，避免创建 “张三”“Zhang San”“张三-客户” 三个重复对象。出现同名时，用公司或角色区分，不要修改姓名制造歧义。

第六步：建立三个 Search Nodes

Search Nodes 是这套工作流能持续运转的关键，因为它们会随源节点更新。

My open tasks

条件建议：

• Supertag 是 Task；
• Owner 是当前用户；
• Status 不是 Done；
• Due date 按升序排序。

将过期任务单独分组，避免它们埋在长期清单中。

Project follow-ups

条件建议：

• Supertag 是 Task；
• Project 等于当前项目；
• Status 不是 Done。

显示 Owner、Due date、Source meeting 和 Status。会议结束后立即打开这个视图，检查是否有任务缺少负责人或日期。

Unreviewed meetings

条件建议：

• Supertag 是 Meeting；
• Decisions reviewed 不是 Yes；
• Date 在最近 14 天。

它能防止录音和摘要被创建后无人复核。知识库中最危险的不是没有 AI，而是充满看似正式但未确认的 AI 输出。

第七步：建立项目仪表板

在 Project 模板中引用以下内容：

• 最新三次 Meeting；
• 当前 Open tasks；
• 最近 Decisions；
• Open questions；
• Related Sources；
• Last reviewed date。

仪表板应尽量由 Search Nodes 和引用生成，不要手工复制任务。复制会产生两个不同状态，最终没人知道哪个是真的。

每个项目指定一名结构负责人，负责合并重复人物、清理失效字段和检查查询。小团队可以每周轮换，但不能默认“大家都会维护”。

第八步：每周 20 分钟维护

每周固定复核：

1. 处理 Unreviewed meetings；
2. 给缺少负责人或日期的任务补充信息；
3. 关闭或重新安排过期任务；
4. 合并重复 Person、Project 和 Source；
5. 检查新增 Supertag 是否真的必要；
6. 更新项目 Last reviewed date；
7. 抽查 AI 摘要是否能回到原始证据；
8. 记录本周 AI credits 与失败重试。

如果同一类错误连续出现，例如 AI 总把讨论提议当成最终决定，应修改提示和复核清单，而不是继续人工修补所有结果。

控制 AI credits 的方法

• 先清理转录，再运行一次结构提取；
• 只把当前 Meeting 节点作为上下文，不要默认包含整个工作区；
• 将“摘要”“任务”“来源”分成必要的少数步骤；
• 对长会议先切分有边界的议题；
• 记录每次命令消耗和是否产生可用结果；
• 在确认模板稳定前，不要批量处理历史会议。

Tana Outliner 当前帮助页显示 Plus 约 8 美元/月、Pro 约 14 美元/月，并分别提供不同 monthly credits；价格、额度、试用和年付折扣会变化，以账户结算页为准。

隐私与合规检查

Tana Outliner 的官方说明表示不出售数据、未经许可不读私人笔记、数据存储在 Google Cloud并采用静态和传输加密，也表示 AI 供应商受合同约束不得用内容训练模型。但 AI、转录、日历、Readwise、MCP 等功能可能涉及不同子处理者。企业使用前应要求最新隐私政策、DPA、子处理者、数据保留与删除说明，并确认明确适用于 Tana Outliner。

不要引用新的 Tana 所完成的 SOC 2 Type 2 作为 Tana Outliner 认证；官方已明确报告范围不包含 Outliner。受监管数据、员工会议和客户录音应由法务或安全团队批准。

导出和恢复测试

完成第一个项目后，不要只点击“导出成功”。实际检查：

• 会议原文是否完整；
• Person、Project、Task、Source 字段是否可读；
• 引用关系是否以可理解方式保留；
• 附件是否能单独下载；
• 日期和时区是否正确；
• Search Nodes 和命令丢失后，是否还能重建关键视图。

Tana Intermediate Format、复制粘贴和其他导出方式各有边界。复杂 Supertag、查询和命令迁移到别的工具通常不能一比一保留，所以要保留字段说明和最小数据字典。

常见失败模式

一开始建立二十种 Supertags

结果是字段重叠、同义对象和无人理解的模板。回到五种最小对象，只有出现真实查询需求时才扩展。

AI 直接创建所有任务

结果是错误负责人、模糊日期和重复节点。改为“AI 生成候选—人工确认—再创建”。

摘要覆盖原始转录

出现争议时无法核查。原始记录只追加或归档，不被摘要替换。

每个项目复制一份任务

任务状态彼此冲突。保留一个 Task 节点，通过引用和 Search Nodes 在多个位置展示。

把产品拆分后的资料混在一起

新 Tana 和 Tana Outliner 的官网、套餐与合规范围不同。所有采购和安全引用必须标注适用产品与访问日期。

完成标准

当你可以从一个 Project 节点看到最近会议、已确认决定、未完成任务、负责人、日期和来源，并能从每个任务回到原始会议证据时，这套工作流才算完成。漂亮的图谱不是目标；可追溯、可执行、能复核和能导出的知识才是目标。