一篇讲 agent 改 spec 的论文里，100% 这个数字最不值钱。
Agent4Spec 里那个 100%，是语法错误检出率，九个模型里最好的那个做到的。听起来很漂亮。
但它最不值钱。
OpenAPI 的语法错误是可判定的。一段 spec 合不合法，跑一遍校验器就有答案，不需要判断力。所以“检出加自我修正”这条流水线，本质上是一个能对着答案反复改到通过的循环。它当然会有很高的成功率。这是任务的性质，不是模型的功劳。¹
你只要能对答案，就能考满分。
超过 95% 的修正实现成功率，是同一件事的另一面。凡是能被自动验证的东西，就能被自动改到合格。这类数字迟早会顶到 100%。报道它的价值，和报道“编译器能发现语法错误”差不多。
开头的说法太绝对了，收紧一点：它不是没用，它是这篇里最容易复现、因此最不该被当成结论的那个数字。一个可判定的任务被做到 100%，说明这个任务已经被解决了。说明不了做它的东西有多强。
真正有内容的是另一个数：建议的 endpoint 改进，采纳率超过 50%。
这个数字量的不是机器能不能做对，是人愿不愿意点头。
50% 是个奇怪的数字。它像及格线，不像好成绩。论文把它写成正面结果，我能理解，从零做到一半采纳，对一个自动提需求的 agent 来说确实不低。但反过来问一句：剩下那一半为什么被拒？
两种解释。一种是 agent 提的东西一半是噪音，另一半撞上了真需求，这是最乐观的读法。另一种是评审那端的人，点头的成本比摇头低。
后面这种更值得担心。
给 spec 加一个 endpoint 不像改一行代码，它没有即时的故障反馈，加错了要等客户端接进来才知道。也就是说，说 yes 的代价被推后了，说 no 的代价是当下就要跟一个看起来很勤快的 agent 解释为什么不做。人在这两种成本面前会怎么选，不用我说。
你可能会反对说，50% 只是个评估口径问题，别过度解读。这话有道理。我确实分不清那 50% 里有多少是“这条建议不错但现在不做”——那是正常的路线图权衡，不是评审打哈欠。这两种我分不出来，论文大概也分不出来。²
但不管是哪种，它都指向同一个东西：这两条流水线在干的事，性质完全不同。
一条在替一个本来就有主的东西做体检。API spec 有没有语法错误，答案客观存在，谁来看都一样。另一条在替一个本来没主的东西做决定：这个 API 该不该多这个能力，该不该跟着行业领先者补这个功能。
API spec 会烂，通常不是因为没人发现里面的语法错误。你打开手上项目那个 openapi 文件，看一眼最后一次实质改动是什么时候，大概就明白问题在哪了。它不是写错了，是没人负责。它是某次需求评审的副产品，之后跟着代码漂。lint 工具一直都有，spec 该漂还是漂。
所以我不太信“自动校验”能救 spec。它救的是本来就有人管的那部分。真正让 spec 和实现脱节的，是“这个 API 应该长什么样”这个决定散落在很多人手里，谁都不拥有它。
Agent4Spec 的另一条流水线——市场分析、找功能缺口、自动补齐 feature——其实是在给这个没人拥有的东西指定一个代理主人。
这就是它比校验那条线有意思得多的原因。也是它危险得多的原因。校验错了，编译器会告诉你。补功能补错了，可能一年后才有客户告诉你。
我这里可能错了。也许我高估了“有没有主”这件事，低估了纯机械校验在真实项目里的价值——大部分团队的 spec 烂，可能真的只是懒得跑 lint。³
但如果我没高估，接下来的推论是这样：这类工具真正改变的，不是 spec 的质量，是 spec 的产出方式。它会开始像 diff 一样被提出来、被审、被合进去。
走到那一步，值钱的能力就从“写 spec”挪到“审 spec”。从想清楚一个 API 该长什么样，挪到在一个已经写好的提案上判断该不该点头。
培训市场和招聘 JD 现在还在为前一种能力定价。这个错位比“agent 能不能自主维护 spec”值得关注得多。
¹ 注意“最好那个模型”这个措辞。九个模型里最好一个到 100%，和九个都到 100%，是两个结论。论文表述没错，转述的人容易滑过去。
² 两个数据集是人工整理过的，一份通用场景，一份工业场景。通用那份好办。工业那份里的“行业领先者”是怎么定的、参照数据从哪来，我不知道，也不打算猜。只是想指出，如果参照物本身也是人整理出来的，那 50% 这个数就不只量了 agent，还量了整理者的判断。
³ 这个反例我是认真写的：如果 spec 烂的主因真是懒，那自动校验这条线就是主力，市场分析那条才是锦上添花。那我对这篇的评价就得整个倒过来。我暂时不这么认为，但没有强证据。