← 返回洞察
2026 年 9 月 · 5 分钟阅读
代码生成不再难，瓶颈是人的上下文：Atlassian 5 人团队的交付纪律
关键定义
多 agent 编排（multi-agent orchestration） 用一个 planner agent 把 PRD 拆成工作项、coder agent 执行、独立 reviewer agent 检查、人类解决冲突的分工流水线。Atlassian 用约 15 小时、约 250 次 agent 会话跑出一个可运行的应用——但真正的生产化发生在人类重新接管领域理解之后。
瓶颈是人的上下文（human context bottleneck） 代码生成能力已超过团队理解业务领域的速度，再多的生成代码也修不了「还没理解的问题」。Atlassian 第一次跳生产失败后得出的结论：交付上限由人对领域和架构的理解决定，不由 agent 的编码速度决定。
把问题做小（make the problem small） 不再一次啃下整个 PRD，而是先选一个团队能真正消化、两三周能交付的单一功能，端到端跑通并借此定型构建方式。Atlassian 把它当作从原型走向企业级生产的关键转折。
2026 年 8 月，Atlassian 公布了一次少见的内部实验：5 人团队用多 agent 把一个周末原型推进到企业级生产，约 5 个月上线、约 5 倍人均产出——但成功的前提是先经历一次失败的跳生产。我们的判断：AI 原生交付的瓶颈已经位移。代码生成不再稀缺，稀缺的是人在开工前对领域的理解；「规划与评审保持人重、执行交给 agent」才是可复制的交付纪律，不是模型或提示词的任何参数。
一、原型很快，跳生产很难：一次失败暴露了真正的瓶颈
团队从一份高层 PRD 出发，构建了四角色分工：planner agent 拆工作项、coder agent 干活、独立 reviewer agent 检查、人类解决冲突。约 15 小时、约 250 次 agent 会话、100 多次评审驳回、10 多次升级到人之后，产出的是一个带真实数据库、能运行的应用，不是 wireframe。来源：Atlassian 官方博客（2026-08-26）。
但把 mock 换成真实集成时崩了：真实 schema 与 mock 不一致；每个 PR 都带着 E2E 测试改动，回归测试失去意义；产品需求还在移动；更关键的是——没有高层系统设计可依，团队没有对「应该怎么实现」的判断力，agent 反复把领域以错误方式链接起来，循环依赖一再出现。
团队的原话（我们转述为判断）
代码生成已经不难了。agent 产出代码的速度超过了我们理解领域的速度，而再多的生成代码也修不了一个我们还没理解的问题——瓶颈是人的上下文。来源：同上（Atlassian 官方博客）。
二、修复动作：把问题做小，先理解再执行
第一次修复尝试是「选一个功能端到端跑通」：较小的 PRD、并行 ticket、一个工作项一个 PR。这解决了架构失控，但暴露了更深的问题——领域仍在 agent 构建的过程中被发现，产品行为问题合并后才暴露，评审者看不懂大 PR 的意图。
第二次修复才是转折：回到「先规划、先梳理，不靠 AI 撑腰」的枯燥传统。开工前团队把功能过一遍、把边角问题问完、完全消化设计；再构建一个能访问代码库和 PRD 的交互式 planner，它会主动问澄清问题、暴露 PRD 缺口；最后加一个 PR review buddy——能回答「这个改动为什么存在」的审查助手，而不是只标 gap。来源：同上（Atlassian 官方博客）。
结果：写任何代码之前已经拥有领域，规划更快、评审更顺、执行加速，最终无痛落地生产。
三、我们的判断：AI 原生交付是 SDLC 的角色重排，不是 vibe coding 放大
企业级产品与 vibe-coded 原型有一个本质区别：执行 spec 的人不是塑造产品的人。产品、设计、合规多个角色共同定义需求，而 agent 无法中途停下来问任何一个。所以「每个关键决策必须在 agent 开工前显式敲定」不是流程洁癖，而是 AI 原生交付的结构性要求。
我们的判断：这套经验概括为一条角色重排——规划和评审保持人重，执行变成 AI 重，人的位置从「逐行写代码」移到「配置工作流、决定何时接管」。团队花在规划上的每一分钟，都在给 agent 的执行速度兜底；跳过规划换来的速度，会以返工和评审成本加倍偿还。
四、可执行的交付纪律清单
① 把问题做小
选一个团队能消化、两三周能交付的单一功能端到端跑通，再定构建方式。一次吞下整个 PRD 是原型期最贵的错误。
② 先规划后执行，决策显式化
agent 开工前把功能过一遍、把边角问题问完；用交互式 planner 暴露 PRD 缺口；每个关键决策写进 ticket，而不是让 agent 猜。
③ 给 agent 配齐上下文
「如果队友需要它，agent 也需要它」——约定、坑、历史决策写进 agent 能查询的地方；手动操作沉淀为 skill，让 agent 可无人值守地复用。
④ 评审保持人重
PR 再大也要人能看懂：用 PR review buddy 类工具降低理解成本，但最终判断（架构、合规、产品意图）留在人。
⑤ 单仓库让 agent 看端到端
client、server、schema、迁移、测试放一个仓库，agent 能追踪 UI 到数据库的完整影响面，减少跨界误改。
五、行动建议与留给买家的决策问题
行动：下一次 agent 交付立项时，先写一页「领域理解文档」——这个工作流谁在决策、边界在哪、哪三个问题 agent 必须问人；再把 PRD 拆成两周内能交付的单个功能，先跑通再扩。把「团队多久能理解一个新领域」当作比「模型多快」更重要的产能指标。
留给买家的决策问题：你的团队是在「用 agent 加速执行一个已经理解的问题」，还是在「让 agent 替自己理解问题」？如果你发现 PR 越来越大、评审越来越看不懂，那不是 agent 的问题——是领域还没有被人消化。
OOMeta AI
OOMeta 的立场与做法：交付纪律先于模型选型。我们为客户做 agent 落地时，FDE/Bootcamp 的 2 周原型约束与本文同源——原型要快，但开工前必须圈定有界范围、写清决策，原型后必须做领域复盘。本文是这一判断在 Atlassian 生产环境实证上的印证。
预约诊断会参考来源：Atlassian《From prototype to production: lessons learned taking AI-built software to enterprise scale》（2026-08-26，5 人团队、约 5 个月、约 5 倍人效、约 250 次 agent 会话）https://www.atlassian.com/blog/jira/ai-built-prototype-to-production
常见问题
Atlassian 的 5 倍人效是怎么算出来的？+
团队口径：5 人团队把一个周末多 agent 原型推进到企业级生产，约 5 个月上线，对照内部传统构建基线测得约 5 倍人均产出（来源：Atlassian 官方博客）。这是自报口径，未被第三方审计。
第一次跳生产为什么失败了？+
四个原因叠加：真实数据库 schema 与 mock 不一致；每个 PR 都带着 E2E 测试改动，让回归测试失效；产品需求持续移动；没有高层架构可依，代码复杂后 agent 反复制造循环依赖。根因是「构建速度超过理解速度」。
「把问题做小」具体怎么操作？+
先选一个团队能消化、两三周能交付的单一功能；把较小的 PRD 拆成并行执行的多张 ticket，每个 ticket 自包含所有关键信息；一个工作项对应一个 PR，人始终贴近 agent 实际构建的东西。
为什么说规划要「先于代码、不靠 AI」？+
企业级产品里，执行 spec 的人不是塑造产品的人，而 agent 无法中途停下来问产品、设计或合规问题，所以每个关键决策必须在 agent 开工前显式敲定。Atlassian 回归了传统的规划和梳理，再用一个交互式 planner 暴露 PRD 缺口。
这套方法论依赖 Atlassian 自家的工具吗？+
核心纪律（先理解领域、把问题做小、人拥有决策、agent 加速执行、把知识写进 agent 可读的地方）与工具无关；Jira、Bitbucket、Rovo 只是承载。任何团队都可以复制方法本身。
OOMeta 怎么看这套经验？+
它与我们 FDE/Bootcamp 方法论的 2 周原型约束同源：原型要快，但原型前必须圈定边界、写清决策，原型后必须做领域复盘。交付纪律比模型选型更早决定一个 agent 项目能不能到生产。
相关文章
周大福 400 个 Agent 怎么用：先武装员工，再谈客户自主
周大福在 24,000 名员工中部署 400+ 定制 AI Agent（AI Fook），一线店员查库存、看工艺故事、拿推荐，没有一个 Agent 直接面对客户。本文拆解内部优先的上线顺序与窄 Agent 舰队架构，并标注 70% 效率、57% 转化提升均为微软口径、无第三方审计——可复制的是模式，不是数字。
Chewy 把 AI 节省写进成本线：$50M 承诺该怎么读
Chewy 09-09 财报电话会承诺 FY2027 起 AI 年节省 $50M，上一财年已入账「低两位数百万」美元；Cai 助手解决约 30% 自助会话（CIO Dive 报道）。我们的判断：AI 节省要入账才算数——已实现与承诺要分开读；「第一方编排=护城河」的声称，护城河在专有工作流数据，不在编排框架。
358 个银行 Agent：数量是面子，完成质量才是里子
Samsung SDS 在友利银行部署 358 个 AI Agent（厂商发布会口径），覆盖对公、财富、内控、客服五大域。我们的判断：agent 数量是滞后指标——厂商自述的核心挑战已是「完成质量」而非「做什么」，工作流必须为 AI 重新设计。抄数量不抄完成质量，358 会变成 358 个玩具。
文档即策略：财务后办公室 AI 的共同骨架
Rivian 把采购应计自动化、Lemvigh-Müller 让超 90% 供应商确认免接触、丰田把设备诊断从 6 小时压到 3 分钟——三家互不相关的公司用了同一套骨架：业务逻辑写成文档而非代码、置信度分级放行、审计链是一等公民。ROI 数字是厂商自报，可信的是模式的重现。