删一个.filter()省30Token：LLM输出分隔符设计与静默数据损坏

向模型请求五个字段，它返回给你的是一个字符串。字符串和数据库之间隔着解析器，而解析器的失败方式有两种，这两种并非同一失败的不同版本。一种是刺耳的失败：抛出异常，或返回错误的字段数量，导致你重试一次。另一种是静默的失败：返回恰好 k 个自信满满的字段，但其中有一个是错的，从此你失去一行数据。

所以这个页面构建了十四个真实的编码器/解码器对——真正的 JSON.parse、一个 RFC 4180 扫描器（带引号双写处理）、一个标签扫描器、一个行扫描器——并且枚举了每一种生产端状态，而非抽样测试，这就是为什么这里 0.00% 的失败率意味着零失败，而不是"未见失败"：https://dev48.infy.uk/prompt/day70-delimiter-design.html

无需任何假设的探测

一条记录，每个值都很无聊：逗号、换行、管道、引号、井号都不存在。唯一的变量是模型围绕答案写了什么。让它做模型最常做的的一件事——不是幻觉，而是礼貌：

Sure! Here are the fields you asked for:

十四个解析器中有五个会静默返回错误数据。不是报错——是数据。每一种单行格式都会把问候语吸进第一个字段，把告别语吸进第 k 个字段，所以字段数量是对的，解析成功了。如果允许其他五种普通的包装方式，失败率变成 8/14，其中恰好有三种格式通过了全部六种测试——而每一个幸存者都是带有明确闭合标记的格式。

这就重新定义了标签的标准防御。答案前面的 prose 对 ### 标题和 <customer> 标签都无害，所以键控是有效的。答案后面的 prose 就会把它们分开：### 段落有开头没结尾，所以每句"如有需要请随时告诉我"都会落入你的最后一个字段，所有键都存在、已知且计数正确。键控能抵御你答案之前的内容。终止能抵御你答案之后的内容。

免费修复三次击败付费修复

移除十八个字符就换来三十点和整列安全。免费修复让账单更小。而且重试是对模型行为的一次重新抽取，所以它能修复栅栏却修不了逗号——逗号在你客户的姓名里，而在所有生产端状态下，47.50% 的五字段记录都会失败，这让它们的重试预算精确等于零，而不是一个小数字。

被测量结果反驳的东西

我把转义约定作为修复方案构建。把这层包装调到零，它交付 99.54%：数据中的每个冲突都处理了，完全、精确地如广告所说。把这个拨盘调回 8%，它交付 91.58%，而缺失的八个百分点全部来自问候语。它解决了它被设计用来解决的 100% 的问题，而对实际触发的问题解决率为 0%。

它还额外增加了 0.69 个百分点的静默损坏，这是我未曾预料的，也是这个想法的诚实代价。解转义器是一个新组件，带有纯文本格式从未有过的失败模式：模型写入 C:\temp 原文，解转义器好心地去掉反斜杠，你存储了 C:temp——五字符的合理垃圾，而一个硬错误本来更好。加一个解码器就多了一种犯错的可能。

564 个页面内断言和 536 个验证器断言。一个文件，内联 CSS，无外部资源。

这是一个从零开始系列的一部分——每天一个提示技巧，用测量而非描述：https://dev48.infy.uk/promptfromzero.php