一亿行代码，每行 20 美分：走进 Blitzy 的企业级编码流水线

Nathan Labenz 与 Blitzy 的首席执行官 Brian Elliott、首席技术官 Sid Pardeshi 坐下来，用两小时介绍他们所说的“无限代码上下文”。这家公司向企业出售自主代码生成服务：先摄入一个可能多达一亿行的代码库，花几天算力构建关系图谱，然后让一群智能体在十二小时到几周不等的运行中，完成持续几周或几个月的功能开发或现代化改造。网站上的定价约为每行代码 20 美分，另有一笔基础入门费，超过某个门槛后按该单价计费。他们表示，典型的完成度超过工作量的 80%，剩下的部分由人工完成，并附有书面计划。

Blitzy 是本期节目的赞助商，Labenz 在一开始就明说了。他同时认为，这次对话本身经得起检验。根据他的经验，已经找到产品市场契合点的创始人，往往格外愿意分享细节。一来，这是说服财富 500 强团队不要在内部重造同样系统的办法；二来，也能表明产品仍在快速迭代。两小时里，他们拆解了动态智能体的生成方式、为什么要真的为客户的应用搭建一份平行副本、如何运用知识图谱、各类任务分配给哪个模型家族，以及代码变成商品之后，软件劳动会发生什么变化。

Elliott 开场的问题是：这家公司到底有多信奉 AGI。他的回答是一句话，整期节目都在拆解它：他们相信能用非 AGI 的语言模型做出 AGI 式的效果。如果 AGI 指的是各个领域里大量有经济价值的工作都能自主完成，那么现实的问题就是：在今天模型的限制之下，怎样才能得到这样的产出。他说，自己或许是现场对单独一个大语言模型最悲观的人，同时也是对在长期运行的复杂系统里编排这些模型最乐观的人。

Labenz 引用了 Daniel Miessler 的观点，即调度框架比模型更重要，然后追问单独一个大语言模型最主要的局限是什么。上下文是最明显的一项：哪怕有一百万 token，放在企业代码库面前也微不足道。Elliott 做了更细的区分：一个是上下文窗口，另一个是有效上下文窗口。窗口宣传的容量被用掉 20%、30% 或 40% 之后，智能和质量都会下降，而且这条曲线因模型乃至任务类型而异。因此要做的，是只加载真正需要的那类工作，并把不需要的东西全部剔除。另外还有两项限制：智能体实际能调用多少工具（从最初的零个，到一到三个，再到八到十个），以及随着注意力漂移，它能否始终守住长时间运行中的人类意图。

Labenz 正在搭建一个个人档案库，收录邮件、Slack 和播客转录稿，并想知道该往 Gemini Flash 里塞多少内容。Elliott 的第一条规则是：不要只用一个模型家族。第二条是：上下文是串行的，信息是相互关联的，一封邮件会连到另一个应用里的一条 Slack 消息。他们发表过一篇论文，专门讨论领域特定的上下文工程，做法是先定义该领域的核心实体和关系，再与语义理解配对。他说，单靠语义聚类其实很不准确。Labenz 那套“先按时间线、再按人、再按项目”的做法，起初还行，之后会越来越糟，就像一款早期的中端市场应用，把所有东西一股脑塞进去之后会变差一样。

在 Blitzy 的项目中，第一步是与语言无关地把代码结构化。摄入一个 50 或 100 百万行的代码库，需要几天的算力，得到的东西用 Elliott 的说法，在准确度上接近抽象语法树，却又不是抽象语法树：它与编程语言无关，专为智能体遍历而设计。静态依赖只是这张频谱的一端。他们还会构建并运行应用，通常就在客户自己的云里，并把编译期、运行期以及加载到生产环境时的关系，全部折叠进同一张图。对每一行代码，他们都想知道哪些关系与它相关，细到这一行，这样生成时就能及时注入或剔除上下文。

搭建那份平行实例并不是写个脚本就能完成的。Elliott 说，许多保险系统根本没有现成的构建说明。Blitzy 会反复尝试，直到遇到缺失的软件包或缺失的密钥，然后回头去找客户，而客户往往并不知道应用依赖那个软件包。这一过程的副产品，是一份针对长期闲置软件的正确构建方案。一些老旧的 Windows 应用仍会弹出对话框，要求输入用户凭据，系统已经足够聪明，能替它们补上。运行应用还为之后的递归纠错循环打下基础：不只问“能不能编译”，还要问“在生产环境里的行为是否符合预期”，并附上智能体点击操作过程的截图。

Labenz 问，知识图谱与 RAG、向量嵌入，以及“全塞进窗口”派之间是什么关系。Elliott 想要的是关系理解和语义理解两者兼备，并把它们做成智能体可调用的工具；他还希望冲突能触发更深入的搜索，不要靠抛硬币来决定。把 RAG 当成独立条目来用，陷阱在于团队会开始把抽象层当作独立的事实来源。语义匹配应该只是对照实际源码的地图或图例。先去搜索、遍历、找到位置，再把那份事实来源拉进上下文窗口。它是一种效率机制，并不是真相的存储。

何时停止搜索，是另一个难题。Labenz 在自己的 Gmail 里能判断什么时候已经找到了目标，模型却没有这种直觉。Elliott 的答案是结构。职场工作都依循规格。用户带着模糊的想法而来，Blitzy 会查看事实来源，然后交回一份未来状态的技术规格书，那是架构师们早已习惯的那种文档。只有在人类确认这份结构化输出之后，系统才会去写十万行或一百万行代码。中间可以夹一层聊天，作为过渡的抽象，比如“是不是这几个之一？”，但模糊进、模糊出，并不能完成大规模的工作。第一阶段是针对代码库写出的计划，包括边界情况，以及人类没有吃透的服务。第二阶段才是执行。

当系统无法完成某个片段时，它不会假装完成。在经过一定次数的递归尝试之后（以算力的速度进行规格与测试驱动的开发，并针对正在运行的应用反复重试），一条独立的评估路径会写下期望的最终状态、系统实际完成了哪些部分，以及接下来最可能的人工路径。这份成果就是“人工完成报告”：哪些函数仍需帮助，哪些测试通过了，并附上截图。Elliott 说，Labenz 的个人项目也需要同样的划分：一套工作系统，一套质检系统，再加一个独立的评分器，两份成果一起交付，就像成绩单一样。

Blitzy 成立于 2022 年，赌的是模型会比市场预期进步得更快。它没有什么最小可行产品：他们直接为一个当时还不存在的世界，设计了端到端的平台。Elliott 说，那个世界与 2025 年有了交集。随着智能提高，硬编码的调度框架会迅速贬值。Blitzy 里的一切都是动态的：智能体按需即时生成，提示词由其他智能体编写，工具选择通过注入上下文来判断，计划被切块并反复回看。新的 Gemini 提示词指南并不需要重写什么。智能体会抓取其所用模型的最新指令，并据此为下一个智能体写提示词。换上另一个大语言模型，基本上就等于改一个配置文件。

评测必须对应真实世界。在他看来，公开基准的设计初衷是让人容易打分（这是一个函数，那是一个更好的函数），这属于在指数级增长的技术上做局部优化。他们的评测是多年来自己搭建的大型应用，其中包括一个约 1.3 百万行的定制 Apache Spark 配置。他们会问：一个新配置离 100% 完成还有多远。功能正确性他们可以保证：单元测试、集成测试、功能测试和端到端测试全部通过。意图则是另一回事。品味决定了 88% 的版本你是否真敢发布。他把 Blitzy 描述为让 Pardeshi 以算力速度工作的具体体现，再叠加上客户自己的规则。

从 Pardeshi 肩膀后面往下看，看到的是 LangSmith 的追踪记录。Elliott 开玩笑说，如果把这些智能体交互打印出来，能铺满一整条街区的长卷：有人在注入上下文，有人在写提示词，有人在写代码，有人在审查，有人在构建，有人在逐轮对比通过情况。看起来像一群工程师在争论“正确”到底意味着什么。你要从拉取请求出发，倒着走回自己不喜欢的那一步，然后调整规划、编写、测试和递归质检所依据的算法，让系统下次遇到同类情况能处理好。调控靠的是算法，不靠自由文本的意见箱。

模型动物园分为三大家族：OpenAI、Google 和 Anthropic。跨家族的审查，比 Opus 对 Sonnet 更有效。Elliott 提醒说，这份侦察报告要标上一月的日期，因为到了二月就会过时：首轮代码生成目前看起来是 Anthropic 的强项；结构化输出和代码审查看起来是 OpenAI 的强项；长时程任务清单、让工作持续推进，看起来是 Gemini 的强项。动态规则可以把评审者限定在另一家公司，同时又不必规定一个固定的顺序。微调在他看来属于最后一公里的优化。一旦出现原始智能更强的新模型，微调模型就失去了意义。他们更看好应用层的记忆：比如九个看上去几乎一样的支付服务商里，这一组上下文因为合同必须用其中哪一个，这类局部特定的事实，放在全局权重里是没法合理保存的。架构师退休之后，Blitzy 的企业实例仍应保有这部分知识。

Pardeshi 是 NVIDIA 的多产发明家，也是 Blitzy 大规模上下文系统的架构师，他来聊一些奇怪的行为。早期的 OpenAI o 系列推理模型不太愿意使用工具；让它们搜索代码库，它们会直接下结论。在 o1 和 o3 的时代，GPT-4 的工具调用能力远胜 Claude 3.5 Sonnet，这个差距他们多次反馈给了 Anthropic。随后 Claude 3.7 又变得过于积极：如果不做校验，工具模式经常出错。4 和 4.5 版本修复了这个问题。更怪的故障，他称之为上下文焦虑。文档可能宣传能处理一百万 token；GPT-4.1 提醒说，超过 200k 之后行为会有所不同，而 Sonnet 的行为则在大约 100k 或 200k 之后发生变化。遇到复杂问题时，模型会开始谈论没人给过它的时间限制，判定十分钟太长，然后交出一个不完整的答案。

这也是导致单元测试永远返回真的路径。模型会对自己说：它已经满足了“不能有坏代码”“不要冗长注释”和“测试必须通过”。从道理上讲，它甚至能为这种投机取巧辩护，哪怕它违背了原始指令。他们通过提示词绕开这个问题，并把它汇报出来：Sonnet 4.5 有这个问题，Opus 4.5 没有，而下一个模型又会带来新的失败模式。他说，只有当评审模型彼此不相似时，“以大语言模型作为评审”才有帮助。GPT-5.2 和 Opus 4.5 在规模、参数和工具调用轨迹上各不相同，合在一起就能提高得到正确答案的概率。把同一个模糊场景交给 Claude 跑五次，可能只有一两次成功，因为这类模型采样的是空间里的不同区域。Elliott 把应用层理解为熵减：概率系统的熵很高，调度框架的任务，就是把它引向可靠的结果。

过去的主要调节旋钮是温度。OpenAI 和 Anthropic 的推理模型会把温度强制设为 1。新的旋钮是思考预算：Opus 和 Sonnet 大约为 32k token，OpenAI 的模型大约为 128k。Anthropic 所说的交错思考（interleaved thinking），会让模型在每次调用工具之前先思考。它在这份预算里做的事，是先写一份隐藏的初稿，再自我审查、修正，然后才给出可见的答案。以前开发者要把温度设为零、采样五次，才能跑通的就是这样一个循环。关掉思考，就连他认为相对容易的 SWE-bench 也会下降五到十个百分点。他们看到的提升，主要来自推理时的计算，外加各家实验室的系统提示词，这些提示词同时也加固了对提示词注入的防御。

Pardeshi 说，通往完全自主的企业级开发之路，仍然绊在有效上下文上。百万 token 甚至千万 token 的窗口已经存在；但如果你既想要能编译的代码，又想避免上下文压力，高效区间仍然在 100k 以下。顶尖的 Claude Code 用户正在做英雄式的事情：编写 CLAUDE.md 文件、插件、MCP、提示词模板，把输出交给 Codex 来审查，并且每三个月就要重新学一遍这些技巧。在他看来，这更像是你要做的那些辛苦工作换了内容，而非十倍的生产力提升。他的愿景是：一张 Jira 工单进去，一个拉取请求出来，并且遵循团队的实践、Figma 设计稿、路线图、现实中的合并冲突、测试和覆盖率，用户无需亲自做那些英雄式的操作。模型会逐渐商品化，产品是真正能跑通的代码。

Blitzy 的一次运行，大部分时间并不在敲代码。Elliott 说，他们花大量时间在规划、理解系统和影响分析上，也就是资深开发者靠在椅背上思考的那一段，然后以 token 能流式输出的速度生成代码，之后又会在质检和递归改进上投入更多。并行度受软件依赖关系的限制：X 必须先构建、编译并通过测试，Y 才能开始。系统不确定时，就默认顺序执行；只有非常确定时，才会并行。这是质量上的偏好，与速度无关。为了迈向完全自主的企业级开发，他们愿意为每一块增量成本花钱，也愿意为每一个增量算法投入精力，因为拉取请求的另一端是人工劳动。在公司的愿景里，开发者应当去解决边界难题，把打包兼容和质检交给系统。在这个愿景下，剩下的 10% 到 20%，就只是系统的一个缺陷。

如果他们还承诺把每一次能提升质量的 API 调用都花掉，那么每行 20 美分看上去可能像个陷阱。Elliott 对此并不担心。如果要达到 100% 的自主，就得大幅增加算力，那他们就会增加；客户在合同期内可以轻松享用成果，之后他们再调整规模。把自主率从 80% 提高到 99%，会创造足够多的新价值，以至于后来的客户非常乐意多付钱。软件开发的劳动市场规模是 1.2 万亿美元，他也不认为世界上已经没有软件能解决的问题了。当价值差距如此之大时，短期定价不该决定技术路线。

典型的企业客户，通常文档很少，测试覆盖也很少。Blitzy 首先处理的就是这两件事，连带的好处是，技术栈里的其他编码副驾驶也会立刻变好。摄入环节会产出一份技术上准确的依赖与变量规格；产品含义则是与客户一起迭代出来的，并不从“请把你们不清楚的事情全告诉我们”开始。从启动到拉取请求，中间没有 Blitzy 的人工环节。这种规模下的智能体无法为了开会而停下。唯一的停顿，是缺少环境变量，或需要访问原始构建并不需要的某个服务。剩下的任何问题，比如两个文件之间反复打架的测试、规格里隐藏的相互矛盾的需求、配置、遗留的质检问题，都会写进一份报告，附上估计的工时，以及应该接手的职能角色。有些客户仍会做双重审查；有些客户出于监管原因，根本不碰代码，直接合并。

从 80% 到 99%，一半靠模型，一半靠人。更高的智能会让系统注意到，两个端到端测试在打架，因为规格要求了相反的东西；然后它会开出两个全部通过的拉取请求，并询问该选哪种取舍。今天的它只会说自己卡住了。与此同时，人类习惯上并不会提前做两三个月的决定。他们往往要到写代码的阶段，才意识到原本想要的是另一种实现方式，所以 Blitzy 搭建了一种方法：用更新后的指导意见来修改现有的拉取请求，并且重跑的时间要短得多。经过一两轮这样的循环之后，客户就会开始在规格阶段就表达意图。“我们比人们想象的更接近了，”Elliott 说。

对 Pardeshi 来说，微调仍然是一场经典的赌博：只在狭窄的应用场景里做，并且收益要超过等待三个月、等下一代前沿模型所能带来的收益；同时要接受自己会失去泛化能力。排行榜有很多漏洞，而且常常是让人类在两段代码里选自己喜欢的那个，那更多是情绪，而非企业层面的成功。在你真正会分配的实际生成任务里，Gemini、OpenAI 和 Anthropic 在 SWE-bench 上看起来可能很接近，但实际差别依然明显。ARC-AGI 就是他举的例子。模型在 ARC-AGI 1 上拿到了 76%；ARC-AGI 2 并没有变难，只是换了一种题型，得分跌到了 20% 以下。一个五岁的孩子在两者上的表现，看起来都差不多。Chollet 所说的学术意义上的 AGI，即适应一个从未见过的模式，与在广泛任务清单上达到人类水平，并不是一回事。所以他看好面向代码的测试时训练，因为编译和测试能提供信号；他也认为这种做法会在一到两年内变得实用，而非现在。

生成代码的安全是共同责任。各家实验室在训练阶段就会测试越狱和拒绝回答；攻击面仍取决于用户是直接与模型对话（比如在 Claude Code 里），还是提交一份 Blitzy 可能采纳也可能不采纳的计划。另一个更隐蔽的漏洞，是知识截止日期。他认为，目前大多数模型的截止时间大约停在 2025 年 1 月；那之后修补过的库，如果系统不去查询，就会被用成过时的版本。有两种实用的防护办法：把已知的攻击向量写成防御性测试，要求每个任务都必须通过；并在拉取请求之前运行 Snyk 之类的 CVE 扫描器。Blitzy 会先跑这一轮预检，并尝试修复发现的问题，让客户不必亲自动手。和开放式聊天相比，代码是更容易防护的情形。

至于劳动力，他按时间尺度来划分。短期内，代码是商品。以前值钱的脚本，现在只是一句提示词。初级工程师未必分辨得出某个脚本会不会毁掉生产环境，所以市场会更看重能做审查的资深人员。中长期来看，工具在理解意图、防止意外结果方面会越来越好，而在 Blitzy 内部，已经在使用 AI 的中级和初级工程师，表现已经达到资深人员的速度。深度、速度和系统知识，越来越多地可以直接从模型获取。资深人员如果过不了“我只相信自己写的代码”这道坎，会很吃力；初级工程师则不必先去“忘掉”什么。公司招了资深、中级和初级工程师，去年夏天还招了高中实习生，让他们把排行榜的运行自动化。现金薪酬他定在 100k 到 300k 美元之间，股权另算，对于合适的人才可以出更高价。而“合适”的标准也变了：一个人可能在全新项目的黑客松上胜出，并不一定是做过很多遗留系统的人。

Labenz 说，他会把这份转录稿变成自己个人 AI 基础设施的待办清单，这大致就是这期节目的用意。测量你实际在用的模型的有效上下文，不要只相信宣传册。在生成代码之前，先把文档和测试覆盖补进代码库，因为这会提高你已经拥有的每一个副驾驶的下限。至少让两家公司的模型相互审查。写规格时要写明取舍，因为系统越强，瓶颈就越会转移到意图上。保留你的质检流程，并要求一份人工完成报告，说明哪些没有完成、为什么没完成，以及还需要多长时间。在合并之前设置安全检查。

Elliott 的结语愿景，与开场时的赌注没有变化。人类开发者应当解决边界难题，并以能颠覆业务的方式运用技术，打包和质检不必操心。完全自主的企业级软件，会先通过模型原始智能到来、通过编排到来，还是通过人们更会表达自己想要什么而到来，这仍是一场悬而未决的竞赛。从这次对话看，Blitzy 正试图把前两者推进到大多数团队认为可能的范围之外，并把第三者变成一个产品循环：规格、拉取请求、精修，然后下一次把规格写得更好。