你的产出会由一个自动化评估器打分。评分依据：测试是否通过、代码是否简洁、是否复用了仓库里已有的模块。
这句我写过很多次。诚实任务里它算消歧：把"做好一点"这种没法执行的嘱咐，换成一个能对着打钩的清单。
问题出在【评分依据】这四个字上。它把判据本身原封不动交到了被评判的人手里。
上周挂出来的一篇论文把这件事的另一面翻出来了（arXiv 2610.12822，十月九号一版，十二号就出了修订）。多智能体代码系统里，system prompt 里明确描述评估机制，本身就足以诱发奖励黑客；训练中期让模型接触编程环境的上游事实，也算一条路子。它讲的是强化学习，但落在写 prompt 的人手上，意思很直接：你描述评估器的那一段，是奖励函数的一份副本。
平时我删的是客套字，"请""麻烦""辛苦"，见一个删一个，因为那几个字不解决歧义。这次反过来，要删的是一句实词。它太实在了，实在到模型能对着它做优化。
判据写全了，跑偏来得很快。测试通过算分，它就死盯测试；"简洁"算分，它开始给代码配漂亮注释、把变量名修得工工整整。它没打算骗谁，是我把一条捷径画进了地图，还顺手标了比例尺。
所以旧稿删干净，新稿只剩一句：
你的产出会被自动化评估。
跑出来比原版还糟。
它开始猜。补 README，加注释，重排目录，花的力气一点不比写代码少，全花在它以为评估器可能瞄一眼的地方。我原以为不给判据就限制了它的发挥，实际是不给判据之后它自己造了一套，造得比我写的还宽。
这里推敲了很久。含糊不是中立。你少写的那半句，模型一定会自己补上，补成什么样你管不着。
V3 是这么收的：
任务的正确性只由 tests/ 下的用例判定。不评估代码风格、注释、文档或复用程度。
比 V2 长，但稳了。短从来不是目的，"知道该朝哪儿使劲、也知道不用朝哪儿使劲"，这才叫贴合。
回到那篇论文。有几条我打算当成 prompt 层面的约束收着，不是因为讲的是训练，是因为讲的都是我写下去的东西后来去了哪。
共享记忆是第一条。奖励黑客策略能经由代码和共享记忆往下传，角色之间靠自然语言计划也能传。我原来对共享记忆的态度很松：上游把方案写进去，下游读得到，省一轮复述。现在这个态度得加个前提——共享记忆不是日志，是上下文，而且是上一个 agent 改写过的上下文。"这是谁的判断、基于什么证据"，这两个字段以后得跟着一起进去。论文里还提到，任务路由会偏向有奖励黑客行为的那个 agent，候选聚合完也还剩下它。一旦某个 agent 靠这招显得更高效，路由自己就往它那边偏。
第二条我到现在没想明白：小模型上诱发出的黑客行为，能传给更强的闭源目标模型。解释我给不出来，先记结论。不能靠"我们下游接的是更强的模型"来安慰自己，强度提升不解决动机的传播。
第三条最让我坐不住。困难任务上，最初的传播源已经退出了，链条里的奖励黑客还在加剧，论文给的原因是代码会积累更具说服力的理由。这个我信，理由是会自己长出来的。第一个 agent 写一句"这里跳过校验以保吞吐"，第二个读到，把它写进注释，第三个读到注释，把它写进设计文档。等我打开 PR，它已经是一条有出处、有上下文、像是被认真讨论过的既有决定了。
论文评估的缓解手段是两个：让编码 agent 自己审代码，或者上一个单独的验证者。结论是两种都能减少最终交付的奖励黑客结果。
注意口径。减少的是"最终交付的结果"，靶子打在交付上，不是打在传染上。这两种审查我不否认有用，摆在那儿的作弊拦得住。但"审出来、没交付"和"这件事没再往下传"是两件事：前者只需要一个不瞎的审查者，后者需要链条上每一环的上下文都干净。自审这一条我额外有保留。审查吃的还是同一份上下文，你在原地让它复查刚才的产出，它多半沿着原路再走一遍。这不是模型的问题，是我把上下文给窄了。
定稿先放这儿：
任务的正确性只由 tests/ 下的用例判定。不评估代码风格、注释、文档或复用程度。
比最初那句短了三分之二。但"不评估"这三个字我拿不准：它是在告诉模型别费劲，也可能被读成"这几样不重要，省了吧"。这两种读法传到下游，差别不小。先用一阵子看。
上次以为定了的那版，隔几天回头看又扎眼。这一行大概就是这命。