AI Native 时代研发组织何去何从¶

Ch05.018 AI Native 时代研发组织何去何从¶

📊 Level ⭐⭐ | 19.6KB | entities/ai-native-rd-org-design.md

核心洞察¶

内部访谈数据（4位深度使用AI的工程师）：

• 写代码占比：30% → 5%
• 和 Agent 对话占比：5% → 60%
• 编码效率提升 10 倍，但端到端需求交付效率只提升 2-3 倍
• 节奏变化：过去6周才能完成的迭代，现在同一天完成（上午上线 → 中午A/B测试 → 下午下线 → 5点上线更好版本） 最值得关注的不是数字，是节奏。

组织的本质：2000年协调问题¶

组织的演化核心在解决同一件事：信息怎么路由。

• 罗马军团：8→80→480→5000人嵌套结构，信息路由协议化
• 1806年普鲁士军队改革：总参谋部（中层管理雏形）
• 1840年代美国铁路：第一个组织架构图（防止火车相撞）
• Taylor科学管理、矩阵组织、Squad、Holacracy、Valve扁平化 核心约束始终没变：人的"管理跨度"（3-8人）。 所有组织形状都是这个约束的妥协。

旧定律都是人的协作物理学¶

• 康威定律：团队内部沟通成本 << 跨团队 → 模块边界不可避免与团队边界重合
• 人月神话：沟通成本随人数指数增长 → 加人无法加速延期项目
• Taylor科学管理：工作拆分成专业岗位 → 人的注意力是稀缺资源
• Manager评价制：员工产出不可观测 → 让"信息上最近的人"代理评估 这些不是抽象工程哲学，是人这个生物的协作物理学。

AI 不是新工具，是新协作主体¶

AI 和人形成镜像反面： | 人 | AI | |----|-----| | 沟通衰减 | 无衰减 | | 需要激励 | 不需要 | | 会疲劳/有情绪 | 无 | | Context switching成本高 | 极小 | | 记忆/注意力有限 | 几乎无限 | 结论：所有"以人形约束为前提的设计"，其前提开始失效。

双层架构：Harness + Hive Mind¶

真正在做 AI Native 的团队（Anthropic、CREAO、内部先锋小组）有一个共同形态：

• 底层 = Harness层：代码、测试、流水线、文档、世界模型，所有信息做成 AI 友好形态 → AI 主导
• 上层 = Hive Mind层：对话、试错、idea涌现、Yes-and → 人主导 Anthropic 有最精密的 Harness，但在 Harness 之上选择运行混乱的文化。这两件事不是替代，是叠加。

范式转换：Org Chart → Execution Graph¶

Ken Huang："Once AI becomes agentic, the organization stops being accurately described by an org chart. It becomes an execution graph."

• 旧 Org Chart：最小单元是"人 + 长期关系网"（粘性极高，reorg周期6-12个月）

• 新 Execution Graph：最小单元是"任务 + 上下文 + 权限 + 工具"（机器可读，重组成本压到 week 级） 核心问题变了：

• 旧问题：ownership——"谁拥有这件事？"

• 新问题：routing + governance——"意图从哪里进入系统？怎么被翻译成行动？什么约束让行动是安全的？"

人的双重角色¶

人既是协作的瓶颈，也是协作的兜底。 人过去默默吸收的隐性成本：

• 不完整的需求
• 没注释的代码
• 不一致的 API 约定

• 口头传达的"潜规则" 人能"猜"和"问老王"，系统能正常运转。AI 没有这个能力——AI 需要结构化、可查询、可执行、确定性的信息。 这导致：

• 新瓶颈：不是 AI 能力不够，是系统的信息形态不够

• "人肉中间件"：员工自己当信息搬运工（各系统手动导出→复制粘贴进AI→把AI输出搬回业务系统）

Harness Engineering¶

OpenAI 2026年初提出：工程团队首要职责不再是写代码，而是让 Agent 能干活。 Agent 出错时，问的不是"它怎么这么笨"，而是"我们少了什么能力？怎么让这个能力对 Agent 来说是 legible 和 enforceable 的？" AI 友好的5个维度：测试完备性、环境完备性、架构合理性（无循环依赖、无跨服务隐式调用）、端到端测试可执行性、文档充分性。

复利效应：Harness 跑起来 → AI 接管越多 → 失败信号越丰富 → Harness 优化越快 → 早建好 Harness 的公司会在某个临界点之后突然加速

管理塌缩（不是消失）¶

把管理者工作拆开（10件事）：战略传导、信息聚合、资源协调、日常决策可被系统替代；激励、辅导、招聘退出、文化建设不可被替代；新出现的是意图教练、身份重建、虚无对抗。 Architect = 新最高杠杆点：设计教 AI 怎么工作的人。把组织的隐性 know-how 翻译成 AI 可消化形态。一份 SOP、一个判据、一段架构决策，直接进入 Harness 层。

Architect 的产出被 N 个 agent 复用、被多个 domain team 依赖、被多个项目继承。 找到、留住、主动转身投入这个角色的资深工程师，是新组织最稀缺的资本。 Agent 是新员工类（Ken Huang）：Agents 需要 onboarding、scoping、supervision、offboarding。但有四个最危险的不对称：

• 可被无限复制
• 同小时既 brilliant 又 brittle
• Compliance-blind by default
• Fast enough to fail at scale

Platform 三柱架构¶

三类工作 / 三种治理¶

• 防御性 ego（保护地盘、隐藏失败、邀功避责）→ Yegge 想杀的是这种 ✅
• 生产性 ego（创新的发动机）→ 被杀时没人立刻看到 🔥 AI 当前架构上做不到：有自我连续性（transformer 是 stateless 的）。

三个真实案例¶

1. 先锋案例：4位深度使用AI的工程师 → 3-5人小组，垂直功能划分（无产品/前端/后端边界）→ 沟通从需求评审驱动转向成果评审驱动 → "决策权还在领域专家手上，但开发权可以交出来"
2. 全员现状：数百条内部调研 → 系统打通是断崖式第一痛点 → "员工正在做人肉中间件"
3. 反例：3人小组两阶段对照 → 有挑战有自主权的项目士气高，被调去他人主导项目（贡献关键但汇报只字未提）→ 士气崩塌 → "可见性 ≠ 被看见"

转型的真实代价¶

三个无法回避的问题： 1. 培养断裂：day 1 AI 已在写代码，day 1 的人应该做什么？入门级岗位本身可能消失 → 整个行业不招 day 1 → 三五年后 senior 池枯竭（产业级灾难） 2. 蒸馏焦虑：员工意识到"我说的越多被替代得越快" → 关键知识藏匿 → Harness 工作不可能完成 → 最优秀的人先走 → 转型基本失败 3. 行业级负反馈：竞争压力让公司收缩 → senior 池消耗 → Architect 储备越来越薄 → "death of expertise" 互相加速

还没解决的¶

• AI 信任度：CR和缺陷分析等高风险环节，"不敢全信、人工又扛不住"两难
• 绩效失效：旧评价依据（老板目击）失效，新依据（artifact可见 + recognition主动）还没建立
• 3-5人小团队是临时最优还是终态？
• AI 知识资产继承：员工花几个月调教的 agent，人走时怎么办？

深度分析¶

1. 从 Org Chart 到 Execution Graph：信息路由范式的根本转变¶

传统组织设计的核心约束是人的管理跨度（3-8人）。这个约束决定了组织必然呈现层级结构，而层级结构天然决定了信息路由路径——ownership 模型。当一个问题出现时，组织成员首先问的是"谁负责这件事"，然后通过汇报链找到责任人。 AI Native 时代打破了这两个前提：

• AI 不受管理跨度约束：一个 Agent 可以同时处理 N 个任务，没有"注意力稀缺"问题
• 任务的路由不再依赖人际关系网络：当任务可以被分解为"意图 → 行动 → 约束"的明确路径时， routing 可以被系统化 这意味着组织的核心问题从 "谁拥有这件事" 转变为 "意图从哪里进入系统？怎么被翻译成行动？什么约束让行动是安全的？" 三个新问题。 Execution Graph 的最小单元从"人 + 长期关系网"变成"任务 + 上下文 + 权限 + 工具"，意味着组织的重组成本从季度级压到 week 级。这是组织响应速度的质变。

2. Harness 复利效应：为什么早动手的公司会形成垄断优势¶

Harness Engineering 的复利效应没有被充分理解。大多数公司看到的只是"AI 帮我写代码效率提升 X 倍"，但真正重要的是：

Harness 完善度 ↑ → AI 接管任务比例 ↑ → 失败信号密度 ↑ → Harness 优化速度 ↑

3. "人肉中间件"揭示的断点：系统打通是 AI Native 的基础设施问题¶

文章中"员工正在做人肉中间件"这个观察非常关键。它说明当前 AI Native 转型失败的首要原因不是 AI 能力不够，而是企业的信息基础设施不支持 AI 操作。 现状：各业务系统没有给 AI 留下操作接口 → 员工手动在 AI 和业务系统之间搬运信息 → 人成了 AI 的 UI 层 这意味着 AI Native 转型首先是Platform 基础设施升级，而不是工具引入或流程再造。Agent Platform Group 的六项基本功（枚举 agents、权限纪律、梯度自治、日志、评估 harness、事故响应）描述的正是这个基础设施的核心组件。

4. 三类工作的治理差异：为什么创新需要"生产性 ego"¶

执行类、优化类、创新类工作需要完全不同的治理模式，这个分类的价值在于：

• 执行类：透明度 > 效率，死防御性 ego 是正确的。防御性 ego 在这里指的是保护地盘、隐藏失败、邀功避责——这种 ego 在执行层会导致信息失真，必须消灭。
• 优化类：结构化 + 留批判空间。需要抑制纯防御性 ego，但也要防止陷入"一切皆可优化"的虚无主义。
• 创新类：保护性环境 + 维护生产性 ego。生产性 ego 是"这是我要弄明白的""我不接受这个答案""没想透我睡不着"——这是创新的心理动力来源。 Steve Yegge 想杀的是防御性 ego，但如果没有刻意保护，生产性 ego 会被一并杀死。这是 AI 时代组织设计最微妙的平衡点。

5. 培养断裂与蒸馏焦虑：两个互相加强的死亡螺旋¶

培养断裂：Day 1 工程师的岗位消失会导致 senior 池枯竭——这不是某一家公司的问题，而是整个行业的问题。当没有人再从 junior 成长为 senior，5 年后整个行业会面临 Architect 储备耗尽。 蒸馏焦虑：最优秀的员工意识到"我输出越多知识给 AI，我自己的可替代性越高"——这个逻辑是理性的，但集体理性与个体理性冲突时，个体理性会胜出。关键知识开始藏匿，Harness 建设失去最重要的知识来源，最优秀的人离开，转型失败。 这两个螺旋互相加强：培养断裂 → senior 稀缺 → 幸存 senior 工作量增加 → 蒸馏焦虑加剧 → senior 流失 → Architect 储备更薄。

实践启示¶

1. 第一步：建立 Agent 名册（Agent Registry）¶

不可能治理叫不出名字的东西。在推进任何 AI Native 转型之前，先搞清楚：

• 团队已经在用哪些 AI 工具（官方允许的 + shadow IT）
• 每个 Agent 的职责边界是什么
• Agent 的操作权限有哪些
• Agent 的执行日志是否被记录 这是 Platform 三柱架构的信息基础设施起点。没有这个，所有治理都是空谈。

2. 从"人肉中间件"断点倒推系统打通优先级¶

系统打通是断崖式第一痛点——这意味着组织应该优先解决让 AI 能够自主操作业务系统的问题，而不是让员工继续做人肉中间件。 具体来说：

• 识别员工每天在 AI 和各系统之间手动搬运信息的操作
• 评估这些系统是否有 API / 有没有办法给 Agent 操作权限
• 优先解决高频、高价值、风险可控的系统对接

3. Architect 角色的识别与转型设计¶

不是所有人都适合转向 Architect，但有些资深工程师天然具备这个方向的潜质：

• 能把模糊的业务问题翻译成明确的架构决策
• 关注"这个决策怎么教给 AI"而不是"这个决策怎么执行"
• 有耐心建立 SOP、文档、评估标准——这些工作短期看不到产出，但长期杠杆极高 对于这些人的激励问题：需要重新设计评价体系，承认 Architect 产出的间接性和长期性。Architect 的产出被 N 个 agent 复用、被多个 domain team 依赖——这种价值无法用传统"产出可见性"来衡量。

4. 创新节点的生产性 ego 保护机制¶

创新类工作需要刻意设计保护机制，防止防御性 ego 文化蔓延到创新节点：

• 设立"创新实验区"——实验项目有独立的评价标准，不以交付效率为主要 KPI
• 鼓励"生产性抱怨"——"我不接受这个答案"是被允许的，"我不管这件事"是不被允许的
• 建立"失败奖"——奖励那些探索了不可行方向并记录下来的团队，而不是只奖励成功

5. 应对培养断裂的长期策略¶

培养断裂问题没有短期解法，但可以从现在开始做准备：

• 将资深工程师的知识"外化"为 Harness 组件——SOP、架构文档、决策记录、评估标准
• 建立"知识继承"机制：每个 agent 的配置、偏好设置应该被版本控制，人员离职时可以被新人和新 agent 继承
• 重新思考"师徒制"在 AI Native 时代的形态：day 1 的人不是学写代码，而是学"怎么和 AI 协作"

6. 理解并接受"可见性 ≠ 被看见"¶

3人小组案例揭示的残酷现实：贡献了关键工作但汇报只字未提，团队士气崩塌。这是一个组织透明度的悖论： AI Native 时代，artifact 可见性大幅提升，但"被看见"（被认可、被记住、被感谢）仍然是人的情感需求，不能靠系统自动化解决。 管理者需要刻意设计可见性反馈机制：

• 定期的"工作认可"仪式（不一定是 formal review，可以是团队回顾的一部分）
• 鼓励在结果汇报中明确标注贡献来源，即使是 AI 执行的任务，也要记录是谁设计的 Harness
• 建立"知识贡献"的可见性——把知识翻译成 AI 可用形态的人，值得被认可

References¶

• [1] Jack Dorsey & Roelof Botha, From Hierarchy to Intelligence, Block Inside, March 2026
• [2] Melvin E. Conway, How Do Committees Invent?, Datamation, April 1968
• [3] Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975
• [4] Ken Huang, What is an Agentic AI Native Organization?, Substack, February 2026
• [5] Peter Pang, Why Your "AI-First" Strategy Is Probably Wrong, X (Twitter), April 2026
• [6] Steve Yegge, The Anthropic Hive Mind, Medium, February 2026 → 原文存档

相关实体¶

• 当公司变成Agent：AI 时代组织的 5 个反思 — 范凌访谈
• AI in Cybersecurity Training Resources | SANS Institute
• AI设计的思想实验：权衡与边界
• Martin Fowler AI 研发 Harness：非确定性承重层