automate everything

Claude Code’s creator has some really good advice 观后感

现在，为 codebase 里的具体问题写定制化自动化工具，越来越值得了。

以前我可能会觉得，给项目写一个很特殊的 lint rule，或者专门搭一套只解决某个小问题的脚本，投入和回报不太成比例。除非这个问题会反复出现很多次，否则还不如在 code review 里顺手看一眼。但 coding agent 改变了这件事的成本。现在，写一个几百行的 lint rule、CI 检查、测试脚本，或者一个专门供 Agent 使用的 skill，都比以前容易得多。很多以前“想做但不值得做”的自动化，现在真的可以做了。

我们已经不可能完全理解自己的 codebase

当一个项目里大量代码由 Agent 生成、修改和组合时，我们很难像以前那样对整个 codebase 保持完整理解。代码越多，系统越复杂，这个问题就越明显。所以更现实的做法是，确保那些真正决定代码质量的地方是清楚的、可检查的、不会轻易被绕开的。比如 API 和模块之间的边界、不能重复出现的 bug、团队对代码风格和实现方式的偏好等等。

如果这些东西只存在于某个人的脑子里，那么它们迟早会在换人、扩团队或者 Agent 参与开发之后失效。把它们写成类型、测试、lint rules、CI steps、脚本、文档、AGENTS.md、CLAUDE.md 或 skills，至少可以让它们变成 codebase 的一部分。

不要让 Agent 每次都手动修同一种错

我现在越来越倾向于这样判断问题：如果 Agent 第一次遇到一个问题，可以直接修掉。如果同一个问题第二次出现，就应该考虑把它记录下来。如果第三次出现，就绝对应该把它自动化。例如，Agent 每次都把某种特定的 API 调用方式写错。你当然可以在每个 PR 里让它改回来，但这件事会不断消耗 Agent 的 token，也会消耗人的注意力，而且它还可能漏掉某些情况。自动化的做法比如写一个 lint rule，直接阻止这种写法；增加一个测试，让错误行为无法通过 CI；写一个 skill，让 Agent 在执行这类任务时自动遵循固定流程；在 AGENTS.md 或 CLAUDE.md 里补充一条明确的行为约束等等。第一次写这些东西可能需要花一点时间，但之后每个 PR 都能复用，变成了一个可以长期工作的规则。这其实就是把 one-off fix 变成 automation loop。

自动化不只是为了提高自己的效率

定制化工具最直接的好处，是让自己写代码更快。但它真正有价值的地方，往往不止于此。它还可以让其他人更容易接手 codebase。新成员第一次进入一个陌生项目时，不可能马上掌握所有上下文。他不知道哪些目录可以改，哪些抽象不能绕过，也不知道团队为什么选择某种实现方式。如果这些知识只存在于老成员的口头解释里，新人只能不断提问，然后等待别人回复。Agent 也一样。它虽然可以搜索代码，但搜索到的信息不等于真正理解了项目的约束。好的自动化可以在新人和 Agent 犯错之前，或者至少在错误进入主分支之前，给出明确反馈。比如：

lint rule 告诉他某种写法不能使用；
测试告诉他某个行为已经破坏；
CI 检查告诉他缺少必要的验证；
skill 告诉 Agent 处理某类任务时应该遵循什么顺序；
文档说明某个决定背后的原因，而不是只列出文件路径。

这样做的目标不是让新人完全不需要理解项目，而是减少那些只能靠“问一个熟悉代码库的人”才能获得的隐性知识。

这可能就是 Senior Developer 的另一种含义

我越来越觉得，Senior Developer 和普通开发者的区别在于，Senior Developer 会减少团队以后需要重复解决的问题。他会搭建测试，让别人不需要手动验证一堆东西；会写 lint rules，让错误写法无法进入代码库；会整理文档，让新人少走一些弯路；会设计更清楚的模块边界，让其他人更容易继续开发。Agent 让这件事变得更容易了。以前一个人很难花几天时间专门完善 Vim 配置、预览环境或者一套项目内部工具，因为团队很可能觉得这不是当前任务。现在，Agent 可以承担很多实现工作。工程师真正需要投入的是判断：哪些问题值得自动化，规则应该写在哪里，反馈应该长什么样，以及怎样验证这个工具确实在工作。

这会让一个人的影响范围扩大：自己写代码时更快；自己的 Agent 更不容易犯错；新成员更容易理解项目；其他人的 Agent 也更容易遵循团队规则；整个团队减少重复劳动。