最近，AI 原生软件开发（AI-native Software Development）开始成为行业讨论的新话题。
越来越多的 AI 智能体（AI Agent）已经能够写代码、修 Bug、提交 PR，甚至自动完成测试。
大家讨论最多的是：哪个 Agent 更聪明、哪个模型更强、哪个工具体验更好。
但我越来越觉得，当 AI 智能体开始真正参与软件交付，一个更大的问题才刚刚出现：
谁来给它们分配任务？谁来提供上下文？谁来判断什么时候需要人工接手？又是谁来决定，它们应该参与哪个 Sprint？
回头看 Jira 二十多年的产品演进，我越来越觉得：今天看到的 AI，并不是 Jira 突然增加的一项新功能，而是它底层逻辑不断演进后的自然结果。
这不是一篇产品发布时间线，也不是一篇官方口径的能力盘点。
它更像是一个 Jira 长期用户回头看时，试着回答一个问题：
为什么这个最初看起来有些朴素、甚至有点“丑”的 Bug Tracker，能一路走到今天，变成一个正在承载人与 AI 协同交付的软件开发平台？
如果只看表面的功能变化，这二十多年当然发生了很多事：从表单页面到 Scrum 面板，从 Server 到 Cloud，从插件生态到 Teamwork Graph，再到今天的 AI 智能体、自动化和成本治理。
但如果往下看一层，你会发现，Jira 真正演进的，不只是功能，而是它对“工作”这件事的理解方式。
在我看来，Jira 这二十多年的变化，可以概括为三次跃迁：
从记录问题，到驱动团队协作，再到今天开始尝试调度人与 AI 一起交付软件。
更准确地说，Jira 二十多年的演进，不是从一个工具变成另一个工具，而是不断扩大“可被结构化管理的工作对象”范围：
从 Bug，到 Sprint，到跨团队协作关系，再到人与 AI 智能体共同参与的交付过程。
它最早不是漂亮工具，而是流程引擎
今天重新审视 Jira，我越来越觉得： Jira 最重要的创新，并不是它能记录 Bug，而是它第一次把“流程”本身变成了软件的一部分。
很多老用户对 Jira 的第一印象，大概都差不多：蓝灰色界面、表单式创建页面、字段很多、谈不上好看，但很“能干活”。
那个年代，很多团队还在用邮件、Excel、共享文件夹，或者更早一批的缺陷管理工具。
Jira 看起来也不是一个“颠覆性”的产品。
它最开始做的事情很简单：创建问题、分配负责人、更新状态、写评论、最后关闭。
但它和许多同类工具不一样的地方，从一开始就存在：
它不是把一个固定流程塞给团队，而是允许团队自己定义流程。
这件事在今天看似平常，但在当时很重要。
很多工具预设的流程大同小异：打开 -> 处理中 -> 已解决 -> 已关闭，你只能适应它。
而 Jira 的思路更像是：你们团队到底怎么工作，你们自己来决定，我给你一个工作流引擎。
很多团队第一次真正“把研发流程跑起来”，并不是因为 Jira 提供了多漂亮的界面，而是因为它第一次把不同团队真实存在的流程差异纳入了系统。
测试想要“待验证”，开发想要“待联调”，项目经理想要“已阻塞”，这些都不是额外备注，而是正式状态。
Jira 从第一天起，就不是一个只会记 Bug 的工具——它更像一个流程引擎的雏形，只不过当时承载的对象还只是缺陷和任务。
敏捷时代，Jira 成了团队的共识界面
从这个阶段开始，Jira 不再只是记录事实，而是开始塑造团队每天如何对齐事实。
后来敏捷开发流行起来，Jira 的身份第一次发生了明显变化。
2009 年 Atlassian 收购 GreenHopper 后，Scrum / Kanban 面板、燃尽图、版本规划等能力逐渐成为 Jira 敏捷体验的重要组成部分。
很多团队第一次真正体会到“敏捷管理”是什么，不是因为读了 Scrum 指南，而是因为第一次把卡片从左边拖到右边，看到 Sprint 里的工作从一堆分散任务，变成了一个可以被可视化、被统计、被复盘的交付过程。
到这一步，Jira 不再只是开发或测试的后台系统。
它成了很多团队每天站会时盯着看的那块屏幕，成了一个团队对当前工作状态的共同认知。
这里面还有一个老用户普遍很有感情的东西：JQL。第一次写出类似：
assignee = currentUser() AND status != Done
这样的语句时，很多人都会有一种“原来还能这样”的感觉。它不是一个简单搜索框，而是一种把工作对象结构化之后，允许你按任意维度提取、组合、追踪的能力。
这其实非常能体现 Jira 的底层逻辑：先把工作对象标准化、结构化，再把它们变成可查询、可统计、可自动化处理的资产。
当然，这个阶段 Jira 的另一面也开始显现：复杂度上升了。工作流方案、问题类型方案、界面方案、字段配置，这些概念把灵活性带到了一个新高度，也把门槛一起抬高了。
如果说早期 Jira 解决的是“把问题记下来”，那么敏捷时代的 Jira 解决的是“让团队围绕同一批任务、同一套状态和同一个节奏协同起来”。这是它第一次从工具走向平台。
平台化之后，Jira 开始承载复杂组织
Jira 的平台化，表面看是功能越来越多，真正重要的是，它开始承载更复杂的组织结构、协作边界和治理要求。
再后来，Jira 开始逐渐摆脱“这是开发团队才会用的东西”这个标签。
一方面，是 Atlassian 自身产品矩阵不断扩展：Confluence、Bitbucket、Jira Service Management、Opsgenie、Statuspage、Jira Product Discovery、Rovo、Jira Align 等等。
另一方面，是 Marketplace 生态的成熟：ScriptRunner、eazyBI、BigPicture、Automation for Jira 等一系列插件，让 Jira 的适用范围快速放大。
很多组织在这个阶段才真正意识到：Jira 不是一个单点工具，而是一个可以承接跨团队、跨职能、跨系统协作的工作底座。
这也是 Jira 发展路径里一个非常重要、但经常被忽略的分叉点。
有一类产品的思路，是尽可能把沟通、文档、项目、日历、流程、代码协作都收进一个统一入口里，用统一交互和统一体验降低门槛。
这样的路线有很强的直觉优势：上手快、入口少、组织推动容易。
而 Jira 走的是另一条路：开放平台 + 专业深度 + 生态扩展。
它的特点不是“什么都自己做”，而是把工作流、权限、对象模型、自动化和集成能力做到足够深，然后通过 API、Marketplace 和平台能力让生态来生长。
这条路的代价也很明显：
它不总是最轻、最顺手、最容易开箱即用的那个。
但它有两个非常强的长期优势。
第一，适配复杂组织的能力更强。
组织越大，流程差异、权限边界和合规要求就越多；这时候，单一、标准化的工具体验往往很难覆盖现实场景。
第二，生态累积会变成真正的护城河。
二十多年的插件、集成、顾问经验、管理员经验，不是靠一个漂亮的新入口就能迅速替代的。
所以，如果从老用户视角看，Jira 的平台化，不是“功能越做越多”这么简单，而是它越来越像复杂组织运行工作流的底座。
Cloud 转型，本质是为上下文连接和 AI 铺路
Cloud 的意义，当然包括不用再自己维护服务器，但更大的变化在于：工作上下文终于有机会在平台层被统一连接起来。
很多人谈 Jira 的 Cloud 转型，第一反应是部署形态变了：
不用自己维护服务器了，不用自己安排升级窗口了，不用为了一个插件兼容性问题熬夜排查了。
这些当然都对。但如果只把 Cloud 理解成“托管部署”，其实低估了这次转型的意义。
从长期使用经验看，Cloud 带来的最大变化之一是：它让原本分散的工作数据，第一次有机会成为统一的底层资产。
在 Data Center 或较早期的本地部署阶段，Jira、Confluence、代码仓库、聊天工具、知识库、告警系统之间即便能连，也常常只是“表面连通”。
链接能跳转，权限能同步一部分，但底层上依然是一个个相互独立的系统。
而 Cloud 让一件事真正变得可能：把工作对象之间的关系，以平台级方式沉淀下来。
一个需求关联了哪些文档、哪些决策、哪些代码变更、哪些讨论、哪些负责人，理论上都可以进入同一张关系网络。
这正是后面所有 AI 能力能否成立的前提。
如果数据还长期散落在彼此分隔的本地系统里，AI 最多只能做到“局部聪明”。只有当上下文在平台层被打通，AI 才有机会从“会回答问题”走向“理解工作关系”。
所以，从这个意义上说，Cloud 不是 Jira 演进故事里的一个部署章节，而是它从“工具集合”走向“统一工作底座”的关键转折点。
Teamwork Graph：AI 真正需要的不是数据，而是工作关系
如果说 Cloud 解决的是“数据放在哪里、系统如何连接”的问题，那么 Teamwork Graph 解决的就是另一个问题：
这些工作对象之间到底是什么关系。
需要先说一句实话：
这仍然是一个持续演进中的基础设施，并不是一个已经完全成熟、边界清晰、所有能力都充分暴露给终端用户的独立成品。
但从方向上看，它非常重要。
因为它指向的不是“再加一个 AI 功能”，而是另一个更根本的变化：Jira 不再只是存放工作记录的地方，它正在理解工作对象之间的关系。
这两者差别很大。
如果一个系统只能看到文字，那么它能做的是摘要、问答、推荐、生成内容。
这样的能力已经很有价值，但它理解的主要还是“文本”。
而当一个系统能看到工作任务、Epic、文档、PR、依赖、负责人、团队、目标、告警和讨论之间的结构关系，它理解的就不再只是文字，而是工作如何发生。
比如，一个 Bug 为什么优先级突然升高，不只是因为描述里写了“严重”，而是因为它阻塞了当前 Sprint 的关键交付，还关联到一个核心客户问题。
一个需求为什么不能立刻开始，不只是因为没人接，而是因为它依赖的架构决策文档还没定稿，相关服务的负责人也在另一个发布窗口里。
没有这些上下文，AI 往往只能按照 Jira 工作项的字面意思完成任务。它也许能够快速生成代码，却不知道背后的架构约束、历史决策和团队约定，结果看似完成了需求，却可能给团队留下更多返工、Review 和维护成本。
这种理解方式，和只看聊天记录或文档内容的 AI，是非常不一样的。
一个更擅长理解文本，一个更接近理解工作本身。
对普通用户来说，这种差异未必一开始就显性，但一旦进入多人协作、跨团队依赖、持续交付的场景，差别会越来越大。
从实际使用体感看，Teamwork Graph 代表的，不只是“搜索更聪明了”或“推荐更准了”，而是 Jira 作为平台开始具备一种新的能力：把组织里的工作上下文，从分散的信息，变成可供系统理解和调用的结构化图谱。
如果说 Teamwork Graph 提供的是组织上下文，那么 Jira 的作用，就是把这些上下文真正转化为可执行、可协同、可治理的软件交付工作流。
AI 智能体时代，Jira 正在成为 AI 原生 SDLC 的调度中枢
如果说前二十年的 Jira，主要是在帮助人类团队把工作记录清楚、协作顺畅，那么最近这一两年最明显的变化是：它开始承接人与 AI 智能体共同完成软件交付的全过程。
不过，在聊 AI 智能体之前，我觉得有一个越来越重要的观点值得先说清楚。
很多人今天谈 AI 软件开发，讨论的几乎都是 AI Coding：哪个模型写代码更快、哪个 Agent 修 Bug 更准、哪个工具生成 PR 的质量更高。
但软件开发，从来都不仅仅是编写代码。
真正的软件开发，是把业务目标、产品战略、团队知识和组织上下文，一步一步转化为能够在真实组织中持续运行的软件。
编码只是其中的一个环节。
需求从哪里来？上下文是否完整？架构是否一致？依赖有没有识别？这些问题，远比”代码是谁写的“更加重要。
也正因为如此，当 AI 智能体开始进入软件开发时，真正需要管理的，不只是代码生成，而是整个软件交付过程。
这也是为什么，Atlassian 最近提出 AI 原生软件开发时，并没有把重点放在"再做一个更聪明的 Coding Agent"，而是重新定义了整个软件开发生命周期（SDLC）。
从最新发布的规划（Plan） → 委派（Delegate） → 规模化（Scale）/治理（Govern） 框架可以看出，Jira 正在帮助团队把需求意图、代码上下文、历史工作记录和团队知识转化为结构化技术规格；随后再把工作委派给 Claude Code、Cursor、GitHub Copilot、Codex（即将发布）或 Jira Coding Agent，并最终把 AI 的执行过程重新纳入团队熟悉的工作流和治理体系。
AI 智能体会不会写代码，只决定了它的能力；而谁来给它分配任务、提供上下文、安排 Sprint、管理交付，决定了它能不能真正成为团队的一员。
这也意味着，Jira 服务的对象正在发生变化。过去，它主要帮助人管理工作；今天，它开始同时服务于人和 AI 智能体的协同工作，让两者在同一套工作流中协同完成交付。
这一点和“一个统一入口的全能 AI 同事”是两种完全不同的产品哲学。
前者追求的是体验上的一体化：
在团队日常沟通的界面里直接 @ 一个 AI 同事，它自主理解需求、拆解任务、编码、验证、提交，全程在对话流里完成。
优势是顺滑、直觉、门槛低——团队不需要学习新工具，聊天窗口就是工作台。
而 Jira 代表的路线更像是：Agent 可以有很多个，能力可以来自不同供应方，但任务分配、上下文理解、状态同步、审计留痕和流程治理要回到一个可管理的系统里。
说得更直白一点，Jira 的战略方向不是绑定单一 Agent，而是尽可能让不同 Agent 能够进入统一工作流。
它更关心的是：
• 任务是否被正确分配 • 上下文是否足够完整 • 结果是否能回到团队工作流里 • 过程是否可追踪
这也带来了一个很明显的体感变化：
过去，Jira 是我更新工作状态的地方；现在，它正在变成提醒我接手关键判断的地方。
以前我打开 Jira 面板，是为了告诉系统我做到了哪一步。
现在我打开 Jira，更可能是为了看 Agent 做了什么、哪些结果需要我 Review 和确认、哪些风险需要我接手。
这不是哪条路线“更先进”的问题，而是哪条路线更适合不同规模、不同成熟度的组织。
对小团队来说，一个万能入口可能更高效；
对大型工程组织来说，能不能统一编排、统一追踪、统一治理，往往更关键。
拉远一点看，Jira 在 AI 时代的身份变化，不是“它也接入了大模型”，而是它正在从一个工作记录系统，升级为一个 AI 原生的软件交付调度系统。
真正决定 AI 落地的，不是模型，而是治理
这一点，可能是长期使用 Jira 的人和普通围观者最大的视角差异。
围观者最先看到的，往往是 AI 会不会自动写代码、会不会自动修 Bug、会不会自动生成文档。
而真正落地过 Jira 的团队，更容易想到另一组问题：
• 这个 Agent 到底能访问哪些项目、哪些仓库、哪些文档？ • 它生成的改动，谁负责 Review，谁最终背书？ • 如果它频繁试错，成本怎么算？ • 如果它把状态改了、触发了自动化，审计日志在哪里？ • 如果一个团队效果很好，另一个团队效果很差，怎么定位问题是在模型、规则、上下文还是流程设计？
这些问题往往不会出现在 AI 演示的聚光灯下，但它们决定了 AI 是停留在概念验证阶段，还是能够真正进入企业生产环境。
当 Agent 从个人效率工具进入团队交付链路，企业面对的问题也会从：“如何使用 AI”转向：“如何治理 AI 参与的工作”。说到底，AI 真正进入企业生产环境，需要同时解决两个问题：
过程是否可控，以及投入是否值得。
举个更具体的场景：
当一个团队第一次发现某个 Agent 在一个 Sprint 里消耗了 2,000 美元的 Token 成本，却只处理了 3 个问题，团队需要的就不是一句“模型还不够聪明”。
而是一个能回答问题的系统：
• 钱花在了哪些任务上？ • 哪些上下文反复拉取？ • 哪些尝试失败了？ • 产出有没有进入 PR、Review 或发布链路？
也正因为如此，Jira 在这个阶段的优势，并不只是某个 Agent 功能有多强，而是它已经具备承载 AI 工作流所需要的组织基础：
• 权限体系定义边界 • 工作流管理过程 • 自动化规则驱动行动 • 状态机记录变化 • 项目边界明确责任 • 审计和成本机制帮助企业持续治理 AI 的使用
Jira 更偏向解决“过程看得见”的问题：
AI 智能体做了什么、为什么这么做、哪一步需要人工介入，都应该能留下记录。
这里也值得提到 Atlassian 去年收购的工程智能平台 DX。它关注的不是单纯统计开发活动，而是帮助组织理解研发效能、开发者体验以及 AI 投入带来的实际价值。其最新推出的 AI 成本管理能力，则更偏向解决"投入算得清"的问题：
统一分析不同 AI 编码工具的使用成本、Token 消耗和 AI 辅助产出，帮助工程管理者衡量 AI 投入与实际交付结果之间的关系。
一个解决过程透明，一个解决价值衡量。
放在一起，组织才有可能真正管理 AI 的使用、成本、风险和收益。
大型组织真正需要的，不只是一个更流畅的 AI 入口，而是一套能承接权限、审计、成本、责任和例外处理的工作流治理体系。
AI 可以承担越来越多的执行工作，但最终负责判断、审核和决策的，依然是人。
因此，企业真正需要管理的，不只是 AI 本身，而是人与 AI 共同参与工作的整个过程。这也正是 Jira 在 AI 时代持续演进的方向。
回头看，Jira 变了很多，但底层逻辑没变
如果把这二十多年的演进拉直来看，表面上 Jira 早已和当年的 Bug Tracker 判若两物。
但它真正的变化，并不是简单增加了多少功能，而是不断扩大自己能够理解和管理的“工作对象”。
最开始，它管理的是 Bug 和任务。
后来，它管理的是 Sprint、Epic、面板、版本以及团队协作过程。
再后来，它开始连接组织内跨产品、跨角色、跨系统的工作关系。
今天，它进一步把人与 AI 智能体共同交付软件的过程，也放进同一套工作流里：任务怎么来、谁来做、做到哪一步、哪里需要人接手，都能被记录和管理。
从记录一个 Bug，到记录整个软件交付过程，Jira 管理的对象一直在变化；但对于越来越多团队来说，它始终承担着同一个角色——成为团队协同工作的共同事实来源（SSoT）。
所以，Jira 的底层逻辑其实一直没有改变：
它不是替你做决定，而是帮助组织把目标、决策、执行、状态、依赖、反馈和改进，沉淀到一个能够持续运行和优化的系统中。
这也是为什么，一个最初看起来普通的缺陷跟踪工具，能够走过二十多年，并进入 AI 时代。
作为长期用户，我的期待和担忧都很明确
说到底，我认可 Jira 今天的演进方向。
因为软件开发进入 AI 时代后，速度本身已经不再是唯一瓶颈。
真正决定效率上限的，是 AI 是否理解工作的上下文，团队是否能够有效协同，以及组织是否具备治理 AI 的能力。
在这些问题上，Jira 的方向是自洽的。
但我的担忧也很明确：
复杂度。
熟悉 Jira 的人都知道，它最强大的地方，往往也是最容易让团队感到有门槛的地方。
它足够灵活，可以适配复杂组织；但灵活到一定程度，就需要管理员、规范、培训和持续治理。
不过，这几年 Jira 其实已经在主动拆解这类复杂度。
比如，团队管理的 Jira 空间已经可以让团队自行配置工作流、工作类型、界面和字段，很多场景下不再需要 Jira 产品管理员介入；
新的 Jira 体验也在不断降低传统方案、字段和配置概念对普通团队的认知负担。
再加上 Rovo Chat、自然语言搜索、智能创建工作项、AI 辅助内容生成和自动化能力，越来越多过去需要“懂 Jira 配置”的操作，正在变成团队可以直接完成的工作。
但 AI 时代带来的问题是：复杂度并不会消失，而可能以新的形式出现。
过去，Jira 的复杂度主要来自工作流、方案、字段、权限和配置；
进入 AI 时代后，复杂度不会消失，而可能转化为 AI 智能体、自动化规则、上下文配置、成本策略、权限边界和人工接管机制带来的新问题。
如果这些新能力只是叠加在原有体系之上，而没有被设计得足够清晰、足够易用，那么很多团队仍然可能停留在“看上去很先进，实际用不起来”的状态。
所以我真正期待的，不只是 Jira 继续增加 AI 功能，而是它能不能用 AI 反过来降低自己二十多年积累下来的复杂度。
比如，让更多配置从“只有管理员懂”变成“业务团队也能理解”；
让更多流程从“先设计、再落地、再维护”变成“在使用过程中被系统持续识别和优化”；
让团队不只是拥有更强大的工具，而是拥有更容易运行起来的工作系统。
毕竟，工具的终极价值，从来不是它能做多少事，而是它能让团队多轻松地把事情做好。
未来的软件开发团队，不再只有产品经理、开发、测试和运维，也会包括越来越多承担不同职责的 AI 智能体。Jira 持续演进的方向，正是帮助这些新的“团队成员”与人一起协同工作。
今天真正需要管理的，已经不只是软件开发团队，而是人与 AI 智能体共同参与的软件交付系统。
如果你的团队也正在思考：
• 如何让 Jira 不只是任务管理工具，而成为企业协作和交付体系的一部分？ • 如何让 AI 智能体真正进入研发流程，而不是停留在个人效率工具阶段？ • 如何构建适合 AI 时代的工作流、知识体系和治理机制？
欢迎留言交流，也欢迎私信探讨。
过去十多年，我持续帮助企业设计和落地 Atlassian 协作平台，重点关注研发流程、知识管理和跨团队协作。随着 AI 智能体开始进入企业工作流，我也在进一步探索一个新的问题：
如何让人与 AI，在同一套工作流中高效协作。
