这条红线防得住什么、防不住什么

一正一反两个真实案例

我们对这条红线的实测结论是:部分生效——能防“凭空编”,防不住“上游丢了当没有”。支撑它的是成稿里成对出现的两个实例:

正面案例(防得住):克制语句。 带约束的写作步在信息不足时,产出了克制的表述,而不是编造补全——红线成功把 AI 摁在了卷宗范围内。这是我们敢把编造当“可防风险”的依据。

反面案例(防不住):URL 误判。 成稿里出现了一句声明:“本课资料中未收录该文 URL”。这句话是错的——URL 在原始资料里明明有,是蒸馏环节把它弄丢了(我们自己的运行留档,日志可查)。写作步严格遵守了红线:“笔记里没有,我就不写,还老实声明没有。”它一个字都没违规,却理直气壮地写出了一个错误事实。

反例的可怕之处:错误穿着“合规”的外衣

看清楚这个反例:你检查写作步,它无懈可击;错误的源头在上游蒸馏,而红线根本管不到那里。这就是约束的能力边界:任何约束只在它的作用范围内有效——红线约束的是“写作步与笔记的关系”,管不了“笔记与原始资料的关系”。

怎么用? 拿到任何一个错误产出时,先问一句:这个错是“编出来的”还是“传导下来的”? 前者是红线失守,加强约束有用;后者是上游丢料,加强写作约束毫无用处——得回上游查。

🔧 动手做:判断四个失效场景(8 分钟)

判断下面 4 个场景各属于哪类失效——A“凭空编”(红线该防而没防住/未设红线),还是 B“上游丢了当没有”(红线正常工作,但错误来自上游)。先自己判断并各写一句理由,再做下面两道测验对答案——其中两个场景的解析就在测验的 explanation 里,另外两个的解析也一并写在那里,别跳过:

1. 蒸馏笔记里没写软件版本号,AI 成稿里写了“适用于 3.2 版”。
2. 原始资料里有一张数据表,蒸馏时漏掉了,成稿写“资料未提供具体数据”。
3. 笔记里写“该方法有效”,成稿扩写成“该方法在 87% 的场景下有效”。
4. 会议纪要原文记了一条反对意见,蒸馏笔记只收录了赞成意见,成稿称“与会者一致同意”。

你会看到:4 个判断和各一句理由,然后通过两道测验核对并拿到全部四个场景的解析。

为什么:排错的第一步是定位失效层。这 4 个场景覆盖了两类失效各自最典型和最隐蔽的形态,做完你就有了一副“先分类再动手”的排错眼镜。