我一直觉得AI 带来的组织变革势在必行。可过去听到的大多是“全员使用 AI”“人效提升 30%”之类的口号。昨晚看到的东西彻底得多他们没有给每个员工发一个 AI 助手而是把公司产研交付的上下文、任务分配、验收和绩效装进了一套闭环系统里。大家好我是陆徐洲。昨晚听一家 HIS 公司分享内部实践有三个数字一直在我脑子里打转。周有效需求吞吐量从 100 个提升到 300 个。运维团队从 175 人缩减到 90 人。下半年计划继续缩减到 30 人。这几个数字来自分享方的内部口径我没有条件独立审计。但当一整套已经运行的系统摆在面前时我还是大受震撼。我一直觉得AI 带来的组织变革势在必行。可过去听到的大多是“全员使用 AI”“人效提升 30%”之类的口号。昨晚看到的东西彻底得多他们没有给每个员工发一个 AI 助手而是把公司产研交付的上下文、任务分配、验收和绩效装进了一套闭环系统里。01、一家公司被编译成了一个巨大的 Harness整个链路由三个系统组成。第一套管需求。交付人员负责提出和澄清需求系统实时抓取客户操作行为与后台日志再由 AI 补全上下文、辅助定位问题尽量减少反复开会和远程沟通。第二套管研发。需求进入工单池以后研发人员“抢单”AI 在指定的代码和业务上下文里自主修改跑测试给出预计工时。人最后负责验收同时成为这张工单的责任节点工时和绩效再进一步影响收入。分享方称不同医院维护在同一套代码基线上约 1.4 亿行代码被组织成知识图谱化的功能节点。AI 根据具体医院的需求定位上下文并生成改动。第三套管部署和运维。需求完成后系统可以关联合同、一键部署、监控运行状态、切换主备库。夜间人工响应不过来时AI 还会在授权范围内处理部分紧急事件。最后项目经理只盯一个结果客户是否验收项目是否交付。如果从 Agent 工程的角度看这家公司其实给整个组织造了一个巨大的 Harness。客户行为和日志是上下文需求工单是任务研发与部署系统是工具测试和客户验收是验证器合同与绩效是奖励函数。任务在系统里流转只有异常和最终责任才落到人身上。这也确实解决了一个长期存在的问题很多公司嘴上说 AI Native实际只是每个人各自用 AI 生成一份文档再把文档从产品发给研发从研发发给测试。几个人拿着 AI 生成的内容来回转述沟通链条一点没短甚至生产出了更多需要阅读的“正确废话”。昨晚这套方案直接把中间的传话环节拿掉了。02、中层消失以后程序员成了“责任节点”它最先压缩的是组织里的信息路由。以前项目经理追进度产品经理拆需求研发经理分任务运维负责人排值班。现在系统自己收集状态、补齐上下文、分发工单、估算时间、提醒超期管理者很难再靠“汇总—转述—催办”证明价值。当然中层不会全部消失。真正复杂的目标冲突、资源取舍、客户关系和事故决策仍然需要人。可如果一个管理岗位的主要产出就是开会、排期、写周报和向上汇报它确实处在最危险的位置。更让我唏嘘的是研发人员的位置。在这套系统里程序员不再完整拥有一个需求。他看到的是工单系统已经准备好上下文、建议改法和预计工时他抢单、验收、交付再接受绩效结算。这个过程很容易让人联想到外卖骑手平台分发订单算法规划路径系统记录时长客户完成评价结果影响收入和下一次接单。程序员和骑手的工作当然不等价知识门槛、工作环境和风险完全不同。但两者的管理逻辑开始同构——任务被切成标准单元由系统分配和计时再用可量化结果评价个人。OECD 把这类做法称为“算法管理”软件部分或全部接管过去由管理者完成的任务分配、监控和评价。它能提高一致性与效率也会带来责任不清、逻辑不可解释和员工自主性下降的问题。我最担心的还不是 AI 写了多少代码。更值得警惕的是一种责任倒挂AI 掌握上下文和执行路径人只保留最终验收和事故责任。如果员工没有足够时间复核没有权力拒绝工时估算也看不清 AI 改动的完整影响那么所谓“人在回路”很可能只剩下“人在背锅”。03、为什么老板一定会喜欢站在经营者的位置这套方案实在太有吸引力了。AI 对外增收目前常常只能作为产品附加值功能更智能一些服务体验更好一些能不能单独多收钱并不确定。内部降本却可以直接量化少开多少会议、少招多少人、一个团队多处理多少工单下一张财务报表就能看到。McKinsey 2025 年的全球调查很能说明问题80% 的受访企业把效率作为 AI 项目的目标但只有 39% 报告 AI 已经对企业级 EBIT 产生影响。真正获得显著价值的企业往往不满足于采购工具而是重写整条工作流。昨晚这家公司显然已经跨过了“给员工装个 Copilot”的阶段。降本增效在这里有两条路。一条是同样的人服务更多医院、承接过去做不了的长尾需求公司的业务边界被撑大另一条是业务量不变持续压缩人力成本。我更愿意看到第一条。现实里两条通常会一起发生。世界经济论坛的 2025 年调查里41% 的组织预计削减因 AI 而技能过时的岗位同时有 70% 计划招聘新的 AI 技能人才。裁员和招人并不矛盾企业在缩减旧任务也在高价购买新的控制点。国际劳工组织的判断更克制全球约四分之一的就业岗位会受到生成式 AI 影响大多数职业更可能被重组而非整份工作直接消失。所以AI Native 组织的尽头首先是一张利润表。技术会决定什么可以自动化市场和管理者决定效率红利最终流向业务扩张、员工收入还是更薄的工资表。04、从 100 到 300也可能是一场繁荣幻觉周需求吞吐量翻三倍听起来非常漂亮但这个指标本身并不足以证明价值翻了三倍。需求可以被拆小简单工单可以被优先抢走困难问题可能长期没人接。一个低价值按钮改动和一次涉及患者安全的核心流程重构在统计表里都只是“完成 1 个需求”。当需求数量直接连接绩效和工资指标很快就会反过来塑造行为。大家自然会优化数字而不一定优化客户真正得到的价值。代码也一样。1.4 亿行代码被整理成可检索的功能知识图谱当然是一笔重要资产。但 AI 让新增代码和医院个性化分支越来越便宜以后代码规模也可能变成库存。相似功能不断复制条件分支持续叠加今天省下来的开发工时会在后面的回归测试、版本升级和故障定位里重新结算。DORA 对 AI 辅助软件开发的研究也观察到了这种张力AI 使用率提高交付吞吐会增加交付不稳定性也可能同步上升生成阶段省下的时间常常转移到了审计与验证。AI 会放大一家公司的工程能力也会放大它原有的混乱。判断这套系统是否真的成功至少要同时看三个维度需求有没有被客户真实使用代码质量和重复度是否恶化生产事故、回滚和长期维护成本有没有上升。只盯工单数很容易得到一场热闹的局部最优。还有两个边界不能绕开。第一是代码与客户数据究竟交给了什么模型是否经过企业授权、隔离、脱敏和审计第二是夜间 Agent 到底能操作什么。主备切换、生产部署和数据修改都属于高影响动作权限应该最小化、过程可追踪、结果可回滚失控时还能迅速交还给人。自动化可以消灭等待不能消灭责任。05、这件事和每个人有什么关系对老板来说真正值得追问的已经不只是“能裁多少人”。如果效率红利只被用来收缩团队短期利润会更好看组织的知识更新、创新能力和风险冗余也可能一起被削薄。最健康的顺序是先让同一群人获得更大的业务边界再讨论哪些岗位需要重组。对中层管理者来说信息差正在快速贬值。以后还能留下来的价值会更接近机制设计、跨部门冲突处理、人才培养和关键决策。系统能催工单却很难替你决定哪个客户值得拒绝。对产品、交付和项目经理来说“把客户的话翻译给研发”不再是一条足够深的护城河。谁能进入真实现场发现用户没有说出口的问题定义可以验收的结果谁才不会被需求系统吞掉。对程序员来说单纯把代码写出来的价格还会继续下降。架构边界、领域建模、验证体系、疑难故障和安全责任会越来越贵。最危险的位置是既不定义目标也不掌握验收标准只在工单池里证明自己比 AI 多看出一个报错。测试和运维也不会简单消失。工作会从重复点击和夜间值守迁移到编写验收规则、故障剧本、权限策略、回滚机制以及处理系统从未见过的异常。AI 执行得越多验证者越需要理解全局。说到底生成能力正在迅速变成组织的公共资源。个人真正需要积累的是三个很难被平台收走的东西对真实业务的理解、判断结果是否可信的标准以及在复杂关系中推动结果落地的能力。未来最便宜的可能是“完成任务”最贵的是定义什么值得完成并有资格确认它真的完成了。昨晚散会以后我很久没有关电脑。我佩服这家公司把流程改得如此彻底也对那张从 175、90 最后指向 30 的路线图感到心情复杂。它可能是一家中小公司穿越成本周期的利器也可能提前展示了很多办公室岗位未来的样子。好的 AI Native 组织会把人从低效传话中解放出来让少数团队服务更大的世界。差的 AI Native 组织会把每个人切成一个可替换的责任节点系统负责思考人负责签字。两者使用的可能是同一套技术。区别只在于公司准备把效率红利分配到哪里。