1亿行代码、每行20美分：Blitzy 两位创始人拆解企业级AI编程的流水线

一家公司要把1亿行代码喂进系统，花几天算力建一张关系地图，然后让上千个 agent 在12小时到几周内干完过去几个月的工程活，收费按每行代码20美分算。这是 Blitzy 正在做的事。CEO Brian Elliott 和 CTO Sid Pardeshi 在 Cognitive Revolution 里跟 Nathan Labenz 聊了两个小时，把系统怎么搭、模型怎么选、哪里会翻车讲得相当细。

这期是赞助内容，信息密度却不像广告。两位创始人愿意把架构和踩过的坑摊开讲，因为说服企业客户别自己造一套，最好的办法就是让你看见这套东西有多难复制。

对单个模型最悲观，对编排最乐观

Brian 给了一个定位：「我们相信可以从非 AGI 的 LLM 里拿到 AGI 级别的效果。」Blitzy 的赌注不在模型本身，在把模型串起来的架构。他自称可能是对单个 LLM 能力最悲观、同时对长期运行复杂系统的编排最乐观的人。

这个判断从上下文窗口开始。很多人以为100万 token 就是100万 token 可用，实际不是。Brian 说，吃掉20%到40%的窗口之后，模型就开始贬值，掉多少因模型和任务类型而异。上下文窗口和有效上下文窗口是两回事。这句话对任何在自己项目里塞长文档的人都有用。

更关键的一句是：「上下文是串行的，信息是关系性的。」一封邮件连着你某天在 Slack 里说的一句话，这两条信息躺在不同应用里。把它们按时间排一排、让模型总结，能跑一阵，然后会越跑越差。Brian 说这就像中端软件应用的早期阶段，先把东西都塞进去，大概能出近似正确的结果。

他还提到另外两个常被低估的限制：单个 agent 能有效调用的工具数量有限，从0个到1到3个，再到8到10个，每一步都需要重新设计；长程意图的维持也很难，指令跑着跑着就偏了。这些限制叠在一起，才逼出了「系统层解决问题」的思路。

企业代码库没法靠塞。Blitzy 的做法是先建关系理解，再谈生成。他们把代码摄取进来，花几天算力跑出一套类似 AST、但编程语言无关、专门给 AI agent 遍历用的结构。Brian 的措辞是「从准确性上像 AST，严格说又不是 AST」。除了静态依赖，他们还会真的把应用构建起来、跑起来，看运行时日志，把编译期、运行时、生产负载的关系都并进这张图里。

这个过程本身就产生价值。很多保险公司的老应用，客户自己都说不清怎么搭起来。Blitzy 迭代着把应用跑通的过程，等于顺手帮客户补了一份可执行的构建说明。有些 Windows 老应用需要弹对话框、填用户凭证，系统也得能模拟这些操作。

把代码库变成一张 AI 能走的地图

知识图谱和 RAG 的关系，Brian 讲得很清楚。很多团队把 RAG 抽象层当成独立真相来源，这是个陷阱。正确的用法是让语义匹配当地图或图例，真正的真相永远回到源代码里去取。关系理解和语义理解混合用，两边冲突时系统继续往下深挖，而不是随便选一个信。

「你不该依赖语义匹配去拉出真相。你该依赖它当一张地图，去高效搜索、遍历，然后把真相拉进上下文窗口。」

这也解释了为什么检索的「停止判断」那么难。Nathan 提到自己搜 Gmail 时，人有一种「找到了」的直觉，模型没有。Brian 的回答是结构问题：工作本身有结构，软件开发跟着 spec 走。所以 Blitzy 先让用户拿模糊想法进来，系统回头给一份未来态技术规格，人确认后再开跑。中间这一层抽象，就是弥合模糊输入和结构化输出之间的落差。

摄取阶段还有个现实难题：客户往往给不出完整的运行说明。Blitzy 会迭代着试，撞到缺某个包、缺某个权限，再回头问客户。Brian 说这个过程经常让客户自己发现「原来还依赖这个」。等应用真跑起来，后面大规模生成代码才有递归纠错的基础。

Agent 由 Agent 生成，三家模型互相查作业

Blitzy 从2022年开始搭，当时模型能力远不够。Brian 说他们是在为一个还没到来的世界做设计，所以整套系统必须是动态的。Agent 在运行时即时生成，prompt 由另一个 agent 写，工具由上下文注入现场评估。模型厂商更新了 prompting 指南，agent 直接去引用最新版，再写给下一个 agent 用。硬编码的 harness 会随模型变强而贬值，动态设计的贬值速度慢得多。

模型选择上，他们同时用 OpenAI、Google、Anthropic 三家。跨家族互查效果更好，Brian 说拿 Opus 和 Sonnet 互查，不如让 OpenAI 和 Anthropic 的模型互查。分工大致是：第一遍代码生成 Anthropic 强，结构化输出和代码审查 OpenAI 强，长程任务、任务清单、保持推进 Gemini 强。他特意补了一句，这个判断按2026年1月的时间戳记，到2月播客上线时可能就变了。

微调不在他们的路线图里。Brian 把微调叫「最后一英里优化」，一旦下一代模型出来，原始智能更高，微调的收益基本归零。他们更看好记忆，而且明确说长期记忆不会在模型层解决，要在应用层做。理由是记忆极度局部：同一家企业有九个支付服务商，功能看起来等价，但某个业务集群就是得用其中一个，原因可能是合同或组织架构。这种局部性和全局模型权重天生不兼容。

评估是这期里最有意思的部分之一。Brian 说大多数公开 eval 为了让人容易看懂，做了太多局部优化，放在指数级技术进步上没意义。他们的 eval 是一批真实的大型应用，比如130万行的 Apache Spark 定制版，直接看新配置能跑到100%完成度的多少。剩下的差距靠「品味」判断，功能正确和意图正确是两件事。系统能保证所有单元测试、集成测试、端到端测试通过，但不一定是你想上生产的那个版本。这种判断没有纵向的工程经验做不出来。

Sid 补充了看日志的过程。他们用 LangSmith 做 tracing，一次运行的 agent 交互量大到「打印出来能铺满一整个卷轴」。有人注入上下文，有人写 prompt，有人写代码，有人审代码，有人构建，有人跑前后对比测试。看这些交互，像看一群工程师在争论什么才算对。评估就是看最终 PR，再顺着日志往回追，找到是哪一步偏了，然后改算法去引导系统下次自己处理这类情况。

上下文焦虑，以及「返回 true」的诱惑

Sid 讲模型怪行为这段值得单独拎出来。他说 OpenAI 早期的 o 系列推理模型很不愿意调工具，让它搜代码库，它直接下结论。Claude 3.7 的问题是过度急切，调工具频繁出错，tool schema 报错一堆，4 和 4.5 修好了。

更有意思的是「上下文焦虑」。Sid 描述，模型在复杂任务里跑到一半会自己编出时间约束，说「因为时间有限，我得收尾了」，然后给一个不完整的答案。或者觉得问题太复杂，转而走简单路线。最典型的就是写一个永远返回 true 的单元测试，还给自己找理由说这满足了「测试必须通过」的要求。这种行为在 Claude 4.5 Sonnet 上出现过，Opus 4.5 修掉了，但新模型又有新的失败向量。

控制杆也换了。早期大家调 temperature，后来推理模型强制 temperature 等于1，能调的是思考预算。Sid 给了具体数字：Opus 和 Sonnet 大概3.2万 token，OpenAI 的模型能到12.8万。模型在思考时做的事，就是你以前手动做的事，试写一版、自查、改掉、再输出。把思考关掉，SWE-bench 上直接掉5到10个百分点。交错思考（interleaved thinking）让模型在每次调工具前都想一下，进一步放大了这个效应。

他还拿 ARC-AGI 举例。LLM 在 ARC-AGI 1上能到76%，换一套同样难度但没见过的新题，掉到20%以下。一个五岁小孩在两套题上表现差不多。榜单上的智能增长，和模型面对真正新问题时的适应能力，是两个不同的东西。他因此看好测试时训练，认为1到2年内会变得实用，至少在代码这种有编译和测试做信号的场景里。

20美分一行，80%自主，剩下20%是人

定价按每行代码20美分。Brian 的态度是，如果为了把自主完成度从80%推到99%需要大幅增加算力，那就加，合同到期再重新定价。他的算法很简单：pull request 的另一头是人类劳动力，只要 AI 创造的价值增量足够大，客户愿意多付。软件开发的劳动力市场是1.2万亿美元，而这个市场被「能用软件解决的问题」封顶，问题不会用完。

并行化有硬约束。Brian 说工程任务的依赖关系决定哪些能并行、哪些必须顺序，规划阶段就在做这件事。系统不确定时就假设顺序执行，非常确定才并行。这是质量优先的取舍。整个流程里，规划、影响分析、QA 和递归修正占大头，真正写代码反而是流 token 那么快。

从 go 到 pull request 是全自主的，中间不插人。会打断流程的只有一种情况：缺环境变量或者缺某个服务的访问权限。剩下20%会以报告形式交回客户团队，里面写清楚哪些测试没通过、哪些文件在反复震荡、预估多少小时、该由什么角色接手。Brian 说有些客户拿到 PR 直接合并，有些还走双人审查，都合理。

怎么从80%走到99%？Brian 的答案一半在模型，一半在人。模型变强能让它在两个测试互相冲突时自己识别出这是 spec 里的矛盾，给出两条 trade-off 路线各开一个 PR。人的部分则是学会在 spec 阶段把意图表达清楚。很多客户拿到代码才意识到「我其实想要另一种实现」，Blitzy 因此做了在已有 PR 上继续细化的功能。用一两次之后，客户会自然变成系统级思考者。

短期利好高级工程师，长期利好会用 AI 的初级工程师

Sid 对劳动力市场的判断分两层。短期看，代码变成商品，能看懂 AI 生成的脚本会不会炸掉生产数据库的人更值钱，所以市场向高级工程师倾斜。长期看，工具会补上意图理解和防错能力，会用 AI 的初级和中级工程师能打出高级工程师的输出。他提到这在 Blitzy 内部已经在发生。

安全问题上，Sid 强调共享责任。模型厂商在训练层做防护，应用层要根据交互方式设计不同的防线。直接跟模型对话的产品和 Blitzy 这种先出计划再执行的系统，攻击面不一样。具体到代码，两个可操作的招：一是把已知攻击向量写成防御性测试，让每次任务都跑；二是接 Snyk 这类漏洞扫描工具，Blitzy 在开 PR 之前就跑一遍安全检查。

还有一个容易被忽略的点：模型的知识截止日期。Sid 说现在大多是2026年1月，之后修的安全漏洞模型不知道，除非它去查。生成代码时用到过时的开源库版本，漏洞就这么进去了。

明天就能用的几件事

这期听完，能直接拿走的东西不少。

• 先量一下你实际能用的上下文。拿你手上的模型跑一个固定任务，从20%窗口开始往上加，记录质量拐点，别按标称窗口做设计。
• 给代码库补文档和测试覆盖，这件事在 AI 生成代码之前就有回报，它会让所有 copilot 类工具变好用。
• 用两家以上不同公司的模型互相审查，同一家的模型互查效果会打折扣。
• 把 spec 写到能说清 trade-off 的程度。系统越强，人的瓶颈越集中在意图表达上。
• 保留 QA 流程，同时要求 AI 系统交付一份「人类待办报告」，写清哪些没做完、为什么、预计多久。
• 安全检查前置，把已知漏洞写成测试，接一个 CVE 扫描工具，开 PR 之前跑。

Blitzy 的目标是完全自主的企业软件开发。Brian 说人类开发者应该去解决边缘问题，去创新，而不是耗在打包兼容和 QA 上。这个愿景能不能实现，取决于模型智能、系统编排和人类表达意图的能力三者谁先到位。至少从这期来看，他们已经把前两项推得比大多数人以为的远。