Hugo Zhu's Blog

前几天看到一条消息：Anthropic 内部很多人都在用一个叫 ELI5 的 skill，工程师 Thariq Shihipar（@trq212，Claude Code 团队）8 月 21 日把它发到了 X 上。我去翻了源码——anthropics/claude-plugins-community 仓库里那个 SKILL.md，321 字节，10 行，没有脚本，没有依赖：

---
name: eli5
description: Explain a topic like I'm a 5 year old. Use when the user types /eli5 or asks for a dead-simple picture explainer of how something works.
---

# eli5

Explain like I'm someone who knows nothing about this topic, using a HTML artifact with big pictures and few words.

Topic: $ARGUMENTS

看完我做了件有点自虐的事：wc -c 量了一下我自己天天在用的博客 skill。50693 字节，1078 行。 是 ELI5 的约 158 倍。

那一瞬间我有点心虚。是不是我这份东西，本质上就是一坨啰嗦？「skill 要短、要克制」这两年快成政治正确了，ELI5 又给它添了一把火。可我心虚了三秒就反应过来不对——这两份 skill 防的根本不是同一类失败，拿同一把尺子量，会两头都量错。

这篇想讲清楚一件事：Skill 该多长，由任务的「失败面」决定，不由极简美学决定。

9 月的一个深夜，我在翻 blog2 仓库里的一个文件，翻到有点不舒服。

skills/hugo-blog/SKILL.md，版本号 3.4.0，1078 行。第一次写它的时候只有几十行。中间模型换了好几代，这个文件一行没删，只加。加进去的每一行背后都是一次真实翻车——「Wan2.7 的 prompt 里不要写中文」「Gemini 的 landscape 必须是 1280x896，小了直接返回 400」「加粗标记内侧不能有空格」。

不舒服的点在这里：让我踩下这些坑的那几个模型，现在一个都不用了。但这 1078 行，一行都没作废。

我盯着它看了很久，意识到自己看的不是一个文件，是一条 loop 的沉淀物。

然后一个念头冒出来：模型训练是一个 loop，Agent 是一个 loop，人生也是一个 loop。 三个 loop 的结构完全一样——行动、观测、评估、更新。区别只有三条：反馈延迟多久、单次迭代多贵、状态能不能跨轮留下。

9 月初，我的数字员工「涌现」在一周里掉了三次链子。

它每天早上八点跑一轮「早读」：读公众号后台、读 GA、digest 小红书、更新 token 消耗、读 aibase——五步，预算一小时。8 月 31 日、9 月 2 日、9 月 5 日，三次吃了同一个兜底。前两次重启了事，第三次我让 opencode 做了一轮十五分钟的验尸：模型网关的机器名，被 /etc/hosts 里一行陈年映射和 DNS 搜索域联手坑了——解析结果里混进一条不通的 IPv6 路由，我常用的工具个个有回退所以毫无察觉，Agent 的运行时没有回退，当场死亡。整个排查过程我写成了 谁停掉了数字员工的早读。

事后回想，我当时的感受不是恼火，更接近于交学费的踏实。这个「早读」场景，技术上毫无炫技之处——定时任务、抓取、摘要、发消息，任何一个传统后端工程师一天就能搭完。但正是这个普通的场景，在过去几个月里每天给我生产真实的执行、真实的失败、真实的修复。我对 Agent 工程的大部分真实认知，不是从论文和 demo 里来的，是从这条 loop 里长出来的。

这让我越来越确信一个判断：Agent 应用工程师的核心竞争力，不是会不会调 Prompt、接 MCP、做 RAG，而是能不能建立一个真实的、持续运行的 Agent Loop。 而在选择做什么项目时，我会把一个指标放在非常靠前的位置：这个场景每天能给我多少次真实的执行反馈。

上个月我连写两篇拆解 DeepSeek Harness（dsh）：一切皆插件：DeepSeek Harness 的野心与收敛鸿沟 说它开源的不是工具，是运行时；一切皆插件：真正硬核的是三个细节 拆了注册即副作用、事件日志做脊柱、乱序完成按序写回这三个工程承诺。当时我的结论是「可以吹，但不必急着用」——预览版、破坏性变更写在官方文档里，日常编码不如用成熟的 Coding Agent。

几周后打脸了：我们把一支真实的钉钉数字员工团队装在了它上面。项目叫 DWH（DingTalk Workforce Harness），四个员工——通用助手 default、管理员 dev、HR 助手 hr、老板秘书 assistant——各自是一个独立的 dsh 进程，在钉钉里各管一摊、各有权限、互相平级。这篇讲为什么「不必急着用」的判断没错，但「怎么用」的答案错了：开源 Agent 运行时的正确用法，不是把它当产品直接用，而是把它当操作系统，在上面建一层「员工管理制度」。

上一篇 两个对手，同一套打法 里，我写 Grok Bot 和 Claude Cowork 两个团队怎么做产品，里面藏了一个我没展开的细节：主持人 Lenny Rachitsky 说，他已经把自己的不少用例从 Cowork 和 Codex 迁到了 Grok Bot 上——迁得非常快。

文章发出去之后，这句话一直在我脑子里转。媒体叙事是「桌面 Agent 是新大陆，用户圈地之后就不会再动」；可生态里最重度的用户、播客主持人本人，一个周末就把家搬了。

那么问题来了：用户从 Cowork 迁到 Grok Bot，代价到底大不大？

我的答案分两半：任务搬家便宜，关系搬家贵。一个用户能迁走多少，取决于他在这个产品里存放了什么。这篇文章用我自己做样本来拆——我给自己的数字员工「涌现」搬一次家，看看什么带得走，什么带不走；拆完你会发现，「带不走的东西」正好回答了第二个问题：AI 产品满足用户的哪三个任务，才能把他变成长期付费用户。

这两年我发给 AI Agent 的指令，措辞在悄悄变化。

以前是「做这个」：改一段代码、排一版格式、跑一个任务。动词是我的，判断也是我的——做什么、不做什么、做到什么程度算完，都是我想好了才发给它。

最近我注意到，越来越多的指令变成了「你觉得呢」。选方案 A 还是 B，这篇文章该不该发，这个候选人要不要约——问题的主语没变，但决定权在换手。

这不是我一个人的变化。AI 越强，这类指令就越自然：它确实比我想得快、比我看得全，多数时候比我想得对。顺着这个坡度滑下去，终点是一个没人愿意直面的问题：如果人把决策全部交出去，判断力会怎么样？社会又会怎么样？

我的答案是：末世版和乌托邦版都错。真正会发生的是分叉——而判断力，会变成新的健身。

1965 年 2 月 7 日凌晨，越共袭击了美军波来古基地，八名美国人丧生。几个小时内，国家安全顾问邦迪把一份备忘录推到约翰逊总统面前：持续报复。3 月 8 日，三千五百名海军陆战队员在岘港登陆。美国全面卷入越南战争，就是这么开始的。

值得注意的不是这个决定，是他们的推理方式。那间屋子里的人，被当时的媒体称为「最聪明的一代」。他们没有忽略历史——恰恰相反，他们是被历史喂得最透的一代人。会议上，洛奇大使明确援引 1938 年的慕尼黑协定，把胡志明的推进类比成希特勒的推进；后来学者在《Analogies at War》（普林斯顿大学出版社，1992）里复盘，在场的高级决策者们，包括邦迪，都确信这个类比是恰当的。肯尼迪本人大学时写过批评英国绥靖政策的荣誉论文，后来出版成书，书名就叫《英国为何沉睡》。「慕尼黑的教训」不是他们的盲区，是他们最深的信念。

十年之后：五万八千多名美军士兵、数百万越南人的生命、美国历史上最糟糕的一场对外战争。

最认真的历史类比，产出了最坏的决策之一。这不是要论证「历史没用」——恰恰相反，这篇要说的是，历史对大模型的价值极大，在训练和推理两端都是。但波来古之后那间椭圆办公室里的场景，指向我真正想讲的判断：历史是极好的律师，极差的法官。 而且它背后还有一个更反直觉的悖论：决策越大，历史的证据效力越弱。

9 月 8 日，Roman Ugarte 坐进 Lenny Rachitsky 的播客录音间，复盘他怎么在一个月里做出 Grok Bot。他是 Grok Bot 的产品负责人，之前是 Cursor 的增长负责人——加入时那家公司只有 15 人左右。

同一年的 4 月 23 日，Cat Wu 坐过同一个座位。她是 Anthropic 的 Claude Code 和 Cowork 产品负责人，工程师出身，中途还去风险投资行业待过一段时间。

这两个人是直接对手。Grok Bot 和 Cowork 抢的是同一批用户：想把知识工作整块交出去的人。Lenny 是 Grok Bot 的重度用户，也是他们 meetup 的合作方；他在节目里说，自己已经把不少用例从 Cowork 和 Codex 迁了过来——迁得非常快。

我把两场对谈的要点摊开逐条对了一遍，发现一件有意思的事：两个不同公司、做竞争产品、隔了四个多月开口的产品负责人，讲的是同一套打法。

不是相似，是逐条重合：原型优先于文档、亲手带早期用户上手、设计师直接提交代码、发布前大规模删功能。

两个对手独立收敛到同一套打法，说明这套打法不是某家公司的文化，也不是某个人的天才，而是结构性的东西。这篇文章把它拆出来。

一个 Bot 用三个多小时给我交了 676 行代码，我花二十分钟合并上线。

当晚我用手机打开自己的博客，按下搜索——白屏，等了几秒才出结果。

跟改之前一模一样。

它没写错任何一行代码。测试清单五条，条条跑通。架构选择比我自己能想出来的更干净。但我想要的那个「快」，它一点没解决——因为我从来没说清，我要的是哪个「快」。

昨天我做了一件拖了半年的事：把自己博客的搜索系统整个换掉了。

我没自己动手。我给一个 AI Bot 发了一句话：「搜索基于一个没人维护的组件，越来越慢，给我一个更好的方案。」三个多小时后它交回来一个 676 行的 PR，我花不到二十分钟验收，点了合并。

值得琢磨的是前面那半年。这件事我一直想做，但每次要动手就先算一笔账：看懂旧代码一天，设计新方案一天，改完测试再上线一天——三天工时，还可能把线上搜索搞坏。算完就觉得，下个月再说吧。

同一件事，换一种算法，「敢」就突然出现了。不是我变勇敢了。