1. 产品介绍
把会议里的结论送到真正做事的地方
本文讨论的 Tana 是面向团队的 AI 会议平台，和同公司的 Tana Outliner 笔记产品分开。它把通话、转写、文档和任务放在一起，并能借助已连接的服务，把讨论整理成待执行动作。
比如一个产品团队在演示时发现移动端登录错误。会后只留下“修复登录”的摘要，工程师还要重新寻找重现过程、确认负责组，再去 Linear 建任务。运营同事可能又在等一条进度消息。会议记录保存了话，但工作还没有进入负责人的工具。
Tana 的价值在于把这段搬运变成可审阅的动作：先整理要创建的问题和要发送的内容，由人确认后执行，并继续展示执行结果。本文聚焦这条“讨论 → 动作草稿 → 确认 → 外部结果”的路径。
2. 核心使用流程
先连接实际要写入的服务
以会中发现移动端登录错误为教学情境。按 Linear 连接指南，在 Settings → Integrations 的个人集成中连接账号，核对授权范围。连接按账号配置，不能因为会议里提到某个工具，就认为系统已能访问它。
会议讨论可以先成为 Tana 内的文档或任务；本文继续看怎样在已连接的服务里创建问题或发送消息。这类操作先形成待接受的动作，会议摘要等内部自动整理则有不同规则。
把讨论变成可以逐项检查的动作草稿
- 说清目标：例如先查是否已有移动端登录问题，没有时再在 Web 组创建，并附上重现步骤。查询与创建是不同动作，不能用一句“登记一下”掩盖目标。
- 打开动作详情：检查服务、团队、描述与要发送的信息；会议动作可以携带转写与截图背景，帮助接手的人回到问题现场。
- 修订内容：动作帮助允许编辑发送指令。服务范围在起草时已确定，在文字里提到另一个服务，不会让这次动作自动获得访问它的权限。
- 接受后执行：确认的是具体对象与内容，而不是泛泛地同意 AI。尚未形成承诺的想法，可以继续留在讨论中。
动作草稿把口头意图变成可审阅材料，让人有机会在外部写入之前发现目标错误或信息缺失。
留在同一张卡片，核对外部结果
接受后继续看动作卡片的运行状态与产物入口，包括执行中、已发送、部分完成、等待用户和失败等。打开创建的实际问题，检查是否写到正确团队、内容是否完整。
如果建单成功而消息失败，外部已经留下了问题，不能按“全部没做”重来。应分别确认已完成与未完成部分，再处理后者。审批决定是否开始，多工具执行却不天然是全有或全无；原卡片同时保留确认过的内容和实际执行结果，团队才能继续处理未完成的工作。
3. 设计亮点与借鉴
把“同意”变成对一份具体内容的确认
一句“帮我登记一下”，可能还没说清目标组、重现条件和负责人。动作草稿让这些空缺在发送前就有机会被发现。用户确认的不只是“允许 AI 做事”，而是眼前这份准备交给同事的内容。
以登录问题为例，补充重现步骤是在完善描述；增加一项尚未授权的服务，则涉及另外的访问范围。这两件事不能因为都写在同一个文本框里，就被当作同一种修改。把内容和允许使用的服务分开，有助于用户知道当前确认究竟能让什么发生。
可以借鉴的是让确认页回答三个具体问题：发到哪里、发什么、还缺什么。对于尚未决定要做的想法，继续保留在讨论中也有价值，不必把每句话都变成任务。
保留批准前后的对应关系，让人继续处理正确的部分
用户刚确认了一项创建任务的操作，接下来关心的是那个任务究竟有没有建成。若跳到一个与原请求无关的结果列表，就需要靠时间和标题重新匹配；原卡片继续显示结果，可以让用户沿着刚才的决定查看进展。
这在一部分成功、一部分失败时尤其重要。已经创建的问题有自己的链接，未发送的消息仍需要处理。把二者都压成“失败”，可能诱导人重复建单；都压成“完成”，又会让剩余工作被遗漏。
值得借鉴的原则是：让用户始终找得到自己确认过的内容，以及每一项操作后来发生了什么。开始执行、执行完成和结果正确，分别需要自己的依据。