Simon 的套话检测器只高亮不拦人，我那套敢拦，10 篇稿子一篇没出来

哈喽，我是飞飞。

先撇清一下，免得你觉得我又在炒冷饭。这条线上我写过几篇：一篇讲我攒了六十几条规矩删 AI 腔，一篇讲哪几种 AI 味我死活不留，还有一篇讲写 skill 的时候规则太宽会反咬。那几篇讲的都是怎么把规则写好。这篇不碰这个。

这篇只问一件事：你辛辛苦苦攒的那些检测规则，到底该不该有权把你的活拦下来。

我是被一张账单逼着想明白的。

他那个工具只高亮

事情起头是 Simon Willison 前两天扔出来的一个小玩意儿。

他用 Fable 5 顺手 vibe code 了一个网页应用，说人话就是没怎么正经设计，边聊边让模型给写出来的。功能特别单一：你把一段文字贴进去，它把大模型最爱用的十种套话给你高亮出来。

被它点名的有 no fluff, no filler, no jargon 这种链式否定，有 sit with that，有 you already know，还有 worth naming。你要是觉得英文没那么直观，换成中文的「让我们一起来看看」「值得深思」「这不仅仅是一次尝试」，那个塑料味立刻就对上了。

我盯着它看了半天。真正让我停下来的，是它的动词。

Highlight。高亮。

它不打分。稿子及不及格它不管，句子该怎么改它也不插手。它就把可疑的地方涂个颜色，剩下的全交回给你。

我当时心里咯噔一下。因为我那套东西，走的是完全相反的路。

我给检测发过阻断权

我写文章是一条流水线在跑：拉资讯、选题、调研、写稿、润色、评阅、配图、分发，十几个环节各归各的 skill 管。

里头有两层检测。

底下一层是硬扫描，靠 grep 硬查。中文那种长横破折号必须清零，那玩意儿是 AI 中文最扎眼的指纹，撒手不管一篇能塞进去二十几个。对仗句式全文最多留一处。三连否定的排比不许排。小标题超过十二个字或者带括号，揪出来重写。中文字数拿正则数一遍，卡在两千到两千五。这层规矩攒到现在一百四十多条，是跟着一百二十多篇稿子一条条长出来的。

上面一层是评分。一层专查 AI 味，从结构模板化、表达空洞、细节缺失这些维度打百分比；另一层拿刘润那套写作心法的六个维度打分，满分一百。

出事的是我给上面这层配的权力。

我当初的设计是：评分低于 80 就自动打回去重写，最多循环三轮，三轮还不达标，整条流水线停在那儿等我裁决。

写的时候我觉得这设计特别负责任。质量不达标，凭什么放出去？

那次批量跑成了空转

真正教育我的是一次批量。

那天我一口气排了十篇稿子进流水线，想着挂着让它跑，我该干嘛干嘛去。

回来一看傻眼了。

十篇里八篇全部撞到了三轮上限，一动不动卡在那儿等我拍板。我离开之前它们在跑，我回来它们还在原地，只是账单涨了：整个批次消耗六十四次 agent 调用，烧掉大约两百七十万 token。

交付了几篇？

零。一篇都没出来。钱花了，时间过了，机器忙了大半天，产出是空的。

更难受的是我一篇篇翻分数的时候。那八篇里好几篇卡在七十七、七十八，就差那么两三分。而给出这两三分的，是一个模型的主观判断。它换个时间点重跑，给到八十一也不奇怪。就为这么一个会飘的数，八篇稿子全压在那儿动不了。

说白了，我拿一个会抖的主观分数，接上了一个能停掉整条产线的开关。

硬规则和软评分该分开

复盘完我改了设计。但我动的地方跟阈值无关。

我一开始的本能是把 80 降到 75。降完琢磨了一下，这是治标不治本，下次照样有稿子卡在七十三。

真正该动的是权力。

后来的规矩是：评分环节只做一轮定点重改，改完不管多少分一律放行。总结里如实写一句「初评 73 分，复核 82 分」，或者「初评 76 分，复核 78 分」。分数照给，照实说，但它不许拦人。

这么改完，我才把两层检测的区别想清楚。

底下那层 grep 硬规则，判的是客观事实。一篇稿子里有没有破折号，小标题有没有超过十二个字，这些事没有商量余地，机器数得清，也不会今天数出一个明天数出另一个。这层我至今还留着阻断权，它揪出来我就得改。

上面那层评分，判的是主观质量。同一篇稿子，模型今天给 79、明天给 83 都算正常。把这种会抖的东西接到阻断开关上，就是给流水线埋雷。

一句话，能被机器判死的，可以有权拦你；只能被机器估个大概的，只配给你提个醒。

Simon 那个工具，踏踏实实就站在后面那一类里。它清楚自己认出来的是「可疑」而非「有罪」，所以它只涂色。

漏检和错拦差着量级

还有一笔账，我当初压根没算过。

漏检和错拦，代价根本不在一个量级上。

漏检的代价是什么？一篇稿子里混进去两句 AI 腔，读者读着觉得这段有点塑料。难受，但天塌不下来，下篇改进就是了。

错拦的代价是什么？整条产线停摆，十篇稿子一篇出不来，两百七十万 token 打水漂。

这两种错差着好几个数量级。既然差这么多，默认那一档就该偏向放行，而不该偏向拦截。

我以前把「宁可错杀不可放过」当成严谨。现在我觉得，那只是没算过错杀的账。

顺便说个更早的坑，正好是同一个道理的另一面。我那条查对仗的 grep 规则写得太宽的时候，会把「它是不是天天重复、规则是不是清晰」这种正常疑问句当成对仗句揪出来。「第一反应」被当成列表编号，「最后一步」被当成收尾套话。每次我都得人工判一遍，这是真命中还是误伤。假如这些误伤当年也带着阻断权，我大概每篇稿子都得跟机器吵一架。

该拦的地方还是得拦

话说回来，我不是在讲检测就该全线放行。

有些闸门我攥得死死的，一点没松。

比如发公众号那个环节。我把它做成必须我手打指令才触发，默认整个跳过。哪怕前面所有检测全绿、评分给到九十，它也不会自己把稿子推出去。

区别在哪儿？

发布这个动作是不可逆的，而且是对外的。推出去就收不回来了。这种地方我宁可多敲一句话，也不接受任何自动化。

而重写一遍稿子这个动作，可逆、对内、随时能补救。给它配阻断权，纯属浪费。

所以那把尺子量的不在这件事重不重要，在它出了岔子能不能补救。补不回来的，闸门焊死；补得回来的，让它先过去。

今天先给哪条降权

如果你手里也攒着一套自己的检测规则，不管是写作的、代码的，还是 agent 流水线上的，今天有件小事可以做。

把规则摊开，一条条问：这条判的是客观事实，还是主观好坏。

判客观事实的那些，留着阻断权没问题。判主观好坏的那些，降级成提醒，只报数，不拦人。

再顺手问一句：这条要是误伤了，我得花多大代价才能救回来。救不回来的，才配当闸门。

说实话，我这套东西现在也谈不上磨好了。规则还在一篇篇往上加，误伤还在偶尔发生，我也不敢说这个平衡就找准了。但至少那条产线不会再因为一个七十八分把自己锁死。

绕了一圈我才明白，检测这件事真正难的不在把规则写多严，在想清楚它到底该不该有权拦住你。Simon 那个只会涂色的小工具，早就想明白了。

你手里那套规矩，有没有哪一条其实不配有拦人的权力？或者反过来，你被自己定的规矩卡住过没有？评论区聊聊，我挺想知道别人是怎么划这条线的。