跨国深谈← 返回←「上下文工程」之父 Dex Horthy：智能体编程的真相与工作流

「上下文工程」之父 Dex Horthy：智能体编程的真相与工作流

关联

人物 Dex Horthy

公司 HumanLayer

概念 智能体 · 上下文工程 · Slop Code Bench · 暗工厂 · 代码审查 · 可维护性 · 子智能体

这一集聊的是：AI 智能体写代码，到底哪些是真的、哪些是 Instagram 式的假象。主角是 Dex Horthy，HumanLayer 的 CEO，也是「上下文工程」(context engineering)这个术语的创造者。

他一上来就火力全开：你在网上看到的关于智能体的内容大部分完全是假的——大家晒的是一周用光六个 Codex 订阅、堆了天量 token，但你问他发布了什么？「给自己做了一堆没人会玩的游戏。」

一个专门证明「模型让代码变糟」的基准

「模型让代码库随时间变糟」过去只是一种感觉，现在有了数据。Dex 发现了一个叫 Slop Code Bench 的基准测试，由威斯康星大学研究员 Gabe Orlansky 的实验室做的，专门证明模型会让代码库随时间推移越来越差。

它和之前三类基准都不同：SWE-bench 是给模型一个真实开源仓库的小 PR、让它把测试跑通；马拉松式基准是「从零重建整个 Excel/Redis」这种几百小时的任务；Cognition 则加入了裁判模型检查是否破坏代码惯例。但这些的共同点是——都把整个问题提前交给模型。

真实软件不是这样构建的。Slop Code Bench 是给模型一个从零构建的任务，然后说：好，现在在这个代码库上加这个功能，再加那个——每个挑战有三到十个检查点。结果显示，所有模型的失败测试数量都呈上升趋势，GPT 5.5 Codex 只拿了约 15%，而他们赞助实验室跑的新模型 Astra 也就 16.5%——维护复杂代码库的能力几乎没有进步。

Dex 的判断是：过去大家总说「代码潦草没关系，那是下一代模型的问题」，但现在已经到了新一代模型，可维护性并没有明显进展。实验室们更热衷于在计算机使用等其他前沿上爬坡，因为「软件可维护性最后那 10% 可能和过去三四年我们花功夫的前 90% 一样难，甚至更难」。

计划的价值：把返工从 75% 压到 10%

核心主张：你永远不可能一发命中(one-shot)。不存在「开五个小时的会做出完美计划、交给智能体就出完美结果」这回事——真相之源应该是代码，不是规格说明。

但规划的意义在于逐层消灭失败模式：从两万五千英尺的一页纸概览里，消除掉智能体可能犯的坏错误中约 50%；再放大到一万英尺，再消除掉另外 80% 的坏方案；这样代码出来时，返工量更可能是 0-10%,而不是大任务一发命中常见的 25%-75%。大公司三十多年来一直是这么干的：写 PR 的人先去找资深工程师对齐方案——只是现在这个对齐对象还包括智能体。

至于「计划」和「spec」的界线，Dex 认为不用纠结标准定义，每个团队会形成自己的品味。他们内部叫「设计文档」而不是计划，区分「我们要去哪、终局是什么」和「我们怎么到那、要做哪些改动」。

大企业的现实：被 slop PR 淹没

「黑暗工厂」(dark factory,即全自动无人工厂的编程模式)是高管圈的热词,但 Dex 说「全是炒作」「我觉得大部分都是 BS」。他讲了一个场景：和一家有数千工程师的老牌公司开会，一线 principal 工程师被 slop PR 淹没——很多来自不在乎或没有扎实工程背景的人。

部门负责人调出一个三万行代码的 PR:「看看这三万行垃圾。」而另一边,某些大公司高管宣称「我们组织 90% 的代码是 AI 写的」。

Dex 说这是顶级公司高管之间的姿态竞赛，每个人都焦虑「我是不是前 99 分位？我是不是被落下了？」

他借用 Andre Breslov 的说法：现在是「Instagram 阶段」——一切都是假的、都是花架子。你要说「对我来说不管用」，别人就说你是「技能不行」。

Dex 的 crusade 是：到底什么东西真正管用？从第一性原理建立理解，而不是从网上看到的东西往回推。

关于提速倍数，他的数字很冷静：每个工程师快 2 到 4 倍，对人类社会就已是变革性的，「但所有人都会错过这一点，因为他们太忙着追求 100 倍」。正确姿势是先想清楚怎么快 2-3 倍，再在此基础上叠加——渐进提速是指数复利的。把工程体系整个扔掉从零重建，行不通；这和 YAGNI(You ain’t gonna need it,你不会需要它)是同一个故事又讲了一遍。

为什么可维护性还是得靠人

看代码有两个原因：确认正确，确认可维护。截图和视频能验证前者，验证不了后者。

圈复杂度这类确定性工具能挡住一部分垃圾函数，但他的原话很硬：「我从来没有见过一个提示词或确定性工具，能在没有人类参与的情况下，以任何有意义的方式对抗模型写出不可维护代码的倾向。」

原因在于品味。有经验的工程师被烂架构咬过——凌晨三点修 bug 时发誓「再也不让任何人合并这种模式的代码」——五到十年里成百上千次，才积累出品味。

我们还没搞清楚怎么把这种品味放进模型里。有同行直接发帖恳求实验室的 RL 研究员：请在训练任务里加入「以删除代码为目标」或「把三个东西重构出好抽象」这类任务。

他的建议同样适用于此：不要抵押你的代码库，指望一年后会有一个聪明到能修复你所有问题的模型。

新人怎么长品味？PR 评审正在失效

品味来自踩坑和导师指导，但传统的传承通道正在被切断。好的 PR 评审是提问式的：「为什么这么做？

看看别处是怎么做的？」逼新人去读代码、去学习。最差的评审是「这是错的，我帮你重写了」——那人什么都没学到。

而现在更糟：评审人写下评论，但知道对方不理解自己写的代码，只会把评论粘贴给 AI 让它修。「到那个时候，我是在做你工作中每一个重要的部分。

」Mitchell Hashimoto 的做法被 Dex 认可：PR 评论只写「去问你的 Claude 为什么这是错的」，不给任何提示，逼你自己做功课。往前看，设计文档评审会承担更多教练功能——因为「设计文档基本上就是一个提示词」，在文档上评论就是在教作者更好地写提示词，这会变得和代码评审一样重要。

Dex 的真实工作流：50% 直接写，10% 夜间机器人，30% 走流程

• 约 50-60% 一发直出：预计少于几百行的改动，不做任何前置规划，直接让智能体做，然后测试、再补几个提示词。
• 约 10% 靠夜间「清洁工机器人」：他们定义代码库的期望终态，用类似恒温器(目标 71 度、现在 69 度就开暖气)的控制循环，每晚自动生成小 PR——修一条 lint 规则、迁移一个旧端点。关键纪律：每个 PR 都要小，太大就永远不会被合并；用看板和标签保证每类任务任何时刻最多一个打开的 PR,没合并就不跑下一个。
• 约 30% 走 RPI 家族流程(新版叫 crispy):先做代码库研究、找出 200 个仓库里对这个功能重要的那七个、汇总上下文，然后一轮到三轮规划会话——大而模糊的事先写产品需求，否则直接进技术设计。特别大、想中途检查的，再加一份「按什么顺序做、每一步怎么检查」的文档——「每一千行检查一次，交付一万行代码容易得多」；一万行全写完才发现坏了，调试面就太大了。有时干脆拆成堆叠 PR,先落第一个可合并的小块。

实现阶段他们用子智能体(主模型编排小模型，跨厂商编排目前要靠 Codex CLI 之类的变通)。但有条内部铁律：不要把你自己没读过的代码发给别人审查。有时读完要改 50%,有时干脆全部扔掉回到设计——而且他强调，人们低估了「直接扔掉输出重试」这个选项的价值。

少并行，别追订阅额度

被问「要不要计划 10 件事夜间全跑」，Dex 的回答是工程学的老道理：「少并行做一些事情。」不想一觉醒来面对一万行代码；并行要大量规划，然后一天头四个小时全在审代码。

更好的节奏：计划两件事，现在启动，盯着进行，今天就把改动落进生产。做两件、两件、两件，比 10 件事同时在飞、忘了两件、四天后交付两件、三件还悬着，端到端吞吐量高得多。

他还点破了 token 堆量文化的根源：订阅制。所有晒「用满六个订阅」的人和企业现实完全脱节——没有企业用订阅计划，它们全都按 token 付费(因为要安全和数据留存要求)。

从 200 美元订阅里榨出 3000 美元的用量不是什么本事，「技能问题不是没能用掉足够多的 token」。他预测回望这个「订阅堆量」时代，大家会说：那只是因为模型按订阅分发给独立开发者，才显得重要，然后某一天就没人关心了。他的个人节奏：研究类任务(大代码库里要跑 10-20 分钟)可以异步启动两三个、去喝杯咖啡，换来的是 90-99% 的上下文准备度；但并行时永远保有一件最重要的事，它一解锁，放下手头一切——哪怕提示词写到一半——因为目标是落地一件事。

【背景】「上下文工程」(context engineering)指围绕模型组织和管理上下文信息的工程方法，Dex 因推广这一术语被广泛引用。SWE-bench、Cognition(Devin 的开发商)、Claude/Codex/Opus 等均为访谈中提及的行业模型或工具。

本集带走

• 别用基准分数外推真实工程：SWE-bench 式小 PR 和「重建 Excel」都不能代表真实构建；Slop Code Bench 这类多检查点连续演进任务显示，所有模型维护代码库的能力都在退化，且短期内 labs 不会优先修这个。
• 规划的本质是分层消灭失败模式：一页纸消灭 50% 坏方案，放大一层再消灭 80%,把返工从 25-75% 压到 0-10%;但别指望完美计划，真相之源是代码。
• 可维护性目前只有人能守：没有提示词或确定性工具能替代有品味的工程师;新产品经理写 PRD 的怪招——给一个两句话提示，让流水线先研究 200 个仓库、再「拷问式」提问补全需求。
• 设一条底线：不把没读过的代码发人审查；写得不好就整个扔掉重试，别恋战。
• 追求 2-4 倍而非 100 倍:渐进提速是复利；少并行,永远有一件最重要的事,它解锁时放下一切。
• 对下一代工程师:PR 评论改成提问式,或学「去问你的 Claude 为什么这是错的」；设计文档就是提示词,评审它就是在教人写提示词。

不要抵押你的代码库,指望一年后会出一个聪明到能修复你所有问题的模型。
Do not mortgage your code base in the hopes that in a year the model will come out that’s smart enough to fix all your problems.
—— Dex Horthy · [01:08]

这是一个完整的基准测试,专门用来证明模型会让代码库随着时间推移变得越来越糟。
It’s an entire benchmark designed around proving that models make code bases worse over time.
—— Dex Horthy · [02:38]

疯狂的事情是这样的:在 Claude 3.5、3.7,大概 Opus 4 那个时代,我们经常这么做——好,是的,我知道代码很潦草,但等到这个问题真正要紧的时候,那就是 GPT-7 的问题了。
Well, so here’s the crazy thing is like we used to do this thing in the like Claude 3.5, 3.7, maybe like Opus 4 days where it’s like, cool, we’re just gonna, yes, I know the code is sloppy, but by the time that matters, that’ll be GPT-7’s problem.
—— Dex Horthy · [06:08]

它最终大概会发生,但实验室们似乎对在其他方面爬坡更感兴趣,比如计算机使用和其他前沿领域——软件可维护性那最后 10% 可能和过去三四年我们花功夫的前 90% 一样难,甚至更难。
It will probably eventually happen, but it seems like the labs are much more interested in like hill climbing on other sorts of things like computer use and other like frontiers that like the last 10% of software maintainability may be like as hard or harder than the whole first 90% that we spent the last three or four years on.
—— Dex Horthy · [06:30]

你没法捕捉所有东西,而且真相之源应该是代码,而不是某个规格说明或计划。
You can’t capture everything, and the source of truth should be the code, not some specification or plan.
—— Dex Horthy · [09:56]

全是炒作。每个人都想互相 impress,每个人都想宣称自己搞明白了 dark factory 那套东西。
It’s all hype. It’s everyone wants to impress each other. Everyone wants to claim they’ve figured out the dark factory thing.
—— Dex Horthy · [18:57]

他说,现在有点像是 Instagram 阶段。一切都是假的。
He said, this is kind of the Instagram phase right now. Everything is fake.
—— 嘉宾 · [20:34]

我不认为说「如果你没有用满六个 Codex 订阅,那你就是个糟糕的工程师」是可以的。我觉得这对行业是有伤害的。
I don’t think it’s okay to be like, if you’re not maxing out six Codex subs, then you’re a bad engineer. I think that’s like hurtful to the industry.
—— Dex Horthy · [21:28]

从对世界的经济影响来看,我认为每个工程师速度提升 2 到 4 倍对人类社会来说都将是变革性的。
I mean, if you think about it, like in terms of like economic impact in the world, I think every engineer going 2 to 4x faster would be transformational to human society.
—— Dex Horthy · [22:01]

但所有人都会错过这一点,因为他们太忙着追求 100 倍了。
But everyone’s going to miss out on that because they’re too busy trying to get to 100x.
—— Dex Horthy · [22:23]

我从来没有见过一个提示词或一个确定性工具,能够在没有人类参与的情况下,以任何有意义的方式驱动代码库的可维护性并对抗模型写出不可维护代码的倾向。
But I have never seen a prompt or a deterministic tool that can drive code-based maintainability and fight the model’s tendency to write unmaintainable code in any meaningful way without a human in the loop.
—— Dex Horthy · [27:15]

我的建议一直是,不要拿你的代码库去抵押,指望一年后、六个月后或十八个月后会有一个聪明到能解决你所有问题的模型发布出来。
And my advice is always like, do not mortgage your code base in the hopes that in a year or six months or 18 months a model will come out that’s smart enough to fix all your problems.
—— Dex Horthy · [30:27]

到那个时候,我是在做你工作中每一个重要的部分。
And at that point, I’m doing every part of your job that matters.
—— Dex Horthy · [32:03]

如果你每一千行就检查一次,交付一万行代码会容易得多。
Because like, it’s a lot easier to ship 10,000 lines of code if you check it every thousand lines.
—— Dex Horthy · [39:31]

我觉得人们低估了你可以直接把输出扔掉重试这一点。
I think people underestimate that you can just throw out the output and try again.
—— 嘉宾 · [41:13]