1. Agent 开发的真实困境我在做 Agent 项目时有一个越来越真实的痛点一个挺大的功能Coding Agent 几个小时就写完了。有 spec、有代码、有单测有效果截图。代码跑起来看着像模像样——结构清晰、命名规范CI/CD 都能通过核心流程也都没问题。然后噩梦开始了。我得去验收它把它能走的路一条条走完把它该守的边界一个个试过把它可能崩的角落一处处抠出来。最要命的是哪怕我吭哧吭哧验上一两天心里依然没底——那些我根本没想到的情况它真的扛得住吗而恰恰是这些没被想到的角落才是日后线上事故的源头。最后的账单往往是这样的AI 写它只要几个小时我验它要花上一两天。而一两天之后我依然不敢拍胸脯说它是对的。写得飞快验得要死。作为一个自认为比较 AI Native 的团队我认为这不是我们独有的问题而可能是行业的普遍困境。2. 大家都在想怎么做却没人管怎么验你有没有发现这几年我们折腾的所有工程其实是一条不断往上爬的阶梯——先是Prompt Engineering研究怎么把话跟模型说对然后是Context Engineering琢磨每一步应该把哪些正确的信息喂给模型再然后是Harness Engineering想着怎么给它装个合适的环境配上趁手的工具最近最火的是Loop Engineering干脆别一句句喂了写个循环让 Agent 自己跑、自己推进、遇到问题自己想办法解决最后交付个结果。这四个阶段是一个持续利用模型智能的提升、并把人类价值不断上移的过程但是它们本质上全是在解决同一件事——怎么让它跑得更好、更自动。却没有任何一级认真回答过那个最朴素、也最要命的问题它跑完了跑的挺快看着还行但是我怎么知道它到底做的对不对、好不好这个一直被我们用人肉盯着看糊弄过去的窟窿今天基本变成了 Agent 开发的主要矛盾请允许我效仿硅谷的风格也造个词 ———Verification Engineering 验证工程叫啥名不重要意思大家懂的都懂~。接下来的内容就是我想好好聊一聊为什么我觉得 Verification 这个重要以及我认为的 Verification Engineering 应该长什么样。3. 这不就是 Evaluation 吗我猜你大概率会立刻皱眉你说的 verification不就是现在满大街的 eval / evaluation / observability / tracing 那一套吗LangSmith、Langfuse 们早做了。这个问题我自己也纠结过很久。最后我的判断是verification 包含 evaluation但它是一个更高维的视角。evaluation 关心的是术层面的事怎么评估模型和 Agent 的性能、怎么追踪每一步发生了什么、怎么把整个过程的可观测性做扎实。这些都极其重要是地基缺了它寸步难行。但 verification 关心的是一个更要命的问题对到底是什么evaluation 告诉你它做了什么、性能如何——成功率 87%、P95 延迟 2.1 秒、这一步调了哪个工具从哪里取了 Memory。verification 要尝试回答它做出来的这个东西是不是我想要的那个好东西。区别在哪前者可以外包给一套工具和指标后者外包不掉。因为什么算好这个标准的源头是一个 builder 对产品的审美。所以我更愿意这么说evaluation 是测量verification 是判断。测量可以被标准化判断是一种品味的表达。一个再牛的 eval 平台能精确告诉你成功率多少、延迟多少、哪一步用了什么工具但它永远替你回答不了那句真正要命的话——这东西做出来到底 UI 好不好看功能好不好用是不是我心里真正想要的那个版本这就是为什么我说 Verification Engineering 站得更高它把 evaluation、tracing、observability 这些看得清的能力当底座然后在上面架起那层真正稀缺的东西——把一个 builder 的产品审美工程化、规模化地表达出来让机器替你反复执行这种判断。记住这一层。后面所有的话都会绕回到它。4. Verifier is the bottleneck我们都幻想过那个画面一个 Agent不用你守着自己就把活儿干了。但你冷静想一句话——一个 loop 真正有价值当且仅当它能脱离你自主运行而它能脱离你又当且仅当它自己能判断什么时候算做完、什么时候算通过、什么时候算失败、以及失败了该怎么修。这个做判断的角色就是verifier验证者。道理其实挺糙一个 loop 跑得再花哨只要背后没有一个你信得过的 verifier你就还得乖乖坐回屏幕前盯着——那它压根没把你解放出来。所以我现在越来越确信Loop 真正的瓶颈从来不是怎么跑起来而是怎么判断对不对。Verifier is the bottleneck。而这里头藏着一个特别残酷的不对称对少数任务验证比生成便宜——测试通过、CI 变绿、编译器接受干脆利落的 0 和 1。这种叫可验证目标loop 在这儿如鱼得水。对大多数真正有价值的工作验证和生成一样难甚至更难这个产品策略好不好这次重构真的更干净吗这个页面用户点进来会不会觉得别扭这些问题你没法塞进一个单元测试里。所以 Loop 工程真正难啃的骨头根本不是把循环搭起来而是怎么造出可验证性——怎么把一个模糊的目标翻译成机器能自己检查的标准。一句话Loop 真正的约束从来不是模型能力而是人类在输出边界上的验证带宽。Claude Code 一晚上能给你提 20 个 PR发 3 个产品版本但你 review 不完。瓶颈不在它那头在你这头。说白了——你不 scale !!!5. 残酷的可验证定律为什么 Coding 已经大结局顺着这个逻辑往下推我想起了业界比较共识的可验证定律一项能力会不会先被 AI 攻克取决于它的验证成本有多低。为什么 Coding 是第一个走到大结局的赛道因为它把可验证的三大要素全占齐了海量训练数据——全世界的开源代码摆在那儿且非常结构化好采集好清洗完美的运行环境——编译器、测试、CI一个能一键判对错的真实世界完善的评估指标——测试通过率、各种 benchmark。于是一旦像 Anthropic 这样的玩家把飞轮转起来——生成 → 用真实环境验证 → 拿验证结果再训练 → 模型更强 → 用的人更多 → 数据更多——这轮子越转越快后来者几乎找不到弯道超车的机会。所以 Coding 赛道已经大结局了接下来我们应该 bet on what?6. 把验证成本打下来如果可验证定律成立下一波机会就是名牌了哪里的验证还很贵哪里就是下一个战场。而最后赢的人不是把模型做得更聪明的人是把验证成本打下来的人。可前面说过那些最值钱的东西——产品好不好、UI 对不对、体验顺不顺——根本塞不进一个单元测试。这种品味级的判断传统手段够都够不着。那怎么办我的设想是让 verifier 成为你产品的原生用户直接住到产品里去玩它。所以也许我们需要考虑重新捡起这些技术Browser-Usefor WebMobile-Usefor AppComputer-Usefor PC/Client有了它们verifier 就不再是隔着代码指指点点而是能像一个真实用户那样亲手打开你的产品一步步点下去亲眼看到结果长什么样。我心里那个产品的样子是这样的让一个 verifier 住进你的 Agent 里成为一个常驻的资深 Pro 用户。它不知疲倦天天用你的产品像最挑剔的老用户那样验收每一个新功能持续告诉你这儿的流程断了、点完这个 button 页面崩了、新版 UI 不如以前的风格好、甚至——你这回的改动其实让产品变差了。它干的事本质上就是把第三节那个外包不掉的难题第一次撬开了一道缝把对产品品味的验收——这件最贵、最依赖人、最不可能标准化的事——变得可以规模化。7. 别追求 day 1 就完美能让验收没那么痛就值钱我猜你又要反驳了品味、体验这种东西怎么可能完全自动验证对完全做不到。但这恰恰是我最想强调的一点你根本不需要 day 1 就实现端到端的完美验证。验证从来不是一个全有或全无的开关它是一条成本曲线。如果你今天能把验收一个功能的时间从两天压到半天能把我盯着屏幕一个个点 case的 80% 交给那个住在 Agent 里的 Pro 用户只留最后 20% 给我拍板——这就已经是天大的价值了。在这条曲线上每往下挪一格都是真金白银的杠杆。别被做不到完美吓退先去做让它没那么痛。8. 尾声一场把人逼向纯粹品味的撤退回头看这条阶梯Prompt 工程化了怎么说Loop 工程化了怎么跑而 Verification 要工程化的是什么算对。当 AI 把做出来这件事变得几乎免费人类手里其实只剩下最后一件外包不掉的事判断什么是好的什么是值得的。也就是—— Taste。所以 Verification Engineering 最终极的样子绝不是用更多测试去把 AI 框死而是想办法把人的品味也变得可以规模化地施加给机器。而 Browser / Mobile / Computer-Use 这些手和眼就是让品味能下沉、能落地、能被一个 verifier 反复执行的那条通道。这是一场漫长的撤退也是一次彻底的解放我们终将从逐行验收里抽身最终人的最大价值就是——决定什么值得做而把它到底做对了没有这件苦差事交给一个住在 Agent 里、比你还挑剔的资深用户。构建已经免费了。下一阶段看谁能把验证变得越来越容易吧~