最近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。第一次写出类似assigneecurrentUser()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 GraphAI 真正需要的不是数据而是工作关系如果说 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在同一套工作流中高效协作。如果你的团队正在推进 Atlassian 平台升级、AI 应用探索或研发效能提升欢迎一起交流。作者简介YY哥• Atlassian 解决方案顾问 | 国内唯一大满贯认证专家 | 中国社区负责人 | 插件开发者• 曾任互联网企业 PMO 总监拥有 15 年职场经验与十余年项目管理、研发效能和企业协作体系建设经验• 长期服务于电商、金融、旅游、医疗、制造、Web 3 等行业• 关注全球化企业跨地域协作、AI 组织上下文建设与 Atlassian 工作系统落地