她把3500人工程团队交给AI代理：真正的难题不是模型，而是人

把AI引入工程团队，最难的不是选模型、搭系统，而是改变工程师和“工作本身”的关系。Angie Jones 用几年时间，把一个3500人的工程组织推向“自治”，她的方法论，远比你想象得更反直觉。

最反直觉的真相：AI转型失败，通常不是技术问题

Angie Jones 在分享一开始就抛出一个让人不安的事实：她花了几年时间，把一个拥有3500名工程师的组织，逐步改造成“自治工程组织”。但真正让她卡住的，从来不是模型能力不够强。

相反，问题出在工程师和 AI 的关系上。很多团队嘴上说“在用 AI”，实际上只是把它当成一个更聪明的搜索框，或者偶尔帮忙写几行代码的工具。Angie 发现，如果只是堆工具、发账号、搞培训，最终几乎看不到组织层面的改变。

“如果工程师不信任 AI、不愿意把工作真正交出去，那所谓的 AI 转型，永远只停留在表面。”这是她后来反复验证的结论。

三个阶段、五个层级：她用一张成熟度模型看清真相

为了搞清楚团队到底卡在哪，Angie 把 AI enablement 拆成了三个阶段：实验（Experimentation）、采用（Adoption）和影响（Impact）。听起来很常见，但她真正有杀伤力的，是后面那张“工程师与 AI 关系”的成熟度模型。

这套模型不是看你用了多少工具，而是看你敢把什么样的工作交给 AI agent。从最初的“偶尔试试”，到让 AI 并行运行、独立推进任务，整整五个阶段。

残酷的发现是：绝大多数工程师，长期停留在第一、第二阶段。他们会用 AI，但不会依赖它，更不会授权它。这也解释了为什么很多公司喊了两年“AI-first”，实际交付效率几乎没变。

更重要的是，Angie 意识到：如果工程师整体不上到第五阶段，她永远不可能看到真正的业务级影响。

不要指望一刀切：AI 冠军也要“定制化升级”

很多公司会犯一个常见错误：选一批“AI champion”，然后期待他们自然带飞整个组织。Angie 试过，但很快发现行不通。

她的做法更细：目标不是让所有人一起冲到第五阶段，而是先把 AI 冠军推到第三阶段——而且是“按团队定制”。有的团队需要的是更强的自动化测试代理，有的团队则卡在需求拆解和任务分派。

关键不在于炫技，而在于让 delegation（任务委派）感觉“原生”。当工程师发现，把一整块工作交给 agent，和他们原本的工作流并不冲突，心理门槛才会真正降低。

这一步，是从‘我在用 AI’到‘我在和 AI 一起工作’的分水岭。

当多个 AI agent 并行工作，GitHub 反而不重要了

真正让 Angie 觉得“我们到位了”的，是某个看似微不足道的变化：工程师开始自然地让多个 AI agent 并行跑任务。

在这个阶段，AI 不再只是帮你写代码，而是能独立推进子任务、相互配合，甚至在某些流程里，完全绕开了传统工具链——“他们甚至都不需要 GitHub”。

这听起来像一句夸张的玩笑，但对 Angie 来说，这是自治的标志性时刻：人类不再是所有工作的调度中心，而是变成了策略制定者和最终把关人。

她形容那一刻“像做梦一样”，但也清楚，这正是她想把整个组织带到的终点。

总结

Angie Jones 的故事提醒我们：AI 时代真正的组织升级，不是买更贵的模型，而是重新设计“信任、授权和责任”。如果你所在的团队还在纠结用哪个工具，不妨先问一个更尖锐的问题：我们愿不愿意，把一整块真实工作交给 AI？

从评估工程师所处的成熟度阶段开始，逐步推动 delegation 变得自然，而不是强行改变流程。未来最有竞争力的工程组织，不是写代码最快的，而是最敢让 AI 自主行动的。

关键词： AI应用， AI Agent， 工程组织， 自治系统， AI成熟度模型

事实核查备注： 1. Angie Jones 是否在 Block 负责 3500 人工程组织的 AI 转型；2. AI enablement 三阶段（Experimentation/Adoption/Impact）的原始表述；3. 成熟度模型的五个阶段具体定义；4. “第一、第二阶段占多数工程师”的判断来源；5. 关于并行 AI agent 可绕开 GitHub 的具体语境。