AI Coding 研发体系(三):团队五级能力模型解析

AI Coding 研发体系｜第三篇

本文深入剖析组织能力维度：随着 AI 融入研发全流程，团队能力将从独立编码、AI 辅助，逐步跃升至监督式工程、多 Agent 协同编排及 AI 研发体系管理。下期将继续详解监督式工程。

本文核心聚焦第四层级：组织能力层。该层承接流程层，并为评价层与治理层提供坚实支撑。

前文探讨流程层时，曾以“订单列表 CSV 导出”为例进行说明。

若仅让 AI 编写代码，它或许能迅速生成下载按钮。然而一旦进入企业级流程，挑战将转化为：由谁界定导出范围，由谁准备订单模块上下文，由谁确认字段顺序与脱敏规则，由谁判定测试结果，以及由谁决定本次变更是否合并。

AI Coding 变革的并非单一编码动作，而是团队内部“职责分工”的本质逻辑。

这正是组织能力层亟需解答的核心命题。

众多团队引入 AI Coding 后，首要反应往往是工具培训。

此举虽有必要，却远远不够。因为工具培训解决的是“如何使用”的问题，而组织能力解决的是“如何将 AI 产出转化为交付成果”的难题。这两者截然不同。

过去，工程师承接需求后，主要依赖个人完成理解、实现、调试与提交。AI 介入后，代码生成部分由 Agent 分担，但需求理解、上下文筛选、验证设计、结果研判及责任归属并未消失。

这些职责反而变得更加显著。

当 AI 承担更多执行动作，人类工程师就必须承担更明确的监督职责。

从组织能力视角审视，AI Coding 团队大致呈现五级能力分化。此处 L1 至 L5 指代能力成熟度，而非公司职级或人员标签。其旨在阐明，团队从个人提效迈向 Agent 研发组织，需填补哪些能力缺口。

此表重点不在于谁更高级，而在于谁承担不同层级的责任。它更适合作为团队能力覆盖图，而非个人晋升标准。在个人提效阶段，L2 已足够；企业若要将 AI Coding 接入流程，L3 将成为分水岭；当团队开始并行使用多 Agent 时，L4 和 L5 方显重要。

这五级中，L3 是关键的转折点。

L1 和 L2 仍更接近个人能力范畴：前者为自主实现，后者为利用 AI 提速。至 L3，工程师开始管理 AI 完成需求。这绝非简单掌握 Prompt，而是要将任务目标、上下文、验证方式及纠偏动作进行系统组织。

以订单导出为例，L2 工程师可能仅让 AI 协助编写导出按钮、补充测试或解释报错。L3 工程师的工作则更靠前：先定义导出范围与权限边界，再准备订单模块上下文，最后设计测试与验收方案。

L3 的出现，标志着 AI Coding 从个人工具使用正式进入人机协作的工程分工阶段。

至 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 落地的同仁，可连贯阅读。

AI Coding 研发体系（一）：企业级 AI 编码的六层架构

AI Coding 研发体系（二）：AI 如何进入研发流程