上周内部交流会，有位同学站起来提了一个问题。
问题原文是这样的：
如果希望公司更像一家 AI-native 公司，各位 Leader 最希望大家立刻停止的一种/几种传统工作方式是什么，以及希望大家开始的一种/几种工作方式是什么？
主持人让我先答。
我第一反应是给一份工具清单：停止手写代码，开始用 Agent；停止人肉搜信息，开始问 AI。这种答案安全、正确，而且没用。
于是我在回答之前，先问了自己一个问题： AI 工具早就全员配齐了，为什么我依然觉得组织不够 AI-native？
答案不在工具上，而在一些我们习以为常、甚至毫无察觉的工作方式上——它们运行得太自然，以至于我们误以为它们就是工作本身。
7 月下旬发生了两件事。表面上毫无关系，放在一起看，指向了同一个地方。
7 月 25 日，YC Startup School 旧金山现场，Jeff Dean 站在 6000 名创始人面前。主持人问：普通创业团队凭什么跟大厂竞争？这位 MapReduce、TensorFlow、TPU、Gemini 背后的首席科学家，给出的答案是 上下文工程（context engineering）——「你只需要一个 API」。他还说了一句我认为值得裱起来的话： 训练数据是几万亿 token 搅成一锅汤，糊进几千亿参数里；而上下文，是模型此刻直接看见的东西，清晰得多。
五天后的 7 月 30 日，字节跳动下发内部邮件，完成近年来力度最大的一次 ToB 架构调整：飞书产品团队并入豆包产品体系，商业化团队与火山引擎合并为新的 GTM 组织「创造力服务平台」。飞书这家「产品+商业化」一体的完整公司，被拆件重组，分别挂到字节的两条主线上——模型，和云。
一个是行业顶端科学家的判断，一个是最务实的 ToB 玩家的组织动作。同一周，指向同一件事：
AI 的竞争已经换场了。大家争夺的不再是模型，而是上下文。
上周和一群刚工作的年轻人交流。有人问我一个问题：我每天都在用 AI，prompt 也调得不错，效率确实提高了——但为什么总觉得，我还是在「自己干活」？
我反问他：你的 AI，会不会越用越好？
他愣了一下：好像不会。每次新开一个对话，都像第一次认识一个新同事。
问题就在这里。他很会用 AI，但他从来没有管理过 AI。
这两件事的差距，比他以为的大得多。
李开复在他的新书《AI 未来已来》里讲了一件微软旧事。
2000 年他升任微软全球副总裁，后来才知道，在他毫不知情的时候，总部一年一度的人才盘点已经把他摆上了桌面——比尔·盖茨和鲍尔默认为他最适合出任一个新事业部的副总裁。他第一次意识到：在这家公司，顶尖人才的去向不是哪个部门领导的家务事，而是最高层亲自过问的大事。
更让他震撼的是制度本身：微软每年把最顶尖的 1% 员工挑出来，不论资历，只看潜力。首席人力资源官告诉他，鲍尔默睡前的功课之一，就是几十份几十份地翻看这些人的资料，确保他们的奖励到位、能感受到最高层的关注。鲍尔默对副总裁们说过一句狠话：
排在前 1% 的人，不属于你们，属于我。我要知道他们都是谁——公司有需求时，我有权随时调动他们。
这是 30 年前的管理智慧：顶尖人才，必须由一号位亲自盯。
但注意它的实现方式——靠鲍尔默的意志力，靠 HR 一年一次的名单。一年一次，几十个人。这已经是人力注意力的极限。而一家几千人的公司里，真正的顶尖人才远不止名单上那几十个人。
李开复写道：2025 年，他在零一万物把这件事重新做了一遍。这一次，用的是「老板 AI」。
我名下有两个数字员工：一个负责开发、测试、部署，另一个在用户群里服务真实的同事。它们不是工具，是组织里两个正式的岗位。岗位一立起来，一个问题就自然跟着来了：
「如果它批错了一张审批单，造成了损失，谁来负责？」
这个问题不难答——难的是我发现，市面上绝大多数 AI 产品，从来没准备回答这个问题，因为它们压根不是「员工」。
Chatbot、数字分身、数字员工，这三个词正在被混着用。很多人以为它们只是同一类产品的不同营销话术：能力弱一点的叫 Chatbot，能力强的叫数字员工。
但我的判断是： 它们是三代不同的东西。 区分代际的不是模型有多聪明，而是两个更根本的问题：
它的 Source of Truth 是什么？它出了错，谁来负责？
想清楚这两个问题，很多关于企业 AI 的争论会立刻变得清晰。
[Read More]让一个 Browser Agent 订一张机票。打开网站、登录、输入出发地和目的地、筛选时间、选航班、提取价格——听起来就六个动作。
但你真的去看第一代 Browser Agent 跑这个流程，会发现它的大部分时间根本没花在这六个动作上。它在登录——它新起的那个浏览器没有任何登录态；它在等待——等页面加载、等元素出现；它在定位 DOM——CSS 选择器又变了；它在重试——某一步失败，推倒重来。真正的业务逻辑，占比很小（这是我观察执行 trace 的估算，不同任务差异很大）。
问题不在模型不够聪明，在架构：浏览器是一次性工具，这些成本就永远摊不掉。
最近有人丢给我一个新产品 ego Lite 的资料，问值不值得试。我的第一反应和大多数人一样：又一个 Browser Agent？但把它的架构看完，我意识到这个理解是错的——它真正动的不是 Prompt，不是模型，而是浏览器在 Agent 系统里的角色。
过去 Browser 是 Tool。现在 Browser 开始变成 Runtime。
这是我认为 Browser Agent 最近一年最值得关注的技术方向。
上周有人请我整理一套数字员工的术语，用途是整理会议纪要。
整理的时候我意识到一件事：会议纪要看起来是最容易交给 AI 的岗位。语音识别模型足够强，转写免费，人人会用。按常理，它应该是数字员工最先上岗的岗位。
但我们真动手做的时候，发现不是这样。
第一版会议纪要机器人，把会议里的每一句话都转写出来了。问题是，没人看得懂：
「关于上次说的那件事，就按讨论的办。」——哪件事？怎么讨论的？
「这个意见我同意。」——谁的意见？
「后续小王跟进一下。」——哪个小王？
而且，转写本身也不总是干净的。真正容易出错的，不是通用技术术语，而是企业自己的语言——项目代号、产品名、客户简称、组织缩写、内部黑话。比如「北极星二期」「天穹计划」「A17 客户」「P0 升级」「DWS」「飞鹰版本」，通用模型根本不知道这些词代表什么，转写很容易出现同音字或拆词错误。
看起来是两个问题：术语转不准；就算转准了，也没人看得懂。
其实是同一个问题：缺上下文。术语转不准，是因为模型的词典里没有你公司的词；看不懂，是因为纪要里没有这些人是谁、属于哪个项目、上次讨论了什么决定、谁负责什么事。
这次经历让我们得到一个后来反复验证的判断： 数字员工不是任何岗位都能做，只有「上下文充分」的岗位才能做好。
判断一个岗位是否适合数字员工，只需要看五件事。
上周整理数字员工的术语，有人在讨论里问了一个问题：
「数字员工背后的 Agent，具体实现上是一套什么东西？」
这个问题问得好。市面上大多数回答是这样的：一个模型加一段 Prompt，接一个知识库，套一个对话框。听起来也没错——demo 确实就是这么做出来的。
但 demo 和员工是两回事。我们做会议纪要数字员工的时候，第一版正是「模型 + Prompt + 转写」，能跑，但没人敢用：纪要里全是「小王跟进一下」，没人知道是哪个小王；待办派错了人，也没有任何机制能发现。
后来它变成一个真正能干活的数字员工，靠的不是换更强的模型——模型一直没换。靠的是在模型外面，一层一层搭起来的东西。
[Read More]上周我让一个 Coding Agent 给一个 Web 应用实现登录功能。三轮迭代之后，它汇报：「完成了，所有测试通过。」
我打开浏览器一看：登录按钮不见了。
我把截图丢回去，它看了一眼，回复：「抱歉，上一轮我把按钮组件误删了。」
有意思的不是 Agent 会犯错——犯错很正常。有意思的是： 它直到看见那张截图，才知道自己犯了错。 那三轮迭代里，它有编译反馈，有测试报告，但它没有任何办法知道最终页面长什么样。它的「世界」是残缺的。
这件事让我更确认了一个琢磨了很久的判断：
[Read More]对于 Coding Agent，最重要的基础设施不是更聪明的模型，不是 Benchmark，而是端到端（E2E）Test Harness。
上周我刚发布《数字员工是下一个十年的故事》。今天读到一篇 36 氪 首发：清华背景的团队奇点逃逸完成千万级种子轮融资，做 AI 原生团队协作操作系统 Nexus。
读完之后我的第一反应不是「又一个竞品」，而是：
这个命题，正在从一个人的判断，变成一个被资本定价的方向。
这不是巧合。当一个论点独立地从不同起点被推导出来——我做企业协作基础设施，他们做多智能体研究——它大概率触到了某个真实的结构。
[Read More]