Dex Horthy关掉AI软件工厂:3个月不读代码会反噬

📍 文 / 老Z

本文整理自 The Pragmatic Engineer 频道节目，2026-07-16 发布。以下为完整中文实录，保留嘉宾原话不做改写。

访谈全文

Gergely Orosz： 所以，什么是上下文工程（context engineering）？

上下文工程：把抽象拆回 token

Dex Horthy： 它有点像把 RAG、记忆、智能体历史这些层层抽象重新拆开。说到底，它们都是把 token 传进模型的不同方式。

Gergely Orosz： 什么是“聪明区”（smart zone）和“愚钝区”（dumb zone）？

Dex Horthy： 你使用的上下文窗口越少，结果通常越好。这条规律几乎一直成立。

Gergely Orosz： 最近又冒出来一个新范式，叫循环工程（loop engineering）。你觉得它的问题在哪里？

Dex Horthy： 循环的问题是，到了某个点，你会生成多到自己读不过来的代码。我们在 2025 年 7 月搭过一个“关灯软件工厂”，到 11 月就把它关掉了。

Gergely Orosz： 我们可以聊聊你说的“更狠地烧 token”和“更聪明地用 token”吗？

Dex Horthy： 我在一个叫 Hyperengineering 的群里，里面都是想把 Claude 订阅榨干的人。这就是我说的“更狠地烧 token”。但真正的问题是：如果你让 AI agent 连续几个月发代码，却没有一个开发者读任何一行，会发生什么？今天的嘉宾 Dex Horthy 就真的试过。他建了一个无人值守的软件工厂，四个月后不得不关掉，因为系统开始停止正常工作。Dex 是 HumanLayer 的创始人，也是“上下文工程”这个词最早的提出者之一，比 Andrej Karpathy 和 Tobias Lütke 把它带火还早几天。过去两年，他和数百名 AI 工程师聊过，研究大家真正用 LLM 构建产品时有效和无效的做法，也在自己的团队里测试了很多极端想法。今天我们会聊上下文工程、上下文窗口的物理规律、循环工程、从 1968 年 NATO 会议到今天的智能体软件工厂、规格驱动开发、为什么规格总会和代码漂移，以及更多。

Gergely Orosz： Dex，欢迎来到节目。

Dex Horthy： 很高兴来。我们进入上下文工程和那些更辛辣的话题之前，先讲讲你是怎么进入科技行业的？你怎么爱上电脑的？

从月球路径算法到平台工程

Gergely Orosz： 我本科读的是物理。后来我意识到自己不喜欢学术。物理专业毕业大概有两三条路：读博士、去金融、或者去写程序。那是 2011、2012 年，我还在本科中间。当时我高中做过一次实习，和加州 Jet Propulsion Lab 的 NASA 研究人员一起工作。他们拿到了一套非常高精度的月球南极地形数据。月球南极很有意思，有些陨石坑因为角度问题从没见过阳光，里面有月球形成时留下的冰冻水。科学家很想去那里探索。我们的问题是：已知月球车最大上坡、最大下坡角度，给定 A 点到 B 点，能不能找一条不会违反坡度限制的路线。我当时 17 岁，从没翻过计算机教材，就写了一个非常天真的、很糟糕的 Dijkstra 最短路算法版本。后来上大学时，我想：我可能不想走学术，但我当年很享受写程序。于是我修了半个 CS 辅修，然后去了芝加哥一家软件公司的 API 平台团队。

Gergely Orosz： Sprout Social，对吧？

Dex Horthy： 对。然后基本就再也没回头。

Gergely Orosz： 之后你又去了哪里？你是怎么学到这些手艺的？你第一份正式工作就做平台工程，这在 2012 年前后并不常见。

Dex Horthy： 入职两三个月后，我发现公司里最有价值的工作，来自那些最早的几个工程师。他们知道所有系统在哪里。客户支持工单你花一天，他们 5 分钟解决；但你必须自己解决，因为你要学习。我意识到，公司里最有价值的人，是在做开发者平台的人：CI/CD、沙箱环境、预览环境。这是我进入“软件工厂”的第一步。入职三到六个月后，我几乎就迷上了这个问题。

Gergely Orosz： 今天大家都在说软件工厂，但你当时就在想这件事了。那还是 AI 之前。

Dex Horthy： 我一直惊讶，有很多开发者说：“我不想碰 CI/CD，我讨厌 CI/CD。”我会想：真的吗？做“构建那个构建东西的东西”，再做“构建那个构建构建东西的东西”，这不就是软件工程师的高杠杆吗？工程师本质上很懒，我们想做能让自己更省力的事。如果我们能建一个东西，帮我们更快地建东西，那就是懒工程师最应该做的事。

Gergely Orosz： 后来你去了 Aspiration，也是平台工程？

Dex Horthy： 对。我刚进去三个月，招我的工程 VP 就离开了，具体是辞职还是被裁我不确定，中间有些戏剧性。我在那里待了一年左右，曾经有一段像代理 CTO，招了几个人，也帮忙找新的 VP。但我后来离开了。我觉得自己可能再也不做 consumer 了，我本质上是 B2B 人。

Gergely Orosz： 然后你去了 Replicated，待了四年，从工程师到前线部署工程师，再到产品经理。

Dex Horthy： 对。我先做了两年核心工程。我们在 Kubernetes、Docker Swarm 真正成熟前，自己做容器编排器。创始人的判断是 Docker 会让 on-prem 软件更容易交付：不是把应用放在某个机柜里，而是“把应用带到数据所在的地方”，而不是把数据传给云厂商。后来我很喜欢客户。我们的客户是 HashiCorp、DataStax、Puppet、TravisCI、CircleCI 这些很酷的工程品牌。公司最难的问题是：如何把一个 3 到 5 年历史的 SaaS 平台打包起来，让完全不了解我们架构的人能在自己的 AWS VPC 或数据中心里可靠运行。我成了第一个真正面向客户的工程师。大概三个月里，我见了所有卡在 pipeline 里的企业客户，3 个月关了 12 单。CEO 说：“天哪 Dex，投资人又开始接我电话了。我知道你想回去写代码，但我需要你招三个人把这个团队建起来，因为你可能天生适合干这个。”

Gergely Orosz： 很多工程师担心，如果去做客户面向的工作，会失去工程信誉。

Dex Horthy： 是的。我没有每天写十小时代码，但周六还会写三四小时。我很高兴做了这件事。个人层面，我二十多岁时一直有点内向、有点社交尴尬。我的叔叔是音乐制作人，曾和 Randy Newman 等很多著名音乐人合作。有次吃饭他跟我说：“如果你想真正擅长某件事，你必须让它成为你唯一做的事。那些晚上和周末弹吉他的人，很难真正伟大。真正伟大的人，是那些如果不弹吉他就没饭吃的人。”于是我想，与其读自助书教自己别那么内向，不如直接把“和人说话、交朋友、帮人解决问题”变成工作。我觉得这奏效了。我建议每个人至少花一两年做非常贴近客户的工作。

Gergely Orosz： 之后你成为创始人，也比较早卷入了 AI。

Dex Horthy： 我应该说，我本可以更早。2020 年 11 月左右，我和芝加哥一个朋友创办了一家数据工程公司 Metalytics，技术上它和现在的 HumanLayer 还是同一家公司，只是使命变了。后来数据工程工具这个市场没有大家想象的那么大，融资和获客都很难。

Gergely Orosz： 大约一年前我在活动上遇到你，当时你已经对使用 AI 有很强的观点。其中一个就是现在很有名的“12-factor agents manifesto”。

Dex Horthy： 我们现在叫它 manifesto 了吗？

Gergely Orosz： 我叫它 manifesto。我们聊聊它。那是构建可靠、生产可用 agent 的 12 条工程原则。你是怎么想出来的？

12 Factor Agents 是怎么长出来的

Dex Horthy： 大概在 2024 年 8 月，我的联合创始人 burnout 后离开了，关系很好。我开始折腾 AI agent。当时最火的是 LangChain、CrewAI 这些 agent 框架。生态很热闹，Discord 里上万人，每个项目都有 ChromaDB 插件、Composio 插件。我当时问：这里缺了什么？agent 能调用工具，但你很难控制它到底调用哪些工具。如果是聊天机器人，UI 里可以 approve/deny。但我痴迷的是“外循环 agent”或主动 agent：它们在后台运行，被事件触发。OpenClaw 基本就是这种形态的最大体现：有心跳，醒来，看有没有事要做，然后尝试完成。我不会信任这样的 agent 做有意义的事，除非它想做关键操作时，我能收到 Slack 或 iMessage，并且确定性地 approve、deny，或者带反馈地 deny：“不，这样做。”

Dex Horthy： 我们在这个空间玩了一阵，和很多创始人、早期工程师、builder 聊。2024 年秋天我们进了 Y Combinator，想法是做一个像 PagerDuty 的 API 平台，只不过不是“谁值班修服务器”，而是“谁值班批准这个 agent”。它可以升级、委派或延后操作。我们为 CrewAI、LangChain 那个生态做了很多东西。但后来我和很多真正把 AI 卖给企业、做六位数合同的 AI 工程师聊，发现他们几乎都试过这些框架一两个月，然后扔掉，改成手写 LLM API 调用，做更像 pipeline 和 workflow 的东西，而不是“工具在循环里自由调用”。我大概聊了一百个人。后来我把这些想法整理成 12 条原则，发到 GitHub，再发 Hacker News，挂在首页大概两天，引起了很多共鸣。

Gergely Orosz： 我快速读一下 12 条：Natural Language of Tool Calls、Own Your Prompts、Own Your Context Window、Tools Are Just Structured Outputs、Unify Execution State and Business State、Launch/Pause/Resume with Simple APIs、Contact Humans with Tool Calls、Own Your Control Flow、Compact Errors into Context Window、Small Focused Agents、Trigger from Anywhere、Meet Users Where They Are、Make Your Agent a Stateless Reducer。

Dex Horthy： 最后一条后来有人在 Twitter 上纠正我，严格说是 transducer，因为 workflow 里有多个步骤。但核心仍然成立。今天回看，最重要的是第三条：Own Your Context Window。无论你做的是 agent，还是 pipeline 里的单步调用，你唯一能影响 AI 输出质量的方式，就是非常在意输入，并精心构造它。

Gergely Orosz： 那我们正式聊上下文工程。我愿意把这个词归功给你，因为我查了一下，你比别人早几天。

Dex Horthy： 加个星号：我从和那一百个工程师、创始人的对话里学到了上下文工程。我没有发明这种做法，只是看到了他们共同在做什么，然后给它起了一个名字。名字很重要，尤其现在 AI 内容里有太多炒作和无意义术语。我觉得这里确实有一个对 builder 有用的词，能解释他们该怎么构建软件。

Gergely Orosz： 所以什么是上下文工程？

生产级 AI 应用要往下拆一层

Dex Horthy： 它就是把那些叠在上面的抽象重新拆掉。RAG、memory、agentic history、structured output，这些在 agentic programming 框架里听起来是不同概念，但最后它们都是把 token 放进模型，让模型产出某种结构化输出。理解这一层，比学习某个 memory 框架、从货架上拿一个 agent 框架更有力量。那些框架能让你到 80%，做一个好 demo；但如果你要从 80% 到 95% 或 99%，你就必须往下走一层，仔细想：我们到底往上下文窗口里放了什么？顺序是什么？用的是哪个模型？所有这些都重要。上下文工程就是：我如何让 AI 尽可能准确地做我想要它做的事。

Gergely Orosz： 为什么它最近变得更常被讨论？是因为上下文窗口变长了吗？还是大家终于意识到 context 这件事很重要？

Dex Horthy： 我觉得它一直重要。只是需要很多聪明人真的去做能卖给企业、质量足够高的 AI 软件，才会发现这件事。最容易做高质量 AI 应用的方式，是在 token 层面思考：把一个问题拆成一串 LLM 调用，而不是只想“工具在循环里自己跑”。后者灵活，但不稳定。你要把 agent 看成 workflow、pipeline，或者少量 tool loop 和明确步骤的混合。你有的杠杆比“工具、模型、system prompt”多得多。这需要更多工作，也需要更深的直觉，但这是突破质量天花板的抽象层。

Gergely Orosz： 成本和上下文工程之间是什么关系？

Dex Horthy： 我喜欢说“先让它跑起来，再让它正确，再让它快”。先看当时最强的模型能不能解决问题，给用户用，看他们要不要。如果有人要，而且用量变大，再投入大量上下文工程。因为早期最贵的不是 token，而是工程师时间。等到你有百万级请求，才值得把流程拆成三次调用，让某些部分用 GPT-4o，某些部分用更便宜的小模型。上下文工程就是把人类努力加入系统，提升效率、速度、价格和成本效率。

Gergely Orosz： 你后来又提到 harness engineering。它是什么？

Dex Horthy： 我去年 10 月或 11 月写过这个词。我的定义是：当你构建 agent 时，你做上下文工程；当你使用像 Claude Code、Codex 这样的 agent harness 时，你要对 harness 的集成点做工程——命令、MCP、skills、代码库组织方式。怎么优化 coding agent 运行的环境，让每一轮结果的下限更高。后来这个词变得很模糊，有人认为是构建 harness，有人认为是围绕 harness 构建。Martin Fowler 的说法更清楚：LLM，本身；inner harness，是工具定义和集成点；outer harness，是人类为了自己的代码库、语言和需求做的定制。这个定义最好。

Gergely Orosz： 命名仍然很重要。

Dex Horthy： 是的。我惊讶的是，“上下文工程”一年后还基本保持同一个含义，而且仍然相关。AI 里 15 个月前写的东西，有多少今天还值得看？变化太快了。上下文工程能活下来，是因为它扎根于 transformer attention 的基本机制。只要我们还没有后 transformer 模型或线性 attention，context engineering 对构建 AI 的人就仍然重要。

Gergely Orosz： 我们聊聊上下文的物理规律。你发过一张“Context Reality Check”的图：上下文到 100 万时，质量会下降。从实践角度，我们要知道什么？

长上下文不是更聪明的模型

Dex Horthy： 长上下文窗口当然有用，因为你可以聊更久。但尤其像 Opus 4.5 或 4.5 1M 这种模型，你并没有得到一个更聪明的模型。模型的智能决定它能否在 10 万、20 万 token 里找到下一步工具调用真正相关的东西。有研究发现，前沿模型大概能跟随 150 到 250 条指令，之后就会快速掉队。后来模型可能更好，但原则一样。我把上下文工程分成两类：信息预算和指令预算。很多人只想到 RAG：别把整本书塞进去，取几个 chunk。但指令预算同样重要。你给模型太多指令，尤其是相互冲突的指令，再加上一段对话轨迹，模型要计算哪些该忽略、哪些该听。当相关信息离当前 turn 太远时，它记住精确指令的概率会显著下降。

Gergely Orosz： 这和传统软件工程很不一样。以前代码要么编译，要么不编译。现在 AI 工程师需要理解 context 的动态。

Dex Horthy： 对。我不是机器学习博士，画不出数学证明，但我们知道 attention 是平方复杂度。你放进去的东西越多，模型的注意力就越被分散。工程师的很多直觉来自凌晨 3 点 debug 过坏模式。Netflix 的 Jake 在 AI Engineer 上说过：“没有比亲自经历坏掉的东西更好的学习方式。”

Gergely Orosz： 说到坏掉，循环工程正在流行。比如 Ralph Wiggum technique。你怎么看？

循环工程：能验证才适合放飞

Dex Horthy： Ralph Wiggum 是一年前我看到的 demo。Jeff Hundley 来旧金山，展示他让 Sonnet 昼夜不停跑，6 周花了 6000 美元，做出一个完整的 Gen Z 编程语言，能编译，还有第二阶段编译器。核心教训是 back-pressure：怎样让模型检查自己的工作？怎样自动把反馈喂回模型？如果问题足够可验证，比如编程语言，模型就能循环自我改进：编译失败就修编译器，程序运行失败就继续修。循环工程的关键是：只要你能让问题高度可验证，就能把它当黑盒，用验证循环让模型迭代。

Gergely Orosz： 你也可以把它用在 CI/CD 上：让模型研究代码库、改一处、发 PR、跑测试、看是否更快，然后继续。

Dex Horthy： 对。如果目标可测，比如“把模型变快两倍”，就可以让它不断尝试。这就是我理解的 loop engineering。

Gergely Orosz： 你们做的慢循环是什么？

慢循环：每晚只开一个小 PR

Dex Horthy： 很多人一兴奋，就想把一切重做成 agentic-first factory，甚至 dark factory。但现实里没人愿意审一个 6 万行的 PR。所以我最感兴趣的是 iterated loops 或 slow loops。结构很简单：一个 cron job，每晚跑 linter，修一件事，commit、push。早上醒来，我们看到一个让代码库变好一点的小 PR。你可以增加反馈机制，比如 React Doctor、prop narrowing；也可以增加范围：从修一件事变成四件事。触发器可以是 Sentry 告警、用户反馈、PM 写票、测试失败或定时任务。重点是，不需要人按按钮，但 workflow 被定义得很小，每次只让系统好一点。

Gergely Orosz： 你有条推文说：“未来一到三年，我们可能会经历凌晨 3 点系统坏掉、你依赖循环修它、但没人知道底层发生了什么的阶段，这对公司是生存威胁。”

关灯软件工厂，四个月后关掉

Dex Horthy： 那条传播很广。另一面是，以今天的模型、语言和基础设施，你也许能短期不读代码。但问题是，循环会生成多到你读不过来的代码。这就是 dark factory。Ryan Leopo 会说 harness engineering 就是尽可能多花 token。我们试过。2025 年 7 月，我们建了 lights-off software factory；到 11 月，我们关掉了。大概 3 到 6 个月，在没人读代码的情况下持续发代码，你会意识到：代码库变得越来越糟，重写比修更容易。也许在 AI 帮助下重写没那么可怕，但我不再相信这是好的默认方式。

Dex Horthy： 我们现在用循环，不是为了让它直接发用户要的功能；我们用循环改善代码质量。我们读所有代码，因为我们在乎架构和 program design：接口、边界、依赖注入，这些让代码库可维护的东西。模型还不够聪明，训练和 benchmark 也还没教会它长期写可维护代码。SWE-bench 这类任务只是：“这里有 Django 的 issue 和 commit，能不能修？”它没有训练模型理解三个月后的可维护性。

Gergely Orosz： 这和高级工程师成长很像。人需要多年踩坑才知道今天一个小错误如何滚雪球。

Dex Horthy： 是的。GPT-7 也许能解决。但如果你现在把灯关掉，说“不读代码也没关系，模型够聪明，只要多扔 token”，也许短期可行。可一旦你把代码评审换成 agentic testing 和 agentic code review，你就失去了对软件架构的直觉。我们自己遇到过：三个月不读某块代码后，出了一个问题。无论用多少专家提示，Opus 4.1 都找不到根因。我们花了好几天钻代码，才发现是一个主键类型一路被错误传递。那次让我改变了看法：以前我觉得偶尔花两周手修问题，换来大部分时间不读代码，值得。现在代码生成速度是 10 倍、100 倍，问题只会更糟。

Gergely Orosz： 我们聊软件工厂。AI 之前和之后，它分别是什么？

软件工厂不是 AI 发明的新词

Dex Horthy： “软件工厂”最早的说法出现在 1968 年的 NATO 会议。那时大家就在谈把编码、测试、验证、集成变成像工厂流水线一样的步骤。后来 Toshiba 等公司也采用这个概念。再后来是 DevOps：用 Chef、Ansible、Puppet、CI/CD 自动化，把原来人在数据中心里手动做的事变成反馈循环。2018 年，美国空军 CTO Nick Chaillan 写过一篇上百页的文章，说国防部需要 software factory：DevSecOps、Jenkins、代码质量扫描、安全扫描、每天发布而不是三个月或一年发布一次。核心都是：用自动化抓住 90% 的问题，让人把时间花在真正困难的地方。

Gergely Orosz： 那 AI 之后呢？

Dex Horthy： 以前的软件工厂有一个工作来源，比如 Jira；然后架构评审、计划、工程师拿票、开发、PR、评审、CI、上线、用户投诉，再回到 tracker。这个循环很长，一个 bug 从写出来到反馈回来可能要两三个月。现在 agentic factory 把“拿票开始工作”的人换成 agent。你有 orchestrator、sandbox、LLM、inner harness、outer harness，也许还有浏览器、录屏器。它发 PR。瓶颈变成 code review，于是你再让 AI 做 code review 和 testing。再往后，部署到生产、用户投诉、support queue 都直接接到 agent：每次出错，你都得到一个 PR。这就是 ramp-up。区别是，代码太多后，人们说：把灯关掉，拿掉所有人工测试和评审，把整个系统当黑盒。

Gergely Orosz： 你觉得我们离理想的全自动软件工厂有多远？

Dex Horthy： 我关注三件事：第一，切穿炒作和术语，真正试东西、和人聊、搞清楚什么有效；第二，保护有用词汇，比如 agent、software factory，避免它们扩散成无意义噪音；第三，往下一层理解机制。软件工厂这块，我最近在研究 RLVR（reinforcement learning with verifiable rewards）、编码 agent benchmark、训练技术。Claude Code 变好，唯一真正让它变好的，是强化学习。他们把模型和 harness 一起训练，所以模型非常擅长调用特定工具：读文件、写文件、搜索文件。这让它比之前的 CLI coding agent 体验好很多。但它只在一个维度变好了。还没变好的维度是：它写出的代码，三个月后是让人和 agent 更高效，还是更糟。

Gergely Orosz： 也就是说我们缺少评估“长期可维护性”的 benchmark。

Dex Horthy： 对。Frontier Code 比较好，会看测试是否通过，再用两层模型评审：功能是否等价、代码质量如何。但还不够。模型写代码和模型审代码不是同一回事。你问模型“这段代码好吗”，它会说“很好”；你让它审同事的 PR，它又能指出问题。它有迎合性。也许可以做一种 benchmark：让模型连续构建 20 个功能，并在不知道后续功能的情况下保持代码库可维护，看它到第 6、7 个 issue 时是否崩掉。

Gergely Orosz： 那软件团队应该怎么改变？

Dex Horthy： 如果你想做循环工程，就一次只建一个 loop，让它小而受控。除了“停止读代码”之外，几乎所有自动化都是好建议。把 support tickets 变成 tickets，再变成 PR，很好。HumanLayer 追求的是在中间加更多 checkpoint：不仅是在 PR 末尾做人审，而是在交给实现者之前，用人和 agent 一起做计划。这就是规格驱动开发的一个更务实版本。花一小时在构建前计划，让 PR 读起来只要 20 分钟，因为代码更接近正确。软件工厂世界里有三个选择：关灯让一切流动，祈祷别造太多 slop；慢下来读每个 PR，只得到 30% 到 50% 的生产力提升；或者找到高杠杆点，用一小时计划省掉四小时实现和返工，以接近人类质量的方式快 2 到 3 倍。

Gergely Orosz： 你们曾经提出 Research, Plan, Implement 框架。你们后来发现哪里错了？

RPI 的反杠杆教训

Dex Horthy： 2025 年 8 月我们第一次讲 RPI。Research 是：构建前让子 agent 并行读大量代码，理解系统，产出 markdown。这是上下文工程：把 100k token 的代码库状态压缩成 10k token 文档。然后新开上下文窗口做 planning。问题是，我们当时的 plan 很糟。它写出每行会改什么、diff block、一堆新文件。人们会“审计划”，但实际上我自己也只是在 skim。结果你没有用计划来重新转向，只是多读了一遍代码，时间翻倍，这就是反杠杆。

Gergely Orosz： 规格驱动开发也类似吗？先生成计划，人审，改，再实现。

Dex Horthy： 对。有人把 spec-driven dev 解释成“只写规格，把代码当编译结果”。这还没有实现，也许 GPT-7 会。现实问题是：spec 会和代码漂移。你有两个 truth source，系统很快失去价值。我们后来发现 RPI 的文档是战术性的：研究、计划、实现，然后扔掉。下次从头研究，因为 token 便宜，我的时间贵。复用过时研究文档只会浪费时间。上下文工程的价值在于：为某个任务范围，压缩代码库状态和 builder 意图，做成短期可用 artifact。

Gergely Orosz： 你也提到 compaction：当 context 变嘈杂时，故意把有用部分压缩成清晰文档，验证它，再开新对话。

Dex Horthy： 对。频繁、刻意的 compaction 是上下文工程的基础。尽量在 smart zone 里工作：小模型前 100k token，大模型可能 200k。研究步骤把代码压成文档；设计步骤把意图和现状压成高层设计；再开新 session 规划。模型读代码和总结很强，但设计 end state、架构和 program design 并不总是强。计划也常常是横向的：数据库、服务层、API、前端，这样你写 2000 行代码后才能测试。我更愿意先 mock 一个 API，用假数据把前端跑起来，再做服务、迁移、业务逻辑、错误处理。人类的品味和判断仍然重要。

Gergely Orosz： 那定义一下 smart zone 和 dumb zone。

Smart zone 与 dumb zone

Dex Horthy： smart zone 有点模糊。以前我说是上下文窗口前 40%；有了百万 token 后，我改成：小模型前 100k，大模型比如 Codex 或 Opus 4.8 也许前 200k。Jeff Hundley 的 Ralph Wiggum 经验也是：上下文用得越少，结果越好。dumb zone 是信息被遗忘、混淆、退化的区域。如果模型在 200k token 处为了让测试过而开始“试这个、试那个”，甚至说“让我删掉你的文件重来”，那就该 compaction 后开新 session。

Gergely Orosz： 你说过，如果模型说“you are absolutely right”，就该重开。为什么？

Dex Horthy： 因为那通常是你生气指出错误时模型的反应。它说“你完全正确”，然后继续做错事。上下文里有四类影响：大小、信息质量、缺失信息、轨迹。轨迹很微妙：你让它改，跑测试，修测试，它会沿着这个轨迹继续；你让它改但不跑测试，轨迹就不同。如果你连续几次骂模型，它下一条很可能继续犯错，因为对话轨迹已经坏了。这时应该重开。

Gergely Orosz： 你最近还说，从“token harder”到“token smarter”。

别更狠烧 token，要更聪明用 token

Dex Horthy： token harder 是优化工厂里一个节点的利用率：我有 6 个 Claude Code 账号，每 5 小时都榨干。这不是优化端到端价值。dark factory 也是一样：拿掉人类 code review，让更多 token 流过。token smarter 是：在不关灯的情况下尽可能快，保持控制、品味、判断、系统架构理解，把十年软件工程经验用于 program design，让代码随着时间更好维护。就像 Google SRE：不是把 SRE 全拿掉，而是用自动化让小团队管理更多数据中心。你希望 headcount 近似对数增长，而输出线性增长。做到这点需要好架构和人在环。

Gergely Orosz： AI slop 呢？你写过：“AI 能写代码，也能写 spec 和 PRD，但规则永远是 slop in, slop out。如果你外包思考，得到的就是垃圾。”

Dex Horthy： 对。你可以手写代码，也可以和模型来回协作，快一点，同时读每个改动，纠正它。这会更快，但不是无限快。另一个极端是关灯，最大化速度。真正的杠杆是降低不确定性：从一句话或语音 memo 开始，让 AI 变成一页纸，你检查；再变成三页；再变成十页详细大纲；最后写代码。你不需要追求每一步完美，但你在不断缩小可能结果的空间。像即时战略游戏，有战争迷雾，你要根据已知信息做最可能成功的决策。

Gergely Orosz： 说回 HumanLayer。它是什么？

HumanLayer：为 agent 时代重做工程协作

Dex Horthy： HumanLayer 是一个 AI IDE、协作平台，也是软件工厂的构建模块。我们服务的是在复杂代码库里解决难题的工程师。市场上有两类人：一类是 vibe coders 做 side projects；另一类是在构建高风险生产软件，坏掉会带来罚款或损失。我们帮后一类人以 2 到 3 倍速度解决问题，同时不坠入 slop，尽量保持接近人类质量。

Gergely Orosz： 你们具体在做什么？

Dex Horthy： 一个想法来自 RPI 和 spec：高层开始，一层层 zoom in，找到杠杆。另一个问题是：“我们要不要杀掉 pull request？”未来 IDE 需要为 agent 从头重想，可能不是文本编辑器旁边挂一个 agent tab。我们从底层开始做一个 IDE，让开发者管理 agent 的工作。然后把它做成协作式：同步引擎、durable streams，让人类输入和反馈实时发生，而不是等到 PR 时才看。优秀工程团队几十年来都做设计评审、架构文档、sprint planning。AI 可以帮这些环节。如果你只用 AI 写代码，就错过了很多东西。

Dex Horthy： 我们做了一个云平台，有类似 Google Docs 的组件，你可以评论，agent 可以呈现 mockup、Mermaid 图、HTML。我们想让 agent 像巨大的 Figma：一切在云端、协作、可见。你能看到同事的 session，他们也能看到你的。就像 Slack 相对 email 的变化：你不必在每个对话里，也能知道发生了什么。工程工作也该有更连续的数据模型：agent trace、文档、任务、项目、git diff 都在同一个共享环境流动。

Gergely Orosz： 这有点像 GitHub 当年对软件团队做的事。

Dex Horthy： 对，我们想做 GitHub 做过的事，但更实时、更连续、更协作，而不是离散的 pull request 单元。

Gergely Orosz： 对 AI startup 来说，地理位置和网络重要吗？你在硅谷。

Dex Horthy： 我没有特别强的观点。Paul Graham 在瑞典讲过为什么 SF 很酷：pay-it-forward 文化、别人因为你在这里而更认真对待你。我在芝加哥住了很久，也有很多朋友。但我从没像现在这样感觉自己和一群人如此同频。这里有很多非常 competent、关心同样问题、热爱同样东西的人。朋友会来办公室 cowork 到晚上 11 点，一起 hack 有趣项目。这种密度不是哪里都有。

Gergely Orosz： 你们怎么招聘？什么是优秀工程师？

Dex Horthy： 我们看重扎实的软件基础：分布式系统、核心 CS、操作系统。不需要是内核博士。我们可以在几个月里教一个人变成好的 AI developer，建立直觉、加速上手。但很难在三个月里教完一个 CS 本科。

Gergely Orosz： 未来几年你对哪些软件工程或产品构建问题兴奋？

Dex Horthy： 实时、云端、沙箱、同步这些新 building blocks 很有趣。我们喜欢 ElectricSQL 团队的 durable streams。你希望 coding agents 可以在任何地方运行：短时间、长时间、按需、按计划，但都是同一个大脑的一部分。我们做的东西一部分很无聊，比如所有数据在 Postgres；另一部分很有意思：分布式系统、基础设施、协作平台。我们是在构建 AI 工具，但协作平台本身就很难。

Gergely Orosz： 最后，有什么书或阅读推荐？

Dex Horthy： 我们经常讲 Martin Fowler 的《Refactoring》。这是经典：改善既有代码设计，理解如何让模型写出更容易维护、阅读、理解、扩展的代码。还有 Clean Code、The Pragmatic Programmer，这些经典现在比以往更相关。

Gergely Orosz： Dex，谢谢你。这次很有意思。

Dex Horthy： 我也聊得很开心，谢谢邀请。

Gergely Orosz： 我真的很喜欢这次对话。Dex 是 agentic coding 的坚定相信者，但也是他在警告我们：如果你不再读代码，大概 3 到 6 个月后，代码库就会变得重写比修复更容易。这来自他的亲身经历。他的团队搭过 lights-off software factory，跑过，然后关掉。我也喜欢 slow loop 的想法。所谓 loop engineering 也许有点空，但 Dex 团队做的事其实很朴素：每天晚上一个 cron job，修一个问题或一个反模式，开一个小 PR。早上团队醒来，代码库稍微好了一点，开发者仍然需要 review 和 approve。任何工程团队今天都可以试。最后，软件工厂这个词来自 1968 年 NATO 会议。60 多年来，每一代软件行业都在尝试自动化更多构建软件的循环。AI agent 只是又一次尝试，只不过可能是目前最成功的一次。

 ✍️ 老Z ·
 欢迎转发，谢绝洗稿