问题出现得很突然，日志倒是留得挺全。多人改同一个提示词文件，合并时 <<<<<<< HEAD 和 >>>>>>> feature/prompt 这几行没清干净就提交了。服务读文件后直接拼进 system，模型开始回答「你需要先解决合并冲突」之类的话，线上日志里能看到请求体带着成串的尖括号。重启服务后仍然复现。
刚开始盯着「CI 里缺少针对提示词文件的 lint 步骤」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。合并后没有跑冲突标记检查就提交了。还有一种是配置读取只去掉注释，没有对内容做校验。
还有一种情况，镜像打包的是构建机上的旧文件，本地看着是干净的。
第一件事是在仓库里全局搜一遍冲突标记
git grep -n -E '^(<<<<<<<|=======|>>>>>>>)' -- '*.txt' '*.j2' '*.yaml'然后确认线上容器里的文件内容
docker exec -it api sh -c "grep -n '<<<<<<<' /app/prompts/system.txt"接着在服务启动时加一道内容断言
python -c "s=open('system.txt').read();assert '<<<<<<<' not in s, 'conflict marker';print(len(s))"修完重新构建镜像后再验证一次
git grep -n '<<<<<<<' && echo BAD || echo CLEAN怎么算真的好了，看的是同一批现象。仓库与容器内都搜不到冲突标记，同一条请求的 system 里只剩正常说明，模型回答恢复成业务内容。
冲突标记是纯文本，模型会把它当成指令的一部分去理解，加一条启动断言比事后翻日志省事得多。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。