如何用 AI 在会议中活下来（甚至享受它）｜Granola 联合创始人 Sam Stephenson

Sam Stephenson 把 Granola 希望带来的感受概括为平静。他设计时想到的场景，是连续会议之间的缝隙：用户迟到了，正在调整窗口，还得想起马上要见谁。

这个场景解释了克制的界面，以及让逐字稿退到一旁的选择。他也承认代价：有些用户根本找不到逐字稿。“扶手”的比喻说明了这种权衡，产品应该支持正在工作的人，而不是成为最抢注意力的主角。关于降低血压的说法，是体验比喻，不是经过测量的健康效果。

Stephenson 说，准备不足、即将见到陌生人时，会前简报特别有用。目标是在需要的瞬间提供少量相关背景，而不是堆出一份无所不包的人物档案。

会后则可以用配方提示追问：漏掉了什么，哪一个问题本可以深入，销售交流还能怎样改善。结构化会议也可以用量表或模板整理记录。这些是嘉宾描述的反思辅助，不意味着 AI 的看法应该决定招聘结果，也不能把个人使用比例当成自动笔记的通用准确率。

持续使用会积累细致的项目背景：谁参与，决定了什么，讨论如何演进。Stephenson 展示了如何利用这些背景开始写内部演示提纲、岗位描述或功能公告，而不是从空白页起步。

重要机制是复用对话的实质内容，有时通过保存的配方提示实现。但草稿仍需要检查含义与受众。访谈并没有证明，只要取用了会议历史，生成公告就自动完整、已经批准，或适合公开发布。

主持人问，管理者能否评估其他团队成员在会议中的表现。Stephenson 回答，Granola 不能随意查看下属的私密会议。他把这种情况与成员主动放进共享团队文件夹的记录作了区分。

因此，跨销售通话或设计讨论查找信息时，有用的语料应是共享到相应空间的材料，而不是公司中的每一次谈话。这是创始人对录制时产品边界的描述，访谈不是独立安全审计，也不构成查看私人用户数据的许可。

讨论区分了两件事：Stephenson 说仍在原型探索中的原生定时自动化，以及用户已经通过 API 或 MCP 组合的自定义报告。主持人举例，将 Granola 信息与其他来源结合，定期生成邮件摘要。

Stephenson 说，企业客户让团队意识到，产品必须能与内部工具协作，即使自己的界面不是最后落点。这是一项工作流判断，不能被写成所有连接器或定时功能都已成为成熟原生功能。背景更多、简报更多，也可能意味着噪声更多。

让个人智能体先替双方开会，是对话中的功能愿望，不是已经展示的产品。更眼前的问题，是一天几场会议之后不断堆积的待办事项。

Stephenson 把这个问题重新连到平静：助手应当帮助人处理工作，而不是只列出更多义务。嘉宾也描述了在多个编码智能体线程之间切换的疲惫。他们对建设产品的热情，同时保留了工作之外的生活与思考空间。

Stephenson 把设计 token、组件和智能体可读的说明，视为让更多同事产出一致功能的基础设施。普通设置页面可以复用已有模式，不必每次重新发明产品的视觉语言。

但他没有把这些基础当成困难设计判断的替代品。核心交互体验仍需要探索。广泛参与内部建设的叙述，也不意味着每位贡献者都可以绕过发布检查。需要区分的是减少重复实现，与取消构成有意义体验所需的判断。

团队在白板、Figma 和代码之间来回移动。Stephenson 说，主要由文案与线性页面组成的订阅流程，可能更适合在画布里检查；而嵌入会议过程的简报，则需要在真实位置进行交互试验。

展示的变化把同一份简报放进通知、笔记附近或悬浮指示器旁。这些是探索，并非所有形式都已最终发布。他还认为，有意义的判断需要与自己相关的背景：迟到和紧张时，简报是否有帮助，既取决于位置，也取决于内容本身。

23:55查看原图

Stephenson 描述，团队会尽早把难看但端到端可用的版本放进应用，让同事反复感受到不足，也更有动力改进。公开发布的质量标准，仍不同于第一个内部版本。

内部助手形成了另一种循环：结合日志、代码、分析数据和对话背景调查问题，再可能创建编码任务或代码变更。演示不能证明 SQL 永远正确，也不能证明生产发布自动安全。共同贡献让工具更有用，却不会取消检查结论的需要。

访谈最后区分了“发布了某个东西”和“让它每天真正有用”。早期内部版本、朋友和测试用户提供反馈，细节仍会在更大范围发布之前继续打磨。

Stephenson 认为，建设变容易之后，决定做什么，以及把细节坚持做下去，反而更重要。从持续执行中抽身，也能帮助形成判断。平静的产品和更有余地的工作文化，最终指向同一个检验：这个系统是否真的让人的一天变得更好？