94% 都在用 AI，为什么只有 6% 敢规模化？
94% 的工程领导者在用 AI，仅 6% 具备可跨整条生命周期规模化的系统。瓶颈不在会不会用，在敢不敢规模化。
很多工程组织并不缺 AI。
缺的是，敢不敢让 agent 在整条软件生命周期上跑起来。
会提示词吗？
会。
接过 coding agent 吗？
也接了。
个人演示很漂亮。
可一到几百人的组织，手就缩回去了。
这到底是模型不够聪明，还是交易结构没搭好？
2026 年 9 月 10 日，Atlassian 在 Inside 博客里谈了一件事：面向 AI-Native SDLC 的 governed agent loops，也就是受治理的 agent 循环。
官方 2026 AI SDLC study 给了一组对照：
94% 的工程领导者在用 AI。
仅 6% 具备可跨整条生命周期规模化的系统。
几乎人人都在玩 agent。
几乎没人敢让它在整条链路上规模化跑，还不把事情跑坏。
别急着把它读成“又一批 Jira 新功能”。
更别把它读成又一篇 Rovo 清单。
这篇文章，我们只谈一件事：
常开循环、标准、可审 PR 与治理，如何改变工程组织的交易成本。
瓶颈不在会不会用。
瓶颈在敢不敢规模化。
一、先问本质：工程组织到底在争什么？
我经常被学员问：
“润总，我们也上了 AI，也接了 coding agent，为什么交付还是上不去？”
想一想再回答。
你们最贵的时间，花在哪里？
是在写那几行关键代码，还是在等人认领、等人测、等人开 PR、等人审？
表面看，这是“写得快不快”。
底层看，仍然是效率之争。
效率之争的关键变量是什么？
不是口号里的“AI 赋能”。
而是：agent 懂不懂你们的世界；懂了之后，能不能常开着跑；跑的时候，有没有统一标准；标准过了，人还在不在合并按钮上。
所以，表面是 Jira 里多了几条能力。
本质是：
把过去一次一次的提示词会话，重新串成一条从 backlog 到可审 PR 的更短工作链。
怎么办？
先把它写成一个极简公式。
二、极简公式：上下文 × 循环 × 标准 × 人审
很多团队把工程 AI 理解成：
换一个更会写代码的模型，组织吞吐就会自动上去。
真的吗？
如果是这样，94% 已经在用，那 6% 的规模化系统，不该这么稀缺。
因为：模型解决的是“会不会写”。
规模化解决的是“敢不敢让它连续写、连续测、连续开 PR”。
于是有了这个公式：
规模化 = 上下文 × 常开循环 × 标准 × 人审
四个变量，缺一个，乘积就接近零。
没有上下文，agent 像外援空降，不懂架构、不懂决策、不懂你们脑子里的那些“大家都知道”。
没有常开循环，就还是一次提示词、一次魔法时刻。
没有标准，并行一放大，质量口径就散了。
没有人审，合并按钮一旦失控，效率就变成风险外包。
你把它当作一道算法，这个算法就要出现漏洞。
三、生活切片：一次买衬衫，和一条被拆碎的产线
我到商场买一件衬衫。
远远看见样式，走近摸面料，看标签，进试衣间。
这是信息流。
然后开单、付款。
这是资金流。
拎着袋子出门。
这是物流。
三件事，一次完成。
所以你觉得购物很短。
工程组织里的很多工作，本来也可以很短。
一张定义清楚的工作项，写、测、开 PR、审、合。
可现实里，它常被拆碎。
等人认领。
等人有空。
等人测完。
等人想起开 PR。
再等人审。
每等一次，交易成本就加一层。
这就像你买衬衫时，看款式在一层，付款要去另一栋楼，取衣服还要约快递员。
不是活变难了。
是链路被拉长了。
Atlassian 想做的，不是再给每个人多开一扇终端窗口。
而是把“定义清晰且未分配的工作项”，放进一条常开的执行循环。
扫描 → 交给 Jira Coding Agent 执行与测试 → 在 Jira 内开出可审 PR。
人还在。
但人不再是每一个前置步骤的瓶颈。
四、第一刀：agent 不懂你们的世界
Agent 为什么容易失败？
不是因为它不会写代码。
而是因为它不懂你们的世界。
架构在哪？
决策为什么这样定？
标准写在谁的文档里？
机构记忆，是在团队脑子里，还是在频道、文档、仓库的缝隙里？
没有共享上下文，agent 每次都像新来的外包。
能交差。
很难对。
Atlassian 的第一层，是上下文，而且把治理嵌进去。
Code Context 建在 Teamwork Graph 上。
它给 Rovo 与 coding agents 提供跨多仓的安全智能。
官方的说法是：从 backlog 想法是否架构可行、生成懂代码的实施计划，到加快缺陷分诊和根因发现，整条生命周期都更准。
注意，这里的重点不是 Rovo 又多了几项能力。
重点是：同一套给上下文的系统，也在控制 agent 能碰什么。
Agent Context Controls，让平台团队规定：哪些 agent 能进某个空间，能看什么。
给上下文，同时给边界。
这才叫治理，而不是把仓库钥匙整串扔出去。
更好的上下文，真的会变成结果吗？
官方转述了一组 DX 分析：使用最多 Atlassian Teamwork Graph 上下文的团队，人均交付约高 64%。
这是 DX 分析、官方转述。
不是你们公司的保证函。
也不是定价单。
它只说明一件事：上下文不是装饰，是吞吐公式里的乘数。
没有它，循环开得越欢，偏离越大。
五、第二刀：一次提示词，不是一条产线
过去两年，工程里的 AI 故事，多半是个人魔法时刻。
补全一行。
写对一个函数。
演示时大家往前倾。
那很好。
可你不能靠“时刻”经营一家工程组织。
官方把下一班车说得很直白：不是显示器上再多开几个终端。
而是受治理的 agentic 执行。
工作按常开循环跑，而不是一次会话做完就散。
Jira 里的 Agent loops，做的就是这件事。
持续扫描定义清晰、尚未分配的工作项。
交给 Jira Coding Agent 执行与测试。
然后在 Jira 内打开可供人审的 PR。
看清楚前提。
不是把整个 backlog 一股脑倒给机器。
是“定义清晰”且“未分配”。
意图含糊的工作项，循环接不住。
接住了，也只会放大含糊。
那标准从哪里来？
Standards：平台团队一次性定义组织编码标准，并映射到仓库。
然后自动共享给在这个代码库里工作的每个 agent、每个开发者。
标准不是写在 wiki 里等人翻。
是护栏，直接铺到执行面上。
AI Review 再补一刀。
每个 PR 上有一个专用 agent。
对照 Standards，先把问题挑出来，再交给人。
人还是要看。
但人看的，不再是从零开始的荒野。
把这几件事叠在一起，闭环是这样的：
人定意图与护栏 → agent 并行执行 → 人/PM 审并决定什么真正上船 → agent 根据已完成工作更新共享上下文
最后还有一句，必须单独说。
合并按钮，仍在人手上。
你没有交出方向盘。
你交出的是，合并之前那些把人拖成瓶颈的步骤。
六、人定意图，人按合并：这才叫交易结构
商业的本质，是交易。
工程组织里，交易发生在意图、执行、审查、合并之间。
谁出意图？
人。
谁并行执行？
agent。
谁决定什么真正发布？
人，以及 PM。
谁更新下一次还能用的上下文？
agent。
谁按合并？
还是人。
这不是把人请出局。
这是重新设计交易结构。
开发者想少做重复认领、少做机械测试、少做第一轮挑错。
平台团队想标准统一、权限可控、出事能追。
组织想吞吐上去，质量口径不散。
只有当这三方都自愿获益，循环才站得住。
否则，要么不敢开。
要么开了就乱。
所以，治理不是效率的反面。
治理是效率能乘上去的那个分母保护。
没有护栏的并行，不是规模化。
是把个人魔法时刻，复制成组织事故。
七、第三刀：说不清有没有用，就不敢规模化
还有一个更隐蔽的瓶颈。
不是技术。
是证明。
领导要看：AI 到底帮在哪，浪费在哪。
董事会要看：花出去的，对应上了什么交付。
可工程组织里的 AI 影响，一直很难量。
没有完美剧本。
但也不能只有感觉。
Atlassian 把度量嵌进同一套系统。
DX for Agentic Development，看吞吐、质量、采用、成本，把花的和交付的映射起来。
官方还写到：它把 AI Code Insights、工具与 MCP 追踪、模型与任务匹配，以及经过学术验证的 Agent Experience（AX）研究，和软件上下文、护栏放在一起，把可观测与治理闭环。
Jira Agent Usage Dashboard，则帮团队负责人看：工作流里哪些 agent 在被用，怎样用 agent 提高交付速度。
这是把实验，变成你能拿到董事会面前的东西。
说不清，就不敢放。
不敢放，循环就永远停在演示。
演示很热闹。
产线很冷静。
八、可用性：别把路线图读成已经全员上架
到这里，先停一下。
别把一篇发布博客，读成明天全公司都能开的开关。
官方写得很克制。
Code Context：对付费客户逐步开放 beta。
Agent loops、Standards、AI Review：private early access。
Agent Context Controls 与 Agent Usage Dashboard：未来数月，对付费 Jira 客户 GA。
DX for Agentic Development：本季度，对 Atlassian DX 客户 GA。
定价，官方这篇没有给。
我们就不要编。
2026 年 9 月 22 日，还有一场 State of AI SDLC 数字峰会，面向工程与产品负责人。
能听，可以去听。
但听之前，最好先知道自己卡在公式的哪一项。
九、给工程负责人的工具箱：五步自查，再谈敢不敢开
如果你是 CTO、工程负责人、平台团队，或者正在评估 agent 进 SDLC，不妨先做一张清单。
第一，意图清单。
你们 backlog 里，哪些工作项定义足够清晰、尚未分配、适合交给循环？
含糊的需求，先别扔进去。
循环放大的是清晰，也会放大含糊。
第二，上下文地图。
Teamwork Graph 现在能看见哪些仓、哪些决策、哪些机构记忆？
Code Context 覆盖到哪一层？
Agent Context Controls 准备让哪些 agent 进哪些空间、看什么？
没有地图，所谓“更懂你们的世界”，只是愿望。
第三，标准护栏。
平台团队有没有一次性定义编码标准，并映射到仓库？
还是仍散落在 wiki、口口相传和“老员工都知道”里？
Standards 的价值，不在多写一页规范，而在让 agent 和人用同一套口径。
第四，人机分工。
AI Review 可以先挑问题。
人/PM 决定什么真正合并。
合并按钮在谁手里，必须写死。
哪些输出可以当草稿，哪些必须双人看，也要写死。
人离开合并键，公式里的“人审”就归零。
第五，度量与节奏。
吞吐、质量、采用、成本，你们现在能看清几项？
是准备用 DX for Agentic Development，还是先看 Jira Agent Usage Dashboard？
更重要的是：哪些能力还在 beta 或 early access，哪些要等未来数月 GA。
把“未开放项”单独列进评估表，比在通稿里找安慰更有用。
用法本身并不神秘。
难的是，你有没有把“常开、有标准、可审 PR、可治理”四件事，同时设计进落地。
结语
回到开头那个问题。
94% 都在用 AI。
只有 6% 具备可跨整条生命周期规模化的系统。
这组官方数字，不是在嘲笑中间那 88 个百分点。
它在提醒：个人魔法时刻，撑不起一家工程组织。
Jira 这条线上放出的，不是又一个会聊天的助手。
而是一条受治理的常开循环：
扫描清晰未分配的工作项 → agent 执行测试 → Jira 内可审 PR → 人按合并 → 上下文被更新。
你仍然控制合并。
你不再必须充当合并之前的全部瓶颈。
最后送你一句，供拍板时自问：
你是在堆积更多一次一次的提示词，还是在降低一次正确交付的交易成本？
在不确定性里，真正确定的，往往不是又一个工程 AI 名词。
而是你是否愿意，把效率这件事，做到可上下文、可循环、可标准、可人审。
敢不敢规模化，才是瓶颈。
来源：Atlassian Inside：Governed agent loops / AI-Native SDLC（2026-09-10）。94%/6% 出自官方 2026 AI SDLC study；约 64% 为 DX 分析、官方转述。