2022 年 3 月 10 日，我写了一篇 Google Analytics 4 简介，从事件跟踪讲到导出 BigQuery，写得挺认真。
那篇文章发表前两个月，奥地利数据保护局裁定 Google Analytics 违反 GDPR；发表前一个月，法国 CNIL 跟上。我当时知道这件事，但没当回事——一个免费工具被欧洲监管盯上，离一个中国工程师的日常太远了。
四年多以后回头看，那两个月恰好是一个分水岭：一个平台用免费换来了整个互联网的行为观测层，然后看着这个观测层被主权一刀一刀切掉。 我今天要写的是另一件事，但它是同一个剧本的第二幕——只不过这一幕的主角换成了代码，而幕布在 2026 年 4 月 24 日已经拉开。
那天 GitHub 改了一个开关的默认值。
上个月一个 CIO 给我看他们的 AI 成果清单，讲得很顺：接入了多少个 Agent、开了多少智能体账号、买了多少 token、做了几场全员培训。我听完问了他一句：「你们每天真实发生的业务里，有多大比例是 Agent 参与完成的？」
他停住了。停了几秒，说：「这个我们没统计过。」
这不是个例。绝大多数企业的 AI 成绩单，记的都是投入项——买了多少、接了多少、开了多少。而真正决定 AI 能不能产生业务价值的那个数字，没人算过。
通用 Agent 之后，企业要解决的，不是再做一个更聪明的 Chat，而是把 AI 真正嵌进每天发生的协同工作流。
过去企业数字化的路径大致是：
业务流程 → 表单 / 审批系统 → 人来操作系统
# generated by hugo AI
AI 时代正在变成：
业务目标 → Agent 理解与执行 → 人做判断与审核
# generated by hugo AI
所以引入通用 Agent 只是第一步。真正的问题是：你的企业有没有一个能让 Agent 进入、理解、执行、反馈、持续优化的工作流载体。 没有载体，Agent 再聪明也只是停在对话框里。
今年 4 月 17 日，Anthropic 上线了 Claude Design，直接对着 Figma 和 Canva 打。这件事在产品层面不算新闻——又一个 AI 生成界面的工具。真正值得注意的是它绕过的是什么：它让一部分设计工作不再需要打开 Figma。
OpenRouter CEO Alex Atallah 在那场访谈里的判断比我狠：他把 Claude Design 看作一种战略动作，「它未必立刻带来巨额收入，却能让设计团队在组织内部更关心 Anthropic 模型」。同时他也诚实地补了一句——从 Figma 公开的经营数字看，它表现依然很好。
两句话放一起，才是完整的事实：被绕过的那部分工作，还没大到能动财报。但方向已经定了——软件的用户界面，正在从「给人操作」变成「给 Agent 调用」，而当人不再打开界面，按人头卖软件的那本账，就开始算不动了。
这篇文章想说的是：数字员工和「给 SaaS 加个 AI 助手」的差别，不在功能强弱，在交付结构和定价单位。而定价单位真要换过去，缺的不是技术，是一个签字的人。
月底，一个用了大半年 AI 的老板跟我抱怨：他知道这个月公司在 AI 上花了多少钱，云账单上写着。但他答不上来另一个问题——这笔钱是哪个团队、哪个流程、哪个数字员工花掉的。
「账单是一整笔，」他说，「就像食堂一个月的米面油采购单，你知道总数，但说不出哪道菜亏本。」
这不是个例。绝大多数企业的 AI 支出，今天都停在「一笔云账单」的粒度上。而我在 OpenRouter CEO Alex Atallah 最近的一场访谈里，看到他给出了一个完全不同的判断——他说这是「很反常、却很少有人讨论」的现象：
「过去员工的成本主要是固定薪酬……未来，员工成本会是动态数字，与每个人是否有效地使用昂贵或廉价模型有关。管理者仍要正常评估员工的效率和产出，但也可以把效率和 AI 使用成本放在一起看。」
换句话说：AI 的成本，正在从「一笔 IT 预算」变成「一份人力成本」。 未来每个员工——尤其是每个数字员工——都会带着两份成本单：一份是薪酬，一份是 token。
三个月前，一个做汽车零部件的朋友跟我吐槽：他们花大半年选的「国内最好的大模型」，搭了三个月的质检 Agent，上线两周被业务部门集体退货。我在 AI to B 的最后一公里 里记下了他那句话：「我们的 AI 项目，死在了数据治理和系统对接上——这两件事，跟模型半毛钱关系都没有。」
那是一次个案级的抱怨。今天，我看到了一份系统级的判决书。
公众号 REIVAX.io 发了一篇文章：《AI 落地传统企业：赋能个人、接管流程，还是造工具？》。作者自述在传统制造企业做数字化，把 AI 进入企业生产链条的方式分成三种模式，然后逐一裁决哪种能落地。这是我少见的 需求侧第一人称 的 AI 落地分析——不是厂商写的，不是咨询顾问写的，是那个要为项目成败负责的人写的。
判决结果出乎很多人意料：制造业用脚投票选中的那个模式，业务流程运行时没有大模型。
TikTok 的 SRE Salman Munaf 最近有一场演讲，开场问题问得很漂亮：
你的 AI Agent 调用退款接口，网络超时了。那退款到底成功没有？
他的答案是：超时从来不意味着失败，而意味着「未知」。Agent 遇到失败的第一反应是重试，没有请求 ID、幂等键和状态查询，这个本能就会把一笔退款退成两笔。整场演讲的论点一句话概括：模型一旦开始调用外部服务，问题就从模型问题变成了分布式系统问题——几十年前命名过的故障模式全部回归，SRE 工具箱必须整体搬进 Agent 架构。
我同意。但我想在他的问题后面再问一句：
就算退款成功了——那笔退款，退得对吗？
这两个问题之间的距离，就是这篇文章要讲的东西。
上周和一位研发负责人吃饭，他刚读完 Anthropic 那份《AI-Native SDLC Playbook》，兴奋又发愁。兴奋的是「原来代码不再是瓶颈这件事，连 Anthropic 都认了」；发愁的是——
「intent.md、spec.md、plan.md、三层控制、持续 Evals……这套东西我要是从零搭，得搭多久？我团队现在连个像样的需求管理系统都还在和 Jira 打架。」
我说，你可能不用搭。你已经有载体了：你的 GitHub Issue。
这篇文章写给研发团队 Leader，讲的是怎么把 playbook 那套六阶段闭环，落在你 今天就在用 的 GitHub 上——不新建系统、不加预算、不改变团队习惯。需要说明：下面那个贯穿全程的需求是 示意 walkthrough，用来把机制讲透，不是某个团队的真实战报；机制本身（Action 触发、产物链、门禁）都是 claude-code-action 和 GitHub 的原生能力，可直接照搬。
我的钉钉数字员工每个月偶尔会抽下风：「⚠️ 暂时无法处理你的消息，请稍后再试。」，往往重启一下就好了。今天我让 opencode + GLM-5.3 排查了下这个问题。
十五分钟后，它把案子破了。凶手很狡猾：藏在三份完美证词背后，还顺走了我的 /etc/hosts 当人质。
xAI 的 Grok Bot 发布页上，留着一条来自运营岗用户 Emma 的感言（译）：
「刚开始的时候，我每 15 分钟就要去查看一次 Bot，事无巨细地盯着它——直到它反过来问我，为什么我总是问这么多问题。现在我放手让它自己干，它反而越用越好。」
这可能是「数字员工」这个产品形态目前拿到的最好背书：不是一个等你提问的工具，而是一个你可以把工作交出去、然后转身去干别的事的队友。
但同一页往下翻，还有一行写给企业用户的小字：加入 waitlist。
喊得最响的「可以把真实工作交给它」，到了企业门口，只换来一句排队等候。这个反差值得认真对待：Grok Bot 上线 24 天，验证了什么？它又到底卡在哪？
先说结论： Grok Bot 验证了「持续角色」这个产品形态，但企业要的是「岗位」。从角色到岗位，差的最后一段不是模型能力，而是组织基础设施。 而这一段，恰恰是企业现在就应该开始在钉钉里上岗数字员工的原因。
写给 Agent 应用工程师。案例是这个仓库的
docs/runbook/：一条自动抄录与 Claude Code 的每一轮交互、再提炼成三份签入文档的管线。这篇讲三件事：它值在哪、怎么做的、以及 那份「提炼契约」里有哪些可以直接抄走的规矩。
这套 runbook 最大的价值不是「有了历史记录」—— 那部分靠会话 transcript 本来就有， 不用额外做任何事。它干的是一件更特殊的活：把「为什么现在的代码是现在这样」从某个 人的脑子里搬到版本库里，并且用机器去逼它对齐提交历史。
CLAUDE.md 自己写着这条链路的痛苦：「改动前先知道为什么是现在这样，否则很容易改回去」。
这个仓库改回去的代价特别高 —— 它有一串静默失败模式：eval 的 answer 闸门一旦放宽，
分数一夜之间虚高接近满分；泄漏闸门漏扫中文路径，整片文档静默地不在检查范围内；
--flatten 丢一个标记位，防自环就失效。每一条都是「当时为什么这么写」一旦丢了，
就会被「顺手改回正常」重新放出来的东西。而这些为什么大概率不在代码里，也不在任何
issue 里。
