AI 替代动作，不替代组织

本文是《人在回路中 Human in the Loop》系列第 5 篇。

从代码反推开始

第 5 篇不能从论文开始。

如果从“Wulf 团队提出了六种人-AI 协作模式”开始，读者很快会把它当成一篇术语科普。HOOTL、HOTL、HITL、HITP、HIC、HAM，六个缩写摆出来，看起来很完整，但企业负责人看完以后，还是不知道明天的组织会怎么开。

这篇要从代码开始。

某个内部增长系统里，有一类动作原本最容易被 AI 滥用：评论、私信、关注、加好友、跨平台建联。它们都不是“写一段文案”这么简单。它们会触达外部平台，会影响账号健康，会留下对客户和品牌的真实后果。

所以后来这类动作被放进一个高级写动作门禁里。

文档里写得很直：默认关闭；dry-run 只落审计和任务记录，不触达外部平台；real-run 只允许单条测试，必须二次确认、人工审批、账号健康通过、频控通过。代码里也有一个专门的确认 token：CONFIRM_REAL_RUN_SINGLE_TASK。

这不是一个技术细节。

这是组织设计。

因为它已经把三个问题写进系统里了：AI 可以做什么，人必须在哪一步出现，出了事以后谁能被追溯。

再看审批表。

系统里有一张 rpa_write_action_approvals 表，字段里有 action_hash、approved_by、expires_at。也就是说，审批不是群里说一句“可以发”，而是每一个动作都要有一条可追踪记录。action_hash 让同一个审批不能随便复用；approved_by 让责任不能散掉；expires_at 让批准不会无限期有效。

更狠的一句在代码底部：高级写动作如果不是从这个门禁创建，就直接拒绝。

这就是“人在回路中”真正落地时的样子。

不是在 PPT 上写“关键动作需要人工审核”。而是 AI 写动作要过什么门、谁能开门、开门多久、门后面留下什么日志，都已经被写进系统结构。

这也是第 4 篇之后必须进入第 5 篇的原因。

第 4 篇讲的是旧劳动契约断了。公司不再只买员工一天八小时，而是在买 know-how 注入度、判断力剩余和责任链。可这些东西如果不落到岗位、流程、知识、责任、治理上，它仍然只是一句新口号。

第 5 篇要做的，就是把这句口号摊成一张表。

这张表的横轴，来自 Wulf 团队 2025 年给出的人-AI 协作六模式。纵轴，是我把它翻译到组织设计里的五层：岗位层、流程层、知识层、责任层、治理层。

六种模式乘以五层，就是三十格。

但真正重要的不是“三十”这个数字。

真正重要的是：每一格都要回答一个具体问题。这个岗位里人在哪里？这个流程里 AI 跑到哪一步停？这份知识是给人看，还是给系统调用？这次失败是谁兜？这条权限是谁给的？

如果答不上来，“人在回路中”就只是安慰剂。

如果答得上来，它才变成组织设计。

Wulf 致敬与六模式

这里必须先把出处讲清楚。

Wulf、Meierhofer、Hannich 在 2025 年 7 月提交了一篇论文，arXiv 编号是 2507.14034。题目是 Architecting Human-AI Cocreation for Technical Services -- Interaction Modes and Contingency Factors。ZHAW 的资料页也能查到这篇论文。

这篇论文的价值，不是又说了一遍“人机协作很重要”。

它把人和 AI 的协作拆成六种模式，并把这些模式和任务复杂度、运营风险、系统可靠性这类因素连起来。换句话说，它不是在问“要不要人在回路中”，而是在问：人在什么位置，AI 在什么位置，什么情况下应该换一种位置关系。

这六种模式，先用普通话讲一遍。

第一种，HOOTL，Human-Out-of-the-Loop。

人不在回路。AI 从开始到结束全自动跑，人既不审批，也不监督。它适合低风险、重复、边界清楚的任务。比如标准化查询、固定规则触发、低后果的数据整理。

第二种，HOTL，Human-on-the-Loop。

人在回路外监督。AI 可以自己跑完整流程，人不逐步参与，但保留观察和干预权。它比 HOOTL 多了一层监督，但仍然不是每一步都过人手。

第三种，HITL，Human-in-the-Loop。

人在关键节点进回路。AI 先跑，遇到不确定、风险变高、需要取舍的时候，把问题升级给人。很多公司嘴上说“人在回路中”，实际指的就是这一类。

第四种，HITP，Human-in-the-Process。

人是流程节点。不是 AI 不确定时才找人，而是流程一开始就规定：某些关键步骤必须由人完成。前面那个写动作门禁，更接近这个模式。单条 real-run 必须二次确认、人工审批、账号健康通过、频控通过，人不是旁观者，是流程结构的一部分。

第五种，HIC，Human-in-Command。

这里要特别小心。HIC 不是 control 口径，而是 Human-in-Command。意思不是“人感觉自己掌控全局”，而是 AI 可以提出方案，但执行前必须由人批准。人在指令位，AI 是建议者。

第六种，HAM，Human-Augmented Model。

人主导任务，AI 做增强。AI 给信息、草稿、提醒、参考案例，但最终还是人完成判断和行动。很多知识工作者最早接触 AI，其实都从 HAM 开始。

这六种模式最有价值的地方，是它们让“人在回路中”不再是一个筐。

过去企业开 AI 会，常常把所有高风险动作都塞进一句话：关键动作要有人审。听起来稳，但落地时会乱。到底是人每一步都审，还是只在 AI 不确定时审？到底是人监督 AI，还是人批准 AI？到底是 AI 辅助人，还是人变成流程节点？

这几个问题不拆开，组织设计就会混在一起。

Wulf 团队的贡献，是先把横轴拆出来。

但这还不够。

六种模式只告诉你人和 AI 的位置关系，还没有告诉你这套位置关系怎么写进公司：岗位怎么改，流程怎么断点，知识怎么沉淀，责任怎么追溯，治理怎么关停。

这就是第 5 篇要继续往下翻译的地方。

从工作流推到组织设计层

这篇不能写成“Wulf 没做的，我来做”。

那样既不准确，也不体面。

Wulf 团队的论文很清楚：他们研究的是 technical services 里的 human-agent interaction，基于技术支持平台案例，抽出六种协作模式，再连接任务复杂度、运营风险、系统可靠性等因素。它的主场，是人和 AI 在工作流里的位置关系。

论文的第 12 页 future research 段也很清楚。

它没有直接说“组织设计层还没填”。它说的是：这些模式需要在真实运营环境里验证性能和可用性；组织文化和协作模式之间可能存在互相塑造的关系；未来还需要开发选择最优人-AI 交互模式的框架，把价值创造和安全风险放在一起权衡。

这几句话已经足够了。

它没有把岗位、流程、知识、责任、治理五层组织设计展开，但它已经把门打开了：六种模式不是论文里的术语，它们会进入真实运营环境，会影响组织文化，会改变员工接受度，也会迫使企业建立选择框架。

我的位置就在这里。

不是发明第七种模式，也不是把 Wulf 的论文改写成管理鸡汤。我要做的是把它往企业负责人的桌面上推一步：如果你接受六种模式，那你就不能只问“这段流程该不该有人工审核”。你要继续问：这个岗位该怎么改？这条流程的人工节点在哪里？这套知识是人读还是系统调用？这次失败谁签字？这个模式怎么治理？

所以第 5 篇的身位，是实证填表。

横轴用 Wulf 的六模式。

纵轴用五层组织设计：岗位、流程、知识、责任、治理。

这不是抢学术功劳，而是把学术框架拿到工程现场里走一遍。

HBR 2025 年那篇关于 AI 时代变革韧性的文章也在讲同一个压力：AI 不是只换工具，people、process、operating model 都会被推着变。传统路线图、年度规划周期、静态运营模式，在 AI 转型里会变成负担。

这句话放到 Wulf 矩阵里，就是很具体的提醒：

你不能拿静态组织去接动态协作模式。

如果一个流程今天是 HITL，三个月后模型稳定了，它可能变成 HOTL；如果一个任务看起来能 HOOTL，但一旦触达客户、钱、合规、品牌，它可能必须退回 HITP。组织如果没有岗位、流程、知识、责任、治理五层表，这些变化就只能靠人拍脑袋。

第 5 篇要解决的，不是让企业负责人背六个缩写。

而是给他一张可以开组织会的表。

6×5 矩阵全景

这张表不要一上来就画成三十格大表。

大表看起来完整，读者会晕。企业负责人真正需要的，不是先把三十格背下来，而是知道每一层到底在问什么。

第一层，岗位层。

同一个岗位，换一种人-AI 协作模式，岗位本身就变了。HOOTL 的岗位更像自动巡检；HOTL 的岗位更像监督员；HITL 的岗位是关键节点裁判；HITP 的岗位是流程里的必经关卡；HIC 的岗位是指令位；HAM 的岗位是被 AI 增强的专家。

所以岗位重写不能只写“熟练使用 AI”。

你必须写清楚：这个岗位的人，是被 AI 辅助，还是监督 AI，还是批准 AI，还是作为流程节点被系统调用。

第二层，流程层。

流程层问的是：AI 可以连续跑到哪里，必须在哪里停下来。比如一个低风险数据采集流程，可以接近 HOOTL；一个会触达外部平台的写动作流程，就不能直接自动化。内部增长系统里的高级写动作门禁，就是一个典型的 HITP 流程：系统可以准备任务，但 real-run 必须过确认、审批、账号健康和频控。

这不是“流程更慢”。

这是把责任写进流程。

第三层，知识层。

知识层问的是：知识是给人看的，还是给系统调用的。过去 SOP 是给新人看的。现在 Skill、prompt、规则库、检查表可以直接被 AI 调用。于是知识层也要分模式：有些知识只是辅助人判断，接近 HAM；有些知识变成系统规则，接近 HOOTL；有些知识必须由人批准后才能进入流程，接近 HIC。

这也是第 4 篇讲的劳动契约问题。

员工交出来的，不再只是文档，而是系统可复用能力。

第四层，责任层。

责任层问一句最朴素的话：错了谁赔。

HOOTL 出错，责任不能凭空消失；HOTL 出错，监督者有没有看见；HITL 出错，人是在什么节点接管；HITP 出错，流程里的那个人是否完成了必经判断；HIC 出错，批准者是谁；HAM 出错，是人的判断错了，还是 AI 提供的信息错了。

没有这一层，所有模式都会变成甩锅语言。

第五层，治理层。

治理层问的是：这套模式怎么开启，怎么暂停，怎么回滚，怎么审计。内部增长系统里，写动作不是一句“允许 AI 发出去”，而是有全局开关、任务类型开关、平台开关、persona 开关、账号开关和高级操作员权限。代码底部还有硬规则：高级写动作必须经过门禁创建，否则拒绝。

这就是治理层。

不是写一份《AI 使用规范》，而是把开关、权限、日志、审批、熔断写进系统。

五层合起来，才是 6×5 矩阵。

横轴告诉你人和 AI 的位置关系。纵轴告诉你这件事要落在组织哪里。三十格不是为了显得复杂，而是为了防止企业负责人把所有问题都塞回一句话：

“关键动作要有人审。”

这句话太粗。

有些动作不需要人审，有些动作只需要人在旁边看，有些动作必须每一步过人手，有些动作必须由人批准 AI 的建议，有些动作则是人主导、AI 辅助。

企业负责人真正要做的，是把这些差别写进岗位、流程、知识、责任和治理。

否则，第 4 篇讲的新劳动契约还是落不了地。

内部增长系统实证填表

我自己的工程里，最早也不是先拿着 Wulf 的六模式去画表。

我是反过来的。

先写门禁，先写审批，先写 real-run 的二次确认，先写哪些动作不能默认放开。后来回头看，才发现那些代码其实已经在替我填 Wulf 矩阵。

某个增长系统里，有一类动作我一直不敢直接交给 AI：评论、关注、点赞、收藏、私信、跨平台 pipeline。它们看起来只是运营动作，但只要一越过边界，就会变成账号风险、平台风险、客户风险、品牌风险。

所以系统里第一条规则不是“让 AI 更聪明”。

是写动作默认关闭。

真正进入 real-run 之前，要过二次确认，要有人审批，要看账号健康，要看频控。代码里甚至有一个很硬的确认 token：CONFIRM_REAL_RUN_SINGLE_TASK。这不是装饰。它的意思是：AI 可以建议动作，但它不能自己把手伸出去。

这就是 HITP。

人不是在最后看一眼结果。人是流程里的一个节点。没有这个节点，动作就不能继续往下走。

再往下看，责任层也不是一句“人工审核”。

系统有审批表，有 action_hash，有 params_snapshot，有 requested_by，有 approved_by，有过期时间。一次写动作，对应一次审批；一次审批，对应一份参数快照；一份快照，对应一个可追溯的人。

这就不是口头确认。

这是把“错了谁赔”写进数据库。

企业里很多 AI 项目最危险的地方就在这里。会上讲“人在回路”，流程图上画一个人工审核框，实际系统里没有 action hash，没有审批人，没有过期时间，没有拒绝路径。出事以后，每一层都能说自己只是按系统走。

那不是人在回路。

那是人在背锅。

再看岗位层。这个系统现在有 20 个 persona 席位，但真正 active 的只有 1 个 POC，另外 19 个还是 planned。这个数字我反而愿意写出来，因为它不漂亮。

它说明一件事：组织设计不是把名字写进 roster 就完成了。

一个 persona 只有写进流程、权限、知识、责任和治理，才算插电。否则它只是一个设计稿，一个将来可能有用的壳。

这和企业做 AI 岗位是同一个问题。

你可以一天之内把十个岗位改名：AI 运营、AI 产品、AI 销售、AI 财务、AI 客服。PPT 上看起来很完整。但如果这些岗位没有对应的判断边界，没有工具权限，没有验收标准，没有失败回滚，它们就不是新组织。

它们只是旧岗位换了新皮。

所以 6×5 矩阵不是为了画一张漂亮表。它真正要企业负责人做的，是把每个格子逼到工程问题上：

岗位层，谁真的插电了，谁只是 planned。

流程层，哪些动作能自动跑，哪些动作必须人过手。

知识层，哪些经验已经沉到规则和模板里，哪些还在人的脑子里。

责任层，哪一次动作能追到批准人，哪一次只是“系统自动”。

治理层，哪些权限默认关闭，哪些权限可以在什么条件下打开。

我越来越相信，组织升级不是从口号开始的。

它从一条拒绝路径开始。

如果 AI 没有被允许做这件事，系统能不能拦住它。如果人没有批准这件事，动作能不能停下来。如果出了问题，组织能不能知道是哪一次参数、哪一个流程、哪一个人、哪一条规则出了问题。

这才是矩阵的实证填表。

不是说“我们用了 AI”。

是说 AI 被放在什么位置，人被放在什么位置，责任被放在什么位置。

中文圈应用边界

Wulf 这套框架不是我一个人在看。

我本地材料里已经看到中文案例研究引用 Wulf 的人机协作框架，并且展开了六种模式。这件事值得提一句，但只能提一句。

原因很简单：这是下游应用信号，不是本篇的承重证据。

更重要的是，那份材料本身还有边界风险。研究笔记里已经标出，第七章末尾出现过 AI 生成提示的痕迹。这样的材料不能拿来做学术背书，更不能拿来当权威引用。

所以公开稿里，我不会点名，不评价论文质量，也不写成“国内已经验证”。最多只写：

中文圈已经有人开始引用 Wulf 框架。这说明它不是孤立术语，而是正在被不同场景拿去解释人机协作。

这句话的作用，是给读者一个位置感。

Wulf 在学界给了六模式光谱。中文案例研究开始把它拿去解释具体服务平台。我这篇文章要做的，是把它再往前推一步：从服务场景推到组织设计。

这三层不能混。

第一层，是 Wulf 的论文。它负责学术框架。

第二层，是中文案例研究。它负责说明这套框架已经有下游应用信号。

第三层，是我自己的工程和组织拆解。它负责把六模式推到岗位、流程、知识、责任、治理五层。

如果把第二层写成第一层，就会失真。

如果把第三层写成原创理论，也会失礼。

本篇真正的身位不是“发明者”，也不是“评论者”。更准确的说法是：工程翻译者。

我把 Wulf 的工作流光谱翻译成企业负责人能拿去开会的组织设计表。翻译得对不对，不看词好不好听，要看能不能回答几个很具体的问题：

这个岗位里，哪些动作可以自动化？

这个流程里，哪些节点必须人审？

这类知识，是沉到系统里，还是继续留在老员工脑子里？

这次动作，如果错了，谁签过字？

这条权限，是默认打开，还是默认关闭？

中文圈应用信号的价值就在这里。它提醒我，Wulf 不应该被写成一个漂亮术语。它已经进入真实场景了。既然进入真实场景，就必须接受真实场景的压力：业务会出错，客户会投诉，系统会误判，人会离职，老板会裁人，流程会断。

所以我不会把这套框架写成“六种模式科普”。

科普没有用。

企业负责人不缺术语表。他缺的是一张能逼自己做决定的表。

哪一格交给 AI。

哪一格留给人。

哪一格必须人机混合。

哪一格现在只是 planned，不能拿去对外吹。

这才是中文场景真正需要的东西。

企业负责人怎么开组织会

Cloudflare 这个案例之所以刺眼，不是因为它裁了 1100 多人。

也不是因为它计划招 1111 个实习生。

真正刺眼的是，它把一号位在 AI 时代必须面对的问题公开摆到台面上：公司不是买了 AI 工具就结束了，公司结构本身要重写。

Cloudflare 官方说，过去三个月内部 AI 使用增长超过 600%，员工每天运行大量 agent sessions。它也说，这次动作不是个人绩效问题，不是简单成本削减，而是重新想象内部流程、团队和角色。

这句话如果翻译成企业负责人听得懂的话，就是：

AI 替代动作，不替代组织。

一个不懂组织的一号位，最危险的不是不会用 AI，而是把 AI 的动作能力误读成组织的替代能力。

AI 能写代码，不代表它懂上线。

AI 能回客户，不代表它能修复信任。

AI 能生成方案，不代表它能为后果负责。

有的老板自己用 AI 手搓了一个网站，就开始觉得工程团队是不是可以少要一点。

这不是懂 AI。

这是把 demo 当生产系统，把动作能力当组织能力。

更危险的是，demo 越顺，他越容易误判。

因为页面能跑，不代表架构能扛。

功能能点，不代表权限、日志、回滚、监控、故障恢复和客户责任链都存在。

你绕过人的同时，如果也绕过了责任链、知识链和故障恢复链，这个组织不是更先进了，是更脆了。

这不是反 AI。

这是反无组织替代。

Klarna 的客服回摆已经提醒过一次。AI 可以处理大量低复杂度对话，但客户支持不是只有回答。它还有安抚、例外判断、信任恢复。成本账算得太单线，服务质量会回来找你。

Replit / PocketOS 的删库事故又提醒一次。AI agent 能写代码，能调用工具，但当它碰到生产权限，错误就不再是文本错误。它会变成数据、客户、法律、恢复成本。

Builder.ai 的故事再提醒一次。软件交付不是“生成一个页面”。它背后是需求、架构、测试、运维、客户交付和责任链。你把这些东西包装成 AI 魔法，最后还是会被真实交付拆穿。

所以企业负责人开 AI 组织会，第一张表不应该是“哪些岗位可以裁”。

第一张表应该是判断流。

把一项工作摊开，逐格问：

哪些动作可以 HOOTL，完全自动跑？

哪些动作只需要 HOTL，AI 跑，人站在外面看异常？

哪些节点必须 HITL，由人做关键拍板？

哪些步骤必须 HITP，每一步都过人手？

哪些任务应该 HIC，AI 只能提方案，执行前必须由人批准？

哪些场景只能 HAM，人和 AI 混合作业，互相补位？

这不是术语训练。

这是组织会议议程。

第二张表，是权限流。

AI 能不能读客户数据？能不能写数据库？能不能发消息？能不能改价格？能不能触发退款？能不能关停账号？每一个“能不能”，背后都不是技术选择，而是责任选择。

第三张表，是异常流。

AI 出错以后，谁先发现？谁有权停止？谁能回滚？谁通知客户？谁承担解释？谁把这次错误写回知识库？

第四张表，是知识流。

老员工脑子里的判断，哪些要沉到规则里，哪些要沉到模板里，哪些只能通过师徒制、复盘和案例库慢慢迁移？新人会用 AI，不代表他能承接隐性知识。AI-native 不是组织免疫力。

第五张表，是责任流。

每一次 AI 动作，能不能追到输入、模型、规则、审批人、执行人、结果和复盘？如果不能，你不是在自动化，你是在把责任打散。

这五张表摊开以后，企业负责人再谈裁员，才有意义。

否则你以为自己裁掉的是成本，实际裁掉的是公司的自我修复能力。

这也是为什么“人在回路中”不是一句温和的管理口号。

它是一套硬约束。

人不是为了显得有人情味才留在回路里。人是为了让判断、责任、异常和恢复能力不从组织里掉出去。

钩到判断溢价

第 4 篇讲旧劳动契约断了。

第 5 篇讲断了以后，岗位怎么重新接线。

但接线之后，还有一个更狠的问题：留下来的人，凭什么更贵？

这就是第 6 篇要讲的判断溢价。

如果 AI 能做更多动作，人留下来的价值就不应该继续按动作计价。过去一个人贵，是因为他能做很多事。以后一个人贵，可能是因为他知道哪件事不能让 AI 做，哪一步必须停下来，哪一个异常意味着整条链路要重画。

这和“人比 AI 有温度”没关系。

温度不能进损益表。

企业负责人真正要算的是：一个人的判断，能不能降低事故半径，能不能减少返工，能不能保住客户信任，能不能让组织少犯下一次错。

所以 6×5 矩阵不是终点。

它只是告诉你，人在哪。

第 6 篇要回答的是：人在那个位置上，为什么值钱。

岗位层里，值钱的不是“这个人还在岗”，而是他能不能定义 AI 不能越过的边界。

流程层里，值钱的不是“这个人还要审批”，而是他能不能在关键节点看出错误方向。

知识层里，值钱的不是“这个人经验丰富”，而是他的经验能不能沉淀成下一次可复用的判断。

责任层里，值钱的不是“这个人愿意背锅”，而是他能不能把责任提前写进系统，而不是事后补救。

治理层里，值钱的不是“这个人懂 AI”，而是他能不能决定哪些权限永远不能默认放开。

这就是判断溢价的入口。

AI 越便宜，动作越不值钱。

动作越不值钱，判断越贵。

但不是所有人的判断都会变贵。只有那些能被放在关键节点上、能承担后果、能把经验写回组织的人，才会变贵。

所以这一系列文章到这里，其实已经从“AI 替代人”走到了另一个问题：

AI 之后，什么样的人更值得留下？

答案不是“会用 AI 的人”。

会用 AI 只是入场券。

真正值得留下的人，是能把 AI 放进正确位置的人。

他知道哪里可以自动化，哪里只能建议，哪里必须人审，哪里要默认关闭，哪里一旦出错必须马上回滚。

企业负责人如果看懂这一点，AI 不是裁员刀。

AI 是组织重写工具。

如果看不懂，AI 就会变成一把很快的刀。它会先砍掉看得见的成本，然后慢慢砍掉看不见的判断、责任、知识和恢复能力。

下一篇，就讲这个更贵的东西。

不是人的岗位溢价。

是人的判断溢价。

---

继续读

• 上一篇：新劳动契约
• 系列入口：人在回路中：Human in the Loop
• 下一篇：判断溢价