今年 4 月 17 日，Anthropic 上线了 Claude Design，直接对着 Figma 和 Canva 打。这件事在产品层面不算新闻——又一个 AI 生成界面的工具。真正值得注意的是它绕过的是什么：它让一部分设计工作不再需要打开 Figma。
OpenRouter CEO Alex Atallah 在那场访谈里的判断比我狠：他把 Claude Design 看作一种战略动作，「它未必立刻带来巨额收入，却能让设计团队在组织内部更关心 Anthropic 模型」。同时他也诚实地补了一句——从 Figma 公开的经营数字看，它表现依然很好。
两句话放一起，才是完整的事实：被绕过的那部分工作，还没大到能动财报。但方向已经定了——软件的用户界面，正在从「给人操作」变成「给 Agent 调用」，而当人不再打开界面，按人头卖软件的那本账，就开始算不动了。
这篇文章想说的是：数字员工和「给 SaaS 加个 AI 助手」的差别，不在功能强弱，在交付结构和定价单位。而定价单位真要换过去，缺的不是技术，是一个签字的人。
一、界面给 Agent 用之后，SaaS 剩下什么
先说那条路径，因为它最直观。设想一个老板想知道某个月的人员异动情况——这是个机制示意，不是某个客户战报——他不需要登录 HR 系统，在钉钉里说一句话，数字员工自己去 HR 系统取数、分析、生成结论，必要时发起审批。
HR SaaS 还是那个 HR SaaS，数据还在它那儿，业务规则还在它那儿。变的只有一件事：它的 UI 没有人看了。
SaaS → API → MCP / CLI → Agent → 数字员工
↑ ↑
数据与规则还在 界面在这一跳之后
从「人操作」变成「Agent 调用」
# generated by hugo AI
这条路里最关键的一跳是 API → MCP/CLI，因为只有这一跳完成了，Agent 才能不靠模拟点击去操作软件。我在 AI to B 的最后一公里 里讲过这个矛盾：传统企业 IT 三件套每个系统都有精美的 Web UI，对人类用户已经足够好，对 Agent 几乎完全不可用——所以「软件 CLI 化」是 AI Ready 的硬前提。
但这里有个被技术叙事盖住的问题：SaaS 厂商凭什么愿意交出 CLI？
开放界面等于开放自己被替代的入口。界面是 SaaS 的估值地基——DAU、时长、粘性、续费率，全都长在「人每天打开它」这件事上。让 Agent 来调用，意味着用户关系转移到了调用方手里，自己退化成一个 API 供应商，议价权差一个数量级。所以理性的 SaaS 厂商会抵抗，就像当年抵抗开放 API 一样。
那谁能让他们交？只有掌握终端用户关系的那一层。这恰好解释了 从货架到 Agent 里那张迁移表的终局判断——谁拥有最完整的上下文和最强的执行权，谁就定义了下一层。CLI 化不是厂商的善意，是价值链重新分配的结果。 这一点想清楚了，后面定价的事才谈得下去。
二、交付结构变了：从项目制到工程化生产
第二条差别在交付。传统 SaaS 定制的链条是这样的：
需求分析 → 产品定制 → 开发 → 实施 → 培训
（周期以月计，成本以十万计，每个客户重走一遍）
# generated by hugo AI
数字员工的链条短得多，而且关键的不是短，是 构成变了：
岗位 SPEC + 企业知识 + 权限 + Tools + Eval → Agent
# generated by hugo AI
这五样东西里，有四样不是软件公司能凭空造的——岗位 SPEC 来自组织怎么分工，企业知识来自现场沉淀，权限和 Tools 来自组织图谱和业务系统连接。它们是企业本来就有的东西，只是过去从来没被结构化。这正是我在 Palantir 从本体长到 Agent，我们从 Agent 长回本体 里说的「钥匙串本来就是本体」：工号是身份，组织图谱是关系，审批链是权限边界的活体实现。
所以这件事的本质，是把大量「项目制交付」变成「工程化生产」——软件工厂 3.0 里模具的逻辑，在交付侧的样子。模具值钱的前提是有足够多订单来摊销它；岗位 SPEC 值钱的前提也是同一件事：同一个岗位的 SPEC，能在多少家企业里复用。
不过我得把这条优势收窄一点，不然它会变成吹牛。钉钉真正独占的不是那串清单。 身份、组织、IM、权限、审批，这些是组织平台的共性——飞书、企业微信都有，把它们列出来证明不了护城河。真正难复制的只有两样：组织图谱的深度（不只是有通讯录，而是知道谁向谁汇报、哪条审批链在跑、哪个项目卡在谁手里）和 业务系统连接的广度（能调到的 Tools 有多少）。至于「执行记录」，它其实是这串清单里钉钉积累最浅的一项——那是 Agent 跑起来之后才产生的，归属和留存策略本身还是个开放问题。
清单从八样收到两样，反而更难反驳。
三、价值从「提效」到「替人干活」，但 ROI 没那么好算
第三条差别是价值口径。SaaS 的 AI 化很容易停在「帮你写一段、总结一下、推荐一下」——提效，但没人说得清提了多少。数字员工的口径是另一句话：这个岗位原来需要一个人，现在 AI 能承担其中一部分工作。
这个口径的好处是 ROI 天然可算。但「天然可算」这四个字，我要给它打个折，因为这里有两个落差：
任务级清晰，编制级模糊。 「承担 60%」如果承担的是最确定的那 60%，剩下的 40% 全是难的、需要判断的、出岔子的——人并不会因此轻松 60%，反而可能更累，因为他从干活的变成了兜底的。这和 数字员工的第一准则不是可控性 里那个电商案例是同一类风险：自动化的部分越确定，留给人的部分越尖锐。
编制不是连续量。 省掉 0.6 个人，编制上裁不掉 0.6 个人。那 0.4 还得有人盯，盯的人也要算成本。所以真实的 ROI 公式里，分母不只是被替代的人力，还有「看着它别出事」的人力——这部分在任务级账上看不见，在编制级账上躲不掉。
承认这两个落差，ROI 论述反而可信。任务级的 ROI 是真金白银，编制级的 ROI 要靠时间兑现。 把这两件事混在一句「降本 60%」里，是这类项目最容易翻车的地方。
四、定价单位要换：从席位到工作
前三条加起来，指向第四条，也是我认为最硬的一条：商业模式会变，因为计量单位变了。
| 传统 SaaS | AI Native | |
|---|---|---|
| 卖什么 | 工具的使用权 | 工作的完成 |
| 计量单位 | 席位（seat） | 完成的工作量 |
| 收入与什么挂钩 | 有多少人买 | 干成了多少事 |
| 风险由谁承担 | 客户（用不用得起来是客户的事） | 厂商（干不成就不该收钱） |
注意最后一行，它是整张表的关键：按席位收费是旱涝保收的，按工作收费是厂商自己扛交付风险的。 这不是换个报价方式，是把自己从卖工具的变成卖结果的。
而这条路在技术上已经被 未来的员工，有两份成本单 铺好了：当每个数字员工的 token 消耗和产出都能逐笔归因，「这一份工作花了多少、产出了什么」第一次变成可计算的量。按工作定价需要的计量能力，数字员工天生就有。
五、承重墙：「干完了」这三个字，谁来认定
但这里有一道墙，我认为是整件事真正的承重墙，也是所有谈 work-based pricing 的人都绕过去的那道。
「一份工作」的计量单位，谁来认定？
- 归客户认定：客户可以无限压价。「这个结果不算达标」「这批数据还得重跑」——每一句都合理，每一句都在少付钱。
- 归厂商认定：客户根本不信。你说是你干的活，凭什么按你的口径付钱？
两边都谈不拢，是因为缺了第三方：一份没有公证的计量，撑不起一个按结果计费的合同。
这正是我在 评测集是一份没人签字的文件 里说的那个问题，换了个身份出现。那篇讲的是工程侧：一个团队在某场景连续 20 多轮自动迭代都没效果，最后查出的根因藏在工具层；但那篇真正想说的是更扎心的一层——20 多轮里，没有一个人问过「这批评测 case 本身选对了吗」，因为这份评测集没有主人。当时的结论是：Eval 集需要一个签名，否则飞轮没有 owner。
现在把这句话挪到商业侧，它的分量完全变了：Eval 集的那个签名，就是按工作收费的结算依据。
工程侧（#384）： Eval 没签名 → 没人对「什么叫好」负责 → 飞轮空转
商业侧（本文）： Eval 没签名 → 没人对「干完了没」负责 → 合同扯皮
# generated by hugo AI
同一份文件，两个用途。工程上它决定 Agent 往哪改，商业上它决定谁付多少钱。这也是为什么我认为这条线比「数字员工好不好用」重要得多——谁持有 Eval 的签名权，谁就同时掌握了质量定义权和结算定义权。
把这条线串起来看，四篇讲的其实是一件事：
#384 Eval 需要签名 → 谁来定义「什么叫好」
#356 模具需要验收标准 → 谁来定义「什么算交付」
#393 成本单需要归因 → 谁来定义「花了多少、产出多少」
本文 定价需要计量公证 → 谁来定义「干完了」
# generated by hugo AI
计量单位是整个 AI Native 商业模式的基石。而这块基石现在没有公证机制——这是我认为接下来五年，企业软件市场真正要争夺的位置，比争模型、争入口都更靠近钱。
那这个签字的人，最可能是谁？我的推测是 岗位的业务 owner，而不是 IT，也不是厂商。理由回到 #384 那条结论：评测集没有主人，所以没人对「什么叫好」负责；而最该当这个主人的，是那个原本为这个岗位的结果负责的人。把 Eval 集挂到岗位上，业务 owner 签字确认这份 Eval 代表「这个岗位干完了的标准」——签的是标准，不是每一单。平台则负责存证：哪一单跑过、按哪版 Eval 验的、结果是什么，留痕不可改。这样客户不用逐单认定（他认定的是标准），厂商也不用自证清白（存证在第三方）。
这是我目前的推测，还没在真实合同里验证过。但结构上它比另外两个选项都站得住：逐单认定谈不拢，厂商自证没人信。
六、反方
反方一：这些你在 从货架到 Agent 里不是都讲过了？
讲过一半。#345 回答的是「平台在争什么」——从争人，到争意图，到争 Agent 的执行量，那是战略地图。这篇回答的是「生意怎么成交」——交付结构怎么变、定价单位怎么换、换的时候卡在哪。落点不同：#345 说增长公式从 seat 变成 task，但没回答 按 task 收费时，task 由谁认定。那正是本文的全部篇幅所在。
反方二：seat → work 只是话术。SaaS 厂商不会真换定价，客户也不会接受按量付费的不确定性。
客户侧的不确定性，恰好是 token 经济学在解决的。Alex 在访谈里给过一个实测个案：一个模型两周内价格降 10 倍，用量涨了 13 倍——典型的杰文斯悖论。单价雪崩意味着「按工作付费」的绝对金额会一路走低，客户面对的不确定性在变小，而不是变大。厂商侧的阻力是真的，但 #393 那条逻辑对厂商同样残酷：当客户的 token 消耗能被逐笔归因，seat 定价那种「买 100 个席位只用 20 个」的模糊地带就藏不住了——续费谈判桌上，客户会拿着第二份成本单来问你。不是厂商想不想换，是账本变清楚之后换不换得回去。
反方三（最该正面答的那个）：这一整套说到底是在给钉钉数字员工背书。
拆成两半答，因为一半是真的。
可证伪的判断是「定价单位会从席位迁移到工作，而迁移的前提是计量有公证」——这不是钉钉的主张。usage-based pricing 在 SaaS 里已经跑了多年，AI 公司按 token 计费更是日常；Alex 说的「员工成本会是动态数字」也是第三方在同一时期独立看到的。这条可以被证伪：如果三年后企业软件的计费单位仍然以席位为绝对主流、且没有任何计量公证机制出现，那这条就错了。
有条件的建议是「钉钉适合做这件事」——它确实依赖前提：数字员工的执行链路可计量（#393），组织图谱能提供权限和 Tools（本文第二节收窄后的那两样），Eval 能挂到岗位上（#384）。这三个前提不成立的场景——比如纯靠员工自觉用 AI、消耗散落在十几个工具里——这套定价方法照样落不了地。所以我不主张「钉钉的成本核算比别人强」，只主张「数字员工这个形态天然适配按工作计量，而钉钉在做数字员工」。
写在最后
回到开头 Claude Design 那张多米诺。界面被绕过，只是这件事的第一块牌。第二块是交付链条从项目制变成工程化生产，第三块是定价单位从人头换成工作。
而第三块牌推不动的原因，从来不是技术不够。技术早就够了——token 能计量，产出能验收，链路能归因。推不动是因为 「干完了」这三个字现在没人有资格签。
所以如果要把这篇文章压成一句话：AI 助手是给人多一双手，数字员工是给组织少一个人；而少一个人的前提是，有人敢在「干完了」那一栏签字。 签字的人是谁，比模型是谁，更接近这门生意的本质。
你见过哪家公司已经在按工作（而不是按席位）给 AI 收费了？他们怎么解决「谁来认定干完了」这个问题？欢迎留言讨论。