AI coding 会让科技公司变成更小的经营单元

过去两年，大家讨论AI coding，最常见的说法是“研发效率会提升”。真正的问题不是工程师写代码快了多少，也不是产品经理写PRD快了多少，而是：当写代码、写文档、做测试、改bug、生成原型这些“执行动作”突然大幅提速以后，传统科技公司的产研组织还需不需要维持原来的规模、分工和管理方式？我的判断是：AI coding最终会让很多科技公司从大型产研流水线，变成更小的经营单元。

这里的“更小”，不是简单地说公司员工变少，而是指组织的基本单位会变小：过去一个产品模块可能需要产品经理、设计师、前端、后端、客户端、测试、项目经理、运维一起组成流水线；未来很多产品模块可能会变成少数几个AI-native的product builder，直接负责用户问题、产品定义、AI coding、验证上线和经营结果。这不是一次工具升级，而是一次组织成本假设的重写。

01｜从瀑布、敏捷到AI coding：产研组织的第三次变化

我过去经历过几种不同形态的产研组织。

最早在传统软件公司，大型系统往往采用瀑布开发模式。一个复杂产品可能有几千人参与，一年发一个大版本，每个人像螺丝钉一样负责其中一个模块。那时候的问题是：系统太复杂，人太多，必须靠计划、流程和层级来保证可控。

后来到了互联网公司，敏捷开发、OKR、双周迭代、固定发版日成为主流。相比瀑布，敏捷的核心不是“计划一年”，而是更快地响应变化：需求不断排队，版本不断发车，产品和研发围绕更短周期协作。

但AI coding带来的变化，比瀑布到敏捷更剧烈。因为瀑布到敏捷，本质上还是人在写代码、人在写文档、人在测试、人在发布，只是节奏变快了；AI coding则是让执行本身被自动化。过去一个需求从PRD、设计、开发到测试，可能需要两三周；现在用Codex、Claude Code这类工具，局部场景里一天就可能完成过去数周的工作。

公开研究也能看到类似趋势。GitHub/MIT关于Copilot的受控实验显示，使用AI pair programmer的开发者完成指定编程任务的速度比对照组快55.8%。这个数字未必能直接等同于所有真实团队的产能提升，但它足够说明：coding已经不再是过去那个完全依赖人类手工速度的环节。

所以，AI coding时代真正的问题变成了：瀑布时代解决的是“如何组织大量人完成复杂工程”；敏捷时代解决的是“如何更快响应变化”；AI coding时代要解决的是“当执行速度远远超过组织吸收速度时，公司该怎么办”。

02｜产研团队的变化，很像火车系统的变化

产研组织的变化，很像人类火车系统的变化。蒸汽火车时代，火车要跑起来，需要一整套人工系统。Union Pacific（美国联合太平洋铁路公司）对铁路岗位的历史描述里，列车乘务组包括负责驾驶机车的火车司机、负责整列车运行和乘务协调的列车长、负责检查列车并协助制动和调车的制动员，以及给蒸汽机车火箱加燃料的司炉；站场和线路侧还有扳道员、信号维护员、铺轨工等岗位。那时候火车不是一台机器在跑，而是很多人托着机器跑。

后来铁路进入电气化、高铁和自动驾驶阶段，动力系统、信号系统、调度系统、安全系统不断自动化。JR East是东日本旅客铁道公司，运营东京及日本东北、上越、北陆等区域的铁路和新干线线路。它对新干线自动驾驶的规划使用GoA（Grade of Automation，自动化等级）来描述列车自动化程度：GoA2是司机仍在车头的半自动驾驶，系统负责部分驾驶动作；GoA3是车上仍有乘务人员，但不必由司机在车头持续驾驶；GoA4则是不需要车上人员的无人值守运行。

火车仍然在跑，甚至跑得更快、更准、更安全，但围绕“让火车跑起来”的很多岗位消失了，或者规模大幅缩小了。司炉不再需要，很多制动、调度和安全动作被系统接管，司机的角色也被重新定义。

但这不等于铁路系统里所有人都消失了。乘务、车站服务、餐饮服务、客户服务、安全应急这些岗位仍然存在。以Amtrak（美国国家铁路客运公司）为例，它的车上与车站服务团队仍然负责乘客体验、服务准备、餐饮、销售终端、清洁收尾、安全和客户沟通等工作。

科技公司也是一样。AI coding改变的是产研系统里的“动力系统”：写代码、写文档、做测试、改bug、生成原型、发布版本。这个系统越自动化，围绕执行配置的大量岗位就越会被压缩。

但销售、用户研究、客户成功、行业理解、企业采购沟通这些岗位，不会因为coding变快而同步快50倍。它们更像乘务员、餐车厨师和车站服务人员，连接的是机器之外的真实人类世界。

所以，AI coding不是让所有岗位一起消失，而是让不同岗位的生产力提升出现巨大差异。围绕“让火车跑起来”的人会减少，围绕“乘客为什么坐这趟车、坐得是否舒服、是否愿意再次购买”的人还会继续存在。

03｜AI最大的问题不是提效，而是把瓶颈从“执行”转移到了“价值吸收”

一个科技公司的产品工作，大致可以拆成三段：

research：研究用户、市场、竞争和机会；planning：制定策略、规划版本、定义产品方案；execution：写代码、做设计、测试、发布、推广。

AI对这三段的提升并不均匀。它可以让执行大幅提速。代码生成、测试生成、文档生成、重构、设计初稿、需求草稿，这些环节都会明显变快。但对于research和planning，AI的帮助要有限得多。它可以帮你总结资料、生成假设、整理访谈提纲，但很难替你真正判断：哪个市场值得做，哪个客户会付费，哪个产品方向未来三年会成立。更重要的是，公司的价值不是在代码写完的那一刻产生的，而是在用户理解、使用、付费、续费、增购、推荐之后才产生。

所以我认为AI coding最大的影响不是“提效”，而是把组织瓶颈从执行转移到了价值吸收。

过去，很多团队的瓶颈是“做不出来”：研发排期太满，设计资源不够，测试跟不上，版本发不出去。AI coding之后，很多团队会第一次面对一个更残酷的问题：东西做出来了，但用户不一定消化得了，销售不一定卖得出去，收入不一定涨得起来。

这在企业软件里尤其明显。一个B端客户是否采购、续费、增购，往往取决于预算周期、审批流程、IT安全、组织共识、迁移成本和内部推动者，而不是你这个月多做了30个功能。你可以一天写10个需求，但客户不可能一天完成10次组织变革。

Google Cloud对2024 DORA报告（DevOps Research and Assessment，软件交付效能研究与评估报告）的解读也提醒了类似问题：AI采用提升了文档质量、代码质量和代码review速度，但AI采用增加25%的同时，也伴随交付吞吐估计下降1.5%、交付稳定性估计下降7.2%。这说明开发过程某些局部指标变好，并不自动等于整体交付系统变好。

但这里还有第二层更深的问题。AI不只是把瓶颈转移到价值吸收，它还会脱掉很多组织管理层的“皇帝新衣”。过去，很多产研团队可以用过程指标证明自己有价值：

我们开发了N个需求。我们完成了N个复杂项目。我们支持了N条业务线。我们修复了N个bug。我们有N个工程师、N个小组、N个版本节奏。这个项目很复杂，所以我们很重要。

在执行很贵的时代，这套叙事有一定合理性。因为做一个复杂项目确实需要大量人力、协作、排期、测试和发布，它至少能证明组织投入过巨大努力。

但AI coding之后，这套叙事会迅速贬值。当一天可以生成大量代码、写出几十页PRD、修复一堆bug、产出多个原型时，“我们做了很多”就不再能证明“我们创造了很多价值”。

以前管理层可以对老板、董事会、投资人说：我们做了多少复杂项目、完成了多少需求、搭了多少系统。以后别人会问得更直接：这些复杂项目到底带来了多少新增用户、多少收入、多少续费、多少利润、多少真实留存？也就是说，AI coding会迫使产研团队从“过程价值”回到“经营价值”。当执行变便宜，复杂本身就不再是功劳；只有被市场吸收的复杂，才是价值。

04｜feature数量不再是价值：AI会放大产品团队的功能冲动

AI coding还会放大产品团队的另一个危险：功能冲动。过去一个团队做功能很慢，所以天然会克制。一个需求要排期，要设计，要开发，要测试，要上线，要观察反馈。这个过程虽然低效，但它本身形成了一种约束：因为贵，所以不敢乱做。

AI coding之后，这个约束被打掉了。如果一个产品团队一天可以做10个需求，一周可以做50个需求，那么团队很容易把“能做更多功能”误认为“应该做更多功能”。老板会觉得生产力上来了，团队也会觉得自己更有价值，于是大家自然倾向于把更多功能塞给用户。

但用户并不需要这么多功能。以Slack这样的企业协作产品为例，它的客户可能是科技公司，也可能是工厂、销售团队、咨询公司、学校、政府机构。不同组织对“效率”的定义完全不同。科技公司可能重视异步协作和工程工具集成，传统企业可能更重视审批、权限和稳定性，销售团队可能更重视客户信息流转。如果研发团队因为AI coding太快，就把几百个功能都塞进产品里，对某些用户是有用的，对另一些用户就是噪音。

“功能越多越好”本来就是一个危险假设。2005年Journal of Marketing Research的经典研究《Feature Fatigue》指出，技术进步让公司更容易给产品加载大量功能，但太多功能会让产品难以使用、让用户不知所措；用户在购买前往往高估功能数量的价值，真正使用后会更重视可用性。

AI coding会让这个问题更严重。过去功能膨胀还受研发资源限制；现在如果执行便宜了，产品团队更需要主动克制。否则，组织会从“研发排期驱动”变成“AI产能驱动”，不是因为用户需要，所以我们做，而是因为我们做得出来，所以我们做。

这会让产品团队迷失方向。AI时代最危险的产品团队，不是做得太慢的团队，而是因为做得太快，所以把“能做”误认为“该做”。

05｜执行产能过剩后，裁员是经营理性的一部分

如果执行产能突然提高，组织一定会面对一个刺耳的问题：是不是应该裁员？

很多人不愿意直接谈这个问题，会说多出来的工程师可以去做创新、技术债、架构优化、用户共创、第二曲线。但这个回答在很多现实公司里是不成立的。因为优秀的工程团队本来就在做这些事情。

一个成熟的研发团队里，工程师并不只是写小功能。他们本来就在做长期需求、技术债、架构升级、性能优化、bug fix、核心功能、创新项目。AI coding加速的不是某一类“低端需求”，而是整个执行集合。如果所有执行工作都被加速，那就不存在一个无限大的“更高价值工作池”可以吸收所有人。

更现实的是：如果一个团队原来需要100个工程师完成既有需求、长期规划、技术债和创新探索，现在AI coding让同样的工作只需要更少的人完成，那么经营者一定会重新估算编制。这不是道德判断，而是商业判断。

世界经济论坛《Future of Jobs Report 2025》也提到，在AI改变业务模型的背景下，77%的雇主计划提升员工技能，但也有41%的雇主计划在AI自动化特定任务的地方减少员工规模。

所以，AI coding对企业经营者来说会形成一个悖论：不引入AI coding，可能被更高效的竞争对手干掉；引入AI coding，效率提升之后，又必然面对裁员和组织缩编。

在增长市场里，公司也许还能用新增业务、新市场、新产品线吸收一部分产能。但在成熟市场、稳定市场甚至收缩市场里，最理性的选择往往不是继续堆功能，而是保留必要冗余后缩小团队。

这不一定是一次性裁掉90%。现实中更可能是停止扩招、减少外包、合并团队、降低层级、自然流失不补人，再到阶段性裁员。但方向是明确的：AI coding不会自动创造更多市场需求，它只会让公司更快看见：原来有多少岗位是围绕“执行很贵”这个旧假设配置的。

06｜产品经理和工程师的边界会重组：未来是更小的产研经营单元

AI coding还会重写产品经理和工程师的边界。在AI之前，优秀产品经理的画像已经越来越全面。早期产品经理可能只需要写PRD；后来要懂用户、懂运营、懂数据、懂商业化、懂技术实现成本；再后来还要理解销售、续费、客户成功、社区运营和经营结果。

也就是说，在AI之前，一个优秀产品经理已经越来越像一个产品模块的小CEO。他未必会写代码，但他需要理解用户问题、产品结构、业务目标、技术约束、商业闭环。AI coding之后，变化就变得更本质了：原来唯一没有被优秀产品经理覆盖的coding，也开始被工具打开。

这不是说所有产品经理都能立刻取代工程师，也不是说工程师不重要了。真正复杂、高风险、大规模、高并发、高安全要求的系统，仍然需要顶级工程师。但大量普通业务系统、内部工具、SaaS模块、运营后台、增长实验、垂直行业软件，并不一定需要完整保留过去那种产品经理、设计师、前端、后端、客户端、测试、运维的流水线。

未来很多公司会出现一种新的核心角色：产品型全栈建设者，或者叫AI-native product builder。这种人可能来自优秀产品经理，也可能来自有产品sense的研发。他不一定是传统意义上的最强程序员，但他懂用户、懂业务、懂技术结构，能指挥AI coding完成开发，能做基础验证，能推动上线，也能对经营结果负责。

这就是我说的“更小的经营单元”。它不只是更小的研发小组，而是更直接地面对经营结果。这个小单元不再用“做了多少需求”证明自己，而是用“创造了多少用户价值和商业结果”证明自己。不是铁路不存在了，而是让火车跑起来所需的人变少了；不是软件工程不存在了，而是围绕软件执行配置的大量岗位会变少。

07｜口头拥抱AI，底层抵制AI coding：传统组织的真实惯性

但这并不意味着中国传统互联网公司会很快转向这种AI经营单元。逻辑上成立的组织形态，不会自动在现实中发生。大公司不是按最优效率运行的，它还按权力、责任、风险和惯性运行。

第一，组织文化会抵抗。很多CTO、VP、总监嘴上讲效率，但在传统公司里，管多少人、掌握多少HC、控制多少预算，本身就是权力和职级的一部分。一个管理者手下有500人，和手下只有50人，在组织里的地位完全不一样。所以AI coding的问题很敏感。

经营者视角看到的是：500人能不能变成50人？管理者视角看到的是：如果变成50人，我的权力、预算、职级和存在感是不是也一起缩水？很多公司并不缺提高效率的工具，缺少的是愿意承认“我原来管的500人，未来可能只需要50人”的管理者。

第二，经济停滞期反而会让公司更保守。从理性上说，市场增长放缓、经济压力变大，公司更应该引入AI、减少冗余、提高效率。但现实里，增长好的时候公司才更有空间试错；增长停滞时，任何一次线上事故、客户投诉、系统崩溃都可能变成管理责任。

于是公司会出现一种矛盾状态：战略会上高喊全面拥抱AI，研发流程里却只允许Copilot做少量代码补全，不允许Claude Code或Codex这类Agent真正读取全仓、修改历史代码、重构核心链路。这不是简单的落后，而是组织风险偏好的结果。

第三，责任机制会抵抗。传统大公司为什么喜欢层级？不只是为了协作，也是为了责任缓冲。500人团队出了问题，可以说是某个总监管理不力，是某个owner没把关，是测试遗漏，是历史架构债，是跨部门协作失败。责任链条很长，问题可以被分摊。但如果变成5个AI-native小组，每个小组带着AI coding工具直接改代码、上线、验证，一旦出事故，责任链会非常短：

谁让AI改的？谁review的？谁合并的？谁批准上线的？

组织越小，责任越清晰；责任越清晰，中层越害怕。传统大公司的安全感来自责任分散，AI经营单元的效率来自责任闭环。前者需要层级、流程、审批和背锅链条；后者需要少数人直接面对产品结果、代码质量和商业成败。两套系统天然冲突。

第四，遗留系统会抵抗。很多公司的核心系统早已不是清晰、健康、可理解的工程资产，而是一堆勉强运行的历史代码。几十万行甚至几百万行代码里，混杂着多年前的临时逻辑、特殊客户兼容、灰度开关、权限例外、旧接口、埋点兼容和没人敢删的判断。人类工程师虽然慢，但至少知道哪里不能碰。AI Agent一旦“自信地优化”了某个看似冗余的逻辑，可能就会把一个多年没爆的雷引爆。

这份2024 DORA报告的数据也能解释这种谨慎：虽然AI带来生产力提升，但仍有39%的受访者表示对AI生成代码几乎没有或完全没有信任。

所以很多中国传统互联网公司的真实状态，很可能不是“不用AI”，而是“安全地表演使用AI”。允许补全，不允许自主重构。

允许写demo，不允许改生产系统。允许写周报说AI代码占比提升，不允许AI真正改变研发组织关系。允许口头欢迎AI，不允许底层研发模式真的转向AI coding。

世界经济论坛2025年关于东亚与大洋洲的区域洞察里也提到，组织文化和变革阻力被64%的雇主视为业务转型的重要障碍，高于全球平均水平。这正是传统组织面对AI的真实惯性。

很多公司欢迎的不是AI coding，而是不会改变组织关系的AI补全。它们害怕的不是AI写代码，而是AI让原来的层级、分工和责任链失去意义。所以，中国传统互联网公司不会很快完成这种转型。

真正先变化的，可能不是大厂核心业务，而是小团队、新公司、边缘业务、内部工具、增长停滞但有强经营压力的中小型SaaS。这些组织没有那么多历史包袱，也没有那么复杂的管理层级，更容易接受一个现实：未来的产研团队，不一定要更大，而是要更像一个小型经营体。

结语

AI coding不是让产品团队“更快做更多事”，而是迫使公司重新回答几个更基础的问题：什么事情值得做？谁有资格判断？组织应该围绕什么稀缺资源配置人？一个团队到底是在创造经营结果，还是只是在生产过程指标？

在执行稀缺的时代，公司围绕工程师、流程和项目管理组织生产。在执行不再稀缺的时代，公司会围绕判断力、用户理解、商业转化和系统责任重新组织生产。

所以，AI coding的真正影响，不是研发效率提高了多少，而是科技公司会被迫变成更小、更直接、更接近经营结果的组织单元。这不是效率工具的升级。这是产研组织的一次重新发明。