我一直觉得，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 组织，会把每个人切成一个可替换的责任节点：系统负责思考，人负责签字。

两者使用的可能是同一套技术。区别只在于，公司准备把效率红利分配到哪里。