/goal 复制一切:当软件复制成本为零,谁来满足井喷的需求

When replication costs zero, the bottleneck shifts from building to defining what to build

上周,一个做 HR 的朋友给我发了张截图——某 SaaS 产品的面试评估表界面,问我:「这个东西,你们悟空能做吗?」

我没回答能不能做。我问她:「你手上有没有一个你已经在用的、类似的东西?哪怕是 Excel。」

她说有,一个用了两年的 Excel 模板,里面有公式、有下拉选项、有自动算分。

我说:「把它给我。」

拿到之后我想:如果我对悟空说一句 /goal 复制这个 Excel 模板的功能,生成一个钉钉 AI 表格工作流,面试评估表自动算分,结果推送到群聊——悟空能不能跑通?

技术上完全可以。dws CLI 有 AI 表格的建表、写数据命令,有审批流的提交命令,有群消息的发送命令。数据统一存在钉钉平台上,悟空通过 CLI 就能访问。整个路径是通的。

问题不在技术。 问题在于:当每个 HR、每个运营、每个项目经理都看到「我也想要一个那样的东西」,这种需求的总量是无限的。谁来供给?

[Read More]

工作流即软件,软件即 Agent:AI Coding 的真正战场

The next wave is not building new systems faster — it is encoding proven SOPs into digital workforce

上周和一个做制造业的朋友吃饭。他的工厂有一条产线质检流程,沉淀了八年的 SOP,写在 47 页 Word 文档里,涵盖了从来料抽检到成品出货的 23 个检查节点。

他说:「这套流程是我们最值钱的资产之一。但执行全靠人——培训一个质检员要三个月,离职率 30%,新人上来又得重新学。」

我问他:「你想过把这套 SOP 变成 AI 驱动的工作流吗?」

他愣了一下:「谁来帮我做这个?我手下的 IT 团队连 ERP 都维护不过来。」

这就是当下最大的供需错配: 企业最有价值的资产是沉淀多年的 SOP,但没有人把它变成可执行的数字员工。

[Read More]

Loop Engineering:AI Agent 工程的第五层

From Prompt to Goal — the human defines the finish line, the agent finds the path

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 工程的一次范式跃迁。

Loop Engineering 五层演进

[Read More]

VOC 闭环:Windows 用户打不开悟空,AI 怎么用 4 小时从报错到发版

From VOC Signal to Code Fix — Building AI-Native Enterprise SOP

知识管理有四个值得做的企业场景,其中「企业 SOP / 最佳实践沉淀」看起来最不起眼——知识静态、更新慢、容易退化成高级搜索、用户日活偏弱。

但如果你换一个角度看,SOP 沉淀的真正价值不是「把经验存起来」,而是 把经验变成可执行的系统行为

这篇文章用一个完整案例来说明:一位 Windows 用户打开悟空发起任务,悟空报错「任务执行环境准备失败」,到 AI 定位根因、修复代码、验证、发布,全程 4 小时。每个环节 AI 做什么、人做什么、知识如何在这个过程中自然沉淀。

[Read More]

别再手动整理用户反馈了:把 VOC 变成一条自动化生产线

从原始用户声音到产品 Backlog,一套可落地的端到端自动化流水线设计教程

每家公司都说"以用户为中心",但 90% 的用户声音(Voice of Customer, VOC)最终的归宿是——躺在某个 Excel 表里,等着某个产品经理"有空的时候"去翻一翻。

问题不是团队不重视用户反馈。问题是:从原始反馈到可执行的产品动作之间,隔着太多手工活。 收集、清洗、分类、归因、优先级排序、写进 Backlog——每一步都在消耗人的精力,而人的精力是有限的。

这篇文章是一个完整的教程:如何用 AI + 自动化工具,把 VOC 变成一条可执行的生产线——从原始数据采集,到最终输出结构化的产品需求,全程自动。

[Read More]

别用同一把尺子量所有 Agent:按行业和岗位设计评测体系才是正经事

通用任务型 Agent 评测的核心矛盾——以及一套可落地的分层评测框架设计

上个月参加一个 Agent 产品的内部评审,产品经理拿出一张 benchmark 表格:准确率 92%、响应时间 1.2 秒、幻觉率 3%。数字很漂亮,领导很满意。

然后我问了一个问题:“这个 92% 的准确率,是在什么任务上测的?”

回答是一组通用 QA 数据集。

我又问:“你的目标用户是电商运营,你有没有用电商运营真实工作场景的任务来测?”

会议室安静了五秒钟。

这就是今天 Agent 评测的核心矛盾:我们在用"通用考试"的成绩来预测"专业岗位"的表现。 这就像用高考数学成绩来判断一个人能不能当好外科医生——逻辑上不成立,但大家都在这么干。

[Read More]

企业级 AI 必须设计成出错后可以追责到人

从'AI 做的'到'谁让 AI 这么做的'——构建可追责的 AI 系统

上周一个真实案例:某电商公司的 AI Agent 自动调整了 2000 个 SKU 的定价策略,导致部分商品以成本价以下售出,一天亏了 80 万。复盘会上,所有人面面相觑——

运营说:“我没动过,是 AI 自动调的。” 技术说:“模型输出没问题,是数据源有异常。” 数据团队说:“数据是实时抓取的,跟我们无关。”

没有一个人为这 80 万负责。

这不是个例。当 AI 从"辅助工具"升级为"执行主体",一个被企业严重低估的问题出现了:出了事,找谁?

[Read More]

To B Agent 失败的根本原因:不是能力问题,是没有把 Agent 变成默认路径

从工具赋能到职责替代——为什么建议型 Agent 注定失败,以及电商场景的破局之道

回顾过去两年,无数 To B Agent 项目的墓碑上都刻着同一句话:“技术很好,但业务没用起来。”

技术团队困惑——模型能力明明够了,准确率也达标了,为什么运营就是不用?是培训不够?是界面不好?是 Prompt 没调好?

都不是。真正的原因是:你给了运营"用不用随便"的选择权。而只要有选择权,理性人就会选择不用。

[Read More]

别再卷模型了:To B Agent 创业,用户反馈才是生死线

模型训练已成系统工程,单点突破不再构成壁垒——能替代初级岗位的 Agent 产品,靠场景数据和反馈闭环赢得市场

2026 年,一个事实已经无法忽视:模型训练不再是一项研究活动,而是一项系统工程。

预训练需要万卡集群和 PB 级数据管线,强化学习需要奖励模型和 RLHF/DPO 的工程化流水线,推理优化涉及量化、蒸馏、speculative decoding 等一整套工具链,Agent 能力构建则横跨 function calling、长上下文、规划与工具使用的多维调优。任何一个方向的突破,如果不能在其他环节配合落地,就只是一篇论文,不是一个产品。

这意味着什么?模型本身正在变成标准化基础设施。 就像今天没有哪家 SaaS 公司拿"我们用了 PostgreSQL"当竞争优势一样,未来也不会有哪家 Agent 公司仅靠"我们微调了一个更好的模型"赢得市场。

那么 To B Agent 创业的制胜变量到底是什么?

[Read More]

当钉钉变成命令行:办公协同 Skill 的 Token 交付时代

钉钉 CLI 化开放让通用办公技能成为 AI Agent 的标准装备——过去靠定制软件解决的个性化需求,现在用 Token 就能交付

软件行业有一个永恒的矛盾:标准化产品满足不了个性化需求,定制开发又贵得离谱。每家企业都想要"适合自己的办公系统",但 SaaS 只能给你 80% 的功能,剩下 20% 要么忍着,要么花十倍的钱去定制。

钉钉的 CLI 化开放正在改变这个游戏规则。当钉钉的消息、日历、审批、文档、通讯录等能力都可以通过命令行接口被 AI Agent 直接调用时,一个新范式浮现了:过去需要写代码、做定制、走项目的办公需求,现在可以用自然语言描述,由 AI 用 Token 来交付。

[Read More]