Hugo Zhu's Blog

上周有人请我整理一套数字员工的术语，用途是整理会议纪要。

整理的时候我意识到一件事：会议纪要看起来是最容易交给 AI 的岗位。语音识别模型足够强，转写免费，人人会用。按常理，它应该是数字员工最先上岗的岗位。

但我们真动手做的时候，发现不是这样。

第一版会议纪要机器人，把会议里的每一句话都转写出来了。问题是，没人看得懂：

「关于上次说的那件事，就按讨论的办。」——哪件事？怎么讨论的？

「这个意见我同意。」——谁的意见？

「后续小王跟进一下。」——哪个小王？

而且，转写本身也不总是干净的。真正容易出错的，不是通用技术术语，而是企业自己的语言——项目代号、产品名、客户简称、组织缩写、内部黑话。比如「北极星二期」「天穹计划」「A17 客户」「P0 升级」「DWS」「飞鹰版本」，通用模型根本不知道这些词代表什么，转写很容易出现同音字或拆词错误。

看起来是两个问题：术语转不准；就算转准了，也没人看得懂。

其实是同一个问题：缺上下文。术语转不准，是因为模型的词典里没有你公司的词；看不懂，是因为纪要里没有这些人是谁、属于哪个项目、上次讨论了什么决定、谁负责什么事。

这次经历让我们得到一个后来反复验证的判断： 数字员工不是任何岗位都能做，只有「上下文充分」的岗位才能做好。

判断一个岗位是否适合数字员工，只需要看五件事。

上周整理数字员工的术语，有人在讨论里问了一个问题：

「数字员工背后的 Agent，具体实现上是一套什么东西？」

这个问题问得好。市面上大多数回答是这样的：一个模型加一段 Prompt，接一个知识库，套一个对话框。听起来也没错——demo 确实就是这么做出来的。

但 demo 和员工是两回事。我们做会议纪要数字员工的时候，第一版正是「模型 + Prompt + 转写」，能跑，但没人敢用：纪要里全是「小王跟进一下」，没人知道是哪个小王；待办派错了人，也没有任何机制能发现。

后来它变成一个真正能干活的数字员工，靠的不是换更强的模型——模型一直没换。靠的是在模型外面，一层一层搭起来的东西。

上周我让一个 Coding Agent 给一个 Web 应用实现登录功能。三轮迭代之后，它汇报：「完成了，所有测试通过。」

我打开浏览器一看：登录按钮不见了。

我把截图丢回去，它看了一眼，回复：「抱歉，上一轮我把按钮组件误删了。」

有意思的不是 Agent 会犯错——犯错很正常。有意思的是： 它直到看见那张截图，才知道自己犯了错。 那三轮迭代里，它有编译反馈，有测试报告，但它没有任何办法知道最终页面长什么样。它的「世界」是残缺的。

这件事让我更确认了一个琢磨了很久的判断：

对于 Coding Agent，最重要的基础设施不是更聪明的模型，不是 Benchmark，而是端到端（E2E）Test Harness。

上周我刚发布《数字员工是下一个十年的故事》。今天读到一篇 36 氪 首发：清华背景的团队奇点逃逸完成千万级种子轮融资，做 AI 原生团队协作操作系统 Nexus。

读完之后我的第一反应不是「又一个竞品」，而是：

这个命题，正在从一个人的判断，变成一个被资本定价的方向。

这不是巧合。当一个论点独立地从不同起点被推导出来——我做企业协作基础设施，他们做多智能体研究——它大概率触到了某个真实的结构。

我的钉钉组织里有两名不领工资的「员工」。一个负责开发、测试、部署另一个；另一个在用户群里服务真实的同事。两个的主管都是我。

经常有人问我：这两个东西到底是什么？Agent？机器人？助手？

我的答案是： 它们是岗位。

这个回答背后，藏着一个我琢磨了很久的判断：

Agent 能解决能力问题，而数字员工解决组织问题。AI 真正进入企业，不是因为模型更聪明，而是因为它第一次拥有了组织身份。

模型能力的竞赛已经足够激烈，也足够拥挤。但企业 AI 真正的瓶颈从来不在能力——而在 信任。能力决定一个 AI 会不会干活，身份决定它能不能上岗。下一个十年的故事，不是造出更聪明的 Agent，而是让 AI 以「岗位」的形式，真正进入组织。

上个月，我们团队一位产品经理花了两周写了一份 40 页的 PRD，描述一个智能审批 Agent 的需求。用户故事、流程图、异常分支、验收标准，写得滴水不漏。

她把 PRD 丢给 Coding Agent，说：「按这个做。」

三天后 Agent 交付了。代码能跑，测试通过，接口对齐。但她试了五分钟就皱眉：「这不是我要的东西。」

哪里不对？她说不清。审批流程是对的，权限校验是对的，消息通知是对的。但 Agent 处理「领导已读不回超过 48 小时」的策略，不是她脑子里想的那个。PRD 里写的是「超时后自动提醒」，Agent 就老老实实给所有超时审批发了一轮提醒——包括那些「领导出差没看手机」的非紧急件。她真正想要的是「先判断这条审批是否紧急，紧急的才提醒，不紧急的等下次汇总」。

这个判断，她没写进 PRD。因为她觉得这是「常识」。

Agent 没有常识。Agent 只有你给它的判据。

太平洋汽车的内容被豆包、千问和 DeepSeek 引用之后，合计触达了 1237 万用户。

这个数字是太平洋汽车 App 自有流量的 113.8 倍。

一百一十三倍。超过一百倍的用户通过 AI 平台「消费」了太平洋汽车的内容——他们在豆包的聊天窗口里问了一个关于买车的问题，豆包引用太平洋汽车的评测给出了答案，用户满意地关掉了对话。

然后呢？ 太平洋汽车什么都没得到。 没有访问，没有注册，没有广告展示，没有用户画像。内容被吃干抹净，连渣都没剩。

这个故事来自极客公园上周的一篇报道，讲的是 AI 时代互联网流量的大崩塌。但让我想了很久的不是流量问题——而是一个更底层的问题：

如果内容本身不是最有价值的资产，那什么才是？

上个月和一位做 HR SaaS 的朋友吃饭。他刚花了两百万买了一批行业测评数据，准备训练自己的垂直模型。

我问他：「竞品如果也买同样的数据呢？」

他愣了一下：「那……我们还有先发优势。」

「先发多少？」

「大概……半年？」

半年。这就是原始数据作为护城河的保质期。

三个月前，我写了一篇 中国 SaaS 厂商的护城河应该怎么建，核心公式是：

护城河 = 垂直行业数据资产 × 行业 Know-How × 客户成功体系 × 生态协同

那篇文章里，我把「数据壁垒」放在七大维度的第一位，画了一个数据飞轮：客户使用 → 数据沉淀 → 模型训练 → 更精准的服务 → 更多客户使用。

三个月后，我要修正自己。

飞轮里转的不是数据，是 eval。

上个月一个团队找我聊数字员工落地。

他们已经有 12 个 agent 在跑了。销售助手、客服助手、HR 问答、会议纪要……每个都是独立项目，独立部署，独立维护。

CTO 说：「我们想扩到 200 个。」

我问：「现在 12 个的权限怎么管的？」

他愣了一下：「每个 agent 一个 API key，配在环境变量里。」

「记忆呢？A 部门的 agent 会不会读到 B 部门的会议纪要？」

「……应该不会吧。」

「两个 agent 对同一件事判断冲突了，谁说了算？」

沉默。

12 个靠人盯，200 个靠什么？

而且这 12 个跑在半年前的模型上。模型半年一换代，agent 策略周级迭代——你还没把 12 个理顺，底座已经换了。这不是「多部署几个」的问题。这是架构问题。

前两天看到一篇文章，标题很刺激：「飞书被收编，钉钉要改名，企业微信慌不慌？」

核心论证链很锋利：互联网办公平台第一次降维打击了传统企业软件，然后 AI Agent 第二次降维打击了超级 App。结论是 To B 软件只剩两种位置——要么成为入口，要么成为入口背后绕不开的系统。

写得很好。但我读完之后一直在想一个问题： 他说的「绕不开的系统」，对钉钉来说到底意味着什么？

不是「钉钉也能活下来」这种防御性思考。而是：如果钉钉主动选择，它应该把资源押在哪里？