Claude Code一周年复盘：工程师开始指挥Agent队伍丨Claude
输入“/”快速插入内容
Claude Code一周年复盘：工程师开始指挥Agent队伍丨Claude
Claude Code一周年复盘：工程师开始指挥Agent队伍丨Claude
用户4242用户42426月13日修改
原创 Capihom Capihom 晚点再听LaterCast2026年6月12日 21:47 北京
我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。
全文约 3500 字，如果你现在没有时间，试试转成播客稍后再听
"每次 Claude 犯错，我不会告诉它下次别这样做；我会让它把做法写进 CLAUDE.md，或者做成一个技能。"
"验证 Agent 时，人们想到单测、lint 和类型检查；他们真正要问的是：Agent 能不能把东西跑起来。"
"未来到底是产品还是工程？每个人都会同时做两件事。"
Claude Code 正式发布一周年，Anthropic 找来 Claude Code 负责人 Boris Cherny 和产品负责人 Cat Wu 复盘这一年，讨论了工程团队的工作方式怎么变化。最早的内部 Slack demo 只有两个人点了反应；一年后，Boris 已经在同时驱动“一棵由上千个 Agent 组成的树”。Cat 则讲到桌面应用、设计、PM、财务和数据科学团队怎么把 Claude Code 放进日常流程。读这期，最有用的地方不在功能清单，而在 Anthropic 自己怎么判断：当 Agent 能运行、能验证、能写回经验，人的工作会从亲手执行，转向设计循环、挑选想法和守住边界。
一年后，Claude Code 变成一支队伍
Boris 回忆第一次发布 Claude Code 时，自己把小视频发到 Slack，只有两个人点了反应。Cat 说，当时它做一些很容易的工程任务还不错。Boris 接着打趣：这是很委婉地说，它其实还没有那么好。短短一年后，画面已经完全不同。他不再只和一个 Agent 对话，而是让一个 Agent 去提示另一个 Agent，再继续分叉出去，形成一棵上千个 Agent 的树。 工程师的负载没有简单减少，控制台从“我写代码”变成“我调度一群会写代码的执行者”。
"现在我有一支 Agent 军队在做事，一个 Agent 提示另一个 Agent，再提示更多 Agent，像一棵有上千个 Agent 的树。"
这段复盘把 Claude Code 的变化讲得很清楚：早期卖点是“能不能帮我改一段代码”，现在的关注点已经变成“能不能长期运行、互相分工、自己补齐流程”。如果工程团队还只把它当成一个更聪明的 autocomplete，就会错过它真正进入组织流程的方式。Boris 说得更直接：只要把错误写回系统，Claude 就能“run forever”。支撑这段原话的，是一套很朴素的工程习惯：每个失败都要留下可复用的痕迹，并进入下一次执行，不能只停在某个工程师脑子里。团队知识也会随着每轮运行变厚，也更容易被复用。
错误要写回技能，别只修眼前这一单
Boris 提到一个他认为最重要的工作习惯：每次 Claude 犯错，他不只是告诉它“下次别这样”。他会让 Claude 把新规则写进 CLAUDE.md，或者沉淀成一个 skill。这样做的结果，是同一个错误不会只在当前对话里被修掉，而会变成下一轮 Agent 能继承的组织记忆。 Agent 能不能越用越顺，不只取决于模型强不强，也取决于团队有没有把失败写回流程。
"每次 Claude 犯错，我不会告诉它下次别这样做；我会让它写进 CLAUDE.md，或者做成一个技能。"
Cat 在桌面应用里的做法很像。团队有一个 desktop development skill，教 Claude 如何启动本地桌面应用，并用 computer use 在界面里点击、触发新 UX、覆盖边界情况。遇到 staging 环境异常时，Claude 还会去读 Slack，判断是不是别人已经遇到同样的问题。调试完成后，她会让 Claude 更新这个技能。工具使用一次，经验留下来一层。很多团队引入 AI 后卡在“每次都要重新教一遍”，Anthropic 的处理方式更像维护内部 runbook：把容易出错的环境、权限、测试路径和排查步骤，变成 Agent 每次开工前能读到的操作手册。
验证要从单测走到真实运行
谈到 verification，Boris 觉得很多人一开始会误解。开发者听到验证，脑子里通常是 unit test、lint、type check。这些当然重要，但它们本来就容易自动化。Agent 的验证要再往前走一步：它能不能真的运行软件，打开应用，触发功能，看到出错，再自己修复和复测。Opus 4 早期接入时，Claude 曾经在 bash 里打开一个 Claude CLI，测试自己刚写的功能，让团队第一次感觉到这件事很“疯狂”。
"谈 Agent 的验证时，人们会想到单测、lint 或类型检查；实际上要问的是：Agent 能不能把东西跑起来？"
今天他们已经把这种循环放到 iOS simulator、Android simulator 和桌面 computer use 里。对团队管理者而言，验证能力会直接决定 Agent 的授权范围。如果它只能生成 diff，人还要逐行检查；如果它能跑起本地环境、走一遍 UX、复测边界条件，人就可以把注意力放到更少、更重要的判断上。企业落地时也会遇到同一件事：不缺能生成代码的模型，缺的是能说清楚“我已经按你的真实使用路径试过了”的自动化闭环。
PM、设计和财务都开始直接改系统
Anthropic 内部最有冲击感的变化，是“everyone codes”。Boris 说他从没待过一个 PM 会写代码、而且代码还不错的团队。Cat 的解释更直接：Claude 开始写代码之后，重要性上升的是想法、产品上下文、业务上下文、设计判断和用户理解。一个懂用户、懂业务、懂产品细节的人，能提出更好的改动，也能让 Claude 把这些改动落到应用里。
"Claude 写代码后，更重要的是你有什么想法；如果你有产品、业务、设计和用户上下文，你会提出更好的想法。"
他们还看到相邻角色先从工程师肩膀后面观察，然后自己上手。设计师直接做原型、改应用，不再每次都排工程师时间；PM 也会改应用；财务团队在 Claude Code 里做 projections；数据科学团队屏幕上也常开着 Claude Code。角色边界没有立刻消失，但代码入口被打开后，很多原来卡在排期里的小改动，开始被离用户最近的人直接推动。Boris 后面被问到未来是产品还是工程，他的回答很干脆：每个人都会同时做两件事。Anthropic 的产品、DevRel、设计团队都写代码，工程师也越来越多地端到端交付产品，自己构思、实现，再和 legal、marketing、安全团队一起把它安全地推向外部。
Routine 把 GitHub Issue 直接推到 PR
Cat 最兴奋的用法是 routines。团队里有工程师负责 voice mode，他设置了一个 routine，监听所有 ticket、GitHub issue 和 voice mode 相关 bug report。Claude 会主动捡起来修，开 PR，再 ping 给他。后来他发现还有很多反馈没人处理，就把同一套模式扩到更多入口。Cat 自己有一次准备晚上修一个 edge case，结果 Claude 告诉她：另一个人的 Claude 已经修好了。
"他有一个 routine，会监听每个 ticket、每个 GitHub issue、每个 voice mode 的 bug report，然后 Claude 主动修复并把 PR 发给他。"
Boris 说，Agent SDK 最早让团队知道 Claude Code 可以被程序化调用，但一开始大家还不知道该用在哪里。Routines 是第一个特别清晰的落点：照看每个 PR、处理 code review comment、修 CI、rebase。过去这些是工程师每天被迫切换上下文的小事，现在可以交给一个持续盯着队列的 Agent。他还提到 Loop：团队曾经从“我直接写源码”跳到“我和 Agent 对话，由 Agent 写源码”；现在正在跳到下一层，人和 loop 或 routine 对话，再由它去提示 Claude。入口每上移一层，人的时间就从执行细节里再释放一层。
Auto Mode 让人少看 99% 的确认框
Boris 现在在 CLI 里最常用的是 Auto Mode。过去他会用 plan mode，现在他说新模型已经不太需要单独的 planning step。他会启动一个 Claude，让它自己开始工作，然后转到下一个 Claude，不坐在旁边盯着每一步工具调用。早期 Claude Code 依赖 permission prompt，每次跑工具都问用户能不能执行；那是一年半前可用的方式，因为当时分类器和模型对齐水平还没有现在好。
"当你会接受 99% 的请求时，人的眼睛会自然失焦；Auto Mode 让你只关注最重要的那一小部分。"
他们认为 Auto Mode 反而更安全，因为它不会让人被大量“几乎都该点 yes”的请求淹没。内部上线前，团队收集了数千条完整 Agent trajectory 和权限请求，让 Auto Mode 判断是否安全；再请 red teamers 尝试 prompt injection、攻击代码库，并把这些样本做成 evals。安全在这里并不靠堆更多按钮，它靠更精确地分配人的注意力，把人留给真的异常。Cat 还补了一层：如果命令看起来可疑、并非用户想运行，模型会直接拒绝；用户可以之后再回头手动允许。默认路径先保护系统，再让人处理少数例外。
旧工程直觉要被模型重新校准
Boris 坦白说，过去一年里有很多功能，第一次有人提出来时他都会觉得“不可能可行”。Auto Mode 就是其中之一：把权限请求交给另一个模型判断，听上去像奇怪的工程方案，但实测表现很好。他因此学到一件事：基于模型构建软件，会让很多多年形成的工程直觉失效。团队要不断 red team、做 eval、看真实数据，再决定哪些旧规则该保留，哪些该重学。
"过去学到的很多工程东西，我现在都得扔掉。我们在一个新东西上构建，必须重新学习。"
他还用 90 年代电脑普及的案例类比企业采用 AI。当时很多公司把电脑放在纸质流程旁边，生产力提升并不明显。后来真正产生收益的公司，是把文件柜、纸和笔拿掉，让电脑进入业务流程中心。Boris 说 Anthropic 入职时没人问同事问题，大家问 Claude；写代码、code review、安全 review、填表，也都围绕 Claude 展开。电脑完成这场组织改造花了 10 到 15 年；他认为 AI 会快得多，因为大部分工作已经数字化，Claude 还会使用电脑、写代码、运行代码。换成团队语言，就是不要把 Agent 放在流程旁边当助手，要让流程本身围着它重排。
视频里还有一个很生活化的片段：Cat 记得 Boris 曾经把电脑插在办公室、锁屏放着，人已经回家，却还在从沙发上远程写代码并连续 landing PR。Boris 说，那就是 remote control 变得足够好的一周。工作地点没变成重点，能不能把环境交给 Agent 才变成重点。
少塞上下文，让模型自己去找
视频最后讲到大型企业最常问的 context engineering。Boris 的判断很明确：Sonnet 3.5 时代，大家谈 prompt engineering；Opus 4 时代，大家谈 context engineering；现在的模型已经不需要把一大堆信息提前塞进去。给它尽可能少的 system prompt、尽可能少的工具，再给它一种拉取上下文的方式，让模型自己完成探索。
"我的哲学是，只告诉模型它需要知道的东西，让它自己找出剩下的部分。"
Cat 也说自己是 context minimalist。给模型太多上下文，有时像是在 micromanage，它可能知道通向同一结果的更好路径。Anthropic 也在让 harness 更轻，把更多空间留给用户自己的 prompt。这里的转向很耐人寻味：过去大家努力写完美提示词，现在更像是在设计一个可探索的环境，让 Agent 通过工具、文件、日志和运行结果自己拼出答案。Boris 最后判断，接下来 Agent 会运行更久、更自主，人很少只跑一个 Agent，更多时候是几个、几十个、几百个，甚至上千个一起工作。Claude Code 的下一年，大概率会长成和今天完全不同的形态。
写在最后
Claude Code 一周年最有启发的地方，是 Anthropic 没把它当成“更会写代码的工具”。他们在改验证、沉淀技能、设置 routine、开放角色边界。工程师、PM、设计师都可以从一个小流程开始：让 Agent 做事，让它自证可用，再把失败写回系统。
内容来源："Reflecting on a year of Claude Code"丨Claude