Claude Code 主创复盘疯狂的一年｜对话 Boris & Cat

Claude Code 主创复盘疯狂的一年｜对话 Boris & Cat Claude Code 主创复盘疯狂的一年｜对话 Boris & Cat Modified June 22 你怎么用它？ 🧑💻Boris 说到 Loop，大概一年半前我们经历过一个转变：本来有源代码，但其实工程师该打交道的对象也许不是源代码，而是 agent。 于是我们做了一次跳跃：我不写源代码，我跟一个 agent 说话，由 agent 替我写源代码。而现在，我觉得正在实现下一次飞跃： 我不再与 agent 说话了，我对一个 loop、一个 routine 说话，由它替我去 prompt Claude。 这太疯狂了，才一年半，就已经有两次巨大的飞跃。 把 Claude 放进流程中心，角色边界也在消失 👩💻Cat 往后退一步看，你看到整个工程组织都在发生哪些变化？ 🧑💻Boris 我要戴上我的商业视角帽子了。 我特别喜欢一个案例：1990 年代《哈佛商业评论》有一篇文章在讨论" 计算机都来了，为什么我们还没看到生产力提升带来的好处？ "。 当年大家从大型机切换到个人电脑是个新鲜事，公司都在摸索怎么用，就像今天大家在摸索怎么用 AI 一样。 而事实证明，要真正拿到计算机的生产力红利，不是把文件柜、纸笔留着来处理业务流程，旁边再摆一台电脑做点什么；你得把文件柜、纸笔都彻底扔掉，让电脑成为业务流程的核心。 对我们来说， Claude 就处在一切的中心 ：新人入职没人问人问题，大家问 Claude，写代码用 Claude，要 code review 找 Claude，要安全审查找 Claude，要填个表 Cowork 替我做。我觉得那些真正搞明白这一点的公司（现在已经有一批了），都在把 Claude 置于正中央。 👩💻Cat 不过对计算机来说，这种转变花了 10 到 15 年。但对 AI，因为我们大多数工作很多已经数字化了，而且 Claude 能用电脑、能写代码、能跑代码，这次转变要快得多。 🧑💻Boris 我感觉，现在跟人打交道是因为那很好玩、能一起做出点东西，而不是因为我有求于人，因为很多事 Claude 也能做。作为工程师，我从未像现在这样享受工程，那些繁琐的部分不用我做了，我就负责想点子、跟客户聊。 那 未来是属于产品还是工程？是人人都成为 PM，还是人人都成为工程师？ 👩💻Cat 每个人都会身兼二职，我认为 这些角色在融合。 以我们自己的团队举例，产品团队都写代码，设计团队也在写代码；再看工程师，很多人是端到端地交付产品。他们对于要构建什么有自己的想法，自己做出来，再跟法务、市场一起弄清楚怎么对外沟通、怎么保证安全，很多时候一个人就把整个流程走完。 AI 特别利好那些好奇心强、有产品品味、喜欢端到端 ownership 的人。 多 agent、手机写代码、context 极简，而一年后会完全不同 👩💻Cat 当大家从"一个 agent"走向"几个、几百个 agent"时，你觉得应该使用哪些产品？ 🧑💻Boris 直到不久前，我写代码还是把同一个仓库克隆 6 份，每份开一个终端窗口、手动来回切。现在很不一样了，我只用 1 个 tab，用我们刚发布的 agent view ，能在一个窗口内同时看管多个并行 agent，省去开一堆终端来回切，体验非常棒。 我也用 桌面版 Claude ，这样就不用折腾代码签出了，它会帮我自动建好 worktree。 还有一件六个月前我绝对想不到的事： 现在我的工作大概有一半是在手机上完成的。 我会在电脑上起一个任务，然后用手机远程控制，到处走走，去拿杯咖啡，再看看我的 agent，也许再起一个 agent。有时候我在跟人聊天，聊出一个新点子，我就当场起一个 agent，用 voice mode 跟它说，让它直接去做，我甚至都不用回到电脑前了。 👩💻Cat 我记得你刚开始这么干的时候，你会下班离开，电脑就开着机、插着电、锁屏放在办公桌上。我以为你过会儿会回办公室拿电脑，可都挺晚了你还没回，我就想，可能你只是不小心把电脑落在这儿了。 然后第二天又这样，第三天又这样，我就纳闷，这太奇怪了，你的 PR 在合，可你电脑就在我旁边。我记得你回我说，"对啊，我正躺在沙发上写代码"。 🧑💻Boris 对，那正是 remote control 变得特别好用的那一周。 👩💻Cat 还有一个用户经常问的：在大型企业里，你们怎么做 context engineering？ 🧑💻Boris 以前大家谈 prompt engineering，谈 context engineering，这其实是 跟当时模型的水平匹配的。 回到 Sonnet 3.5 的时代，你得做 prompt engineering；Opus 4 的时代，你得做 context engineering；但用今天的大模型，你完全不需要做这些。 你只需要给它尽可能精简的提示词和工具集，然后让模型自己搞定。 只用给模型一个获取上下文的方式即可 ，我觉得这是最重要的。 👩💻Cat 我对此的看法很相似，我是个 context 极简主义者 。 所以我的原则是：只告诉模型它需要知道的，剩下的让它自己琢磨。 你给模型太多上下文，有点像在微管理它，而有时候模型知道更好的方法来达到同样的结果，我个人更愿意把这个自由留给它。 另外，我们也在 让 harness 框架更精简 ，给你自己的 prompt 留更多空间，让它更贴合你的意图。 🧑💻Boris 现在用 Claude 有这么多种方式，但我觉得一年后又会不一样，如果还是这些老一套，那才叫意外。我们正在目睹一些巨大的趋势发生： agent 跑得越来越久，也越来越自主。 我现在很少只跑一个 agent，通常是几个、几十个、几百个、上千个。所以那种形态设计会跟以前截然不同，我很难想象未来会是什么样子。 这也是为什么，我特别高兴能以现在这种方式运营团队：人人都能提出想法、人人都能思考产品、人人都与用户保持沟通，我不认为这些想法会来自于我们，它们通常来自于团队。 👩💻Cat 完全同意，也来自于同我们一起建设的社区成员。 什么是 Loop Engineering？ 你设计的不再是一句更好的 prompt，而是一个能自己发现任务、分派执行、验证结果、记住进度、并知道何时把成果交付给你的循环系统，让它替你去 prompt agent。这被看作继 prompt engineering → context engineering → harness engineering 之后的第四级。 它是怎么火的 2026 年 6 月初，Boris Cherny 在 WorkOS [1] 一场公开活动上率先提出 "My job is to write loops"。 6 月 7 日，OpenClaw 之父 Peter Steinberger 发推 [2] ："你不该再 prompt agent 了，你该设计 loop 来替你 prompt agent." 单条阅读量破百万。 同一天，Google 工程师 Addy Osmani 撰文 [3] ，并把 Loop Engineering 拆解为以下那套"五大构件 + 记忆层"的框架。 五大构件 + 一个记忆层 按照 Addy Osmani 的拆解，一个 loop 需要五样东西，外加一个用来记事的地方： • Automations（自动触发）： 按计划自己启动，去发现和分类任务。 • Worktrees（并行隔离）： 让多个 agent 同时工作而不互相踩踏。 • Skills（知识沉淀） ：把项目知识固化下来，避免 agent 每次从零推导。 你怎么用它？ 🧑💻Boris 说到 Loop，大概一年半前我们经历过一个转变：本来有源代码，但其实工程师该打交道的对象也许不是源代码，而是 agent。 于是我们做了一次跳跃：我不写源代码，我跟一个 agent 说话，由 agent 替我写源代码。而现在，我觉得正在实现下一次飞跃： 我不再与 agent 说话了，我对一个 loop、一个 routine 说话，由它替我去 prompt Claude。 这太疯狂了，才一年半，就已经有两次巨大的飞跃。 把 Claude 放进流程中心，角色边界也在消失 👩💻Cat 往后退一步看，你看到整个工程组织都在发生哪些变化？ 🧑💻Boris 我要戴上我的商业视角帽子了。 我特别喜欢一个案例：1990 年代《哈佛商业评论》有一篇文章在讨论" 计算机都来了，为什么我们还没看到生产力提升带来的好处？ "。 当年大家从大型机切换到个人电脑是个新鲜事，公司都在摸索怎么用，就像今天大家在摸索怎么用 AI 一样。 而事实证明，要真正拿到计算机的生产力红利，不是把文件柜、纸笔留着来处理业务流程，旁边再摆一台电脑做点什么；你得把文件柜、纸笔都彻底扔掉，让电脑成为业务流程的核心。 对我们来说， Claude 就处在一切的中心 ：新人入职没人问人问题，大家问 Claude，写代码用 Claude，要 code review 找 Claude，要安全审查找 Claude，要填个表 Cowork 替我做。我觉得那些真正搞明白这一点的公司（现在已经有一批了），都在把 Claude 置于正中央。 👩💻Cat 不过对计算机来说，这种转变花了 10 到 15 年。但对 AI，因为我们大多数工作很多已经数字化了，而且 Claude 能用电脑、能写代码、能跑代码，这次转变要快得多。 🧑💻Boris 我感觉，现在跟人打交道是因为那很好玩、能一起做出点东西，而不是因为我有求于人，因为很多事 Claude 也能做。作为工程师，我从未像现在这样享受工程，那些繁琐的部分不用我做了，我就负责想点子、跟客户聊。 那 未来是属于产品还是工程？是人人都成为 PM，还是人人都成为工程师？ 👩💻Cat 每个人都会身兼二职，我认为 这些角色在融合。 以我们自己的团队举例，产品团队都写代码，设计团队也在写代码；再看工程师，很多人是端到端地交付产品。他们对于要构建什么有自己的想法，自己做出来，再跟法务、市场一起弄清楚怎么对外沟通、怎么保证安全，很多时候一个人就把整个流程走完。 AI 特别利好那些好奇心强、有产品品味、喜欢端到端 ownership 的人。 多 agent、手机写代码、context 极简，而一年后会完全不同 👩💻Cat 当大家从"一个 agent"走向"几个、几百个 agent"时，你觉得应该使用哪些产品？ 🧑💻Boris 直到不久前，我写代码还是把同一个仓库克隆 6 份，每份开一个终端窗口、手动来回切。现在很不一样了，我只用 1 个 tab，用我们刚发布的 agent view ，能在一个窗口内同时看管多个并行 agent，省去开一堆终端来回切，体验非常棒。 我也用 桌面版 Claude ，这样就不用折腾代码签出了，它会帮我自动建好 worktree。 还有一件六个月前我绝对想不到的事： 现在我的工作大概有一半是在手机上完成的。 我会在电脑上起一个任务，然后用手机远程控制，到处走走，去拿杯咖啡，再看看我的 agent，也许再起一个 agent。有时候我在跟人聊天，聊出一个新点子，我就当场起一个 agent，用 voice mode 跟它说，让它直接去做，我甚至都不用回到电脑前了。 👩💻Cat 我记得你刚开始这么干的时候，你会下班离开，电脑就开着机、插着电、锁屏放在办公桌上。我以为你过会儿会回办公室拿电脑，可都挺晚了你还没回，我就想，可能你只是不小心把电脑落在这儿了。 然后第二天又这样，第三天又这样，我就纳闷，这太奇怪了，你的 PR 在合，可你电脑就在我旁边。我记得你回我说，"对啊，我正躺在沙发上写代码"。 🧑💻Boris 对，那正是 remote control 变得特别好用的那一周。 👩💻Cat 还有一个用户经常问的：在大型企业里，你们怎么做 context engineering？ 🧑💻Boris 以前大家谈 prompt engineering，谈 context engineering，这其实是 跟当时模型的水平匹配的。 回到 Sonnet 3.5 的时代，你得做 prompt engineering；Opus 4 的时代，你得做 context engineering；但用今天的大模型，你完全不需要做这些。 你只需要给它尽可能精简的提示词和工具集，然后让模型自己搞定。 只用给模型一个获取上下文的方式即可 ，我觉得这是最重要的。 👩💻Cat 我对此的看法很相似，我是个 context 极简主义者 。 所以我的原则是：只告诉模型它需要知道的，剩下的让它自己琢磨。 你给模型太多上下文，有点像在微管理它，而有时候模型知道更好的方法来达到同样的结果，我个人更愿意把这个自由留给它。 另外，我们也在 让 harness 框架更精简 ，给你自己的 prompt 留更多空间，让它更贴合你的意图。 🧑💻Boris 现在用 Claude 有这么多种方式，但我觉得一年后又会不一样，如果还是这些老一套，那才叫意外。我们正在目睹一些巨大的趋势发生： agent 跑得越来越久，也越来越自主。 我现在很少只跑一个 agent，通常是几个、几十个、几百个、上千个。所以那种形态设计会跟以前截然不同，我很难想象未来会是什么样子。 这也是为什么，我特别高兴能以现在这种方式运营团队：人人都能提出想法、人人都能思考产品、人人都与用户保持沟通，我不认为这些想法会来自于我们，它们通常来自于团队。 👩💻Cat 完全同意，也来自于同我们一起建设的社区成员。 什么是 Loop Engineering？ 你设计的不再是一句更好的 prompt，而是一个能自己发现任务、分派执行、验证结果、记住进度、并知道何时把成果交付给你的循环系统，让它替你去 prompt agent。这被看作继 prompt engineering → context engineering → harness engineering 之后的第四级。 它是怎么火的 2026 年 6 月初，Boris Cherny 在 WorkOS [1] 一场公开活动上率先提出 "My job is to write loops"。 6 月 7 日，OpenClaw 之父 Peter Steinberger 发推 [2] ："你不该再 prompt agent 了，你该设计 loop 来替你 prompt agent." 单条阅读量破百万。 同一天，Google 工程师 Addy Osmani 撰文 [3] ，并把 Loop Engineering 拆解为以下那套"五大构件 + 记忆层"的框架。 五大构件 + 一个记忆层 按照 Addy Osmani 的拆解，一个 loop 需要五样东西，外加一个用来记事的地方： • Automations（自动触发）： 按计划自己启动，去发现和分类任务。 • Worktrees（并行隔离）： 让多个 agent 同时工作而不互相踩踏。 • Skills（知识沉淀） ：把项目知识固化下来，避免 agent 每次从零推导。 • Plugins / Connectors（工具连接） ：把 agent 接入 issue tracker、Slack、数据库等你本来就在用的工具上。 • Sub agents（分工验证）： 做事的和检查的分开，模型不该给自己打分。 • State（状态 / 记忆层）： 一个 markdown 文件，或者一块 Linear 看板，任何活在单次对话之外、记录已完成和待处理的事项，让明天的 loop 能接上今天的进度。agent 会忘，仓库不会。 一个 loop 跑起来是什么样 把这几样拼到一起，一个对话窗口就变成了一个小小的控制台。下面是 Addy 自己反复在用的一种结构： 每天早上，一个 automation 在仓库上自动运行。prompt 调用一个 skill，去读昨天挂掉的 CI、还开着的 issue、最近的 commit，把梳理出来的结果写进一个 markdown 文件或一块 Linear 看板。 对于每个值得处理的发现，该流程会单独开一个隔离的 worktree，并派遣一个 sub agent 去起草修复方案，再派第二个 sub agent 对照项目 skill 和现有测试来审阅这份草稿。 Connectors 负责让这个 loop 自己开 PR、更新工单；loop 搞不定的内容，就丢进分类收件箱（Triage inbox）等人处理。 State 文件是整个系统的核心，它记录了什么已尝试、什么已通过、什么仍处于开放状态，于是明天早上这一轮能接着今天的进度继续往下走。 回头看看人在其中到底做了什么：你只设计了一次，中间每一步你都没有去 prompt。 无论是在 Codex 还是 Claude Code 都是同一个 loop，因为构件是同一批构件。 保持工程师的清醒 随着 loop 效率提升，Addy 在文末仍花了不少篇幅讲“ loop 无法替代人的那部分”。他强调： Build the loop, stay the engineer. 循环可以交给机器，但工程师这个身份不能丢。 他主要担心两件事： 一是理解债（comprehension debt [4] ）：loop 替你写的代码越多越快，你真正读懂的部分就越少；流畅的 loop 只会加速这种债务累积，除非你坚持去读它生成的代码。 二是认知投降（cognitive surrender [5] ）：带着判断去设计 loop，它能帮你提速；用它来逃避理解工作本身，全盘接收反馈结果，最舒服的姿势反而最危险。 说到底，这也正是 loop engineering 比 prompt engineering 更难的地方： loop 并非让工作变得更容易了，而是杠杆支点发生了转移。 写在最后 回看这期内容，Boris 和 Cat 其实在反复说同一件事： Claude 越强，人要做的事就越往上走一层——从写代码，到指挥 agent，再到写 loop。 Boris 说，一年后这些用法大概又会被推翻。功能会进化、routine 会过时，但真正能留下来的，始终是那个"往上走一层"的视角： 把会重复的交给循环，把判断、品味和方向，留给自己。 参考资料 [1] WorkOS： https://youtu.be/RkQQ7WEor7w?si=81OL42IvwN4J8T u [2] 发推： https://x.com/steipete/status/2063697162748260627?s=20 [3] 撰文： https://addyosmani.com/blog/loop engineering/ [4] comprehension debt： https://addyosmani.com/blog/comprehension debt/ [5] cognitive surrender： https://addyosmani.com/blog/cognitive surrender/ 🔗 原文链接： https://mp.weixin.qq.com/s/g6IMliPp... https://mp.weixin.qq.com/s/g6IMliPp... Shirley Shirley 十字路口Crossing2026年6月22日 19:14 美国 “我不再跟 agent 说话了——我写一个 loop，让它替我去 prompt Claude。” 🙍♀️ 作者: Shirley 🥷 编辑: Koji 🧑🎨 排版: NCon Claude Code 上线满一年，Boris Cherny 和 Cat Wu 以主创身份复盘了团队内部的真实工作流。 他们谈论的不是某个具体功能，而是人和 agent 到底该怎么分工。 Boris 说自己现在"不再 prompt agent，而是写 loop"，一半的工程在手机上完成；Cat 则发现自己的 bug 常常被"另一个人的 Claude"抢先修好。 你会看到不同于主流 Claude Code 教程的新鲜视角，也会提前看到最前沿的工作流。 嘉宾背景 🧑💻 Boris Cherny｜ Claude Code 负责人，此前在 Meta 担任 Principal Engineer，并著有《Programming TypeScript》。他在 2024 年 9 月加入 Anthropic 后，将 Claude Code 作为个人项目启动，随后推动其产品化，目前该工具生成的代码已占全球 GitHub 公开 commit 约 4%。自 2025 年 11 月起，他已全面转向 AI 辅助编程。 👩💻 Cat Wu ｜Claude Code 与 Cowork 产品负责人，兼具技术研发与风险投资的跨界背景。她推崇“原型胜于文档”的产品哲学，与 Boris 共同塑造了 Claude Code 的核心形态，并推动 Anthropic 全员使用 Claude Code 办公。 核心观点 • 犯错别重说一遍，写进 CLAUDE.md。 纠正只生效一次，沉淀才有复利，这样 Claude 才能一直自己跑下去。 • 验证不仅仅写单测，是让它自己把东西跑起来。 lint、类型检查早就自动化了；真正的门槛，是 agent 能不能自己运行、自己看结果。 • 逐条点"同意"，反而不如全交给 auto mode。 人点到 99% 都是 yes 时注意力早涣散了，把安全判断交给另一个模型，比人眼更稳定。 • 你的 bug，常常被别人的 Claude 先修好。 让 Claude 盯 issue、自动提 PR、合掉好验证的，这就是 routine。 • 最高阶的用法不再是写 prompt，是写 loop。 模型足够强之后，人的任务是设计一个能自己发现任务、替你反复调用 agent 的循环。 犯错写进 CLAUDE.md，验证靠它自己跑 🧑💻Boris 我们第一次发布 Claude Code 的时候，就是一条很短的小视频。我记得发到 Slack 上，只有两个人点了那种"兴奋"的表情。 👩💻Cat 我当时觉得挺酷的，尤其是拿它做我那些很简单的工程任务，做得相当不错。 🧑💻Boris 这说法已经很客气了，其实就是在说它当时不怎么样。 👩💻Cat 真不敢相信，距离我们第一次发布 Claude Code 才过去一年。 🧑💻Boris 很难回忆起当时是什么样子了，毕竟跟我们今天做的完全不是一回事。 现在我手里是一支 agent 大军，我 prompt 一个 agent，或者有一个 agent 去 prompt 别的 agent、再 prompt 别的 agent，像一棵上千个 agent 的树。 但我觉得做这件事最重要的一个理念是： 每次 Claude 犯错，我不会让它换个方式做，我会让它把这件事写进 CLAUDE.md，或者做成一个 skill。 只要你能做到这一点，Claude 就能一直跑下去。 另一件我们后来才意识到的事，是验证真的很重要，一开始我们没意识到。 👩💻Cat 这一点在我们见到的开发者和企业里经常被提到。你有什么让 Claude Code 把验证做好的建议 吗？ 🧑💻Boris 我觉得这件事几乎所有人都误解了。一谈验证，大家想到的是单元测试、lint、类型检查，可这些本来就容易自动化、也早就自动化了。 但我们说 agent 的验证，是另一回事： agent 能不能自己把这个东西跑起来？ 这其实要花点脑子，因为往往没那么直接，这也是难点之一。 我记得 Opus 4 的时候，Claude 会自己测自己。我们把它接到 Opus 4 上，我说"Claude，开发一个功能，然后在 bash 里测你自己"，它就开了一个小小的 Claude CLI，测了自己写的功能，我当时就想“哇，这太酷了”。 现在我们已经习以为常了，iOS 模拟器、Android 模拟器、桌面端应用，全都有这种循环。但当时真的觉得不可思议，你现在是怎么做的？ 👩💻Cat 我最近主要在折腾桌面端 app。团队里一位工程师加了一个 桌面开发 skill ，教 Claude 怎么运行本地桌面 app，我一直在用它。 它有时还是会遇到 bug，这种情况我就让它去读 Slack，搞清楚是预发布环境（staging）整个挂了，还是别人也踩过这个坑？等它把问题查清楚，我再让它把新学到的经验写进那个桌面开发 skill。 这个 skill 做的事，是让 Claude 启动一个本地桌面 app，然后像人一样用鼠标（Computer use）去点界面。所以当我添加新的用户界面时，Claude 就自己点进去把它走一遍，顺带测各种边界情况，点出 bug 就改、改完再点一次复核。 全员写代码：从工程师扩散到每个岗位 🧑💻Boris 说实话，这是我最喜欢这个团队的地方之一： 人人都写代码 。 我从没在哪个团队遇到过这种情况，我的产品经理会写代码，而且你的代码写得真的很好。 不过我也觉得这件事正变得越来越容易，因为本质上是 Claude 在写代码，所以更重要的反而是你有什么想法。 如果你是一个掌握产品或业务背景，又在思考设计和用户需求的人，你自然会想出更好的创意。 👩💻Cat 有点像所有角色都在融合。 🧑💻Boris 我记得第一次看到我们的设计师 Megan 提 PR，我当时吓坏了，心想"天哪，Megan 怎么在提 PR"。她说"对啊，我就是在修一个 button"。现在这已经是常态了。 👩💻Cat 对，在我们所接触到的企业也都是这种现象：工程师先用上 Claude Code，其他岗位在旁边看着，发现"哇这东西太强了，我也试试"。 于是我们发现，设计师直接在 Claude Code 里改东西，比让工程师做更高效；财务也直接在那跑预测分析；还有数据科学家，大家屏幕上都开着 Claude Code，我觉得它对不同岗位的通用性高得惊人。 你的 bug，常被别人的 Claude 先修了 🧑💻Boris 如今你感觉哪些应用场景正在突破极限？ 👩💻Cat 我特别兴奋的一个是 routines 。 团队里有位工程师把 voice mode 铺到了我们所有产品上，他设了一个 routine，专门监听每一条关于 voice mode 的工单、GitHub issue、bug 报告，他的 Claude 会主动接手这些问题、提交修复 PR、再通过 PR 通知他。 当他实现这个功能后，他就想，“好吧，我们收到了其他反馈，但尚未得到回应“，然后他又设了一个 routine 来监听这些反馈。 有一次我上线了一个小功能，里面有个我没看到的边界情况，有人报了 bug，我本来打算当晚去修。结果我的 Claude 干活时说，"等一下，另一个 Claude 已经把这个修好了"。 我当时就想，“这怎么可能？我从来没跟他交流过啊”，就问他“怎么这么快修好的”，他说他还有一个 routine，专门盯那些超过 5 小时没人响应的 bug 报告，自动提修复，容易验证的就直接合掉。 🧑💻Boris 现在 Claude 老跟我说这个，说别人已经修好了。 👩💻Cat 总有"另一个人的 Claude"正在修它。 🧑💻Boris 对，这是这一年的重要变化之一。我觉得 routines 是第一个真正显而易见的应用，它 几乎能完成所有的代码审查，像保姆一样盯着每一个 PR。 你还记得以前真的要自己回复代码审查 comments、自己修复 CI、自己 rebase 吗？我已经很久没干过这些了。 auto mode：取代 plan mode，比逐条确认更安全 👩💻Cat 当你在命令行界面（CLI） 跟 Claude 同步协作时，你最常用的功能是什么？ 🧑💻Boris 以前是 plan mode，现在不用了。 👩💻Cat 那你改用什么？ 🧑💻Boris auto mode 最好用。新一些的模型其实不再需要单独的规划步骤了。 我觉得这一步对 Opus 4 到大概 4.5 还挺重要，但从 Opus 4.6 开始、到 4.7 就不再需要规划步骤了。 有些人还在用，他们喜欢保留那个规划产物，我不用， 我所有操作都用 auto mode 。我启动一个 Claude，它就开始干，然后切到下一个 Claude，不用坐在那儿盯着它。 不过从很早开始，Claude Code 就有一个权限确认（Ask permissions）模式：Claude 要跑一个工具，就问你"可以跑这个工具吗"，你回 yes 或 no。一年半前，那已经是我们能做到的最好方式了，因为当时没有分类器， 模型对齐也没今天这么好 。 所以 auto mode 是一个很大的进步，因为其实你并不想读大多数这种请求，把它路由给