Claude Code之父的忠告：自动化才是工程师的护城河

近几年，软件工程发生了翻天覆地的变化。许多资深开发者会有一种被时代抛弃的失落感——那些在 VS Code、Atom、Sublime Text 里精心配置环境、打磨工具链的乐趣，似乎正在消失。但 Claude Code 的原始创造者之一 Boris 最近发布的一篇帖子，却给出了一个截然不同的视角：真正热爱工程的人，现在反而应该感到兴奋。

本文基于 YouTube 频道 Theo（t3.gg）对 Boris 观点的解读与延伸展开。Theo 认为，Boris 过往关于"工程师将被取代"的言论有些偏激，但这次的帖子却精准地击中了工程师群体真正应该关注的核心。

为什么资深工程师反而应该兴奋

Boris 的核心论点是：过去最优秀的工程师，往往会花大量时间自动化自己的工作——写更好的 Vim/Emacs 配置、编写 lint 规则捕获重复问题、搭建端到端测试套件以免手动冒烟测试。

Vim 和 Emacs 是两款诞生于上世纪70-80年代的文本编辑器，至今仍被大量资深开发者使用。围绕它们形成了一种独特的"工具匠"文化——开发者花数百小时编写配置文件，定制快捷键、代码补全、语法高亮和自动化宏，将编辑器打造成高度个性化的开发环境。这种文化的核心信念是：投入时间优化工具本身，长期来看会带来指数级的效率回报。Boris 提到的这些活动——写 lint 规则、搭建测试套件——本质上都属于这种"磨刀不误砍柴工"的工程哲学。这些是工程师能做的"最高杠杆"的活动，因为它们成倍放大了个人产出。

Theo 用他在 Twitch 时期的一个例子生动地说明了这种"聪明的解决方案"的价值：他们有一个端到端测试，让两个机器人进入同一个 Twitch 频道，一个发消息、另一个验证消息是否正确渲染。这个测试极其简单，只需启动两个已登录的 Playwright 浏览器实例，却比任何其他手段都更早地捕获到故障。

Playwright 是由微软开发的开源浏览器自动化框架，支持 Chromium、Firefox 和 WebKit 三大浏览器引擎。与传统的单元测试（验证单个函数的正确性）不同，端到端测试（E2E Testing）模拟真实用户的完整操作流程——打开页面、点击按钮、输入文本、验证结果。Theo 描述的测试案例之所以巧妙，在于它用极低的实现复杂度覆盖了极高的系统复杂度：Twitch 的实时消息系统涉及 WebSocket 连接、消息队列、渲染管线等多个子系统，而两个浏览器实例之间的消息收发验证，能一次性穿透所有这些层级。冒烟测试（Smoke Testing）则是指在每次部署前快速验证核心功能是否正常的轻量级测试，名称来源于硬件工程中"通电看是否冒烟"的做法。

"把最复杂的系统用最简单的方式保证其正确性"——正是这种解决问题的思维方式，让某些人比其他人更享受当下的 AI 时代。

自动化的杠杆效应在AI时代被成倍放大

Boris 指出，这些自动化如今变得更加重要。原因很直接：开发者体验的自动化能加速你的工作，而当你运行"一支 agent 大军"时，每一个 agent 都会因此提速。更多的自动化意味着单位时间内更多的产出。

这里的"agent"指的是能够自主执行编程任务的 AI 代理，如 Claude Code、Cursor Agent、Devin 等。与传统的代码补全助手不同，这些 agent 能够理解任务目标、自主浏览代码库、运行命令、调试错误，完成从需求到代码提交的完整流程。"一支 agent 大军"描述的是一种新兴工作模式：开发者同时启动多个 agent 实例，分别处理不同的任务分支。这种并行化之所以可行，依赖于 Git 的 worktree 功能——它允许在同一个仓库中同时检出多个工作目录，每个 agent 在各自独立的 worktree 中工作，互不干扰。当你从管理一个开发者变成管理十个并行 agent 时，任何基础设施层面的改进都会获得十倍的回报。

Theo 补充了一个有趣的观察：过去他推崇的很多东西——比如快速搭建预览环境（Vercel 那种）——曾遭到团队的不少反对，"没人真正需要这些预览环境，反正都在本地跑"。但现在情况完全不同了：当你的代码由分布在云端、后台标签页、work tree 或局域网其他机器上的 agent 构建时，一个好用的预览环境体验就变得极其宝贵。

预览环境（Preview Environment）是指为每个 Pull Request 或代码分支自动部署的临时运行实例，允许团队成员在合并代码前直接访问和测试变更效果。Vercel 是这一理念的主要推动者——当开发者向 GitHub 推送代码时，Vercel 会自动构建并部署一个带有唯一 URL 的预览版本。过去这被部分团队视为"锦上添花"，因为开发者习惯在本地运行 localhost 来预览效果。但在 agent 编程时代，情况发生了根本变化：agent 可能运行在远程服务器、CI 流水线或云端容器中，根本没有"本地"的概念。一个稳定可访问的预览环境，成了验证 agent 产出质量的关键基础设施。

把领域知识"编码"成基础设施

Boris 的第二个论点是：把工作转移到代码里能提升效率。你的 agent 可以每次遇到问题都去修复它，但那会消耗 token，还可能遗漏某些情况。而如果让 Claude 去写一条 lint 规则、一个 CI 步骤或例行流程，那么这一整类问题就能被永久自动化。

Token 是大语言模型处理文本的基本计量单位，大致相当于一个英文单词的四分之三。每次 AI agent 阅读代码、理解上下文、生成回复都在消耗 token，而 API 调用按 token 数量计费。以 Claude 为例，输入和输出 token 的价格不同，长上下文的对话成本可能达到每次数美元。Boris 提到的"消耗 token"不仅是经济成本问题，更是效率问题：agent 每次重新理解和修复一个已知问题，都在浪费计算资源和时间。相比之下，一条写好的 lint 规则在本地毫秒级执行，零 token 成本，且百分百可靠。这就是为什么把重复性问题"下沉"到确定性工具层面，在 AI 时代具有全新的经济意义。

这正是人们谈论"loops"（循环）时的真正含义——自动化整类繁琐工作，而非一次次单独解决。这并非新理念，工程师一直在这么做，但 AI 让门槛大幅降低。

Theo 举了自己的一个鲜活案例：他发现 agent 无法通过 CLI 向 PR 添加视频文件（GitHub UI 拖拽上传的机制无法程序化调用）。于是他在 Cloudflare 上搭建了一个自己的文件上传服务 files.tslop.org，配上密钥分发到他机群里的所有机器，现在这些机器都能上传文件并把链接贴进 PR。

"过去手写这些代码根本不划算，除非你极其频繁地遇到这个问题。而现在 agent 撞上这些问题的频率高得多，一切突然就变得有意义了。"做这些一次性小工具带来的乐趣远超预期。

SolidJS 的创造者 Ryan 也印证了这一点：他历来不喜欢深度配置环境、管理更多活动部件，但 AI 让他第一次觉得"搭建这些东西终于值得了"。更关键的是，如今大多数团队也更愿意让开发者投入时间做这类实验——过去你花三天调 Vim 配置会被老板质疑，现在则完全被鼓励。

让其他人（和Agent）也能顺利贡献代码

这是 Boris 帖子中最重要、也最具争议的一点：自动化让其他人更容易为代码库做贡献。他观察到，工程师现在第一天就能贡献代码（因为 Claude 能替他们导航代码库），甚至非工程师也能像工程师一样有效地贡献。

Boris 认为，阻碍这一切的往往是"存在于人们脑子里、而非编码进自动化"的领域知识。而 agent 带来的改变是：领域知识可以被编码为基础设施——通过代码注释、skills、CLAUDE.md 规则和 memories 来捕获，不再局限于 lint 规则、类型和测试所能表达的范围。

CLAUDE.md 是 Claude Code 引入的一种项目级配置文件，放置在代码仓库根目录，用自然语言描述项目的架构约定、编码规范、常见陷阱和工作流程。当 Claude Code 进入一个代码库时，会首先读取这个文件来建立上下文理解。类似的概念还有 Cursor 的 .cursorrules、GitHub Copilot 的 .github/copilot-instructions.md 以及更通用的 AGENTS.md。这些文件本质上是一种新型的"文档即代码"实践——它们不是写给人看的传统文档，而是写给 AI agent 的操作指南。Skills 和 memories 则是 Claude Code 的进阶功能：skills 是可复用的任务模板，memories 是 agent 在交互中积累的持久化上下文记忆。这整个生态代表了一种全新的知识管理范式：将隐性的团队知识显性化为机器可读的指令。

Theo 对此观点略有保留（尤其考虑到当前技术阶段），但高度认同其核心：作为有经验、懂得好坏代码库区别的工程师，我们的职责是搭建系统，让新人（无论是人还是 agent）进入时更可能维持代码库的质量。这些"护栏"可以是自定义 lint 规则、架构结构，也可以只是 Markdown 文件。

"蠢问题"规则与新手视角的价值

Theo 分享了他管理团队时一直坚持的"蠢问题规则"：新成员每天至少要问一个问题，否则当天工作不算结束。这不仅能帮他们解除阻塞，更重要的是，能让他获得"新人第一次探索代码库时哪里卡住"的直觉——因为"你只有一次机会做代码库的新手"。这种洞察对于让代码库更易上手、预防特定类型的回归极其有价值。

如何正确编写CLAUDE.md引导文件

Theo 给出了几条非常具体的实践建议：

• 不要让 agent 自己写 CLAUDE.md 或 AGENTS.md。这恰恰是值得亲手投入精力的地方，因为你需要理解是什么导致了 agent 的不同行为。
• 观察 agent 的实际行为，再调整这些文件和工具链，以引导模型走向你想要的方向。
• 不要一上来就装满各种 skill 和插件。应该先用工具的默认配置发几个 prompt，看哪里出问题，再针对性地构建解决方案。
• 用尽可能少的上下文发送 prompt，以此测试哪些信息需要被编码进这些引导文件。

一个关键判断标准是：如果你的 CLAUDE.md 只是罗列"代码在哪个位置"，那不是好的引导文件。这些文件应该把模型引导向成功，而非指向具体的代码行。你甚至可以用引导文件让模型主动拒绝某些请求——比如写上"如果有人请求这个功能，停下来告诉他们不行"，它就会照做。

这才是成为高级工程师的路径

Theo 抛出了一个可能有争议的观点：这些技能正是你成为高级工程师的方式。从优秀的个人贡献者，成长为能推动整个团队和业务前进的人，要求你的工作不仅提升自己和产品，还要提升团队的贡献能力。

Staff Engineer（Staff 工程师）是硅谷科技公司中 Individual Contributor（个人贡献者）技术路线的高级职级，通常位于 Senior Engineer 之上，与管理路线的 Engineering Manager 平级。到了 Principal Engineer 和 Distinguished Engineer 级别，则相当于 VP 甚至 SVP 的影响力。Staff 工程师的核心能力不再是写出最精妙的算法或最优雅的代码，而是通过技术决策、架构设计、工具建设和跨团队协调来放大整个工程组织的产出。Will Larson 的《Staff Engineer》一书将这种角色归纳为四种原型：Tech Lead（技术领导）、Architect（架构师）、Solver（难题解决者）和 Right Hand（高管右手）。

但 Theo 的"最辣观点"是：这其实并不新鲜。通往 Staff Engineer 的道路从来不是"写更多代码"，而是"搭建这些结构和系统"。AI 带来的真正改变是——你现在可以独自完成这件事了。

"过去我做个人项目时，根本体会不到别人贡献时的感受，因为所有上下文都在我脑子里。而现在有了 agent，连我自己的个人项目都超出了我个人的理解范围，所以我必须专注于搭建这些系统。"

随着行业持续朝这个方向演进，"打造让代码能被最有效地落地的环境"这项技能，将远比"自己亲手落地代码"更重要。对于希望走向 Senior、Principal、Staff 的开发者而言，这些能力将是最关键的。

改变确实令人害怕，但一旦跨过那条线，编程会重新变得有趣——甚至比以往任何时候都更有趣。

核心要点