前两篇我们分别聊了：为什么要给团队搭一套靠谱的 AI 开发"安全带"，以及我们第一次实践时，是怎么把大家常说的"规范"真的写进代码仓库、让三道门禁从红通通变成绿油油的。

写完之后后台收到最多的问题是："你们说的'AI 原生组织'到底是什么？是不是以后就人人全栈、一个人干一个公司的活？我们 30-50 人的小团队，到底应该先做到哪一步？"

这篇专门和大家聊一聊从人的角度看组织——我会用一张图把三层架构、从 0 到 4 的成熟度路径，以及和最近挺火的"一人公司"（OPC）的关系说清楚。先说好：我们现在还在阶段 1，组织层还在摸索中，绝不敢说"我们已经完成转型了"。

一、AI 原生组织 ≠ 人人会用 Copilot

很多团队一开始对"AI 原生"的理解挺简单的：全员装上 Cursor、人人学会写 Prompt、周会分享一下最近用 AI 敲代码的小技巧。这其实最多是阶段 0：个人辅助阶段——确实有用，但用完就没了，没法传承给新人，也没法度量到底提效了多少，出了问题更没法复盘哪里错了。

我们更认同行业里常说的AI 原生研发组织这个概念，它大概是这样的：

• 规范驱动
  ：先把需求说清楚（spec）再写代码，而且这些规格要进 Git，不能只在微信里聊
• Agent 先上
  ：日常敲代码、写脚本、跑测试，让 Agent 先干，人把关
• 人设计系统
  ：TL、架构师、PM 的价值在于定规则、搭流程、开门禁、设指标
• 可度量可复盘
  ：失败了要归档，返工了要总结经验，不能只说一句"感觉模型变聪明了"

一句话总结：AI 原生组织是"团队协作 + 工程系统 + 基础设施"一层一层叠出来的，不是买了哪家的工具就算转型成功。

二、一张图讲清三层（主图）

从上到下三层，每一层的职责分得明明白白：

1. 组织层（最上面）——人怎么协作、怎么评价、怎么管理

这一层要回答的问题很实在：谁来写需求、谁来做 Review、怎么教新人上手、KPI 怎么设、安全合规谁来拍板。

对应我们内部融合版六层里的 L4-L6（培训、评价、治理）。这一层我们这次投入的精力不算多，但长期来看它决定了这套东西能不能常态化——没有指标和培训，Harness 工程很容易变成"几个热心人在折腾的项目"，其他人凑凑热闹就过去了。

实话实说：我们的角色分工文档已经有了，TM/TL 的新职责也在对齐中；但像 L5 的指标体系、L4 的系统化培训这些，还在路线图上，真不敢说已经完成了 AI 原生组织的转型。

2. Harness 层（中间）——Agent 怎么才能可靠地写出能合并的代码

这一层解决的是：规则放在哪里、流程怎么走、错误怎么被机器拦住、失败了怎么复盘。

包括：Proflow、共享规则/技能、验证脚本、CI 门禁、冒烟测试探针、问题归档等等。这是我们最近一轮建设投入最多精力的地方——工程方面自己评估大概有90% 的骨架已经搭起来了。

现状：我们现在在阶段 1"团队 Harness 工程化"（对外叫AI 优先 · Harness 阶段 1）——规则可以同步、门禁能跑起来、第一个问题已经归档了；运营方面大概有78% 左右，像观察期、周度 Review、全链路压测这些还在补。

3. 基础设施层（最下面）——模型、Git、CI、知识库

这一层要解决的是：Agent 和 Harness 跑在什么基础上。

包括：Git 仓库、国产大模型、OpenSpec 规格库、Repo Wiki、Jenkins 这些。融合版的L1 基础设施主要就在这一层。

现状：底座已经很齐全了；但这并不等于 Harness 层或组织层就成熟了——就像有了公路，不等于交通规则和驾校体系都建好了。

图最下面那句**"规范驱动：先 Spec 后 Code"，是三层都要遵守的纪律**，不是某一层的专利。

三、成熟度路径 0→4：我们在哪、下一步去哪

目标图右边（或者下边）的成熟度路径，对外可以这样说：

有三个点特别容易搞混，这里提前澄清一下：

1. 阶段 1 不是终点
   。门禁绿了，只说明工程系统的骨架立起来了；组织层的指标、洞察闭环还在后面。
2. 阶段 2 不是"下个月就全员换 Claude Code"
   。我们学的是契约和角色分离的思想，按 Qoder/Trae/Cursor 的能力一步步来，不追求 Hook 的虚假对等。
3. 阶段数字和"工程 90% / 运营 78%"不是一回事
   ——前者是成熟度的档位，后者是这一轮建设的完成度百分比。

行业里还有个 YC 三档的说法：大概 70% 的团队还在"AI 增强"阶段（用 Copilot，但流程没变）；我们在**"AI 优先"**的早期——Spec/验证已经进系统了；"AI Native"的组织重构是长期目标，绝不是我们现在就敢用的自我标签。

四、30–50 人团队 vs OPC：借思维，不抄形态

最近"一人公司"（OPC，One Person Company）在社交媒体上挺火的：一个人加一个 Agent 就能干全栈的活。30-50 人的研发团队肯定不是一人公司，但可以借用到三种很好的思路：

最关键的差异：一人公司靠一个人的脑子记住所有上下文；团队必须靠仓库的单一信源 + 角色分工 + 门禁 来替代"老板的脑子"。所以组织层和 Harness 层同样重要——只有 Harness 没有培训和指标，新人照样没法快速上手。

灯塔试点怎么组队：中大型业务功能需求，我们采用标准联合舰队——Owner（开发项目经理）、Harness（架构师）、Spec（产品经理）、IC（开发），扩展环还有业务 UAT、测试、维护；一个人当 Owner 对交付和回滚负责，编组是临时的任务队，不是改组织架构。

五、三层分别要投什么（给管理者的极简清单）

如果你是 TL 或者研发负责人，可以按层问自己三个简单的问题：

组织层

• 新人入职有没有固定的学习路径（而不只是"找师兄问一问"）？
• 有没有1-2 个可以看得到的指标（返工率、spec 覆盖率、CI 一次通过率），而不只靠"感觉 AI 提效了"？

Harness 层

• 规范是写进 Git 了还是只在群里说过？
• 代码合并前有没有机器能跑的验证（单测 / 架构 / 冒烟至少有一个）？

基础设施层

• 模型、Git、CI 是不是稳定可用？
• 知识库和 spec 仓库 Agent 能不能直接读到？

我们自己的评估：Harness 层最强，基础设施层够用，组织层最弱——这和"阶段 1"的判断是一致的，也是下一阶段要重点投入的地方。

六、和前两篇的关系（避免读散）

如果你只收藏一张图，就用AI 原生组织目标图；如果只记一个问题，就问：我们团队在成熟度路径的第几档？组织层有没有在投入建设？

七、读者可带走：判断你团队阶段的三问

1. 规范主要存在哪里？
    聊天记录 / 文档盘 / Git 仓库 —— 越往后越接近阶段 1。
2. 谁对"Agent 产出可合并"负责？
    靠个人自觉 / 几个热心人 / 一个明确的 Owner + CI 门禁 —— 最后一种才像真正的团队 Harness（试点需求的 Owner 一般是开发项目经理）。
3. 失败了怎么办？
    骂模型 / 口头说说 / 问题归档并回灌到 rules —— 最后一种才会走向阶段 3 的洞察。

八、下篇预告

下一篇：《我们如何从 Claude Code 学习，又不照搬》——双正本、三角色、六层 vs 六模块、Harness 2.0 Phase A/B 是什么、不是什么。

欢迎留言：你们团队三层里，哪一层最薄？组织层、Harness 层，还是基础设施？