T3 Code 的 Orchestrator V2 最近上线并进入稳定版——这套做了大约半年的多模型、多 Harness 编排能力终于跑顺了。从一个早期体验欠佳的开源替代品，到如今用户数超过 70 万，它在已经成熟的编程 Agent 工具赛道里跑成了黑马。
为什么值得关注？因为它始终在深耕编程这件事，尤其在别家都往另一个方向走的时候。 ChatGPT 恨不得把 Dots、Spaces 和插件全塞到你眼前，Claude Code 在往通用办公方向扩。T3 Code 的核心就是编程，它是工程师为工程师做的工具。
兼容性上，T3 Code 把你在用的模型、Harness 和订阅接到了一起。它一直支持 Claude Code 和 Codex，最近又把几乎所有其他选项都补上了——Codex、Claude、Cursor、Grok、OpenCode、Antigravity、Muse Code 和 Pi 都是直接内置的。想用其他兼容 ACP 的 Harness，也接入了整个 ACP Registry，Amp、Cline、Copilot 等都可以从里面添加，还可以手动配置。你想用的工具基本都能接进来。
远程环境管理是它明显领先的地方。可以在一个远程环境里启动任务，再让子 Agent 到另一个已连接的远程环境里执行子任务——至少在一些其他头部模型厂商的桌面应用里，还没见到这种支持。如果高度依赖远程环境，T3 Code 是目前用过最好的工具；如果工作流高度依赖多个 Agent，比如指定一个模型做调研、另一个实现、再一个审查代码，它同样是最好的方案。架构上，所有操作都走自己的 WebSocket 服务器，而不是直接往终端发命令或靠奇怪的 Electron 调用建立连接。
一个同时订阅 Codex、Claude、Cursor 甚至 Antigravity、写代码量极大的深度用户，给出的判断是：T3 Code 尤其适合同时用多个模型的人。单从写代码的角度看，Codex 或 Claude 这类头部模型厂商的桌面应用能提供的功能，T3 Code 基本也都有，使用体验和实际表现都达到了原厂桌面编程应用的水平。
而做出这个开源项目的，是三个兼职的人，对面则是市值过万亿美元、拥有成千上万名工程师的公司。项目已有 987 位贡献者、5.44 万 GitHub Star、1.02 万 Fork，采用 MIT 协议；它本身不靠卖 AI 服务赚钱，模型订阅要用户自己准备，但运营这个开源项目其实挺贵。
截图来源：https://github.com/pingdotgg/t3code
这期播客里，T3 Code 作者 Theo Browne 和主持人 Joel Hooks 从头聊了 T3 Code 为什么存在、它到底解决了什么，以及当 agent 真正承担工作时，类型安全、测试、CI 和预览环境为什么反而更值钱了。
本文基于该播客视频整理，经 InfoQ 编辑。
太长不看版
Q：T3 Code 是什么？是给普通开发者用的吗？
A： 一个开源的 agent 编程界面，把 Codex、Claude Code、Cursor 等 Harness 统一包起来。终端里跑一个 websocket 服务，桌面端、网页、手机都能远程连接，甚至能在一台电脑上操作另一台上的线程。
但它不是给普通开发者用的。我做内容、做工具本来就不是给普通开发者准备的，我想服务的是资深工程师的安全区：大公司里周围没人在意的资深工程师，或者学校里已经远超同伴、甚至超过老师的年轻开发者。他们想深入、想痴迷，但身边没有同类，而我不会为了扩大受众降低门槛。
Q：Plan Mode 真的死了吗？大家现在怎么规划？
A： 不是被抛弃，是被吸收进模型本身了。计划模式当年存在的理由是模型太笨、需要靠“限制能力 + 改写系统提示词”来约束它别乱改，而现在模型聪明到不会在你们还没聊完时就抢先动手。大家用“拷问（grill me）”式的追问，本质上就是在做计划。
Q：skills 还有未来吗？
A： 有，但形态会变。可复用流程有价值，团队把规则写进共享 Markdown 很合理，但它依赖 AGENTS.md 等其他文件，两个人跑同一个 skill 也可能因全局文件或模型不同而行为不同。以后这些流程可能变成云端服务：团队任何人点一下，就在不干扰本机 agent 上下文的情况下拿到报告。
Q：为什么你坚决劝人别做独立创始人？
A： 极少数成功，几乎所有人都变得非常抑郁。我只当了约三个月独立创始人，回想那段窗口期还会觉得有压力。
Q：大多数人用 AI 的方式错在哪？
A： 他们不是在用 AI 自动化自己理解的东西，而是在用 AI 逃避建立那份理解。正确路径是先在某件事上变得足够好，知道它怎么成功、怎么失败，再带着这份标准把 AI 引进来。把在意用在刀刃上：自动化掉你所热爱之事里那些你不喜欢的部分。
Joel：你玩了一辈子滑板，这段经历怎么让你得了“AI 精神病”？
Theo： 最表层的一点，是习惯说别人听不懂的话。有次我坐 Uber，跟一群滑板朋友从一个滑板场去另一个活动，我坐在后排，车上大多是玩滑板的女生。她们聊占星，我一句都听不懂。那一刻我意识到，这就是非滑板人听我聊滑板的感受，是非工程师听我聊工程的感受，也是不在旧金山的人听我聊 AI 的感受。
Joel： 行话是必要的恶，本质是压缩。你专精一个领域久了，就必须有一套自己的语言，对一种文化做压缩。
Theo： 如果旧词足够描述新东西，说明它不够新，新东西值得新词。
说回滑板，这个领域还给了我一个衡量模型能力的指标——Skatebench。多数前沿模型在 82% 到 88% 之间，只有一个到了 95。你能猜到是哪个模型吗？
Joel：Kimi？
Theo：Gemini 3.1 Pro。先快速说说 Skatebench 是什么：它是一个测试，我通过物理特征描述一个滑板动作，板往哪走、人往哪走、绕哪个轴转、转多少度，把正在发生的事完整描述出来。你不可能每次命名动作都把每个变量说一遍，所以滑板有自己的语言：kickflip、heelflip、tre flip、backside 360 kickflip……这些词都是动作流行之后才被发明出来的，但语法深深嵌在滑板里。真正有意思的是，模型既要能推理三维动作，也要懂这套语法，才能把术语正确组合和化简。我觉得 Google 在这里有很大优势：3D 推理高于平均，多语言和本地化能力又强，Fable 这类模型在同一榜单上只有 70 多到 80 出头。
Joel：新模型出来，你怎么测？
Theo： 要看模型定位。像 ox alpha 在 OpenRouter 上 stealth launch 的那一次，产品说明写得很清楚：只做编程和 agent 任务。对这种模型，我不太会把它交给 Skatebench。真要用，目的也是测代码能力，比如让它把自己加进 Skatebench，看它能不能在代码库里找到路径，处理这种相对完整的任务。
更常见的做法是：把它直接放进日常工作流。先在 Harness 里把它配好，再让它去别的 Harness 里配置自己。让它用现有工具分析我的代码库，然后追问它为什么选这个工具、为什么引入这个 skill、怎么看这个代码库的架构、有没有拿到做改动所需的条件。这一轮下来，既能看出它如何理解自己的能力和边界，也能反过来得到关于我自己系统设置的反馈。
接着让它承担真实工作，难度逐步提高：先从“修这个区域的 bug”开始，一直到“我有这个六年没迁移、没更新的应用，把它在另一套完全不同的技术栈上重建一遍”。
Joel： 这听起来像招人，或者合同工转正。
Theo： 更像一场理想中的面试。理想情况下，每面完一个候选人，团队都应该交流一次：这个人走到哪一步了，接下来该往哪个方向问。我犯过几次错：有人按薪资区间投岗，而不是按岗位实际级别投。曾经有一位非常资深的工程师投了一个初级岗，结果整场面试表现远低于她的真实水平，因为那就是一套初级岗的面试。理想的做法是，一旦发现能力超预期，就把面试轨道往上调。
对模型也是同一个思路：我能信任它有多资深，它能走多远，需要给它多长的绳子，给了绳子之后还能信任多少。
Joel：你一直强调拥有自己的技术栈，没有这种心态的开发者会失去什么？
Theo： 我一贯的看法是，你很难真正控制和高效使用自己不理解的东西。我一直以来的做事方式是：我喜欢折腾，不只是想看一个东西内部怎么运作，也想看做出这个东西的人怎么工作。我会深挖这个人或这个团队：是什么让他们做出它，什么启发了他们，什么问题把他们逼到非做不可，他们接下来要往哪走。因为如果我和做东西的人不对齐，长期也不可能和这个东西本身保持对齐。
对冲这件事最好的办法，是选择开源的东西。不只是因为免费或者可以自由使用，而是因为开源本身允许你折腾、贡献和理解。不开源的软件，从根上就更不可能和我的利益一致。哪怕我一行代码都不贡献、一眼源码都不看，只要它不开源，创造者和我在某些需求上分道扬镳的概率就明显更高；如果它开源而分歧还是发生了，至少我还能把方向纠正回来。
我刚写软件的时候，最流行的编辑器是 Dreamweaver，最流行的技术栈是 .NET，都很封闭。后来 LAMP 生态起来，再往后是 Electron、Atom 之后的 VS Code，我发现自己可以完全定制编辑器，可以定制部署的服务器，也可以定制框架和库，甚至能顺便感谢做新功能的人。真正让我兴奋的不是控制本身，而是“我能控制”这件事，以及有人愿意把它做成可被控制的样子。
T3 stack 就是把这套逻辑落地的结果：把一组我信任的开源小工具按 Unix 风格组装起来，不是把每个工具都改到完美，而是让它们组合成一个能解决真实问题的整体。
现在这套思路又原样交给了 agent。我花了多年时间让全栈 TypeScript 应用在两端互相感知：改一个数据库字段名，消费这份数据的客户端组件立刻报错，整条链路类型安全。现在 agent 从终端获得反馈，而终端背后正是我维护了多年的这套系统。
Joel： 但大多数开发者没有这么强的热情。你做的 T3 stack、T3 Code，某种程度上就是替他们把这些挖好了，T3 Code 本身也像一组工具组成的 stack。
Theo： 我做的内容本来就不是给普通开发者的。最初做频道，是因为我怀念在 Twitch 和一群极客同事聊 Svelte 3、聊 Rich Harris 在做什么、聊 Apollo 3 终于转向 hooks 的日子。COVID 之后，和团队吃饭的机会没了，这种交流也断了。我很快让室友 Mark 不堪其扰，因为我不停地跟他讲这些东西。后来去 Twitter Spaces 找人聊，当时只有 30 个粉丝。又给做有趣产品的人发私信，感谢他们，顺便给博客提反馈。再后来开始直播，并把录像传到 YouTube，因为 Twitch 的回放体验太差。
结果远超预期。我以为最多 1 万订阅，每条视频一两千播放；实际是每条 10 万到 30 万播放，订阅早就过了 50 万。我低估了优秀开发者的数量，这一切快得有点不真实。我想要的不是给普通同事科普“下个项目该选哪个框架”，而是深聊 React 为什么转向 Server Components 这种细节。频道慢慢成了这类人的安全区：在大公司里周围没人同样在意的资深工程师，或者在学校里已经远超同伴、甚至超过老师的年轻开发者。他们想深入，想痴迷，但身边没有同类。
评论区当然也有人抱怨：每两周一个新模型，改一个配置字符串就得重学一遍。说实话，我不太在意这类人。他们人数够多，也在帮忙养活我们做的事。但我在乎的是那种想学、想成长、想聊到伴侣都觉得烦的工程师，我不会为了让更多人进来而降低门槛。
还有些人身处偏远地区，高中时只跟一个过气的、只会 COBOL 和 Java 基础的老程序员学过编程，身边根本没有人能点燃那把火。频道想做的，就是给这些人一个火堆。
Joel： 这有点像 AI 之前那个“每周一个新框架”的抱怨。很多人把自己的偏好当成好坏：我不喜欢，所以它不好。其实你可以降低门槛、扩大受众，也许收入更高，但你自己不会享受。
Theo： 坦白来说，即使浏览量少十倍，我也还是能赚不少。但我留在这里，是因为我的受众独特而有价值。我的受众很特别：一边是微软的 VP，他们说得多了、写得少了，需要知道 AI 领域在发生什么；另一边是 17 岁的开发者，虽然同龄人都不在意，他也为了热爱继续写。
品牌想同时触达这两种人：年轻开发者先接受一项技术，两年后带着它进公司，而公司里签字的 VP 或高管又恰好听过同一套内容。两端一夹，品牌愿意付更高的价格。如果我为了扩大受众去做自己不想做的事，每个观众的价值反而会被稀释。所以我不必把内容做笨，也能养活团队，这相当于十倍的受众。
Joel：T3 Code 为什么存在？它到底是什么？
Theo： 没有东西是必须存在的，我们完全可以关掉电脑去森林里待着。但 T3 Code 的出现有一组很具体的原因，理解了这组原因，也就理解了它是什么。
起点是 Julius（T3 Code 的主要工程师）和我都很喜欢 Codex 桌面应用，我们很早就拿到了访问权限。Julius 是我认识的最厉害的开发者，但他偏偏不是终端派。一般人只要有他三分之一的水平，职业生涯基本都围绕终端展开。他写的代码比谁都多，却至少有一半是通过 VS Code 里的 git 面板完成的，连 git 都不肯用命令行。我一开始很不理解，但也很感兴趣，因为我喜欢看高产的开发者用和我不同的工作流。他是 GUI 派，我是 TUI 派。我在终端里用 Claude Code 和 Codex 用得很顺时，他还在找怎么把同样的能力放进图形界面。
Codex 应用发布后，我们都试了。我很喜欢，他更喜欢。但我们俩对性能回退和结构变化都很敏感：一旦进入心流，原本在某个位置的东西突然被挪走，就会非常烦躁。Codex 的 CLI 和 AppServer 都开源，桌面应用却不开源，所以它出现我们不喜欢的变化时，我们什么也做不了。
我想解决这个问题，先做了一个原生桌面应用，希望把 agent 编程的性能做到极致，结果没有达到预期，反复折腾之后只能放弃。接着我把市面上所有 Harness 管理工具都逐一试用了一遍：cmux 我至今每天都在使用，它用侧边栏和标签页管理终端；Conductor 是闭源的桌面应用，用来管理本机的 Claude Code 和 Codex。但它们要么不够优雅，要么不能自由修改。
最后我勉强再试一次，这次用 Electron 重做。我知道一提到 Electron 就会引来大量批评，但它在长文本、滚动、代码、图表和图片的动态渲染上性能合适，而 Google 在 Chromium 生态上投入的数十亿美元，让跨平台体验有了一个很好的起点。
T3 Code 是一个包住 Codex、Claude Code、Grok Build、Cursor、OpenCode 的 GUI，但它不只是一台机器上的应用。我们的架构是：终端里跑一个 websocket 服务器，绑定本机的各种 Harness，桌面端、app.t3.codes 网页端、iOS 和 Android 手机端都能连进来。React Native 版本已经开源上架，SwiftUI 重写版在 TestFlight，也开源。我把自己所有电脑都放进 Tailscale 网络，可以从一台机器连另一台上的线程。比如，我手边这台笔记本上运行着一批线程，但没有一个跑在这台机器上，合上盖子再打开，它们还在，因为工作都在另一台算力很强的机器上。
这样做解决的是几个具体的恐惧：不用再担心每开一个线程电脑就变得更热、应用变得更慢，不用怕 Codex 在一段重要工作快结束时崩溃，也不会面对第二天打开时一批项目和线程不知道先看哪个。所有设计都围绕一件事：有想法时快速起一个线程，完成后快速合并。比如，侧边栏做成收件箱样式，优先显示没完成的工作，而不是最近碰过的工作。
它还解开了开发者和某一家实验室工具的绑定，以前想用 Anthropic 模型，就得用 Anthropic 的 Harness，因为 200 美元套餐里有 8000 美元的推理量，换成 Cursor 或 Copilot 不划算。而 T3 Code 直接控制你电脑上已经登录的 Claude，界面开源、MIT 协议，可以自由 fork。相当一部分用户跑的是自己 fork 的版本，贡献者也很多。有大牌产品克隆或 fork 了 T3 Code，也有人因为每天用这个工具，第一次给开源项目提交代码：他们会问它关于自己的问题，读它自己的源码，然后动手改。我们甚至加了 npx t3 triage，T3 Code 启动不了时也能把上下文交给 Claude 或 Codex 排查。
如果我和 Julius 哪天走向大家不喜欢的方向，用户也可以 fork 出去，保持自己喜欢的样子。这个时代信任越来越少，你能信任的，只有自己能改的代码。
Joel： 周末我在高速上开着全自动驾驶，用特斯拉浏览器打开 T3 Code，点连接，家里书桌上的电脑就出现了。我接着原来的会话，走 Starlink，穿过林区时信号时断时续，线程掉了又回来。我并没有全神贯注地想完成任务，只是觉得这件事很好玩，虽然也有点吓人。
Theo： 所以开源也危险，界面能让人在开车时用。
Joel： 这跟开源无关，就是现有能力。我以前用 SSH 和手机终端连电脑，能用，但配置麻烦，也不是谁都会。而 T3 Code 把门槛降下来了。
Theo：T3 Code 最酷的用法不是下载桌面端。我现在大多数电脑上都不跑应用了，而是在 Mac 和 Linux 上运行 npx t3 connect，它会给你登录 URL，确认后装一个登录即启动的服务，这台电脑就能被远程使用，不用装别的。
Joel：能看到 Plan Mode 断崖式下跌，大家现在怎么计划？
Theo： 我想了很多关于 iOS 6 的事。iOS 6 之前是拟物化时代，苹果要把界面做得像实物：Calendar 像纸质日历，Books 像木书架，Compass 像桌上的实物，Calculator 的按钮排列和屏幕样子也照着实体计算器来做，尽管触摸屏上根本没有真正的按钮。因为用户不信任手机能替代这些东西，苹果也不知道怎么设计得更好。后来用户习惯了，很多人根本没拥有过实体日历和指南针，苹果就转向 iOS 7 的扁平设计，为“怎样最好用”设计，而不是为“人们熟悉什么”设计。
这次转向当时遭到很多反对，有人至今认为方向错了。但它让软件先变简单，再变得更有能力：如果每增加一个功能，都要在界面上放一个对应的物理开关或旋钮，软件就做不大，也做不深。
我认为 AI 工具还在拟物化阶段：假装 Git 的三十年用法很重要，终端必不可少，不看每一行代码就不算真开发者，这些是对旧方式的依恋。模型变好之后，就有了改变的空间。
plan mode 一方面映射了“先计划再执行”的旧习惯，另一方面是当时模型不够好，需要靠模式限制能力、改系统提示词，只让它读文件、帮用户理结构。现在模型聪明了，不需要这些限制。
Joel： 大家用“grill me”式追问，本质上还是计划，只是模型不会在聊完前抢先动手。
Theo： 过去是功能、甚至整个产品的东西，现在可以只是一个提示词或 Markdown 文件。过去有人搭建复杂的软件工厂，二十种 sub-agent 分管任务、互相审查、套大循环和测试；现在直接让 Codex 或 Claude Code 拆任务、审查、用 browser use 测试，无需改动现有工具，也能得到几乎相同的功能。我认为这就是我们要去的方向，既因为模型变得足够聪明能处理这些，也因为工具越来越能支持这些动态流程，还因为人们越来越接受这就是 agent 现在能做到的。
我不写自定义 sub-agent。唯一例外是 Claude Code 的一个 bug：我的版本只让 sub-agent 调 Opus 4.8，不让调 Opus 5，所以我创建了 system prompt 为空的 Opus 5 和 GPT 5.6 sol，让顶层 agent 还能操控。其他时候我只说需求，信任模型，前提是项目里有它需要的工具。
Joel：那 skills 还有未来吗？
Theo： 有，但形态会变。可复用流程本身有价值，因为模型对措辞敏感。团队想保证行为一致，把规则写进共享 Markdown 很合理。问题是它依赖你其他的 Markdown，比如 AGENTS.md。两个人跑同一个 skill，也可能因为全局文件或模型不同而行为明显不同。我写“得到确认前把问题当只读”，对 Claude 系列必要，对 Codex 或开放权重模型就会带来麻烦：问它 PR 评论值不值得处理，它回答值得，却不采取行动；让它修改，它会修改，但不会 push。我用 ox alpha 时，尽管模型很棒，我不得不连着说了三次：“没问题，去做吧”。我认为以后这些流程可能变成云端服务：团队任何人点一下，就在不干扰本机 agent 上下文的情况下拿到报告。
Joel：类型安全、lint、自动化测试、CI/CD，过去用来防止我们自己和同事犯错。现在，我越来越依赖这些机制，因为我想给 Agent 更多自主权。什么时候这些检查只是自我安慰、做做样子？什么时候真有用，甚至值得再往深处做一层？
Theo： 自动挡也有齿轮，只是你看不见。齿轮让发动机更高效，防止熄火。即使驾驶员用不着操心怎么换挡，齿轮依然能让发动机设计得更高效。类型安全也是这样，它让 Agent 更有把握地改代码。凡是让 Agent 更难工作、更难有把握地做出改动的东西，恐怕都很难长期存在。我觉得你提到的这些工具不属于那一类。
有了全栈类型安全，每改一行代码，你用不着把整个系统重新验证一遍。你可以更有把握地改动、更早发现问题，也省得把不能正常工作的东西交给同事和用户，浪费他们的时间。无论 AI 变得多聪明，都会从中受益，尤其是在上下文窗口没有大幅增长的情况下。我经常在多个项目之间切换，记不住这个函数接收的是对象、字符串还是数字，还是这几种类型的组合，参数按什么顺序排列，也记不住它返回的是被修改过的对象、只读值、裸字符串，还是一个错误类型。没有类型系统，我就得记住这些细节，或者到处反复核对。上下文总得有个地方存。如果全靠脑子记，忘了就等于丢了，事情很快就会乱套。
Agent 也一样。每开一个新会话，它都得重新建立这些知识。它只知道会话历史里有的东西，对你的代码库没有先验了解。你可以在 AGENTS.md 或 CLAUDE.md 里给它一些提示，但上下文窗口再大，也装不下大多数代码库。要让 Agent 有把握地修改系统，更重要的是看它只掌握部分信息时，能安全地做多少改动。在大公司或大型代码库里，没有人真正知道整个代码库怎么运作，理想状态下，你也不需要知道。类型系统提供的正是这一点，让你有信心地做改动。
Joel：我们过去为软件建立的最佳实践、设计模式和各种保护机制，仍然很有价值。它们给我们提供了上下文，让我们在不同项目之间切换时，用不着把所有细节都记在脑子里。Agent 也能从同样的机制中获益。
Theo：Agent 就像一位天赋惊人的工程师，却困在最糟糕的《土拨鼠之日》里。每次你交给他一个任务，他的大脑就会重置，忘掉此前学到的一切。想象一下，这位工程师是你团队的员工，却连自己已经入职都不知道。你会给他写一封怎样的信，让他每天醒来扫一眼，就能跟上目前的情况？某种程度上，`CLAUDE.md` 就应该起到这个作用。
他已经精通工程，也完全能在你的代码库里找到需要的东西。他缺的是最基本的信息：从哪里开始、你是谁、他的工作是什么。用一封简短的信把他的角色和职责交代清楚，就能帮他更快上手。毕竟，他每天都是第一天上班。
说到验证系统，我觉得眼下最被低估的做法之一，是用 Agent 执行那些难以写成程序化规则的检查。Macroscope 是我最喜欢的 AI 代码审查平台之一，我们已经用它加入了越来越多这样的检查。我们在 Macroscope 里建目录，定义通过和失败标准，CI 时启动审查 agent。其中一项检查 Effect 最佳实践，确保每次代码提交和新开的 PR 都遵循我们看重的 Effect 编码约定。另一项用来防止代码偏离设计系统，造成 UI 回归。我们把代码库里已有的设计系统组件做成了一份简明索引，也列出过去 PR 里出现过的问题。比如，有人在某个组件里自己实现了一个 tooltip，没用我们已经提供的那个。能写成 lint 的早就写了，仍然有遗漏。
用自然语言写下这些要求，就像我在交代公司里的每一位员工，审查每个 PR 时要逐项核对什么。拿飞行来打比方，飞机遇到状况时，飞行员会照着清单逐项检查。我们的清单在每个 PR 提交时触发。Agent 能读懂我用普通英语写的要求。它当然做不到完美，但往往能在人工介入前发现潜在的回归。
这让我想起第一次用 TypeScript 的感受。有多少错误能在轮到审查者或维护者处理之前就被发现？Lint 规则、TypeScript、端到端测试，都能帮我们提前拦下问题。现在，我们还可以用类似的方式，把团队对代码和设计的判断标准写进 Markdown，让 Agent 在给出通过或不通过的结论前逐项核对。等到需要人工审查时，我们已经更有把握确认这些要求得到了满足，团队也少了反复指出同样错误的负担。
Joel：类型检查和 lint 是按确定规则运行的关卡。现在，你还可以让模型运用判断和推理去检查另一类问题。能查到什么程度，取决于模型的能力，也取决于你愿意为这项检查花多少 Token。这样就多了一双眼睛，能发现原有规则难以覆盖的问题。
Theo：对我来说，观念上最大的变化之一，是意识到 Agent 给自然语言带来了什么。我经历过 Node 刚出现的时候。JavaScript 当时主要用来在浏览器里操作页面。突然之间，你可以下载、安装一个二进制程序，在终端里运行它，再把一个 JS 文件通过管道传给它。这门原本用来摆弄页面元素的语言，居然能直接在我的电脑上运行，用来控制机器、做实实在在的工作。那时我觉得很不可思议。
有了 Node，JavaScript 从一门用来修改网页的语言，变成了可以用来构建程序、应用、交互体验和服务的语言。Claude 和 Codex 给自然语言带来了类似的变化。就像把 JS 文件通过管道传给 Node 一样，你可以把 Markdown 文件通过管道传给 Claude，让它执行里面的指令。
我有个服务每天早上 10 点运行。cron 定时把一份 Markdown 指令交给 Agent，Agent 遍历我维护的各个项目里所有尚未关闭的 PR，再根据审查结果生成新的 HTML，直接覆盖原页面。这样，我每天开工时都能看到一份更新后的仪表盘。整个仪表盘就是一个 HTML 文件，省去了定制后端和专门的托管环境。
这太不可思议了。有些应用值得用 C 或 C++ 从头写。你不会用 Node 重写 ffmpeg，也不该用 Markdown 重写 web 服务器，但我以前很多维护起来很麻烦的零碎工具，现在就是一个 Markdown 文件，基本没什么要维护的。想做更多类似的事，也用不着每次都开发一个新工具。把想做的事写下来，挂到 cron 上，它就会按时执行。
Node 当年降低了很多软件的开发门槛。以前有些东西我觉得实现成本太高，根本不值得做，有了 Node 就容易多了。现在，这道门槛又降了一次。我想定期获取一些信息、管理收件箱，或者自动配置系统，都可以这样做。比如，理想情况下，我每天开工前，手头几台机器上的核心软件都已经更新到了最新版。这件事写点 Markdown，再配一个 cron 任务就能安排好。
Joel： Reese Solomon 最近发了条推文，说 AI 的乐趣之一是再也不用写 dashboard，我觉得挺好笑的。
Theo： 是的，现在我想把什么东西可视化，都能很容易地做到。这太棒了。
Joel：独立创始人的能力边界变了，他们低估了什么？
Theo： 我先说结论：别做独立创始人。极少数成功，几乎所有人最后都很抑郁。独自创业，孤独和疲惫是独一无二的折磨。我只做了约三个月独立创始人，回想起来还是有压力。有好的联合创始人，我才能走得更远、熬过艰难的部分。
Joel： 我完全同意。我自己也更愿意和人一起工作，那让我觉得有生命力，一个人闷头干反而受不了。换个问法：团队今天该怎么提升自己的能力？
Theo： 每个人都必须关心使用者。不是让后端工程师去认识头部 YouTuber，而是要知道自己在团队里的位置、谁消费你的工作、他们的需求是什么。后端要多和前端、应用团队待在一起，也要和平台团队保持同步。中间那部分，也就是你关闭的工单，越来越不是你的工作。只要 Jira 或 Linear 的工单足够详细，agent 就能完成。如果觉得不是，那是在骗自己。
你要为 agent 铺路。回想你最愉快的工作经历：谁给你的任务、怎么呈现、代码库里有什么让任务更容易完成、你带着什么上下文、对问题有多熟悉、有什么方法验证改动、第一次提交收到什么反馈、你怎么处理……这些对 agent 同样有效。你的工作不再是“上下文进去、代码出来”的黑箱，而是把箱子设置好，让它成功。
Joel：你最近传达了一个“更大格局思考”的想法，我想知道这如何与你刚才说的团队如何更多思考用户联系起来。当我们应该在我们创造的软件方面更大格局思考时，核心意味着什么？
Theo： 回想那个工作几乎自然流出的时刻：成功所需的一切都在，包括对问题和用户的认知、工具、验证系统的权限、好用的 dev server、能轻松拉起的 staging。把这些复制下来，编码进代码库。当你对“ PR 真的能上线”的信心从 40% 提高到 60%、70%、85%，交付能力会指数级放大。不是为一两个人或十个人铺路，而是能按工作量动态扩缩团队。
如果有 85% 的通过率，你就能拉起几百个 agent 清理 backlog，前提是系统能让它们验证工作。代码库不要要求全局设置、特定端口、只能跑一个桌面实例；要让 agent 能同时起五个浏览器版本对比，能访问 iOS 模拟器点按钮，有真实后端可跑。你的开发者评审、改代码、测试时最大的痛点是什么？消除这些摩擦。如果你还不能在改自己代码的同时，拉下同事的改动试跑而不弄坏本地环境，agent 也做不到。你自己能在一件事和另一件事之间切换而不丢线索，agent 才能从一个变成一百个。昨晚睡前我合并了 28 个 PR，因为系统已经验证过，到我手上状态很好。
我一直喜欢把代码库和系统搭成能同时推进很多件事的样子，同事可以随时拉下来改，然后有信心地发布。现在 agent 让我更有动力去打磨这些粗糙的边缘，我提过一个 3000 行的 PR，只为通过 Tailscale 暴露 T3 Code 的 dev server，方便远程测试。这种事以前只有 500 人团队才值得做：花一周让三个人的远程开发快 30%，不划算。但几百个 agent 的切换成本，一旦消灭，回报是指数级。
Joel： 这又回到使用者。人负责想需求、意图和结果，agent 负责规模。以前只有几千名开发者的 Google 能想这些问题，小团队想不了。
Theo： 大公司把“以前怎么做”编码进流程，不照做可能被开除。小团队的流程可以随技术变化，而技术变化比流程快得多，差距从没这么大。小团队只要把系统建好，就有机会胜出。判断标准是：有 95% 的把握绿色 PR 不会影响用户，再加上能轻松回滚的系统，你就可以闭眼合并。
Joel： 我在 Vercel 工作时见过这种内部系统，自己经营软件公司 15 年，一直没有时间和精力搭建，现在可以认真考虑了。
Theo： 这些年在意的细节，现在得到了空前的回报：TypeScript 的全栈类型安全，tRPC 对前后端关系的信心，还有我最喜欢的 Vercel 功能，preview deployment。关联仓库之后，每个 PR 都有和生产一致的无状态预览环境，点开即可启动，没人使用时零成本。以前我为预览环境搭过很多 CI 流水线，它变成核心产品功能后，我和队友发版都更有信心。我修改一点，他们点开确认，运行正常就合并。验证方案应该简单到只是看一眼方案，任何摩擦，比如等代码拉取、构建、关掉另一个 dev server，都会让我更不想验证，代码更不可能合并，或者合并了也不能跑。
Joel： 自动合并也是，给 agent 一个 Markdown 护栏，判断能不能合。以前躺几周的 PR，现在几分钟内就能合并。
Theo： 还能让 agent 翻 PR 历史和风险，告诉你合并前该测什么，就像一个聪明的同事先给一份简报。
你可以用 agent 自动化不喜欢的部分，但前提是足够了解它。你得对不喜欢的事有足够深的在意，才能找出所有边界情况，再交给 AI。多数人卡在这里：他们用 AI 逃避建立理解，而不是自动化已经理解的东西，这是给自己留下隐患。
先变好，知道它怎么成功、怎么失败，再带着标准把 AI 引进来。不要因为不想学前端、不喜欢 Kubernetes、不喜欢 code review，就整体交给 AI。先在意、先设置好，再引入 agent，成功率会高得多。我的建议是，自动化掉你热爱之事里那些你不喜欢的部分。
Joel： 把它当成开发者的竞争优势。越投入、越有热情，越能在行业现状里保持乐趣，也就能坚持越久。
访谈视频原链接：
https://www.youtube.com/watch?v=2iu5u3sUukc
参考链接：
https://www.youtube.com/watch?v=uLGxb4F3SyI
https://www.youtube.com/watch?v=atyZsZ4W9ag
声明：本文为 InfoQ 原创，不代表平台观点，也不构成投资建议，未经许可禁止转载。
