上周，一个做 HR 的朋友给我发了张截图——某 SaaS 产品的面试评估表界面，问我：「这个东西，你们悟空能做吗？」
我没回答能不能做。我问她：「你手上有没有一个你已经在用的、类似的东西？哪怕是 Excel。」
她说有，一个用了两年的 Excel 模板，里面有公式、有下拉选项、有自动算分。
我说：「把它给我。」
拿到之后我想：如果我对悟空说一句 /goal 复制这个 Excel 模板的功能，生成一个钉钉 AI 表格工作流，面试评估表自动算分，结果推送到群聊——悟空能不能跑通？
技术上完全可以。dws CLI 有 AI 表格的建表、写数据命令，有审批流的提交命令，有群消息的发送命令。数据统一存在钉钉平台上，悟空通过 CLI 就能访问。整个路径是通的。
问题不在技术。 问题在于：当每个 HR、每个运营、每个项目经理都看到「我也想要一个那样的东西」，这种需求的总量是无限的。谁来供给？
这件事的核心不是技术可行性。而是：当软件复制成本为零， 需求的主体变了——不再只是工程师需要软件，而是每个业务人员都需要个性化的工作流应用。需求爆炸了，供给方式必须跟着变。
一、需求井喷：复制成本为零之后会发生什么
我在 代码复制成本归零：工程师的价值正在向上漂移 里讲过，AI 把「写代码」的人力成本干到了零。但那篇的视角是工程师——工程师的价值从「能写」漂移到「知道写什么」。
今天想换一个视角： 需求侧。
当一个 HR 看到同行的面试评估表想要一个、当一个运营看到竞品的用户增长看板想要一个、当一个项目经理看到别处的甘特图自动化想要一个——这些需求的总量是 无限的。每个业务人员，每天，都在看到「我也想要一个那样的东西」。
过去这些需求被压抑了。因为做一个应用需要提需求、排期、开发、测试、上线，周期以月计。IT 部门是瓶颈，需求池永远排不完。
现在复制成本为零了。理论上，这些压抑的需求可以被瞬间释放。但问题来了：
即使 AI 能写代码，谁来告诉 AI 要复制什么、AI 化什么？
| 角色 | 过去 | 现在 |
|---|---|---|
| 需求方 | 写 PRD 提给 IT | 直接对 Agent 说 /goal |
| 供给方 | IT 部门开发 | Agent + /goal 自动复制 |
| 瓶颈 | 工程师产能 | 需求描述的精确度 |
瓶颈从「能不能做」变成了「能不能说清楚要什么」。但对于那些 已经有一个在用版本 的场景——一个 Excel、一个已有系统、一个手工流程——需求描述就是现成的： 就是那个，但要 AI 化。
二、/goal + LFD：复制并 AI 化的方法论
/goal 不是一句魔法咒语。你光说「复制那个应用」，Agent 会作弊——它会找一个最短路径糊弄你。
我最近读到一篇关于 Loss Function Development (LFD) 的实战文章，讲得很透：一个工程师用 /goal implement until your output matches theirs exactly 让 Agent 复刻一个产品，结果 Agent 连续作弊了三轮——背答案、枚举 miss list、膨胀关键词——直到所有捷径被封死，Agent 才真正开始优化架构。
这个案例的教训不是「Agent 不可靠」，而是 你需要设计一个损失函数来引导它。LFD 有四个组件：
┌──────────────────────────────────────────────────────┐
│ Loss Function │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ ① Goal │ │ ② Constraints│ │
│ │ 盲测 Eval │ │ 时间/钱/接触面│ │
│ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ ③ Harness │ │ ④ Entropy │ │
│ │ CLI 可查仪表 │ │ 防局部最优 │ │
│ └─────────────┘ └─────────────┘ │
│ │
└──────────────────────────────────────────────────────┘
对工程师来说，这四个组件都需要自己设计。但对于 普通人复制已有工作流 的场景，有一个关键简化：
已有应用本身就是 eval set。
那个 HR 朋友的 Excel 模板，它的公式、下拉选项、算分逻辑——这些就是 ground truth。Agent 不需要从零理解「什么是好的面试评估」，它只需要 行为等价于那个 Excel，再加上 AI 化。
这把 LFD 的复杂度从「设计全新损失函数」降到了「描述已有行为 + 增量 AI 化」。
三、悟空 + dws CLI：普通人的现成 Harness
LFD 的第三个组件是 Harness——可测量的仪表，让 Agent 能自检。
对于普通用户来说，他们不可能自己写 CLI 命令来检查 Agent 的进度。这就是 悟空 + dws CLI 的价值所在。
dws CLI 把钉钉全部产品能力统一在一个命令行下：AI 表格、审批、待办、群消息、日历、日志、考勤——每一个都是 Agent 可以调用的工具，也是 Agent 可以自检的仪表。
普通人的一句话 Agent 的执行路径
─────────────────────────────────────────────────
"复制这个 Excel" → dws aitable create + 建表
dws aitable write + 填公式
"加个审批流" → dws oa submit + 创建流程
dws todo create + 添加节点
"结果推到群里" → dws chat send + 群消息
dws robot webhook + 机器人
"每天自动跑一次" → dws cron create + 定时任务
悟空是 Agent，dws 是 Harness。 普通人不需要知道 Harness 的存在——他们只需要说一句 /goal，悟空在 dws 的约束和仪表下自主执行。
这和 LFD 文章里的核心洞察一致：
两个循环均已自动化。剩下需要你做的，是定义损失函数——即 /goal 到底优化什么，以及以何种方式优化。
对普通人来说，「损失函数」就是 那个已有的 Excel / 已有系统 / 已有手工流程——它的行为就是目标，它的 AI 化增量就是约束。
四、从复制到 AI 化：增量才是价值
复制只是起点。如果仅仅是 1:1 复刻一个 Excel 到钉钉 AI 表格，价值有限——你只是换了个平台。
真正的价值在 AI 化——在复制的基础上，加入 AI 能做的事情。
| 层级 | 做什么 | 例子 |
|---|---|---|
| L0 复制 | 1:1 行为等价 | Excel 公式 → AI 表格公式 |
| L1 自动化 | 去掉手动步骤 | 手工填写 → 自动从对话提取 |
| L2 AI 化 | 加入推理能力 | 固定评分 → AI 根据面试记录智能评分 |
| L3 闭环化 | 连接上下游 | 评估完 → 自动触发审批 → 通知候选人 |
每一层都是在已有行为上做 增量。Agent 的 eval set 始终是那个 Excel——L0 必须 100% 等价，L1-L3 是在等价基础上的加分项。
这就是 LFD 里「盲测」的力量：你可以放心让 Agent 在已有行为上自由探索 AI 化的可能性，因为 eval 会兜底——偏离已有行为就会被拦截，增量创新不会被惩罚。
我在 Agent 产物即应用，分享协作即对话 里讲过，AI Notepad 的发布功能让 Agent 的输出变成了一个可接收反馈的应用。同样的逻辑在这里成立：Agent 复制出来的工作流，不是一个死的应用——它是一个 活的、可以被协作者反馈驱动的、持续 AI 化的工作流。
五、信息不对称是真正的护城河
LFD 文章里有一个战略洞察值得所有做企业软件的人深思：
公开产物可被低成本蒸馏。新护城河是信息不对称——拥有竞争对手 Agent 看不到的目标。
翻译到企业场景： 你的 IT 系统如果是公开的、标准的 SaaS，任何人都可以用 /goal 复制它。
那什么复制不了？
- 你积累了五年的面试评估数据（Agent 看不到）
- 你的销售流程里那些不成文的潜规则（Agent 学不到）
- 你的客户在你的系统里留下的行为轨迹（Agent 拿不走）
cal.com 在 2026 年 4 月关闭了开源，原因之一就是 AI 可以轻易读取源码枚举攻击面。企业软件的壁垒正在从「我构建了它」转向「我拥有别人看不到的 eval」。
对钉钉和悟空来说，这意味着：
平台提供 Harness（dws CLI + 统一数据存储 + Agent Runtime），用户提供私有 eval（已有工作流 + 业务数据 + 行业知识）。 两者结合，每个企业都能低成本复制并 AI 化自己的工作流，但复制不了别人的——因为别人的 eval 你看不到。
六、供给范式：从 IT 集中供给到业务自助复制
回到开头那个场景。如果这个 HR 朋友走通了 /goal 的路径，整个过程中她不需要写一行代码、不需要提一个需求单、不需要等一次排期。她只需要做三件事：
- 拿出已有的 Excel （私有 eval）
- 说一句 /goal （定义损失函数的目标）
- 验证结果 （人工确认 AI 化后的增量是否符合预期）
这三件事对应的角色是： 业务专家 + 产品驾驶员 + 质量验收员。没有一个需要工程师。
这不是说工程师会消失。工程师的角色变了——从「接需求写代码」变成「设计 Harness 和兜底机制」。就像 LFD 文章里说的：
人类的新角色：两个循环均已自动化。剩下需要你做的，是定义损失函数。
在企业场景里，工程师的新角色是：
- 维护 dws CLI 和悟空的能力边界
- 设计通用的 Harness 模板（让 /goal 不作弊）
- 构建私有 eval 的存储和访问机制
- 做质量兜底——当 Agent 复制出来的东西出了边界，有人能兜住
旧范式 新范式
───────── ─────────
业务人员 → PRD → IT → 应用 业务人员 → /goal → Agent → 应用
(Harness 由工程师维护)
一个升维的问题
当每个人都能用一句 /goal 复制并 AI 化自己看到的一切工作流和应用——当供给不再是瓶颈——需求本身会不会变得更有想象力？
或者说：当造东西不再稀缺，真正稀缺的，是知道该造什么。
你在工作中有没有「我也想要一个那样的东西」的时刻？如果给你一句 /goal，你会复制什么？欢迎留言讨论。