Atlassian 最具争议的增长决策｜Mike Cannon-Brookes
摘要
Atlassian 的可服务市场远不止开发者工具：超过一半用户从事的并非技术岗位。 Cannon-Brookes 对品类的定义是经过刻意设计的：「我们解决人的问题，不解决技术问题。」Jira 从2002年的缺陷追踪工具，演变为问题追踪器、路线图系统和连接技术团队与财务、人力资源、销售、市场等业务团队的通用工作流引擎。
Cannon-Brookes 认为，AI 会压缩业务流程，而不会让工作流软件消失。 Agent 会从流程图中移除单个方框和分支，但相关文件、链接、评论和输出仍会重新进入流程，接受审核、审批或进一步自动化。他的逆共识判断是：AI「是加速器，不是替代品」（“an accelerant, not a replacement”）。
Rovo 之下真正的战略资产，是一张具备权限感知能力的「团队协作图谱」，包含超过1000亿个对象和连接，环比增速超过50%。 这张图谱自2019年起由连接 Atlassian 产品和外部 SaaS 应用的链接构建而成，为企业搜索、上下文理解、排序和 Agent 行动提供底层能力。已有超过350万人每月使用 Atlassian 的 AI 功能：「我们不想营销 AI，我们想把它交付出去」（“We don’t want to market AI; we want to ship it.”）。
AI 显然正在提升从任务到代码的速度，但 Atlassian 拒绝把代码生成变快等同于客户价值，甚至拒绝将其等同于已经实现的生产力提升。 编码约占开发者每周工作时间的1/3，而生成式代码会把工作转移到重建心智模型和审核输出上。考虑到高 token 消耗工具可能让每名开发者花费数千美元、让 Atlassian 每年支出数千万美元，DX 将量化交付指标与定性调查结合起来，以寻找真实 ROI。
Atlassian 的应用层战略，是提供上下文并选择模型，而不是把产品押注在单一模型供应商上。 其生产级 AI 网关运行着超过75个模型，Rovo Dev 在一项典型任务中可能调用2至3个模型，包括 Claude Code 或 Gemini。一个值得注意的内部用例不是从零创建产品，而是对超过500个代码仓库进行 API 变更——大规模「割草」（“mowing the lawn”），让工程师重新回到「景观设计」（“landscape architecture”）。
Cannon-Brookes 既不接受开发者大规模被替代，也不接受只有资深工程师才能继续就业的判断。 他预计5年后 Atlassian 会雇佣更多开发者；让1名资深工程师搭配4至5名经验较少的工程师，仍有持续存在的经济价值，而 AI 可以放大后者的产出。责任仍由人承担：无论代码由 Rovo Dev、Cursor、Claude Code 还是 GitHub Copilot 生成，提交或审批代码的人都对其负责。
Atlassian 的经营准则是「把增长周期拉长，而不是追求更快增长」，即便公司最新披露的营收增速约为21%、云业务增速为26%、RPO 增速为40%。 Cannon-Brookes 希望5年后仍能实现超过20%–30%的持久增长，而不是为了眼前营收，把所有可用资金都花在一个季度上。他给投资者的关键判断是：公司是在播种未来需求，还是只是在收割过去的工作，直到「田地荒芜」。
精读
1. Atlassian 解决的是人的问题和协作问题，而不是编程问题
Cannon-Brookes 纠正了 Biewald 以开发者为中心的前提：技术团队占 Atlassian 活跃用户不到一半。银行、汽车制造商和制药公司都是技术驱动型企业，但 Atlassian 的作用，是让它们的技术团队和业务团队围绕产品与服务真正交付所依赖的流程协同起来。
Jira 的历史解释了这种误解从何而来。2002年的第一个版本是面向开发者和产品经理的缺陷追踪器；随着功能请求和路线图加入，它变成了问题追踪器；更丰富的工作流最终又让它成为一套远超软件开发场景的通用引擎。
共同的对象，是一项在人和系统之间流转的工作。IT 或 DevOps 队列与 HR 或财务服务队列在结构上可能几乎完全相同：工作进入队列，由某人管理，其他参与者贡献内容，而组织需要保留状态和责任归属。
2. Agent 移除的是工作流步骤，而不是工作流本身
Cannon-Brookes 与主流叙事的分歧在于范围：「很大一部分」业务流程会变得更快、更准确、质量更高，但他怀疑大量流程会彻底消失。人们仍然需要协作、跟踪事项，并运用自己的脑力。
他更偏好的心智模型是一张流程图。来自多个供应商的 Agent 技术可以消除「这个方框、那个方框，甚至整条分支」，但周围的工作流仍然存在；这一变化同样适用于技术团队和非技术团队。
因此，Atlassian 增加了将工作分派给 Rovo Agent，或分派给 Salesforce、Google Agentspace、Cursor 和 GitHub Copilot 等平台上的外部 Agent 的能力。Agent 完成任务后，可能返回文件、链接、评论或文本，交由另一个 Agent 或人来审核、授权、打印、发送或继续路由。
Biewald 提到，客户正在用 vibe coding 自己编写仪表盘，并要求供应商提供 API 或 MCP server。Cannon-Brookes 表示认同，但区分了创建技术与成为软件开发者：财务员工生成一次性 Python 分析，是在解决问题，不一定意味着他把软件工程作为职业。
3. 企业级 vibe coding 仍需要受治理的底座
Cannon-Brookes 认为，更广泛地创造技术对社会是「巨大的净利好」：营销人员可以搭建基础网站和应用，财务团队可以完成过去需要程序员参与的分析。但这并不意味着程序员和开发者会消失，尤其是在生成出来的系统开始长期运行之后。
企业层面的约束，来自生成界面之外的一整套要求——权限、合规、治理、监管、审计、数据驻留，以及安全访问内部信息。制作一个公共网站是一类问题；把一个临时搭建的内部应用安全地接入公司数据，则是另一类问题。
Atlassian 对平台的投入正是由这一约束驱动。Agent 要安全参与工作流，前提是企业具备企业搜索、有组织的数据和具备权限感知能力的连接：「不了解底层数据层，我们就无法构建 Agent。」
4. Rovo 将 SaaS 链接变成组织记忆
Cannon-Brookes 把链接称为「SaaS 贸易中的集装箱」。链接在被打开之前就携带了有用的结构：它能识别某个 Google Doc、Figma 原型、GitHub pull request、Salesforce 记录或监控报告，并揭示该对象与其他工作的关系。
Atlassian 大约从2019年开始，利用自身应用和外部 SaaS 产品之间的链接构建团队协作图谱。如今图谱包含超过1000亿个对象和连接；据 Cannon-Brookes 介绍，其增速超过50%环比。
难点在于对关系进行类型化并执行权限控制。一条 Jira issue 可以连接到 pull request、代码仓库、项目、业务计划和电子表格；理解这些对象的类型，系统才能在图谱中导航和排序，而不是把每个链接都当成没有差别的文本。
LLM 让这张图谱从组织知识变成了「组织记忆」。Rovo 可以理解文档内容，跨数百个 SaaS 应用回答问题，也可以通过还原公司内部的历史，解释「fairy dust」和「alchemists」等只有该公司自己理解的术语。
5. AI 采用率看活跃度，而不是看授权席位
Cannon-Brookes 认为，Rovo 可能成为全球最大的企业搜索引擎之一，并且是最好的一个，因为 Atlassian 能把语义检索与关系、排序和权限上下文结合起来。同一张图谱也能改善 Jira 待办、Confluence 推荐、搜索答案、聊天和 Agent 行动。
Atlassian 此前披露，每月 AI 用户超过350万。相比客户数量或购买席位，Cannon-Brookes 更看重这一指标，因为没有活跃度的协作「毫无意义」；100个授权席位只有5名用户，形成的「闲置软件缺口」最终很可能只会续订20个席位。
他的产品结论是，AI 产品和非 AI 产品之间的区别最终会消失。Jira 变得更有用，是因为它可以跨 Confluence、Figma、Slack、Google Docs、Microsoft Teams、Zoom 和 Salesforce 进行推理，而不是因为它多了一个孤立的 AI 标签页。
6. 代码速度不等于工程团队生产力
Biewald 问，感觉自己借助 AI 变快的开发者，是否真的产出了更多东西。Cannon-Brookes 将代码速度与团队速度区分开来：前者是把分配到的任务转化为已提交、已测试或安全的代码；后者还包括选择正确的工作、可靠交付、维护质量，以及交付客户真正想要的价值。
在他引用的研究和 Atlassian 数据中，编码本身约占开发者每周工作时间的1/3。过去几十年，工具一直在加速这部分工作，从汇编语言到高级语言，再到云基础设施、JetBrains IDEA、VS Code，以及如今的 GitHub Copilot、Cursor、Claude Code 和 Rovo Dev。
Atlassian 跟踪「开发者愉悦度」，因为软件创作是一种创造性职业：高效的工程师会进入心流，而构建中断和测试失败会让他们痛苦不堪。AI 暂时扰乱了这一代理指标——生成的代码让人感觉神奇，但开发者必须重新构建过去在编写代码时自然形成的心智模型。
7. DX 让快速上涨的 AI 工具账单变得可问责
经济账已经从每个席位约50美元的 IDE，变成每名开发者可能花费数千美元的 token 成本。Cannon-Brookes 表示，在 Atlassian 内部，这些工具每年可能消耗数千万美元：「如果能获得价值，我很乐意花这笔钱。」
DX 将 pull request 周期时间等量化指标，与经过精心设计的定性调查结合起来。Cannon-Brookes 将其「DX Core 4」框架与 DORA 指标作了区分，并强调两类数据单独都不够；只有结合起来，才能找到可执行的约束点。
他提到的最简单生产力干预，反而最能说明问题：直接问工程师「在这里工作有什么让你觉得糟糕？」如果足够多的人都提到构建系统需要数小时，组织就有了明确的改进目标，即使整体交付数据看起来仍然健康。
在一支超过1万人的研发组织中，Atlassian 跟踪 Rovo Dev、Claude Code、Cursor 和 GitHub Copilot 的花费、时间、采用率、ROI 和上下文；这些工具在内部都各有数千名用户。Cannon-Brookes 强调，随着模型能力趋同，结果会因任务不同而变化。
8. 上下文让代码维护成为近期杀手级应用
Rovo Dev 的目标，是把 Jira issue 转化为经过审批的 pull request；合并后的 pull request 能提供代码质量的强信号。其团队还在构建自我反思能力，让 Agent 能够改进，并避免在旧仓库、新仓库和结构不同的仓库中重复犯错，就像毕业生通过代码审核不断学习一样。
团队协作图谱同时提供技术上下文——既有 issue、pull request、代码仓库和过往解决方案——以及来自 Confluence、Google Drive 或 Figma 的产品上下文。Atlassian 的生产级网关包含超过75个模型，而一项典型的 Rovo Dev 任务可能调用2至3个模型，其中有时包括 Claude Code 或 Gemini。
Cannon-Brookes 给出的最佳例子，是公司内部一项服务的 URL 和请求格式发生变化。超过500个代码仓库需要修改配置或代码；团队先让 Rovo Dev 编写并提交少量示例，随后 Agent 利用这些示例和图谱，寻找结构相似的变更。
盲目生成500个 pull request，只会把瓶颈转移到人工审核上。一个微小的初始错误，可能在1000次自动循环中不断放大，形成「AI 蠕虫」问题；因此 Cannon-Brookes 坚持让人反复介入，而不是让 AI 写代码、再由另一个 AI 审核。
9. 人提供让 Agent 找到方向的知识
Cannon-Brookes 谨慎地描述了这一限制：AI「生成全新的知识，是一件相当棘手的事」。它非常擅长转化组织和个人积累的记忆，但产品创意、客户洞察和真正全新的方向，仍然需要人所掌握的信息和判断力。
他提出的替代方案，不是一个「魔法按钮」，而是让 Agent 像实习生一样工作：先完成一轮，回来接受反馈，再尝试一次。因此，真正高效的工作单元是人机协作循环，而不是 Agent 接到任务后消失，直到工作被认为完成。
在他的白板示例中，Agent 跨 Teams、Google Docs、Jira 和 Confluence 搜索具备权限控制的材料，生成第一版头脑风暴。随后5至6个人添加便利贴、投票、否决建议并讨论结果；这些人类信号再让另一个 Agent 起草备忘录、流程图或 Confluence 页面。
一个人可以对这份草稿录制 Loom，加入此前没有写下来的知识；AI 随后为时间有限的同事总结视频。反复运行这一循环，会把部落知识转化为组织记忆，同时保留 Cannon-Brookes 认为仍不可替代的人类贡献。
10. 更多 AI 可能意味着更多开发者，包括初级开发者
Biewald 提出了另一面：初级开发者招聘似乎更难，他们传统上的工作越来越容易自动化，需求也像是在转向资深工程师。Cannon-Brookes 承认存在不确定性——「我可能完全错了」——但拒绝接受这一结论，也不接受开发者将被大规模替代的判断。
他预计5年后 Atlassian 会雇佣更多开发者，这与他从 AWS 听到的类似预测相呼应。资深技能会像从本地部署系统转向云系统时一样演变；他认为，让1名经验丰富的工程师搭配4至5名经验较少的人，后者借助 AI 大幅提升能力，仍然具有持续的经济价值。
不可谈判的底线是责任归属：提交生成的代码，就意味着开发者对其负责；审批 pull request，就意味着审核者对其负责。「这是 Rovo Dev 写的」或「这是 Cursor 写的」，都不能成为缺陷或安全事故的借口。
Cannon-Brookes 还认为，初级员工可能比资深员工更早引入新的工作方式。Loom 的传播部分得益于年轻、熟悉视频的员工对同步会议提出质疑；他用「20%有用、80%没必要」作为示例比例，同时指出每家公司都可以自行决定数字。
11. Atlassian 优化的是持续时间，而不是最快的营收 headline
Cannon-Brookes 赞赏云基础设施、支付、SaaS 和应用商店加速分发的能力，但也警告幸存者偏差：科技圈庆祝公司快速达到1亿美元 ARR，却忽视了那些「从0到0」的公司。
大约在2010年，Atlassian 已成立8至9年，营收约5000万美元、利润2000万美元，增速约50%；当时约1亿美元营收被视为上市门槛。对于错过如今压缩版里程碑的创始人，他建议首先问自己：客户是否真正看重产品，分发是否有效。
Atlassian 的目标则是「把增长周期拉长，而不是追求更快增长」。公司最新季度营收增长约21%，云营收增长26%，RPO——剩余履约义务，即已签约但尚未计入未来12个月营收的收入——增长40%；季度营收已超过10亿美元、略高于此水平。
「10美元游戏」概括了资源配置问题：把全部10美元都花在下季度营收上，就没有资金投入架构、应对 AI 颠覆或其他长期项目。Cannon-Brookes 希望决策能够支撑5年后超过20%–30%的增长，并将 Amazon 对基础设施和物流的长期投入视为典型范式。
12. 可持续增长需要像衡量收成一样认真衡量播种
月活跃用户只是第一层指标。Atlassian 还观察「MCU」——Cannon-Brookes 称其为「月度协作用户」，但表示自己不知道这个缩写具体代表什么——以区分 Confluence 的阅读者、创建者、评论者、反应者和链接者。
产品驱动漏斗会跟踪试用、7天使用情况、D30、2D30 和回访行为；企业增长还取决于 IT 把关人对安全、合规、治理、控制、分析和推广的评估。每个子群体对价值的定义不同，阻止采用的原因也不同。
销售管线面临同样的时间跨度选择：本季度的结果，可能是在大约2年前由一条多年期管线播下的种子。Cannon-Brookes 那位已经退休的联合创始人曾将管理定义为平衡播种与收割——如果收割速度超过资源再生速度，最终会留下贫瘠的田地。
更深层的检验，是企业靠积累资源产生的「利息」生存，还是在不知不觉中消耗本金。AI 可以生成更多报告，但仍然需要人来解读、决定哪些事项值得关注并展开协作；Cannon-Brookes 最后说，好奇心与创造力是留在科技行业的根本。