@bcherny: 我一直在思考的一件事：过去，我认识的最优秀的工程师们花大量时间以各种方式自动化自己的工作……

我最近一直在思考一件事：过去，我认识的最优秀的工程师会花大量时间以各种方式自动化他们的工作。无论是优化 vim/emacs 的自动化操作，编写 lint 规则来捕获重复的代码问题，还是构建一套端到端测试以避免手动冒烟测试应用，这些都属于工程师能做的最高杠杆活动，因为它们放大了工程师自身的产出，从而让他们能构建更多东西。

我认为现在这些自动化变得比以往更加重要。原因有几点。

首先，基础设施和开发者体验（DevX）自动化能加速你的工作。如果你正在管理一组智能体，那么每个智能体也会因此加速。自动化越多，单位时间的产出就越大。

其次，将事情迁移到代码层面能提升效率。你的智能体可以在每次发现问题时修复它，但这会消耗 token，并且可能遗漏某些情况。相比之下，如果 Claude 编写一条 lint 规则、一个 CI 步骤或一套例程，那么这类问题就能永久地完全自动化。这正是人们谈论“循环“（loops）时的真正含义——自动化整类杂务，而非逐个解决。这并非全新的想法，工程师们已经这样做了很久！

第三点，也是最重要的一点：自动化让他人更容易为代码库做出贡献。我越来越多地看到，工程师在第一天就能为代码库做贡献，因为 Claude 可以帮他们导航代码库；而非工程师也能像工程师一样高效地贡献代码。阻碍这两者的，往往是那些存在于人们脑中而非自动化中的领域知识——那些过去你必须在上手时学习的东西。得益于智能体，现在可以将领域知识编码为基础架构，这种能力不再局限于 lint 规则、类型和测试所能表达的范围；它几乎可以捕获所有领域知识，编码成代码注释、技能、CLAUDE.md 规则和记忆。如果我在一个不熟悉的 iOS 代码库上提交 PR，而代码审查者因为没使用正确框架而拒绝它；或者设计师构建了新功能，却因为没遵循正确的架构模式被拒绝——这些都是自动化的失败。

每个团队都应该编写 CLAUDE.md、REVIEW.md、技能和文档，使智能体能够在零额外上下文的情况下高效地在他们的代码库中工作。这听起来有点疯狂，但同时也是工程师一直在做之事的自然延伸：自动化，并将领域知识编码为基础架构。随着模型变得更聪明，工具链更成熟，这个任务会变得更加容易。与此同时，每个团队都有责任寻找将领域知识转化为基础设施的方法，这样 Claude 就能更好地编写代码，代码审查能自动捕获问题，下一个在你们代码库上工作的人也能更容易地做出贡献。

这就是为什么 Claude Code 总是告诉我它要“跑一个冒烟测试“—— @bcherny 教会了它这个。

嘿 @bcherny 你看到这个了吗哈哈？