MoreRSS

site icon1Q43 | 虹线修改

自称:评论尸。代表作《互联网是人类历史的一段弯路吗?》《垄断的困境》《互联网与中国后现代性呓语》 公众号”赤潮AKASHIO",播客”二维吾码”主理人。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

1Q43 | 虹线的 RSS 预览

WorkBuddy 成功,是因为腾讯办公套件太烂了

2026-08-31 09:30:00

前几天和汐笺讨论 Workbuddy 为什么成功,我在微信里发出了一句很像为了流量硬拗出来的标题:

“我突然意识到,WorkBuddy 的成功,源于腾讯办公套件的失败。”

这句话很像为了流量硬拗出来的标题,也很容易让人以为,腾讯会议、腾讯文档和企业微信都是失败产品。

事实恰好相反。

腾讯会议是国内最普及的视频会议工具之一;腾讯文档借助微信关系链覆盖了大量临时协作;企业微信也进入了许多大型企业,尤其擅长销售联络、私域运营和客户关系。三个产品单独拿出来都很能打。

问题只出在后两个字:“套件”。

它们的用户、入口和工作流始终没有汇入同一个中心。腾讯办公留下了三个成功的单品,却没有形成一个成功的整体。

几年以后,这个长期未解决的问题,居然给 WorkBuddy 留出了一条路。

按照易观统计的月访问量口径,2026 年 6 月,WorkBuddy 在国内桌面端 AI 原生办公智能体中排在第一,访问量达到 2097 万次。第二名 TRAE IDE 国内版是 1279 万次,QoderWork 是 788 万次。这个数字不等于真实用户数,更不能直接证明 WorkBuddy 已经赢下整个市场,但至少说明它已经抢到了国内办公 Agent 的第一波主流位置。[1]

奇怪的地方也在这里。

WorkBuddy 至今连一个像样的中文名都没有。它没有像腾讯游戏那样获得铺天盖地的宣发,也没有被塞进微信或 QQ 的一级入口。至少在用户每天能看见的地方,腾讯没有拿出那种“今天开始全公司都给我推”的大厂气势。它甚至来得不算早,阿里旗下 Qoder 在 1 月底就发布了 QoderWork,比 WorkBuddy 早了一个多月。

至于产品力,我把几款产品都体验过以后,很难说 WorkBuddy 在 PPT、表格、浏览器操作、文件处理上形成了什么天堑。各家都能读文件、做调研、写报告、生成幻灯片、远程接收任务。今天这家强一点,明天另一家补上。大厂的免费额度、算力补贴和线下推广也没有什么祖传秘方,阿里、字节、百度一样会烧钱。

所以,那些最常见的答案,在解释 WorkBuddy 为什么成功上都不太有效。

注意,这里说的是 WorkBuddy,不是 WorkBuddy 类产品。

Codex 在海外的火热,已经证明了这种产品形态成立。

中国用户很难稳定使用 Codex 和 Claude Cowork,于是国内一定会出现替代品。模型会调用工具、Agent 能拆任务、本地文件很重要,这些判断都对。它们解释了这条赛道为什么必然出现一个赢家,却没有解释赢家为什么恰好姓腾。

当几款产品看起来都差不多时,真正拉开差距的变量,可能藏在产品之外。

WorkBuddy 最大的优势,恰好来自腾讯过去没有做成一款足够成功的办公套件。

1. 三件都成功,但“套件”失败了

2022 年初,企业微信 4.0 发布。腾讯当时给出的重点叙事,是企业微信、腾讯会议、腾讯文档“三杰合体”。

这个说法很有腾讯特色。

三款产品明明都姓腾,到了 2022 年,才需要郑重宣布它们终于合体。

别家企业没有这样的。

你无法想象看到苹果召开发布会,宣布“iPhone、AirPods 和 Apple Watch 从今天起正式互相认识”。正常的产品生态,通常在用户注意到之前就已经连上了。

根据《21 世纪经济报道》记者白杨当时的报道,三支团队早在 2018 年就尝试合作,最后依然各自发展。直到 2021 年 6 月,腾讯总办明确要求三款产品必须协同,整合才重新提速。报道里还提到,用户长期抱怨三款应用彼此割裂:账号不完全通,数据不完全通,权限体系也各有各的脾气。更麻烦的是,三款产品横跨不同事业群,后台、用户群和发展路径都已经成熟,任何一次深层改造都牵一发动全身。[2]

这段历史很适合解释腾讯办公产品的问题。

腾讯会议当然算成功。疫情期间,它几乎成了中国人对视频会议的默认认知。更关键的是,它的海量用户里,很大一部分根本不使用企业微信。一条会议链接可以跨公司、跨学校、跨组织流动。腾讯会议越容易被任何人点开,它就越不需要企业微信充当入口。

腾讯文档也一样。它最常见的分发路径是微信、QQ群或某个网页里。临时填表、多人改稿、收集材料的人,可能从头到尾都没有企业微信账号。腾讯文档的用户增长更多依赖微信群传播,而非企业微信的组织树。

企业微信同样有规模很大的企业客户。但它在很多企业里最有辨识度的价值,落在了企业与 C 端客户之间:销售加客户,运营维护微信群,导购经营私域,CRM 追踪线索。一个企业完全可以用企业微信连接几百万消费者,同时用钉钉打卡审批、用飞书做项目和文档。

这种“脚踩三条船”并不罕见,也未必意味着管理混乱。每套工具都在完成自己最擅长的一段。腾讯会议解决跨组织开会,腾讯文档解决低门槛协作,企业微信解决企业如何伸进微信里的客户关系。

于是一个很腾讯的局面形成了:腾讯会议和腾讯文档各自拥有大量企业微信之外的用户;企业微信拥有很多企业,却没有承包这些企业的全部办公流程。

三个产品都成功了。只有“套件”没有成功。

它们没有围绕企业微信形成一套清晰的主从关系,更像三块彼此重叠、又各自拥有海岸线的大陆。用户可以从微信进入腾讯文档,从短信或链接进入腾讯会议,从企业微信进入客户关系,再转身回到飞书或钉钉继续做内部管理。

同一个人上午用腾讯会议见客户,中午在腾讯文档改材料,下午通过企业微信维护客户群,晚上又回飞书推进项目。四次行为可以发生在同一天,心智上依然属于四套工具。它们共享 Logo,没能共享同一种用户关系。

说得难听一点,腾讯没有办公套件,只有三款彼此加了好友的办公软件。

过去腾讯解决这个问题的办法,是继续打通。

企业微信里放进会议,会议里可以调文档,文档再去识别组织身份。产品之间修了很多走廊,用户仍然需要自己搬箱子。讨论结束以后,谁去整理纪要。纪要写完以后,谁去更新方案。方案更新以后,谁去通知相关的人,这些半截工作依然留给员工。

所以截图里“WorkBuddy 合并了三款产品的用户群”这个直觉,大致是对的,只是“合并”听起来太像把所有人迁进同一个 App。

WorkBuddy 做到的是同时兼容三批原本彼此不从属的用户:企业微信之外的会议用户,企业微信之外的文档用户,以及把企业微信主要当成客户连接器的企业员工。它不要求这些人先成为同一种用户,也不要求企业先统一软件采购。

它汇流了三种入口。

腾讯会议提供事件,腾讯文档提供对象,企业微信提供组织和客户关系。一个产品积累“发生了什么”,一个产品积累“留下了什么”,另一个产品掌握“应该交给谁”。过去这三种上下文之间隔着大量人肉复制粘贴。WorkBuddy 一出现,复制粘贴的人可以换了。

腾讯办公留下了很多房间,也留下了很多没有人负责的走廊。更麻烦的是,有些房间甚至建在飞书和钉钉那边。

Agent 恰好是会跨楼跑的东西。

2. WorkBuddy 是一个拿着门禁卡的跑腿员

传统办公套件喜欢解决“大家在哪里工作”的问题,因为只有闭环才能带来生意。

飞书和钉钉的理想状态,是所有人使用同一套账号,进入同一个组织,消息、会议、日历、文档、知识库和审批都留在同一栋楼里。只要人和数据搬得足够完整,工作流自然可以连起来。

这个方案很合理,代价也很高。

现实里的企业也很少按照厂商的想象只买一套。一个公司完全可以让销售在企业微信里维护客户,让行政在钉钉里打卡审批,让产品和研发在飞书里推进项目,再用腾讯会议接外部客户。管理者嘴上追求统一,部门会用脚投票。中国企业办公的真实形态,经常是一只被不同 SaaS 拼起来的赛博人体蜈蚣。

企业要迁移数据,管理员要重新配置权限,员工要学习新的界面,外部合作伙伴还得愿意陪你搬家。腾讯会议、腾讯文档和企业微信已经各自长大以后,再做这件事,就像试图把三栋住满人的楼改造成一栋楼。图纸看上去很漂亮,真正施工时,每砸一面墙都会有人投诉。

Agent 换了一条路。

它不强求所有工作发生在同一个地方。用户只需要给它足够的门禁卡,然后说清楚自己要做什么。

比如:“把上午会议讨论的内容整理成项目进展,参考上个月的方案,更新数据表,再把结论发给项目群。”

过去,这句话要被一个白领拆成一串动作:找会议记录,下载文件,翻旧文档,复制数据,打开 Excel,整理格式,回到群聊,确认谁该收到。每个软件都完成了自己那一小段,软件之间的缝隙由人来填。

WorkBuddy 接过的,正是这些缝隙。

它可以从会议内容里找决定,从文档里找背景,从文件夹里找数据,再把结果交还给群聊。几栋楼还在原地,住户也不用搬家。现在多了一个跑腿员,他认识路,手里还有钥匙。

WorkBuddy 的产品时间线也很有意思。3 月初开放后,它很快加入了企业微信、钉钉、飞书和 QQ 等多渠道 Bot。腾讯文档的原生资料库和产物回传,到了 4 月底才上线。换句话说,这款产品先以独立桌面 Agent 的形态跑了起来,随后才陆续拿到腾讯办公产品的门禁卡。[3]

这和“把 AI 放进企业微信”有很大区别。

如果 WorkBuddy 从企业微信里出生,它首先要理解企业微信的组织、客户和权限,然后在企业微信允许的范围里工作。现在的顺序倒了过来:WorkBuddy 先围绕任务建立入口,企业微信、腾讯文档、飞书和钉钉都成了可调用的工具。

我以前在《不要轻易地走进 AI Native》里写过一句比较绝对的话:所有试图颠覆 Office 的产品,如果它长得不像 Office,基本都做错了。

当时我的判断是,Office 已经装下几十年积累出来的人类文档需求。一个 AI 创业团队想靠几个漂亮页面重新发明 Word 和 Excel,大概率会先把自己累死。AI 更适合成为成熟软件里的按钮。

Codex 以后,这个判断依然有效, 只是后续逻辑变了——不需要为 Agent 打造一个 AI Native 的 Office,它只需要去操作现成的 Office 就可以了。

WorkBuddy 没有重造 Office。它把 Office、浏览器、文件夹、聊天软件都当成工具。过去 AI 藏在文档侧边栏里,等人点击。现在 Agent 会自己打开文档、按下按钮、取走结果,再去下一个软件。

所以,WorkBuddy 对腾讯办公最大的意义,落在了另一处:它没有急着把“三杰”合成一款产品。

它让“三杰必须合成一款产品”这件事失去了必要性。

腾讯过去一直想把三栋楼改造成一栋楼。WorkBuddy 证明,给跑腿员多配几张门禁卡,可能便宜得多。

3. 飞书的问题,是套件太成功了

前两年,几乎所有人都公认飞书是 AI 时代最好的搭档。

这个判断非常合理。

坦诚清晰自成立之初就是字节跳动的企业文化之一,落在制度和企业管理里,就是字节跳动可能是目前国内互联网公司里内网公开文档最多的企业——凡无必要,皆不保密。

而飞书本身就是围绕这套信息透明体系构建的办公工具,当极端依赖上下文的 AI 办公时代来临的时候,它变成最适配 AI 的办公套件是意料之中的事情。

在这一轮 AI 革命开始之前,飞书已经把聊天、文档、会议、日历、多维表格、知识库和组织关系塞进同一套系统。整套体系各组件之间的信息传递、内容引用、相互关联都流畅的不像话。

AI 接入之后,可以像飞书用户一样丝滑的在内网畅游,给出最准确、最有用的答案。

在 Copilot 时代,这几乎是标准答案。

AI 作为副驾驶,需要坐在一辆已经装好的车里。飞书的车况很好,仪表盘齐全,地图和乘客信息也都在车上。企业微信这边则更像三辆车停在同一个停车场,钥匙还不通用。两年前让我下注,我也会觉得飞书更适合承接办公 AI。

但 Agent 把驾驶位也拿走以后,问题变了。

一个足够强的 Agent,不会满足于给飞书文档续写两段文字,或者替多维表格补一列数据。

它希望用户直接说出真正的目标,剩下的工具由它决定——必要时用飞书,必要时用 Office,必要时打开网页,必要时进入企业自建系统。

这时,飞书的完整开始变成一层约束。

入口上,Agent 越能独立完成任务,用户越不需要逐个打开飞书里的文档、会议和工作台。指标上,用户少点了十次页面,却更快完成工作,这究竟算飞书活跃下降,还是 AI 效率提高?商业模式上,企业将来买的是飞书席位,还是 Agent 的任务额度、Token 和数字员工?生态上,一个通用 Agent 理应平等连接钉钉、企业微信、Office 和 WPS,飞书却没有理由花大力气培养一个帮助用户离开飞书的入口。

这些冲突不会写在发布会 PPT 上,却会真实存在于每一次产品排期和组织汇报里。

Microsoft 365 Copilot 也面临类似处境。它最舒服的位置,是 Word、Excel、PowerPoint 和 Teams 的总管。它熟悉这座宫殿的每一个房间,也天然希望所有工作都留在宫殿里。一个独立 Agent 更像拿着合同四处跑的包工头,今天进 Microsoft Office,明天去 Google Workspace,后天钻进某家公司的老 ERP。总管的资源更多,包工头的路线更自由。

WorkBuddy 恰好没有一座必须守护的宫殿。

企业微信没有成功统治腾讯会议和腾讯文档,腾讯也没有一套足够强势的办公商业模式,需要 WorkBuddy 为席位收入、套件日活和生态封闭负责。它可以支持飞书,也可以支持钉钉。可以调用腾讯文档,也可以处理本地 Office 文件。至少在产品早期,谁能帮它完成任务,谁就能进入工具箱。

腾讯在 To B 领域的弱势,于是产生了一个很反直觉的结果。

飞书的 AI 首先要向飞书负责,它回答的是如何让用户觉得飞书更好用。

WorkBuddy 暂时只需要向任务负责,如果腾讯自己的工具不好用,那用别人的也可以完成用户的任务。

成功的办公套件总想让 AI 增强自己。腾讯那几款散装办公产品谁也没有资格要求 WorkBuddy 效忠。它继承了腾讯的资源,却躲过了宗主的指挥。

这可能才是 WorkBuddy 和竞品之间最难在功能表里看见的差距。

也正因如此,飞书、钉钉里的 AI 往往先从原有用户里分走一部分使用时长:把写文档的人变成用 AI 写文档的人,把开会的人变成用 AI 总结会议的人。

WorkBuddy 的增长路径更像把几批此前没有共同入口的人重新捆在一起。有人从本地文件进入,有人从腾讯文档进入,有人从企业微信或飞书妙记传来上下文。大家原本不属于同一套办公软件,最后却在同一个 Agent 里汇合。

这当然算不上腾讯办公生态比飞书强。相反,是因为腾讯办公生态恰好弱到没有办法阻止这种汇合。

前段时间,有媒体报道飞书被并入豆包业务,我最初也没想明白是为什么。后来在思考这篇文章的时候也想明白了——Agent 必须大于办公套件,而不是小于办公套件。

只有这样,Agent 才能真正涵盖工作中所有可能的偶发的、意外的、与第三方产生的需求,而不是被预制的办公套件限定在一个固定的行为逻辑中。

4. 腾讯又一次绕开了 To B

众所周知,腾讯的 To B 业务做得并不算好。

至少在办公软件这条线上,企业微信没有建立钉钉的先发优势,也没有形成飞书那种鲜明的产品心智。腾讯很擅长让十亿个人自发使用一款产品,却经常在企业采购、实施交付、管理员配置和组织推广这套流程里显得不太腾讯。

WorkBuddy 的增长路径,刚好绕过了这套流程。

传统企业软件先找老板。销售谈预算,安全团队谈合规,IT 部门谈部署,管理员谈权限,最后员工收到一封通知:“公司已经采购某某系统,请大家于本周五前完成激活。”产品好不好用,通常排在合同签完以后。

WorkBuddy 先找员工。

个人下载安装到电脑上,授权一个文件夹,就能用它整理材料、做 PPT、分析表格。员工不需要等公司统一迁移文档,也不需要说服所有同事换掉原来的办公软件。产物最后仍然可以发回原来的群、原来的文档、原来的邮件。

免费积分用完了,实在不行自己充点吧。毕竟由奢入俭难,太太, 试过这个之后,你也不想自己手做 PPT 了吧?

这类产品有一个很准确的定义:

它帮助 C 端用户完成 B 端工作。

据《21 世纪经济报道》对 WorkBuddy 团队的采访,产品在正式开放前,已经有超过 2000 名腾讯内部的非技术岗位员工参与使用。公测以后,访问量又迅速超过预期,团队不得不紧急扩容。[4]

这两千名员工的价值,不只是给产品做内测。他们提供了大量真正的办公失败:文件格式不对、权限拿不到、任务做一半断掉、PPT 可以打开但没法汇报、表格算完以后没人敢信。

编程 Agent 团队擅长让模型执行,非技术员工则不断提醒他们,职场里的“能运行”和“能交差”隔着一整套人情世故。

这也很符合腾讯过去做 To B 的路径。

我在《互联网历史进程中的腾讯 To B》里写过,腾讯云早期没有凭空理解企业客户。它从 QQ 开放平台上的社交游戏长出来,因为小公司扛不住 QQ 导来的流量;视频云从 QQ 和腾讯视频积累的音视频能力长出来,因为直播创业公司没有能力自己铺 CDN。腾讯先在 C 端遇见真实问题,再把解决问题的能力卖给企业。

WorkBuddy 是这个故事的全新版本。

它先解决一个员工今天晚上要交 PPT 的问题,随后再处理企业如何统一购买、管理权限、沉淀 Skill 和审计数据。

个人版已经跑起来以后,腾讯在 6 月才发布 WorkBuddy 企业版,开始补齐组织管理、企业知识和治理能力。[5]

这里的顺序很重要。

企业微信过去希望先获得企业,再通过组织获得员工。WorkBuddy 从员工的具体任务里长出来,企业最终面对的是一批已经开始使用 Agent 的人。采购部门可以不买,安全部门也可以暂时不批,但那无法让员工重新喜欢上手工搬运文件。

所以,WorkBuddy 真正汇流的,远远超过腾讯会议、腾讯文档和企业微信的三批注册用户。

它汇流的是这三款产品之外,甚至包括许多其他公司,其他办公产品各自留下的半截工作:会议留下的讨论和决定,文档留下材料和知识,报表留下的分析,内部系统留下的日报周报,OKR 留下的自我评估,企业微信留下组织关系和交付对象。

Agent 把所有这些碎片重新拼成一个任务,并且不要求你像飞书和钉钉那样,引入另一个巨大的“完整套件”。

腾讯迟迟没有形成统一办公入口,WorkBuddy 反而有机会成为那个入口。

腾讯 To B 最成功的时候,经常是它暂时忘记自己正在做 To B 的时候。

5. 失败留下的,刚好是一块真空

写到这里,需要重新给标题叠一层甲,免得被腾讯 PR 找麻烦。

腾讯会议、腾讯文档和企业微信都算不上烂产品。任何一家创业公司单独做出其中一款,都足够写进融资材料吹很多年。腾讯办公真正糟糕的地方,仍集中在套件化:三款成熟产品各自成立,始终没能共同形成一条自然的工作流。

这种失败不会自动生出 WorkBuddy。

Codex 证明了 Agent 可以执行任务,OpenClaw 让更多中国用户理解“电脑里养一个会干活的东西”是什么感觉;CodeBuddy 团队提供了现成的执行底座;两千多名内部员工提前暴露了非技术任务的各种死法;公测又刚好撞上国内 Agent 需求最旺的窗口。

这些因素共同决定 WorkBuddy 能不能起飞。

腾讯办公过去留下的结构,决定了它起飞以后能飞向哪里。

如果腾讯早就拥有一套像飞书那样强势的办公平台,WorkBuddy 很可能会被放进企业微信工作台,成为“AI 助手”菜单下的一项新能力。它要先服务企微客户,先接企微权限,先证明自己带动了企微活跃,再考虑是否连接钉钉和飞书。

现实给了它另一种命运。

腾讯会议有会议内容,腾讯文档有知识和产物,企业微信有组织和客户,微信与 QQ 还有触达个人的入口。资产全都在。与此同时,没有一款产品强大到可以宣布自己就是腾讯办公,要求其他产品排队进贡。

这是一份很奇怪的遗产。

有遗产,但没有宗主。

创业公司想做同样的事情,需要从零搭连接器、说服用户授权、建立品牌信任,还要承担一次任务跑几十分钟的算力成本。飞书和钉钉想做同样的事情,又必须处理新入口与旧平台之间的利益关系。WorkBuddy 卡在中间:它能调用大厂资产,也拥有一段近似创业公司的自由期。

这段自由期有多长,还很难说。

腾讯已经开始给 WorkBuddy 增加企业版、统一身份、知识空间、组织管理和治理能力。每一项都很必要,也会把它重新拉回传统办公套件熟悉的世界。

企业要权限,管理员要审计,销售要合同,生态要优先级,事业群要算收入。等这些东西全部长齐,WorkBuddy 可能会变得更强,也可能开始变得很重。

但同时值得注意的是,企业微信里又在内测另一套与 Workbuddy 完全独立的 AI 助理系统——大圆。

这看起来似乎又是一个腾讯内部赛马的故事,但也许这种赛马过程中的“相互消耗”,反而会让 Workbuddy 在这种“明 B 实 C”的自由生长再多保持一段时间。

毕竟,如果 Workbuddy 如果与企业微信深度绑定,那么它也会面对飞书今天的问题:一个已经成功的新入口,究竟愿不愿意平等地连接所有旧平台;一个开始承担企业收入的 Agent,还能不能只向任务负责。

腾讯过去没有把三款办公软件做成一套。

WorkBuddy 做成的,是让“一套”失去必要性。

它接下来最危险的时刻,也许正是腾讯决定把它重新做成一套的时候。


参考资料

[1] 易观:《2026 年 6 月中国桌面端 AI 原生办公智能体平台访问量出炉

[2] 白杨:《腾讯办公领域“三杰”合体》,《21 世纪经济报道》,2022 年 1 月 13 日

[3] WorkBuddy 官方更新日志:https://www.codebuddy.cn/docs/workbuddy/Changelog

[4] 彭新:《专访腾讯 WorkBuddy 团队:从 CodeBuddy 到桌面 Agent》,《21 世纪经济报道》,2026 年 3 月 15 日

[5] 腾讯:《腾讯云发布效率智能体工具集,为个人与企业打造 AI 新入口》,2026 年 6 月 5 日

AI 不会带来超级组织

2026-08-06 11:14:02

发一篇职务写作,给 AI 赋能组织浇浇冰水。

2025 年之后,“AI 裁员”终于从一种饭桌上的猜测,变成了公司公告里的正式理由。

过去的裁员通稿通常很讲体面:宏观环境变化、组织结构调整、提升运营效率、聚焦核心业务。话说得越圆,真实原因越像被塞进了抽屉。

AI 改变了这套话术。亚马逊、Meta、Block、Klarna,一批科技公司开始把人力收缩和 AI 效率提升放在同一个叙事框架里。美国媒体和咨询机构也开始追踪那些直接归因于 AI 的岗位消失。到 2025 年底,美国直接归因于 AI 的裁员已经超过 5.5 万人。亚马逊两轮裁员约 3 万,其中相当大一部分集中在 L5 到 L7 的中层岗位。Block 更极端,在盈利状态下一次裁掉了 46% 的员工。[1]

Block 不是一家边缘创业公司。它是 X 前联合创始人 Jack Dorsey 创办的金融科技公司,旗下有面向个人的 Cash App,也有面向商户的 Square,还有先买后付业务 Afterpay。换句话说,它不是一个“AI 替代客服”的小样本,而是一家拥有成熟支付、金融科技和商户服务体系的上市公司。

AI 并不一定是裁员的真实理由,而只是一个借口。公司过度扩张、资本市场施压、管理层想把财报做得好看,都可以躲进“AI 转型”这只新瓶子里。纽约时报和 BBC 都提醒过,高管把裁员归因于 AI,常常是在给旧问题换一个更体面的新名字。[2]

可即便它只是借口,借口本身也说明了时代的变化。十年前,企业不敢公开说自己要用机器替代人,那听起来冷酷、反社会、缺乏人味。今天,企业开始把这件事包装成远见。裁员不再只是削成本,它被讲成通往未来组织形态的一张船票。

被削掉的也不只是传统意义上的“执行岗位”。CNBC 在报道亚马逊裁员时,直接把 14,000 个公司岗位的削减、管理层扁平化、资源转向数据中心、芯片和 AI 基础设施放在同一个叙事里。亚马逊不是单纯少招几个人,它是在一边减少管理层,一边把钱砸向 AI 时代的新基础设施。[8]

Axios 引用 Gusto 对 8,500 家中小企业的分析说,每位管理者平均管理的个人贡献者数量,已经从 2019 年的 3 人多,增加到接近 6 人。也就是说,一个老板要管的人差不多翻倍。微软、亚马逊、Google、Meta 也都在过去几年经历了不同程度的“Great Flattening”,也就是去层级、去中层、压缩管理链条。[9]

老板没有消失,只是一个老板要管更多人。组织也没有被 AI 变聪明,它先被 AI 变瘦了。

AI 裁员的真实含义,未必是“机器已经替代人”。它更像一种新管理语言:当企业想削掉中层、压缩白领、重写组织结构时,AI 给了它一个听起来面向未来的理由。

于是,一个非常顺理成章的故事出现了。个人会被 AI 增强,成为“超级个体”。企业也会被 AI 增强,成为“超级组织”。一个人可以带着智能体做过去十个人的工作,一家公司也可以带着智能体完成过去十家公司才能完成的任务。个人升级,企业升级,生态繁荣,大家都有光明的未来。

这个故事很动听,甚至带着一种适合登台演讲的对称美。周鸿祎在此前的清华演讲中讲过类似判断:智能体会让个人成为超级个体,也会让企业成为超级组织。经济参考报关于“一人公司”的报道里,也出现了“超级企业”和“超级个体”共生共荣的表述。微软中国 CTO 韦青则把话说得更直接:每个人都应该在 2026 年成为 OPC,也就是 One Person Company,一人公司。[3]

问题在于,这两件事恐怕很难同时成立。因为这里有一个特别朴素的张力:

如果 AI 真的能让一个人承担企业内部任何一个岗位的工作,那么这个人为什么还必须留在企业里?如果企业真的承认 AI 可以把每个员工都强化到“一人公司”的水平,那么它同时也承认:自己正在批量生产潜在竞争者。

这就是“超级组织”叙事最尴尬的地方。它想同时拥有两个结论:一边说 AI 会让个体前所未有地强大,一边说大企业会在这场个体增强中变得更庞大、更稳固、更不可替代。可让个体变强的那股力量,恰恰在抽空大规模科层组织存在的理由。

超级个体和超级企业看起来像同一枚硬币的两面。更准确地说,它们是一对互相吞噬的命题。承认超级企业成立,就必须承认超级个体成立。因为所谓超级企业的核心前提,正是一个人能借助 AI 胜任企业里的大量岗位。超级个体一旦成立,超级企业又会被反向瓦解。每一个被 AI 增强的员工,都可能从组织内部的“岗位”变成组织外部的“公司”。

这条逻辑链条不复杂,只是它对今天的企业叙事太不友好,所以很少有人愿意把它讲完。

被裁掉的人,会从“降掉的成本”变成“新增的竞品”

裁员时代有一个常见幻觉:企业裁掉的是冗余的人手。

这个说法在流水线时代比较容易成立。机器替代的是重复动作,企业减少的是可替换岗位。员工离开企业之后,很难立刻变成原公司的竞争对手。一个熟练工人可以去另一家工厂,也可以成为小作坊老板,但他很难单独复制一座现代工厂。

AI 让这个边界变得暧昧。白领岗位的许多工作本来就不依赖重资产。写方案、做设计、跑数据、写代码、剪视频、搭投放、做客服、做市场研究、做产品原型。这些工作以前依赖团队,并不完全因为每个环节都极端困难。更多时候,是因为一个人没有足够时间、精力和技能跨度同时处理全部环节。

AI 的作用,正是在这些缝隙里长出来的。它没让普通人立刻变成天才,更像给一个判断力尚可的人套上一组外骨骼。原来需要五个人轮流完成的动作,现在一个人可以先做出一个勉强能跑的版本。原来需要跨部门排期的协作,现在可以在一个下午里被压缩成多轮提示词、几次脚本调用和一组自动化工作流。

所以,企业裁掉的就不再只是“手”。它裁掉的是一批懂业务、懂流程、懂客户、懂公司弱点的人。

Block 前员工接受采访时说,自己每天都在用 AI,很清楚自己正在被工具替代。[1] 这句话有一种黑色幽默。最危险的员工并非不会用 AI 的人,恰恰是最会用 AI 的人。他们知道 AI 能做什么,也知道公司内部哪些工作只是靠流程和人力堆出来的幻象。

当这些人离开组织,他们带走的不只是技能简历。他们还带走了组织的隐性地图:客户真正抱怨什么,供应商卡在哪里,产品经理最怕哪类需求,销售话术里哪些是包装,哪些是实话,内部流程中哪些节点只是权力装饰。

过去,这些知识常常被锁在组织里。员工知道,但员工离开后很难把它们变成产品。因为从知道到交付,中间隔着团队、资金、开发、设计、运营、获客和客户服务。AI 把这段距离压短了。一个被裁掉的中层经理,未必能立刻做出一家亚马逊,但只要他熟悉某个垂直环节,就能做出一个更薄、更快、更便宜的工具,专门服务原公司看不上的小客户群。离开大厂的产品经理可以围绕一个痛点做轻量 SaaS;被自动化替代的客服主管,往往最清楚哪些问题该交给 AI、哪些还得留给人。

大公司的威胁不再只来自另一家大公司,它可能来自一万个非常小、非常窄、非常懂局部需求的一人公司。

这听起来像夸张的未来学修辞,可在 AI 应用层,它已经长出了几个现实切面。最好的例子是 Cursor。

Cursor 是 Anysphere 做的 AI 编程工具。它不是什么在大公司视野之外自娱自乐的小玩具,而是直接杀进了 Microsoft 和 GitHub 的地盘。CNBC 报道,Cursor 在 2025 年完成 23 亿美元融资,投后估值达到 293 亿美元。它还宣称年化收入超过 10 亿美元,员工数超过 300 人。[10]

这个数字本身已经足够刺眼。一个 2022 年成立、2023 年才推出核心产品的团队,在开发者工具这个被 Microsoft、GitHub、JetBrains 等大公司长期占据的市场里,跑出了传统企业软件很难想象的速度。

Menlo Ventures 的 2025 年企业生成式 AI 报告说得更直接:GitHub Copilot 明明有先发优势,也有 Microsoft 的分发优势,可 Cursor 还是靠更快的产品迭代抢走了显著份额。它更早做出了 repo 级上下文、多文件编辑、diff 审批、自然语言命令,并且采用模型无关策略,让开发者可以更快用上 Claude Sonnet 3.5 这类前沿模型。Menlo 还提到,Cursor 在雇佣企业销售之前,收入已经达到 2 亿美元。[11]

这件事的关键,不在于 Cursor 未来会不会变成另一个大公司。关键在于,它没有重建一个完整的 Microsoft,也没有重新发明一套操作系统、一套云服务、一套 Office、一套企业销售机器。它只是抓住开发者日常工作流里最有价值的一个触点,把“写代码”这个动作重新组织了一遍。

AI-native 小团队的可怕就在这里:不必复制巨头,只要在巨头身上找到一块疼痛的肌肉,再把它变成自己的入口。

Gamma 是另一个更适合白领读者理解的例子。TechCrunch 报道,做 AI 演示文稿和视觉表达工具的 Gamma 在 2025 年达到 1 亿美元 ARR,估值 21 亿美元。公司创始人称,这个成绩是由大约 50 名员工完成的,而且公司已经盈利。[12]

50 个人,1 亿美元年化收入。这不是传统意义上的“超级组织”,甚至连一家中型互联网公司的管理半径都算不上。但它切到的是 Microsoft Office 里极其稳定、极其古老、极其高频的局部场景:做 PPT。

Gamma 没有试图复制 Office。它不需要做 Word、Excel、Teams、Outlook、SharePoint,也不需要重建企业账户体系。它只盯着一个白领痛点:人们不是不会做 PPT,人们是厌烦在格式、排版、视觉层级和叙事结构上耗费大量时间。

PowerPoint 把表达变成了页面排版问题,Gamma 把表达重新变成了生成问题。这就是小团队拆大公司的典型方式。大公司拥有套件,小团队只拿走套件里最烦人的一环。大公司负责历史包袱,小团队负责把用户最痛的那一刀磨快。

法律服务里的 Harvey,则把这个逻辑推到了更硬的行业。法律服务过去是典型的“大组织才能承接”的知识工作。它需要资深律师、初级律师、助理、文档审查、合同分析、尽职调查、合规判断、诉讼材料整理。大量工作需要专业判断,也需要大量重复劳动。越大的律所,越像一台用资历、小时费率和层层复核堆起来的知识工厂。

Harvey 的出现说明,这类知识工厂也开始被拆。Harvey 在 2026 年宣布以 110 亿美元估值融资 2 亿美元。官方称,已有 25,000 多个 custom agents 在 Harvey 上运行,覆盖 M&A、尽职调查、合同起草、文档审查等任务;超过 100,000 名律师、1,300 多个组织在 60 多个国家使用 Harvey,其中包括多数 AmLaw 100 律所、500 多家企业法务团队和 50 家资产管理公司。[13]

当然,Harvey 没有消灭律所,也不可能让法律服务变成纯自动化。可它已经把律所和企业法务内部的一部分人工流程,变成可以由 agent 承接的工作流。过去由初级律师、助理和外包团队完成的大量文档工作,现在可以被产品化、流程化、系统化。

这对本文来说已经足够。Cursor 没有消灭 Microsoft,Gamma 没有消灭 Office,Harvey 没有消灭律所。可它们共同证明了一件事:AI 小团队不需要推倒大公司,先切走大公司的一块高价值流程就够了。巨头仍然站在那里,只是身上开始多出一些缺口。

这也是“一人公司”,或者说 AI 赋能小型公司叙事真正锋利的地方。它并不只是创业鸡汤,也不是“人人都可以不上班”的自由职业幻想。它真正改变的是竞争单位的颗粒度。过去,企业面对的是企业。今天,企业可能面对的是从自己身体里脱落出去的一组细胞。

这些细胞曾经参与过组织运转,知道组织的语言、节奏和病灶。它们离开之后,不需要复制母体的全部器官,只需要攻击其中一个薄弱环节。

工业革命摧毁手工业者的优势,是因为机器把规模带到了手工艺人无法竞争的维度。AI 革命的反讽在于,它可能把一部分规模优势重新拆回个人手里。这不是简单复古,更像一次螺旋回归。手工业者曾经败给工厂,因为个人无法承受现代生产的复杂性。今天,一部分复杂性被模型、API、自动化流程和外包网络吸收,个人重新获得了向组织讨价还价的能力。

员工和创业者之间的边界正在变薄。当一个人能做十个人的活,他到底是一名员工,还是一家暂时寄居在公司里的微型企业?企业越强调 AI 提效,这个问题越难回避。

因为它等于在告诉员工:你已经不只是一个岗位了。你是一套可以被复制、外移、重新定价的小型生产系统。

一旦员工相信了这句话,企业就很难再让他只相信前半句。

企业曾经解决协作问题,AI 正在抽走这个理由

“企业为什么存在?”这个问题看起来很像商学院第一堂课,它也确实是。

1937 年,罗纳德·科斯在《企业的性质》中提出一个后来反复被引用的解释:企业之所以存在,是因为市场交易有成本。寻找交易对象、谈判价格、签订合同、监督履约、处理纠纷,这些事情都要花钱。企业把一部分市场交易内部化,用管理命令替代反复谈判,由此降低成本。[4]

通俗一点说,公司是一种省麻烦的机器。如果每一次协作都要在市场上重新找人、议价、签合同、对齐目标,人类社会很难完成复杂生产。企业把人招进来,把角色固定下来,把指令链条建立起来。你在这里写代码,他在那里做设计,另一个人负责销售,还有人管财务、法务、人力和行政。

这套结构的价值,来自一个基本事实:人类协作很贵。

沟通贵,信任贵,交接贵,犯错贵。组织越大,这些成本越高。中层管理、会议制度、流程审批、绩效考核、预算周期,很多东西看起来烦人,却都在处理一个古老问题:如何让大量有限理性的人,围绕一个目标持续行动。

所以,大公司从来不只是办公室、工牌和财务报表。它是人类大规模协作的社会动员工具。

“超级组织”这个概念如果有意义,也应该落在这里:一个依然以科层制组织大量人力、又被 AI 强化过的大型企业。它不是单纯掌握算力、数据和协议的超级平台。平台可以很强,可以很赚钱,可以控制入口,但如果它不再需要组织大量人力去完成个体无法完成的事,它就不再是本文意义上的超级组织。

这一区分很重要。因为许多关于“超级组织”叙事,实际偷换成了“超级平台”叙事。

Meta、Google、OpenAI、微软当然可能在 AI 时代继续强大。它们掌握模型、算力、数据、分发、开发者生态和资本入口。可这只能证明平台权力仍然存在,无法证明科层大企业作为人力动员工具会继续膨胀。

假设某一天,Meta 真的靠 AI 把全球员工数量从 8 万多人压回 2008 年左右的 400 人规模。它可能仍然是一家超级平台,甚至更恐怖。但它已经不再是传统意义上的超级企业。它不再通过组织海量员工完成任务,而是通过协议、算法和基础设施支配外部协作。

这就是 AI 对企业的第一刀,它瓦解的是公司作为一种组织形式存在的理由。

如果一个人能调用模型完成调研、写作、设计、编程、测试、投放和客服,企业内部把这些岗位固定为部门的必要性就会下降。如果智能体之间可以用 API、工作流和标准接口协作,组织内部的沟通链条就会被外部协议部分替代。如果项目可以由一组临时组合的小团队完成,长期雇佣大量员工的收益就会变得不稳定。

企业原本靠内部管理压低交易成本,而 AI 让一部分市场交易成本本身降了下来。这话不是空谈,企业已经在用钱投票。

Menlo Ventures 的 2025 年企业生成式 AI 报告显示,企业生成式 AI 支出从 2024 年的 115 亿美元增长到 2025 年的 370 亿美元,增长 3.2 倍。其中 190 亿美元流向应用层,占全部生成式 AI 支出超过一半。再看一组数:企业 AI 用例里,76% 是购买外部方案,只有少数选择内部自建。2024 年,企业还是 53% 购买、47% 自建。[11]

这组数字说明,企业并没有在 AI 时代本能地把所有能力都收回内部。相反,它们正在更快地购买外部 AI 应用。也就是说,当外部市场可以提供足够快、足够便宜、足够可用的 AI 能力时,企业并不会为了“组织完整性”而坚持内部建设。从科斯的角度看,这就是企业边界在后退。

过去,一个能力要留在公司内部,因为外部采购太慢、太贵、太难监督。今天,一个员工可能先用个人信用卡订阅某个 AI 工具,在工作里证明它有用,然后它再被团队采购、部门采购、公司采购。Menlo 的报告也说,AI 应用支出中有 27% 来自 PLG,也就是产品驱动增长,接近传统软件 7% 的 4 倍。如果把员工私下使用 ChatGPT Plus 这类“shadow AI adoption”也算进去,PLG 驱动的支出可能接近 40%。[11]

这条路径很有意思。传统企业软件是自上而下的:老板、IT、采购、法务、财务、供应商、合同、上线。AI 工具常常是自下而上的:员工先用,团队跟进,组织承认。边界不是 CEO 在会议室里画出来的。边界被员工的工具使用习惯重新划线。

当外部工具先进入工作,再进入合同,组织内部的技术能力就不再完全属于组织。它有一部分属于员工的工具箱,有一部分属于外部应用,有一部分属于模型 API,有一部分属于平台。企业还是企业,可企业的皮肤开始变薄。

BPO(Business Process Outsourcing,业务流程外包)的变化,则是这件事的另一个侧面。

BPO过去是企业处理大量重复、交易性工作的标准解法。客服、IT 外包、财务理赔、发票核对、医疗收入周期管理,很多企业不想内部养一支庞大队伍,就交给外部服务商。a16z 的文章指出,BPO 市场在 2024 年已经超过 3,000 亿美元,预计 2030 年超过 5,250 亿美元。[14]

BPO 本质上也是一种组织。企业不愿内部组织人力,于是把人力组织交给另一个大公司。Cognizant、Infosys、Wipro 这类公司承接的,正是大企业不愿自己处理、却又离不开的大量流程。可 AI 正在拆它。

a16z 把这件事称为 “productize and unbundle the BPO”。也就是把外包服务产品化、拆包化。过去企业要买一整套外包人力,现在可以购买一个 AI agent、一个垂直软件、一个半自动工作流,再配少量人工监督。

它举了几个例子。Decagon 的 AI 客服 agent,可以在客户那里达到 80% 以上的解决率,并改善客户满意度。Camber 把生成式 AI 用在医疗收入周期管理中,有客户首次提交拒付减少 80%,理赔和账单流程节省 50% 时间。[14]

这些案例不证明 BPO 会立刻消失。它们证明的是,大规模外部人力组织也会被拆。以前一个企业自己不想做,就外包给另一个企业。现在 AI 把这个外部企业再拆一次:把服务拆成软件,把流程拆成 agent,把人工拆成监督,把项目拆成按需调用。

这会让“大组织”的边界从两侧同时变薄:公司内部岗位被压缩,公司外部服务商被产品化,中间留下来的,是一组更小、更薄、更高频连接的生产单元。

这并不意味着所有企业都会消失。科斯理论从来没有说世界会变成纯市场。现实也早就证明,企业边界受到很多因素影响:资产专用性、知识积累、组织能力、风险承担、品牌信任、资本结构、监管许可。深圳社科关于企业边界的研究材料也提醒过,交易成本理论本身有解释边界,企业能力理论则强调企业创造知识、人力资本和核心能力的作用。[5]

这正是“超级组织”支持者最强的反驳。他们可以说:企业不只是为了省沟通成本而存在。企业还能沉淀能力,积累品牌,承担风险,调动资本。AI 可以替代一些岗位,却抹不掉这些结构性优势。

这个反驳值得认真对待,但它没有击穿问题。因为 AI 也在进入这些看似更深的层次。

所谓“沉淀核心能力”,过去很大一部分是把人的经验、流程和判断长期锁在组织里。今天,大企业正在做的事,恰恰是把员工经验和组织流程蒸馏进系统。客服话术、销售方法、代码规范、财务流程、法务模板、产品决策文档、运营 SOP,都可以被结构化、向量化、自动化。

这当然不等于 AI 立刻拥有人的全部判断。可它足够改变组织对人的依赖方式。以前,企业要保留某个能力,就必须保留掌握能力的人和团队。现在,企业会越来越多地尝试保留能力的影子:知识库、智能体、自动化流程、模型微调、内部工具。能力从人身上被刮下来,变成系统的一部分。

Harvey 的例子就很典型。法律专业能力本来最依赖人、资历、上下级复核和事务所文化。可一旦合同审查、尽职调查、文件归纳、条款比对被 agent 化,能力沉淀就不再只发生在律所内部的人身上。它也发生在系统、工作流和模型调用中。

这一步很残酷。它把“员工是公司最宝贵资产”这句老话翻译成了另一种现实:员工也是可被提取的数据源。

至于风险承担,它也未必必须由一家大公司承担。资本可以承担风险。股东可以通过组合投资分散风险。董事会可以持有多个小公司的股权。VC 本来就靠一组项目的失败换一个项目的高增长。AI 时代如果让更多小单元具备独立交付能力,风险不一定消失,但风险可以从组织内部转移到资本组合中。

企业能力理论提醒我们,大公司不会因为沟通成本下降就原地蒸发。但它无法保证大公司会沿着“超级组织”的方向扩张。更可能出现的情况,是大公司把一部分能力系统化,把一部分风险资本化,把一部分执行外部化。留下来的核心壳层可能更强,里面的人却未必更多。

Menlo 报告里还有一个数据可以佐证我们的观点,2025 年,AI 应用层创业公司拿到 63% 的市场份额,上一年还是 36%。创业公司在产品、工程、销售、市场、产品等敏捷部门更强;传统大厂在 IT 和数据科学这类依赖深度集成和可靠性的领域仍然更强。[11]

这正好说明 AI 时代的组织变化不会走向一个单一结论。不是所有地方都被小公司拿走。基础设施、集成、合规、可靠性,仍然偏向大厂。可在那些碎片化、数据密集、反馈快、对产品速度敏感的工作里,小团队确实在拿走原本属于大组织的份额。

这时候,“超级组织”的叙事就会遭遇一个进退两难式的困境。

如果 AI 足够强,强到一个人可以通过智能体完成大量企业岗位的工作,那么超级个体会把超级组织瓦解。

如果 AI 不够强,像一些研究和报道所说,只能可靠处理大约三分之一的真实业务,那么它从一开始就撑不起“超级组织”这四个字。

Gartner 预测,到 2027 年,一半因 AI 裁员的公司会重新招人。Forrester 称 55% 的雇主对裁员感到后悔。Klarna 曾高调宣称用 AI 替代 700 名客服,后来又重新招聘真人客服。[6]

两条路的终点并不一样,但都绕不开同一个结论。AI 很强时,大组织被个体和外部协作侵蚀;AI 不够强时,超级组织只是管理层 PPT 里的新瓶旧酒。最稳定的可能性,反而是中间态:公司继续存在,平台继续集中,员工继续被压缩,小团队继续增多,个体获得更多工具,也承担更多不确定性。

这听起来不够振奋,可历史上的组织变迁,大多数都不是励志故事。

大企业的终局可能是一场内部裂解

如果超级组织不成立,大企业会去哪里?一个更有解释力的设想,是内部裂解。

不是所有大公司都会被外部创业者推翻。那太戏剧化,也太符合硅谷神话。更现实的路径,可能是大公司自己把内部拆成大量更小的经营单元。它们共享资本、品牌、基础设施和一部分规则,却在业务层面彼此竞争、组合、分拆和重组。

这种形态并非完全陌生。

海尔的“人单合一”、稻盛和夫的阿米巴经营、内部创业制、事业群拆分、spin-off、员工持股平台、加盟网络、控股集团,都可以看作某种早期影子。它们未必成功,也未必适合所有行业,但都在回应同一个问题:当组织太大,如何把市场压力重新塞回组织内部?

其中最值得展开的是海尔。Corporate Rebels 在研究海尔的人单合一模型时写到,这家拥有 70,000 多名员工的中国家电企业,曾经把公司拆成 4,000 多个自管理微型企业。这些微型企业像独立实体一样运行,有所有权、决策权和“由用户付薪”的机制。海尔的逻辑是让员工直接面对用户需求,而不是在传统金字塔里等待上级命令。[15]

张瑞敏曾把传统封闭金字塔称为“帝国”,把人单合一之后的开放网络称为“雨林”。帝国依靠中心指挥,雨林依靠大量物种之间的自我组织。这个比喻当然有管理学修辞的成分,但它足够准确地说出了大企业裂解的方向:组织不再只是一座垂直大楼,也可以是一片由大量小单元组成的生态。

2016 年,海尔收购 GE Appliances 之后,也尝试把这种模型带入美国组织。Corporate Rebels 提到,GEA 当年的销售增长 11%,尽管市场整体下滑 1%。这个数字不能证明人单合一必然成功,更不能证明它能复制到所有行业。可它证明了一件事:把一个大公司拆成大量微型企业,并不是 AI 时代写作者坐在电脑前发明的概念。它被真实公司严肃实践过,也被管理学界长期研究过。[15]

海尔更像前 AI 时代的笨重版本。没有大模型,没有 agent,没有低代码工作流,没有成熟的云基础设施,一个大企业尚且需要靠组织革命把自己拆小。到了 AI 时代,拆小的技术成本会更低,协调成本也会更低。

以前一个小单元独立面对市场,需要自己处理产品、供应链、客服、财务、数据、营销、人力。今天,它可以从共享平台调用更多能力。财务可以自动化,客服可以 agent 化,营销素材可以生成,数据分析可以交给模型,项目管理可以由工具维护。

这不意味着所有人都能变成老板。它只意味着,小单元维持独立运转所需的最低组织成本下降了。

AI 会把这个问题推到更极端的位置。一个大企业内部,过去可能需要几万人的事业部,未来也许可以被压缩成几百人甚至几十人的单元。一个产品线可以像创业公司一样运行,只保留少量关键判断者,剩余执行由模型、自动化工具、外包网络和共享后台完成。多个小单元之间既竞争客户,也共享底层能力。股东和董事会不再只押注一个庞大组织的整体效率,而是持有一组更细颗粒度的业务组合。

这有点像蜂巢。每个小单元有自己的局部任务、信息和节奏。它们不必每天通过一个巨大的中央大脑接受指令,而是通过接口、规则、资本和目标彼此连接;需要时聚合,完成后拆散;失败的单元被关闭,成功的单元获得更多资源。

“蜂巢式协作”的想象最迷人的地方,不在于它多自由,而在于它把组织从“固定结构”变成了“动态编队”。过去,公司像一栋楼。部门是楼层,岗位是房间,晋升是往上爬。未来的一部分公司可能更像一组临时舰队。每艘船都不大,但可以围绕不同任务快速集结。它们需要共同海图、通信协议和补给系统,却未必需要一个把所有船员永久雇佣起来的巨型船坞。

这套设想当然有很多问题。它可能制造更强的资本控制。因为当组织被拆细,个体和小团队看似更自由,资本却可以用组合投资、平台规则和协议入口掌握更高层的分配权。它也可能制造更糟糕的劳动保障。过去公司至少承担一部分雇佣责任、培训责任和社保责任。小单元化之后,更多风险会落到个人身上。每个人都像创业者,听起来很酷。可创业者的另一面,是没人保证下个月还有收入。

它还可能带来新的协调难题。没有科层组织之后,谁来决定标准?谁来处理纠纷?谁来保证质量?谁来分配收益?

Web 3.0 曾经给过一个激进答案——DAO(Decentralized Autonomous Organization)。DAO 希望用代码、代币、投票和链上规则替代传统公司。它把“公司”这个东西拆到更底层:没有老板,没有办公室,没有传统股权结构,大家围绕协议协作。

但 DAO 的实践也暴露出一个冷冰冰的约束:去中心化、高效决策和唯一共识很难同时获得。越去中心化,决策越慢;越追求效率,权力越容易重新集中;越想形成统一行动,越需要某种中心化机制。[7]

这正好说明组织的裂解并不等于无摩擦天堂。没有科层,不代表没有治理成本。很多治理成本会换一种形态出现:投票疲劳、共识成本、治理代币集中、低效决策、责任不清、少数活跃者事实掌权。

企业嘴上说要超级组织,身体却在减少最能代表科层组织的中间层。Big Tech 的超级扁平化是被成本和 AI 叙事推着压缩中层,海尔的人单合一是主动拆成微型企业,两者的出发点不同,方向却有重叠:组织中间层正在变薄,小单元的压力正在变大。

所以,裂解不等于乌托邦。它只说明大组织的一部分功能可能被重排。企业曾经把协作、风险、资本、知识、身份和保障打包在一起。AI 时代,这个包裹会被拆开。协作交给协议,风险交给资本组合,知识交给模型和知识库,身份变成个人品牌和小团队声誉,保障则成为最麻烦、最容易被甩出去的问题。

这也是“超级个体”叙事需要被泼冷水的地方。个体被增强,不代表个体被解放。他可能获得更强的工具,也可能被迫承担更多原本由组织承担的波动。他可能更容易拿到资本,也可能更容易被平台和模型供应商卡住喉咙。他可以从老板那里独立出来,却未必能从 API 价格、模型限流、分发算法和客户付款周期中独立出来。

卖水者永远在场。淘金者变成一人公司以后,水、铲子、地图和道路仍然可能掌握在少数平台手里。大企业作为雇佣组织收缩,不代表权力自动分散。它可能只是从人力组织层迁移到基础设施层。

所以,我们需要把两个概念分开:超级平台可能存在,超级协作也可能存在,超级组织却未必存在。平台掌握入口、算力、数据和协议。协作发生在大量个体、小团队、智能体和外包网络之间。组织作为大规模雇佣人力的科层工具,反而可能被压缩到更小、更薄、更核心的位置。

这正是标题里的“带不来超级组织”的原因。也许没有超级组织。有的只是超级平台之下的超级协作。

协调者会不会重新长成公司?

所有关于去中心化协作的讨论,最后都会撞上同一个问题:如果没有公司,谁来协调?

这是一个好问题,因为它指出了许多“未来组织”叙事里的浪漫病。人们喜欢想象自由个体在网络里自动组合,好像只要有 AI、协议、规范,协作就会像水流一样自然发生。现实通常更粗糙。协作需要标准,需要信任,需要纠纷处理,需要版本控制,需要权限管理,需要收益分配。没有这些东西,自由协作很快就会变成自由扯皮。

但协调者不一定必须是传统意义上的公司。程序员世界已经给过一个非常好的例子:Git。

Git 是一种版本控制系统。它让大量开发者可以围绕同一套代码协作,记录修改、回滚版本、合并分支、处理冲突。现今由微软所运营的 GitHub 则是建立在 Git 之上的中心化平台,它提供托管、协作、讨论、权限、自动化和社区发现。

GitHub 很强,也很中心化。可一般人不会说 GitHub 是程序员世界的“超级组织”。它没有把全球程序员都雇佣进来,也没有用科层命令指挥开源社区。它更像基础设施和协议枢纽。它让协作发生,记录协作,降低协作成本,并从协作中获得平台权力。

这一区别可以迁移到更广泛的 AI 协作。未来的小公司、一人公司、智能体网络,也许会通过类似 Git、API、A2A 的方式协作。大家围绕标准接口交付任务,围绕协议交换数据,围绕平台建立声誉,围绕合约和支付系统完成结算。

这里当然会出现中心节点。会有新的 GitHub、新的 AWS、新的 Shopify、新的 Stripe、新的模型平台、新的 Agent 协议层。它们可能比今天的大公司更有权力。它们收取通行费,规定格式,决定谁能接入,谁会被推荐,谁被限流。

但这类中心节点的本质更接近基础设施。它组织协作,却不一定组织人力;它制定规则,却不一定雇佣参与者;它拥有平台权力,却不一定承担传统企业对员工的管理和保障责任。

这就是“超级协作”和“超级组织”的分野。超级协作强调规模巨大、节点众多、连接高频、标准统一。超级组织强调科层结构、雇佣关系、内部命令和人力动员。两者都可能很强,但强在不同层面。

把超级协作误认为超级组织,会让我们看错 AI 时代的权力位置。我们会以为未来的大公司更像今天的大公司,只是每个人手里多了几个智能体。实际更可能出现的是:公司变薄,平台变厚;雇佣关系变少,协议依赖变多;中层管理减少,基础设施控制增强。

这个变化对普通人并不天然友好。以前你讨厌老板,至少知道老板坐在哪里。未来你讨厌的可能是一组看不见的接口规则:模型调用费涨了,API 限流了,平台搜索权重变了,支付通道风控了,智能体协议更新后你的工作流失效了。

这种依赖不是空想。Supertab 分析 AI 应用构建者时指出,大量 AI 创业公司都依赖少数基础模型供应商。上游提供商调整价格、访问权限、rate limits 或模型可用性,都会直接影响下游产品的性能和利润。麻烦还在后头。AI 产品的成本结构和传统 SaaS 不一样。传统 SaaS 的边际使用成本相对稳定,AI 产品的每次交互都可能产生 token、检索、数据访问和推理成本。[16]

这意味着,一个看起来很轻的 AI 应用,背后其实拖着一条按次计费的尾巴。用户多用一次,它就多烧一次钱;客户越依赖它,它越依赖上游。

这和过去的互联网软件不太一样。过去,一个 SaaS 产品做到规模之后,服务器成本往往会被收入摊薄。今天,一个 AI 应用做到规模之后,推理成本、检索成本和数据授权成本可能跟着一起放大。你可以做出很漂亮的产品,也可以获得很多用户,但只要你的核心能力来自上游模型,你的毛利率就会被别人捏在手里。

上游的模型公司也没闲着,它们同样在扩张自己的产品生态。OpenAI、Anthropic、Google、Microsoft 不会永远安静地待在 API 层。它们会做企业版,会做 agent,会做插件,会做办公套件集成,会把过去属于应用层的能力吸回平台里。

卖水的人还有第二重身份。第一重,是淘金者得向他买水;第二重,是他看着淘金者赚钱,自己也跳下去淘金。

AI 应用层里,创业公司确实拿走了 63% 的市场份额。可到基础设施层,格局立刻不同。Menlo 的一份报告称,基础设施层 incumbent 仍然拥有 56% 的市场份额;企业 LLM API 支出高度集中在 Anthropic、OpenAI、Google 三家公司,三者合计占 88%。[11]

所以,AI 时代的权力分布可能很奇怪:应用层碎片化,基础设施层集中化。前台看起来到处都是小公司、独立开发者、一人公司、垂直 agent。后台则是少数模型、少数云、少数数据入口、少数分发平台,像地基一样托着所有人。权力没消失,只是换了张皮。

这也是为什么“没有超级组织”不等于“没有超级权力”。AI 也许削弱的是公司作为人力动员机器的必要性。它未必削弱资本、平台和基础设施的支配力。甚至,在某些维度上,它会让这些力量更集中。因为越多小单元依赖同一套基础设施,基础设施就越像空气。空气当然不需要每天命令你。它只需要决定你能不能呼吸。

解放与灾难会同时发生

任何关于“超级个体”的讨论,最后都逃不开价值判断。这到底是解放,还是灾难?

答案很难讨巧。它会同时发生。

对一部分人来说,AI 确实会带来前所未有的杠杆。一个有判断力、有行业经验、有表达能力、有产品感的人,可以用更低成本验证想法、触达客户、组织生产。他不必等待一家大公司给岗位,也不必通过漫长晋升获得资源。模型、自动化工具、低代码平台、支付系统和云服务,会把许多过去昂贵的基础能力开放出来。

这对创作者、开发者、咨询顾问、设计师、研究者、小型服务商,都是实实在在的机会。过去,个人最缺的是执行力。今天,执行力正在变便宜。真正稀缺的东西会变成判断力、审美、问题定义能力、客户理解、责任承担和信用积累。换句话说,稀缺从“手”转向“脑”,从工时转向认知密度。

这听起来很适合知识工作者自我感动。但另一方面的情况也要看看。

当执行力变便宜,很多执行岗位的议价能力会下降。当组织变薄,很多组织原本承担的缓冲功能会消失。当一人公司成为最小经济单元,个体获得自由的同时,也会被迫经营自己、销售自己、融资自己、保障自己。

你可以说这是一种解放,也可以说这是把企业风险拆碎后分发给每个人。

过去,一个普通员工可以在大公司里隐藏一部分波动。业务好坏未必立刻传到工资卡上,项目失败未必立刻导致个人破产。公司当然会压榨人,但公司也在某种程度上吸收了市场震荡。

未来,如果更多人以小单元方式参与协作,市场会更快、更直接地穿透到个人身上。客户不续费,就是你下个月的现金流问题。平台降权,就是你获客成本的问题。模型涨价,就是你毛利率的问题。合同纠纷,就是你自己的法律成本。没有部门替你挡,没有中层替你背锅,也没有公司品牌替你兜底。

这不是“人人创业”的浪漫版本,这是“人人暴露在市场里”的现实版本。

资本也会在这场变化中变得更微妙。一方面,资本集中度可能更高。基础模型、算力中心、云服务、分发平台、支付网络、企业软件入口,都需要巨额投资和规模效应。越多小团队依赖它们,它们越像新的地主。另一方面,个体获得资本青睐的概率也可能上升。

过去,资本投一个项目,往往需要看到团队、组织、招聘计划、扩张路径。未来,一个非常小的团队如果能用 AI 做出足够高的产出,也可能更早进入资本视野。资本会更愿意下注小而快的单元,因为试错成本更低,组合投资更方便。

前文提到的Cursor、Gamma、Harvey 等案例都指向同一件事:资本正在重新认识“小团队”的上限。过去,投资人看一家企业,要看团队规模、招聘计划、销售体系、交付能力。今天,一个 50 人团队可以做到 1 亿美元 ARR,一个 300 人团队可以宣称 10 亿美元年化收入,一个垂直 AI 公司可以把专业服务流程变成 agent 平台。资本当然会兴奋。它们看见的不是“人少”,而是单位人力背后的杠杆变大。

这会制造一种奇怪的社会图景。个体更强,也更脆弱;平台更强,公司更平;资本更集中,创业颗粒度更小。组织消失了一部分,但组织留下的问题没有消失:谁承担失败,谁分配收益,谁获得保障,谁制定规则,谁拥有退出权。

所以,这篇文章不想给大企业开药方。“企业该怎么办”是另一个问题,而且常常会把所有结构性讨论拉回管理咨询腔。仿佛只要企业拥抱 AI、重塑流程、激活组织、打造生态,就能把所有矛盾熨平。

无论哪条路,“超级个体 + 超级组织共生共荣”的对称故事都太顺滑了。真实世界很少这么对称。

尾声:也许真正的“组织”已经改名了

“超级组织”这个词的诱惑在于,它过于顺滑的将 AI 赋能个人过渡到了 AI 赋能企业。

公司还在,只是更强。员工还在,只是更强。老板还在,只是更懂 AI。产业还在,只是效率更高。每个人都获得增强,每个企业都获得升级,旧世界原地安装一个新引擎,就可以继续向前开。

这很符合组织自己的愿望。没有一种组织会轻易想象自己的消失。它们更愿意相信,所有新技术最终都会成为自己的新工具。蒸汽机、流水线、计算机、互联网、云计算,很多时候也确实如此。新技术先冲击组织,随后被组织吸收,最后反过来强化组织。

AI 的麻烦在于,它强化的对象并不只属于组织。它强化每一个能提出问题、调用工具、组合资源、承担责任的人。它把执行力从组织内部释放出来,又把组织流程蒸馏成可复制的系统。它让大公司看起来更高效,也让离开大公司的人更危险。

于是,前文提到的悖论终将浮出水面:如果 AI 没有那么强,超级组织只是口号;如果 AI 真的那么强,超级组织会失去地基。

这不是一个经验预测意义上的绝对断言。大公司不会明天消失,平台巨头也不会因为一人公司出现就主动交出权力。重资本行业、线下制造、医疗、能源、交通、监管牌照,都会让组织继续保留强大的现实基础。具身智能真正压进线下世界,也还需要时间。

本文否定的也不是“公司”本身。公司当然会继续存在,平台当然会继续存在,资本当然会继续存在。甚至很多公司的利润率、控制力和市场地位都会变得更强。真正退潮的,是公司作为“大量人力 + 中层管理 + 内部协调”的历史功能。

以前,公司把人装进去。以后,协议把人连起来。

个体离开科层之后,并不会自动进入自由王国。他会进入模型 API、平台规则、支付系统、资本组合、声誉网络和协议接口共同编织的新秩序。公司这只壳可能还在,只是它里面装的东西变少了,外面连接它的东西变多了。

但在白领工作、数字产业、创意生产、软件服务和知识协作这些领域,趋势已经足够清楚。企业作为人力动员工具的黄金时代,正在被 AI 反向蚕食。

未来也许仍然有巨头,也许仍然有平台,也许仍然有资本权力高度集中的基础设施,可那未必是“超级组织”。真正的超级组织,也许已经不再长得像一家公司。它更像一套去中心化的协作协议,一组无处不在的接口,一张由模型、平台、小团队、个人和资本共同编织的网络。

它没有工牌,也没有组织架构图。但每个人都在里面工作。

参考资料

[1] 版面之外(作者:画画):《历史上第一次,AI 成为裁员公开理由》。https://mp.weixin.qq.com/s?__biz=MTQzMjE1NjQwMQ==&mid=2656154796&idx=2&sn=a91772517d908267d19cba4944f55601

[2] 纽约时报:《AI 成为科技公司裁员的新借口》;BBC 中文关于 AI 裁员叙事的相关报道。https://cn.nytimes.com/technology/20260603/ai-tech-job-cuts/ | https://www.bbc.com/zhongwen/articles/cn4vwyk3np3o/trad

[3] 周鸿祎清华演讲相关报道;经济参考报关于“一人公司”和 OPC 的报道。https://tech.huanqiu.com/article/4Oi9y3f9v1n | https://www.stcn.com/article/detail/3582207.html

[4] 中国社会科学网关于科斯《企业的性质》和交易成本理论的述评。https://www.cssn.cn/skgz/bwyc/202409/t20240904_5775620.shtml

[5] 深圳社科关于企业边界决定、交易成本理论与企业能力理论的研究材料。http://www.szass.com/attachment/0/31/31447/666473.pdf

[6] 钛媒体关于 AI 裁员“回旋镖”、Gartner、Forrester 与 Klarna 案例的报道。https://www.tmtpost.com/7930199.html

[7] 上海财经大学关于 DAO 与公司制、去中心化组织治理约束的研究。https://qks.sufe.edu.cn/mv_html/j00002/202402/4c0a1b0b-e780-4dc4-8cd2-b37082a7d1d9_WEB.htm

[8] CNBC:Amazon targets middle managers in mass layoffs, memo suggests more cuts coming as AI thins Big Tech。https://www.cnbc.com/video/2025/10/28/amazon-targets-middle-managers-in-mass-layoffs-memo-suggests-more-cuts-coming-as-ai-thins-big-tech.html

[9] Axios:Middle managers fade as AI rises。https://www.axios.com/2025/07/08/ai-middle-managers-flattening-layoffs

[10] CNBC:AI startup Cursor raises $2.3 billion round at $29.3 billion valuation。https://www.cnbc.com/2025/11/13/cursor-ai-startup-funding-round-valuation.html

[11] Menlo Ventures:2025: The State of Generative AI in the Enterprise。https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/

[12] TechCrunch:AI PowerPoint-killer Gamma hits $2.1B valuation, $100M ARR。https://techcrunch.com/2025/11/10/ai-powerpoint-killer-gamma-hits-2-1b-valuation-100m-arr-founder-says/

[13] Harvey 官方公告:Harvey Raises at $11 Billion Valuation to Scale Agents Across Law Firms and Enterprises。https://www.harvey.ai/blog/harvey-raises-at-dollar11-billion-valuation-to-scale-agents-across-law-firms-and-enterprises

[14] a16z:Unbundling the BPO: How AI Will Disrupt Outsourced Work。https://a16z.com/unbundling-the-bpo-how-ai-will-disrupt-outsourced-work/

[15] Corporate Rebels:RenDanHeYi: The Organizational Model Defining The Future Of Work? https://www.corporate-rebels.com/blog/rendanheyi-forum

[16] Supertab:What AI Means for AI Startups and Application Builders。https://www.supertab.co/blog/what-ai-means-for-ai-startups-and-application-builders

善用“古法 AI”,能帮你省下很多 Token

2026-07-17 09:54:23

AI 之后,个性化信息系统突然泛滥了。

日报、舆情监控、行业雷达、选题助手、知识推送——名字不同,后台却经常长得一模一样:先抓一堆原始文章,再把每篇文章塞进大语言模型,问它「这篇和我的主题相关吗?」

这很自然。大语言模型看起来会读、会判断,而我又需要一个人替我筛信息,那就让模型把文章读一遍。过去是实习生坐在电脑前逐条判断,现在把实习生换成 API 就行了。

问题是,实习生是固定工资,但 LLM 不是。

假设每天有 500 篇文章,我只关心「科技向善」一个主题。最朴素的实现是发 500 次请求,让 LLM 逐篇判断。这可能还在可接受范围内。

但如果我同时关心科技向善、智能硬件、新消费、县城经济和科技伦理五个主题呢?在不合并分类请求的情况下,500 篇文章乘以 5 个主题,就是 2500 次判断。

这不是严格意义上的「指数增长」,只是文章数与主题数相乘,复杂度变成 O(N×M)。但账单不会因为术语更准确就少一点。文章越多,主题越多,钱和时间一起往里填。

当然,你可以把五个问题合并成一次请求:附上原文,再要求模型返回一个 JSON,分别判断五个主题。请求次数回到了 500 次,但输入没有消失。原文越长、主题边界越复杂、输出字段越多,模型越容易漏判、串题,或者给出一个格式正确、内容却经不起检查的答案。

很多所谓 AI 信息系统,并没有解决信息筛选问题。它们只是把人工阅读的成本,改写成了模型调用的成本。

但我想到一个问题:今日头条早在 2012 年 8 月就上线了。此后十几年,我们又在支付宝、滴滴、浏览器和无数与资讯八竿子打不着的 App 里刷到了个性化信息流。

那个没有 LLM 的时代,到底是怎么做推荐的?

这个问题先按下,文章最后再回来。

你需要的可能不是「理解」,只是「距离」

先回到最简单的任务:每天从 500 篇 RSS 文章里,捞出和几个固定主题相关的内容。

LLM 会把它理解成一个阅读理解题:读文章、读规则、推理、输出结论。

但它其实也可以被改写成一道几何题:

这篇文章,离「科技向善」这个主题有多近?

Embedding 正好适合做这件事。

Embedding 模型会把一段文本转换成一串固定长度的数字,也就是一个向量。你可以把它想象成一台「语义坐标转换器」:文章进去,出来的是它在语义空间中的坐标。

很多人第一次认识 Embedding,是在 RAG 里看它负责召回。这一代应用开发者大多从 LLM 时代进入 AI,起点又在应用层,很容易把 Embedding 当成 RAG 的固定配件:离开知识库问答,就想不起它还能干什么。

其实只要一个任务可以改写成「比较两段东西有多像」,Embedding 就能在许多场景单独派上用场。

在向量视角下,「OpenAI 发布新的模型路由能力」和「Anthropic 更新企业 API」这两句话的距离会比较近,「某地暴雨导致航班延误」这句话则会与前两句相差十万八千里。向量里的某一个数字通常没有可读含义,但两个向量之间的距离有意义。

做法不复杂:

  1. 把文章变成向量;
  2. 把主题描述也变成向量;
  3. 计算两者的余弦相似度,超过阈值就算命中。

余弦相似度关心的是两个向量的方向是否接近。工程里常写成:

cosine_similarity(A, B) = dot(A, B) / (norm(A) * norm(B))

如果向量预先做了 L2 归一化,后面的余弦相似度甚至可以简化成一次点积。

Embedding 本身不是分类器。真正的分类器,是「Embedding + 主题锚点(范文) + 相似度 + 阈值」这四样东西拼起来的结果。

我为 FreshRSS 做的低成本分类插件 FreshRSS-AutoLabel,就是这个最基础的版本。

用户先为每个主题准备几段范文,也就是「这个主题下的典型文章会写什么」。系统把新进入 FreshRSS 的标题、Feed、作者和截断后的正文拼成一段文本,为它生成一次 Embedding,然后与每个主题的范文向量比较。最高相似度超过阈值,就自动打上对应标签。

省钱靠两件事:

首先,范文很稳定。20 个主题,每个主题 3 条范文,第一次算完 60 个向量后就可以缓存。模型、Instruction 和范文文本没变,就不用重算。

第二,文章向量也能复用。一篇文章面对 20 个主题,不是生成 20 次向量,而是生成 1 次,再在本地(不调用 API)和 60 个范文做点积。

于是成本模型从:

文章数 × 主题数 × LLM 判断

变成了:

文章数 × Embedding
+范文首次向量化
+ 本地点积

500 篇文章、20 个主题、每个主题 3 条范文,第一次大约是 500 次文章 Embedding 加 60 次范文Embedding。此后只要范文不变,每天主要就是新增文章的 500 次 Embedding,而不是 10000 次 LLM 分类。

如果使用本地的 0.6B Embedding 模型,API 账单可以归零。真正的成本只剩本机的 CPU/GPU 时间和电费。

Embedding 与 LLM,不是大小模型之争

它们根本不是同一类工具。

维度 Embedding 分类 LLM 分类
核心任务 计算语义距离 阅读、推理并生成结论
输出 固定长度向量 文本或 JSON
多主题成本 文章向量可复用,主题向量可缓存 主题越多,Prompt 与判断负担越重
稳定性 相同模型和输入下结果稳定 受 Prompt、采样和模型版本影响
延迟 编码后直接返回,适合批处理 需要逐 Token 解码
可解释性 可以看到相似度、最佳范文和阈值 可以生成解释,但也可能事后合理化
擅长 主题匹配、召回、粗筛、聚类 复杂规则、跨文档推理、摘要与改写
本地部署 小模型即可,资源要求较低 通常需要更大模型和更多资源
日常边际成本 运行时接近 0 每次判断都继续消耗 Token

标题虽然写着「不需要 LLM」,复杂规则和生成任务还是要用它。比如「提到了 AI,但不是投融资新闻,也不是产品发布,还得包含可复现代码」,一个相似度阈值多半不够。把多篇材料压成一段有观点的综述,Embedding 更写不出来。

但只判断「像不像」时,没必要调用一个会推理、会写作、会解释的大语言模型。很多 Harness 的浪费,不是模型太贵,是模型摆错了位置。

用户只给一个主题名,范文从哪里来?

上面的 FreshRSS-AutoLabel 有一个前提:用户愿意认真写范文。

现实里,大多数人只会输入四个字:「科技向善」。

这四个字太短了。它可能指无障碍技术、数字普惠、未成年人保护、医疗 AI,也可能只是企业公益稿。直接拿它去做 Embedding,主题边界会很模糊。

我维护的另一套企业内个性化舆情日报系统,面对的就是这个问题:多名用户分别订阅多个主题,系统每天从数百篇文章里挑出与各自主题相关的写作线索。

这里仍然需要 LLM,但只在用户首次订阅主题时用一次。

用户输入主题名和一句可选描述后,LLM 会生成 3—5 条正向范文,以及 2—3 条负向范文。

正向范文回答「什么样的文章应该被选中」;负向范文回答「什么东西看起来很像,但应该排除」。随后,这些范文被 Embedding 并存进数据库。从第二天开始,主题标准已经固化成一组向量,不再需要 LLM 逐篇判断。

我后来把 LLM 留在了这里:

让 LLM 定义标准,而不是每天执行标准。

定义主题是低频工作,需要语言能力;执行匹配每天重复,更适合矩阵运算。把两者拆开,LLM 就不用在流水线上逐篇审稿了。

这套系统对每篇素材只生成一次 Embedding,并缓存到 PostgreSQL + pgvector。每天的主题匹配,主要是素材矩阵与范文矩阵相乘:取素材与所有正向范文的最大余弦相似度,再经过负向关键词硬过滤、Top-K 和最低分阈值。

有意思的是,实测中负向范文不一定适合直接参与减分。原本看起来更「智能」的 正向相似度 - 负向相似度,反而可能搅乱已经很干净的正向排序。因此,日常主分只取 max(正向相似度),对「融资」「股价」「IPO」这类稳定噪声,直接用字符串关键词做硬过滤。

能用一行 if 关键词 in 文本 解决的问题,就不要召唤一块显卡。

聚类与去重,也不必找 LLM 开会

筛出相关文章后,还有两个麻烦:

  • 十家媒体可能都在报道同一件事;
  • 同一条新闻可能连续三天换着标题出现。

照前面的路子,当然可以再把文章交给 LLM 分组、判重。但对新闻标题来说,一个上世纪的字符串算法往往就够了:n-gram。

n-gram 会把文本切成所有长度为 n 的连续片段。比如「腾讯发布混元大模型」的 2-gram 包括「腾讯」「讯发」「发布」「布混」「混元」「元大」「大模」「模型」。再加上 3-gram 和 4-gram,就得到一组可以直接比较的字符片段。

我使用字符级 2—4 gram,而不是中文分词。原因很简单:它不需要词典,不会被分词错误拖累,中英文混排也能直接处理。AI HarnessDeepSeek 和中文标题放在一起,并不妨碍它工作。

两段文本的相似度使用 Overlap Coefficient:

overlap(A, B) = |A ∩ B| / min(|A|, |B|)

分母取较小集合,而不是像 Jaccard 那样取并集。新闻标题经常一长一短:「腾讯发布混元」和「腾讯正式发布混元大模型并开放 API」明显是同一件事。如果用并集做分母,长标题新增的大量片段会稀释相似度;Overlap Coefficient 更关心「短标题有多少被长标题覆盖」。

在企业舆情日报里,事件聚类先用 Embedding 找到语义相近的候选,再用 n-gram 做二次确认。向量负责召回,n-gram 负责把「都在谈 AI、但并不是同一件事」的文章拆开。满足条件的文章通过并查集合并成事件簇。

跨天去重则更直接:只在同一主题内,把今天的标题与过去三天已保留的标题和摘要首句比较。高于阈值就标记为重复。它是纯字符串集合运算,成本接近零,而且每一步都可以复现。

最后才轮到 LLM:把筛选、聚类、去重后剩下的少数事件簇,写成 200—320 字的线索综述。

原来要读 500 篇的模型,现在只处理十几个小簇。LLM 负责最后一公里,不再蹲在入口做全量安检。

如果用户连主题都不填呢?

固定主题日报再往前一步,会遇到更难的问题:用户不想维护主题。

这正是我做邸报时面对的场景。

邸报是一套自托管的个性化 RSS 阅读引擎。用户只需要正常阅读、收藏、稍后读、点赞、隐藏和标记不感兴趣。系统不要求用户先写「我关心 AI Infra、中日经济对比、消费电子和县城经济」。主题会从行为里自己长出来。

我没有再让 LLM 总结一份用户画像,而是在本地维护多个动态兴趣簇。

当用户收藏一篇文章时,系统取得这篇文章已有的 Embedding,和现有正向兴趣簇比较:足够相近,就用加权方式更新这个簇的中心;不够相近,而且行为信号足够强,就创建一个新簇。

new_centroid = normalize(
  old_centroid × (1 - learning_rate)
  + article_vector × learning_rate
)

为什么不是把所有喜欢的文章平均成一个「用户向量」?

因为一个人可能同时关心 AI Infra、中日经济对比、消费电子、宏观经济和本地生活。把它们平均起来,只会得到一个谁也不像的中间点。多个兴趣簇,才允许一个人同时拥有互不相干的兴趣。

正向和负向也要分开。喜欢 AI,不等于喜欢每一种 AI 新闻;对某类融资稿点了「不感兴趣」,不应该把整个 AI 兴趣一起拉低。因此邸报分别维护正向簇与负向簇,负向更新和合并更加保守。

行为也不能一视同仁。收藏、点赞、读完是强信号;打开和读到 25% 只是弱信号;快速退出主要影响短期惩罚,不应该立刻创造一个永久兴趣。否则用户只要误点一次,画像就会被带跑。

兴趣还会衰减、合并和裁剪。最近三天突然关注的发布会,可以进入一个半衰期约 18 小时的短期意图向量;长期没有证据的兴趣簇会变弱;非常相近的簇会合并;低权重的单样本簇会被删除。

所谓「无限主题」,不是在 Prompt 里塞进无限个主题,而是让主题成为会生长、会衰减的本地数据结构。

Embedding 只是地图,不是推荐系统

做到这里,还不能直接按相似度从高到低发日报。

Embedding 对语义很敏感,却可能错过公司名、人名、缩写、代码名和刚刚出现的新词。因此邸报还使用 SQLite FTS5 与 BM25,从用户有行为的文章里提取长期和短期关键词画像,补一条精确词项召回通道。

FTS5 是 SQLite 自带的全文搜索模块。它会按照配置的 tokenizer 把标题、摘要和正文拆成词项,建立一份倒排索引:某个词出现在哪些文章、出现过几次、位于哪个字段,都可以提前记下来。查询时不必逐篇扫描全文,直接从索引里找出包含目标词的文章。

BM25 负责给这些文章排序。一个词在某篇文章里出现得越多、在整个文章库里越少见,通常得分越高;同时它还会修正文档长度,避免长文单纯靠词多占便宜。邸报还给标题、摘要和正文设置了不同权重,所以「DeepSeek」出现在标题里,会比埋在正文末尾更值得关注。Embedding 负责找语义上相近的内容,FTS5 和 BM25 则把专名、缩写与新词捞回来。

候选文章来自多个桶:最近文章、与兴趣簇相似的文章、命中关键词的文章、收藏或稍后读的文章,以及用于增加来源多样性的文章。把这些候选合并后,才进入混合打分:

推荐分 =
  语义相似度
  + BM25 关键词分
  + 新鲜度
  + 来源偏好
  + 文章状态
  - 负向兴趣惩罚
  - 重复惩罚
  - 过度曝光惩罚

新文章还没有 Embedding 时,会得到一个临时保护分,避免它因为后台任务尚未完成就永远沉底。

初步排序后,还要做一次类似 MMR 的多样性重排。同一来源、同一重复组、同一兴趣家族在前排出现太多,后续文章就会被压下去。用户想要的不是「最像自己兴趣的 20 篇同质文章」,而是一份有覆盖面、有密度的日报。

MMR 是 Maximal Marginal Relevance,通常译作「最大边际相关性」。它不是一次性把文章按分数排完,而是一篇一篇往结果集里放:每轮既看候选文章本身有多相关,也看它和已经选中的文章有多重复。可以粗略写成:

MMR 分数 = λ × 相关性 - (1 - λ) × 与已选内容的重复度

λ 越高,排序越贴合原始相关性;越低,系统越愿意牺牲一点分数来换取更多主题和来源。邸报没有只比较文章文本,还把同一来源、同一重复组和同一兴趣家族都算进惩罚里。这样第二十篇「同样很相关」的 AI 新闻,会让位给一篇分数稍低、但能补上其他主题的文章。

邸报甚至有一个谨慎的本地 FTRL 模型,用用户的行为去轻量校准语义、关键词、来源、新鲜度等特征的权重。但它先在 Shadow 模式训练,样本不足时不影响排序;真正启用后,占最终分数的比例也受到上限保护。

FTRL 是 Follow-The-Regularized-Leader 的缩写,是一种适合在线学习的轻量算法。它不需要定期拿全部历史数据重新训练,而是每收到一次新反馈,就小幅更新一次特征权重。用户收藏或读完一篇文章,可以算正反馈;快速退出、隐藏或标记「不感兴趣」,则算负反馈。跑久以后,模型会逐渐学到这个用户更看重语义匹配、关键词、来源还是新鲜度。

它不是另起一套推荐系统,而是在原有规则分上做校准。邸报先让 FTRL 在 Shadow 模式里旁观:照常训练和预测,但结果不进入正式排序。高质量样本积累到一定数量后才允许启用,而且只以很小的比例混入最终分数。这样既能利用个人行为调整权重,也不至于因为早期几次误点就把整个日报带偏。

Embedding 不是推荐系统,它只是地图。

用户的每次行为都在移动地图上的兴趣中心。排序器再拿着这张地图,在兴趣、新鲜度、来源、重复、探索和负反馈之间算账。

推荐理由也不必让 LLM 现编。系统把各项分数和证据保存下来,就能告诉用户:这篇文章命中了哪个兴趣簇、哪些关键词、哪个高权重来源,又因为哪些重复或负向信号被降权。这种解释来自真实计算过程,而不是模型看完结果后的合理化作文。

真正省 Token 的方法,是让模型退出主循环

三套系统的差别,其实是用户给系统的东西越来越少。

FreshRSS-AutoLabel 里,用户自己写范文,文章只需 Embedding 一次,再与所有固定主题匹配。

企业内个性化舆情日报里,用户只给主题名。LLM 在订阅时生成主题范文;日常筛选、排序、聚类和去重交给 Embedding、关键词与 n-gram,最后再让 LLM 写线索综述。

到了邸报,用户连主题也不用给。收藏、读完、点赞、隐藏和「不感兴趣」会慢慢长成正负兴趣簇,再与 BM25、新鲜度、来源、多样性和本地轻量学习一起完成排序。

小模型没有胜过大模型。成本是靠架构省下来的:该用 LLM 时用,不该用时让它退出。

最后,把开头的扣子解开

开头拿今日头条做了引子,但我不得不说,这是个写作技巧,因为它和本文的三套系统其实对不上。

大规模、多用户推荐系统通常不靠「文章与几个主题范文的相似度」吃饭。

主力是协同过滤算法,以及后来长出来的整套召回和排序体系。协同过滤算法其实大家反而更熟悉一些,就是前些年很多自媒体都科普过的:与你行为相近的人喜欢什么,系统就更可能把什么推荐给你。它吃的是 用户-物品 之间的大规模行为关系,不只是文章内容。

本文讲的内容匹配、向量相似度、关键词检索、聚类、去重和多样性重排,更像上一代推荐系统里的边角技术:它们用于冷启动、内容召回、特征补足、重复控制和排序校正,而不是单独扛起一个今日头条。

可个人日报恰好没有平台的条件。

你没有数亿用户,没有足够密集的 用户—文章行为 矩阵,也不需要预测陌生人下一秒会不会继续滑动。你只有一个人或一小群人的订阅源、几百篇文章,以及一个更朴素的目标:把真正值得看的东西先捞出来。

在这个尺度上,推荐系统的「边角技术」已经够用了。

对从 LLM 时代才进入算法与工程世界的 Vibe Coding 一代来说,这些旧技术值得补课。Embedding、余弦相似度、BM25、n-gram、SimHash、兴趣簇、MMR、FTRL,不如大模型性感,但便宜、稳定,出了问题也知道该从哪里查。

做 Harness 时,我现在会先问一句:这一步的“智能”真的需要 AI 吗?毕竟“智能”这个词早在这一轮 LLM 爆发之前,就已经出现在几乎各类软件和家用电器里了,也许我所需要的根本不是一个 AI 级别的智能。

如此这般,省了很多 Token。

当然,如果你看不懂本文,也可以直接把本文发给你的 Vibe Coding Agent 说:我不想接 LLM 了,你看看这个方案行不行。

最后的最后

最后的最后,给我的 Fiar-Code 项目邸报做一个广告。这是一个个人版的“头条”,它实现的效果是:首先做一个 RSS 阅读器,然后在你的订阅范围内,依据你的阅读行为进行个性化排序。

它适用于你有很多 RSS 订阅,每天 Inbox 里有 400 篇以上的文章入账,不可能把所有内容看完,但又想有个算法帮你快速筛选出你关心的内容,并且不想给 LLM 模型交大额账单。

同时,它是免费、自部署、代码可审计、数据不出站的,可以满足你的隐私需求,不用担心你的行为数据被大平台拿走当广告。

最重要的是,正如本文介绍的,它只需要一个 0.6B Embedding 模型驱动,你甚至可以在本地使用 Ollama 驱动(Macbook 连风扇都不转),不依赖任何第三方 API,真正实现 0 账单智能。

官网是:https://dibao.app

欢迎自取。

这个项目因为我现在每天都在高频自用,因此会在长时间保持维护。

为什么说 Anthropic 是邪恶的?

2026-07-01 13:59:02

如果你重度依赖海外 AI 工具,又恰好生活在中国,你大概早就习惯了”赛博二等公民”的待遇。

你得找干净的节点,得注册海外的信用卡,得时刻担心那个好不容易养起来的账号,会不会在某次风控里被”连坐”封掉。

但 Anthropic 这次干的事,还是超出了我的想象。

2026 年 6 月 30 日,Reddit 的 r/ClaudeCode 板块。一个用户发帖,标题简单粗暴:Claude Code 在给你贴标签。

发帖人 LegitMichel777 说,自 Claude Code v2.1.91 版本起,只要把它接到代理服务器(proxy),并且系统判定你“跟中国有关”,它就会在每一次请求里,悄悄改写你打出的标点。[1]

具体到什么程度?开发者 thereallo 把客户端代码拆开,逆向了一遍:日期里的短横“-”被换成斜杠“/”;句子里最普通不过的一个撇号“’”,被替换成几个人眼几乎分不出来的 Unicode 变体字符。[2]

这条帖子冲上了 Hacker News 首页,拿了 605 分。评论区当场吵翻。

我第一反应真的是想笑。一家把“安全”刻在招牌上的公司,一家标榜自己是全宇宙最在乎人类命运的 AI 实验室,煞费苦心地在文本里埋了一个隐形指纹,专门用来标记“这个人可能跟中国有关”——结果被一个极其无聊的、专门针对标点符号的怪癖当场抓包。

但笑完,是真的不舒服,甚至感到一种生理性的恶心。因为比起光明正大地写明”禁止中国相关实体使用”,Anthropic 选择了明知故犯地隐瞒。

在历史上,很多组织都干过类似的事情,而与 Anthropic 最相似的是纳粹——给犹太人的护照盖一个“J”字,并告诉他们:这只是个符号,没什么大不了的。

这篇文章不打算讲隐私,隐私在这个语境下显得太小儿科了。因为 Anthropic 干的这件事比隐私深沉得多——它不是在收你的数据,它是在定义你的身份。

这是一个从“你是谁”出发、而不是从“你做了什么”出发的判断系统。

1. 用撇号传递信息

为了后续的讨论,我们需要先复述一遍 LegitMichel777 讲述的技术细节,如果你已经了解了,可以跳过接下来的几段。

Claude Code 的歧视代码触发条件非常具体,具体到你能看见写下这行代码的人那张充满算计的脸:环境变量 ANTHROPIC_BASE_URL 被设置,说明请求经过了代理;系统时区落在 Asia/ShanghaiAsia/Urumqi

命中之后,Claude Code 会做两件事:把请求里的日期格式从 2026-06-30 强行改写成 2026/06/30;把普通的撇号 ' 换成 Unicode 变体——命中域名黑名单换成 \u2019,命中“中国实验室关键词”换成 \u02BC,两条都中,换成 \u02B9。[2]

这几个字符,肉眼几乎看不出差别。放进任何一个普通的文本编辑器,你会以为这就是标准的英文右单引号。它们的差别只存在于字节层面,只有会读 Unicode 编码表的人、或者是接收这些数据的 Anthropic 服务器,才看得出来。

这还不够,域名黑名单和关键词列表怎么藏?他们先用 base64 编码,再用密钥 91 做一次 XOR 混淆。解出来的关键词,是 deepseek、moonshot、minimax、zhipu、baichuan、stepfun、01ai、dashscope——挨个数下来,几乎把中文互联网能打得上号的大模型公司,点了一遍名。[2]

这道工序绝不是什么“顺手写的一行判断”,也不可能是 Anthropic 的实习生手滑。它是一个系统工程:先写一份名单,再把名单编码,再把编码结果做加密混淆,再把混淆结果嵌进产品里,让它在你完全不知情的情况下运行。

这里面的每一步都是深思熟虑的决定,每一步都要有人经过代码审查。

这就是我不能用“偏见”而一定要用“歧视”来概括这次 Anthropic 的行为。因为算法偏见可能来自数据中的无意识样本偏差,但歧视代表着主动决策。

但 Claude Code 里所做的行为,恰恰是有主语和主观能动性的。

有人写了一个 if 判断你是谁。有人选了要屏蔽的公司名单。有人决定把这份名单藏起来,而不是写进用户协议第几条。有人测过,这套水印在正常使用中不会被肉眼发现。这每一个“有人”都是真实存在的职务角色:提出这个 feature 的产品经理、批准它的 tech lead、在 Code Review 里点了 Approve 的那个同事、把这个版本推上生产线的 release manager。

我知道科技圈不爱听“共犯”这个词,但它就是共犯。

你可以说,Claude Code 目前干的事,无非是往请求里塞一个隐形水印,又没打你、没抓你、没冻结你账户。这话没错。可翻开历史看看,每一次大规模的排斥,最初都只是“先记一下”。至于名册建好之后会发生什么,从来不是写名册的人自己决定的——写名册的人,只是把决定权提前让渡给了未来某个使用这份名册的人、或者某项疯狂的政策。

我甚至可以想象 Anthropic 内部的动机逻辑。他们大概觉得自己在执行某种正当的商业防御:这些中国 AI 公司确实在“非正常竞争”,确实在“蒸馏”他们的模型,所以标记一下、收集一点数据、留一条后路,是合情合理的应对。

但问题是,大模型本身是一种在使用方法上对后端全透明的技术,也就是从理论上来讲,Anthropic 可以通过行为识别来解决所有“不符合规定的使用”,而不是圈定一个“不符合规定的人群”。

而采用隐蔽的方法来传递用户身份的侦测,更说明了 Anthropic 自知这样的划分并不名正言顺。因为如果它真的认为自己正当、正确、正义,可以参照 Stripe,以及全球任意一家互联网金融公司那样通过有效证件对用户进行真正的 KYC。而不是偷偷识别“这个可能是中国人”,再偷偷传回总部。

直到今天,Anthropic 依然没有对这次指控做出公开回应。沉默,就是最傲慢的态度。

我猜他们不是不想回应,是没法回应。解释为什么埋水印,等于承认埋了水印;解释为谁埋的、用什么标准判定”跟中国有关”,等于把一份歧视清单摊在桌面上给全世界看。不回应,至少还能躲在”不予置评”后面假装这件事不存在。

但这件事不会因为他们不回应就消失。代码已经被反编译,XOR 密钥已经公开,域名列表已经摊在 GitHub 上被全世界传阅。Anthropic 的沉默不是危机的结束,只是他们还没有想好一个不那么难看的说法。

2. 定义即暴力:从颅骨到时区

暴力这个词,在现代人的语境里,太容易让人先想到枪、集中营、毒气室。但研究种族灭绝的历史学界早有共识:真正决定谁会被杀的那一步,往往发生在很多年前,一张纸上,一次毫无波澜的登记里。

1935 年,纳粹德国颁布《纽伦堡法案》(Nuremberg Laws)。这部法案做的第一件事,不是抓人,是重新定义”谁是犹太人”。以前,这个身份多少带点宗教和文化认同的意味——你有犹太信仰你就是犹太人,你改宗了你就可以不是。法案之后,身份变成了纯粹的血统算术:查你祖父母四人里有几个是犹太人,划进”犹太人”或”米施林格”(Mischlinge,混血)的不同等级,再细分出四分之一、二分之一血统的类别。[3]

这套分级表在实际执行中演化出了一种荒谬:一个人可能一辈子没进过犹太教堂、吃猪肉喝啤酒、甚至已经受洗成为基督徒——但只要档案里写着你有一位犹太祖父母,你就是法律意义上的犹太人。同样,一个虔诚的犹太拉比如果祖父母四人凑巧只有三个是被归为犹太血统的,他反而被分进”一级混血”,可以暂时保住工作和财产。宗教、文化、自我认同,在这张表面前全部作废。唯一的真实,是血统档案上的那四个格子。

这套分级表画出来像一份遗传学作业。极其精确,极其官僚,极其冷。它冷的地方在于:一旦你被归进某一格,能不能上学、能不能行医、能不能结婚、能不能保有财产,全部按格子走,不需要再看你这个人到底是谁。你的灵魂不再重要,你的成分决定了一切。

护照上盖一个“J”字,是这套分级表最后、最可见的产物。真正干活的,是前面那张分级表。盖章的公务员,只是在执行一份早就做完的分类。

但分类要落到几百万人头上,光靠人手写名册是不够的。这时候,一家美国科技巨头帮上了忙:IBM。

IBM 通过德国子公司 Dehomag,向纳粹政府提供了 Hollerith 打孔卡制表系统。1933 年的人口普查用的就是这套系统——不只是数人头,而是能按“种族”“宗教”“职业”这些维度交叉检索。历史学者 Edwin Black 在《IBM 与大屠杀》里详尽地还原过这条链路:普查数据摸清了犹太人口的分布,隔都居民被逐一统计。到了集中营,囚犯的复杂人生被压缩成一串五位数编号,刻在袖标上,用打孔卡系统追踪调配劳动力。[4]

分类系统先于灭绝到位,灭绝才谈得上被“流水线化”。没有硅谷先驱的前代技术,那套暴力系统根本跑不出那么高的效率。

Edwin Black 在书里记录了一个细节,任何人看l都会不寒而栗:IBM 不仅卖了机器,还派了工程师去德国维护这些机器,定期检修,确保打孔卡系统运转良好。换句话说,IBM 从头到尾知道自己的客户在拿这些机器干什么。但他们没有停下来。因为生意就是生意。

集中营内部还有一整套色标系统——三角形的颜色和位置,标记你是政治犯、犹太人,还是“反社会分子”。管理者一眼就能分辨,囚犯却常常读不懂自己身上贴的是什么。[5]

这才是最关键的一点:标记的可读性是不对称的。写标记的人看得懂,被标记的人看不懂。

把这套逻辑,原封不动地摆到 Claude Code 旁边对照一遍。

Claude Code 会检测你的时区是不是 Asia/Shanghai,跟纽伦堡式的“居住地/血统普查”是同一个动作,只是普查对象从“你祖上是哪个民族”,换成了“你的系统时钟设在哪儿”。撇号被换成一个 Unicode 变体,跟集中营里那个只有管理者看得懂的色标三角形,也是同一个动作,只是载体从衣服上的布料换成了网络传输的字节。

一个是墨水戳在纸上,一个是零宽度级别的字形替换。技术上,二者相差了大概九十年的载体演进。逻辑上,它们是同一件事:先给你建一份档,再决定拿这份档怎么用——而你,作为被标记的对象,全程不知道自己已经被记录在案。

我知道有人到这里会觉得我危言耸听:一个破撇号而已,至于类比到纳粹和集中营吗?至于。

因为我不是在类比暴力程度,我是在类比制度设计。纳粹的色标系统不需要集中营的焚化炉才能成立——它本身就是一个独立的、完整的、自洽的分类装置。

即使没有后来的大规模屠杀,这套色标系统本身也已经构成了一种暴力。因为它剥夺了被标记者对自己身份的叙事权。Anthropic 的水印也一样。你不需要等到某天 Anthropic 拿着这份数据库向政府交名单,才能说这件事是错的。它在你不知情的情况下替你完成了一次分类、并把这个分类永久记录在你的请求流里——光是这个动作本身,就已经越过了底线。

这里可以再摆一组对比,会更扎眼一点:德国用血统证明“纯洁”,美国用肤色证明“纯洁”,Anthropic 用时区和域名证明“安全”。三套系统操心的东西,表面上完全不同——种族、肤色、地缘政治——底下用的,却他妈是同一套官僚工具箱:先划出一个“他者”的范畴,再给这个范畴配一套可执行的判定规则,最后让规则自动运行,运行到不需要任何人再做一次良心上的判断。

这才是分类系统真正恐怖的地方。它不需要执行者恨你,它只需要执行者照着产品经理的表格填字段。

Anthropic 的工程师大概没有一个人怀着种族仇恨写下那个 if 判断。这恰恰是问题所在——作恶不再需要恨意做燃料,只需要一份需求文档,和一个愿意按需求文档写代码、并且放弃追问的打工人。

3. 一滴血与一个域名

如果说纳粹的分类学野蛮而张扬,那么美国的种族隔离制度则完美示范了另一种可能:野蛮可以完全不需要张扬,甚至可以包装成一套行政流程。

“一滴血规则”(one-drop rule),字面意思就是它的定义:只要一个人的血统里有“一滴”黑人血统——哪怕祖上八代只有一位——法律上就该被归为黑人。这不是一句民间俗语,这是美国多个州曾经白纸黑字写进法律的正式规则,学术上叫 hypodescent(血统从劣原则)。[6]

这条规则最诡异的地方,不在于它显而易见的歧视,在于它把“你是谁”这件事,完全交给了行政官员手里的那支笔。弗吉尼亚州有一位名叫 Walter Plecker 的登记官,靠着一部《种族纯洁法案》(Racial Integrity Act),可以单方面把整个混血家族,重新划进“黑人”的档案。这家人可能几代都被当作白人生活,但 Plecker 一份文件,身份就被强行改写了。没有法庭,没有申诉,一份表格就是终审判决。[7]

定义权,就是暴力权。你不需要在街上打人,只需要有权决定“这个人是什么成分”,剩下的暴力,会由整套社会的齿轮自动执行。

隔离制度另一件招牌产品,是“红线区”(redlining)。1930 年代,美国联邦机构 HOLC(房屋所有者贷款公司)给全国主要城市画风险评级地图,用红笔圈出“危险”街区——住着少数族裔的社区,几乎毫无悬念地全被圈进红区。银行照着这份地图放贷,红区居民几十年贷不到房贷,财富积累从地理层面被物理锁死。

这份地图不是公开羞辱,它甚至不需要挂在任何一户人家门口。它躺在银行和政府机构的档案柜里,安静地决定着一整代人能不能买房、能不能积累资产、能不能把房子留给下一代。你从街上走过,看不出这条街被画了红线,你只会发现,自己去申请贷款,总是莫名其妙地被拒。

在这条规则运行的三十年间里,整整一代美国黑人家庭被锁在财富积累的门外,而他们身边的白人邻居用同样的收入水平、同样的还款能力,拿到了贷款、买了房、把房子升值后的财富传给下一代。

今天美国白人和黑人之间的财富差距,有相当一部分可以直接追溯到这几张地图——它们在被废止几十年之后,依然像幽灵一样影响着下一代人的资产负债表。这就是隐蔽分类的真正威力:它的伤害不发生在被标记的那一刻,而是发生在被标记之后每一个看似中立的“正常流程”里。银行从来没有在你的贷款申请表上写“黑人”两个字,它只是查了一下你的地址,然后查了一下那张地图,然后把你的申请表放进“不批准”那摞文件里。

饮水机上那块写着“Colored”的牌子,公开、羞辱、刺目,是隔离制度最容易被记住的画面。但红线地图告诉我们一个更冷的事实:真正决定命运的排斥,往往不需要一块牌子。它藏在流程里,藏在评级表里,藏在一份没人会主动给你看的档案里。

这正是我看到 Anthropic 那份 XOR 混淆域名黑名单时,最先想到的画面。

base64 编码,加一次密钥为 91 的 XOR 混淆——这道工序,在功能上和红线地图一模一样:把一份“谁该被特殊对待”的名单,从公开可见,改造成隐蔽可执行。它不写进用户协议,不出现在任何一份产品说明里,就躺在代码深处,安静地决定着你的请求会不会被悄悄改写。

从饮水机牌子到 Unicode 水印,人类文明进步的似乎只是隐蔽性:排斥的效率提高了,而排斥的可见度反而降到了零。

如果这一切还只停留在一个开源社区的技术八卦上,也许还能被归为“某家公司的产品设计争议”。但就在一个多月前,这套逻辑已经从代码层面,堂而皇之地升级成了国家行为。

2026 年 6 月 12 日,美国政府以国家安全为由,下令暂停任何外籍人士使用 Anthropic 的 Fable 5 和 Mythos 5 模型。注意官方声明那咬文嚼字的措辞——不论此人身在美国境内还是境外,连 Anthropic 自己的外籍员工,也一并被切断访问。[8]

这里要解释一下这条禁令背后的法律逻辑,因为它在中文世界几乎没有对应物:美国出口管制体系里有一个概念叫“视同出口”(deemed export)。意思是,把受管制的技术信息交给一个外国人——哪怕这个人此刻就坐在加州硅谷某间豪华办公室里,甚至持有美国合法工作签证——在法律上,等同于把这项技术直接出口到了他的母国。判定标准不是这个人身在哪里,不是他为哪家公司工作,不是数据中心设在哪个法域。判定标准只有一个:他生而为谁。

这条禁令切断的人里,甚至包括 Andrej Karpathy——一位在 AI 圈家喻户晓的研究者,持有 EB-1(美国“杰出人才”)绿卡,早已是美国永久居民。他没有做错任何具体的事,甚至为美国的 AI 产业立下过汗马功劳。但他被挡在门外的唯一理由,是他的出生地。

这不就是一滴血规则的 2026 年版本吗?只是评判标准从“血统比例”,换成了“国籍出身”。一旦被判定“不纯”,你身处帝国心脏、手握顶级人才绿卡,也无济于事。Anthropic 最终顺水推舟,选择在全球范围下线这两款产品,以完成所谓的合规。

这里得插一句话,避免被读成自打自脸。我自己之前写过一篇《AI 也该有护照了》 ,主张给 AI 系统一个透明、可问责的国籍标识。乍之一听,这两篇文章好像在自相矛盾:一篇在帮 AI 许国籍,一篇在质问国籍引发的差别待遇。

但它们其实是同一套逻辑的两面。“国籍”作为一项公开规则,本身没有问题:它写在法律里,写在签证表格上,你知道规则存在,也知道自己会被怎样对待——这是可以拿到桌面上争论、修正、申诉的秩序,一种“护照”式的秩序。

Anthropic 在 Claude Code 里做的事,性质完全不同:它没告诉你规则是什么,甚至没告诉你规则存在。你的时区、你连的域名,在暗处被换算成一个关于“你是谁”的判断,这个判断会不会影响你、以什么方式影响你,你无从知晓,也无从申诉。

如果用中国人近代经历过的创伤记忆来解释,Anthropic 更像是给人发了一张“良民证”,而不是在你的护照上签发了一张签证。良民证是占领当局发给被统治者的身份证明,用来证明你“暂时没问题”,发放和收回的权力,全部单方面握在统治者手里,随时可能因一条你看不见的规则被收走。

护照式的国籍秩序,问题可以拿到桌面上吼;良民证式的隐蔽分类,连吼的资格都不给你。

我知道肯定有人会跳出来洗地,说国家安全考量和种族隔离不是一回事,一个关乎技术管制,一个关乎种族仇恨,动机天差地别。这话我只同意一半。

动机确实不同——没有政客能在 2026 年的国会发言里直接喊“血统纯洁”这种话了。哪怕是现在全球政坛都在右转,这也是大逆不道的话语体系。

但一滴血规则和视同出口原则,用的是同一套底层判断逻辑:不问你做了什么,只问你生而为谁;不给你辩护的余地,因为你的身份本身就是原罪证据。

我们总以为隔离制度的恶,在于它公开、羞辱、刺目。但真正高效的排斥制度,从来不需要张扬。它悄悄发生,被排斥的人甚至察觉不到自己已经被归入了另一个格子,直到某一天,贷款被拒了,请求被悄悄改写了,或者账号被直接切断了——才后知后觉地发现,原来早就有一张表,把你放在了“需要处理”的名单里。

Anthropic 选的,正是这条最高效、也最恶心人的安静之路。

4. 以安全之名

Anthropic 这个名字,原本取自信息论之父克劳德·香农(Claude Shannon);“Anthropic”本身在英文里是“人本主义”的意思,疯狂暗示这家公司要做“以人为本”的 AI。招牌产品直接叫 Claude。这整套充满理想主义光环的品牌叙事,从起名字的那一刻起,就在声情并茂地向全世界布道:我们是最讲安全、最讲对齐、最在乎全人类福祉的那家 AI 实验室。

他们甚至提出过一套叫 Constitutional AI 的训练方法:给模型发一部“宪法”,让它按一套明确写下来的所谓普世价值观去自我约束、自我修正。CEO Dario Amodei 常年在公开场合像个传教士一样大谈“AI 安全”“对齐人类价值”“负责任的扩展”,几乎把这些大词直接焊在了公司的 Logo 旁边。

这套叙事讲了太多年,讲到大家耳朵都快起茧子了,讲到几乎没人会退一步追问一句最基本的问题:所谓的安全,到底是对谁的安全?

同一家公司,一边在官方博客上慷慨陈词“我们致力于让 AI 系统对齐全人类的价值观”,一边在客户端产品里埋了一段比木马还隐蔽的代码,专门用来给“跟中国有关”的用户悄悄换标点符号。

这还不是唯一的反差。今年早些时候,Anthropic 曾致信美国国会,极其高调地指控中国同行阿里巴巴通过不正当手段“蒸馏”窃取了自家模型的能力。 这件事本身就很有戏剧性——“蒸馏”是一个在 AI 行业被广泛使用的技术手段,开源社区每天都在互相蒸馏,Anthropic 自己创立之初也没少用公开数据集训练。但当“蒸馏”的对象变成了中国公司,这件事就立刻被升级为“盗窃国家机密”级别的指控,被直接写进了一封给国会的正式信函。

Anthropic 此前曾经多次发表报告指责中国官方和企业利用 Claude 进行一些违反美国法律或其使用协议的恶意行为。但成文法与种族歧视最大的区别就在于其不应以身份进行惩罚,而应以行为进行惩罚。

如果我们将 Anthropic 的行为替换到其他领域,这个逻辑就会非常清晰:我们发现某一地区罪犯中的有色人种比例偏高,因此我们认定有色人种全员是罪犯,对他们进行更加严格的限制和监视。

换句话说,它其实并不在意你是否真的违反了它的用户协议,或用 AI 做了哪些不该做的事情。你只要能证明你是真正的,持有美国护照的美国人,那么你即便是做了这些也不会被封号。

这一逻辑恐怕在任何意识形态的现代司法区都是不允许的,它触及了现代文明某些更底层的共识。

再加上前面那道针对全球所有外籍人士——哪怕是自家核心员工——的 Fable 5 封锁令。

三件事摆在一起看,这家公司的“对齐人类价值观”,显然是想要把一些人类从“人类”这个词的定义里排除。

历史上的纽伦堡法案,正式名称叫《保护德国血统与荣誉法》。种族隔离制度最常见的自我辩护,是“保护种族纯洁”和“维护社会秩序”。今天,在科技圈,站在同一个语法位置上的词,换成了“AI 安全”。

“安全”是目前为止,人类发明出来的最好用、最廉价的道德外衣。它在很多情境下确实是重要的,但在很多情境下又是最好用的借口。

它不需要你撕破脸皮说出“我讨厌某个特定群体”,你只需要皱起眉头说一句“这一切都是为了安全”,剩下的排斥、监控、区隔、封锁,都可以顺理成章、堂而皇之地推行下去,甚至还能在推特上收获一波掌声。

更重要的是,Anthropic 不是那种被政府管制逼着改产品的受害者。它是在主动鼓励、甚至抢先于政府介入地缘政治,拿这种看似自我约束的行为当商业竞争的筹码。这不是被迫合规,是明确的主动作恶。

对一个普通用户来说,这才是整个事件中最魔幻、也最无力的地方:你可能完全不关心中美博弈,你可能连政治新闻都不看,你只是半夜坐在电脑前想用个编程工具赶个 deadline。结果你的输入被悄悄标记、悄悄改写,仅仅因为你恰好用着中国时区,恰好连了一个被他们列进黑名单的域名。

地缘政治的碾压不再需要你主动参战,它会像个尽职尽责的机器一样,主动把你算作战场的一部分。

利益不相关声明:评论尸本人自 2022 年起从未订阅过 Claude 的官方付费套餐及第三方未授权的 Claude 中转站服务,本文也不是因个人账号被封禁而怀恨在心撰写的泄愤之作。

参考文献

[1] LegitMichel777,”Anthropic embedded spyware in Claude Code…”,Reddit r/ClaudeCode,2026-06-30。链接

[2] thereallo,”Claude Code Is Steganographically Marking Requests”。链接

[3] USHMM,”The Nuremberg Race Laws”。链接

[4] Wikipedia,”IBM and the Holocaust”。链接

[5] USHMM,”Classification System in Nazi Concentration Camps”。链接

[6] Wikipedia,”One-drop rule”。链接

[7] African American Registry,”The ‘One Drop Rule’ in America, a story”。链接

[8] Anthropic,”Statement on the US government directive to suspend access to Fable 5 and Mythos 5″,2026-06-12。链接

邸报 v0.1.0:一个很旧的东西新生了

2026-05-30 09:30:54

你好,

久等了,邸报刚刚上线了第一个可公开安装的版本。

版本 v0.1.0
项目 邸报 Dibao
协议 BUSL-1.1
Github github.com/Pls-1q43/Dibao

邸报是什么?

简单来说,邸报是一个 RSS 阅读器,它把算法推荐放回你自己的 RSS 信源里。

邸报可以跑在你的 NAS、VPS 或本地电脑上。导入 OPML,添加 RSS 地址,像用任何阅读器一样阅读、收藏、标记。区别在于,邸报从你的行为里学习,在你订阅的文章中重新排序——不扩大信息来源,只在你选定的池子里,把更值得先看的东西浮上来。

每篇推荐都有解释。不是黑盒分数,是可以追问的理由。

如果你的 RSS Inbox 里每天也会新增上百篇文章,那么你一定会喜欢邸报。

邸报是免费的,没有中心化服务,不绑定任何 LLM API。接一个免费的 embedding provider(比如硅基流动)或在本地跑一个 0.6B 的模型,邸报就能有非常出色的推荐效果。

数据在你的持久化目录里。SQLite,一个文件,备份就是复制粘贴。

我在日记里把它叫做“外部嗅觉器官”。不替你判断,只在信息流里把可能接上你脑子里那条暗线的东西,先叼到你面前。

为什么做这个?

LLM 火了以后,“AI 个性化阅读”成了一个热门叙事。几乎所有方案都在让大模型直接吞掉你的信息流——总结、筛选、判断,每一步烧 Token。

但推荐从来不是生成问题,是匹配问题。

今日头条从来没问过你喜欢什么,你只要用,它就越来越懂你。核心不是语言模型,是行为数据 + embedding + 排序。这条路 2013 年就验证过了,只是没人想过把它接回 RSS。

因为没人觉得 RSS 还值得救。

我也曾经不想救它。2015 年我和几个朋友做了「赤潮 AKASHIO」,第一篇推送叫《互联网死了 23%,这只是开始》。赌的是长图文、订阅、读者自己选择信息来源这件事还有意义。十一年过去,媒介从长图文迁到短视频,订阅迁到推荐系统,赤潮自己因为名字变成敏感词被迫改名「红流」。中文互联网的信息分发权,几乎全交给了平台算法。

你大概和我一样:厌倦了平台替你决定该看什么,但又不想退回手工 RSS 几百篇未读堆成墙的日子。信源归你管,排序帮你做,数据留在你手里。

邸报试图占住这个位置。

现在可以做什么?

v0.1.0 已经发布。你可以用 Docker Compose 一键部署,五分钟跑起来。

README 里有完整的 compose.yaml 和 provider 配置指南。

如果你觉得好用,或者觉得这个项目的正走在正确的方向上,可以到 Github 上给个 Star。邸报是 source-available 项目,Star 是让更多还在用 RSS、还愿意自己部署的人看到它的方式。

遇到问题、有想法、或者只是想说一声“跑起来了”,GitHub Issues 随时开。

RSS 阅读器流行于 2000 年,推荐算法被广泛应用于 2013 年,而邸报诞生于 2026 年,这完全归功于 Vibe Coding。

邸报的所有代码由 AI 生成,正如我之前在 X 说的:我在尝试用很新的东西,做一种很旧的东西。

希望你喜欢。

安装时如果遇到问题,可以直接回到 GitHub Issues 里开帖。

如何给 Notion AI 接入第三方 API?

2026-05-12 09:07:10

我之前讲过将「哈勃半径」作为一种私人信息宇宙,并将它接入 Notion AI。

但问题是,Notion AI 如果不使用 Custom Agents 似乎无法接入第三方 API,而 Custom Agents 有高昂的使用费,如何解决这个问题呢?

这里补一个更工程化的实用技巧:通过 Cloudflare Worker 将任意第三方 API 接入 Notion AI。

我用博查搜索,来讲解如何操作。

它的核心原理很简单:

  • 第三方 API 通常要求 POST 请求,并且需要在请求头里放 API Key。
  • Notion AI 当前更适合通过 webpage.load 读取一个 GET 可访问的网页。
  • Notion AI 的计算机工具可以做 SHA-256 之类的哈希计算。
  • 所以中间需要一个 Cloudflare Worker 网关:对 Notion AI 暴露一个带签名的 GET 页面,对第三方服务发起真正的 POST API 请求,再把结果渲染成 HTML。

换句话说,它不是让 Notion AI 直接调用第三方 API,而是给 Notion AI 搭一座「可阅读的桥」。

如果你觉得下面的内容读起来很麻烦,也可以将这个文章直接丢给你的 Notion AI,让它教你如何设置。

一、为什么需要 Worker 网关

很多 API 的调用方式是这样的:

POST <https://api.example.com/v1/search>
Authorization: Bearer API_KEY
Content-Type: application/json

{
  "query": "搜索词",
  "count": 5
}

但 Notion AI 更容易处理的是一个普通网页:

<https://your-worker.example.workers.dev/?query=搜索词&count=5&ts=时间戳&sign=签名>

Worker 做的事情,就是把后者翻译成前者。

Notion AI 访问的是一个 GET URL。Worker 收到 URL 参数,验证签名,把参数组装成 POST 请求,调用真正的第三方 API,最后把返回结果变成 HTML 页面。这样 Notion AI 不需要理解 API 的认证细节,也不需要使用 Post 方法来接触真正的第三方 API。

这实现了在不给 Notion 额外交钱(使用 Custom Agents)的情况下,使用默认版本的 Notion AI 来接入第三方 API。

二、最小可用架构

这个方案里有三个角色:

  1. Notion AI:负责理解用户意图、生成查询词、计算动态签名、读取网页结果。
  2. Cloudflare Worker:负责鉴权、参数转换、调用第三方 API、渲染 HTML。
  3. 第三方 API:负责真正提供搜索、数据库查询、模型推理或其他能力。

它的链路是:

用户问题
→ Notion AI 生成 query
→ 计算 ts + sign
→ webpage.load 访问 Worker 的 GET URL
→ Worker 验签
→ Worker 向第三方 API 发起 POST
→ Worker 把 JSON 渲染成 HTML
→ Notion AI 阅读页面并总结

这里最关键的一点是:API Key 不应该出现在 Prompt 里,也不应该出现在 Notion 页面里。它应该存放在 Cloudflare Worker 的环境变量中。

三、以博查搜索为例

博查 API 原本是一个搜索接口。我们希望 Notion AI 可以这样使用它:

搜索:2024 年诺贝尔物理学奖得主
返回:5 条结果
需要摘要:是

对应到 Worker 暴露出来的 URL,大概是:

<https://your-bocha-worker.example.workers.dev/?query=2024%E5%B9%B4%E8%AF%BA%E8%B4%9D%E5%B0%94%E7%89%A9%E7%90%86%E5%AD%A6%E5%A5%96%E5%BE%97%E4%B8%BB&summary=true&count=5&ts=1715000000&sign=计算出的哈希值>

其中:

  • query 是搜索词,必须 URL 编码。
  • summary 控制是否让博查返回长摘要。
  • count 控制返回条数。
  • freshness 可以限制时间范围,比如一天、一周、一个月、一年。
  • include 可以限制搜索域名。
  • exclude 可以排除搜索域名。
  • ts 是 10 位 Unix 时间戳。
  • signts + SECRET_KEY 的 SHA-256 哈希。

这个签名机制不是为了做到银行级安全,而是为了避免这个 Worker URL 被随便滥用。时间戳通常只允许几分钟内有效。

四、Worker 示例代码

你需要先在 Cloudflare Woker 上建立一个新的 Worker,然后填入以下代码:

// 辅助函数:计算 SHA-256 哈希值
async function generateSHA256(message) {
  const msgUint8 = new TextEncoder().encode(message);
  // 使用更严格的对象参数格式,避免部分 Worker 环境抛出 TypeError
  const hashBuffer = await crypto.subtle.digest({ name: 'SHA-256' }, msgUint8);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  return hashArray.map(b =&gt; b.toString(16).padStart(2, '0')).join('');
}

export default {
  async fetch(request, env, ctx) {
    // ==========================================
    // 0. 拦截并放行 OPTIONS 跨域预检请求
    // ==========================================
    if (request.method === "OPTIONS") {
      return new Response(null, {
        status: 204,
        headers: {
          "Access-Control-Allow-Origin": "*",
          "Access-Control-Allow-Methods": "GET, OPTIONS",
          "Access-Control-Allow-Headers": "*",
          "Access-Control-Max-Age": "86400",
        }
      });
    }

    // ==========================================
    // 全局错误捕获边界,把 1101 错误转为可见的 HTML 报错
    // ==========================================
    try {
      const url = new URL(request.url);
      
      // ==========================================
      // 1. 配置项 (请替换为你的真实数据)
      // ==========================================
      const BOCHA_API_KEY = '博查 API Key'; 
      const SECRET_KEY = '你生成的一个 32 位随机 Key'; 
      const THRESHOLD_SECONDS = 300; 

      // ==========================================
      // 2. 动态 Token 验证逻辑
      // ==========================================
      const tsParam = url.searchParams.get('ts');
      const signParam = url.searchParams.get('sign');
      let isAuthenticated = false;

      if (tsParam &amp;&amp; signParam) {
        const requestTimestamp = parseInt(tsParam, 10);
        if (!isNaN(requestTimestamp)) {
          const currentTimestamp = Math.floor(Date.now() / 1000);
          if (Math.abs(currentTimestamp - requestTimestamp) &lt;= THRESHOLD_SECONDS) {
            const messageToHash = tsParam + SECRET_KEY;
            const expectedSign = await generateSHA256(messageToHash);
            if (signParam.toLowerCase() === expectedSign.toLowerCase()) {
              isAuthenticated = true;
            }
          }
        }
      }

      if (!isAuthenticated) {
        return new Response('&lt;h1&gt;403 Forbidden&lt;/h1&gt;&lt;p&gt;Invalid Signature or Expired Timestamp&lt;/p&gt;', { 
          status: 403, 
          headers: { 'Content-Type': 'text/html;charset=UTF-8' }
        });
      }

      // ==========================================
      // 3. 提取参数与构建 Payload
      // ==========================================
      const query = url.searchParams.get('query');
      if (!query) {
        return new Response('&lt;h1&gt;400 Bad Request&lt;/h1&gt;&lt;p&gt;Missing parameter: query&lt;/p&gt;', { 
          status: 400, 
          headers: { 'Content-Type': 'text/html;charset=UTF-8' }
        });
      }

      const payload = { query: query };
      if (url.searchParams.has('freshness')) payload.freshness = url.searchParams.get('freshness');
      if (url.searchParams.has('summary')) payload.summary = url.searchParams.get('summary') === 'true';
      if (url.searchParams.has('include')) payload.include = url.searchParams.get('include');
      if (url.searchParams.has('exclude')) payload.exclude = url.searchParams.get('exclude');
      if (url.searchParams.has('count')) {
        const countVal = parseInt(url.searchParams.get('count'), 10);
        if (!isNaN(countVal)) payload.count = countVal;
      }

      // ==========================================
      // 4. 发起请求并渲染 HTML
      // ==========================================
      const bochaResponse = await fetch("https://api.bocha.cn/v1/web-search", {
        method: "POST",
        headers: {
          "Authorization": `Bearer ${BOCHA_API_KEY}`,
          "Content-Type": "application/json"
        },
        body: JSON.stringify(payload)
      });

      const bochaJson = await bochaResponse.json();

      let htmlContent = `&lt;!DOCTYPE html&gt;
      &lt;html&gt;
      &lt;head&gt;&lt;meta charset="utf-8"&gt;&lt;title&gt;Search Results: ${query}&lt;/title&gt;&lt;/head&gt;
      &lt;body&gt;
        &lt;h1&gt;搜索结果:${query}&lt;/h1&gt;
        &lt;hr&gt;
      `;

      if (bochaJson.data &amp;&amp; bochaJson.data.webPages &amp;&amp; Array.isArray(bochaJson.data.webPages.value)) {
        const results = bochaJson.data.webPages.value;
        if (results.length === 0) {
          htmlContent += `&lt;p&gt;未能找到相关网页结果。&lt;/p&gt;`;
        } else {
          results.forEach((item, index) =&gt; {
            htmlContent += `
              &lt;article style="margin-bottom: 24px;"&gt;
                &lt;h2&gt;&lt;a href="${item.url || ''}"&gt;${index + 1}. ${item.name || '无标题'}&lt;/a&gt;&lt;/h2&gt;
                &lt;p&gt;&lt;strong&gt;来源:&lt;/strong&gt; ${item.siteName || '未知'} | &lt;strong&gt;时间:&lt;/strong&gt; ${item.datePublished || item.dateLastCrawled || '未知'}&lt;/p&gt;
                &lt;p&gt;&lt;strong&gt;摘要:&lt;/strong&gt; ${item.snippet || ''}&lt;/p&gt;
            `;
            if (item.summary) {
              htmlContent += `&lt;p&gt;&lt;strong&gt;总结:&lt;/strong&gt; ${item.summary}&lt;/p&gt;`;
            }
            htmlContent += `&lt;/article&gt;&lt;hr&gt;`;
          });
        }
      } else {
        htmlContent += `&lt;h2&gt;API 请求出错或返回结构异常&lt;/h2&gt;&lt;pre&gt;${JSON.stringify(bochaJson, null, 2)}&lt;/pre&gt;`;
      }

      htmlContent += `&lt;/body&gt;&lt;/html&gt;`;

      return new Response(htmlContent, {
        status: 200,
        headers: {
          "Content-Type": "text/html;charset=UTF-8",
          "Access-Control-Allow-Origin": "*"
        }
      });
      
    } catch (error) {
      // 如果再遇到致命错误,会在这里直接被拦截并打印在网页上
      return new Response(`
        &lt;h1&gt;Worker Error (1101 Prevented)&lt;/h1&gt;
        &lt;p&gt;内部发生了未捕获的错误:&lt;/p&gt;
        &lt;pre style="background:#f4f4f4; padding:15px;"&gt;${error.stack || error.message || error}&lt;/pre&gt;
      `, { 
        status: 500,
        headers: { 'Content-Type': 'text/html;charset=UTF-8' }
      });
    }
  },
};

五、给 Notion AI 的调用 Prompt

Worker 只是桥。真正让它变成 Notion AI 技能的,是一段清晰的调用说明。

可以这样写:

接口地址:`https://your-bocha-worker.example.workers.dev`

【URL 参数说明(必须进行 URL 编码)】

- `query` (必填): 你的搜索词。
- `summary` (可选): 是否返回长摘要,传 "true" 或 "false"。建议查阅复杂资料时设为 "true"。
- `count` (可选): 返回条数,1-50。默认 10。
- `freshness` (可选): 时间范围限制。可选值:"noLimit"(默认), "oneDay", "oneWeek", "oneMonth", "oneYear" 或指定日期格式如 "2025-01-01..2025-04-06"。
- `include` (可选): 限制在指定域名内搜索,多个用 `|` 分隔(如 [qq.com|m.163.com](http://qq.com%7Cm.163.com))。
- `exclude` (可选): 排除指定域名,格式同上。

【强制鉴权步骤】
每次发起请求前,必须按以下步骤生成动态鉴权参数:

1. 获取当前准确的 10 位 Unix 时间戳(精确到秒)。
2. 将该时间戳与字符串 "你设计的 32 位随机 Key" 拼接(格式:时间戳+密钥)。
3. 使用计算工具计算拼接字符串的 SHA-256 哈希值(输出小写)。
4. 将时间戳作为 `ts` 参数,哈希值作为 `sign` 参数。
5. 在完成权鉴 URL 的拼接后,不再使用计算机工具,而改为使用浏览网页的工具(web.loadPage)发起搜索。

【调用格式示例】
如果你要搜索 "2024年诺贝尔物理学奖得主",并需要摘要,返回 5 条结果,最终请求的 URL 格式应如下:
`https://bocha-notionai.xiaoyao-f87.workers.dev/?query=2024%E5%B9%B4%E8%AF%BA%E8%B4%9D%E5%B0%94%E7%89%A9%E7%90%86%E5%AD%A6%E5%A5%96%E5%BE%97%E4%B8%BB&amp;summary=true&amp;count=5&amp;ts=1715000000&amp;sign=计算出的哈希值`

获取到 JSON 响应后,请解析其中的 `data.webPages.value` 数组,提取 `name`、`url`、`snippet` 和 `summary` 字段,整理并总结后回答用户的问题。

在这个 Prompt 里,Notion AI 只需要知道「如何生成签名」和「如何拼 URL」。真正的 API Key 留在 Worker 里。

如果担心把 SECRET_KEY 也写进 Prompt,可以进一步做一层更保守的设计:让 Worker 接收一个固定的内部 Token,或者改用 Cloudflare Access、IP 限制、一次性短链等方式。但对个人使用场景来说,时间戳 + 哈希签名 已经足够轻量。

六、这个方法可以接入什么

博查只是一个例子。只要第三方服务能被 Worker 调用,就可以用类似方式接进 Notion AI:

  • 搜索 API:中文搜索、垂直站点搜索、私有搜索引擎。
  • 数据 API:自建数据库、Notion 之外的表格、CRM、日志系统。
  • 模型 API:转录、摘要、分类、向量检索、图像理解。
  • 自动化 API:Webhook、内部工具、个人服务器上的脚本。

它们都可以被包装成一个 Notion AI 能读懂的网页。

这件事的意义不只是「让 Notion AI 多一个工具」。更准确地说,它让个人可以把自己的外部系统,变成 Notion AI 的可观测边界。

当这些 API 接进来以后,Notion AI 不再只是访问 Notion 页面和公共网页。它可以访问你的订阅源、你的私有搜索、你的自动化流水线、你的本地知识系统。