The SaaS Apocalypse Is a Goldmine With Figma’s Matt Colyer

如果你愿意这么说，这要么是 SaaS 的末日，要么是软件的下一个时代。我对此真的非常兴奋，而且我觉得 Figma 和很多其他 SaaS 企业也是如此。因为，像，我在 developer tools 领域工作很久了，而大概五年、十年前，对全球开发者数量的估计大概是 25,000,000、30,000,000、40,000,000，差不多就是这个量级。我觉得这个时代最令人兴奋的地方在于，我认为这个数字会达到 10 亿，甚至可能更多。我认为我们正经历一个极其非凡的产品开发时期，以及真正意义上的技术民主化。

我认为最终结果是，这个世界上的软件会大幅增加。如果你身处这个领域，那就意味着这里是一座金矿。对吧？

Every 是你保持在 AI 前沿所需的唯一订阅。如果你在乎紧跟最新的 models，并使用最新的 tools，那你就必须订阅它，才能把真正有价值的信号从噪音中区分出来。今天就前往 every. 订阅。Matt，欢迎来到节目。

谢谢邀请我，Dan。

对于那些还不认识你的人，你是 Figma 负责 developers 的 product management 总监。我想先从一个我觉得大家都在想的大问题开始。我可能应该先说一下，我大概两个月前买了不少 Figma，差不多就是那个时候，因为当时有一整套所谓 SaaS pocalypse 的叙事。我想和你深入聊的——我觉得你有很多内容可以分享，包括 AI、AI 与 product management，以及你自己一直在做的各种事情——但我也很想先从这个问题开始：在 AI 时代，SaaS tools 会发生什么？

而我觉得 Figma 是一个非常有意思的例子，总会有人说，哦，我再也不用 Figma 了。比如，你们刚刚在产品里发布了一个 agent，而且你们还有 Figma MCP。所以，如果你是从 Figma 刚开始时那个还没有 AI 的世界，过渡到现在这个已经大规模扩展、而且有了 AI 的产品阶段，那这到底是怎么运作的？以及你们是怎么思考这个问题的：我们是否要向 agents 开放产品？

我们要自己做 agent 吗？什么有效？什么无效？诸如此类的这些问题，我都非常感兴趣。

对，我很愿意今天聊这个。我觉得对我来说，这件事来自几个不同的角度。我想第一点就是，所谓 SaaS 的末日，或者说，如果你愿意这么表述的话，软件的下一个时代——也许这是一个更积极的说法。我对此真的很兴奋，因为，像，我在 developer tools 领域工作很久了。

而且，怎么说呢，也许在五年、十年前，大家估计全球开发者的人数大概是——我也不确定——2500 万、3000 万、4000 万，上下浮动。我觉得当下最令人兴奋的是，我认为这个数字会到 10 亿，对吧，甚至可能还不止。于是我觉得，我们正经历一个非常惊人的产品开发时代，以及真正意义上的技术民主化。现在外面有很多流行说法，比如 homegrown software（自建软件）之类的，我们之后也可以聊这些。但我觉得最终结果就是，世界上的软件会显著变得更多。

所以回到你刚才提到的那个点，比如所谓的 SaaS pocalypse，以及这对那些已经有成熟产品的公司意味着什么——如果你就在这个领域里，那它其实意味着一座金矿。对吧？意味着外面有大量机会，而我对此真的很兴奋。我觉得 Figma 以及很多其他 SaaS 企业也是这样想的。所以我觉得另一部分——也就是你在网上看到那些更偏负面的讨论——是在说：如果我可以用 vibe code（氛围式编程）去做每一个 app，那会怎样？

对吧？我觉得这个时期特别有意思的一点是，不知道为什么，今年 1 月好像就是那个转折点——这件事突然成了更大的主流叙事。我自己做这类事情大概已经有 18 个月到两年了。所以我之前其实就已经是那种“对，去把所有东西都做出来吧”的状态，但我感觉好像全世界都是到今年 1 月才跟上来的。我当时就是，“对，去把所有东西都做出来吧”，而且人们现在确实正在这么做。

而我很期待接下来会发生什么，因为以我自己的经历来看，做出它的初始版本真的很有趣。对吧？其实两年前我就做过一个自己的 agent（智能代理），第一个是一个 email agent（邮件代理）。我后来回头看它最初是怎么开始的，发现它真的就是一个很糟糕的 Python script（脚本），有点摇摇晃晃的，有时候连回复都发不出去，我当时就觉得，行吧。但更大的叙事其实是：软件公司构建的不只是代码而已。

对吧？我之所以愿意付费给 Gmail 来处理我的邮件，是有原因的。因为事实证明，当你面对“SMTP 版本需要升级”这种事的时候，真的挺烦的。你会想：我才不在乎这个，我只是想收邮件。

所以，当我不得不在自己的个人生活里运行我自己的 agent 时，我就切身体会到了那种痛苦：我想要的产品并不存在，所以我自己造了一个，然后也就顺带接手了它持续运行的成本。而且说实话，我现在买的软件比以前任何时候都多，因为我会想，嗯，这个工具看起来不错。那我干脆付钱让别人替我运行这个 MyAgent 吧。

我完全同意。作为一个也用 vibe code 做过不少工具的人，a，确实有个人维护的问题；但 b，我也曾经用 vibe code 做过工具，后来还把它们重新发布到了 production（生产环境）里。让我告诉你，这绝不是你说一句“修掉这个 bug”那么简单。我确实觉得，这一点在所谓的 “SaaSpocalypse” 讨论里被严重忽略了。不过我得说，如果你最早做的事情之一就是一个 email agent，那我真的特别好奇你现在是怎么处理邮件的，因为我感觉事情刚刚发展到一个阶段：你好像可以某种程度上“在不处理邮件的情况下处理邮件”，我对此特别兴奋。

对。是的，我可以再多讲一点这个故事。所以，两年前这个问题开始的时候，我当时在工作里用的是 chatbots（聊天机器人），因为在那个时间点，那基本上还是主要的 interface（交互界面）。那时候 agent 的使用其实还根本不算一回事。

所以就拿我的个人生活来说吧，我有孩子分别在三所学校上学。如果有家长在听，你们肯定知道收到 PTO 邮件时是什么感觉，还有各种“今天主题是什么？”之类的通知。你也知道那种错过活动的感觉——这大概是世界上最糟糕的家长感受之一——比如你错过了 spirit day，因为你的孩子那天没有弄 crazy hair day，你真的会觉得自己人生都失败了，这我可以很负责任地说，而且我还不止错过过一次。所以我当时就想，我不能再错过下一次了。然后我就想，你知道我其实有什么吗？

我有办法，而且这事是因为我每天得追踪大概 15 封邮件。你会觉得 corporate America 里大家已经够能发邮件了，等你看看学校 PTO 发来的那些邮件吧。所以我就想，你知道吗？这些我根本没法全读完，但谁可以呢？

agent。我当时就想，为什么我不能直接在某个现成的 agent 平台里做这件事呢？然后我意识到，缺的那一块其实就是：我只想把它接到 email 上。所以它最最初的第一个版本，真的就是字面意义上的：抓取一个 email inbox，看最新那封邮件，然后直接把内容粘贴给某个 LLM，再把返回结果原样输出回来。我知道你很喜欢聊 prompt，而我那时候最喜欢的 prompt 基本上就是：转发这封邮件，然后让它“提取事实”。

而且一直让我很震惊的是，我发过去一封好几页的邮件，最后拿回来的结果却只有三条 bullet point。

对，确实。我还记得那些日子。就是把这些东西接起来、复制粘贴，我现在会觉得那已经是很遥远的事了，但其实也就是一两年前。

对。还有，顺着你刚才说的 agent，那之后我又加了一个 memory system。对吧？因为就像你说的，我还没有把它完全自动化，而且我也不确定自己是否信任它能代表我直接回复，但加上 memory system 以后，真的是一个彻底的 unlock。然后它现在演化成的样子是，我有一个 daily 机制，所以，这里面有个挺有意思的点。

我觉得 OpenClaw 好像也抓住了这一点，但我认为真正把事情点燃的，其实是 proactive 这一部分。我的版本是这样的：我会让我的 agent 把所有这些内容整理成摘要，然后每天在固定时间给我发一封邮件。对我来说，真正的 unlock 在于：我不用再去打开某个工具、再主动提问获取内容，它就是自己出现了。当然也不是说它特别聪明，它只是每天在同一个时间做这件事。

但我觉得，agent 的发展方向会是更强的 proactive，然后进一步去思考：我是不是需要主动联系我的 owner，让他们知道现在发生了什么？

所以如果那差不多就是你几年前所在的状态，那么现在呢，你在工作流上有哪些已经会依赖、而且让你挺兴奋的东西？听起来你好像在 OpenCloud 里用了某种 brief 功能，但还有哪几样你最近一直在 tinkering（折腾、试验）并且很喜欢的东西？

我觉得我在工作里正试着搞清楚的一件事，是 summarization（摘要总结）。我觉得这份工作的一部分，就是理解海量的信息，然后再想办法过滤这些信息，并且思考我要怎么把这种能力赋予我的 agents（智能体）——也就是判断什么重要、什么不重要。可这其实是个很难的问题，因为很多你读到的东西，第一轮看时你会觉得“哦，这不重要”，结果三天之后它又变得重要了。所以问题就在于，你要怎么描述哪些东西重要、哪些不重要？

而且这些 agents 也给人一种有点……怎么说呢，我会让它做的一件事是把我所有的会议都过一遍。公司里的所有会议我们都会录到 Notion 里，我可以让 Codex 把所有会议都扫一遍，然后告诉我：“这里是所有你可能会感兴趣的内容。” 这真的很酷，因为这样一来，我就像参加了所有那些我实际上没参加的会议。但问题是，如果它给我的东西不太对，我告诉它“不太对”，它又会矫枉过正，把所有我说过想要的东西全都给我，但给得太多、太字面了。总之，它就是会以一种很奇怪的方式，始终差那么一点点，不会完全对。

对，我就是挺想知道你在这件事上现在做到什么程度了，因为我感觉这还是目前尚未解决的问题之一。感觉我们大家都还在摸索。就像你刚才说的，比如 email，还有你的 inbox（收件箱）——你已经把它完全自动化了吗？它会代表你直接回复吗，还是说每一封回复都要你批准？实际用起来是什么样的？

我每一封回复都得批准。不过基本上，我现在的做法是：在 Codex 里，我有个小 app，我会在 Codex 的 app browser 里打开它，这个 app 是本地运行的。然后它每天都会把我所有的邮件扫一遍，再给我一个列表：页面上会列出每一封邮件，同时附上一份 draft（草稿），意思是“这是我大概准备怎么回复”。而且因为它能访问我的电脑和各种内容，如果邮件是我律师发来的之类的，它还可以自己去搜索相关信息，然后给出“这是我觉得我应该怎么说”的建议。接着我就一路往下滚，然后跟它交流。

我们有个工具叫 monologue。我就是直接对着它 monologue（口述），告诉它：“不，去把这个改掉”，或者“可以，这份 draft 可以发”，或者“不行”，诸如此类。然后我已经连续大概四周都保持 inbox zero（收件箱清零）了，这真的非常夸张——以前从来没发生过。我的 assistant 都在说：“what the fuck is going on here？”我……

我完全承认，我就是 inbox zero 这套信条的信徒之一。所以这么多年我一直都在践行它，而且我确实相信它，不过这玩意儿也确实很费工夫。我对你说的 monologue 那个东西挺好奇的。你是真的直接对它说话，还是你是打字给它？对。

它能理解 video（视频）吗，还是说它只能处理 audio（音频）？

现在还只有音频。

对。这又是一个对大多数人来说算是隐藏技巧的东西。比如说，音频解锁真的很重要。而且，我从中学到的一点是，跟电脑说话其实会有点奇怪。所以，我的一个小技巧是，我其实会经常用 Loom，因为假装自己是在给某个人做 screen sharing（屏幕共享）时，感觉就没那么怪了，这样我就能真的把问题讲清楚。

太好笑了。

比如，在办公室里也是这样吗？

对。就是，我觉得——不过我猜我大多数时候还是在家里这么做，这样别人就不会听到我在自言自语了。但是，即使在办公室里，我也觉得大家不会……他们大概只会以为你是在开 Zoom 之类的。

对。对。对。总会有、以前某个时候总会有这么一道心理障碍。现在在办公室里，我就默认大家不是在跟我说话。

我会假设他们是在跟自己的电脑说话。所以，如果他们是在跟我说话，反而会显得有点奇怪。

我们活在一个什么样的世界啊。真是个神奇的世界。我知道。

但我觉得，它已经变成了这种……有点像社交性的东西，你某种程度上能看出来：他们是在看电脑吗？还是在抬头？或者，还有那种压低声音的小声说话，你知道的，就是他们会稍微凑近自己的电脑，然后说，我想让你……做这个小小的事情。然后，然后，然后你就……

……会说，好吧。

我知道这里是在发生什么了。

但它就是快了大概两倍。我忘了具体是多少了。我也不确定。大概是说话比打字快两倍到三倍。

而且，我还有，你知道，carpal tunnel 之类的问题，所以这样也不会那么刺激我的手。人体工学上要好得多。所以，对，使用语音是个非常非常大的 unlock（突破）。不过我确实还是想回到我们刚才最开始在说的那件事，也就是，好吧。我们就这么说吧，我觉得我们现在的看法是一致的。

SaaS apocalypse 不是一回事。实际上，做出一款始终都能正常运行的 SaaS 软件，是一项极其巨大的投入，只有一部分人想去做，而另一些人就是想为此付费。但接下来我们更明确一点，深入到 Figma 这个语境里。所以，你知道，这里面会有一些问题。放在设计世界里。

我到底是想直接和我的 landing page 聊天，然后那样去移动各种元素，还是说我想待在 infinite canvas 上？而且我知道在我们内部，几乎所有设计师都非常——我是非常早期地问过他们的——他们全都属于 super early adopters（超级早期采用者），他们的态度都是：对，你知道，typing（打字）很适合做第一版，但如果要真正把细节做对，我就需要能够亲手去移动东西。所以在设计领域里，这会怎么改变？你觉得，当你设计某样东西的可能性发生了如此巨大的变化时，这会如何改变产品策略？

对。我的意思是，我觉得这里面有很多东西要拆开来看，而且我觉得，你知道，我们现在还处在 very early innings（非常早期的阶段），还在慢慢摸索。我觉得我们仍然有点处在这种“text box 说了算”的后遗症里。就像，我觉得我们很多人默认都会把 chat 当成 generative UI（生成式 UI）的体验形式。而我感觉我们正在开始进入它的第二章节，也就是：这是否意味着什么？

而且，这也是我为什么会对我们的 agents 发布这么兴奋的一部分原因。我们其实已经在内部用了有一段时间了。对于那些还没见过的人来说，它的能力是在 Infinite Canvas 上直接使用一个 agent。我觉得回过头看很有意思，所谓旧东西又变成新东西了。就像在整个 LLM 和 ML 领域里，很多事情都在发生，比如我们好像把 eval 重新发明了一遍。

所以就像，哦，好吧，我们以前就有 unit tests。又像是，我们把 prompting 重新发明了一遍。我们以前也有 user input，现在又像是，哦，好吧。而在这个新的 AI 时代里，design 依然是那样，那些原则仍然重要。

对吧？所以，对我来说，design 的一个核心原则就是 diamond 模型。这里面有这样一种想法：先 divergent thinking（发散思维），再 convergent thinking（收敛思维）。而大多数 design 问题都是这样；这也是 brainstorm 的理念所在，也是为什么人们会告诉你，千万不要一上来就否定别人的想法。brainstorming 的重点，就是先不断地产生想法。

而我觉得这些新能力里有一件我们还没有完全释放出来的事情，就是把 generative thinking（生成式思考）大幅增强的能力。很多时候，我们会被自己的生活叙事和亲身经验困住，于是总是从某个特定角度去看问题。这也是为什么有 teammates 会这么有价值，对吧？你去和队友聊，他们的出发点可能完全不同，于是这个问题的答案也会变得不一样。

而创造力，往往就来自你们两个人之间的那种对话：哦，我之前没从那个角度想过，这很有意思，让我接过来，再在这个基础上继续往上构建。对吧？所以，再回到这个问题：在这个新的 AI 世界里，这意味着什么？

如果我们能跳出 text boxes，因为我觉得 text boxes 非常受限，它非常像一种线性的方式：先这个，再那个，再这个。如果我们来到 canvas 上，并且你能拥有其中一些类似的概念，同时 agents 又允许你做不同的 generative thinking，那就会变成这样：嘿，我有这个 frame，我们从这里开始。就像，嘿。

我觉得它应该是 grayscale。然后你再有另一个 frame，你会想，哦，让我试试 SIPA。然后又会变成，哦，这个 SIPA 的东西很酷，但是这个 type 不对。然后又会想，哦，让我试试那个。

然后现在又会变成，哦，accessibility 不达标，那我把这个 frame 复制一份再试一次。所以，我觉得——而且即便这样，我仍然认为这还只是 early innings。这在很大程度上仍然是由 human 来驱动输入的，对吧？

而且，像你之前也多少谈到过那种 proactive flow（主动式流程）。对吧？我觉得我们开始在摸索这样一种可能：如果我们有一个 agent（智能代理），它会说，这里是我扔到 canvas（画布）上的一堆 frames（设计帧）。你的任务是去推动它们，尝试不同方向，而不是一味地在同一个方向上加码。但我觉得还有另一类 agent，是这样一种情况：好，现在这个 canvas 上已经有了 25 个关于新 marketing page（营销页面）概念的 frames。

对吧？接下来就是，我该怎么把它们收敛下来？所以这时候会有一个 convergent agent（收敛型 agent），它会说，好，这三个有点像一类，这几个又聚成另一类。而且我觉得，你还可以让它给出自己的意见，比如你可以说，假设你是一个正在点进这个页面的 customer（客户），哪一个最说得通，对吧？所以我觉得我们其实还远远没有把这些能力真正挖掘出来。

所以我觉得，即便是最好的 agents，比如 command line agents（命令行 agent），也还不具备完成这类工作流的能力。所以这大概就是我眼中 design（设计）和 product thinking（产品思维）的未来所在。

我觉得这完全说得通。对，而且就我目前观察到的情况来看，agents 在这样一种场景里确实特别强：我已经有一套 design system（设计系统）了，我现在需要一个新的 landing page（落地页），那你就按照我现有的 design system 给我生成一个 landing page，差不多就是这种事。说实话，很多 designer（设计师）其实并不想把时间花在做第 n 个 landing page，或者这篇帖子对应的第 n 张 graphic（图形）之类的工作上，这些事情更偏 convergent（收敛），而没那么 divergent（发散）。那关于未来，比如 Figma 这类设计工具，或者更广泛地说软件产品，在允许 external agents（外部 agent）接入，与自己内建 agent，或者两者并存——而你们确实也两者都有——这件事上，你觉得它会怎么发展？

我的意思是，我觉得两种我们都会拥抱。对吧？而且我认为，design workflow（设计工作流）和 engineering workflow（工程工作流）虽然不同，但它们之间的边界正在变得模糊。所以我觉得未来，我们都会成为 builders（构建者）。对吧？

而这在某种程度上取决于，你是从什么视角切入这个问题的。所以我们现在当然是非常支持 third party agents（第三方 agent）的。我们对此的答案就是我们的 MCP server。对吧？我觉得 MCP 的一个好处就是，它能在各种不同类型的工具之间提供一种 standardized interface（标准化接口）。

对吧？所以我们大致是从两个方向来看这个问题的。我们会把它看作 code to design（从代码到设计）。比如说，就像你刚才举的那个场景，那其实是个很常见的事情：你会说，嘿，我们有一个 sign up page（注册页面），但它不支持 GDPR。

对吧？大多数人不会说，你知道我该怎么做吗？我要从一个 greenfield page（全新空白页面）开始，重新构想我们的 signup flow（注册流程）应该怎么设计，才能加入 GDPR。大多数人只是想把工作做完。就像你周一早上登录系统时会想，好，我只要把这件事搞定就行。

比如说，在这里帮我加上一个复选框。对那种工作流来说，如果你已经习惯在 Codex、Claude、Windsurf 或 Cursor 里工作，你就打开自己的 code base，启动 MCP server，然后对它说，嘿，你能不能把这个页面复制出来，比如启动 dev server，打开这个页面，再把它复制进 Figma Canvas，它真的会这么做。这是我们今年早些时候发布的功能之一，有点让人震惊：agent 居然能如此忠实地完成这件事，但事实证明它们确实可以。这样一来，你就把那些枯燥重复的活全都去掉了，对吧？

不仅如此，你还把它放进了一个你可以真正与之交互的媒介里。感觉就是，好，现在我可以用大多数人都熟悉的直接操作工具，非常精确地去移动和调整这些东西。我们想到的另一类工作流则是：好，既然我们已经有了 design，就把这个 design 再带回 code，对吧？

所以我们有一个叫 kit design context 的工具，它会读取一个 Figma design，把你使用的各种属性、components，以及你在 design library 里提供的其他各种规范都打包起来，然后提供给 agent。同样，这也有点像魔法。agent 会像这样说：好，很棒，让我先看看你当前的 code base。

我会建一个 branch，创建一个 PR，做出这些修改，然后你还可以对 agent 说，好，帮我截个图并放到 PR 上。接着，你的工作就有点像你刚才提到的、你之前处理 email 的那种工作流：你不会直接 merge，但你会想，好，至少我现在已经有了一个不错的起点。

对吧？然后你就可以进去，在这个基础上继续发挥。

关于什么样的产品内置 agent 体验才算好——也就是内嵌在产品内部的 agent——你学到了哪些在 Figma agent 之前可能并不知道的东西？

我不知道，这确实是个挺有意思的问题。什么才会让它成为一个好产品？我觉得“具体性”很重要。这一点非常贴近 Figma，但 context（上下文）和 personalization（个性化）很重要。像我过去在一些 AI 公司做过的其他产品里，personalization 往往是最后才考虑的事情。通常都是先让它对所有人都能工作起来。

但我觉得，真正把一个“还可以”的 agent 区分成一个用户真正喜爱的 agent 的，是个性化这一点。我们刚才提到过 memory（记忆），在那些第三方聊天 agent 里，它就是一种个性化形式。我觉得对 Figma 来说，对应的东西就是 design system。但如果你有一个 assistant，却没有“这是我们如何组织 design、如何把它们组合起来”的这种概念，那它产出的 design 从这个角度看就是不可用的。

我不太清楚你们对 Figma 的计划是什么，还有，怎么说呢，让它主动一些、成为一个 proactive agent（主动式 agent）这件事。但我很好奇，如果你们确实有这方面的计划和实验，现在进展怎么样？显然，就像我们之前聊过的，这类事情其实挺难做对的。

对。我是说，我觉得未来就是往那个方向走的。比如说，如果你看 agents（智能体）这一路是怎么演化过来的。我可以说的是，我们内部确实有很多项目在推进，只是我不太能谈太多具体细节。

我确实觉得这是一个我们会走在前面的领域。对吧？所以，我想我可以谈谈我们今天看到的问题。就是，如果世界上的软件数量真的在爆炸式增长，那么更大的挑战之一就会变成：好，那你怎么确保这些东西和你的价值观保持一致？对吧？

所以，我觉得接下来我们就会变成那个 bottleneck（瓶颈）。对吧？因为能审查所有这些工作的人工眼睛就只有这么多。所以问题就变成：我们怎么提供一种解决方案，让人们既能继续以这些 agents 生成内容的速度去创新，同时又能守住他们的价值观。

从内部来看，在 Figma 里，你们自己的工作流——无论是 engineering org、product org 还是 design org——从一个 pre-AI 的世界走到现在，这个转变是什么样的？

我是一月加入的，而我会说，即便只是在这段时间里，变化也已经有点像天壤之别了。就像，我觉得一月份的时候，大家还只是在尝试这些新的工作方式，而且是横跨所有职能。对吧？我想大概 engineering 还是走在最前面的，像大多数这类情况里一样，不过我可以给你举一个 product org 的例子。就是，我们之前有一次 off-site。

我觉得你当时可能还真来过。说来也巧，圈子确实很小。我对那次 off-site 最深的一个记忆之一是，我们有一个 product operations 团队，他们整理了一套我们称之为 PMOS 的东西。然后先稍微退一步讲一下背景。

对我来说，AI 带来的一个重要 unlock（突破）是：你会开始意识到，几乎每个问题最终都会变成一个 context（上下文）问题。这样一来，工作的重点就变成了：如何用一组恰当的信息来框定这个问题。所以我们的 product operations 团队就在想，作为 PM，我们做的很多工作本来就是结构化数据，那为什么不把这些都汇总到一起呢？于是就变成：好，先把组织架构图弄一份过来。

我们会把那个丢进一个 SQLite table 里，然后放到 file system 中。接着就像，好吧，为什么不做一个连到 Asana 的 connector 呢？然后我们再接 Slack，再接 GitHub，以及其他一些东西。对吧？

然后真正的洞察是，skills 在那个时候已经真正起飞了。就像，好吧，这里的 magic sauce（关键诀窍）之一，是我特别喜欢的一个 skill：创建 onboarding file。也就是当你给团队加入一位新成员时，作为 manager，你得去创建一份定制化的说明，比如，好，这些 channels 是你应该了解的。

这些人是你应该认识的。它会把很多我以前会说完全只存在于我脑子里的知识提取出来。但随后你开始看到，如果你把 context（上下文）塑造得当，这些数据其实本来就已经在那里了。我已经有 org chart，它可以沿着 org chart 走一遍，弄清楚这个新团队里谁是团队成员，谁是在 product、engineering、design 这一侧构成 trifecta 的关键三方。你只需要先标识出来，比如，这就是那位新成员。

这是他们将要加入的团队。然后它就会做大量研究。接着它会进入 Slack，找出相关 channels。它会像这样判断：哦，这个团队大概率就是这三个 channels，然后它再去读取最近三十天的内容。

然后它会继续，接着去检查 Asana board，把所有 projects 都找出来。所以最后它返回结果时，你会觉得，哦，这好得有点不可思议。就像，是的，这已经是一个相当不错的起点了。