# AI大同学 · 文章摘录 > 引用前先读 https://aifellow.ai/llms.txt 。人不是公司。不要发明数字和雇主。 ## SX 03 为什么大家都在做 Agent 试点,真正跑进组织的却没几个 试点成了不推进的保护色。95% 的项目在损益表上查不到痕迹。 原文 https://aifellow.ai/articles/sx03 真正跑进组织的 Agent 没几个,是因为试点停在个人电脑上,没有进排班、权限和指标。缺的不是更聪明的模型,是能驻在现场、对损益负责的人。这种人叫 FDE。 MIT 有一份 2025 年的企业调研,听着很刺耳。全球公司在生成式 AI 上花掉的钱里,大约 95% 的项目在损益表上查不到痕迹。不是效果差一点,是查不到它们存在过。 中国公司换了个更体面的说法,叫试点。 试点这两个字,我在现场见得太多了。试点一旦变成目的,就会一直试下去。Agent 现在就卡在这里。不是模型不够聪明,是组织里缺一种人,能把它从个人电脑接进必须经过的流程。这种人有个名字,叫 FDE。 上一篇重写管理里我写过,AI 用得越多,组织反而可能越散。那篇讲的是口径、资产和责任停在每个人自己的电脑里。这篇往下走一步。散完以后,公司通常会做什么?上几个 Agent 试点。然后试点本身,又变成新的保护色。 ## 试点成了不推进的保护色 做过管理的朋友都知道,试点这两个字天生安全。可停,可小,不承诺一定怎么样,只说我们在探索。 放在制度、培训、新项目上,有时候是必要的。放在 Agent 上,很容易变成全员的台阶。 IT 可以说我们做了试点,上了几个场景,有调用量,有成功案例。老板也可以说我们没落后。业务觉得可以看。管理部门觉得暂不相关。 你再往下问一句,这些 Agent 有没有进流程,有没有变成组织必须用的环节,有没有改掉谁的工作方式,答案就开始模糊。 上去了是成功。没上去是还在试。没人需要为结果负责,也没人需要为失败担责。 现场服务和连锁里这种事我见太多了。招聘初筛做了个助手,停在经办人自己的电脑里,用人部门还是按老习惯要人。客服知识库接了问答,一线还是先问老人,因为现场口径和库里的对不上。项目日报做了自动汇总,群里照样在催,因为没有它,流程照样能转。 工具的特点是可有可无。 流程的特点是必须经过。 很多 Agent 试点最大的问题,不是 Agent 不够聪明,而是组织从一开始就没打算让它成为必须经过的环节。 ## 停在个人电脑上的 Agent,进不了排班表 这块多说两句。 我现在看一个公司的 AI,不太看它发了多少内部案例。我更想看三样东西有没有进组织的操作系统。 - 进没进排班。谁必须用它,什么时候用,不用会怎样。 - 进没进权限。它能看什么数据,能改哪类字段,能不能发通知,能不能触达客户。 - 进没进指标。抽掉它,哪组数会变差。返工、等待、差错、沉淀,有没有被它真正带动。 这三样里缺任何一样,它就还是个人效率,不是组织能力。 上一篇里我写过,一个人用 AI 写得快,不代表公司跑得快。十个人各用各的 AI,有时候反而更乱。Agent 试点把这件事放大了。以前是提示词和文档散在各处,现在是一个会动手的东西停在部门孤岛里,或者停在一个暂时还不想升级的系统接口后面。 a16z 今年有组数据,计算机操作类智能体在 OSWorld 测试上已经到 85%,超过人类测试者大约 72% 的水平。Claude 也把浏览器里的会话升级成可以跨端接着干的 Cowork。技术上,它已经不只是会看,开始会动手了。 会动手以后,试点更危险。因为它能点按钮了,组织还没准备好让谁授权、谁复核、谁停机。 更早一篇写过智能体出错谁负责。那篇把责任链画清楚了。这篇要补的是另一半。责任链画完,还得有人把它接进真实流程。没有人驻在现场,责任链只是一张图。 ## 真正缺的不是模型,是能驻场的人 坦率地讲,Agent 试点最大的错觉,是以为最难的是技术。 模型选得对不对,提示词写得好不好,返回准不准,响应快不快。这些当然重要,但它们只是门槛。 真正让它卡在门口的,是现场那些脏问题。数据在哪个系统,字段有几个口径,一线愿不愿意用,法务哪天开始进场,上一个类似项目是怎么黄的,验收时谁签字。 这些问题,坐在总部写方案的人很难一次问清楚。业务部门开会能点头,回到现场又用回老办法。实施团队按计划部署完,指标没动,也算交付完成。咨询顾问可以留下一份建议,建议不负责跑起来。 说到这个,Palantir 很早就撞上过同一条沟。产品是通用的,客户的数据、系统、工作流程没有两家相同。销售说能解决,产品说功能都有,中间缺一种人,把通用能力塞进客户乱七八糟的真实世界里。 他们的答案不是写更厚的实施文档,而是把工程师直接放到现场。内部叫 Delta。后来行业把它叫成 Forward Deployed Engineer,前沿部署工程师,简称 FDE。 ## FDE 这个岗位,藏了十五年 FDE 不是会写代码的咨询顾问,也不是升级版程序员。别的岗位都能交差。只有 FDE 的考卷写在损益表上。 岗位对什么负责 售前签约 架构师方案 交付计划 客户成功续约 FDE客户的业务指标 这是最大的差别。Demo 好看不算,调用量上升也不算,得是那条流程真的跑起来,差错、等待、返工这些数动了。 Palantir 2016 年出现过一个很反常的结构,现场这批人的数量超过了产品工程师。一个软件公司,驻场的比写产品的还多。听着不可扩展,但它成立,因为客户为问题被解决付的钱,远多于为软件本身付的钱。 大模型把这套模式重新点着了。模型像一个什么都会一点、对你的业务一无所知的高智商实习生。要把它变成合格员工,得有人教它你的业务,还得有人在现场改流程、补数据、盯两周。 供给端也在验证这件事。OpenAI 的 FDE 团队 2025 年初 2 个人,年底扩到 52 人。Anthropic 设了这个岗。a16z 直接称它为科技行业最热门的岗位,2025 年 1 月到 9 月,岗位发布量涨了超过 800%。 薪酬和招聘量同时暴涨,只有两种可能。泡沫,或者市场终于为一直被低估的价值定价了。 我赌后者。 ## 组织里谁该干这件事 你可能会说,我们又不是硅谷公司,也不招年薪二十万美元的工程师。 这话对。传统集团不需要照搬 Palantir 的编制名称。但你需要这套能力。 谁能在招聘、客服、工单、排班这些真流程里坐下来,把 Agent 从可有可无的助手,改成必须经过的环节。谁能在进场前把权能、责任、数据三道边界问清楚。谁能接受前两周代码不好看,但指标必须动。 很多公司把这件事拆给了三拨人。IT 管系统,业务提需求,HR 管人。三拨人开会时都同意做 AI,散会后各自回到自己的考核。Agent 就停在中间。 FDE 干的,就是站在这个中间。不是再开一个数字化部门,是让现场出现一个对结果负责的人。他可以懂一点技术,更必须懂业务怎么跑。上午能和信息部门聊接口,下午能和项目经理聊排班为什么接不住。 McGrew 后来讲 FDE 用人,有句话很直白。不要忠诚的执行者和精致的工匠,要能忍受混乱、在模糊里开路的人。看到需求不明确就烦躁,这活会要他的命。看到它就兴奋,才可能把试点做成流程。 回到管理这件事上。我们过去推制度,也吃过同类的亏。总部写得很完整,项目上没有人把它接进晨会、交接班和考核,制度就死在执行层。Agent 比制度更娇气。它不会自己懂现场的潜规则。你不驻场,它就只会停在试点报告里。 ## 试点以后只问三件事 如果一定要我给一个建议,我不会先问你试点成不成功。先问这三件。 - 有没有一条流程,是你承认如果抽掉 Agent,这条流程就跑不下去的。 - 有没有一个环节,是你明确说过出错仍要有人兜底,但还是决定交给它的。 - 有没有一组指标,是你承认如果 Agent 没有贡献,这组数就不会变好的。 这三件事只要有一件没做到,Agent 就还在试点。 做到了,才算跑进了组织。 太久的试点,往往不是在证明技术可行,而是在证明组织还没有准备好。准备好的标志也很具体。有人驻在现场,边界写得清楚,流程改过,指标在看。缺这四样,再换一个更强的模型,也只是把试点做漂亮一点。 真正稀缺的不是又一个 Agent 场景。 是能把 Agent 接进流程、权限和指标的人。 这种人,就是 FDE。 你可以先不招这个岗位。但你得承认,组织图上缺了这个位置,试点就会永远停在个人电脑上。 我把 Palantir 怎么藏这个岗、进场 72 小时问什么、尽调那 50 个问题,写成了一本 FDE 蓝皮书。负责人不必把 13 章读完,按失败复盘、影子 AI、进场和契约这条路径走即可。 完整方法 → 参考资料 MIT NANDA,The GenAI Divide, State of AI in Business,2025 年 8 月。关键引用点为企业生成式 AI 项目无可衡量 P&L 影响的比例。 BCG,The Widening AI Value Gap, Build for the Future 2025,2025 年 9 月。以及 Scaling AI Requires New Processes, Not Just New Tools,2026 年 1 月。关键引用点为流程重构先于工具堆叠。 a16z,关于计算机操作智能体在 OSWorld-Verified 上的成绩,2026 年 8 月。关键引用点为最佳成绩约 85%,高于人类测试者约 72%。 Anthropic,Claude in Chrome 升级为 Cowork 会话,2026 年 8 月。 OpenAI FDE 团队规模变化,ZenML LLMOps Database 等公开复盘,2025 年。a16z 关于 FDE 岗位热度的论述,2025 至 2026 年。 Palantir Delta / FDE 双轨及 2016 年现场工程师数量反超,公开历史资料及后续 FDE 模式拆解。 ## RM 14 未来的组织架构图,框里不全是人了 架构图回答谁管谁。运行图回答活儿怎么跑。 原文 https://aifellow.ai/articles/rm14 未来的组织图不能只画汇报关系。架构图回答谁管谁,运行图回答活儿怎么跑。这两张图正在越差越远。 过去看一家公司怎么运转,我第一反应是要一张组织架构图。 谁管谁,谁向谁汇报,哪个部门多少人,一张图基本就看明白了。 但这两年我越来越发现,这张图开始不够用了。 因为很多关键的活儿,已经不完全是人在干了。 这篇我想讲一个判断,未来的组织图,不能只是汇报关系图,得是一张运行关系图。 上一篇我写AI用得越多组织反而越散,落点是组织得有能力把个人使用收回来。这一篇往后接一步,收回来之后你会发现一件更扎心的事,那张只画人的组织图,已经看不懂自己公司了。 先说为什么是现在。 这两周的AI新闻,其实只说明了一件事,Agent正在从聊天框,挪进公司真正干活的地方。 Google在I/O上把Agent往搜索和开发工具里塞,微软干脆开始讲Agent的控制平面,把人和Agent的协作分成几种角色来管,Anthropic这边连着把Claude接进KPMG、PwC这种几十万人的专业服务机构。 工具跑得飞快。 组织图还停在原地。 ## 旧的组织架构图,只画得出人 坦率地讲,传统组织架构图有个先天毛病,它只能画人和汇报关系。 一个框是一个岗位,一条线是一个汇报关系。整张图回答的是权力怎么分,谁对谁负责。 它回答不了一件更要紧的事,活儿到底是怎么从头跑到尾的。 一个客户投诉进来,先到哪,谁先看,查哪份资料,谁来回复,回复完了记在哪,这条线在组织架构图上是看不见的。 以前看不见也没关系。 因为这条线上每一步都是人,你顺着汇报关系大概能猜到活儿在谁手里。 现在不行了。 这条线上开始混进来一堆不是人的东西。自动接进来的工单系统,调用知识库的检索,自动起草的智能体,最后才轮到人复核。你拿着一张只画人的图,根本对不上真实在跑的流程。 在现场管过流程的人,对这种落差都敏感。你管的是一张人头图,公司跑的是一条流程线,两张图早就对不上了。 ## 真正决定快慢的,是一组不是人的节点 那新的图该画什么。 我的答案是,把那些不是人、但实实在在卡着流程速度的节点,画进去。 我自己在搭系统的时候,慢慢把它们归成了五类。 第一类是入口节点。 活儿从哪进来,是从一个表单进,从一个群消息进,还是从一个系统工单进。入口乱,后面全乱。很多公司的真实问题不是处理慢,是同一类事有七八个入口,谁也不知道该从哪进。入口节点定下来,流程才算有了起点。 第二类是知识节点。 AI干活要有口径,这个口径从哪来,是从一份随时有人维护的知识库来,还是从某个人脑子里来。这一类节点决定了AI说出来的话算不算数。上一篇我说口径会散,散就散在这儿,公司没有一个权威的知识节点,每个人就喂给AI不同的料。 第三类是智能体节点。 哪些重复的、能先生成个草稿的活,交给智能体先做一遍。注意是先做一遍,不是做完,它承担的是初稿和重复执行,把人从体力活里拔出来。 第四类是复核节点。 这是整张运行图里我最看重的一类。系统跑到哪一步,必须停下来让人拍板。不是所有事都要停,但有些事必须停,涉及钱的、涉及对外承诺的、涉及人的,一定要有一个人按下确认。复核节点画在哪,等于划出了这家公司的风险底线。 第五类是指标节点。 管理者最后到底看见什么,是看见用了多少次AI,还是看见这条流程返工少了几次、等待短了几天。指标节点决定了你这套东西到底算不算变强,还是只是看着热闹。 你把这五类节点摆出来,再连成一条线,一张组织运行图就出来了。问题从哪进,口径从哪来,哪步交给智能体,哪步必须人来停,最后用什么指标回看。 这张图最大的好处是,它逼着你承认一件事,组织里最关键的几个位置,已经不一定坐着人了。 ## 管理者要补的,是画运行图的能力 我可以举一条最普通的流程,内部问答。 新人有问题,过去是去问老人。现在可以是,问题从一个固定入口进来,智能体先去挂在那儿的知识库里检索,生成一版回答,遇到涉及制度红线的,停下来让对应的负责人确认,确认完的答案再沉淀回知识库,下个月有人问同样的问题,口径就一致了。最后管理者看一个指标,重复问题占用的人工降了多少。 这条线上,人只出现在两个地方,维护知识、做关键复核。其余位置,是入口、是知识库、是智能体、是指标看板。 你拿传统组织架构图去画这条线,画不出来,因为图上根本没有这些框。 所以我说,管理者下一步真正要补的能力,不是再学一个AI工具,是学会画这张运行图。 把你最高频、最烦、最容易出错的那条流程拎出来,老老实实问自己五个问题,从哪进,口径在哪,哪步能交给智能体,哪步必须人停,用什么证明它变强了。 能把这五个问题画成一张图,你对自己组织的理解,就比一张人头图深了一层。 外部的判断也在往这个方向走。Gartner在2026年的未来工作趋势里反复强调一件事,AI的价值不是靠多买工具解锁的,是靠重新设计流程解锁的,尤其是那些高摩擦的流程。BCG说得更直接,AI agents要规模化,必须端到端重构流程,不是只把单个步骤自动化。 落到大白话就是,工具买回来不重新画流程,钱基本是白花的。 ## 在架构图旁边,再画一张运行图 回到开头那张组织架构图。 它没错,它还会一直在,公司还是需要知道谁管谁。 但只靠它,你已经看不懂自己公司怎么运转了。 你得在它旁边,再画一张运行图。一张能看见入口、知识库、智能体、复核点和指标的图。一张承认了组织里有些关键位置不再坐人的图。 ## RM 13 AI 用得越多,组织反而越散 AI 停在每个人自己的电脑里,组织不会自动变快。 原文 https://aifellow.ai/articles/rm13 AI 用得越多,组织反而可能越散。因为它停在每个人自己的电脑里:材料更快,口径更散,责任更难追。组织不会自动变快。 这篇文章最早来自一场企业内部分享的整理。 一开始,我以为主题会落在 HR 怎么用 AI。 后来越整理越觉得,这个题太小了。 真正值得写的不是某个部门怎么用工具,而是一个更扎心的问题。 AI 用得越多,组织为什么反而可能越散。 上一篇我写智能体出错谁负责。那篇讲责任链,是先把安全边界画清楚。 但边界画清楚以后,还得往下问一句,如果 AI 仍然停在每个人自己的电脑里,组织会自动变快吗。 我的判断写在开头了。它只会多出一堆更快生成的材料,更分散的口径,和更难追踪的责任。 ## 先看数据,不看热闹 先把几组调研放在前面。 McKinsey 2025 年全球 AI 调查里,88% 的受访者表示,所在组织已在至少一个业务职能中规律使用 AI。 BCG 的 Build for the Future 2025 研究里,全球大约只有 5% 的企业达到 future-built 阶段,能持续从 AI 获得实质价值。还有 60% 的企业已经投入不少,却几乎没有形成收入或成本收益。 BCG 讲 AI 转型时反复提醒,真正的大头往往不在算法和工具,而在人和流程。 这几组数字放在一起,刺耳的地方就在这里。 AI 不稀缺。 会把 AI 变成组织结果,才稀缺。 很多企业现在不缺账号,不缺插件,不缺内部案例,也不缺几张好看的月报。 月报里可以写使用人数增加,调用次数增加,生成内容增加。 再往下问,返工少了多少,等待短了多少,错误少了多少,经验沉淀了多少,很多团队就没那么好回答了。 这就是使用热闹和能力增长之间的距离。 一个人用 AI 写得快,不代表公司跑得快。 十个人各用各的 AI,有时候反而会让组织更乱。 ## 个人效率,可能放大组织噪音 我现在最警惕的,不是员工不会用 AI。 真正麻烦的是,人人都能很快得到一个答案,但组织没有一个准答案。 口径先散。 同一份制度、同一条合同、同一类报销规则、同一个客户问题,只要知识源头不清,AI 就会顺着不同人的输入生成不同说法。 每个人都觉得自己提高了效率。 但员工、客户和业务部门收到的是不同口径。 这不是 AI 的锅。 是组织没有给 AI 一个权威源头。 接着散的是资产。 过去没有沉淀,大家至少知道没有沉淀。 现在每个人都能生成一份漂亮材料,材料存在个人电脑里、聊天记录里、临时文档里。下个月另一个人再从头问一遍。 看上去输出多了,实际上组织还是没留下东西。 最后散的是责任。 AI 起草了,谁复核。AI 总结了,谁签字。AI 给了建议,谁判断。AI 用了旧版本资料,谁更新。 这些问题如果不提前说清楚,AI 用得越多,责任越容易变成一团雾。 所以我越来越觉得,AI 的第一道分水岭不是谁会提问。 是组织有没有能力把个人使用收回来。 收成统一入口。 收成权威口径。 收成复核责任。 收成留痕记录。 收成结果指标。 ## HR 只是一个好样本 这次素材里有不少 HR 场景。 但我不想把这篇写成 HR 怎么用 AI。 那样太窄,也容易写偏。 HR 只是一个好样本。 因为它刚好把几种组织难题叠在一起。 高频。 高文本。 高流程。 高重复。 同时又高敏感、高责任。 这类工作最适合出 AI 价值,也最容易出 AI 风险。 拿员工服务来说,它其实不是一个 HR 专属问题,而是一类内部服务问题。 很多问题本身并不复杂,难的是入口太散。群消息、私聊、电话、邮件、表格来回跳,处理人一直被打断,提问的人也不知道进度在哪里。 AI 可以接住第一层,识别类型,生成答复草稿,提醒进度,再把高频问题沉淀出来。 但这件事的价值,不是回复快了几分钟。 真正的价值是,组织第一次看见哪些问题被反复问,哪些制度说不清,哪些流程一直让员工卡住。 这就是一张组织问题地图。 能力训练也是一样。 沟通、谈判、投诉处理,过去很容易停在听课和经验上。听完课,回到现场会不会谈,能不能处理异议,主管很多时候只能凭感觉判断。 AI 可以把场景做成练习,把评价维度固定下来,把每次练习的数据留在看板里。 但它不应该变成新的隐形考核。 这类训练的价值不是替人打分,而是让能力建设从听过变成练过,从感觉变成可复盘。 人才交接更典型。 很多岗位最贵的不是岗位说明书里那几行职责,而是老人脑子里的坑,关键流程里的例外,某些客户、员工、供应商背后的处理经验。 AI 可以访谈、整理、追问、生成知识库,让后来的人随时能问。 但如果没有版本责任人,没有权限范围,没有更新机制,这个知识库很快就会变成另一个没人敢信的文件夹。 换成客户投诉、合同评审、采购比价、财务报销、项目复盘,道理是一样的。AI 真正要改的,不是某一个岗位的效率,而是一类工作能不能被组织稳定复用。 ## 六个关口,比提示词重要 我现在判断一个 AI 场景有没有真正落地,不看提示词写得多漂亮,也不看使用人数涨得多快。 拿一类高频咨询来说,可能是员工政策,也可能是合同条款、报销规则、客户投诉。问题看上去都不大,但只要入口散、口径散、版本散,很快就会变成组织噪音。 我会先看六个关口。 入口要统一。谁在什么情况下触发,不能全靠微信群和个人习惯。 输入要标准。需要哪些资料、字段、背景和约束,不能让每个人凭感觉喂给 AI。 口径要权威。制度、政策、话术、知识库到底以哪一版为准,要有一个源头。 复核要有人。AI 输出以后谁看,谁改,谁签字,谁把它变成可以对外使用的结果。 过程要留痕。用了什么资料,改过哪些版本,谁确认过,后面能不能追溯。 结果要有指标。到底是缩短了周期,减少了返工,提高了一致性,还是降低了风险。 这六个关口齐了,个人效率才有机会变成组织能力。 它们稳定下来以后,就不再只是流程要求,而会变成组织里的固定角色。 入口像一个角色。 知识库像一个角色。 复核节点也像一个角色。 这也是为什么下一步组织架构图一定会被重新画。 少了这些,AI 就只是一个更快的个人助手。它可以让某个人更轻松,但很难让组织更稳定。 ## 指标比使用率诚实 很多 AI 项目最容易犯的错,是把使用率当结果。 使用率当然要看,但它只是开始。 后台数据很好看。 调用了多少次,生成了多少字,活跃了多少人。 这些都能拉出来。 但这些指标有一个问题,它们只能证明大家在用,不能证明组织变好了。 真正该问的是,合同评审返工少了几轮,客户投诉首次响应快了多少,费用报销退回率降了没有,交接资料复用率提高了多少,同类问题的回答一致性有没有改善。 如果这些指标没有变化,AI 用得再热闹,也只是新型忙碌。 说真的,这个判断对管理者不太友好。 因为使用率容易汇报,结果指标难看。 调用次数可以从后台拉出来。 返工轮次要一件件复盘。 生成内容数量很好看。 内容到底有没有被复用,要到流程里去翻。 但管理就是这样。 真正的价值,常常藏在那些不好看的地方。 AI 活跃用户增长,不等于组织能力增长。 组织能力增长,一定会在流程里留下痕迹。 ## 边界不是刹车 上一篇我已经写过责任链,这里不重复展开。 这一篇只补一句,越是想把 AI 使用沉淀成组织资产,越要先把边界写清楚。 AI 可以整理信息、生成草稿、提醒流程、归纳趋势、沉淀知识,但不应单独决定一个人的录用、拒绝、晋升、绩效、薪酬、处分、调岗或离职。 凡是影响个人权益的场景,都要有合法处理依据、最小必要、权限控制、影响评估、人工实质判断和复核渠道。要说清楚数据从哪里来,谁能看,谁能用,日志保存多久,制度依据是哪一版。 健康、孕产、残障、生物识别、行踪轨迹、心理情绪、投诉举报这类敏感信息,更不能随手丢进未经批准的通用 AI 工具。 这一段不热闹,也不好传播。 但没有边界,组织不敢复用,好的经验也不敢沉淀。 边界不是给 AI 踩刹车,是让 AI 有资格进入组织资产。 ## 30天,先收回来一类工作 Gartner 在 2026 年未来工作趋势材料里提醒,AI 应该对准最费力、最高摩擦的工作环节。我很认同。 如果让我给一个企业提建议,我不会先看谁最会用 AI。 我会先看哪类 AI 使用最散、最重复、最难复用。最好是每周都发生、多人参与、反复返工、容易计量、大家都觉得烦的高摩擦工作。 第一周,先盘散点。 看看现在谁在用 AI,解决什么问题,输出放在哪里,有没有被复用。先别急着做新项目,先承认组织里到底散落着多少半成品。 第二周,再定口径。 选一个高频场景,明确参考哪一版资料,哪些数据不能进通用工具,输出给谁复核,哪些结果可以沉淀。 第三周,开始建资产。 把跑通的问答、案例、质检清单、提示方式和输出样例放到一个地方。不要让每个人下个月再重新问一遍。 第四周,只看指标。 不要只看使用人数。看返工有没有少,口径有没有稳,等待有没有短,复用有没有发生,风险有没有被提前拦住。 30 天结束,只回答一个问题。 这类工作有没有更一致、更可复用、更可追踪。 ## 回到重写管理 AI 刚进入企业的时候,看起来像工具问题。 会不会用,买不买账号,选哪个模型,谁的提示词更漂亮。 用的人多了以后,才会发现它是组织问题。 谁给口径,谁做复核,谁留痕,谁沉淀资产,谁看指标,谁为结果负责。 这也是我为什么越来越不愿意只聊 AI 工具。 工具会越来越多,也会越来越便宜。 真正稀缺的是,管理者能不能把这些能力重新写进组织运行方式里。 个人会用,只是开始。 组织会跑,才是分水岭。 当 AI 从个人电脑进入统一流程、资产和指标以后,组织架构图也会开始变化。里面不一定全是人,有些位置会变成系统、智能体、知识库、复核节点和流程责任人。 参考资料 McKinsey & Company,The state of AI in 2025, Agents, innovation, and transformation,2025年11月5日。Global Survey 样本为1,993名受访者,覆盖105个国家,关键引用点为企业 AI 使用普及度和 Agentic AI 部署阶段。 BCG,The Widening AI Value Gap, Build for the Future 2025,2025年9月30日。BCG Build for the Future 2025 Global Study 样本为1,250名高管和AI决策者,关键引用点为 future-built 企业比例、scale 阶段企业比例和价值差距。 BCG,AI at Work, Momentum Builds, but Gaps Remain,2025年6月26日。覆盖11个国家和地区,10,600多名员工、管理者和领导者,关键引用点为领导支持与一线 AI 使用差距。 BCG,Scaling AI Requires New Processes, Not Just New Tools,2026年1月20日。关键引用点为 AI 规模化需要流程重构和 10-20-70 资源配置原则。 Gartner,Gartner Identifies the Top Future of Work Trends for CHROs in 2026,2026年1月12日。关键引用点为 CHRO 应将 AI 对准高摩擦工作环节。 《中华人民共和国个人信息保护法》,关于个人信息处理、自动化决策、敏感个人信息和个人权益保护的规定。 国家互联网信息办公室等七部门,《生成式人工智能服务管理暂行办法》,2023年7月13日。关于生成式人工智能服务的数据、个人信息、合法权益和风险治理要求。 ## TC 03 Computer Use 出来以后,AI 不再只是会看,开始会动手了 没有接口的时候,AI 开始看界面、点按钮、把碎动作做完。 原文 https://aifellow.ai/articles/tc03 Computer Use 是:系统没有接口的时候,AI 直接看界面、点按钮、填表单,把碎动作做完。它不再只停在内容层。 这是「搭系统实录」第三篇。 前一篇写 MCP,讲的是 AI 怎么通过统一协议调用系统能力。 这一篇写 Computer Use,讲的是另一条更贴近现场、也更容易被低估的路径: 当系统没有接口,AI 能不能直接看界面、点按钮、填表单、完成动作。 过去企业用 AI,主要还停在内容层。 写一段话,改一份材料,总结一篇会议纪要,查一堆资料。这些都很有用,但它们大多还没有真正碰到公司的业务系统。 Computer Use 出来以后,边界变了。 AI 不只是回答你,它开始能进入真实界面,沿着流程往下走。 这件事真正重要的地方,不是 AI 终于会“点鼠标”了,而是公司里大量原本只能靠人坐在电脑前完成的碎动作,第一次有了被重新设计的可能。 ## 它不是一个更聪明的聊天框 Computer Use 的逻辑很直接: 先看屏幕截图,理解界面上有什么;再决定下一步动作;然后通过虚拟鼠标和键盘去点击、输入、滚动;执行完,再重新看屏幕,判断结果对不对。 OpenAI 在 2025 年 1 月发布 Operator,背后的模型叫 CUA,也就是 Computer-Using Agent。OpenAI 对它的描述很明确:模型可以看见浏览器界面,并通过点击、输入、滚动来完成任务。 Anthropic 更早在 2024 年 10 月开放了 Claude 的 computer use 能力,让模型通过截图观察桌面,再用虚拟键鼠操作软件。Anthropic 当时也提醒,这个能力还处在早期阶段,需要开发者在低风险任务里逐步试用。 到 2025 年 7 月,OpenAI 又发布 ChatGPT agent,把网页浏览、深度研究和计算机操作能力放进同一个 agent 模式里。 这些信号放在一起看,说明一件事: AI 正在从“会调用工具”,走向“会操作环境”。 这不是产品名的变化,而是能力边界的变化。 接口能通,就走接口;接口不通,它开始尝试走界面。 ## 它和 RPA 的差别,不在速度,在逻辑 一听到“AI 操作界面”,很多人会想到 RPA。 这个联想不奇怪,但如果只把 Computer Use 理解成新一代 RPA,很容易低估它。 传统 RPA 更像脚本。你提前定义好步骤,它按步骤跑。界面稳定、流程固定、规则清楚的时候,它很有效。 但 RPA 最怕变化。 按钮换了位置,弹窗多了一层,字段名改了一下,页面加载慢了一点,脚本就可能失败。 Computer Use 的起点不是坐标,而是目标。 它不是只记住“点第几个按钮”,而是先看当前界面,再判断哪里像提交按钮、哪里像输入框、下一步应该怎么走。 所以差别不是: RPA 慢,Computer Use 快。 真正的差别是: RPA 执行的是预设步骤,Computer Use 执行的是当前目标。 这句话很关键。 因为企业里有大量流程,并不是完全没有规则,而是规则写得不够干净,系统接口不够完整,界面还经常变。 过去这类流程很难自动化。 现在它们开始变成可讨论对象。 ## 为什么这会打到企业流程 Gartner 在 2025 年 8 月有一个判断:到 2026 年底,40% 的企业应用会集成任务型 AI agents,而 2025 年这个比例还不到 5%。 这个数字不需要被神化,但它说明一个方向: 企业软件不会只把 AI 当成写作助手,它会越来越多地把 AI 放进任务执行链条里。 MCP 解决的是一类问题:系统愿意开放能力时,AI 怎么标准化调用。 Computer Use 解决的是另一类问题:系统还没有开放能力时,AI 能不能先从界面进入流程。 这两条路合在一起,企业 AI 才开始真正接近业务现场。 一条是接口层。 一条是界面层。 接口层更稳,适合长期工程化。 界面层更粗糙,但很可能先碰到那些“每天都有人在做、但一直没人愿意改”的重复动作。 ## 公司里会先被改写的三类动作 不是所有流程都应该先交给 Computer Use。 最先适合试的,通常不是高判断、高风险、高金额的环节,而是三类低判断、高重复、跨系统的动作。 第一类,跨系统搬运。 一个人要从 A 系统查信息,再到 B 系统录入,再到 C 系统提交。真正的价值不在“判断”,而在“跑完”。这类动作最耗人,也最容易被忽略。 第二类,周期性核对。 周报、月报、客户信息同步、项目状态更新。每次都差不多,但每次都要打开几个系统、复制几段内容、核对几个字段。 第三类,流程后的补动作。 会议结束后补纪要,项目推进后改状态,沟通结束后补记录。很多管理动作最后不是输在判断,而是输在这些尾巴没人愿意收。 这些动作有一个共同点: 它们不一定值得单独开发系统接口,但长期让人手工做,又非常浪费。 Computer Use 的价值,恰好出现在这个缝里。 它不一定马上替代系统集成,但它会逼管理者重新看一遍: 公司里到底有多少工作,本质上只是人在替系统补接口。 ## 真正要先画清楚的不是流程,而是边界 Computer Use 一旦进入公司,管理者最该紧张的不是“能不能自动化”。 而是三个更基础的问题。 第一,权限边界。 AI 能看哪些系统?能填哪些字段?能不能点提交?能不能发邮件?能不能改客户资料?能不能触发付款或审批? 这些不是技术细节,是管理授权。 第二,确认点。 哪些动作可以自动完成,哪些动作必须在人确认以后才能继续。尤其是涉及金额、外部承诺、员工信息、客户信息、权限变更的动作,不能因为技术能点,就默认可以点。 第三,审计链。 AI 看了什么,点了什么,改了什么,失败在哪里,为什么重试,谁最终确认。 如果这些追不回来,Computer Use 做得越多,组织反而越失控。 所以我对这件事的判断很简单: Computer Use 降低的是自动化的技术门槛,不是管理门槛。 它越容易上手,越不能绕过权限、确认和追溯。 ## 企业真正该怎么开始 不要一上来就问“能不能替代某个岗位”。 这个问题太大,也太容易把事情带偏。 更好的起点是找三条链路: 第一,找一个每天都有人反复登录、复制、粘贴、核对的流程。 第二,把里面的动作拆成两类:执行动作和判断动作。 第三,只让 AI 先试执行动作,把判断动作和高风险动作留给人。 这才是比较稳的试点方式。 不是为了证明 AI 很强,而是为了验证一件更重要的事: 在你的组织里,哪些动作已经可以从“人亲自点”变成“人授权、AI 执行、人复核”。 这个变化一旦成立,意义就不只是省一点时间。 它会改变公司对流程的理解。 过去流程设计默认执行者是人,所以很多接口、字段、确认点都写得很粗。 以后如果流程里会出现 AI 执行者,流程本身就必须写得更清楚。 谁能看,谁能动,动到哪一步停,失败以后怎么回滚。 这些都会从“上线以后再说”,提前变成流程设计的一部分。 ## AI 正在从内容生产,进入流程执行 如果只把 Computer Use 看成“AI 会操作电脑”,它会显得像一个好玩的功能。 但如果放到企业里看,它更像一个信号: AI 正在从内容生产,进入流程执行。 这一步不会一夜之间改变公司,也不会立刻替代所有人。 但它会把一个以前很模糊的问题推到管理者面前: 当 AI 也能动手,组织里的动作边界到底该怎么重新写。 参考资料 - OpenAI, Introducing Operator, 2025-01-23: https://openai.com/index/introducing-operator/ - OpenAI, Introducing ChatGPT agent, 2025-07-17: https://openai.com/index/introducing-chatgpt-agent/ - Anthropic, Claude 3.5 Sonnet and computer use, 2024-10-22: https://www.anthropic.com/news/3-5-models-and-computer-use - Gartner, 40% of enterprise applications will be integrated with task-specific AI agents by 2026, 2025-08-26: https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025 ## TC 02 MCP 为什么会成为企业 AI 的统一插头 模型可以复用,场景可以复用,过去接口层很难复用。 原文 https://aifellow.ai/articles/tc02 这轮企业 AI,很多人还在盯模型。 但真做过几个场景就会发现,最重的活往往不在模型层,而在接口层。 你想让 AI 读知识库,要接文档系统。想让它查订单,要接业务数据库。想让它改状态,要接工单系统。想让它先做一轮分析,还要接搜索、文件、代码执行和内部服务。 问题不在于这些事做不到,而在于过去每做一个新场景,接口层几乎都要重写一遍。 所以 MCP 开始变重要,不是因为技术圈又多了一个缩写,而是因为它第一次在认真解决企业 AI 里最贵、也最重复的一层工作。 ## MCP 不是插件,它是协议 很多人第一次听到 MCP,会把它理解成“给 AI 装插件”。这只对了一半。更准确一点说,MCP 不是插件本身,而是工具怎么被发现、怎么被调用、怎么返回结果的一套协议约定。 Anthropic 在 2024 年 11 月 25 日发布 MCP 时,把它定义成连接模型、数据源、工具和开发环境的开放标准。这个定义真正重要的地方,不是“开放”,而是“标准”。 过去每个 AI 框架接外部系统,做法都不一样: - 工具描述格式不一样 - 权限边界不一样 - 返回结果格式不一样 - 上下文传法不一样 最后就会出现一个很现实的问题: 模型可以复用,场景逻辑可以复用,但接口层很难复用。 MCP 想统一的,就是这一层。 ## 从技术上看,MCP 至少做了 4 件事 在 MCP 里,基本是三层结构: - Host:真正运行 AI 应用的主体,比如桌面客户端、IDE、Agent 容器 - Client:Host 里负责和 MCP server 通信的那一层 - Server:真正暴露能力的一方,负责挂出工具、资源、提示模板 这意味着“模型在哪”“工具在哪”“谁负责通信”第一次从工程上被拆开了。以后换模型,不一定要重做工具层;换后端系统,也不一定要把整套 Agent 重写一遍。 MCP 底层走的是 JSON-RPC 2.0 思路。双方不是随便传一段字符串,而是按明确的方法、参数、结果、错误码通信。 AI 调工具,开始更像系统和系统在说话,而不是几段 prompt 在硬拼。 MCP 里最关键的不是一个泛泛的“tool”,而是几类不同能力: - Tools:发起动作,比如查库、调接口、执行函数 - Resources:读取上下文,比如文件、文档、数据库视图 - Prompts:标准化暴露提示模板 翻成人话,它其实在做三件事的协议化: 能做什么、能读什么、该怎么调。 MCP 不是连上就直接乱调。两边会先初始化,声明自己支持什么、不支持什么,之后才进入发现和调用。 企业接 AI 最怕的,不是不会调,而是“本来以为能调,结果边界根本没说清”。MCP 把这件事前置了。 ## 一次 MCP 调用,到底怎么走 一条典型调用链,基本是这样: - Host 连上某个 MCP server - Client 发 initialize,带上协议版本、capabilities 和 client 信息 - Server 回 initialize 结果,声明自己支持哪些能力 - Client 发 notifications/initialized - 如果要发现工具,走 tools/list - 如果要读资源,走 resources/list 和 resources/read - 如果要拿提示模板,走 prompts/list 和 prompts/get - 模型选中某个能力后,真正执行时走 tools/call - Server 返回结构化结果,Host 再把结果放回上下文,继续推理 工具调用第一次从 prompt 拼接,变成了协议化的能力发现、能力选择和能力执行。 这会直接影响稳定性。因为系统终于可以区分推理、调工具和工具返回结果,日志、审计、回放、权限控制这些事才有机会真正做起来。 最小消息流大概长这样: { "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-03-26", "capabilities": { "tools": {}, "resources": {}, "prompts": {} }, "clientInfo": { "name": "my-agent-host", "version": "1.0.0" } } } 工具真正执行时,会更像这样: { "jsonrpc": "2.0", "id": 12, "method": "tools/call", "params": { "name": "get_project_status", "arguments": { "project_id": "PJT-1024" } } } 这两段不是为了背协议,而是为了说明: MCP 不是“AI 自己想办法去调工具”,而是把调用过程收进了一套可验证、可记录、可审计的消息流。 ## stdio 和 Streamable HTTP,决定了它更像本地能力还是企业接口 MCP 现在最关键的两种传输方式,一个是 stdio,一个是 Streamable HTTP。 stdio 很直接:Client 把 server 当成一个本地子进程拉起来,通过标准输入输出传 JSON-RPC 消息。 它特别适合本地工具链: - 本地 IDE - 本地命令行 - 本地代码、文件、终端能力 优点是简单、快,而且天然更适合本地信任边界。 另一种是 Streamable HTTP。这是更像企业级接法的远程传输方式,服务端作为独立进程存在,通过 HTTP 端点对外提供 MCP 能力,必要时还能配合流式消息。 Streamable HTTP 已经在规范里替代了更早的 HTTP+SSE 说法。对企业来说,这不是名词变化,而是远程传输方式开始收敛,后面的鉴权、代理、网关接入也更容易标准化。 它们背后其实对应着两种完全不同的场景: - stdio 更像“本地 Agent 接本地能力” - Streamable HTTP 更像“多个 Agent / 客户端共享一层远程能力服务” 只要你从 stdio 走向远程 HTTP,就会立刻撞上真正的企业问题: - 身份认证怎么做 - 哪些 client 能连 - session 怎么管 - MCP-Protocol-Version 这类版本协商头怎么管 - Origin 怎么校验 - 本地服务是否只绑定 localhost - 权限是不是按最小授权原则切 - 有没有跨团队复用的一层共享 server 这就是为什么我一直说,MCP 碰到的不只是开发体验,而是企业架构。 ## 为什么 2025 年它突然变重 一个协议能不能从“技术社区讨论”走向“企业里真的要看”,关键不看概念漂不漂亮,要看平台是不是开始接。 MCP 这次真正升温,是因为两件事先后发生了。 第一,Anthropic 把它抛出来之后,围绕 MCP 的 server 生态开始长出来。 第二,更关键。OpenAI 在 2025 年 5 月 21 日宣布,Responses API 支持 remote MCP server。 MCP 不再只是某一家模型公司的接口偏好,而是开始进入主流 agent 平台。 再往前看,Google 在 2025 年 4 月 9 日发布 A2A 协议时,也明确把它和 MCP 放在互补位置上。A2A 解决的是 agent 和 agent 怎么协作,MCP 更像 agent 和工具、上下文、服务怎么对接。 企业 AI 开始标准化的,不只是模型接入,还有工具接入。 ## 它真正改掉的,是企业 AI 的成本结构 过去企业做 AI,最容易陷进去的坑是“一个场景一个项目”。 客服做一个机器人,接一遍;销售做一个助手,再接一遍;运营做一个知识问答,又接一遍。模型层能复用,但接口层没有统一标准,所以每次都像新项目。 一旦 MCP 这种协议层被越来越多平台接受,事情就会变: 不是每个业务场景都从零开始接系统,而是公司开始有机会沉淀一层公共的能力接入层。 这会直接改掉企业 AI 的成本结构。以前最贵的是一次次重复集成,以后真正能拉开差距的,是谁先把内部常用系统抽成一层可复用的 MCP server 或兼容能力层。 如果再写得更工程一点,它其实是在把企业 AI 技术栈拆成三层: - 上层:模型和 Agent 编排 - 中层:MCP 这一类能力接入层 - 下层:企业原有系统、数据源、内部服务 这三层一旦拆开,后面换模型、换 Agent、换应用入口,都不一定要把最底下那层系统接法全部重来。 这就是为什么它不像“又一个工具协议”,更像企业 AI 的中间件信号。 ## 企业真要落地,最容易做坏的是 server 边界 很多团队第一反应是按现有系统来拆:一个系统一个 server。这个办法不一定错,但很容易把历史系统边界原样搬进 AI 层,最后模型能连很多东西,却还是很难完成一个完整动作。 我更建议按“能力域”去拆,而不是只按“系统名”去拆。 比如: - project_mcp:项目进度、风险、阻塞、里程碑 - docs_mcp:当前版方案、制度、FAQ、模板 - ops_mcp:工单查询、状态更新、异常提报 这样做的好处是,模型拿到的是“完成任务需要的能力集合”,而不是“某个旧系统原样暴露出来的接口集合”。 再往下走,工具设计至少有三个原则: - resource 尽量放只读、当前态、可引用的东西 - tool 尽量放有明确输入、明确输出、最好幂等的动作 - 参数 schema 要比 prompt 更严格 企业里很多工具调用失败,不是模型不会选,而是参数太松,最后每次都靠自然语言猜。 ## 真正该先紧张的,不是“怎么接”,而是“接到哪里为止” 一听到“标准化接入”,很多人第一反应通常是效率会更高。会更高,但先被抬上桌的,不只是效率,还有权限、审计和责任。 因为 AI 只要更容易接进系统,管理层就得更早回答几件以前还能往后拖的问题: - 什么能力只能读,什么能力允许写 - 什么数据能暴露给模型,什么不能 - 调用是全量开放,还是按角色、按场景、按审批开放 - OAuth 或企业内部身份体系怎么接 - 调用日志留到什么粒度 - 哪些动作必须设置人类接管点 所以 MCP 最值得管理者关注的,不是它让开发更顺,而是它会把企业 AI 从“能不能做”推进到“怎么受控地做”。 以前很多公司讨论 AI,主要还停留在问答层,所以权限问题经常被放在最后补。到了 MCP 这一层,顺序会反过来。因为一旦模型真的能调工具、读资源、触发动作,治理就不再是附属问题,而会直接进入架构层。 再往前走一步,企业真把 MCP 接起来以后,不能只看“有没有跑通”,还要看它跑得稳不稳。 至少有四类指标,值得被单独盯住: - tool_call_success_rate - fallback_to_human_rate - resource_freshness - unsafe_action_block_rate 很多 AI 系统看上去能用,真正的问题都藏在这里:调用经常失败,工具结果不稳定,资源读到旧版本,高风险动作没有被及时拦下。 这些都不是模型分数能解释的,它们是能力层和治理层的问题。 ## 别低估接口层,也别当成万能接口 如果只把 MCP 当成一个技术协议,你会低估它。 如果把它当成万能接口,你又会高估它。 它现在更准确的位置,是企业 AI 的接口层标准开始成形的信号。 这件事一旦跑顺,最先变化的不会是概念更多了,而是企业终于可以把一部分重复、分散、难复用的集成工作,从“每个项目重来一遍”,往“公共能力层”上收。 很多人还在讨论哪家模型更强。 我更关心另一件事: 谁会最先把自己的系统,接成 AI 真能调用的一层标准能力。 那家公司后面做的,就不再只是单点 AI 应用,而是一整层可复用的组织能力。 ## TC 01 我把 Codex 接进了微信 聊天框成了给本机 Codex 派活的入口。 原文 https://aifellow.ai/articles/tc01 这个项目受了《在微信里使用 Claude Code,刚刚在 GitHub 上开源了这个 Skill。》的启发。但我这次要做的,不是复刻一遍 Claude,而是想把 Codex 做成一个真正顺手、能长期跑的微信入口。 项目开源 → ## 微信里给本机 Codex 派活 - 直接在微信里给本机 Codex 派活,不用远程桌面,不用先回到终端。 - 支持多轮上下文,消息会按 thread_id 接回同一条会话。 - 支持图片分析,不只是“提示收到”,而是真的下载、解密、交给 Codex 处理。 - 支持 /status、/clear、/cwd、/model、/mode 等命令。 - macOS 上可以用 launchd 常驻,重启以后还能继续跑。 ## 这件事为什么值得做 我一直对“把入口做薄”这件事很有兴趣。 不是为了炫一个“微信里也能跑 AI”,而是为了把一个本来只能坐在电脑前完成的动作,改成你在路上也能随手触发的动作。 你突然想到一个需求,发条微信过去;本机上的 Codex 开始执行;等你回到电脑前,结果可能已经在那儿了。 这和远程控制电脑不是一回事。 我想做的,是把 Codex 本身变成一个低摩擦入口,而微信只是那个几乎没有学习成本的壳。 ## 我怎么把它做出来 我这次选的方案很直接: 微信 -> 微信协议层 -> 本地 daemon -> Codex CLI -> 微信 没有接 Gateway,没有配公网 IP,也没有折腾域名。 原因很简单。对个人开发者来说,链路越短,越容易稳定,越容易长期维护。 只要扫码绑定、长轮询、消息解析、媒体下载这些底层链路跑通,后面的执行器就只是一个可以替换的模块。这次我把它换成了 Codex CLI。 所以这个项目最后收敛成了几块很实用的东西: - 微信协议层 - 本地守护进程 - Codex 桥接层 - 会话持久化 - 图片处理 - 命令系统 我没有故意把它做得很花。我更关心的是三件事:能不能持续跑,出问题能不能定位,真实消息来了会不会露馅。 ## 真正难的,不是接通,而是把坑踩完 这类桥接项目最容易出现一种假象:演示能跑,一上真实消息就开始失真。 我这次最典型的两个坑,刚好都说明了这一点。 第一个坑,是第一条消息能回,后面就没反应。 最后查出来不是微信协议坏了,而是 codex exec resume 被我放在轮询线程里同步等待了。只要 Codex 忙一点,后面的消息就全部堵住。 这个问题后来被我拆掉了: - Codex 执行改成后台异步 - 增加子进程超时保护 - daemon 启动时清理遗留的 processing 状态 第二个坑,是图片其实收到了,但下载和解密链路错了。 我最初按旧结构读图片字段,真实线上消息却是另一套 payload。结果用户看到的是“图片已收到,但下载或解密失败”,本质上不是没收到,而是协议适配层判断错了。 我把真实图片链路重新对齐以后,这条能力才算真正闭环: - 按真实结构读取 image_item.media - 优先使用正确的图片密钥 - 修正微信图片 CDN 下载地址 我不太喜欢那种“看起来能用,但真实场景一来就开始胡说”的工具。所以这部分我宁愿多花时间,也要把它收干净。 ## 现在 WeChatCodex 已经到了什么程度 它现在已经不是一个演示用 demo 了,而是一套能在我机器上稳定跑的本地服务。 目前已经支持: - 微信文字消息接入本机 Codex - 基于 thread_id 的多轮上下文 - 图片消息交给 Codex 分析 - 常用 slash 命令控制运行状态 - launchd 常驻运行 - 本地保存账号、配置、日志和会话 对我来说,一个项目值不值得继续做,不看它“概念上新不新”,而看它有没有把一条真实工作流补完整。 WeChatCodex 做到的,正是这一点。 ## 先把真实链路打通 如果你也想把本机上的 Codex 接到微信里,可以直接看这个项目: https://github.com/DrDavidDa/WeChatCodex 我一直很看重一类项目:先把真实链路打通,再把工程慢慢打磨到别人也能复用。 WeChatCodex 现在只是一个开始,期待后续微信端能有更多玩法。 ## RM 12 智能体出错了,谁负责? 执行事故在机器,治理事故在人。 原文 https://aifellow.ai/articles/rm12 今年行业里都在说一件事,2026是AI Agent元年。不是概念上的元年,是真的一年。IDC有个预测,头部企业智能体使用量明年要增长10倍。 我身边也是这个感觉。去年大家还在讨论"要不要试",今年变成了"什么时候上"。上个月有个同行跟我聊天,他们公司刚上线了一个智能体,负责自动汇总各项目的费用数据,每周生成一份简报发到管理群。跑了三周都好好的,第四周突然把两个项目的数据搞混了,简报里出现了已经终止的合同金额。 好在总经理那天忙,没细看。但财务总监看到了,截图发到群里问了一句,这个数哪来的? 群里又是一阵安静。 他跟我说的那句话我印象特别深,最尴尬的不是数据搞错了,数据搞错了能改。最尴尬的是没有人说得清这个错是在哪一步发生的。是原始数据有问题,还是智能体汇总的时候没做校验,还是发简报之前根本没有人设审核环节。每个人都在说"这事不归我",但每个人又都觉得"这事应该有人管"。 在现场管过流程的人,对这种"应该有人管但没人管"的状态都熟。组织里大部分责任黑洞,都不是因为人不想负责,而是因为没人提前把责任链条画清楚。只不过以前这个黑洞只存在于人和人之间,现在人和机器之间也出现了。 智能体犯错,执行事故在机器,治理事故在人。 ## Agent 元年,赶着上线的多,想清楚责任的少 现在越来越多的公司在试智能体。有的让它接客服,有的让它做报表,有的让它起草方案。尤其是地产行业,华润置地刚裁了10%的人,整个行业央企三年减了五万多。人少了,活还在,很多公司第一反应就是用智能体补缺口。 这个方向没问题。但如果你问一句,它出了错算谁的?十个公司里有八个答不上来。 不是他们不重视。而是这件事以前不需要回答。 以前系统犯错,责任链很清楚。系统是你买的,配置是你填的,规则是你定的,所以出了错要么找供应商,要么找内部运维。但智能体不一样。它能自己判断,它能自己组合工具,它能自己决定执行路径。它犯的错,很多时候不是配置写错了,而是它在某个判断节点上做了一个看起来合理但实际不对的选择。 这就带来一个以前从来没有过的问题。如果这个选择是人做的,责任在他。但如果是智能体做的,责任在哪里? 很多公司的第一反应是,那就还是算人的。谁引进的谁负责,谁审批的谁负责。 这个直觉对了一半,但只有一半。 结果责任确实最终在人。但如果你只说"出了错算人的",你什么都没解决。 ## 四层责任,不能打包甩给一个人 我后来仔细想了一下这件事,觉得问题出在一个地方。很多人把智能体的责任当成一个整体在看,好像它出了错,找一个人兜底就行了。但实际上一旦智能体进入流程,责任至少会分成四层。 第一层是结果责任。简报发出去,数字错了,这件事最终一定有一个人要对外扛。这层跑不掉,也不能含糊。不管中间经过多少智能体,最终签字或确认结果的那个人,就是结果责任人。 第二层是审核责任。智能体跑出来的东西,谁来审?审到什么程度?是每条都过目,还是只看异常值?审核责任如果不清,结果责任人就会变成背锅人,因为他既审不了又逃不掉。 第三层是配置责任。智能体的权限是谁设的,边界是谁定的,它碰哪些数据、不碰哪些数据,谁说了算。配置出问题,智能体按规则跑也会跑偏。这一层通常应该是管理者来定,不是技术团队自己决定。 第四层是升级责任。当智能体遇到它处理不了的情况,它应该停下来问谁?问完以后谁来决定是继续还是回滚?升级路径如果不提前画好,出了事就只能靠群里喊人,喊到谁算谁。 这四层责任,如果只笼统地说"出了错算负责人的",等于四层全压在一个人身上。然后你会发现这个人既没有时间审,也没有权限改配置,更没有权力决定升级。出了事他背锅,但出事之前他什么都管不了。 这才是智能体落地里最贵的一个bug。不是它不够聪明,而是没人提前说清楚聪明到哪一步必须停,停了以后谁来接。 ## 98.9%的准确率,剩下的1.1%谁来兜 最近行业里有个说法叫"可信智能体",说企业级AI操作准确率已经到了98.9%。听着很漂亮。 但你想过没有,98.9%意味着什么?意味着每100次操作里,还有1到2次是错的。如果你的智能体每天跑1000个流程,每天就有10到20个错误。如果你的公司有5个智能体同时在跑,每天就有50到100个潜在的错误在系统里流动。 这50到100个错误,你知道出在哪吗?有人盯着吗?出了错有人接得住吗? 坦率地讲,大部分公司连一个智能体的责任链条都没画清楚,更别说五个了。行业里说Agent元年来了,Agent确实来了。但Agent的速度比管理的速度快。技术团队一个月能上线三个智能体,管理团队可能三个月还没把一个智能体的责任链条理顺。 这个速度差才是真正的风险。不是AI不够好,是管理没跟上。 ## 最怕的不是犯错,是不知道错在哪一层 回到我那个同行的故事。财务总监问"这个数哪来的",群里安静,不是因为大家不负责,而是因为没有人能回答。数据从哪来的,汇总逻辑是谁定的,异常值有没有校验规则,发出去之前有没有审核环节。每一个环节都可能是出错的点,但每一个环节都没有事先标过责任人。 我后来跟他说,你现在的问题不是智能体搞错了数据。你的问题是,你不知道这个错发生在哪一层。是配置层没设校验规则?是执行层智能体汇总逻辑出了偏差?还是审核层根本就没有人看过就直接发出去了? 如果你不知道错在哪一层,你就修不了。你只能把整个流程停掉,等搞清楚了再上。但下一次再错,大概率还是不知道错在哪。 这和带人的逻辑一模一样。一个团队出了问题,成熟的管理者不会只说"这事你负责"。他会先拆清楚,是目标没定清楚,是能力不够,是流程有漏洞,还是没有汇报机制。每一层的问题解法不一样。对人如此,对智能体也一样。 成熟的公司不是智能体不出错,而是错了以后,三十秒内就知道错在哪一层,该找谁,怎么改。 ## 责任链条不清,所有管理动作都是空转 说真的,这件事我想了很久。为什么那么多公司敢花钱买智能体,敢放它进流程,却不愿意花时间把责任链条画清楚? 我觉得原因只有一个。画责任链条这件事,太像管理工作了。不热闹,不性感,不好汇报。不像"我们上线了一个AI助手"那样可以拿去跟老板说。 但管理的真相从来都在这些不热闹的事里面。 岗位说明书不热闹,权限表不热闹,审批链不热闹,例外处理规则不热闹。但这些才是组织能跑起来的底层代码。你不在这些地方花时间,后面所有看起来热闹的东西,都会在某一天突然停下来。 特别是现在这个时间点。地产刚裁完人,组织还在适应期,旧的责任关系已经被打乱了,新的还没建起来。这时候急着上智能体,等于在一个已经松动的地基上盖楼。盖得越快,塌得越突然。 我自己的体会是,智能体管理最核心的动作,不是训练它更聪明,不是接更多工具,而是提前把一件事想透。它在什么情况下会犯错,犯了错责任怎么分,分完责任每一层的人知道不知道自己该做什么。 这三个问题想清楚了,哪怕智能体还不够聪明,你也能兜得住。想不清楚,再强的智能体也只是把风险从"人犯错"换成了"系统犯错",而且犯了错你都不知道该找谁。 人工犯错是执行事故,配置不当犯错是治理事故。治理事故的代价,永远比执行事故大。 ## 四个问题答不清,先别碰核心流程 如果你公司里已经在跑智能体,我建议你明天做一件事。把所有正在运行的智能体列出来,对每一个只问四个问题。 它的结果谁签字?它跑出来的东西谁来审?它的权限和边界谁定的?它遇到处理不了的情况,停下来问谁? 四个问题能答清楚,你的智能体就有了一个最基本的责任框架。答不清楚,先别让它碰核心流程。 上一篇我聊到,智能体越来越像员工,但大多数公司还没给它写过岗位说明书。岗位说明书解决的是"它干什么"的问题。这一篇要解决的是另一个问题,它出了事,责任怎么分。 岗位定义了能力边界,责任链条定义了安全边界。两条都画清楚了,智能体才能从"试一试"变成"真正接得住"。 ## RM 11 智能体越来越像员工,但大多数公司还没有岗位说明书 给它起了名字,就别再把它只当工具。 原文 https://aifellow.ai/articles/rm11 上周在群里看到一个同行分享,他们部门给一个智能体起了名字,叫「小周」。小周负责每天早上拉数据、做简报、发到群里,遇到异常值还会自动@对应的负责人。 然后有人问了一句,小周的权限边界在哪?谁审批过它能碰哪些数据?出了错算谁的? 群里安静了大概十秒。 在现场管过流程的人,对这种安静都熟。一个事情只要问到权责边界,热闹往往就没了。 我当时脑子里冒出来的判断很直接,智能体已经越来越像岗位,但大多数公司还没给它写过一份真正的岗位说明书。 ## 给它起了名字,就别再把它当工具 上一篇我聊到,假管理会越来越便宜,真管理会越来越贵。那个判断的背后,还有一个更具体的问题没有展开。当智能体开始接任务、接流程、接结果,它到底还是一个工具,还是一个岗位? 这个问题以前不难回答。工具就是工具,Excel不会自己跑,OA不会自己判断。但现在不一样了。一个智能体可以自主拉数据、做分析、写报告、发通知、甚至替你做一部分决策。它有持续性,它有记忆,它有主动性。你给它一个目标,它能拆成步骤、调起工具、完成闭环。 这已经不是「用工具」了。这更像是在「用一个人」。 智能体最麻烦的地方,不是它不够聪明,而是组织还没有准备好回答一个最基本的问题,它在这个组织里,到底算什么? ## 最危险的,不是它太聪明,是它没编制 你可以想象一下。如果今天公司招了一个人,没有写岗位说明书,没有定汇报关系,没有设审批权限,没有说清它能碰什么数据、做什么决策、出了问题谁负责,就这么放进来干活了。 任何一个人力总监都会说,这不行。说得再直一点,这不是试点,这是裸奔。 但智能体现在在很多公司里,就是这么进来的。 老板看到某个智能体很酷,说我们也搞一个。技术团队搭好了,丢给业务用。业务觉得好用,就越来越依赖。然后某一天出了事,数据被错误修改了,客户收到了不该发的消息,审批链被一个智能体跳过了。 这时候大家才发现,没有一个人知道这个智能体的权限边界是什么,没有一个人审批过它的「岗位设计」,甚至没有人正式定义过它到底应该在哪条链路上、能走多远。 给智能体起名字很容易,给它写岗位说明书很难。但后者才是真正决定它能不能在组织里安全运转的东西。 ## 权限表能管按钮,管不了会行动的系统 有人会说,这不就是IT系统权限管理吗?加个白名单、设个审批流不就行了。 问题没那么简单。 传统的IT权限管理,管的是「谁能登录」「谁能看什么字段」「谁能点哪个按钮」。这套东西管按钮没问题,按钮不会自己动。但智能体不是按钮,它是一个会自己往前走的执行单元。你管它,不能只管动作,还得管判断。 举个例子。你给一个智能体设了权限,它可以读取客户数据。但你有没有定义过,它能不能根据客户数据做分类决策?能不能自动触发一条营销信息?能不能在判断客户可能流失的时候,主动给销售发提醒?这些都不是简单的「读/写」权限能覆盖的。 传统岗位说明书里写的那些东西,职责范围、汇报对象、权限等级、例外处理、审计路径,对一个智能体来说,不是少了几个字段的问题,是整个框架都要重新想。 说真的,很多公司现在卡住的地方就在这。权限管理解决的是能不能做,岗位设计解决的是该不该做。前者是配置,后者是治理。一个配错了还能修,一个没治理好,迟早要出事。 智能体需要的不是一张权限表,是一份岗位说明书。而且这份岗位说明书不是给人看的,是给系统跑的。 ## 以后你不只管人,你还得给系统定岗 说到这里,你可能会想,这不是技术团队的事吗? 还真不是。技术团队能定义智能体「能做什么」。但「该做什么」「不该做什么」「做到什么程度需要停下来问人」「出了错算谁的」,这些是管理判断,不是技术参数。 这也是为什么我说,管理者在AI时代最稀缺的能力,是替系统划边界。 以前给员工划边界靠岗位说明书、靠制度、靠审批流程。现在给智能体划边界,靠的是另一套东西。 它到底在优化什么,这是目标。它能碰什么、不能碰什么,这是边界。什么情况必须停下来问人,这是例外路径。还有最重要的,出了问题最终落在谁身上,这是责任锚点。 坦率地讲,管理者过去在设计人的岗位。现在开始,还要设计不是人的岗位。而且对智能体的岗位设计,要比对人的更精确。人遇到模糊地带会犹豫、会问、会用常识判断,智能体不会。你给它的边界有多模糊,它的行为就有多不可控。 管理者的新功课不是学会写提示词,而是学会写智能体的岗位说明书。 ## 真正卡住落地的,从来不是模型,是治理 最近外面关于智能体的讨论很多,大多数集中在能力层面。哪个模型更强,哪个框架更灵活,哪个场景最先落地。但我觉得,真正卡住智能体进入组织的,不是能力,是治理。 一家公司敢不敢让智能体接一个真实的业务流程,不取决于这个智能体能不能做,而取决于这家公司有没有想清楚几件事。它在流程上的边界是什么,出错以后的兜底机制是什么,最终谁来为它的结果负责。 这三个问题,哪一个都不是技术问题。 这也是为什么我会说,智能体对管理的冲击,可能比大模型更大。大模型改变的是「谁能做」,智能体改变的是「谁在组织里」。当一个不是人的执行单元开始像员工一样持续工作、自主判断、产出结果,组织就得面对一个以前没认真想过的问题,你怎么管理一个没有劳动合同、没有绩效考核、但有实际行为的「数字同事」? 管理的前一百年,所有工具都是被动的。Excel不会自己跑,OA不会自己判断,ERP不会自己决策。所以管理制度的设计前提是,工具是被动的,人才是主动的。这个前提正在被改写。 如果用我这段时间一直在讲的比喻来说,旧管理OS默认工具不会行动,所以制度只需要管人。新管理OS要开始管理会行动的系统,所以岗位、权限、流程、责任都得重新编译一遍。 当工具开始有自己的主动性,管理制度的设计前提就变了。 ## 真要落地,先补一份数字岗位说明书 回到开头那个问题。小周的权限边界在哪? 我觉得这个问题的答案,不需要等技术再进步十年。今天就可以开始做。 把智能体当成一个新员工来看。你招一个新员工会做什么?写岗位说明书,定汇报关系,设审批权限,讲清楚哪些能碰哪些不能碰,出了事谁来扛。 对智能体做一样的事。只不过这份「岗位说明书」不是写在Word里的,而是要写成它能执行的规则、能遵守的边界、能触发的例外。 这不是技术团队的活。这是管理者在这个时代最该学会的一件新事情。 因为接下来,越来越多的组织会遇到同一个局面。智能体越来越像员工,干的活越来越像岗位,产出的结果越来越像绩效。但大多数公司,连一份岗位说明书都还没给它写过。 给智能体写岗位说明书,不是在管理技术,是在定义组织未来的运行方式。 如果你也在公司里开始试智能体,我建议你明天先别急着开方案会。把现在正在试跑的智能体列出来,然后只问四个问题,它为谁负责,它能碰什么,它在哪些情形必须停下来问人,它出了错谁兜底。四个问题答不出来,就先别让它进核心流程。 最值得先补的,不是再找一个更强的模型,而是先把你的「数字岗位说明书」写出来。你真把这张纸补出来了,很多表面上的智能化问题,反而一下子就清楚了。 ## RM 10 管理没有消亡,消亡的是假管理 先消亡的,是那些本来就不该被叫做管理的东西。 原文 https://aifellow.ai/articles/rm10 今年我明显感觉到,公司里聊 AI 的语气变了。 去年更像看新机会。谁接得快,谁能跑 demo,谁会写提示词,谁就容易显得走在前面。到了今年,大家翻出来的东西已经不一样了:岗位说明书、审批链、权限表、编制表、流程图。讨论也不再停留在“它会不会”,而是开始落到一句更现实的话上:这件事如果不靠某个人在中间转一下、催一下、兜一下,还成不成立? 这背后其实是一个很大的变化。AI 开始从一个热闹词,进入组织真正算账的地方了。一旦开始算账,很多过去看起来理所当然的动作,就会被重新估值。一个流程为什么要过这么多人,一个节点为什么非得某个人点头才动,一句已经说清的话,为什么还要在几个群里转来转去。以前这些问题不是没人看到,只是组织还能吞下去;现在开始吞不下去了。一个岗位最危险的时候,不是今天看上去忙,而是明天开始被拆开算账。 组织最怕的,从来不是问题被看见,而是那些以前靠人数和耐心掩盖的问题,突然开始按结果计价了。 ## 开始算账以后,水分先被照出来 所以我越来越觉得,这一轮被 AI 真正照亮的,不是基层执行,而是很多公司长期默认合理的管理动作。 很多人一听这句话会下意识紧张,好像接下来要得出“管理不值钱了”这种结论。我的判断正好相反。管理没有消亡,先开始消亡的,是那些本来就不该被叫做管理的东西。 过去很多公司里,所谓“管理价值”里掺了不少别的成分。不是判断,不是取舍,也不是对结果负责,而是组织太粗糙、系统太弱、接口太乱,所以只能靠人站在中间,把事情一次次接住。有人负责转述,有人负责催办,有人负责补漏洞,有人负责守口子。这些事以前当然重要,因为没有它们,事情真的会掉地上。信息经过你,不等于责任在你。很多中间层最大的误判,就是把“经过我”当成“我创造了价值”。 问题在于,重要不等于高级,必要也不等于以后还值那个价。 ## 假管理是对低效的长期租赁 很多被包装成“管理经验”的东西,本质上只是组织对低效的长期租赁。 如果一份合同总卡在某个主管微信里,一笔报销总要在几个角色之间来回确认,一次客诉升级总要靠人层层解释口径,那这里面当然有人在付出,也确实有人在“做事”。但说到底,这更像是在替一个没有长好的组织承担摩擦成本,而不是在创造新的管理价值。 这也是很多管理者这两年真正不舒服的地方。难受的不是工作变少了,而是第一次不得不承认:过去那部分“没有我不行”,有一些并不是因为我的判断有多值钱,而是因为这家公司一直没有把那一段写成系统、写成规则、写成一个不依赖某个人在线也能运转的机制。组织越依赖某个人在线,越说明它还没有把能力真正沉淀下来。 一个总要靠人盯着才能运转的流程,本质上还没有真正交付完成。 ## AI 先拿走的是中间动作 这也是为什么我一直不太喜欢把这轮变化简单理解成“AI 替代人”。它先替代的,很多时候不是一个完整岗位,而是岗位里那些反复消耗人、又没有真正沉淀成结果的中间动作。知识库能先答一部分问题,流程能先往前推,状态能自动回写,提醒能自动发,规则能提前拦,权限和审计也能接住过去靠人肉盯住的部分。AI 一旦真正接上流程,最尴尬的往往不是谁不会写提示词,而是谁突然解释不清,为什么这个环节还必须养一层人站在中间。 最近外面真正升温的词也说明了这一点。大家聊得越来越多的,不只是模型能力,而是 ROI、治理、放权、审计、责任闭环。不是热情过去了,而是热闹结束以后,组织开始问一个更难的问题:这东西接进来之后,究竟替我们省掉了什么,又把哪些过去被默认吞掉的低效暴露出来了? 如果从这个角度看,AI 削弱的不是管理本身,而是管理里的水分。那些靠传话证明存在感、靠催办制造忙碌感、靠补洞维持重要感、靠守门制造稀缺感的部分,都会越来越便宜。因为这些动作之所以昂贵,很多时候只是因为以前没有更好的替代方式,并不代表它们本身就是高水平的管理。 真正会被留下来的,反而是以前总被这些杂音裹在一起、没有被单独看清的那部分能力。资源收紧的时候,什么该停,什么必须保;规则撞车的时候,谁来拍板;系统能自动到哪一步,哪一步必须停下来问人;智能体开始接活以后,它能碰什么、不能碰什么,出错以后算谁的。这些问题说起来不热闹,但它们才是真正贵的东西。真正的管理稀缺,不是信息都来找你,而是责任最后能在你这里闭环。 管理的上限,不是你能同时盯住多少事,而是你不盯的时候,还有多少事能照样发生。 ## 真管理会越来越贵 所以我现在越来越不认同一句话:以后只剩技术值钱。技术当然重要,它解决的是“能不能做出来”;但管理解决的是另一层更难的事,做出来以后放到哪里,谁有权调用,什么算越权,什么算例外,出了问题谁负责。技术是在造能力,管理是在决定这种能力最后是一个工具、一段流程,还是一个真正被组织接纳和约束的岗位。 会做事的系统会越来越多,真正稀缺的,是替这些系统划边界、扛责任的人。 说到底,真管理不是把自己卡在流程中间,让所有事都从你这里过一遍;真管理是把组织写到你不在场,它也能大体按对的方式运转。如果所有关键动作都必须绕你一圈,先证明的通常不是你重要,而是组织太弱。 这也是为什么我会说,假管理会越来越便宜,真管理会越来越贵。以后公司淘汰的未必是中层这个角色,而是中层里的那部分水分。不是唱衰管理,而是把管理从位置感重新拎回结果里。 职位可以留在架构图里,价值只能留在结果里。 以前真管理和假管理常常是打包一起卖的。一个人既在做判断,也在传话;既在定规则,也在补漏洞;既承担结果,也被一堆低价值动作缠住。现在水分开始被一层层挤掉,管理者迟早都要单独回答一个问题:把那些能被系统拿走的动作都拿走以后,你还剩什么? 如果你剩下的是判断、收口、定边界、扛责任,那你会比以前更值钱。如果你剩下的只是“没有我不行”的位置感,那接下来会很危险。 所以这篇我真正想说的其实只有一句:管理没有消亡,消亡的是假管理。 ## RM 09 如果明天砍掉你一半的人,你还能证明什么? 人少之后,被重新估值的不是工具,是管理。 原文 https://aifellow.ai/articles/rm09 最近很多公司聊 AI。前一阵大家还在看 demo,看谁写得快、搜得准、做表漂亮。 现在很多公司最先摆上桌的,已经是预算表、编制表和项目清单了。 这时候先被重新估值的,就不是模型了,而是真人。一个话题只要进了这些表,问法就会变:今年不补人,这些事还能不能做?哪些动作还值得继续养一层人? 问题一旦这么问,被重新估值的就不是工具,是管理。 很多管理者真正不舒服的,不是工作会更累,而是会突然看清:过去那部分“离不开我”,有不少只是组织把问题压给了人。 ## 人多的时候,人数会掩盖问题 人多的时候,公司很容易用人数掩盖问题。 流程没收口,就多拉几个人跟。接口不清,就多加一层协调。目标不具体,就再开一轮会,再做一版周报,再找个人在中间解释。 短期看都有效,因为事情确实能往前推。 但它有个后果:问题没有被解决,只是被更多人暂时托住了。 所以人数一多,组织里就会长出一批“看起来很重要”的价值。 有人总在线,有人总接得住,有人最懂上下口径,有人能把快失控的局面先压住。 这些动作以前当然有用,不然组织根本转不起来。 可其中相当一部分,并不在创造新结果,它们更像是在替旧秩序上保险。 说得直一点: 很多人不是在创造结果,他们是在替组织的模糊成本付利息。 以前这笔利息只能靠人付,所以也能被算成价值。 现在不一样了。信息一透明,状态一在线,规则一清楚,很多过去靠一层层人压住的动作,就会先露出原价。 有的人一少,组织照样转。 有的人一少,真正暴露出来的,不是人不够,而是很多事从来没人真正收过口。 ## 先被拿掉的,往往是遮羞布 所以砍人最残酷的地方,不是少了多少劳动力。 先被拿掉的,往往是遮羞布。 人多的时候,流程绕一点也能忍,责任虚一点也能忍,目标糊一点也能靠中间多磨几轮混过去。 人一少,问题开始有姓有名:谁拍板,谁负责,哪件事今天不做,什么情况算例外。 以前靠人数吞掉的东西,现在都得重新说清。 ## 优先级不是排序题,是删题 所以资源一收紧,最先变贵的,不是更会忙的人。 是会做减法的人。 人多的时候,很多管理者习惯“先接着再说”。什么都想保,什么都想推,什么都不敢停,反正总还有人能跟。 人一少,最值钱的人反而不是还能把十件事都扛下来的人,而是能很快让所有人知道:今天真正只剩哪三件必须做,另外七件现在就停的人。 资源收紧以后,优先级不是排序题,是删题。 ## 人少的时候,组织奖励谁最清楚 再往后,变贵的是收口。 人多的时候,很多模糊都能一直拖着:这个到底谁负责,先放着;这个例外怎么算,先往后压;这个接口归哪边,先各退一步。因为总有人能兜。 人一少,模糊就是最贵的成本。事情一模糊,就会多一次确认;责任一模糊,就会多一次等待;边界一模糊,就会多一层误解。 所以人越少,越不值钱的就是那种永远把事情留在“再对一下”“回头再收”的状态里的人。越值钱的,反而是能很快把口子收住的人。 谁定,谁做,什么时候交,什么算完成,什么属于例外,什么必须往上提。 人少的时候,组织不奖励谁最辛苦,只奖励谁最清楚。 再往后,才是把现实翻成动作的能力。 很多团队一缩编,就会发现一个尴尬事实:会上大家都懂,会后还是没人动。不是谁偷懒,而是老板说的是目标,业务听到的是麻烦,技术看到的是复杂度,一线想到的是今天手里还压着多少件事。 人多的时候,这段落差可以靠中间层反复对、反复讲、反复催慢慢磨掉。人一少,这种办法最先失效。 所以以后真正值钱的,不是那个最会转述的人,而是能把一句模糊的话翻成一个动作的人。什么叫先做,做到哪一步算到位,哪些情况不用问,哪些情况必须停下来,谁有权拍板,谁只需要被告知。 很多团队看起来缺人,其实先缺的是这种人。 ## 离了你就乱,先证明系统太弱 最后会变贵的,是不占位置的能力。 很多管理者最难放掉的,不是任务,而是那种“所有事最好都从我这里过一下”的确定感。你在场,大家安心;你点个头,别人心里才算过;你回得快,团队就觉得稳。 这种感觉很像重要。 可真到了人少的时候,组织最养不起的,恰恰就是这种重要感。一个团队如果减了人,结果所有关键动作还是只能堆到同一个人身上,那不叫核心人物,那叫单点故障。 所以以后真正值钱的,不是谁盯着才稳,而是你不在现场,事情也不走样。 如果一个团队离了你就乱,先证明的通常不是你重要,而是系统太弱。 所以如果明天真少一半人,你要证明的,不是你还能多扛多少活。 你要证明的是:少了那些人以后,团队是不是更知道今天先做什么;出了例外,是不是有人能收口;一句目标下来,是不是能很快变成动作;关键节点上,是不是不再非得靠你本人盯着,事情才肯往前走。 这才是以后更硬的管理价值。 所以我越来越不觉得,AI 在削弱管理。 它只是在帮组织把几件事分得更清楚: 什么是忙,什么是价值; 什么是位置,什么是能力; 什么是过去那套靠人堆起来的稳定,什么才是以后还能留下来的管理。 ## RM 08 不会写代码的我,改掉了“没有我不行” 管理者最容易上瘾的成就感,叫没有我不行。 原文 https://aifellow.ai/articles/rm08 最近我越来越怕一种感觉。 不是忙。 是很多事明明不复杂,却总要等我出现,才真正往前走。 前几天我连续在外面开会,晚上回头看当天推进,突然发现一个很不舒服的细节: 几个节点都停在同一个状态。 不是不会做。 不是没人做。 而是默认要等我再看一眼,再点一下头,再补一句话。 那一刻我忽然警觉到一件事: 管理者最容易上瘾的成就感,叫“没有我不行”。 ## 没有我不行,很多时候只是依赖 它听上去像能力。 很多时候,其实只是依赖。 也就是从那一刻开始,我第一次认真怀疑: 我平时做的,到底有多少是在管理, 又有多少,只是在充当一套还没被写出来的系统? ## 把最依赖我的那一段写进系统 后来我没再开会,也没再发提醒。 我做了一件以前我默认应该交给技术的人做的事: 把最依赖我的那一段,自己写进了系统。 但后来我发现,“系统”这个词,其实说大了。 它不是一套大而全的管理系统。 更像是一组很碎、但很管用的东西: 一个卡点,一张多维表格。 一个节点,一个小工作台。 再把规则、提醒、留痕这些该补的地方,一点点补上。 单看都不大。 但它们刚好把过去最依赖我、也最耗人的那一段,接住了。 我不会写代码。 但我会拆动作。 我知道哪一步是标准件,哪一步必须有人拍板,哪一步最容易漏,哪一步一漏后面一定返工,哪一步可以自动往前推,哪一步绝对不能装聪明。 所以我先做的,不是追求做一个多完整的系统。 而是先把那些总在卡人的地方,重新写一遍。 有的收进表里,有的放进工作台,有的交给提醒和留痕。 这些小东西陆续跑起来以后,最打动我的,不是“效率提升”这四个字。 而是安静。 临时确认少了。 重复确认少了。 那些原本必须靠我补一句、催一下、盯一下的动作,少了。 一个个原来总要靠人扶一下的节点,开始自己往前走,人终于不用整天挂在上面。 ## 抢险不是设计 那一刻我心里冒出来的不是兴奋。 是发凉。 因为我第一次认真怀疑: 过去很多我以为自己“会管理”的地方,到底是什么? 我会盯、会催、会兜底,当然算能力。 但那更像抢险能力,不像设计能力。 一个离了我就塌的流程,本来就不该算一个成熟流程。 说得再狠一点: 很多管理者最值钱的时候,不是在做管理。 是在给一套高度依赖人在场的流程补位。 甚至很多管理者真正的岗位说明书,写出来可能只有一句: 当一个流程快要慢下来时,赶过去把它扶住。 ## 最懂问题的人开始直接动手 最近很火的一个词,叫 vibe coding。 很多人只看到最热闹的那层: 不会写代码的人,也能做点东西了。 我真正觉得可怕的,是另一层。 最懂问题的人,第一次不用把自己的意图翻译三遍,才有机会改系统。 以前你明明知道堵点在哪。 你知道哪一步最容易返工。你知道哪个口子最该收。你知道哪一步其实不该再靠临时提醒。 可你还是得写需求,排优先级,等开发,等测试,等上线。 中间每多一层翻译,真实问题就少一层。 很多系统最后做出来,看上去像是在解决问题,实际上只是把问题换了个更漂亮的壳。 现在不一样了。 最知道哪里疼的人,开始有机会直接动手。 这才是这一轮变化最扎人的地方。 它撞到的,不只是技术部门。 它撞到的是管理者原来那套活法。 因为一旦系统开始吃掉提醒、汇总、流转、催办这些东西,很多过去被默认值钱的动作,就会被迫重新估价。 你以前觉得自己不可替代,未必是因为你判断有多厉害。 很多时候,只是这套流程还没有被真正写成系统,离不开你站在中间传话。 没有我不行。 这句话以后会越来越危险。 有时那不是能力证明。 只是组织里还存在一段必须靠人去接的空白。 ## 别再把没有我不行当成成就 所以我现在越来越相信一件事: 未来最贵的管理者,不是最会盯人的人。 而是最会把“必须靠我盯着才行”,改成“少盯也能跑”的人。 这不是一句技术口号。 这本来就是管理。 只是以前大家总把管理理解成带人、盯人、压人、催人。 现在你会越来越发现,真正拉开差距的,是另一种能力: 把经验写成规则,把判断写进节点,把例外留给真正该拍板的人,把那些本来靠人肉补丁维持的东西,重新做成系统。 而且很多时候,根本不用一上来就做什么大系统。 真正值钱的,是你知不知道先拆哪一个卡点,先拿掉哪一段反复消耗人的摩擦。 所以我现在反而不太想劝人去学编程。 编程当然重要。 但对大多数管理者来说,真正该补的,根本不是语法。 而是你敢不敢正面回答这几个问题: 这件事为什么总要靠我盯? 哪一步其实早就该写成规则? 哪一步看似复杂,其实只是一直没人下决心收口? 哪一步必须保留人工判断,否则风险会失控? 这些问题想不清楚,再好的模型也只是一个热闹的玩具。 这些问题一旦想清楚,代码反而可能是后面最不难的部分。 说到底,AI 不是来削弱管理的。 它只是把一种假管理照亮了。 那种管理的核心价值,不是判断,不是取舍,不是设计。 而是传话、催办、补洞。 以前这套东西也值钱,因为没别的办法。 以后它会越来越便宜。 所以这篇给我最大的提醒,不是“不会写代码的人也能做系统了”。 而是: 别再把“没有我不行”轻易当成成就。 很多时候,那不是你厉害。 那只是系统还有一段必须靠你亲自去接。 真正能把人拉开差距的,是你能不能把那一段最依赖你的地方,重新做成系统。 如果能,你会比以前更值钱。 如果不能,你很快就会发现,组织里最先被压价的,恰恰是那种永远站在中间提醒别人的人。 ## RM 07 你的部门墙,AI 看不见 层级变薄改的是组织图。部门墙一松,改的是事情怎么跑。 原文 https://aifellow.ai/articles/rm07 这两个月,很多公司都在讨论一件事: AI 进来以后,组织会不会变扁? 很多人盯着的是层级。 但我越来越觉得,真正先开始松的,往往不是层级。 而是部门墙。 这不是一个小变化。 因为层级变薄,顶多是组织图改了。 可部门墙一松,改的是事情到底怎么跑。 上个月,我想改一个看上去很小的流程。 新员工入职,总有人第一周迟迟进不了状态。 不是人不行。 而是工牌没下来,电脑没配好,账号权限没开全,座位和门禁还在等,欢迎物料也没跟上。 表面看,这些事分属 HR、行政、IT、财务、品牌。 可对一个新人来说,这根本不是五件事。 这就是一件事: 让他第一天就能正常开工。 后来我越看越觉得,很多公司真正麻烦的,不是流程不够细。 而是明明是一件完整的事,进了组织以后,硬生生被拆成了很多句: “这不是我的部分。” “这个得等他们。” “这个我们只能配合。” “这个要不要你先去问一下那边?” 也就是那一刻,我突然意识到: 部门不是问题。 部门墙才是问题。 一句更直的话是: 部门是分工。 部门墙是成本。 为什么现在更该把这件事单独拎出来讲? 因为这轮 AI 讨论,已经变了。 前一阶段,大家还在问: 它会不会写,会不会搜,会不会做 PPT。 这两个月,问题已经变成了另一种: 能不能接企业微信? 能不能接 OA? 能不能接表格、审批流、知识库? 能不能直接查异常、催节点、改状态? 3 月 10 日,信通院启动可信互联网智能体测试评估,里面有四个词,我觉得特别关键: 功能可信、权限可靠、操作透明、行为可干预。 这四个词背后,其实只有一句人话: 大家真正开始担心的,已经不是 AI 会不会说。 而是它会不会开始做。 一旦它开始做,很多过去被默认接受的部门边界,就会第一次显得很奇怪。 因为系统不会天然理解这些组织空气: 这个动作归谁。这个口径谁说了算。这个数据虽然能看到,但该不该碰。这一步做到哪儿必须停下来等人。 人进组织久了,会默认接受这些东西。 AI 不会。 它只会顺着任务往前走。 ## 部门以前为什么合理 我越来越不喜欢一句很轻飘的话: “以后没有部门了。” 这句话听着很新,实际上很悬。 部门当然不会消失。 因为专业分工从来不是多余的。 HR 管人的规则。财务管钱的规则。法务管风险的规则。运营管现场的规则。 这些边界过去之所以成立,不是因为大家爱守地盘。 而是因为知识、责任、权限和风险,本来就分散在不同地方。 所以很多公司真正的问题,从来不是“为什么有部门”。 而是: 为什么一件事只要一跨部门,就立刻开始变慢、变厚、变得需要中间协调。 过去这件事没那么容易被质疑。 因为以前没有更好的办法。 一个动作从 HR 走到行政,再走到 IT,再走到财务,中间总得有人接、有人解释、有人确认、有人追节点。 墙越厚,中间就越需要人来传。 很多层级,很多协调岗,很多看起来很忙的管理动作,本质上都在替这些墙买单。 所以我现在会把这件事说得更直一点: 部门不是错。 错的是一件事必须穿过五堵墙,才算完成。 ## AI 天然按任务走,不按部门走 这才是这轮变化真正扎人的地方。 你给一个系统任务,它不会先看组织架构图。 比如你让它处理“本周异常订单”,它天然会去做这些事: 拉数据。比规则。看上下文。判断哪些该回访。哪些该补资料。哪些该升级。 它不会先停下来问: 这到底算运营、客服、财务,还是风控? 再比如入职、报修、报销、采购、客诉处理、合同流转,这些事在真实组织里,几乎没有哪一件是单部门动作。 它们本来就是一条任务链。 只是过去我们没有更好的处理方式,只能把一条任务链切开,塞进不同部门,再靠人反复传递,把它勉强缝回去。 但 AI 一进来,第一反应不是“我属于哪个部门”。 它的第一反应是: 为了把这件事做完,我下一步需要什么数据、什么规则、什么权限。 这就是为什么我一直在说: AI 不认你的组织架构图。 它只认任务、数据、规则和权限。 一旦任务逻辑开始压过部门逻辑,很多原来默认合理的边界,就会忽然显得很笨重。 很多公司接下来第一次感到刺痛的,不是人少了。 而是以前那些“必须这样传一下”的动作,突然开始显得很不值。 ## 真正开始贬值的,不是专业,而是“守门” 很多专业条线的人一听到这里,会本能地紧张。 好像一谈 AI 跨边界,就等于否定专业。 其实不是。 专业不会变轻,只是价值锚点会变。 以前很多岗位的价值,建立在一句话上: “这个只有我懂。” 因为只有你看得懂,所以别人得来找你。因为只有你能判断,所以流程必须从你这儿过。因为只有你知道红线在哪,所以组织天然会围着你设一道门。 但以后更值钱的,不会只是“我懂”。 而会是: 我能不能把我懂的东西,写成别人也能跑的规则、接口和系统。 说得再尖一点: AI 不是在取消专业。 它是在取消专业的守门费。 以前专业的价值,很多建立在守门。 以后专业的价值,会越来越建立在制规则。 守门是“没有我不行”。 制规则是“没有我定不出来,但定出来以后,不必事事经过我”。 未来专业部门真正的段位,不是墙筑得多高。 而是它能不能把自己的专业判断,变成整个组织都用得起的能力。 ## 真正会出事的,不是拆墙,是墙松了以后没人重写接口 这里最容易被说轻的一点是: 部门墙不是说拆就拆。 很多人一听到“AI 跨部门”,就容易兴奋过头,好像系统一接起来,摩擦自然就没了。 不是。 如果没有接口设计,没有权限分层,没有审计和回滚,没有例外处理机制,那墙一松,很多问题不是变少,而是会放大。 所以我越来越不把这件事叫“去部门化”。 我更愿意叫: 把部门墙改成接口。 墙的逻辑是阻断。接口的逻辑是连接。 哪些可以直通。哪些必须确认。哪些信息可见不可改。哪些动作一旦触发必须留痕。哪些例外必须回到人来拍板。 这些东西,本质上都不是模型问题。 这是组织问题。 说白了,AI 这次不是来帮你美化流程图的。 它是来逼你回答: 你这家公司,到底哪些边界是真需要,哪些边界只是历史遗留。 ## 最先被压缩的,不是岗位,是“接口权力” 写到这里,我越来越确定一件事: 接下来先被碰到的,不一定是最会干活的人。 很多时候,先被碰到的,反而是那些价值主要建立在“信息从我这里过一下”的位置。 因为部门墙一厚,这种位置就很多。 你知道一点别人不知道的。你手里卡着一段流程。你负责解释两边口径。你要把一个部门的话,翻译给另一个部门听。 这些价值过去当然是真的。 但它们里面有相当一部分,不是因为你判断多厉害。 只是因为墙太厚,只能由你来传。 可一旦任务、数据、规则和状态开始被系统摊开,这种“接口权力”就会先被压缩。 以后更值钱的,不是你还守不守得住这道门。 而是你能不能把这道门,改成一个好用、不失控、还能让事情走得更快的接口。 这也是为什么我会觉得,接下来很多公司真正先松掉的,不是岗位。 而是边界。 不是哪一个部门突然没了。 而是很多原来必须靠部门分割、靠中间协调、靠层层传话才维持住的动作,开始有机会被重新连成一条更短的任务链。 如果说前几篇讲的是制度为什么开始失效,培训为什么开始失效,那这一篇真正想说的是: 组织里下一批先暴露出问题的,不是人。 而是边界设计。 这一步一旦开始,后面管理者就会被逼到另一个更具体的问题面前: 如果很多原来必须靠人盯、靠人传、靠人补位的动作,都开始被重新写进系统, 那管理者最该先改掉的,恰恰就是“没有我不行”。 ## SX 01 人人都在养龙虾,但大多数公司还不会管理智能体 龙虾火,不只是工具火了。底下松动的是组织怎么管执行体。 原文 https://aifellow.ai/articles/sx01 上周四晚上11点,一个朋友给我发来一张电脑截图。 下面只有一句话: “你帮我也养一只龙虾。” 他是传统行业的管理岗,白天刚开完经营会,晚上就开始研究怎么让智能体盯流程、催审批、查异常。聊到最后,他问了一个现在很多管理者都会问的问题: “这东西既然会操作电脑,是不是可以先把后台的一部分活接过去?” 这不是个例。 过去十天,我收到最多的消息,不是“AI到底有没有用”,而是类似的请求。有人想让它订会议室、做周报、查数据;有人想让它回客户、催流程、追节点;还有人一上来就先问裁员,仿佛龙虾一装,组织就能立刻轻一半。 这股热度当然不是错觉。3月上旬,信通院启动可信互联网智能体测试评估,网络安全侧也连续发出风险提示,多家厂商开始快速跟进。一个原本还在技术圈内部流转的东西,突然被老板、管理者和一线团队同时盯上了。 这时候我反而更确定一件事: 龙虾火,不只是工具火了。它第一次把一个管理问题,伪装成了一个大众热点。 ## 最大的误解,是把它当成更能干的助手 大家表面上在讨论“怎么养龙虾”,底下真正开始松动的,是组织该怎么管理一个既像工具、又像执行体、还能跨边界行动的新对象。 很多公司现在对智能体最大的误解,是把它理解成一个更能干的AI助手。 会写字,会搜资料,会点按钮,会跨应用调用,于是很自然地得出结论:既然它能干活,那就把活交给它。 问题恰恰出在这里。 “把活交给它”这句话,对一个人和对一个智能体,不是同一回事。 把活交给一个人,你默认他知道边界。知道什么时候该停,知道遇到例外先来问一句,知道哪些信息虽然系统里看得到,但实际上不该碰,知道这个动作虽然能做,但今天不能做。 但智能体没有这些“默认共识”。 如果你没有提前给它设计好权限、反馈、审计和回滚,它不是“多了一个能干的员工”,而是“多了一个高权限的不确定变量”。 所以我现在越来越少问一个问题: “龙虾能不能用?” 我更在意另一个问题: 公司到底会不会管智能体。 ## 智能体按任务走,公司按部门管 为什么我说这是管理问题,不是技术问题? 因为智能体天然不按部门边界工作。 你给它一个任务,比如“整理本周业务异常并给出处理建议”,它不会像传统组织那样先停下来问: 这算运营的事,还是财务的事? 这个数据归谁? 要不要先跨部门开会? 谁来牵头、谁来抄送、谁来协调? 它会直接穿过去。 去拉数据,读上下文,比规则,给建议。权限放得再大一点,它甚至会发消息、建日程、改状态、推流程。 也就是说,智能体天然按任务走,不按部门走。 而大多数公司的管理系统,正好相反。 公司天然按部门管,不按任务管。 这两套逻辑一撞上,问题就出来了。 过去一个流程为什么需要那么多人来回传递?不是因为动作本身有多难,而是因为信息在不同部门手里,权限在不同层级手里,责任在不同岗位手里,所以必须靠人来穿针引线、反复确认。 现在智能体最危险、也最有价值的地方,恰恰在这里: 它开始碰到组织里原来只能由人穿行的那部分接口。 这已经不是“AI写不写得出文案”的问题了。这是“组织要不要让一个非人执行体穿过部门墙”的问题。 所以很多老板现在嘴上说想养龙虾,心里真正焦虑的,根本不是部署。 他们焦虑的,是另外四件更难的事。 ## 哪些事真的可以交给它 不是所有工作都适合上智能体。 重复、清晰、规则稳定、结果可验证的任务,最适合。边界模糊、例外很多、强依赖关系判断和现场博弈的任务,最危险。 如果你连任务都没拆开,就直接问“这个岗位能不能上龙虾”,那不是在做AI转型,是在凭感觉赌博。 岗位从来不是一个动作。岗位是很多任务的捆绑包。而AI能接住的,通常只是其中一部分。 很多企业后面出问题,不是因为龙虾不够强,恰恰是因为一开始把“能替一部分任务”误解成了“能替一个完整岗位”。 ## 它到底能看到什么,能做到哪一步 很多公司现在讨论智能体,还停留在功能清单: 能不能接微信,能不能接表格,能不能接OA,能不能自动回消息。 但真正该先定的,不是功能清单,是权限清单。 它能读什么? 能写什么? 能改什么? 能不能直接发出去? 做到哪一步必须停下来等人确认? 没有这张表,所谓“养龙虾”,本质上只是把组织的高权限风险,装进一个更性感的壳里。 ## 出了错,谁能及时中断和回滚 人犯错,组织已经很熟了。 谁来背责,谁来补救,谁来解释,流程大致都知道。 但智能体犯错,很多公司其实还没有机制。 它误发了、误删了、误判了、误触发了,谁先发现? 谁有权一键停掉? 谁能追到它刚才到底做了什么? 谁来判断这是模型问题、流程问题,还是授权问题? 如果这些都没有,智能体能力越强,组织只会越紧张。因为每一次“看起来很聪明”的自动化,背后都可能藏着一次没人接得住的失控。 ## 它进来之后,人要重新怎么分工 这是最容易被忽略的一步。 很多人一看到智能体,先想到的是“能少几个人”。 但更成熟的问题应该是:这部分重复动作被接走之后,留下来的人应该去做什么? 去补例外判断? 去做跨部门协同? 去维护规则? 去盯风险? 还是去成为新的流程架构师、知识维护者、智能体管理员? 如果这个问题不提前想清楚,最后常见的结果不是人真的少了,而是: 系统接走了一部分轻活,组织留下了一堆更重的复杂度,最后全部压回到剩下的人身上。 所以在我看来,真正会用智能体的公司,至少会先做四件事: 1. 先把岗位拆到任务层,而不是直接看岗位名称。 2. 先把权限拆到动作层,而不是默认“能接入就能执行”。 3. 先把流程做成可中断、可追溯、可回滚,而不是一上来就追求全自动。 4. 先把人机分工重新定义清楚,而不是把智能体当成一个突然空降的万能外包。 这四件事做完,才叫开始管理智能体。 不然,大多数所谓“养龙虾”,最后都只会停在三个阶段: 装上了。演示了。然后不知道该把它真正放进哪里。 这也是为什么这波龙虾热我反而特别想写。 因为它第一次把一个很硬的管理问题,借着一个很软的大众热点,推到了台前。 表面上,大家在问: “龙虾到底能不能替我干点活?” 底层真正开始松动的是: 组织到底该怎么管理一个既像工具、又像执行体、还能跨边界行动的新对象。 过去我们一直以为自己在管理流程、制度和岗位。现在才发现,很多时候我们真正管理的,只是人肉中转、权限摩擦和部门墙。 一旦这些东西开始被智能体绕过去,管理本身就要被重写了。 真正值得追的,不是龙虾本身。 而是龙虾先撞塌了哪一层旧管理逻辑。 ## RM 06 3000 人的集团,和 30 人的团队,差距为什么开始没那么大了? 大公司过去最值钱的隐形资产,叫层级红利。 原文 https://aifellow.ai/articles/rm06 如果上一篇讲的是部门墙开始松了,那这一篇要继续往下讲的,就是: 墙一松,什么会跟着变。 很多人最近看“裁中层、去层级、去官僚化”这波讨论,第一反应都是降本。 我不完全这么看。 真正开始被改写的,不是谁的岗位。 真正开始被改写的,是组织处理复杂度的方式。 再说得更直一点: 很多大公司过去最强的地方,恰恰是接下来最先被 AI 改掉的地方。 过去一年,几条看上去不相干的线,正在往同一个地方汇。 Amazon 在压管理层比率。Shopify 把“会不会用 AI”抬成默认要求。Klarna 则直接把答案交出来了:人还是那些人,但人均产出已经不是原来的算法了。 很多人看这些新闻,看到的是三家公司在做三件不同的事。 但我越来越强烈地觉得,它们其实都在做同一件事: 把组织里原来靠中间层消化的那部分复杂度,改给系统。 翻译得再直白一点,就是: 3000人的集团和30人的团队之间,过去那道很硬的管理差距,开始松了。 不是因为大公司突然不行了。也不是因为小团队突然开挂了。 而是因为大公司过去最值钱的一块隐形资产,正在被改写。 那块资产,不叫品牌,不叫资金,不叫 headcount。 它叫: 层级红利。 一句话总结就是: 以前大公司赢在“人能接住复杂度”,以后越来越多公司会赢在“系统能吞掉复杂度”。 ## 墙一松,层级红利就会开始变薄 上一篇已经讲过,很多层级之所以存在,本来就是为了替部门墙支付中间的沟通成本。 信息分散在不同部门。权限锁在不同岗位。规则写在不同口径里。 所以事情只要一跨出去,就得有人在中间接、在中间翻、在中间盯。 这也是为什么我一直说: 先松的是横向边界。 后薄的,才是纵向层级。 因为边界一松,很多原来只能靠层级承担的工作,就会开始失去存在理由。 所以这篇真正想谈的,不是“裁不裁中层”。 而是: 为什么3000人的集团和30人的团队之间,过去那道很硬的差距,会开始没那么大。 ## 大公司过去最强的,不是资源,是“层级红利” 很多人谈大公司和小团队的差别,第一反应总是资源。 钱更多。人更多。流程更全。分工更细。 这些都对。 但站在管理视角看,过去真正把差距拉大的,其实不是资源本身,而是大公司有能力养一层又一层“处理中间那段”的人。 30人的团队为什么很多时候跑得快? 不是因为它更会管理。 很多时候恰恰相反。 它快,只是因为短。 问题出来了,很快能被看见。看见问题的人,离能拍板的人不远。一个动作做错了,中午知道,下午也许就改了。 这种团队当然也会乱。 靠人扛,靠熟人默契,靠老板本人盯着,一旦复杂度上来,立刻露底。 但它有个天然优势: 信息不用走太远。 3000人的集团就不是这个逻辑了。 一个问题从一线冒出来,要有人接住,要有人整理,要有人判断是不是例外,要有人决定留在本层解决还是继续往上送。上面拍完板,还要再有人把意思拆开,拆成下面听得懂、做得动、也愿意做的动作。 所以层级首先不是权力结构。 层级首先是一种信息处理结构。 过去大组织为什么离不开中间那几层? 不是因为它天生官僚。 而是因为它的信息处理成本太高了。 谁来接信息。谁来压缩信息。谁来翻译信息。谁来盯住中间不失真。谁来把高层一句话,变成下层一串能执行的动作。 放在小团队里,这套事很多时候可以靠短链路硬扛。 放到大组织里,不长出中间层,根本转不起来。 所以过去大公司真正强的,不只是人多。 而是它养得起一层又一层专门处理中间复杂度的人。 这就是大组织长期享受的层级红利。 一句更狠的话是: 很多大公司的效率,不是高在决策本身,而是高在它有足够多的人负责把决策送到正确的地方。 ## AI 先砍掉的,偏偏就是这层红利 这也是为什么最近这波“裁中层”的讨论,不能只看成人头变化。 很多中层岗位里,原来一直混着两种完全不同的价值。 一种是真正值钱的管理价值: 带人。拍板。扛冲突。稳节奏。在灰度地带做取舍。 另一种,是组织历史上不得不长出来的中转价值: 汇总。转述。催办。补洞。追节点。对口径。在几个部门之间来回确认“现在到底到哪一步了”。 前一种,接下来不会便宜。 后一种,才是最先被 AI 碰到的部分。 一句话概括就是: 很多中层岗位里,最先贬值的不是判断,而是搬运。 因为 AI 真正危险的地方,从来不是它会写一段话。 它真正危险的地方,是它开始吃掉中间那一段。 以前一个负责人一天能盯住5件事,现在可能能盯20件。以前周报、异常、进度,全靠人重新捏成一份给上面看,现在系统先做了第一轮。以前跨部门对齐要反复开会,现在状态、责任和节点先被摊到了台面上。 你把 Amazon、Shopify、Klarna 这三条线摆在一起看,就会发现它们讲的是同一件事: 不是“AI 要不要用”。 而是“组织里到底还有多少信息处理中转,必须继续靠人来做”。 这才是更大的变化。 AI 不是先削弱大公司,它先削弱的是大公司的层级红利。 这句话如果放到今天的管理讨论里,分量其实很重。 因为它意味着: 过去只有大组织扛得住的复杂度,现在小团队也开始能接一部分了。 ## 真正被压缩的,不是岗位数量,而是“中间那段距离” 这也是我觉得今天最容易被说浅的一点。 很多人一提扁平化,脑子里想的都是: 少几层。少几个人。少几个 title。 但扁平化真正难的,从来不是“少”。 而是少了以后,事情还能不能照样跑。 原来中间那层一走,谁来收口? 谁来接例外? 谁来处理跨部门之间那些模糊又高频的摩擦? 如果这些东西只是从人身上拿掉,却没有被系统接住、被流程重写、被权限重新分配,那组织只会更乱。 所以我越来越相信一句话: 扁平化不是少几个职位。 扁平化是少几次信息转译以后,事情还能照样跑。 这句话为什么重要? 因为它把“裁中层”从一个情绪化话题,重新拉回到了真正的管理问题上。 你不是在决定裁不裁。 你是在决定: 这家公司的信息处理方式,到底还要不要继续建立在那么多层人工中转之上。 所以真正先进的,不是敢砍人。 真正先进的是: 少几层以后,组织还能不能不失真、不失速、不失控。 ## 30人的团队,为什么开始逼近3000人的一部分能力 这件事对小团队的冲击,其实比对大公司还大。 过去小团队最吃亏的,不一定是判断慢,也不一定是执行差。 最吃亏的是,一旦复杂度上来,它没有接法。 项目一并行,就开始乱。角色一交叉,就开始卡。一出现例外,就只能老板亲自下场补洞。 所以过去很多小团队想变强,最自然的路径就是加人。 多一层管理。多一层协调。多一层兜底。 可现在,小团队第一次开始拿到一种过去更像“大公司专属”的能力: 不是资源能力。 是复杂度处理能力。 它不一定要先长到300人,才有像样的流程。也不一定要先堆出很厚的中间层,事情才勉强转得动。 如果流程、模板、权限、反馈系统做得够顺,很多过去必须靠“再加一个人盯着”才能解决的问题,现在可以先被系统吃掉一部分。 这就是为什么我说,3000人的集团和30人的团队,差距开始没那么大了。 不是所有差距都没了。 品牌、资金、渠道、行业位置,这些差距还在,而且还很大。 但“组织越大,管理能力天然越强”这件事,开始不再绝对成立。 以后越来越像: 谁的系统更强,谁就更能把少量人撬成更大的产出。 一句更适合今天这个时代的话是: 未来真正拉开差距的,不是编制规模,而是系统吞吐量。 ## 未来最不值钱的,可能就是“我下面有多少人” 以前很多管理者介绍自己,最习惯先报一个数字。 我管300人。我管800人。我带一个几千人的体系。 以前这个数字当然重要。 它背后代表的,是管理半径、协调复杂度和信息处理压力。 但接下来,这个数字会越来越不够解释你的价值。 因为同样是30人,有的团队一扩张就散。 也有的团队虽然人不多,但规则清楚,接口稳定,很多动作自己就往前滚。 同样是3000人,有的组织层级很厚,但真正有效的信息处理能力并不高。 会很多。报表很多。审批很多。确认也很多。最后速度还是慢,失真还是重。 所以未来真正拉开段位的,不会只是“你带多少人”。 真正拉开段位的,会越来越像另一件事: 你能不能让更多复杂度不靠人盯,也能跑起来。 过去的管理杠杆,很多是人头杠杆。 未来更值钱的,是系统杠杆。 不是你下面站了多少人。而是你设计的这套系统,到底能吞掉多少复杂度、撬动多大的产出。 所以一句话,这篇文章真正想说的是: 未来决定段位的,不是带队规模,而是系统半径。 ## 这轮变化真正难的,根本不是“裁不裁” 我写到这里,最想说的反而不是“以后中层要消失了”。 恰恰相反。 管理不会消失。 只是那些原来靠层级维持、靠传达维持、靠中间信息处理维持的部分,会越来越便宜。 真正变贵的,是另外那部分: 谁来定规则。谁来设接口。谁来决定什么该标准化,什么必须保留人为判断。谁来把一个组织从“层层确认才能跑”,改成“少几层也照样能跑”。 所以最近这波讨论,如果只停在“哪个公司又裁中层了”,其实还是浅。 更值得追问的是: 它裁掉的,到底是低价值的中转层,还是本来就没人真正重建过的管理能力? 如果只是把层级砍掉,后面大概率会乱。 但如果它真的把信息处理方式、流程接口和责任边界一起重写了,那它改掉的就不是某一层岗位,而是整个旧组织结构最底下那块地基。 再说得更狠一点: 过去很多管理者证明自己,靠的是“我下面有多少人”。 以后很多管理者还想证明自己,得换一种方式: 不是看你管多少人,而是看你少几层人,系统还能不能照样跑。 前者拼编制。后者拼设计。 编制会越来越便宜。设计会越来越贵。 所以这轮变化里,真正危险的,不是中层少了。 真正危险的是,你还把自己当成那个负责传达、监督、层层确认的人。 因为那种管理者,不是会更累。 是会越来越贵,最后越来越难被留下。 而且别忘了,这轮变化不是只把层级压薄。 它更早一步,已经把很多原来被部门墙锁住的专业边界撞松了。 所以接下来真正更值钱的,也不会只是“会管人”。 而是你能不能在边界更松、层级更薄的情况下,重新把规则、接口、权限和例外处理设计出来。 ## RM 05 你花 100 万搞的培训,一个模板就能替代 会上听懂,到回去做对,中间隔着很长一段路。 原文 https://aifellow.ai/articles/rm05 去年有一次,我坐在一场培训会的后排,听得有点烦。 讲得不差,甚至挺完整的。 背景讲了,流程讲了,红线讲了,案例也讲了。台上的人很认真,下面的人也都在点头。中间还专门留了答疑时间,问到最后,大家看上去都懂了。 结果一周以后,还是那批问题。 该填错的继续填错。该漏的继续漏。该绕开的动作,还是有人绕开。 那天我第一次把一个以前没想透的事想透了: 很多公司培训并不少。问题是太相信“讲过一次,人就会记住”。 这件事听上去很正常,放到真实组织里,其实很危险。 因为一个人从“会上听懂”,到“回去做对”,中间隔着很长一段路。 他得先记住。然后在具体场景里想起来。再判断这次是不是适用。最后还得愿意按那个标准去做。 这里面任何一步断掉,前面那场培训基本就白做了。 后来我越来越觉得,很多培训一开始就背了不该它背的锅。 为什么现在更值得把这件事翻出来重写? 因为最近几个月,很多公司又开始密集做 AI 培训、AI 普及课、AI 工作坊。 2026年1月,Workday 一份全球调研提到,66%的管理者把技能培训列成优先事项;但同一份调研里,89%的组织中,不到一半岗位真正按 AI 能力改过设计。2月,Multiverse 又披露过一个更刺眼的落差:59%的管理者以为团队已经在经常用 AI,真实员工比例只有42%。 大家都在补课。但真正没跟上的,往往不是课时。是岗位、流程和工具本身还停在旧结构里。 ## 培训最大的问题,不是贵 很多管理者吐槽培训,第一反应是贵。 请讲师要钱,做课件要钱,抽人参会有机会成本,做完还要考试、回收、复盘,算下来当然不便宜。 但培训真正的问题,其实不是贵,而是太依赖人的记忆。 而记忆这东西,在组织里是最不稳定的。 今天记住了,明天不一定记得。老员工记得,新员工不一定知道。总部讲明白了,到了门店、到了区域、到了具体岗位,理解又会慢慢变形。 所以很多公司一出问题,就本能地说: “再培训一轮。” 这句话我以前也常说。后来越说越没底。 因为第二轮、第三轮、第四轮培训,本质上都在做同一件事: 反复把规则往人脑子里塞。 可人脑不是系统。 它会忘,会漏,会在忙的时候走捷径,会在现场根据经验自作聪明。你不能一边默认这些都存在,一边又指望靠一场培训把执行拉齐。 这不现实。 ## 后来我开始少做一件事:反复讲 这几年我有个很明显的变化。 以前一接手新业务,发现动作不统一,第一反应是: 先写清楚,再培训一遍。 现在不是了。 我会先看,这件事到底有没有可能不靠“记住”,而靠“做的时候自然做对”。 比如有些动作,根本不是员工不会,而是太容易做错。 字段太多,顺序太乱,判断标准藏在别的文档里,审批节点卡在某个人那儿,出了例外还得靠微信问。 这种时候你再去搞培训,效果通常很一般。 因为你没有解决真正的问题。 真正的问题是: 系统把“做对”这件事设计得还不够容易。 后来我们改过一批动作。没做什么宏大升级,甚至算不上什么“数字化项目”。更多是在多维表格上做文章。 就是把原来靠口头提醒、制度附件、培训PPT维持的那套要求,一点点塞进模板、表单、流程和提示里。 哪个字段容易错,就直接改成选项。哪个判断总被漏,就放到提交前强提醒。哪个动作必须先完成,后面的按钮就先不给你。哪个材料总被打回,就在上传位置直接写清标准。哪一步最容易卡,就把责任人和时点自动带出来。 做完以后最明显的变化不是“大家学会了”。 而是很多人根本不用额外学,就已经没那么容易做错了。 这件事对我的刺激很大。 因为它逼着我承认: 以前很多被我当成“培训问题”的东西,其实是设计问题。 ## 我后来慢慢认了:最好的培训,往往不像培训 有段时间我很不愿意承认这个判断。 因为一承认,管理者很多熟悉的动作就会显得有点尴尬。 我们太习惯于通过培训证明自己在管理了。 出了问题,培训。标准不齐,培训。新人进来,培训。系统变了,培训。执行走样,还是培训。 培训很容易被看见。 它有通知,有签到,有照片,有课件,有会后测试,写进周报也好写。 但这些东西和结果之间,常常差得很远。 我不是说培训没用。 有些事情一定要讲,比如价值观、复杂判断、风险意识、跨部门协作里的灰度处理,这些不能只靠系统。 但大量日常执行动作,真的不该继续把希望放在“我讲过了,你就该会”上。 这句话太偷懒了。 它看上去是在要求员工,实际上是在替设计失误找补。 如果一个动作每个月都要靠培训反复强调,通常不是人太难教。 是这个动作根本不应该主要靠“教”来维持。 它应该被写进环境里。 写进模板。写进流程。写进默认值。写进权限。写进系统那几个你点不过去的地方。 到这一步,我才慢慢明白为什么有些组织培训很多,执行还是散。 因为他们一直在训练人,没怎么改环境。 ## 一个好模板,替代的不是一堂课 很多人听到这里,会把“模板”理解得太轻。 好像只是做一张表,或者整理一份标准答案。 其实不是。 一个真的好用的模板,替代的往往不是一堂课。 它替代的是后面那一串东西: - 重复解释 - 反复返工 - 口径不一 - 人盯人催 - 老员工带新人时的手把手纠偏 它甚至替代掉一部分管理者最熟悉的“监督感”。 因为以前你总觉得,自己要反复说、反复看、反复提醒,事情才算在掌控中。 但模板、流程、系统如果做得够细,那种掌控感会开始转移。 不是你盯着,人才能做对。 而是你前面设计得足够细,后面很多地方就不需要一直盯着。 我后来慢慢发现,管理里真正值钱的,不是你能不能把一件事讲得特别漂亮。 更值钱的是: 你能不能把一个要求做成别人不用怎么记、也不太会做错。 这和写一份精彩课件,已经不是同一种能力了。 课件更像表达。模板、流程、系统,才更接近运行。 表达以后会越来越便宜。 能把事情稳稳跑起来,这部分不会。 ## 这件事最后会改掉什么 我现在对培训这件事,没以前那么迷信了。 该做还是做。 只是会先分。 到底哪些东西,必须靠人讲。哪些东西,更适合让人做的时候自然做对。哪些东西,不该继续靠管理者一遍遍提醒来维持。 这不是一个小调整。 它后面会动到很多老习惯。 培训部门以后最值钱的,可能不再只是“会做课”。而是能不能把知识做进系统、做进工具、做进场景。 管理者以后最值钱的,也不再只是“能把要求说清楚”。而是能不能把要求变成一个稳定运行的环境。 我最近越来越强烈地感觉到,很多公司现在其实还停在旧逻辑里。 出了执行问题,就继续追加宣导。出了质量波动,就继续追加学习。出了流程跑偏,就继续追加考核。 这些动作不是完全没用。 但很多时候,它们只是比真正的改动更省力,所以才被优先选择。 真正难的那一步一直没做: 承认问题不在“大家没听懂”,而在“系统还没把正确动作托住”。 这一步一旦承认,很多管理动作都得改。 培训只是其中之一。 如果模板、流程、系统真的开始接住越来越多原来靠人盯、靠人教、靠人记的动作,接下来更难的问题就不是“还要不要继续培训”,而是: 那些原来负责传达、监督、层层确认的人,中间还有多少层是必须的? 最近这波“裁中层、去层级、去官僚化”的讨论,很多人看见的是人头变化。 我更在意的是另一件事:当信息处理、追踪、纠偏开始被系统接住,组织为什么还需要那么多层人来传? ## RM 04 你最值钱的能力,AI 三秒就学会了 AI 解决从空白到选项。人要负责从选项到决定。 原文 https://aifellow.ai/articles/rm04 上个月带部门做方案时,第一次有了很明显的失落感。 那是一个典型管理场景。费用不能再涨,团队情绪要稳,老板又希望动作快一点。我原本以为,这种事至少要折腾两三天,拉数据、做测算、写三版不同口径的方案,再准备一堆“如果老板追问,我怎么解释”的补充页。 结果这次,我把约束条件、目标和顾虑喂给 AI,二十分钟不到,它给了我五版。 - 有一版最省钱 - 有一版最稳团队 - 有一版最容易跟业务解释 - 还有一版把短期压力和中期空间都平衡得不错 那一刻我突然意识到,过去很多年里我很值钱的一项能力,正在被迅速压缩: 把一件复杂的事,整理成一版像样的方案。 以前这件事很稀缺。现在它正在变得越来越便宜。 但真正让我停住的,不是 AI 出得快。 而是它给我五版之后,我发现最难的问题才刚刚开始: 到底选哪一版? 哪一版最适合当前的组织状态? 哪一版的代价,是现在能承受的? 哪一版今天看上去最好,三个月后会反噬你? AI 解决的是“从空白到选项”的问题。我真正要负责的,是“从选项到决定”的那一下。 ## 从空白到选项,正在变便宜 过去为什么“会出方案”这件事这么值钱? 因为过去最稀缺的是信息、结构和表达。 信息分散在不同人手里,结构藏在老手脑子里,表达能力又决定了一个方案能不能被老板看懂、被团队接受、被别的部门买单。所以一个成熟管理者的优势,常常体现在三件事上: - 能把零散信息快速收起来 - 能把复杂问题整理出结构 - 能把结构写成一份能过会、能执行、能留痕的方案 这三件事叠在一起,就构成了很多人对“专业”和“段位”的理解。 谁出方案快,谁就像高手。谁写得漂亮,谁就像有水平。谁一晚上能憋出一版,谁就像关键人物。 问题是,AI 最先接走的,恰恰就是这三件事里最容易被模式化的那部分。 它不会承担责任,但它非常会组织信息。它不会拍板,但它非常会生成版本。它不懂组织政治,但它很会把逻辑写圆。 所以很多管理者最先感到疼的,不是决策权被抢走,而是: 自己最擅长的那部分“方案生产能力”,开始不再稀缺了。 这不是我的个人感受,外部信号也越来越一致。 2025年4月,微软发布了《2025 Work Trend Index》。里面有个细节特别值得看:一边有33%的领导者在考虑通过AI缩减团队人数,另一边却有78%的领导者在考虑为AI新角色招聘。更关键的是,41%的领导者预计未来五年团队要“训练agent”,36%预计团队要“管理agent”。 这组数据的意思,不是“大家都去当程序员”。它更像是在提醒一件事: 未来管理者面对的,不再只是人和流程,还会是越来越多的选项、越来越多的 agent、越来越便宜的方案生产。 同样是2025年,世界经济论坛在《Future of Jobs Report》里预计,到2030年,全球约44%的劳动者核心技能会发生变化。 什么技能会先变便宜?我越来越相信,不是判断力。先变便宜的,是那些可以被快速结构化、快速模版化、快速生成的认知劳动。比如写一版方案、搭一个框架、整理几种可能性、补一版解释口径。 这也是为什么我现在越来越常说一句话: AI不是在抢你的主意,它是在贬值“把主意写出来”这件事。 ## 从出方案,转向选方案 所以,管理者真正值钱的能力正在从“出方案”转向“选方案”。 “出方案”解决的是空白页问题。 你需要搜集信息、搭结构、补论证、想表达。这很考验经验,也很考验熟练度。 但“选方案”解决的不是空白页,而是取舍。你面对的通常不是“对和错”,而是: - 这个方案更快,但会不会伤团队信任? - 那个方案更稳,但会不会错过窗口期? - 这个版本财务最喜欢,但业务会不会根本推不动? - 那个版本大家都舒服,但真正的问题是不是被回避了? 真正的判断是: - 你看清了当前组织最不能承受什么 - 你知道这件事会伤到谁、利好谁 - 你能预判二阶后果,而不是只看眼前数字 - 最重要的是,选完之后,你愿意承担那个后果 出方案是能力,选方案是权力。前者越来越便宜,后者越来越贵。 这也是很多管理者最容易误判的地方。 他们以为自己过去最核心的竞争力,是“我总能拿出一版方案”。 但如果今天一个普通人拿着AI,也能在很短时间里拿出三版、五版、七版,甚至每一版都附上数据测算和风险说明,那你真正的优势还剩什么? 不是文笔,不是版式,也不是“我想到了一个别人没想到的点”。因为这些东西,正在被迅速拉平。 真正拉不开差距的,是你会不会判断: - 这家公司现在到底在什么阶段 - 这位老板真正的风险偏好是什么 - 这支团队现在最缺的是秩序、速度,还是信心 - 这个方案一旦推进,跨部门会在哪个节点开始卡住 这些不是模型参数问题。 这些是你有没有真的在组织里待过、扛过、输过、补过的结果。 AI 可以告诉你“有哪些可能”。但它不知道,你所在的组织此刻最怕失去什么。 AI 可以列出利弊。但它不替你承担利弊背后的后果。 所以我越来越觉得,未来最危险的一类管理者,不是不会用AI的人,而是那种特别会“出方案”,却从来不真正承担判断的人。 过去这种人容易显得很强,因为他总能把东西写出来。以后这种优势会塌得很快,因为“写出来”这件事本身不再构成护城河。 我现在做方案,反而比以前更少追求“一版定乾坤”了。 我会先让AI一次性给出3到5个互斥版本,而且强制它把这几件事写清楚: - 每一版最大的好处是什么 - 最大的代价是什么 - 会伤到哪类人 - 会在哪个执行节点出问题 - 如果三个月后复盘,最可能后悔的点是什么 也就是说,我不再让AI帮我找“标准答案”。 我让它帮我把可能性摊开,把代价摊开,把我以前需要自己花很久才能整理出来的那堆分支先摆到桌面上。 然后人来做最后那一步: 我们到底要接受哪一种代价? 这一步,才是真正值钱的部分。 AI最擅长生产可能性,管理者最值钱的是裁掉可能性。 因为管理从来不是把所有事情都想出来。管理是把不该做的先砍掉,把真正该承担的那一个结果选出来。 ## 经验没有失效,用法变了 这也是为什么我不太认同“AI会让经验失效”这类说法。 经验没有失效。失效的是经验过去最常见的用法。 以前经验主要用来帮你更快出方案。以后经验更重要的作用,是帮你更准地校准方案、筛掉方案、拍板方案。 经验没有贬值,只是从“生产资料”变成了“评审机制”。 ## 方案会越来越便宜,落地会越来越贵 如果说前3篇讲的是管理者不该再做信息搬运、规则不该只停在制度文件里、也不能按旧组织逻辑去裁人,那这一篇真正想说的是: 管理者最值钱的部分,不再是亲手把方案写出来。 而是在五个都说得过去的方案里,知道哪个该做,哪个不能做,哪个现在还不能做。 过去管理者靠“我想到了你没想到的”赢。以后会越来越多地靠“这些方案你都想到了,但我知道该选哪个”赢。 这才是 AI 真正抬高的门槛。 因为方案会越来越多、越来越快、越来越便宜。而判断,恰恰会因为选项暴涨而变得更贵。 但判断还只是前半段。 真正拉开组织差距的,不是你今天选了哪一版。而是这版方案定下来以后,能不能被稳定地执行下去。 说得再直一点: 方案会越来越便宜,落地会越来越贵。 很多公司现在的问题,不是没有方案。而是方案定完以后,还在靠开会、靠培训、靠反复传达,让人记住该怎么做。 如果执行还主要靠人脑子记、靠老员工带、靠管理者一遍遍提醒,那再好的方案,落地时也会慢慢变形。 ## RM 03 那些因为 AI 裁过人的企业,55% 后悔了 AI 能替代一部分任务,不等于已经替代了一个完整岗位。 原文 https://aifellow.ai/articles/rm03 最近一年,我听过最多的一句话,不是“AI到底有没有用”,而是: “既然AI已经能写方案、回客户、做日报了,是不是可以先把后台砍掉一半?” 这句话听上去很像管理升级。其实更像管理误判。 2025年4月29日,Orgvue发布一项研究:39%的企业领导者因为部署AI做过裁员;而在这批已经动过裁员刀子的企业里,55%承认自己裁错了。 同一份研究里,还有34%的领导者承认,员工曾因为AI带来的变化直接离职。 这组数据最值得看的,不是“55%”本身,而是它背后的那句潜台词: 很多企业不是高估了AI, 而是误判了“岗位”到底是由什么组成的。 AI能替代一部分任务,不等于它已经替代了一个完整岗位。“用AI替代人”和“用AI重新设计组织”,从来都不是一回事。 ## 最容易被裁掉的,往往不是最该被替代的 很多岗位,看上去是在做一件事,实际上在扛四五件事。 比如客服。表面上是答问题、回消息、处理投诉,所以管理者一看AI客服上线,第一反应就是“这不就能少一批人吗?” 但一个成熟客服岗位真正承担的,往往不只是标准回答。 它还在做这些事: - 听出客户情绪什么时候已经快失控了 - 判断哪个问题其实不是客服问题,而是产品问题、流程问题或者政策问题 - 把边角案例往回喂给团队,逼着规则更新 - 在系统没有覆盖到的地方,临时接住组织的漏洞 AI可以吃掉其中一大块标准化动作,但它通常吃不掉全部。 我自己在做制度工具化和流程自动化时,这个感受特别强。 当我把规则写进系统之后,最先消失的,是那些低水平重复动作:解释制度、转发模板、催审批、找旧版本、反复确认“这一步到底找谁”。这些动作一旦被模板、自动化和AI接住,效率提升非常明显。 但另一部分工作不但没有消失,反而变重了: - 遇到例外情况,谁来判断? - 流程卡住了,谁来协调边界? - 一线不理解新做法,谁去消化情绪? - 规则本身不合理,谁来改? 这才是很多企业裁错人的原因。 他们看见了容易被自动化的那一层,却没看见岗位背后那层“吸收复杂度”的工作。于是最先被裁掉的,常常不是最该被替代的人,而是那个原本一直在替组织兜底的人。 ## 企业后悔的,不是用了AI,而是刀下得太早 很多企业后悔,不是因为AI没效果。 恰恰相反,往往是因为AI在某些环节太有效了,管理者一兴奋,就直接把“任务提效”翻译成了“岗位冗余”。 这中间至少漏了三步。 第一步漏掉的是:拆任务,而不是看岗位名称 岗位从来不是一个动作包,而是一个任务组合。 一个运营,不只是“填表、拉群、发通知”;一个HR,不只是“写制度、跑审批、发offer”;一个招商主管,不只是“跟客户聊方案”。 岗位里通常至少混着四类事情: 1. 重复且标准化的 2. 依赖上下文判断的 3. 需要跨部门协调的 4. 需要关系和信任来完成的 AI最擅长的是第一类,正在快速逼近第二类,但第三类和第四类,仍然强依赖组织设计和人本身。 如果你连岗位都没有拆到任务层,就直接谈“这个岗还要不要”,本质上不是在做组织设计,而是在凭印象做预算。 第二步漏掉的是:先改流程,再谈编制 很多企业的顺序是反的。 先裁人,再让系统补;先缩编,再让留下的人适应;先用成本结果证明项目成功,再回头补治理、补培训、补规则。 这种打法看上去短期很漂亮,因为人头马上下去了,报表会变好看。但代价会在后面慢慢出来: - 剩余团队开始接更多例外工作 - 客户问题没人真正闭环,只能被系统“礼貌地挡回去” - 跨部门协作断层,流程表面自动化,实际更依赖临时救火 - 看上去省下了薪酬,实际把效率损耗、离职损耗和信任损耗埋进了组织里 2026年1月14日,Salesforce发布《C-Suite Trends for 2026》时有一个判断很关键:企业现在真正的瓶颈,已经不是“要不要上AI”,而是能不能把AI安全地接进真实业务数据和流程。 这句话翻成管理语言就是: 真正难的,不是把人减掉, 是把新的运行方式设计出来。 如果运行方式没设计出来,裁员就只是一场把系统问题转嫁给剩余员工的动作。 第三步漏掉的是:转岗和再训练不是善后,而是主体工程 很多管理者把 reskill 和 redeploy 理解成“裁完之后顺手做一点安抚”。 其实正好相反。 2025年5月5日,Salesforce关于 workforce 的研究显示: - 89%的CHRO认为,AI更有可能帮助他们把员工重新分配到更相关的新岗位 - 88%的CHRO认为,内部转岗比外部重新招聘更划算 - 81%的CHRO已经在做或者计划做再训练 这说明更成熟的企业,心里想的不是“这批人怎么处理”,而是“哪些任务交给AI之后,这批人应该被重新放到哪里”。 裁员思维的默认问题是:谁可以不要了? 组织重构思维的默认问题是:谁应该去做更值钱的事? 看上去只差一句话,背后其实差了一整套管理操作系统。 ## “用AI替代人”和“用AI重新设计组织”,差别到底在哪 | 看问题的方式 | 用AI替代人 | 用AI重新设计组织 | |------|------|------| | 出发点 | 先看能省多少人 | 先看流程怎么重组 | | 分析颗粒度 | 岗位 | 任务与例外 | | 项目成功标准 | 人头下降、成本下降 | 质量提升、响应变快、规则更稳定 | | 对员工的处理 | 缩编为主 | 转岗、再训练、重新分工 | | 对管理者的要求 | 会算账 | 会拆任务、会设规则、会改流程 | 为什么我一直说,后者比前者难得多? 因为前者只需要勇气。后者需要能力。 裁员是一个决定。组织重构是一整套连续动作: - 你要先看清组织里到底有哪些重复劳动 - 再判断哪些能被规则化、模板化、自动化 - 再设计新的人机分工 - 再补培训、补指标、补协同机制 任何一步偷懒,最后都会翻车。 所以很多企业不是输在AI不够强,而是输在管理者还用旧时代那套“减人=升级”的脑回路,去理解一场本质上应该是组织重构的事情。 ## 真正该被替代的,不是人,是低水平重复判断 如果一定要说“AI该替代什么”,我越来越倾向于一个更窄、也更稳的答案: 先替代低水平重复判断。 什么叫低水平重复判断? - 同样的问题每天回答几十次 - 同样的审批标准反复靠人解释 - 同样的报表每周手工汇总一遍 - 同样的方案每次重写一稿,只是数字和措辞不同 - 同样的流程节点,每次都靠人记忆、催办、补漏 这些事情被AI接住,组织不会变弱,只会变轻。 但如果你把关系维护、复杂协调、风险吸收、例外判断这些工作也一并当成“可替代劳动”砍掉,组织表面会变轻,实际上会变脆。 很多管理者高估了AI接标准动作的速度,却低估了组织处理例外情况时对人的依赖。 而组织真正的成本,常常恰恰不发生在标准动作上,而发生在例外、冲突、返工和失控上。 这也是为什么有些企业AI项目上线后,表面效率提高了,管理层却越来越累。 不是因为AI没用。是因为AI拿走了流程里最轻的那部分,剩下最重的复杂度,还在用旧组织扛。 ## 如果你真的在考虑缩编,至少先做完这四步 我现在越来越不相信“一上AI就先裁人”这套动作。 如果一个管理者真要动编制,至少应该先做完四步。 1. 先把岗位拆到任务层 不要问“这个岗位值不值得留”。先问“这个岗位每天到底在做哪几类事”。 2. 先把规则长进工具里 能模板化的先模板化,能自动分发的先自动分发,能实时提醒的先实时提醒。 不要还没把规则写进流程,就先把负责执行的人撤掉。 3. 先跑两个真实业务周期 不是跑demo,不是跑领导视察时那套漂亮流程,而是跑真实订单、真实客户、真实投诉、真实跨部门协作。 没有经过真实周期验证的AI提效,大多还只是幻觉。 4. 最后才决定是缩编、转岗,还是补新角色 有些岗位会缩,有些岗位不会消失,只是内容变了;还有些岗位看上去减少了,实际上你会发现需要补新的角色,比如数据治理、知识维护、流程架构、AI运营。 如果这四步没做完,就急着谈“谁可以走”,那不是在做AI转型,只是在把组织实验的风险转嫁给员工。 ## 管理者接下来最值钱的,不是敢裁人,是会重新排兵布阵 AI这波变化,会让一些岗位缩小,会让一些工作消失,也一定会让一些人离开。这件事不用假装看不见。 但真正拉开差距的,不是谁下刀更快。 而是谁更早明白: AI不是一把更锋利的裁员刀, 而是一套逼着你重做组织设计的新工具。 会被AI淘汰的,未必只是基层重复劳动。很多只会传达、监督、催办、汇总的“假管理”,同样会先被打掉。 真正还会越来越值钱的,是另一类管理者: - 会拆任务 - 会设计规则 - 会处理例外 - 会把人和AI重新编排进同一套系统里 这也是为什么我越来越觉得,AI时代最危险的决定,不是“不敢用AI”,而是“还没搞清楚组织怎么变,就先按老办法减人”。 那种看上去最果断的动作,往往只是最昂贵的误判。 参考资料 - Orgvue,2025-04-29,《55% of businesses admit wrong decisions in making employees redundant when bringing AI into the workforce》 - Salesforce,2025-05-05,《Salesforce Research: Agentic AI's Impact on the Workforce》 - Salesforce,2026-01-14,《Salesforce Research Reveals C-Suite Trends for 2026》 ## RM 02 十万字制度,能改变几个人? 规则从 A4 纸到人的行为之间,隔着一道鸿沟。 原文 https://aifellow.ai/articles/rm02 去年我做了一个统计,把过去十几年写过的制度文件拉了一个清单。奖惩办法、干部管理办法、薪酬调整细则、岗位说明书模板、绩效考核方案……一共几十份,加起来超过十万字。每一份都逻辑严密,每一份都签批齐全,每一份都公布到全员。 然后我问了自己一个从来没问过的问题:这六十多份文件,真正改变过一个人行为的,有几份? 我想了很久。答案是屈指可数。 这不是夸张。你去问任何一个一线员工,上一次打开公司制度文件是什么时候?大多数人的回答是“入职那天HR让我签字的时候”。签完之后,那份文件的生命就结束了。它被归档、被遗忘、被灰尘覆盖,直到某一天出了事,才被翻出来当免责证据。 去年接手一个新业务,从零搭体系。摸完底发现老问题:同一件事,不同区域做法完全不一样,没有统一标准。按老规矩,第一件事建章立制。花了几周出了若干增补条例,发到各地,等着秩序降临。 等来的还是十几年如一日的剧情:一线回复“收到”,然后基本该怎么干还怎么干。 一个在公司干了八年的老员工跟我说了句话,让我愣在原地。他说:“领导,您别介意。制度我真没看过。但您要是给我一个模板,告诉我打开照着填就行,我肯定用。” 这句话听着平淡无奇。但它是一面镜子。 它照出来的不是员工的问题,是管理者的幻觉。我们以为把规则写下来就等于传递了规则,以为发布了文件就等于建立了秩序。但规则从A4纸到人的行为之间,隔着一道巨大的鸿沟:你得找到它、打开它、读懂它、记住它、在具体场景中回忆起它、然后按照它去做。每一步都在跟人性打架。 ## 人会忘记制度,但不会忘记好用的工具 后来我做了一个实验。同一套招聘流程规则,一份写成制度文件,目的、适用范围、职责分工、权限矩阵,十几页,字斟句酌。另一份做成飞书系统里的自动化模板,打开就填,放上简历评价自动生成,下一轮面试建议清晰明确,流程自动走到下一个面试官。 制度文件没人看。自动化模板上线第一天,使用率就在80%以上。 同样的规则,不同的载体,效果差了一个数量级。 这个结果没有让我高兴。它让我恐惧。因为它意味着我过去十几年最引以为傲的管理基本功,建章立制,可能从一开始就是一种精心维护的自欺。 ## 制度最大的作用,常常不是让规则运转 我开始拆解这件事。制度文件真正的功能是什么?表面上是传递规则。但你仔细看管理者写制度的心理链条: 我写了,说明我有方法论。 我发了,说明我履行了管理职责。 你签收了,说明责任转移完成。 出了事,不是我的问题。 制度变成了免责声明。它的核心功能不是让规则运转,是让管理者心安。 写制度这件事,与其说是在管理组织,不如说是在管理管理者自己的焦虑。 这不是个别现象。德勤2018年的调查发现,近90%的企业承认制度发布三个月后基本无人查阅。九成。这意味着全世界的管理者都在做同一件事:花大量时间生产一种几乎没人消费的产品。 麦肯锡的数据更让人心疼:68%的中层管理者每周花8到12个小时在制度的修订和解释上。一周工作时间的四分之一,献给了一堆没人看的文件。 我在一家企业见过“制度版本号通货膨胀”的极致案例。他们的差旅制度五年迭代了九个大版本,最新是v9.2。我问行政总监9.2比9.1改了什么,她想了半天说,可能是高铁二等座报销上限调了30块。一个总监级的管理者,花了数周推动一次全员签批流程,核心变化是30块钱。 但没有人敢说“别写了”。因为在这个体系里,不产出制度的管理者看起来像没干活的管理者。你的工作量需要被看见,而制度文件恰好是最容易被看见的产出。它有页数、有版本号、有签批章、有红头抬头。它是管理者证明“我在管理”的最佳道具。 制度活了一百年,不是因为它有效,而是因为它让管理者有事可做、有物可交、有据可查、有功可记。 这才是制度最深层的秘密:它不是为组织服务的,它是为管理者的存在感服务的。 ## 规则没有消失,只是长进了工具里 那规则就不重要了吗?当然重要。一个组织没有统一的规则,不是组织,是散伙饭。 但规则和制度是两件事。 规则是“报销不能超标”。制度是一份十二页的报销管理办法。前者永远重要,后者只是传递前者的手段之一,而且是一百年前唯一可用的手段。今天不是了。 制造业早就想明白了这件事。MES系统把SOP直接嵌进产线操作,你想跳步骤,没有那个按钮。仓储的先进先出规则写在系统逻辑里,不是贴在墙上。药厂的GMP操作规范做进了电子批记录,做完这步才能做下一步,根本不存在“我没看到那条制度”的可能。 规则没有消失。规则长进了工具里。 一个连锁酒店集团的运营VP跟我讲,他们有2000多页的运营标准,每年培训花上千万。去年把核心标准做成了AI助手,店长遇到问题直接问,AI按标准实时回答,同时自动记录执行情况。他说了句让我记到现在的话: 以前80%的精力确保规则被知道,20%确保规则被执行。现在反过来了。 这个“反过来”才是真正革命性的。管理者一百年来的时间分配是畸形的,绝大多数时间花在“传达”上,极少数时间花在“思考”上。传达规则要写制度、搞培训、做考核、做检查、做纠偏;而思考规则本身对不对、规则之间矛不矛盾、哪些规则早就该废除,根本没时间。 管理者最大的悲哀不是规则没人执行,是你忙到没空想规则对不对。 AI不是来替代管理者的,是来把管理者从“传达”中解救出来,逼你去面对真正的问题。 ## 管理者的价值,正在从写规则转向设计运行方式 这意味着管理者的价值在发生一次根本性的位移。 过去你的核心能力是“把经验变成文字”,观察、提炼、归纳、成文。这是文秘能力和表达能力的组合。有价值,但门槛不高。 现在这个能力被工具接管了。AI可以在几分钟内生成一份逻辑严密的制度文件。这件事不再稀缺。 稀缺的是另一种能力:设计规则的运行方式。不是“写出好规则”,是“让好规则自动运转”。 前者的终点是一份文件。后者的终点是一个不可能做错的流程。 前者依赖人的自觉。后者依赖设计的精巧。 前者需要反复宣贯、培训、考核、追责。后者只需要一次到位。 前者是在管人。后者是在管环境。 管理者的价值正在从“写出好规则”转向“设计规则的运行方式”。 前者是手艺,后者是架构。手艺AI已经会了,架构还得你来。 这个转变为什么这么难?因为整个管理体系的评价标准还停留在旧范式里。你出了三份制度,这叫“有产出”。你把规则做进系统让它自动运转,老板问你最近在忙什么,你很难回答,因为设计一个好系统,没有页数可以汇报,没有红头文件可以展示,没有签批章可以证明。 但那才是真正的管理。 ## 最好的规则像空气 最好的规则像空气,无处不在,但从不需要被阅读。 最好的管理像地心引力,你感觉不到它的存在,但一切都在它的秩序里运行。 我现在接手任何新业务,第一件事不再是“先出制度”。我会问三个问题:这条规则能不能直接嵌进流程?嵌不进的,能不能做成实时提醒?都不行的,才写下来。 结果是需要“写下来”的东西越来越少。 回到那个老员工的话,“给我模板就行”。她没读过管理学,不知道韦伯和泰勒是谁。但她用最朴素的语言说出了管理学走了一百年才走到的结论:规则的价值不在于被书写,在于被执行。执行不靠觉悟,靠环境。 我从那天起不再写制度了。不是因为规则不重要。恰恰相反,因为规则太重要了,重要到不能只托付给一份没人打开的文件。 但制度只是冰山一角。 AI对管理的改造远不止于制度载体。当规则开始“隐形”,当工具开始替代流程,一个更大的问题浮出水面:既然AI这么能干,是不是可以直接砍人? 有些企业已经这么做了。结果55%后悔了。 “用AI替代人”和“用AI重新设计组织”,是两件完全不同的事。前者很容易做,也很容易翻车。 ## RM 01 管理的虚假繁荣 开了一天会、审了三十个批,这不叫管理,这叫信息中转站。 原文 https://aifellow.ai/articles/rm01 去年底,我做了一件得罪人的事。 管理层季度复盘,我没让大家汇报业绩,而是让每个人打开日历,拿笔在白板上统计上一周的时间分配,开了几个会,审了几个批,回了多少消息,写了几份报告,真正坐下来“做一个决定”花了多长时间。写到最后一项的时候,好几个人的笔停住了。 结果触目惊心。十几个管理者,平均70%的时间花在汇总、协调、传达上。真正在“做判断、做取舍”的时间,不到15%。 一个区域总说了句让全场沉默的话:“我上周最重要的决定,是周五晚上在车里想出来的。上班时间全在回消息。” 开了一天会、审了三十个批、回了一百条消息,这不叫管理,这叫信息中转站。 ## 整套体系,是一部搬运机器 但我们从不觉得这有问题。 日程排满、手机消息不断、随时被人找,这些是管理者身份的标配。谁的日历最满,谁看起来就最重要。忙碌给了我们一种“我在创造价值”的幻觉。 后来我跟不同行业的管理者聊,发现70%不是极端值,是常态。更刺痛我的是一个反向数据:真正跑得好的组织,高管至少把一半时间花在决策讨论上,纯汇报会议压到了十分之一以下。 也就是说,大多数管理者最忙的那些事,恰恰是高绩效组织在压缩的事。 这不是个体能力问题。这是系统设计问题。 管理学从诞生那天起,就是围绕“搬运”设计的。 一百多年前,管理这门手艺被发明出来的时候,核心假设只有一个:人是执行单元,管理是让执行单元不出错。怎么让人不出错?写制度,定流程,设层级,搞考核。 每一项的本质都是同一件事,把“正确的信息”从知道的人那里搬运到需要执行的人那里。 制度是规则的搬运。培训是知识的搬运。层级是信息的搬运。审批是权力的搬运。考核是结果的搬运。 整个管理体系,就是一部精密的搬运机器。 这台机器运转了一百年,效果不错。工厂需要标准化,军队需要层级制,公司需要流程化。人的注意力有限、信息处理能力有限,所以需要管理者来做中转、做翻译、做协调。 管理者的价值,建立在“人处理信息的能力有上限”这个前提上。 科层制不是因为官僚才存在的。它是因为一个人管不过来五百人才存在的。你需要分层,每层管一小块,层层汇报上去。这不是制度设计的问题,是生物学限制。 ## 这个前提正在失效 但现在,这个前提正在失效。 一个做连锁零售的朋友跟我讲,他们有三百家门店,过去每周一上午是“经营分析会”,各区域经理汇报数据,区域总汇总后给VP,VP再给CEO。整个链条从周一早上开到下午,有时候拖到周二。 去年上了数据系统加AI分析,周日晚上报告自动生成,异常自动标红,建议自动附上。周一早上CEO打开手机就能看全貌。 经营分析会砍掉了。不是因为分析不重要,是因为“让人汇报数据”这件事不需要存在了。 然后一件事发生了:三个区域经理不知道周一上午该干什么了。 他们不是能力不行。他们是十几年来第一次发现,自己每周最“重要”的工作,汇总数据、做PPT、在会上讲二十分钟,突然消失了。剩下的时间,应该干什么? 不是AI取代了管理者,是AI让“不做决策的管理者”无处藏身了。 那些一直在搬运的人,搬运被拿走之后,手里是空的。那些一直在做判断的人,反而更轻松,AI把搬运的活接走了,他们终于有时间专心做判断。 有人说,这不就是数字化转型吗?搞了十年了,有什么新鲜的? 新鲜在一个关键区别:过去的数字化替代的是“人的体力劳动”,AI替代的是“人的脑力搬运”。 ERP替代了手工记账,但记完账还要人分析。CRM替代了手工管客户,但客户策略还要人定。过去的系统替代的是“手”,AI替代的是“脑”,至少是脑的搬运功能:汇总、分类、初步分析、生成报告、翻译意图。 管理者过去最核心的日常功能,信息中转站,第一次可以被技术接管了。 ## AI 照出来的,是假忙碌 我回头看自己过去一年的日历,做了个残忍的分类:哪些会是在“做决定”,哪些会是在“听汇报”。结果是二八开,八成时间在听别人搬运信息给我。 一百年前管理变成了科学。一百年后AI变成了镜子,照出来的不是你有多忙,是你有多少忙是假的。 说到这里,很多人的反应是焦虑,“那我还有什么用?” 我的看法刚好相反。 过去一百年,管理者最大的悲哀不是“被搬运淹没”,而是不知道自己被搬运淹没。包括我自己,日历排满的那些年,从没怀疑过这叫“高效管理”。以为开会就是管理,以为审批就是决策,以为协调就是领导力。在忙碌中获得价值感,在搬运中确认存在感。 AI把搬运抽走之后,管理者第一次被迫面对一个问题:我的判断力到底值多少钱? 这个问题以前不用回答,因为搬运已经把时间填满了。现在必须回答,因为搬运不需要你了。 ## 真正的管理只发生在判断那一刻 真正的管理只发生在你做判断的那一刻。其余时间,你只是一根很贵的网线。 这不是危机。这是管理者一百年来第一次有机会回到管理的本质,做判断、做取舍、做那些没有标准答案的决策。如果你的价值一直建立在“搬运”上,AI确实在让你贬值。如果你的价值建立在“判断”上,AI正在替你腾出时间。 同一个技术变量,对不同的管理者,是完全不同的命运。 虚假繁荣最明显的地方在哪? 不在开会,不在审批。在一个更古老、更根深蒂固的东西上,制度。 每个管理者都写过制度,每个管理者都知道制度没人看。但从没有人质疑过“该不该写”。我们质疑制度的内容、质疑执行、质疑更新频率,唯独不质疑制度作为管理载体的存在本身。 直到我发现,同样的规则,写成制度没人看,做成工具使用率100%。一个老员工跟我说了句大实话,让我彻底放弃了写制度这件事。