Claude Code没有"魔法
本文基于 InfoQ 对 Daisy Hollman（Anthropic Claude Code 团队，主导插件与 Agent 设计）在 NDC Copenhagen 演讲的整理。Daisy 曾在 C++ 标准委员会深耕近十年并担任两年主席。
核心观点速览
- 如果 Claude 不能做所有你能做的事，它就无法和你一起做你的工作。 给模型访问你完成工作所需信息的权限，不是要取代你，而是成倍放大你。
- 定制化就是知识——弥合模型天生所知与团队所知之间差距的唯一手段。
- 钩子是唯一真正能扩展的插件抽象：不匹配就不注入，只在触发时才往上下文里放东西。
- 2026 年的核心转变：从"把信息输入模型"转向"把信息从模型输出给用户"，人的注意力才是系统中最小的盒子。
从聊天机器人到 Agent
Agent 这个术语的由来本身就是一条演进路径：从零次工具调用，到一次，到几次，再到某个时刻模型有了足够的自主性，我们才管它叫 Agent。
编码 Agent（Claude Code、Codex、Cursor）本质上就是 Agent，只不过给的工具是普通程序员用的：文件编辑、CI、跑代码、编译——基本都能归入 shell 命令。但工具调用原始得令人震惊：模型写 JSON，Harness 执行，结果塞回上下文窗口紧跟其后的位置，整个机制就这么简单。
Claude Code 的编辑工具 schema 是个纯粹的查找替换——没有光标，没有选区，没有引号转义，旧字符串必须逐字节匹配。用前端类比的话，这相当于你只能用 String.prototype.replace() 做 IDE 级别的代码编辑，连 codemod 都不如。但模型在这方面的表现已经好得惊人：Daisy 让 Claude Code 自己生成嵌套引用旧幻灯片 JSON 的新幻灯片，整个过程中一个 token 都没错。
上次看到字符串替换错误，大概是在 2025 年 2 月或 4 月。模型已经远远超越了那个阶段，因为这是很容易训练的东西。
METR 的"Agent 摩尔定律"图表显示：模型能以 50% 成功率完成的任务时间跨度，大约每四个月翻一番。这个趋势在 2026 年初开始停滞——过了 Opus 4.6 之后，"什么算作 16 小时任务"的误差范围已经太大了。但 Daisy 的判断是：如果你在七八十年代打赌摩尔定律会趋于平稳，你的处境会和当时不打赌的人截然不同。这个趋势至少还会再持续一两年。
Mozilla 基金会四月的数据更具冲击力：使用最新模型在一个月内修复的安全漏洞数量，比过去 15 个月修复的总和还多。
为什么要定制化
如果我们在朝 AGI 前进，模型应该是普遍智能的，为什么还需要定制？三个理由：
- 模型需要访问完成工作所需的东西——开箱即用的 Claude 只能看到一个代码仓库和一个 shell，默认甚至不能走出启动文件夹。
- 模型需要了解你公司的全部机构知识——代码库 Conventions、机构记忆、两个季度前尝试过但从未见天日的事情。
- 模型必须有工具去获取这些。
大多数专业软件工程并不存在于源代码里。编程是关于源代码的，但软件工程涉及的远不止编程。
Daisy 给了一个很有实操感的建议：试着离开终端，做一整天的工作。如果你收到 Slack 消息却无法通过告诉 Claude 该说什么来回复，如果你遇到 CI 失败却需要手动把错误信息复制粘贴到 Prompt 里——那你在替模型做事，而不是模型在替你做事。
定制化的本质是上下文学习（In-context learning）——就是文本文件。模型权重在发布那一刻就被冻结了，随着微调接口逐渐收缩，几乎所有定制化都发生在文本层面。这对程序员来说是个好消息：你不需要懂 LLM 权重的数学原理，只需要会操控文本。
Claude 现在工具调用的方式，差不多相当于 Unix 的 ED 编辑器。从 ED 到 VS Code 之间的巨大鸿沟，就是机会所在，而这一切都发生在文本空间里。
红色波浪线与反馈循环
模型拿到的是纯文本，得不到 IDE 里那种富文本反馈——变量不存在时的红色波浪线、类型错误的即时提示。Claude Code 的解决方案是 post tool use hook：工具调用执行后，把你提供的信息作为工具响应块的一部分附加进去。
关键洞察：让 Agent 在你代码库里表现更好的最快方式，不一定是更聪明的模型，而是更紧密的反馈循环。 尽早告诉它犯了错，而不是等到编译时。而且这些脚本大部分你早就有了——你以前就是靠它们来鼠标悬停查看红色波浪线的。
用 React 类比：这就像把 eslint-loader 的 fix: true 从 webpack 编译阶段提前到了 onSave 钩子——反馈延迟从分钟级降到毫秒级，开发体验完全不同。
工具分两种：
- 弥补智能不足的工具：给初级工程师用的护栏，等他们成长后就得换一套。
- 随智能一起扩展的工具：能跨越级别，因为高级工程师偶尔也会犯这些错，但他们知道什么时候不是错误。专注构建第二种工具。
上下文窗口是一个盒子
上下文窗口是模型为了预测下一个 token 所能看到的那一组 token——有限的、固定大小的。过去一年模型能力爆炸式增长，但上下文窗口的大小没变过：2024 年底出现第一批 100 万 token，2025 年 2 月最前沿是 100 万 token，现在还是 100 万 token。
我注意到很多"软件工程师"对"上下文工程师"这个头衔有抵触情绪。这两件事其实是同一件事。
定制化的核心原则：零开销原则——不为你不用到的东西付费。 你不能天真地把所有东西都倒进这个盒子里。
Daisy 用了一个绝佳的类比：这就像在 Arduino 上跑 npm。 电脑上的包管理器可以处理菱形依赖冲突——直接导入两个不同版本的库就行。但定制上下文时做不到，你必须智能地判断哪个更相关。
另一个硬约束是 KV 缓存。LLM 的 next token 预测要求前面所有 token 保持一致，否则缓存失效，预测成本贵 10 倍。Cursor 早期在 Cursor Rules 上就吃过这个亏——用 LRU 缓存策略动态换入换出规则，结果成本高得离谱。
选择可扩展的插件抽象
如果有 5000 个仓库，每个都想提供三四个 Skill，会怎样？
| 抽象 | 扩展性 | 代价模型 |
|---|---|---|
| MCP 服务器 | 差 | 工具名称+描述+schema 始终占用系统 Prompt |
| 工具搜索 | 略好 | 先加载名称，按需搜索，但仍难扩展 |
| Skill | 中等 | 正文按使用付费，但描述始终加载 |
| 子 Agent | 较好 | 上下文外执行，只返回摘要 |
| 钩子（Hooks） | 最好 | 不匹配不注入，零上下文开销 |
钩子是唯一真正能扩展的抽象。 如果你在做 Rust 项目，10 个 JavaScript 相关的 Skill 仍然要付费（描述在系统 Prompt 里），但 10 个 lint JavaScript 的钩子会立刻发现你没在写 JavaScript 然后退出——你只为 CPU 资源付费，而 CPU 比上下文空间宽裕得多。
CLAUDE.md 为什么不适合作为插件抽象？因为它在"不为没用到的功能付费"这件事上是最糟糕的——如果允许插件在每个上下文最开始无条件注入大量文本，就会被限制在同时只能激活五到十个插件。它在实现端成本太低，但在使用端成本太高。
Skill vs 子 Agent 的关键区别：Skill 是上下文内的，子 Agent 是上下文外的。 Skill 把描述展开到自己的上下文窗口里；子 Agent 展开到独立上下文窗口，只返回摘要。
多 Agent 工作流
要扩展规模、提速的唯一方式就是同时做多件事。能舒服地同时管理 20 个 Claude，工作量差不多是管理 5 个时的 4 倍。
- Git worktrees：每个会话放到不同 worktree，各 Claude 不互相踩脚。Daisy 的设置从 A 排到了 Z（16 个常驻 worktree 已经不够用了）。
/color：给每个 Agent 标注颜色——非色盲人类回忆颜色相关事物比回忆文字更快。- Agent 团队：
Send message工具让 Claude 能跨会话通信，可以委派任务也可以平级分享。 /loop：给模型用的 cron 命令，可以安排消息每隔 10 分钟自动出现，还能自行关闭。解决模型在任务完成前"睡着"的问题。- 自动模式：实现多 Claude 协作的关键，通过多轮模型和分类器筛查判断操作是否危险。成本增加 10% 到 40%，但让 /loop、Agent 团队和过夜运行真正可行。
- Fleet View（Claude Agents）：所有正在运行的东西显示在一个地方，团队成员用它一周合并了约一千个 PR。
- 远程控制：云服务器上运行持久化 Agent，通过手机和桌面版交互。Daisy 演讲的部分内容就是从酒店走过来时通过手机与 Agent 交互完成的。
2026 年的转变
2025 年是把信息输入模型以获得更好的结果，因为 Agent 编程还处于萌芽期，我们一直在不断补偿模型犯下的错误。2026 年，会转向把信息从模型传递给用户。
用户给模型的信息质量会随着模型变强而变得越来越不重要。今年的问题在于：你能多快地切换上下文，多快地扩展工作流以获取关于模型正在做什么的信息。你的注意力是系统中最小的盒子。
最后三件事：
- 给模型访问权限。
- 思考那个盒子——你往盒子里放了什么，这会如何影响你从盒子里得到什么。
- 选择那些能够扩展到大规模、真实世界软件工程的抽象。
Zero's take
这篇文章最值钱的地方不在于"Claude Code 怎么用"，而在于 Daisy 作为一个系统设计者对 Agent 工程的底层思考。几个判断：
上下文工程就是软件工程的下一个形态。 这不是营销话术。过去资深工程师的工作是给初级工程师写文档、定规范、搭脚手架；现在换成了给 Agent 做同样的事，而且你得在每个级别上都做。如果你在前端团队里写过 ESLint config、写过 ADR、写过 onboarding doc——你已经在做上下文工程了，只是对象从人变成了模型。
钩子 > Skill > MCP 的扩展性排序值得认真对待。 这对前端工程师特别有启发：我们太习惯于"把所有东西都塞进 bundle"的思维方式（像 webpack 把所有依赖打包），但上下文窗口不是 bundle，它是 Arduino——内存有限，每个字节都要争。钩子的设计哲学本质上是"事件驱动的按需加载"，这和 React 的 React.lazy + Suspense 是同一个思路：不为用户看不到的东西付费。
KV 缓存的约束被严重低估了。 Cursor 的 LRU 翻车案例说明，在 LLM 时代做缓存策略比传统 Web 缓存复杂得多——你不能简单换入换出，因为任何前缀变化都会让整个缓存失效。这就像你不能在 React 里随意 key={Math.random()} 一样，但代价从"重新渲染"变成了"10 倍推理成本"。
"从 ED 到 VS Code 的鸿沟"是最大的机会判断。 现在所有 AI 编程工具都还停留在文本查找替换的原始阶段，IDE 级别的实时反馈（红色波浪线、类型推导、智能补全）对模型来说还不存在。谁先把这套富反馈机制做好，谁就拿到了下一个时代的入场券。
一个保留意见：Daisy 对"Agent 摩尔定律还会持续一两年"的判断偏乐观。METR 自己都承认过了 Opus 4.6 后图表失效了，Mozilla 的数据点虽然震撼但只是单一数据点。指数增长在任何技术领域最终都会遇到物理约束——上下文窗口的停滞本身就是信号。