w4.5概念⏱ 约 5 分钟

分工原则:模型审内容,脚本审结构

学完能把每条检查项分派给正确的审核方,复合型检查会拆层

🔎 最后验证 2026-08📚 来源:课程产线设计留档与两门课的真实运行日志、事故记录(作者一手留档)

为什么学这个

前几节你已经攒齐了三样东西:换角色的审核提示词(w4.2)、审核盲区标注(w4.3)、第一个机械闸门(w4.4)。但手里工具多了,新问题马上出现:下次产线跑起来,一条具体的检查——比如“交叉引用对不对”——到底该丢给模型,还是写成脚本?

派错了,不是效率问题,是漏检问题。派给模型的结构检查会掉进 w4.3 讲过的盲区;派给脚本的内容检查,脚本根本读不懂。我们的产线在两门真实课程的生产留档里撞出来一条收束原则,这一节把它讲透:模型审内容,脚本审结构,两者不能互相替代。学完这节,你手上的翻车检查清单每一条都会有明确的责任方。

💡 打个比方

品酒师能尝出这瓶酒的层次和缺陷,但你让他“尝”出瓶里是不是正好 750 毫升,他做不到;量杯一量一个准,但量杯永远量不出这瓶酒好不好喝。

审核也一样:有些事需要“理解”,有些事只需要“数”。让品酒师去量毫升、让量杯去评酒,都是把活派错了人。

模型审内容:需要“理解”的活

先看模型那一侧能干什么。断言有没有依据支撑、表述是不是在偷懒、逻辑通不通——这些判断的共同点是必须先读懂语义。“这句话是不是在编造”没有任何机械规则可以判定,只有换了角色、换了立场的模型(w4.2 的审核角色)能审。

反过来说,脚本在这些事上完全无能:它能确认“正文里有 5 条要点”,永远确认不了“这 5 条说得对”。我们产线的三个机械闸门(语法修正、编译复验、结构体检)没有一个碰过内容质量——不是没写,是写不出来。

再看另一侧。总数对不对、编号格式合不合法、编译过不过、引用的那一节存不存在——这些检查的共同点是答案唯一、规则可以写死。节数等于大纲数,就是一条 grep -c 的事。

这类活必须交给脚本,因为模型这一侧有两个硬伤:

都看到这了，打个赏呗！