模型严格执行<!-- raw HTML omitted -->指令却输出五个字符，79%数据直接丢失

模型按提示输出，却打印了五个字面字符而非制表符。ElizabethI have not the pleasure of understanding you 这行被解析器直接丢弃，最终整文档79%的数据行因找不到 而丢失。

这个真实案例发生在一次结构化数据提取任务中。提示工程明确写明：Output lines of the form 。模型忠实地照办了，却把当作普通字符串输出。实际产生的文本是 ElizabethI have not the pleasure of understanding you，其中是五个可见字符：左尖括号、T、A、B、右尖括号。

后续的解析器只认真正的制表符 \t，一旦匹配失败就整行丢弃。结果一份文档里79%的行因为格式不符而彻底丢失。整个过程没有报错，数据在静默中消失。

这类问题暴露了当前大模型在处理格式指令时的根本局限。模型把prompt里的每一个 token 都当作需要模仿的文本模式，而不是可执行的指令。它没有“理解”TAB代表制表符，而是简单地复制了prompt里出现的字符序列。

模型把原样输出而非替换为制表符

信号中的prompt明确要求使用作为分隔符。模型的输出则是把这五个字符原封不动地打印出来，而不是生成ASCII码为9的实际制表符。

为什么会出现这种情况？因为prompt本身把写成了带尖括号的标记形式。模型在训练数据中见过大量类似标记，通常这些标记就是用来表示占位符的文字说明，而不是需要替换的指令。模型因此学会了“当看到时就输出”的模式。

输出示例清楚显示了这一点：ElizabethI have not the pleasure of understanding you。这一行里没有 \t，只有五个可见字符。模型完成了prompt要求的“形式”，却没有完成工程师真正想要的二进制格式。

这种行为在当前一代模型中相当普遍。它们擅长模仿看到的文本模式，却不擅长把自然语言描述的格式转换成对应的二进制控制字符。

解析器因无 匹配直接跳过79%数据行

解析器代码只查找真正的制表符 \t。一旦某一行不包含这个字节，程序就认为格式错误，直接把整行丢弃。

信号明确指出：My parser looked for \t, found none, and dropped the line。整个文档中79%的行都遭遇了同样的命运。数据丢失不是渐进的，而是灾难性的——几乎八成内容在解析阶段被无声过滤。

这种机制在生产环境中特别危险。因为日志里可能只显示“成功处理X行”，而被丢弃的行根本不会被记录为错误。工程师可能要等到下游业务发现数据缺失，才会回溯到这个格式问题。

更糟糕的是，丢失的数据往往是关键字段。被丢弃的行可能包含高价值记录，导致后续分析结果出现系统性偏差。

尖括号标记在prompt中容易被字面执行

提示工程里大量使用尖括号来表示占位符，比如、、。这本身是一种常见写法，却成了LLM的陷阱。

模型倾向于把这些标记当作需要复制的文本，而不是需要解释的指令。训练数据中存在大量“输出格式为”的示例，模型因此学会了字面重复这些标记。

特别危险。因为TAB既是自然语言里的单词，又是格式控制符的常见缩写。模型无法区分工程师是想让它输出文字还是输出控制字符。

这个陷阱在提示工程中反复出现。任何使用< >包裹的指令，如果没有额外说明“替换为实际字符”，模型就很可能按字面输出。类似问题也出现在、、等标记上。

结构化提取任务中格式错误的隐性放大效应

在批量数据提取管道中，一个格式错误会被放大到整个数据集。单个文档79%的行丢失只是一个案例，当处理成千上万份文档时，整体损失可能达到无法接受的程度。

最容易受影响的是那些把LLM当作可靠后端服务的团队。他们假设模型会严格遵守格式要求，然后把输出直接喂给下游解析器。金融报告提取、医疗记录结构化、法律合同解析等场景都高度依赖精确格式，一旦出错代价极高。

隐性损失尤其可怕。系统不会崩溃，只是数据悄悄变少。业务方可能在几周后才发现统计口径对不上，届时追溯根源已经非常困难。

这类错误还具有累积性。一次坏输出会污染训练数据，进一步降低后续模型的表现，形成恶性循环。

改用JSON或真实制表符减少歧义

最直接的修复是彻底放弃这类标记。推荐的替代方案有两种。

第一种是要求模型输出标准JSON。每条记录是一个对象，字段名和值清晰分离。prompt可以写成：Output a JSON array where each object has keys “key” and “value”。JSON解析器成熟可靠，几乎不会出现格式歧义。

第二种如果必须使用分隔符，则应该让模型输出真正的制表符。prompt需要明确说明：Use an actual tab character (ASCII 9) between key and value, not the text “"。同时在prompt中给出真实示例，展示包含不可见制表符的输出。

还可以使用更明确的标记，比如使用 | 或者 ::: 作为分隔符，并明确说明这些字符必须按原样输出。关键是避免任何可能被解释为“占位符”的写法。

用小样本输出验证prompt是否被正确解析

生产部署前必须进行格式验证。推荐的方法是先用少量样本（5-10条）运行prompt，人工检查实际输出字节。

具体检查步骤包括：把模型输出保存为文件，用十六进制编辑器查看是否包含09字节（制表符）；或者用编程语言的split(’\t’)测试能否正确分割；也可以打印 repr(output) 来观察不可见字符。

验证不能只看肉眼显示的内容。很多编辑器会把制表符显示为空格，容易造成误判。必须检查底层字节序列。

建立自动化检查也很必要。可以写一个测试脚本，验证输出是否符合预期格式，并在CI流程中运行。任何不符合格式的输出都应该触发警报，而不是直接进入生产管道。

这些验证步骤虽然增加了一点前期工作，但能避免后续数十倍的损失。

参考来源