我名下有两个数字员工：一个负责开发、测试、部署，另一个在用户群里服务真实的同事。它们不是工具，是组织里两个正式的岗位。岗位一立起来，一个问题就自然跟着来了：
「如果它批错了一张审批单，造成了损失，谁来负责？」
这个问题不难答——难的是我发现，市面上绝大多数 AI 产品，从来没准备回答这个问题，因为它们压根不是「员工」。
Chatbot、数字分身、数字员工，这三个词正在被混着用。很多人以为它们只是同一类产品的不同营销话术：能力弱一点的叫 Chatbot，能力强的叫数字员工。
但我的判断是： 它们是三代不同的东西。 区分代际的不是模型有多聪明，而是两个更根本的问题：
它的 Source of Truth 是什么？它出了错，谁来负责？
想清楚这两个问题，很多关于企业 AI 的争论会立刻变得清晰。
[Read More]上周有人请我整理一套数字员工的术语，用途是整理会议纪要。
整理的时候我意识到一件事：会议纪要看起来是最容易交给 AI 的岗位。语音识别模型足够强，转写免费，人人会用。按常理，它应该是数字员工最先上岗的岗位。
但我们真动手做的时候，发现不是这样。
第一版会议纪要机器人，把会议里的每一句话都转写出来了。问题是，没人看得懂：
「关于上次说的那件事，就按讨论的办。」——哪件事？怎么讨论的？
「这个意见我同意。」——谁的意见？
「后续小王跟进一下。」——哪个小王？
而且，转写本身也不总是干净的。真正容易出错的，不是通用技术术语，而是企业自己的语言——项目代号、产品名、客户简称、组织缩写、内部黑话。比如「北极星二期」「天穹计划」「A17 客户」「P0 升级」「DWS」「飞鹰版本」，通用模型根本不知道这些词代表什么，转写很容易出现同音字或拆词错误。
看起来是两个问题：术语转不准；就算转准了，也没人看得懂。
其实是同一个问题：缺上下文。术语转不准，是因为模型的词典里没有你公司的词；看不懂，是因为纪要里没有这些人是谁、属于哪个项目、上次讨论了什么决定、谁负责什么事。
这次经历让我们得到一个后来反复验证的判断： 数字员工不是任何岗位都能做，只有「上下文充分」的岗位才能做好。
判断一个岗位是否适合数字员工，只需要看五件事。
上周整理数字员工的术语，有人在讨论里问了一个问题：
「数字员工背后的 Agent，具体实现上是一套什么东西？」
这个问题问得好。市面上大多数回答是这样的：一个模型加一段 Prompt，接一个知识库，套一个对话框。听起来也没错——demo 确实就是这么做出来的。
但 demo 和员工是两回事。我们做会议纪要数字员工的时候，第一版正是「模型 + Prompt + 转写」，能跑，但没人敢用：纪要里全是「小王跟进一下」，没人知道是哪个小王；待办派错了人，也没有任何机制能发现。
后来它变成一个真正能干活的数字员工，靠的不是换更强的模型——模型一直没换。靠的是在模型外面，一层一层搭起来的东西。
[Read More]上周我刚发布《数字员工是下一个十年的故事》。今天读到一篇 36 氪 首发：清华背景的团队奇点逃逸完成千万级种子轮融资，做 AI 原生团队协作操作系统 Nexus。
读完之后我的第一反应不是「又一个竞品」，而是：
这个命题，正在从一个人的判断，变成一个被资本定价的方向。
这不是巧合。当一个论点独立地从不同起点被推导出来——我做企业协作基础设施，他们做多智能体研究——它大概率触到了某个真实的结构。
[Read More]我的钉钉组织里有两名不领工资的「员工」。一个负责开发、测试、部署另一个；另一个在用户群里服务真实的同事。两个的主管都是我。
经常有人问我：这两个东西到底是什么？Agent？机器人？助手？
我的答案是： 它们是岗位。
这个回答背后，藏着一个我琢磨了很久的判断：
Agent 能解决能力问题，而数字员工解决组织问题。AI 真正进入企业，不是因为模型更聪明，而是因为它第一次拥有了组织身份。
模型能力的竞赛已经足够激烈，也足够拥挤。但企业 AI 真正的瓶颈从来不在能力——而在 信任。能力决定一个 AI 会不会干活，身份决定它能不能上岗。下一个十年的故事，不是造出更聪明的 Agent，而是让 AI 以「岗位」的形式，真正进入组织。
[Read More]太平洋汽车的内容被豆包、千问和 DeepSeek 引用之后，合计触达了 1237 万用户。
这个数字是太平洋汽车 App 自有流量的 113.8 倍。
一百一十三倍。超过一百倍的用户通过 AI 平台「消费」了太平洋汽车的内容——他们在豆包的聊天窗口里问了一个关于买车的问题，豆包引用太平洋汽车的评测给出了答案，用户满意地关掉了对话。
然后呢？ 太平洋汽车什么都没得到。 没有访问，没有注册，没有广告展示，没有用户画像。内容被吃干抹净，连渣都没剩。
这个故事来自极客公园上周的一篇报道，讲的是 AI 时代互联网流量的大崩塌。但让我想了很久的不是流量问题——而是一个更底层的问题：
如果内容本身不是最有价值的资产，那什么才是？
上个月和一位做 HR SaaS 的朋友吃饭。他刚花了两百万买了一批行业测评数据，准备训练自己的垂直模型。
我问他：「竞品如果也买同样的数据呢？」
他愣了一下：「那……我们还有先发优势。」
「先发多少？」
「大概……半年？」
半年。这就是原始数据作为护城河的保质期。
三个月前，我写了一篇 中国 SaaS 厂商的护城河应该怎么建，核心公式是：
护城河 = 垂直行业数据资产 × 行业 Know-How × 客户成功体系 × 生态协同
那篇文章里，我把「数据壁垒」放在七大维度的第一位，画了一个数据飞轮：客户使用 → 数据沉淀 → 模型训练 → 更精准的服务 → 更多客户使用。
三个月后，我要修正自己。
飞轮里转的不是数据，是 eval。
前两天看到一篇文章，标题很刺激：「飞书被收编，钉钉要改名，企业微信慌不慌？」
核心论证链很锋利：互联网办公平台第一次降维打击了传统企业软件，然后 AI Agent 第二次降维打击了超级 App。结论是 To B 软件只剩两种位置——要么成为入口，要么成为入口背后绕不开的系统。
写得很好。但我读完之后一直在想一个问题： 他说的「绕不开的系统」，对钉钉来说到底意味着什么？
不是「钉钉也能活下来」这种防御性思考。而是：如果钉钉主动选择，它应该把资源押在哪里？
一个人类员工一天审批 20 单、发 50 封邮件、访问 10 个系统。如果权限有漏洞，损害上限是 20 单。
一个 Agent 一秒调 100 次 API。一分钟 6000 次，十分钟 60000 次。如果权限有漏洞，你甚至来不及发现，损害就已经是 **指数级 **的。
这不是量变，是质变。传统权限模型（RBAC / ABAC）有一个隐含假设： 操作者是人，操作速度是人的速度。 这个假设在 Agent 时代彻底失效了。
再加上三个新问题：委托链（人委托 Agent A，A 调用 Agent B，B 访问系统 C）、上下文依赖（同一个 Agent 在不同群里有不同权限）、可被操纵（Agent 可能被 prompt injection 劫持）——传统权限模型不是「需要升级」，而是 需要重新设计。
[Read More]晚上 10 点，纽约的产品经理在 Linear 上建了一个竞品分析的 ticket，在群里 @ 了东京的工程师，又发了一封邮件给伦敦的设计师。三个渠道，三种状态，没有一个地方能看到全貌。
第二天早上，产品经理问：「进度怎么样了？」东京说：「刚看到群消息，还没开始。」伦敦说：「邮件？我昨天没在线。」Linear 上的 ticket 状态还是 To Do——因为没人记得去更新它。
这个场景每天都在全球化团队里上演。我们用了二十年时间解决「人怎么跨时区协作」——异步文档、录屏、standup 录音、follow-the-sun 排班。但本质上，所有方案都在做同一件事： 让不在场的人也能跟上进度。
如果有一种同事，它没有时区、不需要睡觉、7×24 在线、能在你下班后继续推进工作呢？
这种同事已经存在了。它叫 Agent。但我们的协同办公产品——通讯录、IM、邮件——还没有为它做好准备。
[Read More]