cc创始人对谈，Claude Code一周年回顾 ：内部经历两次认知跃迁，第三次正在路上

Claude Code上线整整一年了。

Anthropic发布了一段对谈，由Claude Code负责人Boris Cherny和产品负责人Cat Wu回顾这一年。他们聊了很多东西，有些判断相当值得关注，Boris有一个判断：一年半时间，内部工程师经历了两次认知跃迁。第三次正在路上，没人知道终点在哪。

完整视频中文字幕版我附在文后了。

cc刚开始就是一坨

最开始的Claude Code其实并不好用。Boris自己说，一年前，Boris把产出演示视频发到公司Slack，只收到两个表情，cat wu没好意思直说，事实上就是一坨

一年过去，Boris描述自己现在的工作状态是：让一个Agent去驱动另一批Agent，后者再各自拆分出更多Agent，形成一棵树状结构，里面可能跑着数千个Agent在同步处理事情。

他总结出一个核心经验：每次Claude犯错，不要只是告诉它下次换个做法，而是让它把正确做法写进CLAUDE.md文件，或者整理成一个可复用的技能。这样Claude就能持续运行，不断自我校正，而不是反复出现同样的问题。

验证，被误解最深的一件事

Cat Wu说，她和开发者、企业聊下来，发现大家对验证这件事普遍有误解。

一提到验证，大多数人想到的是单元测试、代码格式检查、类型检查，这些东西。但问题在于，这些东西本来就是自动化的，并不是什么新挑战。

对AI Agent来说，真正的验证是另一回事，核心问题是：Agent能不能自己把它写的东西跑起来，能不能自己检查它的输出是否正确。

Cat举了一个她自己的例子。她在开发桌面应用，团队一位工程师专门写了一个桌面开发技能，教Claude怎么在本地启动桌面应用。当应用跑起来后，Claude会用computer use功能在界面上点点点，触发新的交互，测试边界情况，发现问题就修复，改完再重新检查。

遇到环境问题时，Claude还会自动去读Slack消息，判断是不是staging环境整体挂了，还是只有自己遇到的bug。每次解决新问题后，Claude会把解法更新进那个技能文档里，供下次直接用。

设计师在提PR，财务团队在用Claude Code

Cat提到一个现象：不止工程师在用Claude Code，整个公司各个角色都渗透进去了。

工程师是第一批用的。旁边的同事看到后也开始试，结果发现很好用。

现在Anthropic内部，设计师直接在代码库里改按钮，不再需要找工程师；产品经理自己改产品功能；财务团队用Claude Code跑财务预测；数据科学家把它当标配工具。

Cat说，这背后有一个简单的道理：Claude在写代码，决定代码写成什么样的关键，越来越依赖你有没有好的想法，有没有对产品、业务、用户的理解。而这些，并不是只有工程师才具备的东西。

有人设了一个常驻例程，专门盯着没人回复的bug

Boris提到了routines（例程）这个功能，他认为这是目前最清晰、最值得关注的一个应用方向。

他举了一个团队里的真实故事。一位负责语音功能的工程师，给自己设置了一个例程：自动监听所有和语音相关的GitHub issue和bug反馈，发现新问题后，Claude直接生成修复方案，提交PR，然后通知这位工程师。

后来这位工程师觉得还可以扩展，又加了一条规则：凡是超过5小时没人处理的bug反馈，Claude自动生成修复，好验证的直接合并。

Boris说，有一次他自己写的一个功能出现了边界case，有人提了bug，他准备当晚修。结果他的Claude在跑任务时提示他：这个bug已经被别人的Claude修了。Boris去查，发现那位工程师压根不知道有这个功能存在，是他的例程自己发现并处理的。

Boris说，他现在的工程日常里，代码审查、CI修复、rebase，这些事情已经很久没自己动手做了，都是例程在跑。

auto mode：从怀疑到真香

Claude Code最初的交互方式是每执行一个工具调用就弹出确认框，让用户手动点确认。

Boris说，他之前很喜欢plan mode，现在完全不用了，全部切换到auto mode。

理由是：新一代模型已经不需要单独的计划步骤，直接跑反而更流畅。而且面对大量重复的确认请求，人类的注意力会自动过滤，真正有风险的请求反而容易被忽略。

auto mode的做法是把每个工具调用请求路由给另一个模型来判断是否安全。Boris说，他一开始听到这个方案时觉得根本不可能好用，但实测数据证明效果非常好。Cat补充，他们的判断是：auto mode比手动审批每个请求实际上更安全，因为用户的注意力被集中到了真正重要的事情上，而不是被大量无关紧要的弹窗淹没。

在上线之前，他们收集了数千条完整的Agent操作记录，用auto mode模型判断每条是否安全，结果准确率极高。然后专门找了红队来做提示词注入攻击，把成功案例整理成测试集，再让内部团队继续攻击，不断优化。

最终上线的auto mode，不只针对已知漏洞，还能防御他们能想到的最复杂的攻击手段。

Loop：正在发生的第二次跃迁

Boris描述了他所看到的两次认知跃迁。

第一次发生在大约一年半前：工程师开始意识到，他们不需要直接写源代码，他们只需要和Agent说话，让Agent来写代码。

第二次正在发生：工程师不再直接和Agent对话，而是和loop或例程交互，由loop来调度Agent，Agent再去写代码。

Boris的总结是：一年半时间，完成了两次这种级别的跃迁。

整个工程组织正在改变

Cat提到了一篇1990年代哈佛商业评论的文章，当时的问题是：个人电脑都来了，为什么企业还感受不到生产力提升。

文章的结论是：你不能一边维持原有的纸质工作流，一边在旁边放一台电脑。真正的生产力提升，要求你扔掉文件柜，扔掉纸和笔，把电脑放在所有流程的中心。

Cat认为这个逻辑现在正在AI身上重演。那次电脑的转型花了10到15年，AI会快得多，因为大量工作已经数字化，Claude本身就能操作电脑、写代码、运行代码。

Anthropic内部已经在按这个逻辑运作。新员工入职，遇到问题不找同事问，直接问Claude。Boris说，写代码用Claude，代码审查用Claude，安全审查用Claude，填表格用Co-Work。Claude在所有流程的中心。

工程师还是产品经理，未来哪个更重要

有人问，未来到底是人人都写代码，还是人人都做产品。

Boris的答案是：两者都是，角色在合并。

他说Anthropic现在的团队，产品团队写代码，开发者关系团队写代码，设计团队写代码，工程师则从写代码一路延伸到管产品、跑法务流程、做安全审查、搞营销沟通。

他说，AI时代真正受益的是那些有好奇心、有产品品味、喜欢端到端全程负责的人。

手机遥控几百个Agent，从沙发上合并代码

Boris提到了他现在的具体工作方式。

以前他在终端里开六个标签页，每个标签页对应同一个代码库的一个git checkout，手动在几个任务之间切换。

现在他只开一个标签页，用新的agent view管理所有并发任务，桌面应用会自动帮他管理work tree克隆，不用手动处理。

更大的变化是，他大约一半的工程工作是在手机上完成的。用remote control连上在家里或公司电脑上跑着的Agent，在路上喝咖啡的时候检查进度，随时启动新Agent。遇到新想法，打开语音模式直接说出来，Agent当场就开始构建，不需要回到电脑前。

Cat说她记得有一段时间，每天Boris离开公司都不带电脑，屏幕还开着放在桌上，她以为是忘了。结果连续好几天都这样，后来发现Boris还在不断合并PR，一问才知道是从沙发上远程控制完成的。那是remote control真正好用起来的那一周。

上下文极简主义

Cat提到上下文工程这个话题也在演变。

Sonnet 3.5时代，要靠prompt engineering。Opus 4时代，要靠context engineering，精心设计给模型的上下文。

现在她的方法是：只告诉模型它必须知道的东西，其他的让模型自己想办法。给模型太多上下文，相当于在微观管理它，而模型有时候自己知道更好的路径。

Boris的补充是：只需要给模型提供一种获取上下文的途径就够了，让它自己去拉取需要的信息，而不是把所有可能有用的东西都事先塞给它。

接下来会更难以预测

Boris说，再看一年后，现在这些工具和用法大概率都会变成全新的样子。

他观察到的趋势是：Agent运行时间越来越长，自主性越来越强，单次运行一个Agent已经很少见，更常见的是几十个、几百个、几千个同时跑。形态会根本性地变化。

他说他不知道那时候的产品会长什么样，这很大程度上要靠整个团队一起摸索，因为想法不会只来自几个人，而是来自整个团队，也来自所有在外面和他们一起构建的社区。