Anthropic 给 Claude 装了一套个人操作系统

Claude's System Prompt Is Not a Prompt — It Is a Personal Operating System

前两天我拿到一份文件:Claude 最新旗舰模型 Fable 5.1 在 claude.ai 消费端的完整系统提示词。不是泄露的片段,不是网友总结的版本——是完整原文。

274,608 个字符,超过 4 万个英文单词。

大多数人听到「系统提示词」会想到一段开场白:「你是一个乐于助人的 AI,请礼貌、安全地回答。」我以前也是这个印象。但把这份文件从头到尾读完之后,我改变了判断:

这不是提示词,这是一套个人操作系统。

Claude’s System Prompt Is Not a Prompt — It Is a Personal Operating System

[Read More]

从会做 Agent 到制造 Agent:一个应用工程师的成长路线

From Building Agents to Manufacturing Agents: A Growth Path for Agent Engineers

今天和一个朋友聊天。他说自己做了一个非常精简的 Agent Harness,准备开源,让大家可以直接用。

我第一反应不是问他写了多少代码,而是问:

你看过 Pi Agent、OpenCode、DSH 吗?

他说,没有深入研究过。

那一刻我没有继续追问,但一个问题在我脑子里转了一下午:今天成为一个 Agent 应用工程师,真正重要的到底是什么? 是能够自己写一个 Agent Loop,还是能够把 Agent 真正做成一个有价值、能生产、能赚钱的产品?

这篇文章把那条成长路线完整画出来。

From Building Agents to Manufacturing Agents: A Growth Path for Agent Engineers

[Read More]

数字员工上岗半年,我在钉钉上的时间翻了一倍

AI Won't Build a New Entry Point — It Deepens Your Dependence on the Old One

半年前,我给自己上了第一批数字员工。上岗之前,我的想象是这样的:任务交给 Agent,我只管派活和收结果,我在钉钉上的时间应该大幅下降。

半年后,我打开自己的屏幕时间统计:我在钉钉上的时间没有下降——翻了一倍

起初我以为是个体差异。但和几位同样在带数字员工的同事交流后,发现大家的处境差不多:Agent 越多,人在 IM 里花的时间越多。

这让我必须把一个判断写下来:

AI 不会造出新入口,只会加深你对旧入口的依赖。

AI Won’t Build a New Entry Point — It Deepens Your Dependence on the Old One

[Read More]

评测集是一份没人签字的文件

An Unsigned Eval Set Is a Flywheel Without an Owner

最近读到一篇两万字的 Agent 自进化方法论,写得相当扎实。其中记了一条血泪教训:有团队在某个场景上连续 20 多轮自动迭代,效果一直不提升——最后发现根因根本不在配置层,而在工具层。20 多轮里,系统忠实地修 Prompt、改 Skill,每一轮都按评测信号在优化。

回头看,最惊人的不是根因藏得深,而是这 20 多轮里,没有一个人问过:这批评测 case 本身,选对了吗?

没人问,因为没人需要问——这份评测集没有主人。

这篇方法论(作者 yannisyang、ethanytzhou)把评测、记忆、落地、控制四个环节拆成飞轮:评测是眼睛,记忆是大脑,落地是手脚,人机协作是方向盘。四个齿怎么建、坑在哪、从零到一怎么落地,都讲了。它最有价值的一句话是:

大多数团队的问题恰恰在于:每个组件内部做得还行,但组件之间的「箭头」没有自动化。

飞轮的瓶颈不在齿,在齿与齿之间的通路。我完全同意——但沿着这句话再往下推一步,会发现一个这篇两万字没有回答的问题:

所有箭头里最上游的那一条——「什么叫好」——它的定义权在谁手里?

An Unsigned Eval Set Is a Flywheel Without an Owner

[Read More]

连奥特曼都改不掉复制粘贴的习惯

Even Sam Altman Cannot Break His Copy-Paste Habit

OpenAI 的创始人山姆·奥尔特曼,最近在一次专访里说了一段让我停下来的话:

现在有了 Codex,明明可以换一种办法工作,我却还在沿用以前的习惯。我不应该到处乱点,在不同的聊天软件之间复制粘贴,漫无目的地浏览邮件……然而,我的脑海里却根深蒂固地认为,做这些事情就是工作,就是高效。

注意这段话的主语。这不是一个对 AI 一知半解的传统行业老板,也不是一个拒绝新技术的保守派——这是做出 ChatGPT 和 Codex 的人,是这个世界上离 AI 最近的人。

他知道更好的办法。他手里就有那个更好的办法。他还是改不掉。

如果连他都这样,那「AI 会自然改变我们的工作方式」这个假设,就有必要重新审一遍了。

Even Sam Altman Cannot Break His Copy-Paste Habit

[Read More]

麦肯锡终于说了:Agent 也要绩效考核——但他们没说怎么考

McKinsey Says Agents Need Performance Management — But Not How to Measure Them

8 月底,麦肯锡的播客 McKinsey Talks Talent 里,主持人 Lucia Rahilly 抛出了一个很多公司都在回避的问题:Agent 进了核心工作流,谁来管它?

资深合伙人 Brooke Weddle 的回答很直接:「HR 管理的不再只是人类的绩效,现在还有数字员工。」 全球技术与 AI 负责人 Kate Smaje 接着把问题拆成了三问:

「我到底有多少个 Agent?谁对它们的绩效负责或担责?它们创造了多少价值?」

问完,她自己补了一句更狠的话:当她问企业「上次讨论非人类劳动力的绩效是什么时候」——「几乎没有组织能回忆起自己把这件事排上过议程。」

听到这三个问题的时候,我愣了一下——这不是新闻,这是我今年 3 月起就在博客里反复写的那一系列问题。麦肯锡用了整个 8 月,终于追上了这条线。

他们给出的答案也对:Agent 归使用它的业务负责人管,不是 IT,不是 CTO。 这和我在数字员工的第一准则不是可控性里推导的主管制,几乎是同一个结论的两条路径——他们从管理实践归纳,我从问责公理演绎,殊途同归。

但这份答案只答了一半。

[Read More]

Agent 开发者的工具箱:标准比清单重要

An Agent-First Toolchain — Criteria Matter More Than the List

前几天有人给我发了一份「2026 年 Agent 开发者工具箱」清单,整整 15 个名字:git、gh、docker、uv、node、pnpm、nvm、rg、jq、curl、fzf、just、direnv、python、go。分层清晰,还配了星级。

我顺手在自己这台跑 Agent 的机器上核对了一遍,结果很有意思:15 个里我只装了 7 个。

for t in git gh docker uv node pnpm nvm rg jq curl fzf tmux direnv just mise; do
  command -v "$t" >/dev/null && echo "$t: yes" || echo "$t: NO"
done
# generated by hugo AI

git、gh、uv、node、pnpm、rg、curl 在;docker、jq、fzf、tmux、direnv、just、mise 一个都没有。机器没罢工,Agent 每天照样在上面干活。

所以我没有急着去补齐那 8 个缺口,而是先问了一个更基本的问题:这份清单是按什么标准选的?是给人用的,还是给 Agent 用的?

这两个问题的答案,会导出两份完全不同的清单。

An Agent-First Toolchain — Criteria Matter More Than the List

[Read More]

数字员工的自我进化:从 Harness 开始,每天重复干同一件事

Harness RSI Runs on Production Data, Not Algorithms

最近读了一篇关于 Harness 自进化的报道,里面有个细节让我停下来想了很久。

停下来的原因,是我们自己也卡在这里:数字员工上线一段时间了,它好像变「顺手」了,但说不清是不是变「聪明」了。这个模糊感,恰好被报道里的三个数字点破。

报道里那家公司说(厂商自报口径):他们平台上 95% 以上的 Agent 被每天重复运行;在留存用户中,93.4% 的操作是系统自触发的;超过六成的自动化流程持续运行了一个月以上。

大多数人读到这三个数字,看到的是「这家公司用户很多」。我看到的是另一件事:这三个数字加起来,恰好是递归式自我改进(RSI)最稀缺的原料。

Harness RSI Runs on Production Data, Not Algorithms

[Read More]

江湖还是那个江湖,但选择可以更从容

The Jianghu Remains — But Your Choices Can Be Lighter Now

8 月 31 日,离职高发的异动日。下定决心的已经走了,还在犹豫的,犹豫到最后一刻。

今晚和一位同事吃饭,酒过三巡,他问我:你对未来怎么看?

我没给宏图大略,只说了几件我越来越相信的事。写下来,分享给所有觉得自己无从选择的朋友。

The Jianghu Remains — But Your Choices Can Be Lighter Now

[Read More]

从三小时到十五分钟:我把周报蒸馏成了一个 Skill

From Three Hours to Fifteen Minutes: Distilling My Weekly Report into a Skill

岗位真实,人名与数据已脱敏。这是一篇可以被复制的实践——文末有千问办公实操路径。

我是某条业务线的一号位,每周要向 CEO 汇报商业化、产品与组织三条线的进展。10 位直接下属,周报形态五花八门——有人发长文消息,有人甩一个文档链接,有人发文件附件;同一个指标,业务线和 BI 各有一个数,谁也不服谁。

上周日,我第一次让 AI 同事全程接管这件事。没有 SOP,没有模板,纯靠对话指挥:一个个群、一个个单聊地读,一份份总结、比对、入稿。从早到晚干了三个多小时,周报是交出来了,token 烧了上亿。

贵,但值——因为做完之后,我让 AI 把整个过程复盘了一遍: 哪一步是固定动作?哪一步踩过坑?哪个数字要过谁的口径? 然后把这些蒸馏成了一份 weekly-report 技能文档:固定坐标、模版结构、素材来源对应表、指标字典、历史教训,一条不落。

这周日,我只说了一句话:开始整理本周的周报。

AI 同事加载技能,按流程执行:读上周远端文档定结构、批量收集十个来源、报「已收/未交」清单、按字典压缩入稿—— 不到十五分钟,一份质量过关的周报草稿出来了,全是重点信息。

省下来的时间,我去做了真正值钱的事:写下业务、产品、组织面对客户与竞争的方向判断,预演 CEO 的追问,补上风险与决策请求,再把待确认的问题分发给责任人。下面是这份周报背后的五个细节。前四个发生在十五分钟里,第五个,是十五分钟和 AI 都替代不了的。

From Three Hours to Fifteen Minutes: Distilling My Weekly Report into a Skill

[Read More]