Atlassian AI负责人复盘20多款应用加装AI经历与招聘向初级倾斜的转变

Sherif Mansour 已在 Atlassian 工作了 17 年。他负责整个产品组合的 AI，并掌管产品管理这一职能，也就是管理 450 名产品经理（PM）。Atlassian 有 20 多款应用。其中六款诞生于生成式 AI 时代，其余则是多年前的产品。如今有超过 500 万用户为了这些 AI 能力而定期使用这些应用。

他的 SaaStr AI 演讲正是围绕当下每个拥有成熟产品的创始人都面临的问题展开的。关于如何把 AI 融入 B2B 软件，每一个言之凿凿的说法，都有一个同样言之凿凿的反面说法。走无头（headless）路线，因为聊天是你唯一需要的界面。聊天是糟糕的用户体验，所以要构建真正的功能。永远不要把 AI 生硬地嫁接上去，而要从头重建。团队里的每个人都应该成为 AI 构建者。

Atlassian 用真实的团队和真实的用户对所有这些说法进行了大规模测试。以下是他们必须做出的三个决定，以及每个决定的结果。

决定一：Atlassian 差点没把聊天功能放进自己的应用

两年前，把 Rovo 聊天加到 Jira、Confluence 和其他应用里，在内部是有争议的。反方观点：聊天不是终极形态，对很多任务来说它是最糟糕的界面。试试用聊天去填一张表单。正方观点：没人知道用户会用 AI 做什么，所以给他们一个开放的盒子，观察就好。

最终解决问题的办法很平淡。Atlassian 反正都要构建一个聊天后端，来支撑整个产品组合的 AI 功能。既然后端已经存在，他们就把它发布到了全部 20 多款应用中，看看能学到什么。

Sherif 用 DOS 做类比。命令行曾是操作系统的通用界面。你可以在里面做电子表格、文字处理和游戏。随着时间推移，那些常见用例变成了带有真正 UI 的专用应用。命令行从未消失，而且依然覆盖着长尾需求。聊天在 AI 中扮演的正是这个角色：它能处理无限的用例，并告诉你哪些用例值得拥有一个真正的界面。

一个白板提示词如何变成了一个功能、一个工作流和一个 Agent 工具

他以 Confluence 白板为例进行了讲解。通过阅读用户输入的内容，他们总结出了三种模式。

• 提示词变成一个按钮。用户不断要求聊天把他们的便签按主题分组。聊天做不到。Atlassian 把它做成了一个功能：选中卡片，按主题分组。
• 提示词变成一个工作流。头脑风暴之后，用户会写下长长的提示词，要求把便签转成 Jira 的 backlog 条目（或 Trello，或 Linear）。这失败了，因为相关工具还不存在。现在你选中卡片，选择哪些进入 backlog，工单就会被创建出来。
• 提示词仍然是提示词。“把我的客户反馈从 Salesforce 和 Google Drive 里提取出来，把洞察放到我的白板上。”Atlassian 没有为这个构建 UI。它从聊天开始，落到画布上，然后用户可以回到聊天。

有一件事是他们没有预料到的：每一个为人类构建的功能，也必须作为工具暴露给 agent。按主题分组现在已经是 Rovo agent 可以调用的技能。白板转 backlog 也是。客户可以通过 MCP 或 Atlassian 的 CLI，把这些技能暴露给他们运行的其他工具，包括 Claude Code 和 Cursor。无论用户是否在 Atlassian 应用内，Atlassian 的功能都能被使用。

起初的假设是聊天功能是临时性的。先从它身上学习、构建功能，然后再移除它，因为客户已经有 ChatGPT 和 Claude Code 了。这个假设错了。数百万用户每天都在使用 Rovo 聊天。Sherif 给客户打电话时，他们告诉他他们也用 Gemini 和 Claude Code 以及其他各种工具。人们使用离自己工作场景最近的 AI。他为这次演讲准备的幻灯片就是在 Google Slides 里做的，布局用的是 Gemini，理由相同。

他的建议很具体：如果你的产品每天都有用户在使用，就上线聊天功能。Atlassian 利用用户输入的内容来决定构建什么以及何时构建。

决策二：Atlassian 在 2.5 年前把一个智能体步骤直接加到了 Jira 工作流上

标准建议是永远不要把 AI 硬加到现有产品上，而要从零开始重新构思一切。Atlassian 偏做了别人告诉你不要做的事。

先介绍一下 Jira 的背景。Atlassian 的新 PM 入职时都以为 Jira 是给开发者用的。其实大多数 Jira 用户并不是软件工程师。它是一个面向各种团队的工作流引擎。Sherif 举的例子：在打车应用里投诉一段行程，这条投诉会经过一个 Jira 工作流。跟大型电信运营商争议话费账单，也是同样的道理。

于是在 2.5 年前，Atlassian 在现有的 Jira 自动化设计器里新增了一个框：在这一步使用 Rovo 智能体。这确实是往现有工作流上直接加装的组件，之所以发布是因为他们不知道市场会往哪个方向走，想要快速学习。

客户的用法远超预期。他们加了分支和条件，还把多个智能体串联起来。他描述的一种模式：工单进来，一个智能体接手，营销智能体调用 Canva 生成素材，社交智能体读取素材并发布。这些客户在 Jira 里本来就有由人来执行的流程，他们只是把已有的流程自动化了。

Sherif 用厨房打了个比方：他家买了一栋房子，在翻新之前先凑合用着旧厨房。住进去之后他们才知道哪些问题值得解决。他们逐步更换了一些部件，最后才彻底改造。如果你已有用户和工作流，那才是你的资产，你要做的是演进它。从零开始重建只适用于新产品，Atlassian 也这么做，推出了六款 AI 原生应用。

贯穿整个产品线的规则：凡是能和人一起做的事，都能和智能体一起做

大约六个月前，团队从这次加装工作里总结出了一条原则。他们为智能体要解决的每个问题，都是之前已经为人类解决过的问题。人类需要工具、上下文、目标和问责机制，以及了解队友正在做什么的可见性。智能体需要同样的四样东西。而一旦人人都在启动智能体，跨人与智能体的规划也成了一个更大的问题。

规模不同，但基本构件几乎完全一样。于是 Atlassian 把整个产品线逐项过了一遍：

• 你可以 @ 一位真人。现在你也可以 @ 一个智能体。
• 你可以把一个真人加进 Jira 工作流的某一步。智能体也一样。
• 你可以把一张 Jira 工单指派给一个真人。智能体也一样。
• 你可以在 Slack 或 Microsoft Teams 里和真人聊天。Rovo 智能体也在那里。

由此得出的设计评审规则：当一个团队展示智能体做了产品中人类不能或不会做的事时，要追问为什么不同。有时确实有充分的理由。但据 Sherif 说，十有八九，智能体都应该遵循已经为人类建立的模式。

决策三：10 个“AI 构建者”团队快速推进了几周，随后陷入停滞

Sherif 将 AI builder 定义为主要工作就是用 AI 工具交付代码的人。流行的结论是，产品经理、设计和工程会合并为这一个角色。Atlassian 拥有 450 名产品经理和大约 800 名设计师，因此需要弄清这是否属实。

他们启动了约 10 个软件项目，配备经过精心挑选的 AI builder：既有工程师，也有能用 AI 编程的产品经理和设计师，项目横跨新代码库和现有代码库。

最初几周一切顺利，团队推进非常快。然而几周到几个月之后，他们的速度大幅放缓。Sherif 的描述是：“人人都在划桨，却没人在掌舵。”没有人就构建什么做出关键决策，团队只好原地打转。产品经理和设计师自然而然地退回原来的岗位，因为提供客户背景信息和做出决策，才是他们能为团队扫清障碍的最有用之事。

比例说明了问题。Atlassian 的产品团队大约每 10 名工程师配 1 名产品经理和 1 名设计师，平台团队约为 1 比 20。随着工程师借助 AI 的交付量大增，产品经理和设计师表示感觉像是 1 比 30 甚至 1 比 40。工程师更快地回来问接下来做什么、这样做对不对，而整天埋头 vibe coding 的产品经理根本没空回答。

Atlassian 正在增设 AI builder 这一角色，但大多数产品经理或设计师都不会成为它。在小型创业公司里，人人都可以是构建者；在中型或大型组织里，Sherif 认为不行。

招聘管道发生逆转：初级更多，资深更多，中间更少

他总是从高管那里听到同一句话：别招初级员工了，用 AI 招一名资深员工就行。初级员工只会产出垃圾内容，资深员工能干更多的活，而初级员工要一两年才能回本。

Atlassian 却反其道而行。以往的招聘管道是少量初级加大量中级和资深员工，现在则是两端权重加大，中间减少。

理由是：Atlassian 的 R&D 有数千人，他们必须忘掉自己 10 年、20 年、30 年来的工作方式，而忘却比学习更难。应届毕业生却没有什么要忘掉的。Sherif 12 岁的孩子从可视化编程语言直接跳到 vibe coding，正在 Replit 上开发一款 App Store 应用。他完全跳过了语法，并以为编程本来就是这样。

Atlassian 的内部研究也印证了这一点。初级员工使用 AI 的可能性最高高出 38%，进行实验的可能性接近两倍，使用的工具也更多。他们同样会产出大量垃圾内容，而且并不觉得自己效率特别高。资深员工采用得更慢，但更善于识别垃圾内容，也更善于让 AI 产出更好的结果，因为他们花了很多年与初级员工一起打磨工作。

Atlassian 特意把这两类人放在一起。每隔几个月，整个 R&D 组织都会举办 AI Builder Week：为期四天，同步进行，让所有人同时放下日常工作。初级员工展示新工具和新技术，资深员工则分享质量控制、垃圾内容，以及如何在通用 AI 之上构建差异化 AI。Atlassian 已将该项目的方案、日程和各场次视频开源。

Sherif 对人才问题的总结：能找到 AI builder 就招，但比起 10 倍个人，更要打造 10 倍团队。

Sherif 的最大失误与错误假设

• 为要不要推出聊天功能而争论不休. 两年前这在内部颇具争议，它之所以最终广泛上线，只是因为后端反正都必须存在。
• 把聊天当作临时产品。原计划是通过它学习、构建功能，然后把它撤下。如今数百万用户每天都在使用 Rovo 聊天。
• 以为拥有 ChatGPT、Gemini 和 Claude Code 的客户不会使用应用内 AI。他们全都在用，而且会选离手头工作最顺手的那个。
• 在底层工具尚未存在时就发布聊天功能。用户写了很长的提示词想把白板笔记推送到 Jira，结果却收到失败。
• 只为人类构建功能。将每个功能作为智能体工具并通过 MCP 暴露出来的需求，是后来偶然才意识到的。
• 花了大约两年才明白智能体需要与人类相同的基础能力。智能体在 2.5 年前就已进入 Jira 工作流，而“人类能做的事，智能体也能做”这条规则大约六个月前才确立。
• 相信每个人都能成为 AI 构建者。大约有 10 个团队是基于这一前提组建的。
• 把最初几周的速度当作成果。一旦没人做决策，同样的团队在几个月内就停滞了。
• 让产品经理和设计师写代码，而实际比例从 1:10 变为 1:30 或 1:40。就在他们停止掌舵的那一刻，掌舵的工作变得更重了。
• 招聘组合偏重中级和高级人员，轻视初级。现在已经颠倒了。
• 资深员工早期采用 AI 较慢。最擅长识别垃圾内容的人反而更慢上手这些工具。