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

前言/我们正在看到的事情

我们最近做了一份内部访谈，问几位深度使用 AI 的工程师"你日常时间分配的变化"。结果有点出乎意料——

写代码的占比，从过去的 30% 降到 5%；和 Agent 对话的占比，从 5% 升到 60%；查问题的时间下降一半以上；纯编码效率提升 10 倍，但端到端需求交付效率只提升 2 到 3 倍。

更值得停下的不是数字，是节奏：一个工程师上午 10 点上线一个新功能、中午做 A/B 测试、下午 3 点根据数据下线、5 点上线更好的版本。同一天。这是过去 6 周才能完成的迭代。

为了理解这件事到底意味着什么，我想先回到一个更基本的问题：组织到底是为什么存在的？

把这个问题拉远一点看，会发现组织的演化已经持续了两千年。本质都在解决同一件事：信息怎么路由。

罗马军团把军队拆成 8 → 80 → 480 → 5000 人的嵌套结构，就是把信息路由协议化：每一层都有人聚合下层、传递上层。1806 年，普鲁士被拿破仑打败之后，军队改革重建了"总参谋部"，这是中层管理的雏形：一群专门做信息整合和决策预演的人。

1840 年代，美国铁路从军队里借来这个结构，画出了世界上第一张组织架构图——为了避免火车相撞。Taylor 的科学管理把这个金字塔做到极致；战后矩阵组织、Spotify 的 Squad、Holacracy、Valve 的扁平化，都是各种修补。

这两千年里有一件事没变：组织演化的核心约束是人的"管理跨度"：一个人能直接管的下属在 3 到 8 之间。这个数字不是文化决定的，是人这个生物的硬限制。所以所有组织的形状本质上都是在这个限制上做的妥协。

Block 在最近一篇文章里说得很直接："问题从来不是要不要分层，而是：人是不是这些层唯一的承担者？现在，他们不再是了。"[1]

如果组织的形状是为了适配"人"，那么组织里的所有具体设计，也都是人的镜像。

康威定律说"组织结构 = 系统结构"[2]——为什么？因为团队内部的沟通成本远低于跨团队，所以模块边界不可避免地与团队边界重合。Brooks 在《人月神话》里说"加人无法加速一个延期的项目"[3]——为什么？因为沟通成本随人数指数增长。Frederick Taylor 把工作拆分成专业岗位——为什么？因为人的注意力是稀缺资源。我们今天还在用的 manager 评价制和强制分布——为什么？因为员工产出不可观测，所以让"信息上最近的人"代理评估。

这些定律和制度都不是抽象工程哲学，它们是人这个生物的协作物理学。组织设计的所有特点本质上都是这个物理学的具体实现。

接着这条线，AI 进来之后会发生什么？

AI 不是过去意义上的"工具"：工具是延伸人的能力，AI 是新的协作主体。它的特点正好和人形成镜像反面：人有沟通衰减，AI 没有；人需要激励，AI 不需要；人会疲劳和有情绪，AI 没有；人有 context switching 成本，AI 极小；人的记忆和注意力有限，AI 几乎无限。

也就是说，上一节里所有"以人形约束为前提的设计"，其前提开始失效。

那 AI 实际是怎么进入组织的？是替换人吗？还是和人共存，怎么共存？

观察几个真正在做 AI Native 的团队——Anthropic、CREAO、我们内部的一些先锋小组，会发现一个共同形态：它们的工作分两层，两层的运作逻辑甚至是相反的。

底层是极度结构化的 Harness 层：代码、测试、流水线、文档、世界模型，所有信息都被做成 AI 友好的形态，这一层越结构化越好，AI 主导；上层是极度松散的 Hive Mind 层：对话、试错、idea 涌现、Yes-and，这一层越松散越好，人主导。

Anthropic 几乎肯定有比任何公司都精密的 Harness（Claude 就是它造的），但它在 Harness 之上选择运行混乱的文化——这两件事不是替代，是叠加。结构化是为了释放无结构的协作，不是用结构控制一切。

如果 AI 是新协作主体，AI 的特点正好和人形成镜像反面，那么过去围绕"人"被设计出来的整个组织和研发体系，应该怎么重设计？新瓶颈又会落在哪里？

这是接下来要回答的问题。但要真的回答它，得先承认一件事：组织本身这个对象，需要被重新思考。

Ken Huang 在一篇文章里有一句话，我认为很关键。"Once AI becomes agentic, the organization stops being accurately described by an org chart. It becomes an execution graph."[4]

它的意思是：当 AI 真的能行动、能调用工具、能修改系统、能执行 workflow，你的公司就不再能被一张 org chart 准确描述。它变成了一张 execution graph，一个把人、agents、数据、权限、工具、审批关系当作同等节点的活的网络；节点之间不是"汇报关系"，是"意图到行动的转化链路"。

这个范式转换里最关键的一点是核心问题变了：旧问题是 ownership——"谁拥有这件事？"新问题是 routing 加 governance——"意图从哪里进入系统？怎么被翻译成行动？什么约束让这个行动是安全的？"

为什么这件事真的重要？让我从一个管理者的体感角度补一个：每个做过组织调整的人都经历过 reorg 的真实代价：计划几个月、执行几个月、恢复信任又几个月，一次完整的 reorg 周期常常是 6 到 12 个月。

这是因为旧组织的最小单元是"人 + 长期关系网"。这个单元粘性极高，每次 reorg 实际上是在重新建立信任、重新拆解依赖、重新切割身份归属。

Execution Graph 把组织的最小单元从"人 + 关系网"换成"任务 + 上下文 + 权限 + 工具"，这个单元里大部分依赖是机器可读的 artifact，不是人脑里的隐性关系。

所以重组的成本可以从季度级压到 week 级，这是数量级的跃迁。从公司层面看，这可能是 AI Native 转型最被低估的红利：不是"组织能更高效"的小提升，是适应性速度本身的升级。

前不久看团队的 AI Native 访谈调研，做记录时我在文档里随手写了一句批注：「之前的模式一个工作需要拉入很多人来做模块划分，功能上需要相互协议和对齐目标，消除理解的不一致性。但如果是一个人或者少数人来自定向下的处理，就不需要协商和对齐，自己理解清楚，就能开始干了。」

事后越想越觉得这句话隐含了一个更深的判断——协作的本质是消除理解不一致性的成本，而这个成本，过去一直是人在扛。

人为什么扛得起？不是因为人多牛，是因为没别的选择。我们这个生物有一些硬约束：通信带宽很窄、记忆有限、注意力是稀缺资源、切换情境成本极高，再加上情绪、疲劳、动机这些非线性变量。这些约束放在一起，定义了人作为协作主体的物理形状。前面说的康威定律、人月神话、manager 评价制，都是围绕这些约束的妥协。

但这次访谈让我看清了之前没认真想过的另一面：

人既是协作的瓶颈，也是协作的兜底。

什么意思？过去几十年我们抱怨的所有"组织效率问题"——会议太多、对齐成本高、信息上下传递失真、流程慢，矛头都指向人。

但同时还有一件事却很少有人正面说：一份不完整的需求、一段没注释的代码、一个不一致的 API 约定、一段口头传达的"潜规则"......这些缺陷之所以系统能正常运转，是因为人在用自己的灵活性、推理能力、社会沟通能力悄悄把缺口补上。开个会问一下、走过去问老王、凭经验猜一下、跑去预发环境试一下——这些动作发生得太自然，自然到我们不再把它看作"工作"。

但它们是工作。它们是人扛在肩上的、维持系统运转的隐性成本。

整个研发系统其实长期容忍着大量的不规范、不结构化、不完整的信息，只要人足够聪明、勤奋、熟悉，这些缺陷就不会上升为瓶颈。

而当 AI 接管执行之后，这一面就翻过来了。AI 没有"猜"和"问老王"的能力：它需要的是结构化、可查询、可执行、确定性的信息。但传统系统根本没有这些，因为它从来就不是为 AI 设计的。

这就是新瓶颈的真相：它不是 AI 能力不够，是系统的信息形态不够。过去被人吸收的所有"信息隐性化、信息非结构化、信息缺失"的成本，第一次以瓶颈的形式暴露出来。

我先给一个数据。这是公司内部最近做的一份大规模 AI 化调研，对象是已经在大量使用办公和编程 AI 工具的员工——不是 AI 化的反对派，是已经在用、并且想用得更深的那批人。

在所有维度的期待里，提及最多的是什么？不是模型能力更强，不是响应更快。是"系统打通与数据整合"——数百条原声，所有岗位、所有层级提及频次最高，断崖式领先第二名。

具体痛点是：员工已经认可 AI 的处理能力，但苦于 AI 无法触及他们日常工作的数据和系统：钉钉、数据系统、研发系统、邮件、审批流。

结果是一种很反讽的人机协作：员工自己当信息搬运工，从各系统手动导出数据、复制粘贴进 AI、再把 AI 输出搬回业务系统。

把这个画面看清楚：员工正在做"人肉中间件"。

AI 已经能处理（大模型很强），但系统没给 AI 留接口（系统是为人设计的）。所以人成了系统和 AI 之间的中间件，这是当前 AI 化最大的隐性税。

OpenAI 在 2026 年初提出过一个相关概念叫 Harness Engineering[5]——工程团队的首要职责不再是写代码，而是让 Agent 能干活。当 Agent 出错时，不是问"它怎么这么笨"，而是问"我们少了什么能力？怎么让这个能力对 Agent 来说是 legible 和 enforceable 的？"

我们内部访谈里，一位工程师同事给"AI 友好"做了一个 5 维度归纳：测试完备性、环境完备性、架构合理性（无循环依赖、无跨服务隐式调用）、端到端测试可执行性、文档充分性。

这五个维度有一个共同本质——它们要求的不是"能用"，是"AI 友好"。而我们今天大量的研发系统，能用是因为人聪明，不是因为它们 AI 友好。

新瓶颈一旦看清，给到的判断就很硬：这个瓶颈不会自己消失，需要人主动去拆。而拆它的工作有一个不显眼但至关重要的特性——复利。

一旦 Harness 跑起来，AI 接管的工作越多，失败信号越丰富，Harness 优化得越快，这是一个开始之后只会加速的飞轮。早建好 Harness 的公司会在某个临界点之后突然加速；晚建的公司不只是慢一点，是会被远远甩开。

6.1 管理塌缩

如果新瓶颈的拆除工作如此关键，它会落到谁头上？

CREAO 的 CTO Peter Pang 直接说：他自己两个月前还有 60% 时间在管人，现在不到 10%[5]。Block 把判断说得更激进——"永久的中层管理层不再必要"。

但这个结论太粗糙。

把传统管理者的工作拆开看至少有 10 件事——战略传导、信息聚合、资源协调、日常决策、重大决策、冲突调解、激励、辅导、招聘退出、文化建设。

这十件事在 AI Native 之下命运分化得很厉害——前四项（战略传导、信息聚合、资源协调、日常决策）可被系统替代（World Model 承载 alignment、自动化报告替代汇报）；重大决策和冲突调解形态在变——重大决策从 manager 拍板下沉到离客户最近的 DRI；冲突调解的总量随团队变小自然减少；激励、辅导、招聘退出、文化建设这四项不可被系统替代（伦理上必须由人完成）；还有一类是新出现的——意图教练、身份重建、虚无对抗——以前不需要做、现在需要做、目前几乎没人在做。

所以判断是：管理塌缩，不是管理消失。是管理在重新选择它的位置。

新出现的角色里最关键的是 Architect：设计教 AI 怎么工作的人。这个角色不是写代码、不是堆功能，而是为整个 Execution Graph 设计架构：定义系统能力的边界、设计 SOP、建立测试基础设施、搭建集成与 triage 系统、定义"什么叫好"。

换句话说，Architect 是把组织的隐性 know-how 翻译成 AI 可消化形态的人——他做的每一份 SOP、每一个判据、每一段架构决策，都直接进入 Harness 层、直接决定 AI 接管的深度。

这个角色的特殊性在于——它要求最懂这个领域的人来做。写好的测试需要懂业务的人；写好的 SOP 需要做过这件事的人；定义好的判据需要有品味的人；设计好的架构需要见过失败模式的人。这些都是资深工程师才有的特质。

→ 所以 Architect 是新组织的最高杠杆点——一个 Architect 的产出会被 N 个 agent 复用、被多个 domain team 依赖、被多个项目继承。组织里能找到、留住、并主动转身投入这个角色的资深工程师，就是新组织最稀缺的资本。

还有一类新员工被忽略了——Agent。Ken Huang 直接说"Agentic AI introduces a new employee class."不是比喻——Agents 需要 onboarding、scoping、supervision、offboarding，但它们和人有四个最危险的不对称：可被无限复制、同小时既 brilliant 又 brittle、compliance-blind by default、fast enough to fail at scale。管 agent 不是管软件、也不是管人，需要第三套治理框架。

6.2 Platform 三柱架构

管理者塌缩之后剩下的、扩张出来的、加上数字员工，这些怎么安顿？

Ken Huang 给了我目前看到的最具体的回答：Platform 三柱架构。

柱 1 · Agent Platform Group——中央团队，runtime 标准、权限、日志、可观测、评估 harness、安全部署。Huang 说："This is not 'AI research' in the romantic sense; it's production engineering plus governance."这就是 Architect 角色的组织化形态。

柱 2 · Domain Teams——业务团队。"Own outcomes rather than models."对结果负责，不对模型负责。3-5 人的垂直功能小组就是它的实现。

柱 3 · Risk and Oversight——治理层。Huang 给了一个很硬的定位："An immune system rather than a bureaucratic brake"——免疫系统，不是官僚刹车。"When governance is done well, it does not slow the Hive Mind down; it keeps it alive."

这一柱最被低估——前面所有 AI Native 讨论都在讲创造性、效率、文化，但没人正面回答"出事了怎么办？"Huang 说："Assuming nothing will go wrong is not optimism; it's negligence in a world where mistakes can propagate quickly."

把双层结构（Harness 层 + Hive Mind 层）和三柱架构叠在一起：柱 1 在底层建造、柱 3 在底层守护、柱 2 在上层探索和交付。

横看是两层、竖看是三柱：柱 1 建造底层、柱 3 守护底层、柱 2 在上层探索和交付。

Huang 给了 6 项基本功：枚举 agents、权限纪律、梯度自治、日志、评估 harness、事故响应。它们都不"性感"，但基础设施工作有复利。

6.3 三类工作 / 三种治理：Death of ego 是有边界的

我想在这一节做一个反转——给前面的判断加一个边界条件。

前几节引用的素材里有一个共同倾向——大家都在朝最大化透明度 + 最大化死 ego 的方向推。Yegge 用了一个词："death of the ego"[6]。

听起来很美。但我越想越不踏实——它会扼杀创新。

我先做一个区分。我们日常说的 ego 把两种东西混在一起了：防御性 ego（保护我的地盘、隐藏失败、邀功避责）是旧组织协调机制的副产品——Yegge 想杀的是这种，他对的；生产性 ego（"这是我要弄明白的"、"我不接受这个答案"、"这件事没想透我睡不着"）是创新的发动机——它被杀掉的时候，没人会立刻看到。

为什么生产性 ego 是发动机？困难问题需要数月级的持续注意力——靠"我的"作锚点；创新要求愿意在公开场合显得愚蠢——靠 skin in the game；死胡同期需要顽固——靠"我不接受这是无解问题"；创新常常是反共识的——Hive Mind 越成熟反共识声音越难维持；凌晨 2 点的执着——只发生在你真心觉得"这是我的事"的问题上。

这五件事 AI 当前架构上做不到。AI 没有自我连续性——transformer 是 stateless 的，本质上排斥"在一个问题上保持几个月在乎"这件事。所以创新工作就是人在 AI Native 组织里的真正不可替代领域。

回到 Death of ego——它在哪些工作上对、哪些工作上错？我把工作分成三类：执行类——杀掉防御性 ego 是对的，越透明越好；优化类——抑制 ego，结构化但留批判空间；创新类——保护半成形的想法，主动维护生产性 ego，半私密、不强制广播。

如果一个组织把这三类工作用同一种治理方式管——Death of ego 一刀切——结果就是：执行的高效率 + 创新的死亡。

前面五节判断都是逻辑推理。下面用三个案例来检验。

1 · 先锋：内部访谈的 4 位深度使用 AI 的工程师——写代码 30%→5%、和 Agent 对话 5%→60%、3-5 人小团队按垂直功能划分（不再有产品/前端/后端边界）、沟通从需求评审驱动转向成果评审驱动、决策权与开发权分离（"决策权还在领域专家手上，但开发权可以交出来"——访谈原话）。这是 AI Native 跑通后的样子。

2 · 全员：上一节那份数百条系统打通调研——它告诉我们，普通员工已经在大量用 AI，但还卡在"人肉中间件"阶段。这是 AI 化中段的真实状态。

3 · 反例：一个内部 3 人小组的两阶段对照——同一批人、同样能力。阶段 1 在做一个有挑战、有自主权的项目，团队自评行业前沿、士气很高；阶段 2 因为战略调整被调到他人主导的项目里，贡献关键但汇报里只字未提——士气崩塌、想退出。变量唯一是 ego 投入条件。

这里有一个尖锐的观察："可见性 ≠ 被看见"。他们的代码 commit 都在那里所有人都能看到（可见性），但管理者没在汇报里念他们名字（没有被看见）。这是两件事，而新系统里很容易把前者当成解决了后者。

讲到这里要停一下，问一个不能回避的问题：人怎么办？

行业里因为推行 AI 引发的人员结构调整压力不小，公司内部有一种自嘲："把自己蒸馏完，就在组织里没位置了"。

蒸馏（distillation）这个词太准了。员工每写一份 SOP、每教 AI 一个流程，确实是在把知识"导出"到组织资产里。它感觉是合作行为，但结构上接近一种替代关系。

这件事不能回避，至少有三个原因。

第一，培养断裂。旧路径很清楚：day 1 写简单代码 → 几年写复杂代码 → 设计系统 → 定战略，每一步都是上一步的连续延伸。新路径里这条线断了，day 1 AI 已经在写代码，那 day 1 的人到底应该做什么？最让人不安的可能是：入门级岗位本身可能消失。每家公司不招 day 1 是局部最优，但整个行业不招 day 1，三五年后 senior 池开始枯竭——这是产业级灾难。

第二，蒸馏焦虑会直接破坏 AI Native 转型。当员工意识到"我说的越多被替代得越快"，关键知识开始藏匿，而 Harness 工作恰恰需要员工说出"哪些隐性约定需要被结构化"。员工不说，Harness 工作就不可能完成。最优秀的人先走（他们外部选择最多），剩下的是 risk-averse 的 followers，然后转型基本失败。

第三，行业级的负反馈环：当一些公司开始用 AI 替代而不是放大人时，竞争压力会让其他公司跟着收缩；senior 池被慢慢消耗、Architect 储备越来越薄；大家不知不觉在 "death of expertise" 的方向上互相加速。几年后，整个行业的判断力会被同步抽空。

我不假装有完美方案，但有几个方向能避免最坏情况。明确 AI 红利的分享方式：是用它来扩展组织边界、做以前做不了的事，还是用它来收缩团队？这两条路给员工的信号完全相反；转型必须有真实的"接住"机制，Architect 通道、跨领域 DRI、新业务负责人、真实的过渡支持......不能只是 PPT 上写；诚实分类哪些岗位形态正在变化，因为模糊的承诺比明确的告知更伤人；评价系统必须跟着变，口头说"判断比执行值钱"但 KPI 还是产出量，员工不会信。

AI Native 转型最难的部分不是技术，是处理"被转型"的人。组织里的人不是 capability units，他们是有 ego、有焦虑、有家庭、有身份的存在。AI Native 不是把人当 capability 调度——是给 capability 之外的部分留出位置。

把前面的判断推到这里，仍然有几件事我没有答案。

第一，AI 的信任度。CR 和缺陷分析这种高风险环节，AI 产出仍需打问号，人工审核又跟不上，形成"不敢全信、人工又扛不住"的两难。

第二，绩效失效。评价的旧依据（老板目击）失效，新的依据（artifact 可见 + recognition 主动）还没建立。

第三，3-5 人小团队是临时最优还是终态——目前的"魔法"可能来自三个临时条件：探索者效应、过渡期人形需求、审稿层价值。

第四，AI 知识资产继承。员工花几个月调教好的 agent，人走时怎么办？目前没有任何公司有完整方案。

这些都是开放性问题。承认它们没答案，比假装有答案更诚实。

写到最后，留几条值得记住的判断。

第一，Harness 工作不显眼，但它是组织未来速度的复利本金。早投入和晚投入的差距，不是线性的，是指数的。今天每小时投在 Harness 上的工程精力，就是明天 AI Native 速度的来源。

第二，不要把 AI Native 转型当作"又一次 reorg"——这是错配。AI Native 的真正价值不是再做一次组织调整，而是让组织未来不再需要痛苦的 reorg。今天投入到 Execution Graph 上的工程，是把"组织响应变化"这件事从季度级压到 week 级，这是组织级别的复利。Harness 复利让组织变快，Execution Graph 复利让组织能持续应对变化——两个复利合在一起，是 AI Native 转型的真正礼物。

第三，解决 Architect 的激励问题。把"被威胁的资深工程师"转化为"被赋能的 Architect"：给身份、给权力、给资源。

第四，分辨节点类型，执行节点全透明 + 死防御性 ego；创新节点保护性环境 + 维护生产性 ego。两者搞混 = 执行高效 + 创新死亡。

第五，开始做 agent 名册，你不可能治理你叫不出名字的东西。

最后回到 Block 那个问题——你的公司理解什么是真正难以理解的？这个理解每天都在变深吗？

如果答案是没有，AI 只是降本故事，砍掉人头、几个季度提升毛利、最终被更聪明的对手吞并。如果答案足够深，AI 不是增强你的公司，是揭示你的公司到底是什么。