Vaibhav Gupta 用 slop 对抗 slop

Vaibhav Gupta 的题目叫 “fighting slop with slop”。这个标题很口语，但讲的是一个严肃问题：AI 产出的粗糙内容，能不能用另一套 AI 工具链来治理。

原视频：https://www.youtube.com/watch?v=htM02KMNZnk

slop 不是情绪词，是工程对象

很多人说 AI slop，通常是在表达厌烦：代码看着能跑但不优雅，回答很满但不准确，工具调用很勤快但没有抓住问题。Vaibhav 的做法不是停在抱怨，而是把 slop 变成可观察对象。

他讲 BAML 和一套围绕 LLM function 的工具链。核心思路是：不要只靠人肉 review 模型输出，而是把输出变成可记录、可比较、可测试、可 A/B test 的对象。

转录里有一段很典型：如果你能发现语言特性，能比较哪个 skill 用更少 tool calls、哪个出错更少、哪个结果更正确，你就可以更确定地改进系统。这里的重点不是 “slop” 这个词，而是从主观评价变成可测量反馈。

AI 输出也需要软件工程工具

这和普通软件工程很像。我们不会只靠肉眼判断所有代码是否可靠，而是靠 test、lint、type check、trace、profiling。AI 输出也需要同样的工程化。

如果你不知道 prompt 哪一步坏了，工具调用哪里错了，schema 哪个字段不稳定，模型输出为什么不可 parse，你就无法改进系统。你只能继续调 prompt，或者换一个更贵模型。

BAML 这类工具的价值，是把 LLM 调用从 “一段神秘文本” 拉回工程对象。你可以看结构、看调用、看错误、看对比。能定位，才谈得上修复。

用 slop 对抗 slop 的边界

当然，这里也有一个风险：用更多 AI 工具治理 AI 输出，可能制造更多层黑盒。Vaibhav 的方法之所以有价值，不是因为又套了一层模型，而是因为它把评估和观察变得更具体。

如果第二层 AI 只是说 “我觉得第一层不错”，那没有意义。它必须产生可检查证据：字段是否符合 schema，测试是否通过，工具调用是否命中，输出是否能被下游消费。

我的理解是，AI 应用成熟的标志，不是输出变得漂亮，而是错误变得可定位。不能定位，再强的模型也只是黑盒。能定位，software factory 才能从玄学调参变成工程迭代。

Bun 的背景让这场更有说服力

Vaibhav 的例子不是轻量玩具项目，而是 Bun 这种涉及运行时、编译器、类型系统、codegen、并发语义和多语言 FFI 的工程。这样的项目如果说两年没做传统意义上的逐行 code review，会让人警觉。

但他不是说“我们完全相信 AI”。恰恰相反，他的核心是建立一套足够密的观察和检查系统，让 AI 产出的粗糙部分被另一套工具链捕获。这里的重点不是放弃工程标准，而是把标准更多写进机器可执行流程。

这和软件工厂主题很贴。生成代码会越来越便宜，真正稀缺的是判断哪些生成物可信。Vaibhav 说 fighting slop with slop，本质是用便宜自动化覆盖大量低级检查，把人从机械 review 里释放出来。

关键是让 AI 产出可比较

如果一个 prompt 版本生成的结果只是“看起来还行”，团队很难进步。你需要知道它比旧版本好在哪里：更少 tool calls？更少 schema 错误？更少 runtime failure？更容易被下游解析？更少人工修正？

BAML 这类工具把 LLM 调用变成可比较对象。它让输出结构化，让失败可记录，让不同 skill 和模型可以对比。这样团队才能像优化软件一样优化 AI 流程。

这套方法不适合偷懒

最危险的误读是：既然 slop 可以对抗 slop，那就可以降低标准。实际上刚好相反。你只有标准足够明确，才能把检查自动化。没有标准，第二层 AI 只会给第一层 AI 背书。

所以这场对团队的要求很高：你要先定义什么是坏输出，什么是可接受，哪些字段必须稳定，哪些错误绝不能进主流程。AI 工具链越复杂，标准越要清楚。

来源与说明

本文基于 AI Engineer World’s Fair 2026 Day 1 主舞台视频转录、官方日程信息，以及本地 AI engineering 知识库整理。文章不是逐字稿，而是按单场分享的主线、上下文和工程启发重写。