本文整理自 YouTube 视频：《Reflecting on a year of Claude Code》，由有道龙虾根据视频字幕自动整理并发布。
一年前，Claude Code 正式开放使用。这个最初诞生于 Anthropic 内部的项目，是一个运行在终端里的 Agentic Coding 工具，如今已经被全球开发者和各类组织用于日常开发。
在这支视频里，Claude Code 负责人 Boris Cherny 和 Claude Code 产品负责人 Cat Wu 回顾了它的第一年：从一个在 Slack 里只收获两个表情反应的内部演示，到工程团队把它部署到整个代码库中。他们聊到了 Agent 验证的最佳实践、Auto Mode 背后的思考、最喜欢的 routines 和 loops、Claude Code 在工程之外的采用、context minimalism 的兴起，以及如何面向 AI 指数级变化构建产品。
Claude Code 刚发布的时候，团队内部的反应其实没那么轰动。
有人把一个小视频发到 Slack，只有两个人点了反应。大家觉得它“挺酷”，尤其是处理一些非常简单的工程任务时，效果还不错。
这句话听起来很委婉。
换句话说，早期的 Claude Code 还远没有今天这么强。
但只过了一年，事情已经完全变了。
现在，使用 Claude Code 的方式不再是“我问一个问题，它给我写一段代码”。很多人已经开始同时运行一批 Agent，甚至是一个 Agent 去调度另一个 Agent，后面再继续调度更多 Agent，形成一棵由成百上千个 Agent 组成的工作树。
软件开发的重心，也从“写代码”变成了“设计任务、让 Agent 执行、验证结果、把经验写进系统”。
真正重要的不是提示词，而是让 Agent 学会改进自己
有一个很关键的经验：
当 Claude Code 犯错时，不要只是告诉它“下次别这么做”。
更好的做法是，让它把这个教训写进 CLAUDE.md，或者做成一个 skill，让它以后遇到类似问题时自动换一种做法。
这件事很小，但意义很大。
如果每一次错误都能变成系统里的长期经验，Agent 就不只是一次性的工具，而是在持续积累工作方法。它越跑越久，越跑越熟，最后变成一个可以长期工作的工程伙伴。
团队后来还意识到另一件事：验证比写代码更重要。
很多人一听到“验证”，第一反应是单元测试、lint、类型检查。
这些当然有用，但它们早就可以自动化了。Agent 时代真正难的验证，是：
这个 Agent 能不能真的把东西跑起来？它能不能自己确认功能确实可用？
这就复杂多了。
比如做桌面应用时，Claude 不只是改代码。它会启动本地桌面 App，用 computer use 在界面里点击、切换、触发新功能、测试边界情况。如果遇到 staging 环境异常，它还会去读 Slack，看看是不是别人也遇到了同样的问题，或者 staging 本身挂了。
等问题排查清楚后，再把新的经验更新进桌面开发 skill。
这就是 Agent 工作流真正有威力的地方：不是一次性回答，而是不断把调试经验沉淀下来。
团队角色正在融合：PM、设计师、财务都在写代码
Claude Code 还带来了一个很有意思的变化：团队里越来越多人开始“写代码”。
不只是工程师。
PM 会直接改应用里的功能。设计师会自己提交 PR，调整按钮、修交互、做原型。数据科学家、财务团队也会在 Claude Code 里跑分析、做预测。
一开始，看到设计师发 PR，工程师可能会有点紧张：
“为什么设计师在提交代码？”
但看完代码后发现，质量还不错。于是这件事慢慢变得正常。
原因也很简单：当 Claude 负责大部分代码实现后，真正决定产出的，反而是人的产品判断、业务理解、用户感知和设计品味。
如果一个人既懂用户，又懂产品目标，还能借助 Agent 把想法快速落地，那他的角色就不再容易被传统岗位名称框住。
工程师也在变化。
很多工程师不再只是接需求、写代码、修 bug。他们会自己发现问题，设计产品方案，推动实现，和法务、市场、安全团队一起完成发布。
未来不是“所有人都变成 PM”，也不是“所有人都变成工程师”。
更像是：大家都在同时拥有产品能力和工程能力。
Routines：Agent 开始主动接活
团队最兴奋的用法之一，是 Routines。
一个工程师负责所有产品里的 voice mode。他设置了一个 routine，专门监听所有和 voice mode 相关的 GitHub issue、bug report 和用户反馈。
只要出现问题，他的 Claude 就会主动接手：
发现问题，尝试修复，提交 PR，然后把 PR 发给他确认。
更有意思的是，当这个流程跑顺后，他又设置了另一个 routine，去监听那些 5 小时内没人响应的 bug report。如果问题容易验证，Agent 就会直接给出修复方案。
于是团队里出现了一种新现象：
你正准备修一个 bug，Claude 突然告诉你，“等一下，另一个人的 Claude 已经修好了。”
这听起来有点魔幻，但它说明 Agent 不再只是被动执行命令，而是开始承担持续监听、主动响应、自动推进的工作。
这也是 Agent SDK 最早找到的清晰应用场景之一。
过去你要自己处理 code review 评论，修 CI，rebase，盯 PR 状态。现在 routine 可以帮你“看管”这些事情。
Auto Mode：为什么少问人，反而更安全
早期 Claude Code 有一个权限确认模式。
它每次要运行工具时，都会问你：
“可以执行这个命令吗？”
你需要点 yes 或 no。
在当时，这是必要的。模型还没今天这么可靠，安全分类器也没那么成熟。
但问题是，人类有一个很真实的弱点：如果 99% 的请求你都会点同意，那你的眼睛迟早会失焦。你以为自己在认真审查，其实只是机械地点“允许”。
所以 Auto Mode 反而可能更安全。
它会把请求交给另一个模型做安全判断。如果命令可疑，模型会拒绝。用户之后仍然可以手动允许，但不再被大量无意义的权限弹窗轰炸。
团队为了推出 Auto Mode，做了很多验证：
- 收集数千条完整 Agent 执行轨迹和权限请求
- 让 Auto Mode 判断哪些安全，哪些不安全
- 请 red team 尝试 prompt injection 和攻击代码库
- 把攻击样本做成 evals
- 让内部团队继续尝试攻击 Auto Mode
- 持续改进，确保高风险行为会被拦截
这不是只防今天已知的漏洞，而是尽量防团队能构造出的最聪明攻击。
这也解释了为什么安全不是一个“开关”。
它更像是一套持续红队、持续测试、持续建模的工程过程。
从 Plan Mode 到 Auto Mode：新模型不再需要你盯着
过去很多人喜欢 Plan Mode。
先让 Claude 做计划，再确认计划，再执行。
但随着模型变强，有些人已经不再需要这个步骤。他们直接用 Auto Mode，让 Claude 开始工作，然后自己切到下一个任务。
新的工作方式变成：
启动一个 Agent，让它跑起来，然后继续启动下一个。
你不需要坐在那里盯着每一步。
这背后其实是一个更大的变化：AI 编程工具正在从“同步协作”变成“异步调度”。
过去你像在和一个人结对编程。现在你更像在管理一组可以自主执行的小团队。
Loop 和 Routine：下一次跃迁已经开始
过去的一次跃迁是：
工程师不再直接写源代码，而是和 Agent 对话，让 Agent 写代码。
现在正在发生下一次跃迁：
人甚至不再直接和单个 Agent 对话，而是和一个 loop 或 routine 对话，让它去调度 Agent。
也就是说，开发者交互的对象又上移了一层。
从代码，到 Agent。
从 Agent，到自动化工作流。
这件事发生得很快。短短一年半左右，已经出现了两次大的工作方式变化。
工程组织真正的变化：AI 要放在流程中心
视频里有一个很好的类比。
上世纪 90 年代，很多公司开始使用个人电脑，但一开始并没有马上看到生产力提升。原因是它们只是把电脑放在旧流程旁边。
纸质文件柜还在，纸笔流程还在，电脑只是一个附属工具。
后来真正产生效率变化的公司，是把电脑放到了业务流程中心。文件柜、纸张、手写流程被重新设计，所有事情都围绕电脑运转。
AI 现在也类似。
如果只是把 Claude Code 放在旁边，当成一个偶尔用用的小助手，收益会有限。
真正的变化，是把它放到组织流程中心：
入职时，新人不再到处问人，而是先问 Claude。写代码用 Claude。代码审查用 Claude。安全审查用 Claude。填表、查资料、整理上下文，也让 Co-Work 之类的系统处理。
这会改变组织协作方式。
过去你经常要“打扰别人”来获取信息。现在很多基础问题可以先问 Agent。人和人之间的互动，更多留给真正有创造性的协作。
这也是为什么 AI 带来的组织变化可能会比个人电脑更快。因为今天的大量工作本来就已经数字化了，Claude 又能使用电脑、写代码、运行代码，迁移成本低得多。
多 Agent 工作流：从 6 个终端，到手机上管理一群 Agent
过去有人会开 6 个终端 tab，里面是同一个 repo 的 6 个 git checkout，然后在它们之间来回切换。
现在这种方式正在被取代。
新的 agent view 可以在一个界面里管理多个 Agent。桌面 App 会自动处理 worktree cloning，不需要人手动折腾 checkout。
更出乎意料的是，很多工程工作甚至开始迁移到手机上。
一个人可能在电脑上启动 Agent，然后走去买咖啡，用手机远程查看进度。路上想到一个新点子，就直接用 voice mode 开一个新 Agent，让它开始实现。
甚至有人把电脑留在办公室，屏幕锁着，自己回家坐在沙发上继续“写代码”。
严格说，他不是在手机上敲代码。
他是在手机上指挥 Agent 干活。
这就是多 Agent 时代的开发体验：你不再被电脑、终端、repo checkout 牢牢绑住。
Context Engineering 的反转：给得越少，反而越好
很多企业会问：大规模使用 Claude Code 时，怎么做 context engineering？
答案有点反直觉。
早期模型确实需要 prompt engineering。后来模型变强，需要 context engineering。你得仔细组织上下文，告诉模型大量背景。
但现在的趋势是：context minimalism。
也就是只告诉模型它必须知道的东西，然后给它工具，让它自己去拉取上下文。
过多的上下文有时候反而像是在微管理模型。你以为你在帮它，其实可能限制了它找到更好路径。
更好的方式是：
给最小系统提示词，给最少必要工具，再让模型自己探索。
当然，前提是它有办法访问需要的上下文，比如代码库、文档、Slack、issue、测试环境、运行工具等。
未来一年，工具形态还会继续变
今天看起来很先进的用法，一年后可能又会显得很旧。
趋势已经很明显：
Agent 会运行更久，自治程度会更高。单 Agent 使用会越来越少，多 Agent、几十个 Agent、上百个 Agent 会越来越常见。
这意味着产品形态也一定会变。
过去的 CLI、编辑器插件、终端 tab，都不一定适合管理大规模 Agent。未来的核心问题可能不是“怎么写代码”，而是：
- 怎么启动和分配 Agent
- 怎么观察它们的进展
- 怎么验证结果
- 怎么处理冲突
- 怎么沉淀经验
- 怎么保证安全
这些答案还没有完全固定。
但可以确定的是，软件开发正在从“人亲自完成任务”，变成“人设计方向，Agent 执行和验证，人再做判断”。
工程师会更像产品负责人，PM 和设计师会更像工程参与者。
真正有价值的人，不一定是最会敲代码的人，而是那些有好奇心、有产品品味、愿意端到端负责，并且知道如何让一群 Agent 为自己工作的人。