播客听见世界的声音，看见思想的刻度

Claude Code 的创始人兼负责人 Boris Cherny，以及产品负责人 Cat Wu，共同回顾了 Claude Code 的第一年——从一条只收到两个 emoji 回应的 Slack 演示，到如今每天运行数千个自主 agent。两人聊到了他们对验证的理解、auto 模式如何取代 plan 模式、routine 如何消灭整类手工工程工作，以及从"我来写代码"到"我来驱动一个 loop"这一转变，如何在短短 18 个月内完成了两次平台级跃迁。 ## [00:00] Claude Code 的起源与演变 Boris 回忆起把第一版 Claude Code 演示发到 Slack 时，只收到了两个反应。一年后，他的工作流已经是"agent 军团"——一个 loop 驱动 agent，agent 再驱动 agent，形成上千节点的树状结构。让这个工具走到今天的核心原则是：每次 Claude 出错，不要只修正这次输出，而是把解决方案写进 CLAUDE.md 或封装成 skill，让 Claude 从此可以无人值守地持续运行。 > *"每次 Claude 出错，我不会让它换个做法——我让它把解决方案写进 CLAUDE.md，或者做成一个 skill……只要你能做到这一点，Claude 就可以一直跑下去。"* ## [01:10] 如何让 Claude 擅长验证 Boris 和 Cat 都反对把"验证"窄化为 lint、类型检查和单测——那些在 agent 出现之前就已经自动化了。真正的 agent 验证，是让 agent 能实际运行被测软件。Boris 提到用 Opus 4 时的一个转折点：让 Claude 开发一个功能，然后自己打开 CLI 测试自己——当时觉得"太疯狂了"，现在已是基本要求。Cat 目前的做法是：用一个桌面开发 skill，让 Claude 启动本地桌面应用，通过 computer use 点击 UI、触发边界情况，发现新的失败模式后自己更新这个 skill。 > *"我让它读 Slack，判断：当前 staging 是不是挂了，或者有没有人已经踩过这个坑。然后等它把整个问题调试完，我让它把结论更新到桌面开发 skill 里。"* ## [03:14] 角色融合：Claude Code 走向工程师之外 Boris 讲述了第一次看到设计师开 PR 时的心情——从一开始的警觉，到看了代码之后觉得"行，没问题"。Cat 观察到，在众多企业客户中，工程师最先用起来，然后周边角色也开始凑过来：设计师直接在应用里做原型，PM 亲手上线改动，财务团队在 Claude Code 里跑测算，数据科学家让它常驻屏幕。 > *"感觉各种角色都在融合。"* ## [04:48] 用 routine 处理 CI、代码审查等工作 Cat 描述了团队里一位 Claude Code 深度用户：他上线了语音模式，然后建了一个 routine，监听该功能相关的所有 GitHub issue 和 bug 报告，自动起草修复方案并发 PR。后来他又扩展了 routine，专门盯着五小时内没有回应的 bug。Cat 自己也有过类似经历：她上线了一个小功能，留了一个边界 bug，有人提了 issue，但她还没来得及看，当天晚上 Claude Code 就告诉她"另一个 Claude 已经修好了"。Boris 补充说，routine 现在已经接管了所有代码审查，负责盯 PR、做 rebase、响应 CI 失败，他自己已经很久没有手动做这些事了。 > *"他还有另一个 routine，专门找五小时内没人回应的 bug 报告，自动提一个修复，然后他把容易验证的直接合掉。"* ## [06:43] Boris 最常用的功能：auto 模式 Claude 4.6 发布后，Boris 就不再用 plan 模式了；到 4.7，明确的规划步骤已经没有必要。他现在直接用 auto 模式启动 agent，然后转去做下一件事，不再盯着看。这一转变的根源在于早期的权限提示模型——每次工具调用都要审批——和 auto 模式的本质差异。auto 模式把可疑操作交给分类器处理，而不是逐条问人。当 99% 的提示都是无害的，人的注意力会涣散，真正危险的那一条就容易漏掉。auto 模式把注意力集中到真正值得关注的少数情况上。 > *"auto 模式比一条条审批权限提示更安全，因为你只需要关注最重要的事，而不是被一堆 99% 都会选'是'的提示轰炸。"* ## [08:10] 保护 auto 模式：红队测试与 eval 把 auto 模式推给用户之前，需要先建立信任。Cat 介绍了整个过程：收集数千条完整的 agent 执行轨迹和对应的权限提示，让 auto 模式分类器对每一条打标，确认准确率"极高"，再引入红队人员对代码库发起提示注入攻击。每一次成功的攻击都变成一个 eval。内部团队各自尝试注入，挖出更多盲区。最终产出的模型，不仅能抵御已知的野外漏洞，还能抵御团队能构造出的最复杂的对抗性攻击。 > *"这不只是防御今天已知的漏洞，而是抵御我们能构造出的最智能的攻击。"* ## [10:24] 为什么 loop 是下一个飞跃 Boris 把过去 18 个月总结为两次平台级跃迁。第一次：停止直接写源代码——改成和 agent 对话，让它来写。第二次，正在发生：停止直接和 agent 对话——改成和一个 loop 或 routine 对话，让它替你驱动 Claude Code。事后看两次跃迁都显而易见，但从工程思维出发，当时都很难看清。 > *"我不再直接和 agent 说话了。我和一个 loop 说话，或者和一个 routine 说话，让它帮我去 prompt Claude——这真的太离谱了。"* ## [11:06] 工程组织与职责正在如何改变 Boris 援引 1990 年代《哈佛商业评论》的一篇文章——那篇文章追问为什么公司从个人电脑上看不到生产力提升，答案是：电脑必须成为所有业务流程的中心，而不是放在纸质档案柜旁边的附属工具。在 Anthropic，新员工遇到问题不去问同事，而是问 Claude Code。最快理解 AI 价值的公司，都是把它放在运营核心的公司。Cat 补充说，电脑革命花了 10 到 15 年；AI 的压缩要快得多，因为工作本身已经数字化，而 Claude Code 既能写代码又能运行代码。 > *"你必须把档案柜扔掉。把所有纸张和笔都扔掉，然后把电脑放到中心，所有事情都得从电脑过一遍。"* ## [13:30] 未来属于产品还是工程？ Boris 的答案：两个角色正在合并为一个。Claude Code 产品团队人人写代码，开发者关系团队人人写代码，设计师写代码，工程师现在从头到尾地交付产品——定义想法、动手开发、协调法务、市场和安全，把产品推向市场。目前受益最大的是那些好奇心强、产品品味好、愿意端到端负责的人。 > *"AI 真的非常有利于那些好奇心旺盛、有很强产品品味、喜欢端到端拥有所有权的人。"* ## [14:20] 管理数百个 agent：agent 视图、语音模式与 Remote Control 几个月前，Boris 的多 agent 工作方式是：6 个终端标签页、6 个 git checkout、手动切换上下文。现在：1 个标签页，新的 agent 视图，桌面应用自动处理 worktree 克隆。意想不到的变化是：他大约一半的工程工作现在通过手机的 Remote Control 完成。他在桌前启动任务，起身去倒咖啡，拿手机看进展，随手启动新的 agent，遇到新想法就直接用语音模式口述。Cat 注意到，有连续两天 Boris 的笔记本一直放在桌上没动，他却在持续合 PR——他说他是在沙发上写代码。 > *"我去倒咖啡，然后顺手看看 agent 进展，说不定再启一个。有时候正在和别人聊，冒出一个新想法，我就直接在那儿起一个 agent。"* ## [16:05] 从 context engineering 到 context minimalism Boris 梳理了提示工程的演变：Sonnet 3.5 时代需要大量 prompt engineering；Opus 4 时代需要精心的 context engineering；今天的模型两者都不需要了。现在的做法是：给模型最精简的系统提示、最小的工具集，以及一个让它按需拉取上下文的机制——然后放手让它工作。Cat 称自己是"context minimalist"：只告诉模型它需要知道的，因为一上来塞太多上下文是在微观管理，而模型往往知道更好的路径。 > *"给它尽可能简短的系统提示，尽可能少的工具，然后让模型自己想清楚。"* ## [17:17] Claude Code 的下一步 Boris 拒绝预测具体形态，只说方向：agent 运行时间更长、自主性更强，同时并行的数量从一个跳到几十、几百乃至几千。协调这么多 agent 的交互界面"会和以前完全不同"，答案不会来自 Boris 或 Cat，而会来自团队和每天用 Claude Code 构建东西的整个社区。 > *"一年后会是一套全新的东西，如果到时候还是现在这些，那才真的奇怪。"* ## 实体 - **Boris Cherny**（人物）：Anthropic Claude Code 负责人，工具的创始人，本期两位受访者之一。 - **Cat Wu**（人物）：Anthropic Claude Code 产品负责人，本期两位受访者之一。 - **Claude Code**（软件）：Anthropic 开发的 agentic 编程工具，运行于终端；本期核心主题。 - **Auto 模式**（概念）：Claude Code 的权限模型，将工具调用决策交由分类器处理，不再逐条询问用户；取代了早期的逐步审批流程。 - **Loop / Routine**（概念）：由事件触发的自动 agent，无需人工发起即可驱动 Claude Code；被描述为第二次重大平台跃迁。 - **Context minimalism**（概念）：为模型提供最精简的系统提示和工具，让模型按需拉取上下文，而非预先塞入所有信息的开发哲学。 - **Anthropic**（组织）：开发 Claude 与 Claude Code 的 AI 安全公司。 - **Remote Control**（软件）：Claude Code 功能，允许用户通过移动设备管理正在运行的 agent。 - **Agent 视图**（软件）：Claude Code 新界面，支持在单一窗格中管理多个并行 agent。

Anthropic Applied AI 工程师 Isabella He 用 37 分钟现场构建了一个可运行的 SRE 故障响应 Agent——从空白的 `agent.py` 出发，最终交出一个能流式展示工具调用、持久化会话并诊断 P99 延迟尖峰的 Streamlit 应用。整场 workshop 将五分钟架构精讲与实战编码紧密结合，让参与者带走的不仅是一个可运行的 Agent，还有能够扩展到子 Agent、记忆和 Vault 的完整心智模型。 ## [00:19] 欢迎与课程简介 Isabella 首先介绍了 Applied AI 团队在 Anthropic 内部的定位——"产品、研究与客户的交汇点"——并点出本次 workshop 的三段式结构：平台快速回顾、动手编码冲刺，以及 dreaming、子 Agent 等进阶功能展望。驱动场景是每位软件工程师都经历过的噩梦：凌晨三点被 on-call 电话叫醒，而基于托管智能体构建的 SRE Agent 将代替人类自主处理这一切。 > *"我今天的目标，是让大家真正动手在托管智能体上构建，理解 harness 在底层是怎么运作的，并做好上线第一个故障响应 Agent 的准备。"* ## [02:10] 从 Messages API 到托管智能体 Isabella 梳理了产品的演进路径：2023 年的 Messages API 提供了原始的 token 访问能力，但上下文管理、Agent 循环和 compaction 全部由开发者自行实现；Agent SDK 进一步引入了 Claude Code 的文件系统操作能力，但托管仍需自己解决。托管智能体是第三代产品——Anthropic 负责扩缩容、沙箱隔离、可观测性和工具运行时，团队因此能"快 10 到 15 倍地把产品推上生产"。 她用一个真实案例说明了维护负担的具体形态：Sonnet 4.5 出现过"上下文焦虑"，导致任务提前结束；Anthropic 修复了 harness，Opus 4.5 彻底消除了这一行为，之前的补丁也随之作废。 > *"Harness 必须随 Agent 一起演进——这正是我们希望由 Anthropic 来处理 compaction、caching、上下文焦虑等所有复杂性的原因。"* ## [05:55] 核心原语：Agent、Environment、Session 托管智能体应用由三个对象组成。**Agent** 持有"人格"——模型选择、系统提示、MCP 服务器、skill 配置。**Environment** 是执行容器，相当于 Agent"大脑"对应的"双手"，在演讲前一天起同时支持 Anthropic 托管云和自带计算资源两种模式。**Session** 将两者绑定并挂载数据文件；事件（用户消息、工具调用、响应）以流式方式返回给调用方，而非一次性吐出所有 token。 将 Agent 循环与工具执行解耦后，P95 首 token 时间下降超过 90%，同时通过沙箱容器边界消除了凭证暴露风险。 > *"解耦之后，我们团队实测 P95 延迟的首 token 时间降幅超过 90%。"* ## [09:15] Workshop 环境准备 参与者 clone workshop 仓库，进入 `ship-your-first-managed-agent` 目录，创建虚拟环境，安装依赖，将 Anthropic API key 写入 `.env`，然后运行 `streamlit run app.py`。Isabella 确认 Streamlit 页面正常打开，显示故障响应聊天界面——这是后续构建的空白画布。 > *"你可以跟着现场做，也可以今天稍后自己再来一遍——所有内容都会显示在屏幕上，方便大家跟上。"* ## [10:48] 逐步构建 Agent Isabella 对照 `agent.py`（待补全版）和 `agent_complete.py`，逐一复制六段代码： 1. **Agent 定义** — 使用 Claude Opus 4.7 创建 `SRE_AGENT`，配置简洁的系统提示，列明 Agent 角色和可用工具（get_metrics、get_recent_deploys、get_diff、fetch_logs）。 2. **Environment** — 演示用途开放全网络访问的 Anthropic 云环境；生产环境可限制为白名单或通过 Claude MCP 隧道路由流量。 3. **日志上传** — 通过 Files API 挂载日志文件，让 Agent 可对其执行代码；Isabella 指出上下文工程是开发者花时间最多的迭代环节。 4. **Session 创建** — 传入 `agent_id`、`environment_id` 和已上传资源的引用，将所有组件绑定在一起。 5. **事件流** — 从 Session 接收事件（而非原始 token），支持实时展示和可观测性日志记录。 6. **本地工具 + 删除 Session** — 注册 `get_metrics`、`get_recent_deploys`、`get_diff` 作为本地执行的处理函数，并添加删除 Session 的调用，说明被删除的 Session 会从日志中彻底清除。 > *"最后缺的一块，就是把本地工具交给它，让 Agent 能在我的电脑或基础设施上真正开始行动。"* ## [19:43] 运行 Agent 与现场演示 Isabella 用提示词"帮我排查这个故障"启动新 Session。Agent 依次调用 `sandbox_bash`、`get_recent_deploys` 和 `get_diff`，将每个工具调用和响应 token 实时流式传输到界面，最终返回结构化的故障报告：P99 延迟尖峰（达基线的 10 倍）源于 Alice 的 `refactor_order_summary_builder` 提交引入的数据库连接池耗尽。 她指出，生产环境可进一步接入 Claude Code，自动提出修复建议、开 PR，无需人工介入就能完成闭环。强制刷新浏览器后，会话持久性得到验证——所有历史 Session 从云端状态恢复，无需本地数据库。 > *"翻看所有工具调用，你会发现一切都从日志角度持久化在云端，同时也会记录在可观测性控制台中。"* ## [27:18] 架构回顾、进阶功能与问答 Isabella 回顾了事件驱动架构的核心：Session 以事件而非请求-响应对进行通信；事件日志让托管智能体在容器重启后无需重放 Agent 循环即可恢复 Session。随后她预览了四项高级能力： - **子 Agent** — 编排者派生出各自拥有独立上下文窗口的子 Agent，实现并行处理和上下文预算管理。 - **记忆与 Dreaming** — Agent 异步回顾自身 Session 历史，决定保留哪些信息，跨 Session 实现自我迭代和偏好记忆。 - **Outcomes** — 开发者定义评估标准，Agent 自行判断哪些工具调用能达成目标结果。 - **Vaults** — 凭证在独立端点与 Agent 容器之间加密存储，支持按用户和 Session 粒度隔离，依托架构层面的大脑/双手分离实现。 最后，她引导参与者前往后续的 "dreaming" 专场和托管智能体控制台内置的可观测性仪表板。 > *"希望大家都能带走一个关于托管智能体底层工作原理的心智模型——也为自己能成功上线一个 SRE Agent 感到骄傲。"* ## 实体 - **Isabella He**（人物）：Anthropic Applied AI 团队 Member of Technical Staff，本次 workshop 主讲人 - **Claude Managed Agents**（软件）：Anthropic 面向生产级 Agent 的托管基础设施 harness，负责处理扩缩容、沙箱隔离、可观测性和工具运行时 - **Agent SDK**（软件）：Anthropic 早期 harness，支持 Claude Code 文件系统访问能力，需开发者自行托管 - **Claude Opus 4.7**（软件）：workshop 演示中 SRE Agent 使用的模型 - **Sonnet 4.5**（软件）：早期模型，曾出现"上下文焦虑"（任务提前终止）现象，用于说明 harness 必须随模型演进 - **Files API**（软件）：Anthropic 提供的文件上传 API，用于将日志、指标等文件注入 Agent 上下文 - **Dreaming**（概念）：托管智能体功能，Agent 异步回顾自身 Session 历史以更新长期记忆 - **Outcomes**（概念）：托管智能体的目标规格机制，Agent 根据定义的评估标准自主选择工具调用路径 - **Vaults**（概念）：托管智能体中的加密凭证存储，通过大脑/双手分离架构与 Agent 容器解耦 - **MCP tunnels**（概念）：Claude 功能，用于将 MCP 服务器流量通过私有网络路由，而非走公网 - **上下文焦虑**（概念）：Sonnet 4.5 观测到的行为，在上下文预算充足时提前结束任务，Opus 4.5 中已修复 - **Anthropic**（组织）：AI 安全公司，Claude 和托管智能体平台的创造者 - **DataDog**（软件）：生产级监控平台，被引用为演示中 JSON 指标工具的替代方案 - **Streamlit**（软件）：Python UI 框架，用于构建 workshop 的故障响应聊天界面

Man Group 数据与 AI 主管 Tushara Fernando 分享了该公司如何将数十年的机构知识提炼为"技能"，进而将 AI 融入系统化交易。她强调，要让 AI 从个人生产力工具升级为企业级智能体平台，健全的治理体系和共享工作流缺一不可。 ## [00:18] AI 与系统化交易 Man Group 管理着逾 2000 亿美元资产，AI 落地的风险之高对机构客户而言不言而喻。Tushara Fernando 将系统化交易描述为一套算法流程——通过历史回测评估投资信号，类似于管理一支梦幻足球队。 > *交易信号本质上就是用股票做这件事……我们想押注那些能赚钱的，做空那些不能赚钱的。* > *[2, 43]* ## [04:38] AI 生成信号的价值 Man Group 目前在生产环境中运行的交易信号，其研究、回测与提案全部由 AI 完成。人类只在最后审查结果的合理性，数据获取、策略提案到生产部署均由 AI 负责。 > *Man Group 的生产环境中现在正有交易信号在运行……这些信号是由 AI 完成研究、回测并提出的。* > *[4, 38]* ## [05:52] 共享工作流的重要性 交易信号的成败取决于底层工作流，例如数据清洗和异常值检测——Fernando 将其比作冰山藏在水下的部分。不同团队各跑各的工作流版本，结果就会产生偏差，根本无法横向比较各类策略的效果。 > *如果不同团队用的是不同版本的工作流，得出的答案就会不一样。* > *[6, 50]* ## [08:43] 技能治理的实战经验 早期 AI 落地尝试之所以失败，是因为构建"技能"的是熟练用户而非流程负责人，导致各自优化、出现硬编码成本中心等错误。为此，Man Group 建立了一套治理化的技能市集：技能由工作流负责人持有，需经过评测验证，并追踪实际使用情况。 > *把这些技能当成生产代码来对待，因为它们最终就会成为生产代码。* > *[17, 21]* ## [16:40] 在企业层面规模化 AI Man Group 已将 AI 普及至近一半员工，核心策略是把组织上下文作为竞争壁垒。通过将技能打造成机构知识库，公司正在为未来布局——届时，大量 AI 智能体将调用这些能力，持续发现新的投资机会。 > *技能治理真正打开了 AI 在企业规模落地的大门。* > *[19, 21]* ## 实体 - **Tushara Fernando**（人物）：Man Group 数据与 AI 主管。 - **Man Group**（机构）：全球另类投资管理公司，管理资产规模逾 2000 亿美元。 - **Claude**（产品）：Man Group 用于研究、回测和工作流自动化的 AI 模型。 - **Anthropic**（机构）：协助 Man Group 举办技能工作坊并推动落地的 AI 公司。 - **Systematic Trading**（概念）：覆盖数千只证券和数百个市场的算法化交易能力。 - **Backtesting**（流程）：将交易策略在历史数据上回溯运行以评估表现的过程。 - **Sharpe Ratio**（指标）：衡量策略波动性与收益之比的统计指标。 - **Skills Marketplace**（产品）：Man Group 内部的治理化 AI 技能、插件与机构知识库。

本节介绍 Claude Managed Agents——一套专为开发者设计的 API 端点，内置工具调用、安全机制和可观测能力，帮助开发者快速构建并部署生产级 AI 智能体。演讲者详细讲解了 Agents、Environments、Sessions 三大核心原语，以及如何借助它们实现多智能体协调和人机协同控制。 ## [00:00] Managed Agent 核心原语介绍 Anthropic 推出 Claude Managed Agents，以一组 API 端点的形式提供开箱即用的生产级能力，涵盖工具调用、错误恢复和记忆管理。其架构以"Agents"作为技能模板，以"Environments"提供具备细粒度权限的沙箱执行环境，以"Sessions"维护持续的对话上下文与状态流转。 > *Claude Managed Agents 说白了就是我们开发并发布的一组 API 端点……让你能直接用上可扩展、生产就绪的智能体。[01:35]* ## [07:54] 安全连接与沙箱机制 该平台支持自托管沙箱，开发者可使用私有容器和 VPC 保护敏感数据，同时保持对模型的访问。新增的 MCP 隧道功能可安全连接内部 MCP 服务器，Credential Vaults 则将认证令牌与模型上下文完全隔离，避免泄露风险。 > *Claude 可以直接安全地连接到这些 MCP 服务器，无需将其暴露在公网上。[09:40]* ## [10:02] 多智能体编排与实现 演示展示了一套多智能体架构：一个协调者智能体可动态派生专用子智能体，分别处理金融分析、宏观趋势研究等复杂任务。开发者可通过 Anthropic SDK 和 Claude Code 实现这类工作流——Claude Code 专门针对 Managed Agents API 的开发与迭代进行了优化。 > *一个智能体负责判断宏观趋势……另一个则专精金融分析。[11:36]* ## [19:28] 可观测性、记忆与基础设施 Claude Console 提供完整的可观测能力，包括智能体版本管理、会话监控，以及直接编辑记忆存储以修正智能体上下文。该服务内置状态流转和持久化存储，开发者无需手动搭建复杂的自定义智能体循环或沙箱集群。 > *用了 Claude Managed Agents，这些能力全部开箱即得。[26:54]* ## 实体 - **Anthropic** (组织): 开发 Claude 系列模型的 AI 研究与安全公司。 - **Claude Managed Agents** (软件): 用于构建和托管生产级 AI 智能体的 API 端点套件。 - **MCP** (协议): Model Context Protocol，用于安全认证和工具集成。 - **Claude Code** (软件): 专为实现和管理 Anthropic API 而优化的开发者工具。 - **Bun** (软件): 技术演示中使用的高性能 JavaScript 运行时。 - **Cloudflare** (基础设施): 云服务提供商，用于托管私有沙箱和运行环境。 - **Credential Vaults** (功能): 安全存储认证令牌、防止其暴露给模型的机制。 - **Memory Stores** (功能): 持久化存储，支持智能体跨会话保留和检索信息。

Anthropic 工程师 Michael 与 Harrison 介绍了 Claude Managed Agents——一个旨在简化自主 AI 智能体部署所需基础设施、安全与可观测性的平台。通过接管沙箱、身份管理等复杂后端任务，该系统让开发者得以从简单的工具调用迈向长时运行、以结果为导向的智能体工作流。 ## [01:10] 智能体基础设施的演进 Michael 与 Harrison 梳理了 AI 从基础函数调用到能够完整负责功能开发与 PR 的自主智能体的演进历程。他们指出，当前制约生产力提升的瓶颈已不再是模型能力，而是基础设施——真正的目标是让数月的工作在几小时内完成。 > *我们认为未来的方向是：整整一个季度的工作量，能在短短几小时内全部搞定。* > *[2, 34]* ## [04:22] 核心原语与配置 平台提供可组合的原语，涵盖上下文管理、可观测性与安全沙箱，开发者可通过系统提示词和 MCP 工具配置来定义智能体。"Ask Claude"按钮与事件流为智能体会话提供实时透明度，并给出优化建议。 > *这些平台工作我们都替你做好了，你只需要按需选取我们提供的原语即可。* > *[5, 26]* ## [10:05] 高级编排与记忆 平台不止于单任务执行，还支持多智能体编排——Claude 可以派生子智能体来分派工作。"Dreaming"等高级功能让智能体能够跨数千个会话进行反思，通过自主复盘提升长期记忆与任务表现。 > *它让 Claude 能够派生出各自拥有独立上下文窗口的子智能体线程，将工作委托给它们执行。* > *[10, 55]* ## [11:56] 沙箱与安全连接 Anthropic 提供自托管沙箱与 MCP 隧道，让企业在掌控网络策略和审计日志的同时，安全地暴露私有数据。Vercel、Modal 和 Cloudflare 等合作伙伴提供专属基础设施，从面向快速弹性扩容的轻量隔离执行环境，到高性能 GPU 集群，各有所长。 > *MCP 隧道本质上就是把你网络内部的私有 MCP 暴露给云端管理智能体的一种方式。* > *[13, 25]* ## [20:19] 真实场景自动化与性能优化 DoorDash 和 Modal 等公司正在将智能体用于复杂的技术任务，例如自主账户管理和推理调优。通过运行 Nvidia 分析器等工具，智能体能够自主"爬坡"优化性能基准，无需人工干预即可提升工作负载效率。 > *Claude 能优化训练循环……它会跑 Nvidia 分析器，读取分析结果，然后一路猛干，把各项指标越搞越好。* > *[20, 39]* ## [25:23] 未来挑战：身份管理与协作 随着智能体成为算力的主要消费者，业界面临身份管理、出口过滤和任务可恢复性等新挑战。AI 的未来在于从刚性执行走向协作式的"多人在线"模式，让智能体与人类能够根据反馈动态调整方向。 > *我们如何在整条链路上正确分配身份，确保它只能访问应该访问的数据？* > *[25, 55]* ## 实体 - **Anthropic**（组织）：Claude 系列模型背后的 AI 安全与研究公司。 - **Claude Managed Agents**（产品）：用于构建和部署自主 AI 智能体的平台与基础设施套件。 - **Michael**（人物）：Anthropic 技术成员，负责 managed agents 方向。 - **Harrison**（人物）：Anthropic 技术成员，负责 managed agents 方向。 - **MCP**（协议）：Model Context Protocol，用于工具配置与安全隧道。 - **Cloudflare**（组织）：云服务提供商，专注于 MicroVM 和隔离执行等沙箱技术。 - **Modal**（组织）：算力平台，专注于大规模 GPU 沙箱与 AI 工作负载。 - **Vercel**（组织）：合作伙伴，为智能体沙箱提供弹性计算基础设施。

Omni CTO Chris Merrick 详述了「Blobby」的开发历程——这是一套由 Anthropic Claude 模型驱动的智能体分析工具。Omni 将扎实的语义层与内部深度使用 Claude Code 相结合，让用户能够把自然语言转化为复杂的数据可视化，同时保持较高的工程交付速度。 ## [00:07] 用 Claude Code 提升工程效率 Chris Merrick 介绍了 Claude Code 如何改变 Omni 的内部开发节奏，让一支仅 25 人的小团队依然能保持高频提交。即便身为 CTO，Merrick 也借助 Claude Opus 模型的高效能力亲自参与编码，与团队并肩作战。 > *I thank Claude very much for making me uh still able to do some software engineering from time to time. [01:12]* ## [03:14] 语义层与业务上下文 为了弥合通用 LLM 知识与具体业务数据之间的鸿沟，Omni 引入了一套语义层，提供财务定义、表关系等关键上下文。这一层既是权限管控工具，也是数据策划工具，确保 AI 智能体真正理解企业数据环境的独特之处。 > *Claude is incredible at answering questions, but you need to tell it more about your business if you want it to answer questions about your business. [04:03]* ## [11:15] 架构演进与「切脑手术」 团队将 AI 智能体 Blobby 从简单问答工具逐步升级为成熟的智能体框架：把底层模型从 Claude Haiku 换成 Sonnet，以获得更好的多轮对话表现；同时针对「裂脑」问题——子智能体与外层智能体沟通失调——将所有工具整合进单一、统一的智能体大脑加以解决。 > *You want to be careful not to have a split brain between any sort of sub agent system and outer agent system. [15:57]* ## [16:23] 利用 SQL 与 CTE 的熟练优势 Omni 将查询策略从自研 JSON 格式切换为标准 SQL，以充分发挥 Claude 在复杂公用表表达式（CTE）上的天然优势。这次迁移让智能体能够一次性处理复杂的数据问题，显著提升了生成报告的准确性。 > *Claude really likes to write SQL with CTE, common table expressions... and our parser was really good at parsing those [18:27]* ## [19:09] 评测、可观测性与 UI 验证 Merrick 强调，严格的评测体系和原始链路可观测性，是满足高管用户对结果可预期性要求的关键。Omni 遵循「AI 生成，UI 验证」的产品理念：由 Blobby 生成初始看板，再由用户通过工作簿界面进行细化和排查。 > *Our philosophy from a product perspective is AI to build, UI to sort of validate and troubleshoot and refine. [23:21]* ## 实体 - **Chris Merrick**（人物）：Omni 联合创始人兼 CTO，带领工程团队并积极推动 AI 驱动的开发模式。 - **Omni**（组织）：一款 AI 分析平台，让用户能够用自然语言查询数据。 - **Claude**（AI 模型）：Anthropic 旗下的 LLM 系列，驱动 Omni 的数据分析与内部工程工作。 - **Claude Code**（软件）：AI 辅助编程工具，大幅提升了 Omni 的开发效率。 - **Blobby**（AI 智能体）：Omni 的 AI 数据分析师智能体，专为解读和回答复杂数据问题而设计。 - **SQL**（技术）：Omni 语义层生成的查询语言，用于与数据仓库交互。 - **Claude Sonnet**（AI 模型）：Anthropic 旗下特定模型，用于解锁复杂智能体对话中的性能突破。 - **GitHub**（平台）：智能体演示中所用 PR 数据的来源平台。

Sid Budhiraja 是 Claude Code 的创始工程师之一，在 Anthropic 的 Code with Claude 大会上发表了这场演讲，直指一个普遍的效率黑洞：工程师大量时间耗在盯着屏幕等 Claude 跑完，或充当一个"高级 QA 测试员"。他给出三套递进策略——验证、并行化、后台循环——合在一起，让 Claude 基本上可以无人值守地运行。YouTube 上没有字幕；转录由 Gemini Flash 生成（仅段落级别，无词级时间戳）。 ## [00:02] 开场与前置条件 Sid 把这场演讲定位为"Claude Code 301"课，开场先做了一个快速的现场调研。他列出三件他认为必须具备的基础：一份高质量的 CLAUDE.md 文件（"单项杠杆最高的事情"）、把 Slack、Linear、BigQuery 等外部工具接入 Claude Code 让它拼出更完整的上下文、以及把 Claude Code 跑在 Web 端让会话脱离工程师的笔记本电脑、即便机器关掉也继续运行。 随后他介绍了接下来的主线：验证、多 Claude 并行、后台循环，三者环环相扣。 > *"有个实用原则：凡是你日常工作中好用的工具，Claude 用起来也好用。Slack、Asana、Linear、Datadog、BigQuery——这些都能帮 Claude 拼出一个丰富得多的上下文。"* ## [05:14] 让 Claude 自己验证自己的工作 Sid 让听众回想自己最近一次验证 feature 的步骤：写代码、构建、运行、检查副作用、看日志、查数据库、跑单元测试、部署到 staging。他的论点是——这套流程 Claude 也能跑，只要给它合适的工具和指令。 关键机制是**循环**：Claude 写代码，遇到失败，调试，再写代码，如此往复，直到到达成功状态。一旦进入循环，Claude 就能自主爬坡，不需要工程师守在旁边。这套循环在前端（浏览器冒烟测试）、后端（API 校验）和端到端流程上都适用，原理完全一致。 为了把验证循环打包复用，Sid 推荐用**技能文件**——一份 Markdown 文档，存放特定验证任务的指令和工具配置。技能文件还可以自我进化：让 Claude 每次碰到新障碍就更新这份文件，它会逐渐成长为一份团队共享的自文档化手册。 > *"循环本质上是一个你可以替 Claude 搭好的自主回路，让它在某个任务或某个成功标准上持续爬坡。"* ## [15:46] 演示：现场搭建验证循环 Sid 以 MonkeyType 作为演示对象，这是一个开源的 TypeScript/Express/MongoDB/Redis 打字测试应用，代表了真实的全栈生产环境。从一个全新的 Claude Code 会话出发，他让 Claude 启动开发服务器，然后用 `/chrome` Chrome MCP 工具打开 localhost，输入文字，修改设置——手把手带它走完一次基本冒烟测试。 辅助会话跑完之后，他让 Claude 把刚才学到的一切写进 `.claude/demo-verification` 的技能文件里。Claude 生成了一份包含三节的技能文档：启动应用栈、加载 Chrome MCP 工具、执行冒烟测试。接着他让 Claude 开发一个新功能——每次打错字就触发彩纸动画——并用刚创建的验证技能来自证其工作。Claude 写好功能，遇到 ESLint 报错，修掉，重新加载应用，循环往复，直到彩纸出现。 > *"你能看到验证循环在跑：它写了代码，遇到问题，又写更多代码来修，就这样转圈，直到回到一个好的状态。"* ## [26:38] 同时跑多个 Claude 还不崩溃 同时跑多个 Claude 实例会消耗注意力，Sid 个人的上限是四五个会话，再多就难以招架。他介绍了四种突破这个天花板的工具。 **Claude Code 桌面应用**提供统一的侧边栏，把本地终端、云端、GitHub 上所有会话汇总展示——按需要关注的紧迫程度排序、颜色标注、可重命名。终端替代方案是**Claude Agents**（`claude agents`），在演讲前约一周发布，在终端内呈现相同的会话列表，把最需要决策的会话排到最前面。**Claude Code on the Web**（claude.ai/code）在 Anthropic 的云端运行会话，完全脱离工程师的硬件。**Remote Control**（`/remote-control`）则把任意运行中的会话镜像到手机端并推送通知，工程师在车里或开会间隙也能直接回应 Claude 的问题，不用打开电脑。 > *"Remote Control 让你可以用手机控制任意设备上跑着的任意会话。Claude 需要你介入时，手机会震动，哪怕你在车里，随手就能给它想要的输入。"* ## [32:41] 后台循环与例程 即便有了多会话管理工具，工程师还是要亲自决定什么时候开启每个会话、给它什么目标。后台循环把这最后一步手动操作也省掉了。Sid 介绍了 `/loop` 命令：`/loop 10 minutes "babysit my open PRs"` 会每隔十分钟唤醒一个 Claude Code 会话，自主执行该提示词，处理 review 意见、合并冲突、CI 失败，全程不需要工程师守着。 **Routines** 是跑在 Anthropic 云基础设施上的 `/loop`，复用的是 Claude Code on the Web 的远程容器。Claude Code 团队自己就跑着两个例程：一个每天更新文档，一个每六小时扫描 issue 和用户反馈并把摘要发到团队 Slack 频道。验证确保输出可靠，多 Claude 工具保护并行会话间的注意力，例程负责周期性的日常事务，工程师的角色就此从"看门员"变成了"委派者"。 > *"你可以把注意力和时间放在自己真正在意的事情上，其他一切都可以委派给 Claude——可靠度高，放心程度也高。"* ## 实体 - **Sid Budhiraja**（人物）：Claude Code 在 Anthropic 的创始工程师；本次演讲的主讲人。 - **Anthropic**（组织）：Claude 和 Claude Code 的开发商；Code with Claude 大会的主办方。 - **Claude Code**（软件）：Anthropic 的自主编程工具；演讲的核心主题。 - **验证循环**（概念）：自主的"写代码—检查—修复"闭环，让 Claude 在无需人工干预的情况下持续迭代，直到达到预定的成功状态。 - **MonkeyType**（软件）：开源 TypeScript 打字测试应用（Express + MongoDB + Redis）；演示中的真实目标应用。 - **Chrome MCP**（软件）：Model Context Protocol 工具（通过 `/chrome` 调用），赋予 Claude 对浏览器的程序化控制能力，用于 UI 验证。 - **Routines**（概念）：云端定时运行的 Claude Code 会话，支持基于时间或事件的触发，实现完全自主的周期性任务。 - **Remote Control**（概念）：功能（`/remote-control`），将 Claude Code 会话镜像到手机端并推送通知，支持随时随地的异步监管。

Fabian Hedin 是 Lovable 的联合创始人兼 CTO，他介绍了团队为防止非技术用户永久卡住而构建的两套生产系统：Lovable Overflow——一个在推理时注入 agent 上下文的问题-解决方案自维护语料库；以及"venting"工具——让 agent 自行标记平台故障并自动向工程师提交 PR 供审查。两套系统合计将平台的卡住率降低了 5%，效果相当于整整一代基础模型的升级，如今每天约有十个由 agent 提交的 PR 被合并入库。 ## [00:20] 从 GPT-Engineer 到每月六亿次访问 Lovable 的历史可以追溯到 35 个月前的 GPT-Engineer——一个由 Anton 联合创立的终端程序，曾短暂成为 GitHub 增长最快的仓库。那场演示——让模型生成一个贪吃蛇游戏并端到端执行——让外界看到了 LLM 在软件创作上的潜力，但 2023 年中期这套抽象层对非开发者用户还远未成熟。Fabian 将大约十八个月前"对话 + 预览"模式跑通视为关键转折点，此后每三个月就有一个新的基础模型把边界再往前推一步。 平台如今承载着 1500 万个项目。更能说明问题的是：基于 Lovable 搭建的站点每月合计获得六亿次访问，远超 Lovable 自身的流量——这说明用户正在用它交付真正有影响力的产品。 > *"我们平台上有 1500 万个项目，基于 Lovable 搭建的站点每月有六亿次访问。我认为这个数据很有意思，因为它远远超过了 Lovable 自身的流量。"* ## [04:22] 面向 99% 人群的生产级软件：非技术用户为何会卡住 Lovable 瞄准的是那 99% 不会写代码的人，并坚持以生产级质量为标准，而非止步于原型。这让问题比面向专业开发者更难处理。专家遇到问题可以读报错、换库，或者找开发者体验团队；非技术用户在 Lovable 的抽象层里工作，代码大多看不见，根本没有这些退路。 Fabian 引用了软件开发的经典铁律：前 90% 的代码要花 90% 的时间，后 10% 再花 90%。AI 时代这个规律依然成立：vibecoding 能让你快速得到第一版，但要做到完整、无 bug，往往更费时间。在最后那段冲刺里彻底卡死，是 Lovable 能给用户带来的最糟糕体验。 > *"如果他们卡住了，体验会非常糟糕。这几乎是能发生在他们身上最坏的事，因为他们自己解卡要难得多。"* ## [09:55] 定义“卡住”：is_stuck 指标与三类失败桶 当用户连续三次提出相同请求、明确抱怨输出结果，或者提问后直接放弃会话时，Lovable 的 `is_stuck` 标志就会触发。一个小型分类模型会评估每段对话来设置这个信号。 团队将卡住场景归为三类桶。第一类是"可提示解决"的——换个说法或补充一点上下文就能搞定；Lovable 的目标是在用户意识到需要重新提问之前就把这类情况修掉。第二类是平台缺口：agent 本应处理，却因工具缺失或损坏而无法完成。第三类则需要大型基础设施投入——例如 Lovable 很长时间只支持客户端渲染的 SPA，这让注重 SEO 的开发者头疼；就在本次分享的那周，他们刚上线了服务端渲染。每类桶需要不同的修法，但三者共享同一核心愿景。 > *"Lovable 在技术层面的愿景是：平台上搭建的每一个应用，都应该帮助改善下一个应用。"* ## [13:15] Lovable Overflow：绕过错误的舰队知识库 以 Stack Overflow 命名，Lovable Overflow 是一个持续增长的语料库，收录从真实用户会话中提炼的问题描述与解决方案配对。当用户反馈页面滚动卡顿时，一个轻量检索模型会在语料库中搜索相似描述，若匹配结果足够相关，就将一个合成修复注入主 agent 的上下文——不是原始文本，而是经过改写以适配当前场景的版本。 更难的工程问题是保持语料库的时效性。JavaScript 包发布了修复，或者新基础模型已经把答案烧进权重，知识就会过期。Lovable 追踪每条记录的成功率，并剔除失效记录——包括那些在新模型里已经冗余的条目。在"纳入新知识"与"淘汰旧知识"之间保持平衡，结果证明和检索机制本身同等重要。 > *"我们会追踪每个知识文件的成功率，当它过期时直接将其从知识库中删除。我们会持续审查系统里的每一条知识，确保在它不再有用时及时清理。"* ## [17:45] Venting：让 agent 自己汇报遇到的问题 第二套自愈机制把反馈回路倒了过来：不再是 Lovable 工程师盯着失败看，而是 Lovable agent 在遇阻时主动提交报告。agent 的工具集里有一个叫 `vent--send_feedback` 的工具，提示词要求它"每条用户消息中，只要工具、文档或平台行为对你的工作造成实质性拖慢或干扰，就调用一次"。agent 的投诉会落到一个 Slack 频道，一个监控 agent 负责去重和排查，如果问题属实，就自动向工程师开一个 PR 供审查。 约 50% 的自动生成 PR 有意义并被合并。举一个例子：agent 在 `code--copy` 工具里踩到了文件名含空格的 bug，尝试了 URL 编码等各种变通方法后发出 venting，十分钟后修复就上线了。另一个例子走得更远：Lovable agent 抱怨 Framer Motion 的 TypeScript easing 类型设计，暗示这个开源库本身就值得提一个 PR。Fabian 提到，他们在考虑让 agent 把修复直接贡献给更广泛的 JavaScript 生态。 venting 频道还出乎意料地成为了一套早期预警系统。推理服务中断、沙箱丢失、网络层故障——这些生产事故都会在传统监控告警触发前，先以 venting 量的峰值形式出现。有一个"元案例"：agent 在一次会话里连续 venting 了 43 次，随后自己提了一个 PR，建议加入去重逻辑来防止刷屏它自己的创造者。 > *"这个 Slack 频道里 agent 的 venting 多次成为我们发现生产事故的第一信号。即便不是第一信号，它对工程师排查问题也已经非常有价值。"* ## [26:12] 成果、经验，以及自愈机制之后的方向 Lovable Overflow 第一版就将卡住率降低了 5%，发布率提升了 2%，此后还在持续调优。Fabian 给这个 5% 加了背景：这大致等同于升级到全新一代基础模型所能带来的改善幅度。venting 流水线每天合并约十个平台修复。 三条经验格外突出。第一，失败模式的知识具有模型特异性：新基础模型上线后，Lovable Overflow 的现有条目需要重新验证，因为有些会变得冗余，有些则需要针对新模型的不同行为重新措辞。第二，知识有半衰期——哪怕当时正确的修复，随着库的演进也会变错。第三，早期曾有一次类似尝试失败了，不是因为思路有问题，而是成功信号太粗糙，难以调优；如今 1500 万个应用、每天 20 万个新项目，让 Lovable 终于有了足够的信号来让系统跑起来。 除这两套系统外，团队正在用舰队数据做微调，并扩大评估覆盖面，以此作为每次模型发布的门控。Fabian 的结语是：Lovable 的用户带着强烈的意愿来交付真实产品，当他们离开时依然卡着，那就是 Lovable 的失败——所有这套自愈机制存在的意义，就是弥合这个差距。 > *"卡住率降低了 5%。这个数字听起来也许不大，但实际上，它和我们在系统里换上一代新基础模型所能看到的指标变化处于同一量级。"* ## 实体 - **Fabian Hedin** (人物)：Lovable 联合创始人兼 CTO；在 Code with Claude 2026 发表了本次主题演讲 - **Lovable** (组织)：面向非技术用户的 AI 软件构建平台；1500 万个项目，托管站点每月六亿次访问 - **Claude** (软件)：为 Lovable agent 提供支撑的基础模型，服务消费级规模 - **GPT-Engineer** (软件)：由 Anton（Lovable 联合创始人）联合创立的开源终端工具；2023 年成为 GitHub 增长最快的仓库，后演进为 Lovable - **Lovable Overflow** (概念)：舰队学习知识语料库——从真实会话中提炼问题/解决方案配对，注入 agent 上下文，并按成功率持续剪枝 - **Venting / vent--send_feedback** (概念)：agent 端工具，将平台故障报告提交至 Slack；监控 agent 负责去重并自动向工程师开 PR - **is_stuck** (概念)：二值指标，当用户重复提出相同请求三次、抱怨输出结果，或提问后放弃会话时触发 - **Framer Motion** (软件)：TypeScript 动画库；被 Lovable agent 识别为存在次优类型 API 的开源依赖，作为案例引用

Niklas Gustavsson 是 Spotify 的首席架构师兼工程副总裁。他讲述了一个拥有 3000 名工程师的团队如何在数月内将 AI 工具采用率从零推到 99%，以及这一变化对产品研发约束的深层影响。他详细拆解了 Spotify 自研的三套系统：用于大规模自动化迁移的 FleetShift、基于 Claude 的后台编码智能体 Honk，以及让智能体在规模化环境下可靠运行的结构化平台 Backstage。核心论点是：让人类团队跑得快的标准化实践，同样能让智能体跑得快。 ## [00:18] Spotify 的 AI 采用热潮 Spotify 对 AI 编程工具的采用并非缓慢渗透，而是在 2024 年 11 月 Claude Opus 3.5 发布前后出现了明显拐点。数月之内，99% 的工程师每周使用 AI 工具，最新内部调查中 94% 的工程师表示 AI 工具切实提升了他们的工作效率，PR 提交频率上涨了 76%。Niklas 提到，他在准备这张幻灯片时不得不临时更新数据，因为数字还在持续攀升。 这场量变也带来了质变：Spotify 目前提交的大多数 PR，已经是工程师与 AI 智能体共同完成的，而不再是人类独立撰写。 > *"今天，我们超过 99% 的工程师每周都在使用 AI 编程工具。在最新的调查中，94% 的工程师表示，使用 AI 工具帮助他们变得更有效率。"* ## [03:52] FleetShift：AI 之前的代码库自动化维护 AI 出现之前，Spotify 面临的问题是：生产代码库的增长速度是工程团队扩张速度的七倍。这意味着工程师要把越来越多的时间花在维护工作上——版本升级、API 废弃处理、安全补丁——留给新功能开发的精力因此不断被压缩。FleetShift 是应对这一困境的答案：这套舰队管理系统将上述变更视为跨越数千个代码仓库的协调操作，而非逐个组件的手动处理。 AI 进入 Spotify 之前，FleetShift 已经无需人工介入地自动合并了 250 万个维护 PR：系统自动创建 PR、在 CI 中验证，然后合并。这套基础设施后来成为 Honk 接入的编排层。 > *"截至今天，我们已经合并了 250 万个这样的自动化维护 PR。这些工作我们的开发者完全不需要亲自动手。"* ## [07:38] Honk：基于 Claude Agent SDK 的后台编码智能体 简单的规则化脚本处理配置变更和依赖升级还算够用，但一旦涉及实际的代码修改就会力不从心。代码的 API 接口面非常宽——调用同一个方法的写法五花八门，当迁移脚本跑过数百万行代码和数千个仓库时，各种边界情况都会撞上（这种现象有个专门的名字：Hyrum 定律）。正是这种脆弱性，成了催生 Honk 的直接驱动力。 Honk 现在是一个基于 Claude 的编码智能体，运行在 Kubernetes pod 中，由 FleetShift 调度，并配备了 CI 工具，可以自行运行构建、捕获编译错误，在提 PR 前完成自我修正。以前需要多个团队花数月时间完成的 Java 版本迁移，现在一名工程师三天内就能搞定。 > *"与其写确定性脚本来做代码改动，能不能用 LLM 来完成这件事？……由此诞生了一个工具，我们现在叫它 Honk。"* ## [11:34] Honk V2 与多人协作智能体会话 Spotify 的工程师很快摸索出通过 Slack 调用 Honk 的方式——在对话中 @ 它，然后收到一个 PR。这种自发形成的使用模式推动团队向更具交互性的产品方向演进。Honk V2 在这次演讲前一天的黑客周期间以 alpha 版本发布，在原有批量迁移能力之上新增了两个层次。 第一层是与 Chirp 的集成——Chirp 是 Spotify 内部的智能体编排层，允许开发者并行运行多个 Honk 会话并统一协调。第二层是多人协作：多个开发者可以同时向同一个智能体实例提供反馈，被描述为"面向 Claude 的 Google Docs"。Projects 功能将这些会话组合成一个共享工作空间，追踪更长周期的目标。 > *"基本上可以想象一下，类似 Google Docs 的东西，不过是面向 Claude 的。"* ## [14:43] 标准化作为智能体基础设施 Spotify 十多年来一直遵循一个原则：技术选型越少，执行越快。收窄技术栈能减少决策疲劳，让跨团队协作更顺畅，让工程师在更小的技术面上深耕，而不是疲于维护宽泛的技术广度。Niklas 认为，同样的原则直接提升了智能体的表现。 机制是实证层面的：在技术栈更碎片化的代码库中，Spotify 观察到 Claude 产出质量明显下降；在技术栈统一的代码库中则表现更好。Backstage——他们的开发者门户和软件目录——是执行这一原则的层面。它暴露组件归属、技术雷达推荐，以及每类组件的"Golden State"规范。Soundcheck UI 让团队自评合规情况。关键的是，这些信息同样通过 MCP 服务器和 CLI 工具对外暴露，智能体可以直接查询。Honk 修改代码时，lint 检查会立即告知它是否用了不在雷达内的模式，Niklas 亲眼看到 Claude 在这些检查中实时自我修正。 > *"如果 Claude 有大量其他代码可以参考，而且这些代码大致一致，Claude 就会表现得更好。我们正在看到这一点。我们确实有一些碎片化程度更高的代码库，在这些代码库中，我们能看到 Claude 表现更差。"* ## [22:15] 当编程不再是瓶颈之后 Niklas 最后用一次视角重构收尾：AI 转型并没有消除产品研发的约束，而是移动了约束的位置。时间曾经花在写代码上；现在这个约束正在松动，瓶颈转移到了人的决策——该追哪个想法、哪些 PR 真的需要人工审查、哪些原型值得深化。 PR 审查方面，76% 的增幅意味着开发者被审查请求淹没。Spotify 的应对是自动批准低风险 PR，把人的注意力集中在真正重要的地方。原型开发方面，Spotify 现在允许任何人——包括高管——在客户端 monorepo 中打开 Claude，配上一套 skills 和基础设施，输入一个功能需求，几分钟内就能拿到一个可安装的应用，而不是等上数天。演讲结尾，Niklas 提到：六个月后，Spotify 的整个产品研发流程将与以往任何时期截然不同。 > *"Claude 和智能体让我们能够允许任何人在实际的生产代码库中做原型。……原本需要数天甚至数周的事情，现在真的只需几分钟。"* ## 实体 - **Niklas Gustavsson**（人物）：Spotify 首席架构师兼工程副总裁，在 Anthropic 的 Code with Claude 大会上发表了本次主题演讲 - **Honk**（软件）：Spotify 内部的后台编码智能体，基于 Anthropic 的 Agent SDK 构建，运行于 Kubernetes pod，与 FleetShift 集成以完成大规模迁移任务 - **FleetShift**（软件）：Spotify 的舰队管理与迁移编排平台，负责调度和追踪跨数千个代码仓库的自动化 PR，已自动合并 250 万个 PR - **Backstage**（软件）：Spotify 开源的开发者门户和软件目录，暴露组件归属、Golden State 合规信息及供智能体使用的 MCP/CLI 接口 - **Chirp**（软件）：Spotify 内部的智能体编排层，支持并发运行多个智能体会话，并协调多开发者共享会话 - **Hyrum 定律**（概念）：由一位 Google 工程师命名的原则——系统任何可观测的行为都会被某些用户所依赖，由此解释了为何通用迁移脚本在大型代码库中规模化运行时会频繁失效 - **Golden State**（概念）：Spotify 针对每类组件制定的推荐技术与实践规范，Soundcheck 以此衡量各组件的合规程度

Anthropic 的第二期 Claude Code 101 视频详细讲解了如何编写第一个提示词：如何在审批模式和自动接受模式之间选择，何时通过 shift+tab 进入计划模式，以及在"添加深色模式"这一真实任务中，一个优秀的提示词究竟长什么样。 ## [00:03] 像使用普通 AI 助手一样与 Claude Code 对话 开场定位刻意降低门槛——向 Claude Code 发送提示词，和向其他 AI 助手提问并无二致。核心观点是：按下回车前的那些决策，才是真正保护你、让工具更易用的关键。 > *You talk to Claude Code like you would talk to any AI assistant.* ## [00:15] 审批模式与自动接受模式（shift+tab） 开箱即用两种模式。默认审批模式下，Claude 在每次文件变更前都会征求确认。自动接受模式下，文件编辑和创建自动通过，但运行 shell 命令仍需你的许可。shift+tab 可在两者之间切换，无需翻找设置。讲师明确表示不会评判哪种"更正确"，选择符合你操作习惯的即可。 > *In auto accept mode, it will automatically approve an edit or creation of a file, but ask your permission to run commands.* ## [00:40] 计划模式：编写代码前的只读研究 同一个 shift+tab 菜单里还隐藏着第三种模式：计划模式。Claude 接收提示词后，使用只读工具遍历代码库，对模糊之处提出澄清问题，并在触及任何文件之前交付一份详尽的执行计划。适用场景包括多步骤功能实现和安全代码审查——任何你希望在 agent 动手前先审核方案的场合。 > *Plan mode takes your prompt and uses read-only tools to analyze your code base and do research on your suggested implementation.* ## [01:10] 实战演示：提示词实现深色模式切换 演示是视频的核心。从项目根目录出发，通过 shift+tab 切换到计划模式，然后写一个同时完成三件事的提示词：说明目标（"整个应用的深色模式"）、指定 UI（"在 header 上添加切换开关"），并加入一个需要 Claude 研究的约束（"根据我现有的浅色主题找一个合适的对比色"）。目标加界面加约束——这就是优质提示词的隐含模板。 > *Can you create a toggle switch on the header that allows user to toggle between light mode and dark mode?* ## [01:46] 回顾 Claude 实际完成的内容 Claude 返回计划并经用户确认后，最大价值在于可审计性：你可以清楚看到 Claude 做了什么，以及它是如何得出结论的。讲师目测渲染出的深色模式后表示认可——这隐含的教训是：对于低风险 UI 工作，"看起来不错"是完全合理的审查标准，前提是你真的看了。 > *At the end of all this, we can see explicitly what Claude did and how it came to its conclusion.* ## [02:09] 总结：描述要详尽，善用计划模式 最终经验法则：提示词尽量详尽，若希望 Claude 在执行前深入研究你的意图细节，就使用计划模式。如果你倾向于逐步掌控每个环节，审批模式可以让你全程参与。 > *When using Claude Code, try to be as descriptive as possible with your prompt.* ## Entities - **Anthropic Tutorial Narrator** (Person): Anthropic Claude Code 101 教程系列的官方配音讲师。 - **Claude Code** (Software): Anthropic 基于终端的 agentic 编程助手，本期提示词编写教程的主角。 - **Approval mode** (Concept): 默认模式，Claude Code 在每次文件变更前都会请求用户确认。 - **Auto-accept mode** (Concept): 自动批准文件编辑和创建，但 shell 命令仍需用户许可。 - **Plan mode** (Concept): 只读研究模式，在写入任何代码之前生成详细执行计划；通过 shift+tab 切换。 - **shift+tab** (Shortcut): 在 Claude Code 的审批、自动接受和计划模式之间循环切换的键盘快捷键。

Anthropic Claude Code 101 第二集深入引擎盖：收集上下文、采取行动、验证结果的智能循环；上下文窗口在溢出前如何自动压缩；工具相比纯文本输入输出带来了什么；以及用 shift+tab 切换的四种权限模式。 ## [00:04] 开篇问题：它与聊天应用有何不同 解说员将整段视频的核心归结为一个问题——Claude Code 不是聊天应用，那它的本质形态是什么？他们将要揭开的答案就是智能循环。 > *We know that Claude code is different from usual chat applications, but how does it work?* ## [00:13] 智能循环——收集、行动、验证、重复 循环有四个节拍。你输入一个提示词。Claude 通过与模型对话收集所需上下文，模型返回文本或工具调用。Claude 执行动作——编辑文件、运行命令。然后验证结果是否真正满足提示词要求。通过则停止；不通过则再次循环，直到工作完成且可验证。用户在此过程中不会被锁定——你可以在循环运行期间添加上下文、中断或引导模型走向目标。 > *And if they don't, Claude goes back and runs the loop again until the results are complete and verifiable.* ## [01:02] 上下文窗口与自动压缩 上下文窗口是 Claude 的工作记忆——对话内容、文件内容、命令输出，所有它能回溯的内容。它是有边界的。当触及上限时，Claude Code 会自主压缩对话：它决定丢弃什么、摘要什么，让窗口在不丢失线索的情况下重新降低。 > *Once you reach that limit, Claude code compacts your conversation, which automatically determines what it can take out of the context window and what it can summarize in order to bring the context window back down.* ## [01:26] 工具——语义调度以读文件、运行代码、搜索网页 大多数 AI 助手是纯文本输入输出，中间没有任何东西。工具改变了这一切——它们让智能体决定何时执行代码以推进目标。读取文件、搜索网页、运行 shell 命令。Claude Code 通过对可用工具进行语义搜索来选择调用哪个工具并消费其输出。 > *Tools let Claude code and other agents determine when to execute code to get closer to a task.* ## [01:52] 权限模式及跳过它们的代价 默认情况下，Claude Code 在编辑文件或运行 shell 命令前会先请求确认。shift+tab 可循环切换其他模式：**自动接受编辑**模式在不提示的情况下写入文件，但运行命令前仍会询问；**计划模式**将 Claude 限制为只读工具，在执行任何操作前可以起草行动计划。解说员指出了显而易见的权衡——赋予智能体完全自主权意味着错误在发生前更难被捕捉。 > *Giving Claude code free reign to run commands means a mistake could be harder to catch before even happens.* ## [02:28] 回顾——是什么让它不是聊天窗口 四个基本元素组合成一个终端：智能循环、托管上下文窗口、工具和可配置权限。这种组合——读取代码库、对其采取行动、验证自身工作——正是将 Claude Code 与聊天框区分开来的根本所在。 > *It can read your code base, take action, and verify its own work, and that makes it fundamentally different from a chat window.* ## 实体 - **Anthropic Tutorial Narrator** (Person): Anthropic Claude Code 101 教程系列的官方画外音解说员。 - **Claude Code** (Software): Anthropic 的智能终端编程助手，围绕本集拆解的四个基本元素构建。 - **Agentic loop** (Concept): 驱动每个 Claude Code 会话的收集上下文、行动、验证、重复循环。 - **Context window** (Concept): Claude 有边界的工作记忆，保存对话、文件内容和命令输出；溢出时自动压缩。 - **Tools** (Concept): 智能体可调用的副作用——读文件、搜索网页、运行命令——通过对工具目录进行语义搜索来选择。 - **Permission modes** (Concept): 默认模式（询问）、自动接受编辑和计划模式（只读）——用 shift+tab 循环切换。 - **Plan mode** (Feature): 一种只读权限模式，让 Claude 在任何变更前先编制行动计划。

Claude Code 官方安装指南。Anthropic 解说员逐一介绍支持所有平台的一行安装命令——终端、VS Code、JetBrains、Claude Desktop 和网页端——并在结尾给出选择使用方式的简明原则。 ## [00:04] 终端一行安装命令（macOS、Linux、WSL、Windows） 默认方式是终端安装。macOS、Linux 和 WSL 用户只需一条 `curl` 命令；Homebrew 也可以，但不支持自动更新。Windows 下，PowerShell 使用 `Invoke-RestMethod`，CMD 有独立的 `curl` 片段，`winget` 同样可用，但和 Homebrew 一样不支持自动更新。 > *If you're on macOS, Linux, or WSL, use this curl command to install it in one go. If you prefer to use Homebrew, you can also use brew install to install it, but note that this doesn't have auto-update capabilities.* ## [00:33] 在项目中运行 claude 并登录 安装完成后，`cd` 进入项目目录并运行 `claude`。首次启动会出现颜色主题选择和登录流程，支持 Pro、Max、Enterprise 或 API 密钥登录。Enterprise 账户需手动选择对应选项。启动时所在目录即为访问边界——Claude Code 可访问该文件夹及其所有子文件夹，不会越界访问上层目录。 > *Whatever directory you decide to run cloud in, it will have access to that directory and all of its subfolders.* ## [01:02] VS Code 扩展 打开扩展面板，搜索 Anthropic 发布的 Claude Code 扩展，安装前确认蓝色认证标识。可能需要重启。安装后，命令面板（`Ctrl/Cmd+Shift+P`）可打开新的 Claude Code 标签页；也可从任意打开文件点击 Logo，或在设置中完全关闭图形界面、仅使用终端体验。 > *You can also opt out of the UI and just use the terminal experience directly in your settings file.* ## [01:32] JetBrains 插件 步骤与 VS Code 相同：从 JetBrains Marketplace 安装 Claude Code 插件，重启 IDE 后 Claude 图标即出现在启动界面。点击图标会在编辑器旁打开侧边栏，呈现终端体验。 > *For JetBrains IDEs, you can install the Cloud Code plugin from the JetBrains Marketplace. Once you install, restart your IDE.* ## [01:51] Claude Desktop 与网页端 claude.ai/code 登录后，Claude Desktop 会在应用顶部显示"code"开关，从而开放 Claude Code 功能——交互方式与聊天界面相同，但限定在特定文件夹内运行，权限可调，还支持云端执行模式。网页版位于 `claude.ai/code`，体验与桌面端基本一致，唯一限制是仅支持 GitHub 仓库。 > *On the web, you can access Claude code by going to claude.ai/code. This works very similar to the desktop app. However, you're restricted to GitHub repositories only.* ## [02:27] 选择合适的使用方式 解说员的建议：优先用终端，能第一时间获取新功能。IDE 集成提供几乎相同的体验，集成在编辑器内。桌面端适合在 Claude 后台运行时自己做其他事。网页端适合远程操作 GitHub 仓库，或同时运行多个会话。 > *If you want to constantly keep up to date with everything, the terminal is the best bet. Features ship there the fastest.* ## Entities - **Anthropic Tutorial Narrator** (Person)：Anthropic Claude Code 101 课程的画外音主持人。 - **Claude Code** (Software)：Anthropic 的智能编程工具，支持终端、IDE、桌面端和网页端安装使用。 - **Homebrew / winget** (Software)：官方 curl/PowerShell 安装方式的替代包管理器路径，均不支持自动更新。 - **VS Code extension** (Software)：Anthropic 发布的 Claude Code 扩展，安装前需确认蓝色认证标识。 - **JetBrains plugin** (Software)：通过 JetBrains Marketplace 分发的 Claude Code 插件，IDE 重启后在侧边栏显示。 - **Claude Desktop** (Software)：桌面应用，通过"code"开关开放 Claude Code，支持文件夹限定和云端执行模式。 - **claude.ai/code** (Service)：Claude Code 的网页版，仅限 GitHub 托管的仓库使用。

Anthropic 的第二期 Claude Code 101 涵盖了将 Claude Code 从"陌生人"变成"队友"的核心文件：`CLAUDE.md`。内容包括：写什么进去、项目/用户层级如何划分职责，以及三个防止文件变成一堆过时规则的好习惯。 ## [00:02] 为什么 Claude Code 需要持久化记忆 没有 `CLAUDE.md`，每次会话都从零开始——Claude 必须重新遍历代码库、猜测依赖关系、重新发现已实现的内容。这些猜测正是难以精准引导模型的原因所在。该文件的存在就是为了在每次新会话时跳过这一重复的探索过程。 > *When you open up Claude Code without a claude.md file, it's like it has to start fresh every single time.* ## [00:34] CLAUDE.md 是什么以及 /init 命令 它是放在项目根目录的普通 Markdown 文件，每次会话启动时自动读取并追加到提示词末尾——相当于"代码库的入职脚本"。如果不想手写，`/init` 命令可以扫描现有代码生成初稿。示例文件由三个简短模块组成：技术栈（Next.js 15 app router、Tailwind、Drizzle ORM）、命令（开发服务器、测试、lint）和代码风格规则（2 空格缩进、具名导出、API 路由置于 `app/api`、优先使用 server actions）。加载这些配置后，第一次请求 React 组件就能直接得到符合项目风格的代码，无需反复纠正。 > *It's a markdown file that you add to the root of your project and Claude Code reads it automatically every time you start a session.* ## [01:34] 记忆层级：项目级与用户级 是的，应将其纳入版本控制——项目级 `CLAUDE.md` 是为整个团队服务的。但还有第二层：位于配置目录下的用户级 `CLAUDE.md`，它跟随你跨越所有项目。个人偏好——比如注释风格、惯用写法——放在这里，不会污染共享文件。 > *But there's actually a hierarchy of memory files depending on who it's for.* ## [02:01] 保持 CLAUDE.md 实用的三个技巧 讲师推荐的三个习惯。第一，当你需要反复纠正 Claude 某件事时（如"始终使用 server actions 而非 API routes"），明确要求它将该规则保存到记忆中，让修正跨会话生效。第二，用 `@filepath` 引用现有文档，而非复制粘贴内容到文件中。第三——看似反直觉——新项目开始时**不要**先写 `CLAUDE.md`，观察自己在哪些地方反复纠偏；只有那些摩擦点才值得写进去。这样才能保持文件精简而不臃肿。 > *We recommend you start off a project without a claude.md file so you can see where you have to constantly course correct the model.* ## [02:39] 总结：上下文决定一切 一句话总结：让会话令人沮丧还是高效的差距在于上下文，而 `CLAUDE.md` 就是传递上下文的载体。从小处着手——技术栈、偏好、命令——在真实摩擦中逐步完善。 > *Start with your stack, your preferences, and then commands, and just build from there as you go.* ## 实体 - **Anthropic 教程讲师** (Person): Anthropic 官方 Claude Code 101 系列的解说主持人。 - **CLAUDE.md** (Concept): 放在项目根目录的 Markdown 文件，Claude Code 每次会话自动加载，将持久化上下文追加到用户提示词中。 - **/init** (Command): Claude Code 命令，通过扫描现有代码库生成初始 `CLAUDE.md`。 - **项目级与用户级 CLAUDE.md** (Concept): 两层记忆层级——项目文件位于仓库根目录并通过版本控制共享；用户文件位于配置目录，携带个人偏好跨项目使用。 - **@filepath 引用** (Concept): 在 `CLAUDE.md` 中指向现有文档文件的语法，避免重复内容。 - **Next.js 15 / Tailwind / Drizzle ORM** (Software): 教程示例 `CLAUDE.md` 中使用的技术栈，用于展示真实文件的样子。

Anthropic 对 Claude Code 中 Model Context Protocol 的完整讲解：它能连接哪些外部资源、如何添加和划定服务器作用域，以及每个已配置服务器在上下文窗口上悄悄产生的隐性开销。适合正准备将 Claude Code 接入 Linear、GitHub 或内部工具的开发者。 ## [00:02] MCP 存在的意义——上下文在编辑器之外 开门见山：Claude Code 所需的大部分上下文并不在代码仓库里，而是散落在数据库、生产力应用和公共包中。MCP 是一套开放标准，让 Claude 自行决定何时调用这些外部来源，而不是等你手动粘贴进来。 > *Model Context Protocol 是一套开放标准，让 Claude Code 能连接到外部工具和数据源。* ## [00:35] 工具，以及 MCP 服务器究竟接入了什么 在列举具体服务器之前，讲解者先厘清了"工具"这个概念：Claude Code 这类 agent 借助工具来执行动作，这正是它们区别于只会返回文本的普通对话的地方。接着给出两个具体例子——一个 Linear MCP 服务器可把团队 issue 拉进会话，Context7 服务器则能实时推送当前依赖的最新文档。更多连接器可在 claude.com/connectors 找到。 > *工具赋予 Claude Code 这样的 agent 执行动作的能力，让它们能更好地完成任务。* ## [01:14] 添加服务器：HTTP 与 STDIO，以及 /mcp 服务器通过 `claude mcp add` 添加，分为两种类型：**HTTP** 服务器由服务商远程托管，通过网络访问；**STDIO** 服务器是本地进程，运行在自己的机器上。安装完成后，会话内的 `/mcp` 命令可以列出已连接的服务器、查看状态，并随时停用不需要的服务器。 > *HTTP 服务器用于远程服务……STDIO 服务器用于在本机运行的本地进程。* ## [01:42] 三种作用域：local、user 与 project（.mcp.json） 每个服务器都属于三种作用域之一。**local** 将服务器限定在当前项目且仅对自己可见；**user** 让服务器在你所有项目中都可用；**project** 会生成一个 `.mcp.json` 文件并提交到版本控制，这样所有参与该项目的团队成员都会自动获得相同的服务器配置。 > *project 作用域使用 .mcp.json 文件，你将其提交到版本控制后，所有参与该代码库的人都会自动获得完全相同的服务器配置。* ## [02:04] 工具定义会消耗上下文——何时应优先选用 CLI 或 skill 连接器列表背后有一个容易被忽视的代价：每个已配置的 MCP 服务器都会把自己的工具定义注入上下文窗口，无论你是否正在使用它。讲解者给出几层应对策略——用 `/mcp` 停用闲置服务器；如果有 `gh` 或 `aws` 这样的 CLI 可用，优先选它，因为 CLI 不会携带持久性工具定义；或者把工作流封装成 skill，只有 Claude 决定调用时才会加载完整内容。当 MCP 工具定义超过上下文的 10% 时，Claude Code 会切换到工具搜索模式按需发现工具——虽然有用，但不如预加载可靠。 > *MCP 服务器会把工具定义加入上下文窗口，即使你并未使用它们。所以配置了大量服务器时，会大量占用可用上下文。* ## [03:10] 小结 三件要记住的事：`claude mcp add` 安装服务器，`.mcp.json` 与团队共享服务器配置，`/mcp` 用来清理那些实际没在用的服务器。 > *用 Claude MCP add 添加服务器，用 .mcp.json 将其限定到项目范围以便团队自动获取，并通过停用不在用的服务器来控制上下文占用。* ## 实体 - **Anthropic 教程讲解者** (Person): Anthropic 为 Claude Code 101 系列官方配音的讲解者。 - **Model Context Protocol (MCP)** (Standard): 开放协议，让 Claude Code 通过 HTTP 或 STDIO 服务器连接外部工具和数据源。 - **Linear MCP server** (Software): 将团队 Linear issue 引入 Claude Code 会话的连接器。 - **Context7 MCP server** (Software): 为 Claude Code 提供当前所用依赖最新文档的连接器。 - **.mcp.json** (Config): 提交到版本控制的项目级配置清单，让每位团队成员继承相同的 MCP 服务器配置。 - **/mcp** (CLI command): 会话内命令，用于列出、查看和停用已连接的 MCP 服务器。 - **Tool search mode** (Feature): 当 MCP 工具定义超过上下文窗口 10% 时，Claude Code 进入的回退模式，按需发现工具。 - **Skill** (Concept): 完整 MCP 服务器的轻量替代方案；在 Claude 按需加载主体之前，上下文中只存放其名称和描述。

Fiona Fung 负责 Anthropic 旗下 Claude Code 与 Cowie 的工程和产品，她分享了当 Agentic 编程成为团队默认工作方式后，哪些环节出了问题——代码评审、所有权、规划、招聘——以及为了持续交付他们重写了哪些规范。核心逻辑：当编码不再是瓶颈，所有围绕保护昂贵工程带宽而建立的流程就会悄然失效，管理者的职责是快速察觉并重写它们。 ## [00:00] 开场与五大主题 Fiona 开场坦言现场人数远超预期（Boris 和 Jared 的场次还没散），顺势和观众自拍，然后介绍背景：她曾在 Meta 和 Microsoft 带团队，现在负责 Claude Code 与 Cowie 的工程和产品。这套演讲稿一个月前刚写完就已经改过一轮——最初写稿时例程（Routines）功能还不存在。她预告了五条主线：瓶颈已经迁移、团队规范不得不重写、如何推行这些变化、哪些信号证明变化奏效，以及她仍在思考的待解问题。 > *"这套 PPT 大概一个月前做好，内容已经改过了，因为当初写的时候根本没有例程这东西。"* ## [02:10] 转变：瓶颈已经迁移 Fiona 给整场演讲定了一个副标题：*过去管用的，现在未必还管用*。她把听众带回当年用光盘发货的 Visual Studio 2005——制造车间要压盘，截止日期硬得像石头——再指出从光盘到在线分发已经重塑了团队的交付节奏。这次的转变更彻底：多年来编码产能和工程师带宽是最贵的稀缺资源，而这一点在 Claude Code 团队悄然改变了。瓶颈在转移，并不是消失，而是迁移到了验证、评审、跨职能交接和安全合规。现在真正重要的问题是"代码对不对"和"安不安全"，旧有的规划与所有权规范悄然失去了意义。 > *"过去管用的，现在未必还管用。"* ## [07:40] 重写团队规范：代码评审、JIT 规划、技术争论 Claude Code 团队不得不逐条重写规范。第一条是代码评审——人的判断力转向"这段代码真的需要谁来看"。第二条是规划——Fiona 称之为 JIT 规划，类比 JIT 编译，因为原型验证不再是那个需要六个月路线图来保驾护航的昂贵步骤。第三条是技术争论：用代码说话。两个工程师不需要在文档里互相说服，各自原型化 API、看对调用方的影响，Fiona 也明确表示她同样关心 API 对下游的影响，不只看实现本身。统一的原则是：当构建成本低、争论成本高，不能让最后一个提交代码的人赢——要建立让*你*拥有最终话语权的例程。 > *"当构建便宜、争论昂贵，这又会怎样改变你的团队规范？"* ## [13:30] 例程与 Claude 作为第二双手 现在 Fiona 早上喝咖啡时读的是例程（Routines）跑了一夜的产出，而不是自己亲手启动工作。团队重度依赖 Claude 做代码评审——Claude 盯着 PR、处理代码风格、lint、反馈请求，在提交前发现 bug，补充测试——人则专注于还需要建立信任的那些判断场景。她还强调工具的产品感：她曾把 Claude 的终端输出主题配成节日冰蓝色加雪花，随即话锋一转说更重要的是更早发现 bug（左移）和自动化那些"点两下才能回答"的问题，这些比任何单一工具都值钱。 > *"哪些地方你非常信任 Claude，哪些地方你还是希望有人类来把关？"* ## [16:45] 跨职能缺口与招聘策略 Fiona 分享了一个用户调研的故事：团队没有专职内容设计师，于是 Claude 成了她的搭档，负责撰写简洁、适合终端场景的文案。与此同时，团队里的 PM 写代码，工程师也承担 PM 的工作。这引出了招聘的反向结论：非传统背景的程序员现在能做更多工程工作，所以领导者要把招聘火力集中在团队真正欠缺的硬核能力上。她刚加入时，Claude Code 团队产品通才和创意型人才充足，但分布式系统专家严重不足——那正是她主攻的招聘方向。 > *"有了 Claude，非传统背景的程序员现在能做更多工程工作，工程师也可以更多地承担其他角色。"* ## [18:51] 扁平组织与亲自回应客户反馈 Fiona 给招聘方出了道难题：招聘经理，但要求他们先以 IC 身份入职。招聘方觉得她疯了；Fiona 的回答是，吃自家狗粮、亲身使用 Claude Code 本身就是这份工作的一部分，如果候选人对此没有热情，早点知道对团队是好事。扁平的组织结构加上 Claude 作为上下文切换的助力，让她这个管理者仍然能在桌面 Claude Code 上亲自写代码、直接回应客户请求——而不是把每个客户问题都转进工单系统，她直接拉开本地代码仓库，自己回答。 > *"你想招经理，但他们要先从 IC 做起。没有经理会愿意这样的。"* ## [25:00] 走势向好的信号与待解问题 团队的工作度量指标朴实无华：每次提交默认都是 Claude 协助完成，Fiona 大约四个月没见过一次非 Claude 辅助的提交了。但她同时警告不要迷恋"AI 生成了 X% 的代码"这种标题——吞吐量是一个信号，不是目标。最终要问的问题是你在让什么产品变得更令人愉悦、在解决什么问题，质量和可靠性要和数量一起盯。她以"审计自己的投入"收尾，提出她仍在问自己的问题，并把建议递给听众，请他们带回各自的团队思考。 > *"在我们这里，每次提交默认都是 Claude 协助完成的。我大概四个月没见过一次非 Claude 辅助的提交了。"* ## 实体 - **Fiona Fung**（人物）：Anthropic 工程总监，负责 Claude Code 与 Cowie 的工程和产品；曾在 Meta 和 Microsoft 带团队。 - **Boris**（人物）：Claude Code 工程负责人，演讲中多次提及的合作者。 - **Kat**（人物）：Anthropic 同事，同日早些时候做了 Claude 代码评审主题的主题演讲。 - **Claude Code**（软件）：Anthropic 开发的 Agentic 编程工具，现为 Fiona 团队的默认工作方式。 - **Cowie**（软件）：Fiona 团队同时负责工程和产品的姊妹产品。 - **Anthropic**（机构）：构建 Claude 与 Claude Code 的公司。 - **JIT planning**（概念）：Fiona 提出的规划方法，从六个月路线图转向即时规划，类比 JIT 编译。 - **Shift left**（概念）：将 bug 发现和验证前移——通过自动化和工具提前拦截，而非事后评审。 - **Routines**（概念）：团队依赖的、可重复的 Claude 驱动工作流，确保单个人对结果拥有最终话语权，而不是"最后提交者获胜"。

Anthropic 对 Claude Code Hooks 的简短演示——这是一种确定性的"逃生舱口"，用于那些在每次编辑、每次工具调用、每次提交时都必须执行的操作。核心理念：如果你在 claude.md 里写了"始终运行 prettier"并寄希望于模型，那你已经输了；把它移到 Hook 中去。 ## [00:02] 什么是 Hooks 以及为何具有确定性 Hooks 在 Claude Code 生命周期的固定时间点触发，讲解者的核心论点是：与提示级别的指令不同，Hooks 始终会执行。在 claude.md 中告诉模型在每次文件编辑后运行 prettier，大多数时候会奏效——但"大多数时候"正是 Hook 所要填补的空缺。意图相同，但由运行时强制执行，而非向 LLM 建议。 > *You can tell Claude in your claude.md file to run prettier after every file edit and most of the time it will do that, but sometimes it won't. It's not perfect. But a hook makes it happen every single time with no exceptions.* ## [00:37] 常见使用场景 四个典型示例划定了应用范围：文件编辑后自动格式化、记录所有执行命令以满足合规要求、阻止危险操作（如修改生产文件），以及在 Claude 完成长时间任务时向自己发送通知。 > *Common use cases could include auto formatting after file edits, logging all executed commands for compliance, blocking dangerous operations like modifying production files, and sending yourself notifications when Claude finishes a task.* ## [00:52] 配置 Hooks 与五个生命周期事件 配置写在 `settings.json` 中：选择一个事件，可选择用匹配器限定它适用于哪个工具，再提供一条 Shell 命令。五个事件覆盖整个循环——`UserPromptSubmit` 在 Claude 看到提示之前触发，`PreToolUse` 和 `PostToolUse` 包裹每次工具调用，`Notification` 在 Claude 向用户发送通知时触发，`Stop` 在 Claude 完成响应时触发。 > *Pre-tool use which runs before a tool call, post-tool use runs after a tool call completes. Notification runs when Claude sends a notification, and stop runs when Claude finishes responding.* ## [01:22] 使用 post-tool-use hook 自动格式化 典型示例：一个匹配器为 `Edit` 或 `MultiEdit` 的 `PostToolUse` Hook，在 Claude 修改文件时触发。该命令检查文件扩展名并路由到正确的格式化工具——TypeScript 用 prettier，Go 用 gofmt，Python 用 ruff，或项目统一规定的任何工具。 > *You set a post-tool use hook with a matcher of edit or multi-edit, right? So, it fires whenever Claude modifies a file. The command checks the file extension and runs the appropriate formatter.* ## [01:49] 用 pre-tool-use 和退出码阻止工具调用 `PreToolUse` Hook 通过 stdin 以 JSON 形式接收工具名称和输入，并通过退出码决定执行结果：`0` 表示继续，`2` 表示阻止。当 Hook 阻止操作时，它写入 stderr 的内容会作为反馈传回给 Claude，让模型知道原因并调整计划。这正是执行硬性规则的地方——阻止写入生产配置目录、拒绝包含 `rm -rf` 的 bash 命令、阻止向 main 分支提交。讲解者的观点：这些是团队需要保证的事情，而不仅仅是建议。 > *If it exits with code two, the action is blocked and the STD error message gets fed back to Claude's feedback so Claude knows why it was blocked and can adjust.* ## [02:26] 项目级 Hooks 与团队共享 `.claude/settings.json` 中的 Hooks 是项目范围的，可以提交到代码仓库，这意味着整个团队在克隆后会自动继承它们。通过 `CLAUDE_PROJECT_DIR` 环境变量引用脚本，确保无论 Claude 的当前工作目录在哪里，命令都能正确解析。最终原则：如果某件事每次都必须执行，不要把它写在提示里——把它放到 Hook 中。 > *If something needs to happen every time without fail, don't put it in a prompt. Put it in a hook.* ## Entities - **Anthropic Tutorial Narrator** (Person): Anthropic Claude Code 101 系列教程的官方解说员。 - **Claude Code** (Software): Anthropic 的智能终端编码工具，Hooks 在其生命周期事件中插入运行。 - **Hooks** (Concept): 在 Claude Code 循环固定时间点触发的确定性命令——提示级指令的运行时强制替代方案。 - **settings.json** (Configuration): Hooks 声明的位置；项目根目录下的 `.claude/settings.json` 提交到仓库，供团队共享相同规则。 - **PreToolUse / PostToolUse / UserPromptSubmit / Notification / Stop** (Events): Hook 可附加的五个生命周期事件。 - **CLAUDE_PROJECT_DIR** (Environment variable): 在 Hook 命令中用于引用项目相对路径脚本，与 Claude 当前工作目录无关。

Anthropic 官方对 Claude Code 的全面介绍——它是什么、与 Claude.ai 有何不同，以及在让 LLM 对代码库执行命令之前你需要了解的三件事。面向即将首次安装该终端工具的开发者。 ## [00:04] Claude Code 是什么以及在哪里运行 Claude Code 被定位为一款智能编程工具：它理解你的代码库、编辑文件、运行命令，并与你已在使用的开发者工具集成。它支持多种界面——终端、VS Code、JetBrains IDE、Claude 桌面应用以及网页端——但本次演示以终端作为标准体验。 > *Claude Code is an agentic coding tool that understands your code base, edits your files, run commands, and integrates with your existing developer tools to help you get things done faster.* ## [00:34] 它与 Claude.ai 有何不同 关键区别不在于模型能力，而在于访问方式：Claude Code 可直接深入你的终端和整个代码库，复制粘贴到聊天窗口的循环从此消失——该工具在原地完成工作。称其为"AI 智能体"正是对这种直接执行能力的概括。 > *Unlike Claude AI, Claude Code has direct access to your files in your terminal and your entire code base.* ## [00:51] AI 智能体与 Claude Code 能做什么 这里的 AI 智能体是指能与环境交互、采取行动以实现既定目标的软件——最基本的形式是一个在实时循环中运行、可访问工具、外部服务和其他智能体的 LLM。对于 Claude Code 而言，这意味着具体能力：读取并解释你的代码库、跨文件追踪 bug、运行构建脚本和测试、安装软件包，以及从网络获取最新的 API 文档来决定下一步操作。 > *An AI agent is a software that can interact with its environment and perform actions to complete a defined goal.* ## [01:45] 开始前需了解的三个概念 讲解者指出了三个影响日常使用的属性。第一，**上下文窗口**是 Claude 的工作记忆——容量大但有限——这就是为什么智能体需要战略性地浏览代码库而不是全部加载。第二，Claude Code 在运行命令或修改文件前会**请求许可**；无论你是想掌控每一步还是让它基本自主运行，控制权始终在你手中。第三，它**可能出错**：误解意图、引入 bug 或过度设计解决方案。像对待任何工具的输出一样对待它，而非奉为圭臬。 > *By default, Claude Code will ask you before running commands or making changes to your code base.* ## [02:34] 总结 Claude Code 是一款智能编程工具，可读取你的代码库、编辑文件、运行命令并连接外部工具，帮助你更快交付——现已支持终端、VS Code、JetBrains 和 Claude 桌面应用。 > *Claude Code is an agentic coding tool. It reads your code base, edits your files, runs commands, and connects to external tools to help you ship faster.* ## 实体 - **Anthropic Tutorial Narrator** (Person): Anthropic 为 Claude Code 101 系列教程录制的官方旁白配音员。 - **Claude Code** (Software): Anthropic 的智能终端编程助手，可直接对你的代码库进行操作。 - **Claude.ai** (Software): 基于聊天的 Claude 产品——与 Claude Code 的环境内执行方式形成对比。 - **AI agent** (Concept): 在实时循环中运行、可访问工具、外部服务和其他智能体以追求既定目标的 LLM。 - **Context window** (Concept): Claude 的工作记忆——有限，这就是智能体选择战略性导航而非加载完整代码库的原因。 - **VS Code / JetBrains IDEs** (Software): Claude Code 支持的编辑器集成，与终端和 Claude 桌面应用并列。

Anthropic 三分钟演示了他们认为使用 Claude Code 时最重要的习惯：先在计划模式中调研，在触碰任何文件前明确"完成"的定义，然后在推送前让子代理审查差异。 ## [00:03] 为什么探索-计划-编码-提交优于直接动手 开场直截了当——如果你只从课程中养成一个习惯，就选这个工作流。它要对抗的失败模式是：把任务直接粘贴给 Claude，然后看它立刻生成代码——速度快，但后期纠错成本高。 > *Without this, most people jump straight to pasting in Claude to write code, which means more course correcting later on.* ## [00:21] 计划模式：编辑前的只读调研 计划模式将探索和计划合并为一步。Claude 可以读取文件、执行网页搜索，但不允许写入——在提示符处按 Shift+Tab 即可切换。演示者展示了一个真实需求（在图片上传流水线中添加 WebP 转换，找出它的位置、所需依赖和实现思路）。Claude 返回一个计划，你阅读后若发现遗漏可要求修改。这是整个周期中改变方向成本最低的地方，因为还没有写任何代码。 > *With plan mode, Claude can't edit files. It just reads files to gather research on how to tackle this implementation.* ## [01:11] 批准计划，然后在 Claude 编码时随时纠偏 计划确认后，批准操作将执行权交回给 Claude，逐一完成清单。你可以选择文件编辑自动接受还是每次都提示确认。Claude 会自行排查问题，但也要准备好干预——计划模式在这里发挥的价值是：代理携带了生成计划时的调研上下文，因此中途纠偏能落在正确位置，而不是从头开始。 > *This is the benefit of working with plan mode because after the plan is finished, we also have the context of how it got to the results to help it guide its next decision.* ## [01:39] 明确成功标准并为 Claude 提供真实工具 没有"正确"定义的计划会让 Claude 凭猜测行事。明确说明成功的样子，然后为代理配备真正能验证的工具：Claude+Chrome 扩展程序可以驱动浏览器标签页测试刚刚构建的 UI；测试套件为每次循环提供验证基准，Claude 也可以编写测试——但前提是你已经将其作为基准事实审核过。一个耐久性小技巧：当 Claude 反复遇到同一个问题时，让它把修复方案持久化到 CLAUDE.md 文件中，避免反复重新学习。 > *In order for Claude to be confident in its results, it has to be clear on what it deems correct.* ## [02:24] 子代理审查、提交与回顾 推送前，针对差异启动一个子代理代码审查者——第二轮审查对实现方式没有任何执念。然后让 Claude 按你的风格起草提交信息并提交。回顾阶段重新定义了每个步骤：探索提供上下文，计划定义成功，编码是向计划收敛的来回迭代，提交则是审查并推送，让你继续前进。 > *A tip before you commit, run a sub agent code reviewer to look at your code.* ## Entities - **Anthropic Tutorial Narrator** (Person): Anthropic Claude Code 101 课程的官方旁白。 - **Claude Code** (Software): 以本集为主题的、推荐日常使用工作流的代理终端编码工具。 - **Plan mode** (Feature): 通过 Shift+Tab 切换的只读模式——Claude 调研并提出计划，但不能编辑文件。 - **Claude + Chrome extension** (Software): 让 Claude Code 驱动 Chrome 标签页，在宣布任务完成前验证 UI 变更。 - **CLAUDE.md** (File): 项目记忆文件，在此用作持久化反复重学的修复方案的目标文件。 - **Subagent code reviewer** (Pattern): 提交前的 Claude 子代理，在人工推送前审查差异。

Anthropic 的 Claude Code 101 系列视频关于上下文的讲解——什么会填满上下文窗口、自动压缩何时触发，以及保持会话精简所需的实用手段（/compact、/clear、/context、claude.md、MCP 开关、技能、子代理）。 ## [00:03] 为什么上下文是有限的，以及为何重要 上下文是 Claude 的工作记忆：每条提示词、每次文件读取、每次工具调用结果都落入同一个窗口。窗口虽大但有限，一旦开始运行多步骤会话，优化输入内容就是必须的。 > *Every file it reads, every command it runs, every message you send, it all takes up space in the context window.* ## [00:39] 自动压缩与 /compact 命令 接近限制时，Claude Code 会自动压缩：总结重要内容并丢弃嘈杂的工具调用结果以释放空间。你也可以手动触发 `/compact`——在想保留工作记忆但需要更多空间时很有用。权衡点：压缩可能丢失早期轮次的细节。 > *Compaction will summarize important details and remove the unnecessary tool call results and free up a lot of space in your context window.* ## [01:11] /clear 与 /context：重新开始与查看已用空间 如果想彻底重置、不保留任何先前会话记忆，`/clear` 会清空一切。要查看空间实际消耗在哪里，`/context` 会显示总大小、占用最多的类别以及分布图——在决定压缩还是清除之前，先用它来诊断。 > *To check the state of your context, run the /context command.* ## [01:35] 经验法则：功能进行中压缩，功能切换时清除 解说员给出了清晰的启发式规则：还在处理同一个功能、快触到上限了？压缩——你需要相关历史延续下去。计划已完成、要开始新内容了？清除——旧对话会对新工作产生偏差。 > *If you have finished the plan and want to start on a new feature, then clear. You don't want the previous conversation to present bias in anything new that you want to create.* ## [01:57] claude.md、提示词精确性与以多换少 Claude 应跨会话记住的内容都应放入 `claude.md`，避免每次重新发现相同事实。而反直觉的是，简短的提示词反而消耗更多上下文：问题模糊时，Claude 会在代码库中大量 grep 并进行更多推理，这些都会填满窗口。多写一两句具体说明，往后可节省大量空间。 > *The irony behind writing a smaller prompt is that it in the long run, it will take up more context.* ## [02:26] MCP 服务器、技能与子代理作为上下文管理工具 MCP 服务器默认将其暴露的所有工具加载到上下文中——与项目相关时没问题，无关时代价高昂，因此关闭与项目无关的服务器。技能的行为类似 MCP 服务器，但不会将整个工具面加载到上下文。子代理在并行中运行，拥有各自独立的窗口，因此对于事实查找任务（"认证端点在哪里？"），可以派遣子代理，只取回答案而非整个探索过程。 > *Sub agents run in parallel with your main agent but has a complete separate context window.* ## [03:06] 回顾总结 在 Claude Code 中管理上下文，决定了一次会话是高效持久还是停滞不前。使用 `/compact` 压缩长会话，使用 `/clear` 重新开始，提示词要具体，用 `/context` 查看窗口消耗，将只需答案的工作委托给子代理。 > *Managing context within cloud code is crucial. Use slash compact to summarize long sessions and slashclear to start fresh.* ## 实体 - **Anthropic Tutorial Narrator** (Person): Anthropic 官方 Claude Code 101 教程系列的旁白配音。 - **Claude Code** (Software): Anthropic 的代理终端编程助手，本集主题即其上下文窗口。 - **Context window** (Concept): Claude 的工作记忆——有限，由提示词、文件读取与工具调用结果填充。 - **/compact** (Command): 用于总结历史并丢弃工具调用噪声以释放空间的斜杠命令（也可自动触发）。 - **/clear** (Command): 彻底清除会话的斜杠命令，用于在新工作上干净起步。 - **/context** (Command): 报告上下文总大小及各类别占用情况的斜杠命令。 - **claude.md** (File): 项目级记忆文件，Claude 跨会话读取，避免重复发现相同事实。 - **MCP servers** (Software): 工具提供者，默认将所有暴露的工具加载到上下文中——无关时应关闭。 - **Skills** (Feature): MCP 服务器的轻量替代方案，避免将整个工具面加载到上下文。 - **Sub agents** (Feature): 拥有独立上下文窗口的并行代理，用于回答范围明确的问题而不污染主窗口。

子智能体在中间过程不需要留在主线程时最能发挥作用——但无差别地委派任务反而会让事情更糟。本教程划清了有效委派（调研、代码审查、领域专属系统提示词）与常见反模式（专家人设声称、顺序流水线、测试运行器）之间的边界，后者只会消耗上下文、丢失真正需要的信息。 ## [00:03] 引言：子智能体的适用场景与误用场景 本系列前几集讲了如何创建和设计子智能体。最后一集转向部署层面的问题：哪些任务真正值得派生独立智能体，哪些任务反而会因此受损？ 判断标准归结为一个测试：中间过程对主线程重要吗？探索与执行分离时，子智能体物有所值；而当每一步都依赖上一步的发现时，交接代价恰好是你最需要的那些细节。 > *"Simply put, the difference comes down to whether the intermediate work matters to your main thread."* ## [00:32] 调研任务：让探索过程保持隔离 身份验证追踪是一个具体示例。主线程需要知道 JWT 验证发生在哪里——而不是沿途读过的十几个文件。调研子智能体可以扫描整个代码库、跨文件追踪函数调用，最终返回一个精确答案：JWT 验证位于 middleware/auth.js 第 42 行，由 route/api.js 调用。 所有探索过程都锁在子智能体的上下文里。主线程拿到结论就继续推进，搜索历史不会堆满它的窗口。 > *"Your main thread receives JWT validation happens in middleware/auth.js at line 42, called from the Express router and route/api.js, or something like that."* ## [01:15] 代码审查子智能体：以全新视角给出反馈 Claude 审查自己参与编写的代码时存在偏见——它经历了每一个决策，很难从外部视角发现问题。审查子智能体从根本上绕开了这一点：它只看到 diff 和修改后的文件，完全不知道代码是如何演化而来的。 这种"白板状态"还带来第二个好处。项目专属的审查标准——命名规范、安全模式、架构规则——可以一次性写进子智能体的系统提示词，持续稳定地应用，而无需主线程轮次内一遍遍记住它们。 > *"A reviewer sub agent sees the changes in a separate context. It runs get diff, reads the modified files, and applies its specialized review criteria without the history of how the code was written."* ## [01:59] 自定义系统提示词：文案撰写与样式定制 Claude Code 的默认提示词针对简洁、技术性输出做了优化——这对落地页或营销邮件来说恰恰是反效果。文案子智能体拥有完全不同的语气、受众和结构指令，能生成主线程默认设置绝对产出不了的内容。 同样的逻辑适用于 CSS。样式子智能体在提示词里引用设计系统文件，写第一行代码前就自动加载颜色变量、间距规范和组件模式，确保每个样式决策都反映真实的系统，而非合理猜测。 > *"Claude Code's default prompt tends towards concise, technical writing, which really isn't what you want for a landing page or email campaign, unless you want to put your customers to sleep."* ## [02:57] 反模式：专家声称、流水线与测试运行器 三种模式会稳定地让结果变差。第一，人设提示词——"你是 Python 专家"或"你是 Kubernetes 专家"——毫无用处，因为 Claude 本来就具备那些知识。单独派生子智能体只为贴一个专家标签，既承担了隔离开销，又没带来主线程自己做不到的任何东西。 第二，顺序流水线在步骤间并非真正独立时就会崩溃。三段式流程——复现 bug、调试、修复——听起来清晰，实际却行不通：调试智能体需要的是复现智能体的实时上下文，而不是它压缩后的摘要。 第三，测试运行器子智能体会主动隐藏信息。测试失败时，你需要原始输出来诊断问题。只返回"测试失败"的子智能体迫使你额外编写调试脚本，才能还原直接输出本来就会展示的细节。 > *"A sub-agent that returns a test failed forces you to create additional debug scripts to get details that would have been visible in direct output."* ## [04:10] 系列回顾与核心决策启发式 纵观本系列：子智能体是通过 /agents 创建的隔离线程，返回摘要，设计时采用结构化输出和具体描述。适合用于调研、代码审查，以及需要自定义系统提示词的任务；不适合用于专家人设声称、多步依赖流水线和测试执行。 整个框架浓缩为一个问题：中间过程重要吗？如果不重要，就委派出去。 > *"The key question, does the intermediate work matter? If not, then delegate it."* ## 实体 - **Anthropic Tutorial Narrator**（人物）：Claude Code 子智能体教程系列主讲人，来自 Anthropic - **Claude Code**（软件）：Anthropic 的 AI 编程助手；创建和编排子智能体的运行环境 - **Subagent**（概念）：从主上下文派生的隔离 Claude 线程，返回压缩摘要，而非暴露完整的工作上下文 - **JWT（JSON Web Token）**（概念）：作为调研子智能体在代码库中追踪身份验证逻辑的实操示例 - **System prompt**（概念）：子智能体专属指令集，支持与 Claude Code 默认提示词不同的领域专属行为 - **Anthropic**（组织）：Claude 和 Claude Code 子智能体教程系列的开发者