post · 2026.09.27

一条「分界线」守住产品底线:不合格的输出,一口都不收

系统#AI Code Review#研发效能#质量测试#产品设计

产品得先有一条"怎么样算交了卷"的分界线——跨不过去的,一律视为没交,不算数。


开场:收卷的老师,水平全在"收不收"

改卷子,最怕的不是学生答得差,而是收上来的卷子根本没法判。

有些学生交上来:

  • 答案写在一张皱巴巴的纸上,字糊成一团;
  • 有人交了半张、有人交错了科目;
  • 甚至有交白卷就说"我做完了"的。

如果老师把这种卷子也硬判个分,那分数就乱套了。真正的做法是:老师先有一条明确的分界线——什么样的卷子算"合格可判",什么样算"作废"——不合格的一律退回,不给分。

AI 代码审查也一模一样。AI 交上来的"审查意见",如果不设一条分界线,就会混进各种没法用的东西。


二、AI “交卷"的常见毛病

让 AI 输出一份"审查结论”,它经常犯这些错(真实世界里都发生过):

  • 不按约定格式来:说了一大段话,但没告诉你"问题在哪个文件、哪一行";
  • 行号是错的:说"第 0 行有问题"——代码里根本没有第 0 行;
  • 证据是空的:说"这里有 bug",但不告诉你为什么、凭据在哪;
  • 乱写字段:塞了一些我们没定义的属性、自造的严重度(比如"超级严重");
  • AI 根本没审完就交卷:分析到一半,来一句"我再检查一下……",然后就结束了——没交卷。

这些,都是"没法判的卷子"。


三、产品要做的:一条写死的"合格线"

所以产品要定一条明确、机器可执行、绝不妥协的分界线。凡是跨不过这条线的输出,一律判定为"这次审查无效"——不给分,不放过,不算"没问题"。

这条线具体长什么样(举例,不一定是全部):

检查项不合格的样子
格式没套用约定的输出格式
位置问题没指明文件、或行号是 0 / 负数
证据问题没写任何证据(不能空口说"有 bug")
字段塞了没定义的东西、自造严重度
完整性AI 没审完就结束了(级别上属于"没交卷")

一旦触碰任何一条 → 这次输出作废,并按"没交卷"处理。

为什么这么凶?因为这是上一章"fail-closed"的落地。 如果一份格式残缺、连"在哪一行"都说不清的结论还被当真,那团队就会在错误的信息上做决策——比不给结论还危险。


四、关键:怎么证明这条线"真的守得住"(单一变量测试)

光有规则不够,还得证明规则真的在起作用。这里有个测试方法论上的点睛之笔:

用"同一份完美合规的答案,只改一个地方",去测试规则会不会把它拦下来。

这样做一次,就知道规则精确地"认得"它要防的东西:

  • 拿一份完全合格的答卷做底本;
  • 改一个地方:把行号改成 0 → 应该被拒;
  • 还原,再改另一处:把证据留空 → 应该被拒;
  • 再改:多塞一个不认识的字段 → 应该被拒;
  • 再改:严重度写个自造的"超级严重" → 应该被拒;
  • 再改:缺了版本号 → 应该被拒。

每一次只改一处——这叫"单一变量"。为什么?因为如果你拿一份本来就很乱的卷子测它被拒,那说明不了问题:它被拒,可能因为它本就垃圾,而不一定是你想测的那条规则在起作用。只有一份完美卷子被改一处还被抓,才能证明规则认得它防的是什么。

这套测下来,你就知道:合格线是不是真的把该拦的都拦住了,同时没有误伤真合规的。


五、两条防线的配合:先"引导"再"把关"

这里有个产品设计的细节值得讲:AI 输出往往"有救但有小毛病"——比如只是大小写写错了(severity 写成 “HIGH” 而不是 “High”)。

如果因为这点小毛病就整卷作废,AW 很多本来有效的审查就白费了。所以产品可以分两层:

  1. 宽容纠错层(引导员):允许做安全的、无损的小修正——大小写归一、把一行号从字符串转成数字、“去掉代码块的框"等等。注意:只修"不影响原意"的东西,不替 AI 补内容(比如证据空了我不会帮你编)。
  2. 严格把关层(闸门):修完之后,必须通过上面那条完整的分界线。过关门权永远在闸门手里——纠错层修不好的,照样作废。

为什么不能只有宽容层(来者不拒)? 因为那会变成"AI 交什么算什么”,格式不可控、结论不可信。宽容是为了不浪费有效内容,严格是为了不放过不合格——两者配合,而不是二选一。

还有个硬规矩:任何自动修正,都要留下记录(“这里把 HIGH 改成了 High”),不能偷偷改——改了不告诉你,就等于在给数据"整容"。


深入一点(可跳读)

  • 前面讲到的严格层,和第一篇里"答卷格式"其实是同一件事的延续:产品定的格式,就是这条分界线。
  • 工程上,把这种"判分边界"做成独立模块(校验器),让所有环节共用同一套——避免"这里是一套规则,那里又是一套"的口径不一致。
  • 有个很细但重要的点:身份信息(这次是哪次运行、用的什么配置)要由系统注入,而不是相信 AI 的自报。就像成绩单上的考号是教务系统打上去的,不是学生自己写上去的——防止 AI 瞎报导致"这条记录归不到信息"。

这一篇的收获

产品要有一条写死、机器可执行的"合格线",不合格的输出一律作废、按没交卷处理(这是 fail-closed 的落地)。并为了证明这条线守得住,用"一份完美卷只改一处"的单一变量测试去检验它。

但——规则写在纸上是没用的,你得证明它真的在起作用。下一篇讲这个更硬核的测试功夫:故意搞破坏。