AI Coding研发体系（三）：AI研发团队的五级能力模型
公众号名称：白鹭智能
作者名称：鹭野
发布时间：2026-06-04 07:30
AI Coding 研发体系｜第三篇 这一篇拆组织能力层：当 AI 进入研发流程以后，团队能力会从个人编码、AI辅助，逐步升级到监督式工程、多Agent编排和AI研发体系管理。下一篇会继续展开监督式工程。
本篇聚焦第四层：组织能力层。它承接流程层，支撑评价层和治理层。
上一篇讲流程层时，我们用“订单列表 CSV 导出”做了一个例子。
如果只是让 AI 写代码，它可能很快做出一个下载按钮。但真正进入企业流程以后，问题会变成：谁来定义导出范围，谁来准备订单模块上下文，谁来确认字段顺序和脱敏规则，谁来判断测试结果，谁来决定这次改动能不能合并。
AI Coding 改变的不是某一个编码动作，而是团队里“谁负责什么”的分工方式。
这就是组织能力层要回答的问题。
流程变了，人也要变
很多团队引入 AI Coding 后，第一反应是培训工具。
这一步有必要，但不够。因为工具培训解决的是“会不会用”，组织能力解决的是“能不能把 AI 产出变成交付结果”。这两个问题不是一回事。
以前，一个工程师拿到需求，主要靠自己理解、实现、调试、提交。AI 进入以后，代码生成的一部分工作被 Agent 承担，但需求理解、上下文选择、验证设计、结果判断和责任归属并没有消失。
这些工作反而变得更显性。
当 AI 承担更多执行动作，人类工程师就要承担更清晰的监督动作。
五级能力模型
从组织能力看，AI Coding 团队大致会出现五级能力分化。这里的 L1 到 L5 指的是能力成熟度，不是公司职级，也不是给人贴标签。它要说明的是，一个团队从个人提效走向 Agent 研发组织，需要补哪些能力。
| 层级 | 典型角色 | 核心能力 | 工作重心 |
|---|---|---|---|
| L1 | 传统工程师 | 编码、调试 | 自己完成实现 |
| L2 | AI辅助工程师 | Prompt、工具使用 | 用 AI 加快局部任务 |
| L3 | 监督式工程师 | 意图、上下文、验证、纠偏 | 管理 AI 完成需求 |
| L4 | AI Tech Lead | 多 Agent 编排、架构治理 | 管理一组 Agent 和工程边界 |
| L5 | AI Engineering Manager | 体系设计、指标、治理、ROI | 管理 AI 研发系统 |
这张表的重点不是谁更高级，而是谁在承担不同层级的责任。它更适合作为团队能力覆盖图，而不是个人晋升标准。个人提效阶段，L2 已经够用；企业要把 AI Coding 接入流程，L3 会变成分水岭；当一个团队开始同时使用多个 Agent，L4 和 L5 才会变得重要。
L3是分水岭
这五级里，L3 是关键分水岭。
L1 和 L2 仍然更接近个人能力：一个是自己实现，一个是用 AI 提速。到了 L3，工程师开始管理 AI 完成需求。这不是简单会写 Prompt，而是能把任务目标、上下文、验证方式和纠偏动作组织起来。
订单导出这个例子里，L2 工程师可能会让 AI 帮忙写导出按钮、补一个测试、解释一段报错。L3 工程师要做的事情更前置：先定义导出范围和权限边界，再准备订单模块上下文，最后设计测试和验收方式。
| 能力阶段 | 订单导出需求里的表现 |
|---|---|
| L1 传统工程师 | 自己找代码、写导出、跑测试 |
| L2 AI辅助工程师 | 让 AI 写局部代码、解释报错、补测试 |
| L3 监督式工程师 | 定义边界、准备上下文、设计验证、纠偏 AI |
| L4 AI Tech Lead | 决定多个 Agent 如何分工、哪些模块不能自动改 |
| L5 AI Engineering Manager | 用指标和治理判断这类任务是否真的提升交付 |
L3 的出现，说明 AI Coding 开始从个人工具使用，进入人机协作的工程分工。
Tech Lead要管Agent
到了 L4，问题会再上一个台阶。
一个 AI Tech Lead 不能只关心某个工程师会不会用工具，而要关心多个 Agent 如何协作。PM Agent 拆需求，Architect Agent 比较方案，Coding Agent 生成修改，Review Agent 检查规范，QA Agent 设计测试。它们之间的任务边界、上下文共享、状态同步和结果汇总，都需要被设计。
这时 Tech Lead 的工作会更像“工程编排者”：决定哪些任务适合交给 Agent，哪些模块禁止自动改，哪些测试必须跑，哪些结果必须人工确认，哪些失败要立刻停止。
单个 Agent 的能力决定一次任务的上限，多 Agent 的编排能力决定团队能不能稳定交付。
管理者要换指标
到了 L5，AI Coding 就不是工程师个人效率问题，而是研发管理问题。
AI Engineering Manager 要关心的，不只是工具覆盖率、使用人数和 Prompt 次数，而是这套系统有没有真正改变交付结果：一次成功率有没有提高，平均反馈轮次有没有下降，AI 返工率是否可控，验证成本有没有吞掉编码收益，风险事件能不能追踪。
这也是组织能力层和评价层的连接点。没有组织能力，指标只会变成报表；没有指标，组织能力也很难复盘。
AI Coding 的组织分水岭，不是团队里有多少人会用工具，而是多少人能把 AI 产出变成可验证、可负责、可复盘的交付结果。
所以，组织能力层不是软话题。它决定流程层能不能真正运行，也决定后面的评价层和治理层有没有对象可管。
当工程师的工作从“亲自写每一行代码”转向“定义目标、组织上下文、验证结果和承担责任”，监督式工程就不是一个新名词，而是一种新的研发工作方式。
下一篇，我会单独拆这个问题：什么是监督式工程，以及它为什么会成为 AI Coding 进入企业后的关键能力。
后续会继续拆监督式工程、AI 研发指标和 Agent 治理边界。做研发管理、工程效率或企业 AI 落地的朋友，可以连起来看。
内容效果不满意？点此反馈