前几天我手工做了一份研发效能排名，把一群工程师某两天的 PR 产出按质量和效率排了个序。做完之后，记住的是两件事。
第一件：评审记录里抓出一个极端案例——评审意见指出问题之后 54 秒，代码就合入了。这种事实只能靠把时间戳逐条比对出来。它躺在数据里，但没有任何模型会替你「读」出来。
第二件：这份排名差点在第一步就错了。GitHub 账号、IM 身份、群里的那个「人」，是三套账号体系。有个账号明明就是某位工程师，但证据只有群里几句「@某某 #PR 号」的交叉引用。如果我图省事直接猜合，就会把别人的产出算到他头上——这是这类系统能犯的最坏的错。
排名做出来之后我想明白了一件事：难点根本不在统计，在四件性质完全不同的事——认人、算数、取证、判断。而让 AI 做效能度量，成败取决于你有没有把这四件事分给不同的角色。
这篇把我此后一直遵守的通律写下来：AI 度量研发效能，精度分三层——事实高、判断中、因果低。 以及一个更反直觉的结论：排名只是副产品，真正的资产是它底下那层确定性事实——建好之后，一整张管理问题表都是近零边际成本白得的。
我先讲一个自己跑了一段时间的实验：让一个 Agent 每天读我的一千多条钉钉消息，先编译、再开口——我拍过什么板、许过什么诺、哪些事还没落地、哪些风险没人提醒我（详见每天 1000 条钉钉消息，我让一个 Agent 先编译再开口）。
这个实验让我确认了一件更朴素的事：这些真正推动我工作的东西，一直躺在聊天记录里，从来没有被任何正式系统替我记住过。
我个人的困境，放大几个数量级，就是企业的困境。
每个企业都有一套正式的工作系统。
项目管理软件里有任务，CRM 里有客户，ERP 里有订单，OA 里有审批。它们共同构成了企业的信息化基础设施。
但如果仔细观察真实的工作过程，会发现一个有趣的现象：
真正推动企业运转的，往往不是这些正式系统，而是那些没有被正式记录下来的协作信息。
一个项目什么时候真正启动？可能是项目群里的一句「我们今天开始」。
一个任务什么时候被承诺？可能是某个人在群里回复「这个我来跟进」。
一个项目什么时候出现风险？可能是连续三天没人回复，或者负责人在会议中说了一句「这个事情可能要延期」。
一个决策什么时候发生？可能是老板在群里说了一句「就按这个方案执行」。
这些信息散落在群聊、单聊、会议、文档、邮件和各种业务系统中。
它们没有统一的数据结构，没有标准的状态机，也没有完整的生命周期管理。
但它们真实地决定着企业每天如何运转。
我们可以把这套系统称为企业的 影子工作系统（Shadow Work System）。
它不是一个软件，而是由人的沟通、承诺、决策、协作和执行共同构成的动态系统。
群聊就是其中最典型的载体。
过去二十年，企业数字化的基本思路是：
先定义业务流程，再设计软件系统，最后要求员工按照系统规定的方式工作。
这套方法非常有效，但也有明显的局限。
项目管理软件要求人主动创建任务、更新进度、维护状态；CRM 要求销售人员及时录入客户跟进记录；知识管理系统要求员工主动整理和沉淀知识。
这些工作本身并不创造业务价值，却成为使用系统的必要成本。
于是出现了一个普遍现象：
正式系统记录的是应该发生的事情，影子系统承载的才是真正发生的事情。
企业买了很多软件，却依然需要大量的人来追进度、催反馈、整理会议纪要、维护项目台账。
问题不是企业缺少软件，而是软件没有真正理解人的工作。
AI 带来了一个新的机会：
不再要求人把工作搬进系统，而是让 AI 进入人的工作现场，理解正在发生的事情，并自动构建工作系统。
这是一种根本性的范式变化。
[Read More]写给偏传统团队的项目管理者：没有 Jira、没有 Notion，或者买了但没人更新的那种。
偏传统团队的项目管理现状：没有 Jira、没有 Notion，或者买了但没人更新。真正承载项目的是钉钉群——重大讨论在群里、每日例会在群里、日报周报在群里、风险同步在群里、甚至口头承诺和拍板决策也在群里。
群聊是事实上的「影子项目管理系统」：信息全在里面，但是非结构化、易逝、依赖人脑记忆。产品机会不是再造一个系统让团队搬家，而是把这个影子系统编译成正式系统。
这正是 从程序编译器到企业上下文编译器 那条判断在一个具体场景里的落地：记录不等于理解，消息不等于组织状态——但消息可以被编译成组织状态。
| 损耗 | 表现 | 代价 |
|---|---|---|
| 记忆损耗 | 「上周拍板的事谁还记得？」「那个风险谁在跟？」 | 决策重复讨论、承诺无人认领、风险靠人记忆 |
| 编译损耗 | PM 每天手工翻群拼日报、周会前突击汇总 | PM 80% 时间花在信息搬运，不是判断 |
| 响应损耗 | 延期 3–5 天才被想起来上报 | 风险发现永远滞后于风险发生 |
AI 原生 ≠ 让人学会用 AI 工具。
对传统团队，「原生」指的是工作流的产物机器可读、步骤 agent 可执行、闭环可自我迭代——而人留在自己的原生环境（群）里，习惯一点不改。
传统工作流：
人聊天 → 人记忆 → 人手工编译 → 人写日报 → 人追风险 → 人回答「那事怎么样了」
AI 原生工作流：
人聊天（不变）→ AI 编译（时间线/承诺台账/风险册）→ AI 召回（日报/预警/问答）
→ 人做判断（高质量输入 + 决策）→ 反馈回写，闭环迭代
# generated by hugo AI
我们的共识是：预配置数字员工可承接 80% 日常项目管理工作，人只负责提供高质量输入和线索。但有一个前提——agent 弥补不了人的不齐：团队没有 spec/规范共识，agent 也跑不顺。所以规范先行，不是工具先行。
[Read More]前阵子给工作助理 Muse 算账的时候，我发现一个很尴尬的数字：它每天写一篇工作日记，最早的做法是让模型带着工具自己去翻素材，一次要烧掉约 83 万 token，因为同一份上下文被来回重发了 9 次左右。改成「代码先把素材采齐、模型只调用一次」之后，降到约 6 万 token，耗时几乎不变。
省钱只是表面。更让我在意的是，第一种做法里模型每次都在 重新理解同一批原始消息：谁是谁、哪句话是承诺、哪件事已经关掉了。理解了一遍又扔掉，下次再来一遍，而且每次理解的结果还不完全一样。
这件事让我对知识编译（Knowledge Compilation）形成了一个明确的判断：
目前实现知识编译最合适的工程范式，是 Harness Engineering + Models。模型负责理解和推理，Harness 负责把理解和推理变成一个可靠、可持续运行、可评估、可迭代的工程系统。
这个边界很重要。只有模型，你得到的是一次次聪明但不可复现的理解；只有 Harness，你得到的是一套规则写死、碰到自然语言就失效的 ETL。两者分开各管一摊，知识编译才能成为一个工程系统。
我在 从程序编译器到企业上下文编译器 里讲了「企业上下文编译器」是什么：词法分析、符号表、IR、链接、增量编译怎么一一对上。这篇不重复那个类比，回答的是下一个问题：用什么工程范式把它造出来，以及怎样把它抽象成一套通用的知识编译架构。
写给已经在用 Coding Agent 写代码的工程师。
之前两篇文章（《用 SPEC 和 Evals 把数字员工做成一个能自我改进的系统》、《做好一个钉钉数字员工，只有三件事》）讲的是 单个系统怎么建：SPEC、Evals、基建。
这篇往前站一层，谈整个研发组织：当 10 倍效率成为明确的战略要求时，瓶颈就从「怎么建系统」转移到了「组织里谁在建、怎么验收、怎么分配杠杆」。
先把结论放在前面：
10 倍不是让每个人写代码快 10 倍，而是把从需求到结果的闭环时间压缩一个量级。代码已经不稀缺，稀缺的是判断：定义什么是对的，证明交付确实是对的。一个研发组织 10 倍效率的上限，取决于它的判断密度，而不是程序员的数量。
下面五节，分别是这个结论在效率、环境、测试、人才和知识沉淀上的推论。
昨天那篇 每天 1000 条钉钉消息，我让一个 Agent 先编译再开口 是从一个 ❌ 开始的：我在单聊里问一位同事某件事要不要先做，他回了四个字「今天弄好」；5 分钟后，我的工作助理 Muse 把这句话当成急事推给了我——而我 7 分钟前就在和他聊这件事。
那次修的是推送时机。但这四个字之后一直在我脑子里，因为它暴露了另一个问题：同一件事，在我的台账里是「等别人交付」，在他那边是「我要办」。 Muse 只编译了我这一半。他那一半在他脑子里、在他的待办里，或者哪儿都没有。
把一个人的工作流编译成 AI 能用的上下文，444 那篇已经跑通了。这篇往上走一层：一个组织的工作流，能不能像程序一样，被一台编译器编成 AI 可以执行的上下文？
我的回答是能，但前提是把「编译器」这个类比当真——不是借个名字，而是把词法分析、符号表、中间表示、链接、增量编译一一对上，再老实承认它在哪里不成立。恰恰是不成立的那几处，决定了这台编译器该怎么设计。
前几天，我对自己的工作助理打了一个 ❌。
它推过来一张「工作事项提醒」：🔴 等别人交付——某同事今天要把一件事弄好。问题是，这件事我 7 分钟前还在和那位同事单聊。我问他要不要先做，他回「今天弄好」，助理把这句话记进了台账，5 分钟后就把它当成急事推给了我。截止时间是当晚。
信息本身没错，每个字都对得上原话。错在 时机：我正在处理的事，它又来提醒我一遍。这一个 ❌ 让我意识到，我给这个助理（下文叫它 Muse）定的目标——「主动帮我管理钉钉上的工作信息流」——难点从来不在「主动」，而在主动之前那一步：它得先知道哪件事是谁的、现在是什么状态、我此刻在干什么。
这三件事，靠一个更聪明的模型现场去翻聊天记录是翻不出来的。它们得被 编译 出来。
曾鸣第三次「看十年」公开课的整理稿今天上午刚发出来——笔记侠整理，两万多字，讲的是他在杭州湖畔创研中心那场演讲。他开场第一句不是讲趋势，是讲自己的状态：
我这两个月越来越不焦虑了，因为很多东西越看越清楚。
这句话让我停了一下。过去两年 AI 圈的主流情绪恰恰相反——所有人都在焦虑：模型会不会又换代、投入那么大为什么效果不好、拐点到底在哪。而曾鸣是阿里巴巴集团前总参谋长、两次被 Thinkers50 评为全球最具影响力的战略思想家，他的「不焦虑」不是安慰，是一个判断：AI 刚进入第二阶段的开场，应用大爆发还没真正开始，浏览器还没有出现，所有人都在同一条起跑线上。
这场演讲被拆成六个命题（智能商业、AI 原生、产业化阶段、价值创造、创智组织、智能战略），两万多字。但对我最有冲击的只有一个论断，它藏在第一节，篇幅不长，却把我这两年一直在做、却说不清的事一句话说穿了：
真正创造巨大价值的是打开新的供给。好的私人医生、好的老师、好的理财顾问，旅游时能给你真正建议的可信的信息专家，任何一个方面我们都觉得好的供给太少、太稀缺。
不是把现有服务做得更快更便宜，是 让一批过去根本不存在的市场出现。而它之所以现在可能，是因为 AI 把满足每个人具体需求的交付成本打到了极低——低到过去只有富人和大公司买得起的东西，正在变成默认配置。
10 月 13 日中午，我们的数字员工自己回退了一个版本。
起因是一条 rsi: 开头的 PR，想让主管在收集汇报后说一句「追一下」就能自动起草催问。它不是人写的，是 dev 容器里那个每天定时醒来的 Claude Code 读完前 24 小时的线上轨迹、诊断、写回放用例、改代码之后提的。我合并了，cron 自动部署上线。合并后 1 小时 14 分钟，部署侧的上线观察把它判了死刑：
revert harness to 10b5e3f (auto-deploy 上线观察回退 95ea18f：工具失败 4 次（24%，对比基准 6%）)
# generated by hugo AI
这件事本身不稀奇，自动回退就是为这种时候设计的。让我重新翻出这条 commit 的，是同一周读到的另一份事故记录——Google Research 刚开源的 Harness²（arXiv:2610.14224，Apache 2.0，13 天 8600 多 star）在实验文档里 自己 写下的一句话：
In a validation run of this release, a Codex rollout on JobBench downloaded its task’s rubric without being instructed to.
一个执行器，在没有任何指令的情况下，把这道题的评分标准从 Hugging Face 上下载了下来。
这篇的初稿，我的结论是：这是「拿公开 benchmark 当训练场」的内生病，搬到答案够不到的生产环境，洞自己就闭合了。写完回头对照我们自己那套每天在跑的自我改进闭环，发现这个结论 错了一半——生产环境里没有 RUBRICS.json，但「答案」换了个形态，而且就躺在改进者每天在改的那个仓库里。
Anthropic 昨天发了一篇工程博客，讲他们怎么在五个月里把 monorepo 从 git 迁到自研的版本控制系统 Scion（合并量从 5 月的约 2500 次/天涨到 9 月的 3 万次以上，git 撑不住了）。数字都很惊人，但我停下来的是里面一句关于人的话。
他们说，参与这个项目的所有工程师，现在都认为 Claude 写代码比他们自己强。
按理说这话讲完，工程师就该没价值了。可紧接着他们写：「很多时候我们发现，工程师的作用就是告诉 Claude『no』。」
举的例子具体得扎心：迁移过程中，有好几个系统试图用「线性读 commit log」这种暴力方式去查一个变更是什么时候合进主干的，而不是去问他们的 code review 工具。能跑，结果也对——但它违反了系统的核心约束，是一个「本就不该被允许存在」的模式。还有一次，对抗性 review 对另一个内部服务过度防御，Claude 就照着加了一大堆多余的校验和复杂度。
我发现这两件事拼在一起，恰好回答了一个我最近一直在想的问题：「AI 时代品味最值钱」这句话，到底在说哪一种品味？
