w3.2概念⏱ 约 6 分钟

非法编号 4.2b:格式约定是怎么被悄悄突破的

认识隐性格式契约,学会把“默认它懂”的规则写成明文并逐条核对

🔎 最后验证 2026-08📚 来源:本课产线的一手运行留档:非法编号事故的日志与重编号修复记录

为什么学这个

上一节的 41 变 47 事故里,还藏着一个更隐蔽的问题:模型新增的那些节,编号写的是 4.2b、6.5a——数字后面挂了个字母。

单看,这编号还挺聪明:不打乱原有数字编号,像法律条文的"第四条之二"。但它一进下游系统,直接把入库解析撞成了报错,还连带撞坏了 20 处交叉引用。一个"合理发挥",赔进去三轮返工。

这一节讲的是一类你迟早会撞上的问题:你以为不言自明的格式,在模型眼里是可以自由发挥的空间。学完这节,你会知道怎么把这类"默认它懂"的规则变成防得住的规则。

💡 打个比方

小区门牌号都是"4 楼 2 号"这种格式。某天有住户自己在 4 楼和 5 楼之间搭了个阁楼,挂了块牌子:"4 楼半 2 号"。他觉得挺合理——确实在 4 楼上面 5 楼下面嘛。但快递系统直接懵了:地址库里根本没有"楼半"这种字段,所有寄到这里的包裹全部投递失败。

这就是隐性格式契约:你和 AI 之间有一些"没写死但你默认它懂"的格式规则。对模型来说,没有明文写死的规则,都是它可以“合理发挥”的空间。

真实事故:一个字母后缀撞坏了什么

我们给模型的大纲里,所有节编号都是 4.2、6.5 这种"数字.数字"格式。我们以为这个模式够明显了——结果它在插入新节时,写出了 4.2b、6.5a。

从结果看,效果相当于"在不打乱原有数字编号的前提下插入新节",单看还挺合理。但下游入库脚本约定 id 必须是"字母前缀 + 数字.数字"格式,字母后缀一进去,解析结果是 NaN(Not a Number,"不是一个数",程序读不懂数字时的报错值)。

都看到这了，打个赏呗！