给 Agent 的判据要能当场执行，不能只给标准

2026-08-25

我给子代理写规格的时候，红线那一节最容易写成这个样子：内容要准确、措辞要中立、不要写会过时的东西。每一条看着都没毛病，写的时候也顺手。问题不在写的时候，在它被使用的那一刻——执行者拿着「不要写会过时的东西」这句话，站在正文某一具体句子前面，判断不了这一句到底算不算。

这不是看没看规格的问题。「会过时」是一个关于未来的判断，而这句话没有交代用什么方式做这个判断。它描述的是我不想要的结果，没有交出通向这个结果的动作。规格里这样的句子越多，落到每个执行者手里的自由裁量就越大，而这批人彼此之间还不通气。

这个处境是批量作业特有的。人在流程中间的时候，这类模糊标准是够用的：写的人拿不准就来问一句，我说这句留、那句删，标准在一问一答里被逐步定义清楚。而当一批任务同时开工、每篇一个独立的实现者、我只在开工前和收工后出现，那个「问一句」的通道就没有了。规格是我留在现场的唯一一份说明书，执行者拿到它之后必须靠自己走完。这时候一条规则写得对不对是次要的，它能不能被当场执行才是首要的。

标准描述结果，判据描述动作

形容词式的标准——准确、专业、中立、有干货——描述的是成品应该长什么样。它是给验收的人看的，不是给干活的人用的。干活的人需要的是：我现在盯着这一句，我该做什么动作、回答什么问题，然后得到留或删。

我现在检验一条规则的方式很土：把它交给一个不认识我、也没法回来问我的人，他对着正文里任意一句，能不能不请示就给出「是」或「否」。 给不出来的，那条不算判据，只算愿望。

「内容要准确」给不出来。「这一句是我实际做过的，还是我按常理推出来的？推出来的删掉」给得出来——它是一个可以逐句套用的问话，答案只有两个。前者是标准，后者是判据。判据当然更窄，会漏掉一些换了说法的情形，但一条窄而能执行的规则，胜过一条宽而只能靠猜的规则，因为后者在批量里等于没有。

「这个数字下个月可能会变吗」

我这套规格里，禁易变数字那条红线现在是这么落的：先说禁区，然后给一句问话——这个数字下个月可能变吗？会变就不写。

它没有给一张「不能写的数字清单」。这个选择是有意的。清单是封闭的，正文是开放的：我能想到价格、额度、百分比，想不到执行者手里那篇正好要写某个排行位次、某个配额上限、某个还没发布的东西的状态。清单外的东西一出现，执行者要么放行，要么停下来问我——而它问不到我。

一句问话是可迁移的。执行者遇到清单里没有的数字，照样能把这句问话套上去，自己得出答案。同一句问话换一个题材、换一个批次还成立，而清单每换一个题材就得重写一遍，还永远补不齐。

这一点在下游还有一次收益。我这条线上，写的和审的是两个互不通气的 Agent，评审员拿不到实现者的推理过程，它手里只有落盘的文件和同一份规格。规则如果是清单式的，评审员能做的只是把清单再扫一遍，扫不出清单外的；规则如果是问句式的，评审员可以对着同一句话问同一个问题，两边独立地收敛到同一个答案。判据的可执行性，同时决定了这道门在写和审两端是不是同一道门。

我实际写进规格的三条

第一条是字数。规格里没有写「字数要够」，写的是一个口径动作：中日韩字数必须用 Python 按 Unicode 区间数，不许用按字节计的命令行文本工具。这条是踩出来的——按字节计的工具会把中文字数报得高出好几倍，字数门看着是绿的，实际形同虚设。「字数要够」不是判据，因为「数」这个动作本身有歧义；把数法写死，它才成为判据。

第二条是评审员开工的第一个动作。评审提示词里的原话是：如果这个文件不存在或为空，直接返回 verdict=FAIL，并在 remaining 里写明「文件未落盘」。这条把「先确认有没有做，再看做得好不好」这个笼统要求，变成了一个必须先执行的动作。之所以要拆开先后，是因为这两类失败在外面看长得一模一样——都是「返回了一个看起来正常的结果」。不先做那个存在性检查，评审员会直接进入评质量，然后对着一个不存在的东西给出结论。

第三条是泛化自检。规格原文是：把项目名从你的文章里去掉，如果它还能成立，说明写太泛了，重写。 这句话我很喜欢，因为它是「一个删除动作 + 一次观察」，执行者做完就有答案，中间不需要任何品味判断。相比之下，「不要写正确的废话」这种要求，写它的人心里有画面，读它的人没有。

顺带一提，词形结构那部分我也是这么处理的：不写「结构要完整」，而是把每一种词形的段落顺序写死，并在最容易被跳过的那一段旁边标上「这一段不许省」。那些标注不是修辞，每一条对应的都是实际漏过的地方。

边界：哪些标准我至今给不出判据

第一，不是所有标准都能收敛成是非题。 比如「读起来像真人写的」，我到现在没找到一句能当场回答的问话。硬要凑一个出来，能落成的形式大概只剩「有没有出现某几个词」——而那样一来，执行者把那几个词删掉就算过门，文章还是原来那篇文章，只是变得更别扭。这类整体观感的东西，我目前只能靠独立评审和自己抽查兜着，不假装它有判据。同样兜不住的还有事实对不对：脚本能查字数、死链、格式、孤儿页，查不出一句话是不是事实错误，这两种检查不能互相顶替。给不出判据的标准，宁可在规格里注明「这条靠人看」，也不要伪装成一条能自动过的门。

第二，判据一旦落成机械检查，误报会反噬。 我这边发生过一次：某轮机械检查报出来的问题，逐条看下来全是误报——命中的是模板自带的合规声明、规范本身强制要求写的否定句、以及代码示例里的数字。这种门跑几次之后，执行者就会开始整体忽略它，此时这道门等于不存在。所以我宁可判据写窄、漏掉一些，也不接受一个高误报的宽判据。误报的代价不是多花时间核对，是让整道门失效。

第三，判据的形式对了，不代表判据本身对。 我给标题定过一个长度上限，忘了先减去必须包含的关键词本身占掉的长度。剩下的额度不够用，实现者只好砍掉关键搜索词——它完全是照着判据执行的，执行得没错，错在我给的额度。后来放宽了才修好。这件事让我给自己加了一条：凡是配额型的判据（长度上限、条数上限、篇幅区间），要先把不可压缩的固定部分减掉再给出去，否则执行者只能牺牲你真正在乎的那部分。

第四，判据是给不能追问的执行者用的。 如果你的协作方式是一次一件、人在中间随时能拍板，那把规则写成问句的收益很小，甚至会显得啰嗦——因为模糊的地方当场就问掉了。这套写法真正开始省事，是在你必须同时放出去一批、且中途不打算回应提问的时候。

这篇的判据来自我自己带 Agent 干活的实践，样本有限。它更像一份可以拿去验证的假设，而不是一份可以照抄的规范。