当代码变得廉价，判断力成为工程师的核心工作

哥们，你在干什么！？装个 Cursor，别再浪费我们的时间了，你知道你在烧多少钱吗？

那是我醒悟的时刻：这家公司不一样。快速交付不只是我们嘴上说说，我们真的交付得很快。每天，一天多次，甚至周五下午5点也一样。

你可能觉得这很可爱，但对于一个21人的工程团队来说，我们的交付速度是我两年前无法想象的，那时我那个年轻的老板还因为我用老派方式写代码而训斥我。

我们现在自动批准并合并16% 的拉取请求，执行大爆炸式迁移，每周交付几百个 PR，把 1000 行的拉取请求当成家常便饭，而且AI 写了我 97% 的代码。在一个运维繁重、一次故障可能造成数千美元损失的业务中，这些大多没有搞出乱子。

自从每天放学后用 Turbo Pascal 写代码以来，我还没这么开心过。以下是我们如何做到的，以及自 2024 年以来我们的工程文化发生了哪些变化。

责任第一

我接下来要描述的一切之所以有效，是因为我们有高度负责、高度自主的文化。我们不在乎你怎么写代码，但你要用你的电话号码为那东西签字。

我合并拉取请求的政策很简单：
我们有你的电话号码

当你用 AI 写代码时，那仍然是你的电话号码

— Swizec Teller (@Swizec) February 3, 2026

当你把一个系统交付到生产环境时，它归你维护运行。当你构建一个功能时，它归你让它发挥作用。我们期望每位工程师与用户交流，观察利益相关者的工作，并对自己的代码负责。我们团队里没有“把英语翻译成代码”的开发者。那种事我们有 AI。

如果你接受这个约定，我们几乎从不对一个想法说不。先交付，后提问。我们热爱挫折驱动的开发，我们许多最酷的功能都来自工程师尝试一些别人认为不可能的有趣事情。

当然，如果你最初的想法看起来有前途，我们会给你时间和空间去充实它。

工程发生了怎样的变化

当我加入 Plasmidsaurus 时，AI 编码开始变得好用。我们有智能自动补全，一半有用，一半烦得要命。你得跟编辑器较劲才能写完一个想法，还得把它写的一切反复检查三遍。

没人确定用 AI 是让自己更快还是更慢。我们都同意它奏效时感觉像魔法，但当你的编辑器幻觉出一个不存在的方法时，就会增加很多摩擦。直接跟语言服务器对话啊，真是的！

我最喜欢的用例是把 SQL 查询翻译成 SQLAlchemy 代码。Plasmidsaurus 是用我十年没用过的技术栈（Flask+SQLAlchemy）构建的，而且从未如此认真地用过。使用 AI 让我把通用的软件工程经验转化为特定技术栈的语言变得容易多了。

即使现在，我也更愿意用 SQL 思考，然后翻译成我们技术栈偏爱的别扭的 Python 语法。

早期的氛围编程

到 2024 年底，氛围编程开始变得可行。你可以指导你的 AI 编写简单代码，但很别扭。我知道的最好办法是手动把东西复制粘贴进 ChatGPT 再复制出来。

你会描述你的上下文，粘贴有用的代码片段，然后要求一个能运行的脚本。脚本勉强可以在云端运行测试，但整个做法很笨拙。

你不能把 vibe code 作为构建产品的主要方式。我喜欢用它来写那些验证快但生成起来很麻烦的代码。比如数据库迁移和小型管理脚本。任何写代码会让你脱离主要任务心流的事情。

说“这是我们的数据库 schema，添加这个新概念以及到 A、B、C 的外键”比停下对架构的思考、亲手把这一切写出来要容易。你 5 秒内就知道它能不能跑，其中一半还是 python 启动时间。

任务委派的开始

对我来说，第一次重大转变发生在 2025 年 7 月，当时 Cursor 推出了后台 agent。你现在可以把整个任务委派给机器了！

我对 vibe coding 最大的不满是我得看着机器干活。你写一个提示词，然后哇，看 AI 干得多起劲，它思考得好努力！你看着思维链，看着工具调用，看着代码成形，看着它走错路，看着它试图测试自己的工作。我的宝贝 🥺

但那是在浪费时间。你不会雇一个水管工，然后站在他肩膀后面看他修你的水槽。雇人帮忙的全部意义就是买回你的时间。

后台 agent 让你可以发出一个任务，等它完成后再回来。审查 pull request——代码、截图、演示视频——然后直接在评论里留下后续指令。这就像和一位工程师同事一起工作。

最大的影响在尾部

Agentic 开发改变了构建软件的经济学。

我们构建的软件比以往任何时候都多，但我怀疑我们达成的公司顶层优先目标并不比没有 AI 时更多。功能更完整、更精致，因为我们有更多带宽可以投入，但科技是一场红皇后竞赛，我们的目标线也在移动。2026 年算作 MVP 的东西，在 2020 年会是一个有 6 个月路线图的精致高产能功能。

最大的影响在尾部，那些几年前没人会优先处理的 bug 和功能。

作为一个工程组织，我们的主要目标有两个：

1. 构建产品
2. 让业务运营更高效

产品是我们卖的东西，运营效率是我们在超高速增长中生存下来的方式。没有这一点，你就会在经营业务而不是构建软件中溺水，因为 bug 和支持响应缓慢而落下不靠谱的名声，客户就不再来了。

更新一个东西要点 10 次，一周一次还行，但一天 50 次就要命了。百万分之一的 bug 在你只有 5 个客户时没事，但当你每秒服务 50 个请求时就要命了。

在运营上变得更高效，大多看起来像是边缘处的无聊工作。你必须无情地消除系统中的摩擦。

你希望每个工程师都改进运营业务的流程。为此，我喜欢鼓励挫败感驱动的开发。

厌倦了在数据库里管理功能开关？让 agent 给你建一个控制面板。厌倦了通过笨拙的菜单导航内部工具？告诉 agent 建一个 Cmd+K 快速搜索功能。厌倦了管理员工角色和权限？@cursor make me a tool。烦透了“你能帮我快速拉一下这个数据吗？”——永远别让业务用户知道你会 sql 哈哈——建一个快速仪表盘。

每当你反复回答一个问题或执行一项任务时，都可以用一个简短的提示把自己从流程中自动化出去。有了后台代理，你甚至不需要从主任务中分心，所以也无需请求许可。

你觉得我们需要一个能让你的生活更轻松的工具？那就做出来。看到利益相关者在一些扯淡的事情上浪费时间？解决它。

只要你能描述问题，就能让代理开始工作。要求提供功能运行时的截图和视频，这样审查起来就快。先发布，之后再问问题。对于像这样自包含的功能，代码质量可以先放一放。

通过观察利益相关者的工作，我们发现了许多快速修复的机会。我们修复的摩擦越多，来找我们解决问题的人就越多。你永远不希望用户变得自满、认命于苦差事——好的工作软件感觉是无形的，不会碍事。

开始变得容易了，但完成仍然很难

你能让代理在后台处理任何事情，其另一面是，进行中的工作仍然会扼杀你的进展。你心里装的事情越多，你在任何单个任务上取得的进展就越少。

而且它还会悄悄找上你！

你带着一个目标开始新的一天。然后有人在 Slack 上 ping 你，提了个小请求。嗯，听起来很简单，@cursor make it so。接着一个用户报告了一个小 bug。当然，快速又简单，@cursor fix this。然后你有一个 2 小时的会议时段，心想不如让 Claude 放手处理我今天本来打算做的两个大任务。在与利益相关者交谈时，你冒出一个想法，能让那些会议中的所有事情都变得容易得多，甚至变得不必要——我喜欢从业务流程中删掉愚蠢的步骤——于是你快速敲出 300 字的提示，描述背景、想法和一个粗略的实现计划，不知怎么这就花了 20 分钟。

现在下午 3 点了，你有 6 个草稿状态的拉取请求开着。你看了看那些快速修复，合并了一个，然后意识到 Cursor 完全误解了另一个。再试一次。你让 Claude 在后台处理的大任务看起来“几乎还能抢救一下”。

你已经走到这一步，不甘心放弃，于是又发出几个提示。修复你忘了指定的行为，改进代码结构使其合理，提醒 Claude 你不需要测试来验证从未合并的行为已被移除，最终测试该功能。

用 Knuth 的话说，“当心上面代码中的 bug；我只证明了它是正确的，并没有试过它”。我不信任没有亲眼看到运行过的代码。

即使代理生成了截图和演示视频，你至少也得做一次正常路径的冒烟测试。这是发现小 UX 摩擦并在发布前修复的好方法。

一天结束了，你做了很多工作，但只发布了一个小 bug 修复。你的主要优先事项几乎没动。

当软件生成变得廉价时，你可以做任何事情，而且一切都感觉值得投入。这就是陷阱。你必须无情地专注于你的主要优先事项，对其他一切说“还不是时候”。给自己一个小额的每日预算用于临时修复，把其他所有事情都扔进分诊。

我们每个冲刺优先处理的工作中有一半来自分诊。我要求我的工程师们留意，因为我无法出现在每个场合。

但如果只是快速的文案或颜色更改，请不要花 20 分钟权衡优先级。

代码审查是资深人才最高杠杆的工作

没人在乎你产出代码的速度有多快、数量有多大。你交付到生产环境、用户能看到的是什么？用户今天能做什么昨天做不到的事？

但你不能交付垃圾。

现代 DevOps 让交付变得快捷——你点一下按钮，机器人就替你干活。智能体编程让产出代码变得容易——你描述问题然后等待。

审查如今成了瓶颈，而且比以往任何时候都更重要。我说的不只是代码审查，还包括确保功能达成目标、彼此良好协作，以及你的产品看起来不像是被一群嗑了药的浣熊拼凑出来的。

产品债

当每个人都能交付任何想法时，产品债就是一个巨大的危险。

每个用户都觉得，如果去掉那些碍事的无用功能，你的应用会好得多。只不过没有两个用户对哪些功能无用达成一致。🫠

在 Plasmidsaurus，我们有很多加载缓慢、功能臃肿的巨型页面。每次我们想隐藏一个表格列或移动一个组件，就会有一群愤怒的利益相关者冒出来，说那些是他们每天最关注的像素。

而在我们这种高自主性文化下，每个功能和界面都各不相同——极度专注于解决当前问题。每个工程师各自与用户合作，为他们特定的功能打造出色、或至少够用的用户体验，却忘了考虑整体。这样重复几次，用户就会抱怨你的软件看起来很笨重，但又说不清为什么。

这是因为每个功能都像是一条新的学习曲线。这也会让用户害怕尝试你构建的新改进工作流。最好还是用他们知道管用的老方法。

而现在你得维护所有这些累赘。

一年里每周交付一个功能，你就有 52 个生产功能要维持运行。如果每个功能明天有 0.5% 的概率出 bug，而定位并修复需要 3 小时，那你每周就要花将近一整天修 bug。现实中你会任由它们溃烂，直到变成大问题。

你可以用产品审查来对抗这一点。

端到端地审查用户体验，砍掉不起作用的功能，构建设计系统和组件库。工程师和智能体不应该为每个新功能都从第一性原理重新发明基本交互。

代码质量就是金钱

起初，架构会拖慢你的速度。 随着你成长，缺乏架构会拖慢你的速度

加入智能体就像把你的工程组织扩大 10 倍。它们会放大你现有的代码质量。

构建一个巨大的泥球，智能体会乐于继续在泥潭里打滚。创建一个结构化的系统，做到关注点分离、模块之间有清晰的契约，智能体就会遵循这个模式。

但在我职业生涯中第一次，我们可以给糟糕代码的取舍标上明确的金钱成本！在一项实验中，更好的文件结构让一个编码任务的token 成本降低了 83%。

你的智能体为做出改动而需要读取和触碰的代码越少，它们消耗的 token 就越少。你的代码结构越易于导航，智能体就能越快到达需要的地方。对人类友好的东西对 LLM 也友好！

听起来显而易见，但这意味着在一家氛围编程的公司里，总得有人去看代码并强制执行质量。

这意味着垂直的、面向领域的模块，清晰的契约，良好的抽象，以及协同工作的就近放置的代码。如果你在打造自己的简历，可以称之为上下文工程。

根据我的经验，智能体在这方面表现很差。

正如 David K Piano 曾说过的——“AI 并不是在优秀代码上训练的，而是在你的代码上训练的”。Claude 喜欢横向切片、写千层饼代码，Codex 写的代码过于聪明，而 Cursor 每天都有不同的怪癖。

你最好的办法是让智能体遵循已有的模式。

审查代码，构建系统

资深及以上工程师的工作越来越是构建生成软件的系统。不是“软件工厂”，而是一个人类与智能体可以协同工作的社会技术系统。

你必须阅读他人产出的代码。

几个月来，我平均每周要做 40 到 50 次代码审查。我 GitHub 贡献的一半都是代码审查，甚至我自己写的代码也主要是在审查智能体的代码。是的，这很累人。

而这是我能找到的最高杠杆的活动。原因如下。

智能体代码审查缺乏判断力

我们尝试过智能体代码审查，结果……还行。你会得到很多文字和不错的提示，但你必须审查这份审查。BugBot 提出的评论有一半被我们以无关或尚不重要为由驳回。自己构建的甚至更糟。

你需要人类判断力以及当前项目上下文。你会押上整个公司去做的核心产品功能所需的代码质量，与 5 个人每月用一次的临时内部功能所需的代码质量并不相同。审查机器人不理解这一点。

审查机器人也不理解你的业务上下文和期望的架构。它们最多只能引导你走向通用模式和“最佳实践”。

而且智能体不会发现你架构中有问题的模式和期望路径。智能体就像一个拥有无限毅力的勤奋工人。让它们用叉子去挖穿一堵混凝土墙，它们也会完成。

你必须观察它们工作，并注意到哪里别扭。

把人工审查转化为规则

一旦你发现了别扭的模式，智能体编程就成了你的架构超能力。因为智能体会阅读你写的指导！每一次都是 😍

扮演架构师的问题一直在于，没人有时间阅读文档或遵循 SOP。你可以费很大力气传播好的理念，但大多数架构师都会精疲力竭。

当所有人都使用智能体时，你更新一个 .md 文件，此后每个拉取请求都会遵循新模式。这非常棒，但也危险。

与人类不同，智能体不理解你规则的精神。告诉它们测试解析器价值很高，它们就会为每个 Zod schema 编写单元测试。我们不需要测试一个 JSON 转对象的库能否工作。

长期以来，我一直怀疑维护复杂的 .md 文件来指导智能体——直接跟它说就行了！——但我现在被说服了。你不是为智能体写这些文件，而是为那些不知道该要求什么的经验较少的工程师写的。现在这自动且默认地发生了 💪

阅读所有人代码的另一个高价值成果，是顺应你的挫败感，构建确定性 linter，对你反复写下的评论发出警告和错误。自定义 linter 值得编写，因为软件构建变得便宜了。

用平实的英语描述一个模式，然后看着你的智能体写出 700 行 AST 解析魔法，在毫秒内捕获该模式。然后把它加入你的 CI 和提交钩子。

我们在整个技术栈中运行着几十个自定义 linter，效果非常好。所有检查都变绿之前，人类无法合并，智能体甚至在提交代码之前就会运行这些检查。

每次你厌倦了写新的反馈，就添加一条新规则（给智能体展示具体的 PR 示例，这样它就能写出好的 lint），渐渐地你的代码审查就变成了橡皮图章。等同事来看的时候，你的 linter 和 .md 规则已经修复了所有值得说的问题。

这时候你就可以安全地添加自动批准+合并的自动化了。如果低风险代码通过了你的所有规则，为什么还要看它呢？

把英语翻译成代码的初级工程师不存在了，能拼凑成全栈团队的技术专家也消失了。

我们期望每个人都与客户和利益相关者沟通，理解自己工作的影响，从概念到生产全程负责功能，并迭代改进系统。你的目标是关心、负责，让用户满意。

实际上我们都像 staff+ 工程师一样工作。新手负责拥有少数利益相关者的小领域，老手负责拥有大量相互竞争的优先级和触及一切的横切关注点的关键领域。这比敲 Jira 工单有趣多了。

当代码变得廉价，判断力就成了工作。

Cheers,
~Swizec

Filed under: 软件工程团队协作管理生产力AI

用我的书深入探索