The bigger payoff comes when fixing and maintaining happens in the background and your teams can focus on building. That's when you start doing things that weren't even in range before. Anthropic is on step 3 and pushing toward 4. Personally, I just hit level 4. Curious where you are -- what step is your team on?
更大的回报出现在修复与维护都能在后台完成、而你的团队可以把注意力放在构建上的时候。那时你就会开始做一些此前甚至都不在能力范围内的事。Anthropic 目前在第 3 步，并正朝着第 4 步推进。就我个人而言，我刚达到第 4 级。很好奇你们现在处在哪——你的团队处于哪一步？
Once your teams are bought in, how do you track it? Usage is worth watching (e.g. a dashboard), but it measures activity, not return. A better question: would you have spent engineering effort on this anyway? If yes, how much and what would it have cost in manual eng-hours? That's your return.
当你的团队都已经 buy in（认同并接受）之后，你要如何追踪这件事？usage（使用量）值得关注——比如看 dashboard（仪表盘）——但它衡量的是 activity（活动量），不是 return（回报）。一个更好的问题是：这件事你原本是否也会投入 engineering（工程）精力去做？如果会，要投入多少，以及按手工方式需要花费多少 eng-hours（工程工时）？这就是你的回报。
In practice that means giving Claude ways to verify its own work end to end. It means enabling auto mode for permissions, defaulting on automated code review and security review, and using interfaces that let you manage multiple agents at once (Agent view in CLI, Desktop app, iOS and Android apps, Tag). To get to higher levels it means /loop, /batch, dynamic workflows, and worktree isolation for subagents. It's not about a single feature, but rather using the right features with the right guardrails that enable Claude to automate entire classes of work in a way that your team can trust the output.
在实践中，这意味着要给 Claude 提供能够端到端验证其自身工作的方式。这意味着为权限启用 auto mode，默认开启自动化 code review 和 security review，并使用那些能让你同时管理多个 agent（智能体）的界面（CLI 中的 Agent view、Desktop app、iOS 和 Android apps、Tag）。要达到更高等级，则意味着使用 /loop、/batch、dynamic workflows（动态工作流），以及为 subagents 提供 worktree isolation（工作树隔离）。关键不在于某个单一功能，而在于结合合适的 guardrails（护栏机制）使用正确的功能，让 Claude 能以你的团队可以信任其输出的方式，将整类工作自动化。
Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things. I think many of these automations have become even more important now. This is true for a number of reasons. First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time. Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time! Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation. Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.
我一直在想一件事：过去，我认识的最优秀的工程师都会花很多时间以各种方式把自己的工作自动化。比如更好的 vim/emacs 自动化，编写 lint 规则来捕捉重复代码问题，搭建一整套 e2e 测试，这样他们就不需要手动对 app 做 smoke test。这类事情是工程师能做的杠杆最高的工作，因为它能放大他们自己的产出，而这反过来又意味着他们能构建更多东西。我认为，现在这些自动化已经变得更加重要了。原因有很多。第一，infra 和 DevX 自动化能让你更快。如果你还在运行一支 agent 大军，那么这些 agent 里的每一个也都会被加速。更多自动化 == 单位时间内更多产出。第二，把事情转移到代码里会提升效率。你的 agent 也许可以在每次看到某个问题发生时都去修复它，但那会消耗 token，而且还可能漏掉一些情况。如果 Claude 转而写一个 lint 规则、CI 步骤或例行程序，那么这类问题就可以被彻底自动化，并且永久解决。这其实就是人们谈论 loops 时真正想表达的意思——重点不是一次性地解决单个问题，而是把整类繁琐工作自动化掉。这根本不是什么新想法。工程师这么做已经很久了！第三，也是最重要的一点，自动化能让其他人更容易为 codebase 做贡献。我越来越多地看到，工程师在第一天就能开始为 codebase 提交贡献，因为 Claude 可以替他们理解和导航 codebase；同时，非工程师如今也能像工程师一样高效地为 codebase 做贡献。而阻碍这两件事的，恰恰是那些存在于人脑中、而不是存在于自动化里的领域知识——也就是你过去在 ramping up 时必须学习的那些东西。agent 带来的变化在于：能够被编码为基础设施的领域知识，不再局限于 lint 规则、类型和测试所能表达的内容；它现在几乎可以涵盖所有领域知识，并以代码注释、skills、CLAUDE.md 规则和 memories 的形式被编码下来。如果我给一个自己并不了解的 iOS codebase 提了一个 PR，而 code reviewer 因为我没有使用正确的 framework 拒绝了它；或者如果一个设计师做了一个新功能，却因为没有遵循正确的架构模式而被拒绝，这些都说明自动化失败了。每个团队都应该编写那些 CLAUDE.md、REVIEW.md、skills 和文档，使 agent 即使在 prompter 不额外提供任何上下文的情况下，也能在他们的 codebase 中高效工作。这听起来很疯狂，但同时它也是工程师一直以来所做之事的自然延伸：自动化，并把领域知识编码为基础设施。随着 model 变得更聪明、harness 日趋成熟，这项工作会变得更容易。与此同时，每个团队都应该主动寻找方法，把自己的领域知识转化为 infra，这样 Claude 就能写出更好的代码，code review 就能自动捕捉问题，而下一个接手你们 codebase 的人也能更轻松地做出贡献。
New in Claude Code: /checkup Run /checkup to: 1. Clean up unused skills/MCPs/plugins and save context 2. Dedup your local CLAUDE.md against the checked in CLAUDE.md 3. Break up root CLAUDE.md into nested CLAUDE.md's + skills 4. Turn off slow hooks 5. Update your Claude Code to the latest version 6. Enable auto mode by default 7. Pre-approve frequently denied read-only commands .. And a few other goodies. /checkup confirms with you before making any changes. Enjoy!
Claude Code 新功能：/checkup 运行 /checkup 可以：1. 清理未使用的 skills/MCPs/plugins，并节省 context（上下文）2. 根据已 check in 的 CLAUDE.md，对你本地的 CLAUDE.md 进行去重 3. 将根目录的 CLAUDE.md 拆分为嵌套的 CLAUDE.md 和 skills 4. 关闭慢速 hooks 5. 将你的 Claude Code 更新到最新版本 6. 默认启用 auto mode 7. 预先批准经常被拒绝的只读命令……以及其他一些实用功能。/checkup 会在进行任何更改之前先与你确认。请享用！
As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Claude Code team I see what I think is five archetypes: 1. Prototyper: comes up with brand new ideas; churns out many ideas, most of which don't ship 2. Builder: quickly turns a prototype/idea into production-grade product/infra 3. Sweeper: cleans up the UI, simplifies the code and system, unships, optimizes performance 4. Grower: takes a product that has been built and iterates on it to improve Product-Market Fit 5. Maintainer: owns a mature system to make it secure, reliable, fast, and efficient as it scales Many people span across 2 roles, and sometimes 3 roles. I also notice that these roles are not really tied to job function -- eg. across Anthropic, some designers match category 1, some 2, some 3; same for engineers, PM, DS. A healthy team needs a mix of these, depending on the product: - A product that is new and pre-PMF needs people that are strong at 1+2+3 - A product that is growing and has found PMF needs 2+3+4 and some 5 - A product that has strong PMF needs 3+4+5 and some 2 Maybe product roles of the future will look more like this, and less like the domain-specific roles of today?
随着 engineering、product、design、DS 等逐渐融成一种新型角色，我一直在想，未来的角色形态可能会是什么样。比如，当我看 Claude Code 团队时，我会看到我认为存在的五种 archetype（原型角色）：1. Prototyper：提出全新的想法；大量产出点子，其中大多数不会真正发布 2. Builder：快速把 prototype（原型）/idea 变成达到生产标准的 product/infra（基础设施） 3. Sweeper：清理 UI、简化代码和系统、下线功能、优化性能 4. Grower：接手一个已经做出来的产品，持续迭代，以提升 Product-Market Fit（产品市场契合度） 5. Maintainer：负责一个成熟系统，使它在规模扩张时依然安全、可靠、快速且高效。很多人会横跨 2 种角色，有时甚至 3 种。我也注意到，这些角色其实并不真正绑定某种 job function（职能）——比如在 Anthropic，不少 designer 属于第 1 类，有些属于第 2 类，有些属于第 3 类；engineer、PM、DS 也是一样。一个健康的团队需要这些角色的组合，而且会因产品不同而不同：- 一个全新、且处于 pre-PMF（PMF 前）阶段的产品，需要擅长 1+2+3 的人 - 一个正在增长、并且已经找到 PMF 的产品，需要 2+3+4，以及一些 5 - 一个拥有强 PMF 的产品，需要 3+4+5，以及一些 2。也许未来的 product 角色会更像这样，而不像今天这种按领域细分的角色？
Cool way to use Claude Code: deciphering Linear A, a 3500 year old written language from Crete Hope this holds up in peer review! 🤞
一个很酷的 Claude Code 用法：破译 Linear A——一种来自 Crete、已有 3500 年历史的书写语言。希望这能经得起 peer review（同行评审）！🤞
I've been using Artifacts in Claude Code for everything: visual explanations of tricky code, system diagrams, quick previews of a few animation options, data analyses and dashboards I share with the team. They are a game changer for how I work with Claude. Can't wait to hear what you think!
我一直在 Claude Code 里把 Artifacts 用于各种事情：对棘手代码的可视化解释、系统图、几种动画方案的快速预览、以及我会与团队分享的数据分析和 dashboard。它们彻底改变了我与 Claude 协作的方式。等不及想听听你的看法了！
Hello from Code with Claude Tokyo!!
来自 Code with Claude Tokyo 的问候！！
Fable 5 is the biggest step up I’ve felt in our models since Opus 4.5 back in November. After 4.5 came out I uninstalled my IDE when I realized that I’d been doing 100% of my coding in a terminal for a few weeks. With Fable, it’s felt like Claude has stepped up from being a coding agent to a thought and design partner in building the product. Fable has judgement, taste, and dimensionality in a way that previous models didn’t, leading me to trust it more with the most complex work. I think the first time I had this realization was when I asked Fable to debug something. It is the first model I have used that was so methodical and precise, taking measurements and adding logs then verifying that it truly fixed the issue before declaring victory. There’s nothing in claude code’s prompting telling the model to do that, it’s just part of its personality. It really has this “big model smell” that I haven’t felt before.
Fable 5 是自去年 11 月的 Opus 4.5 以来，我在我们模型上感受到的最大一次跃升。4.5 发布后，当我意识到自己连续几周 100% 都是在 terminal（终端）里写代码时，我就把 IDE 卸载了。用了 Fable 之后，我感觉 Claude 已经从一个 coding agent（编程 agent）升级成了与我一起构建产品的思考与设计伙伴。Fable 具备以往模型所没有的 judgement（判断力）、taste（品味）和 dimensionality（维度感），这让我更愿意把最复杂的工作交给它。我第一次真正意识到这一点，应该是在我让 Fable 去 debug（调试）某个问题的时候。它是我用过的第一个如此有条理、如此精确的模型：会先做测量、添加日志，再确认问题确实被修复之后才宣告完成。claude code 的 prompting（提示词）里并没有任何内容要求模型这么做，这就是它个性的一部分。它确实有一种我以前从未感受过的“big model smell”。
We talk a lot about how important it is to set up self-verification loops. Especially in the age of powerful models that can run for long periods of time, self-verification is a key ingredient that enables the model to run for much longer, delivering a result that is closer to what you intended, so you can do more without having to constantly check in on Claude as it works. @delba_oliveira gives a great breakdown of what that looks like and why it matters
我们经常讨论，建立 self-verification loops（自我验证循环）有多么重要。尤其是在强大模型可以长时间持续运行的时代，self-verification 是一个关键要素，它让模型能够运行更久，交付出更接近你原本意图的结果，这样你就能做更多事情，而不必在 Claude 工作时一直不断去盯着它。@delba_oliveira 对这具体是什么样子、以及它为什么重要，做了非常出色的拆解。
When we first demoed Claude Code internally, it got two reactions on Slack. A year after GA, @_catwu and I sat down to talk about what's changed: why I use auto mode instead of plan mode, how routines fix bugs before I see them, why I do most of my coding from my phone now, and where the product is going
当我们第一次在内部演示 Claude Code 时，它在 Slack 上引发了两种反应。GA（正式可用）一年后，@_catwu 和我坐下来聊了聊发生了哪些变化：为什么我用 auto mode 而不是 plan mode，routines 如何在我看到 bug 之前就把它们修好，为什么我现在大多数编码工作都是在手机上完成的，以及这个产品将走向何方。
Seeing a number of benchmarks showing Opus is the best model for long-running work. Five tips for running Opus autonomously for hours/days: 1. Use auto mode for permissions, so Claude doesn’t ask for approval 2. Use dynamic workflows, to have Claude orchestrate hundreds/thousands of agents to get a task done 3. Use /goal or /loop, to nudge Claude to keep going until it’s done 4. Use Claude Code in the cloud, so you can close your laptop (easiest way is the desktop or mobile app) 5. Make sure Claude has a way to self-verify its work end to end: Claude in Chrome browser extension for web, iOS/Android sim MCP for mobile, a way to start the full web server or service for backend work
我看到不少 benchmarks（基准测试）都表明，Opus 是最适合长时间持续工作的 model（模型）。让 Opus 自主运行数小时/数天的五个技巧：1. 对权限使用 auto mode（自动模式），这样 Claude 就不会反复请求你的批准 2. 使用 dynamic workflows（动态工作流），让 Claude 编排数百/数千个 agents（智能体）来完成任务 3. 使用 /goal 或 /loop，推动 Claude 持续执行直到任务完成 4. 在云端使用 Claude Code，这样你就可以合上 laptop（笔记本电脑）了（最简单的方式是使用桌面或移动 app） 5. 确保 Claude 具备端到端自我验证其工作的能力：用于 web 的 Chrome browser extension，面向 mobile 的 iOS/Android sim MCP，以及一种能够为 backend work 启动完整 web server 或 service 的方式
Cowork is at its best on work that’s too big for a chat: research across dozens of accounts, recurring reports, triaging my inbox and drafting replies. If you’ve been curious, this is a good month to find out what it can take off your plate. Can’t wait to see what you do.
当工作大到不是一场 chat 就能搞定时，Cowork 最能发挥作用：例如横跨几十个账户的研究、周期性报告、整理我的收件箱并起草回复。如果你一直很好奇，现在正是个适合看看它能帮你分担哪些工作的月份。迫不及待想看看你会怎么用它。
We doubled Claude Cowork usage limits for the next month. This applies to your 5-hr rate limits. If you’ve been saving up a big messy project, now’s the time.
我们将 Claude Cowork 在接下来一个月的使用限额翻倍了。这适用于你每 5 小时的 rate limits（速率限制）。如果你一直在攒一个庞大又混乱的项目，现在就是时候了。
The teams seeing the biggest wins from AI are completely changing how they work, not speeding up what they already do. What steps can you delete, what handoffs go away, what can an agent just own end to end. Great to see Salesforce go this deep. Shoutout to Srini, @Benioff & team. Full writeup:
那些从 AI 中获得最大收益的团队，正在彻底改变他们的工作方式，而不是仅仅给自己原本在做的事提速。哪些步骤可以删除，哪些交接可以消失，哪些事情可以直接由一个 agent（智能体）端到端负责。很高兴看到 Salesforce 做到这么深入。向 Srini、@Benioff 和团队致敬。完整文章：
Quality went up alongside output. Even with more PRs shipping, total incidents dropped 5%. They built security guardrails and quality standards into the agentic workflow itself. Productivity vs quality is sometimes framed as a tradeoff. They're not seeing it.
质量随着产出一同提升。即使有更多 PRs 交付上线，总 incident（事故/故障）数量还是下降了 5%。他们把安全 guardrails（护栏机制）和质量标准直接内建进了 agentic workflow（智能体工作流）本身。生产力与质量有时会被表述成一种权衡关系。但他们并没有看到这种情况。
Salesforce published a detailed writeup on going agentic with Claude Code. A couple things jumped out. A migration they'd scoped at 231 days shipped in 13. One PR delivered 21 endpoints at 100% test coverage.
Salesforce 发布了一篇关于如何用 Claude Code 推行 agentic 的详细文章。有几件事特别醒目。一个原本估算需要 231 天的迁移项目，13 天就交付了。还有一个 PR 一次性交付了 21 个 endpoint（接口），测试覆盖率达到 100%。