上周，一个做 HR 的朋友给我发了张截图——某 SaaS 产品的面试评估表界面，问我：「这个东西，你们悟空能做吗？」
我没回答能不能做。我问她：「你手上有没有一个你已经在用的、类似的东西？哪怕是 Excel。」
她说有，一个用了两年的 Excel 模板，里面有公式、有下拉选项、有自动算分。
我说：「把它给我。」
拿到之后我想：如果我对悟空说一句 /goal 复制这个 Excel 模板的功能，生成一个钉钉 AI 表格工作流，面试评估表自动算分，结果推送到群聊——悟空能不能跑通？
技术上完全可以。dws CLI 有 AI 表格的建表、写数据命令，有审批流的提交命令，有群消息的发送命令。数据统一存在钉钉平台上，悟空通过 CLI 就能访问。整个路径是通的。
问题不在技术。 问题在于：当每个 HR、每个运营、每个项目经理都看到「我也想要一个那样的东西」，这种需求的总量是无限的。谁来供给？
[Read More]上周和一个做制造业的朋友吃饭。他的工厂有一条产线质检流程，沉淀了八年的 SOP，写在 47 页 Word 文档里，涵盖了从来料抽检到成品出货的 23 个检查节点。
他说：「这套流程是我们最值钱的资产之一。但执行全靠人——培训一个质检员要三个月，离职率 30%，新人上来又得重新学。」
我问他：「你想过把这套 SOP 变成 AI 驱动的工作流吗？」
他愣了一下：「谁来帮我做这个？我手下的 IT 团队连 ERP 都维护不过来。」
这就是当下最大的供需错配： 企业最有价值的资产是沉淀多年的 SOP，但没有人把它变成可执行的数字员工。
[Read More]昨天晚上，我在 AI Notepad 里写完一篇技术笔记，点了一下「📢 发布」，3 秒后拿到一个 URL：https://hugozhu.site/notes/p/bbzH9XEA。
我把链接丢到钉钉群里。10 分钟后，同事在页面上选中一段话，点「📝 批注」写了句：「这里是不是可以加个 error handling 的例子？」这条批注没有变成一条消息淹没在群聊里——它被存进了数据库，等我对悟空说「看看读者怎么说的」，AI 就把所有批注拉出来，当作下一轮优化的上下文。
这不是一个笔记应用的 feature。这是一种新的协作范式： Agent 产物即应用，分享协作即对话。
4 月底，OpenAI 发布了 Codex CLI 0.128.0。更新日志里藏着一句话：「Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls.」几乎同一时间，Claude Code 也上线了 /goal 指令。Greg Brockman 在推特上写了一句：「codex now has a built-in Ralph loop++.」
大多数人把这条更新当作又一个 feature flag 滑过去了。但如果你仔细拆解 /goal 的设计，会发现它代表的不是「又一个功能」，而是 AI Agent 工程的一次范式跃迁。
6 月 9 日下午，我对 AI 说了一句「分析下本项目」。
4 秒后，它给了我一份完整的项目分析报告：13 个 JS 文件、6773 行代码、技术栈拆解、架构特点、功能清单。然后我说「在登录页面加个多语言切换」，它改了 3 个文件，跑了测试，commit，push，部署。全程我没打开过编辑器。
这不是一个 demo。这是一个跑在生产环境的全栈应用——带 CRDT 实时协同编辑、PWA 离线支持、三语国际化、OAuth 登录、AI 代理 Edge Function。35 次 commit，从 2 月到 6 月，每一行代码都是 AI 写的。
上个月有人问我一个问题：「我已经有 LLM-as-Judge 做 eval 了，能不能用它来自动优化 Agent 的执行路径？在不降质量的前提下，找到最省钱的轨迹，然后让 Agent 记住？」
这个问题的答案值得展开。答案是能，而且这可能是当前 Agent 优化里最值得投入的方向。但大多数团队理解错了「优化」的对象。
周一早上 9:30，一个 5 人 Scrum 团队的钉钉群里，AI 表格自动推送了一条晨会摘要：
📊 今日待办 7 项 （P0×2 / P1×3 / P2×2）
⚠️ 发现 3 个支付模块 bug 集中在支付网关，关联上周五 v2.3.1 发布。建议优先处理 #BUG-042，指派给 @张三（支付模块 owner）。
🔗 需求 #REQ-015 与 #BUG-039 存在依赖关系，建议先完成 bug 修复再启动需求开发。
工程师张三看到这条消息，点进 AI 表格，看到 AI 给出的修复方案：「参考支付网关 v2.3.0 的超时配置，建议在 PaymentClient.java:128 添加重试策略，预计 30 分钟」。他结合自己的经验判断，觉得方案基本靠谱，但超时时间应该更短。改了参数，40 分钟搞定。CI/CD 跑完，AI 表格自动更新状态，群里推送：
✅ BUG-042 已修复（张三，40 分钟）→ 已部署 staging
这不是假设。用钉钉 AI 表格 + 群沟通 + dws CLI，这个工作流的每个环节今天都能搭出来。下面拆解怎么搭。
上周我写了一篇 LLM 自动化 vs RPA：省的不是智能，是编排成本，提了一个「探索-编译-执行」的三层架构——LLM 先探索网页、找到可行路径，然后编译成代码，后续直接执行。
写完没几天，微软研究院发了 Webwright，几乎就是这套思路的学术验证。但让我意外的不是它验证了三层架构，而是另一个发现： harness 本身可以薄到离谱。
整个系统只有 ~1000 行代码，三个模块，没有 multi-agent 编排，没有复杂的动作空间设计。它给模型的东西只有一个——terminal。
2026 年，深圳的 OPC（一人公司）政策让无数人跃跃欲试。一个有跨境电商经验的运营，配上 Claude Code + Cowork + 几个 AI Agent，就能在两周内搭起一套独立站、自动生成多语言详情页、定时跑竞品分析、自动联系 TikTok 达人。总投入不到 2 万块人民币。
这听起来是梦想照进现实。但亿邦动力最近的一篇调研揭示了一个残酷的侧面：不少跨境卖家用 AI 工具组合自建了工作流，觉得可以替代传统服务商，结果发现「企业是不允许出错的」——AI 在单点任务上表现惊艳，但在需要稳定执行的长链路中，结果波动、环境依赖、交互异常等问题层出不穷。更关键的是： 这些工具解决了执行效率问题，但没有解决方向判断问题。
Anthropic 在今年 5 月发布的一份 34 页创业手册里，有一句判断我反复回味：
上周，一个同事在悟空里问了一句「上周日活多少」，Agent 自信地返回了一个数字：精确到个位，格式漂亮，SQL 语法无懈可击。唯一的问题是——它用了一张已经废弃 3 个月的旧表。
没有人发现这个错误。因为数字「看起来对」。
这就是 Anthropic 在官方博客《How Anthropic Enables Self-Service Data Analytics with Claude》里描述的核心困境。我第一反应是「这不就是自然语言查数吗」。但读完全文，我发现自己错了——Anthropic 真正在做的，不是让业务人员用中文写 SQL，而是把整个数据工程的范式从「给人看」重构为「给 Agent 看」。
Anthropic 原文里最刺痛我的一句话是：
The initial elation of liberation from ad-hoc requests turns into dread with the realization that this setup separates stakeholders from the underlying infrastructure, documentation, and expertise that previously steered them toward carefully curated datasets.
翻译成大白话：你刚把 Claude 接上数据仓库，业务方欢呼终于不用找你写 SQL 了；但很快你会发现，他们问出来的问题越来越离谱，因为 Agent 失去了原来数据团队通过文档、培训、代码审查建立的「认知护栏」。
这不是技术问题，是 数据产品的用户变了。
[Read More]