这类问题我又碰上了一次。把 system 提示存进 MySQL 的 varchar,前端表单提交后做了二次转义,模型输出里直接出现反斜杠 n 这样的字面量,读出来打印才发现。

第一反应是「前端把换行替换成字面量再提交」,验证下来不成立。

真正麻烦的地方在于,几个原因的现象几乎一样。写入时多做了一次 json.dumps,读取后没有 loads;ORM 字段是 Text,但驱动开了 escape 选项;备份恢复时 mysqldump 又加了一层转义。

第一件事是查库里字段的十六进制

mysql -e 'SELECT HEX(LEFT(content,40)) FROM prompts WHERE id=1'

随后统计转义序列出现次数

python -c "s=open('p.txt',encoding='utf-8').read();print(s.count(chr(92)+'n'))"

还原换行后回写

python -c "s=open('p.txt',encoding='utf-8').read();open('p2.txt','w',encoding='utf-8',newline='').write(s.replace(chr(92)+'n',chr(10)))"

末了核对还原后的行数

python -c "print(open('p2.txt',encoding='utf-8').read().count(chr(10)))"

排查用的命令都是临时敲的,没有写成脚本,事后才整理。

怎么算真的好了,看的是同一批现象。库里读出的 system 与实际行数一致,模型输出不再出现反斜杠 n 字面量。

这里还有个坑。转义问题只看日志很难发现,把字段 HEX 出来对一遍比反复改提示词快。报错文案容易误导,真正的原因往往在相邻那一层的日志里。

作者 9823189