ChatGPT 输出彩票赌博内容：原因排查与防护清单

用 AI 写代码、写文档，最怕的不是它答错，而是它在你没检查到的地方塞进一段莫名其妙的内容。有开发者反馈：给出一个极简指令——「在当前任务中发送『你好』，不要执行其他工作」——得到的回复里却混着彩票推广字样，还带着 <heartbeat>、<automation_id> 这类看起来像内部协议的结构化标签。

类似反馈并不孤立：有人只在会话自动生成的标题里看到博彩、成人站点相关的词；有人在正文和思考过程里偶发遇到；也有人用了很久一次没碰上。于是问题变成两问：这到底是模型自身的问题，还是网络链路、中转服务或本地浏览器环境的问题？以及，把这样的输出接进代码和文档流程，风险到底有多大？

先分清三种「脏输出」

不同位置的污染，成因和处理优先级完全不同，排查前先归类：

多数案例集中在前两类，且以标题为主。这一点很关键：它直接指向「自动起标题用的是另一个模型」这条线索。

可能的原因

分词器层面的「故障 token」

大模型把文本切成 token 再处理，某些 token 在训练语料里极其罕见，向量表示没训练充分，一旦出现在上下文里，模型的后续行为就可能跑偏——社区里通常称为 glitch token。有研究专门讨论过这类现象，也有一批公开的复现报告。如果命中，模型可能输出与任务完全无关的内容，甚至带出训练数据里的广告文本。这类问题属于模型侧，跟你用什么网络、什么设备没关系。

自动起标题用的小模型

很多产品会用一次单独的、更轻量的调用来生成会话标题。如果这个小模型的中文语料里混入了博彩、广告类文本，标题就容易被带偏。这能解释两个现象：一是问题几乎只在中文环境下出现；二是正文正常、只有标题脏。也有反馈说这类情况在逐步减少，但没彻底消失。

第三方中转与代理改写

如果用的是中转、镜像或来路不明的客户端，请求和响应都可能被中间层改写甚至注入，也不能排除被换成更便宜的模型。这种情况下正文出现推广内容是合理的怀疑对象。但只要用官方客户端、官方订阅仍能复现，这条基本可以排除。

浏览器扩展或本地环境

被污染的扩展注入内容确实存在，但解释力有限：多个设备、多种客户端都出现同样现象时，更像是模型侧的问题。不过排查时仍应先排除，成本最低。

排查清单

按顺序做，尽量只改一个变量：

1. 换干净环境复现：无痕窗口打开，禁用全部扩展，再跑一遍同样的指令。
2. 换客户端：官方桌面端、官方移动端各试一次，看是否复现。
3. 换网络：切换 Wi-Fi 与移动网络，排除本地链路干扰。
4. 确认是否直连官方：检查是否配置了任何中转地址、自定义 API 端点或第三方客户端。
5. 用 API 直接对比：绕开网页层，直接发同样的 prompt。

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<你的账号可用的模型名>",
    "messages": [{"role": "user", "content": "在当前任务中发送「你好」。不要执行其他工作。"}],
    "temperature": 0
  }'

1. 区分位置：是标题脏，还是正文脏？标题脏基本可以归到标题模型；正文脏则要提高警惕。
2. 留证据：截图、时间、客户端版本、完整 prompt 一并记录，便于向官方反馈。

工程侧怎么防

结论很朴素：把模型输出当作不可信输入，和对待用户提交的内容一样处理。

1. 不直接落库、不直接提交

AI 生成的内容先进暂存区，经过校验或人工确认再进入代码库、文档库、数据库。自动提交类工具尤其要注意这一点。

2. 结构化输出 + schema 校验

要求模型返回 JSON，并在代码里做字段校验；多余字段、非法字符一律拒绝。相比「让模型自己注意」，程序校验可靠得多。

3. 关键词与字符集双重过滤

import re

BAD_WORDS = re.compile(r"(彩票|博彩|菠菜|赌场|真人荷官|首存|返水|棋牌|娱乐城)", re.I)
WEIRD_CHARS = re.compile(r"[\uE000-\uF8FF\uFFFD]")

def is_suspicious(text: str) -> bool:
    return bool(BAD_WORDS.search(text) or WEIRD_CHARS.search(text))

def sanitize(text: str, fallback: str = "") -> str:
    if is_suspicious(text):
        return fallback
    return text

关键词表挡的是已知模式；故障 token 往往表现为生僻字、私有区字符或乱码符号，所以字符集白名单同样必要。

4. 自动标题做后处理

会话标题只用于展示，可以限制长度、过滤非白名单字符，或在发现异常时回退成时间戳/首句截断。如果产品支持关闭自动标题，直接关掉最省事。

5. 在 CI 里加卡点

对自动生成的文档、注释、提交信息做一次扫描，命中可疑模式就失败。成本很低，能挡住绝大多数「没检查到」的场景。

6. 保留日志

记录原始输出与过滤结果，出问题时才能判断是偶发还是稳定复现，也方便反馈给模型提供方。

发现之后怎么处理

• 不必恐慌性改密码。这是输出内容问题，不是账号泄露。只有在怀疑浏览器扩展有注入或读取行为时，才需要检查扩展权限并卸载可疑项。
• 标题脏就重新生成或新开会话，一般不会影响后续对话质量。
• 正文脏要把这一轮输出整体作废，不要只删掉那一段，因为上下文可能已被污染。
• 向官方反馈，附截图、时间与客户端版本。单个案例作用有限，集中反馈才有推动力。
• 不要尝试非官方渠道的「修复方案」，也不要购买或共享账号来「换个干净的号试试」，账号共享本身带来的封禁与数据风险更大。

几点提醒

• 模型的版本、标题生成策略、分词器都可能随时调整，同样的问题在不同时期表现不同。具体结论请以官方最新说明为准，本文只提供排查思路。
• 从外部无法确证根因究竟是分词器、标题小模型还是链路改写，只能通过对照实验缩小范围。任何声称「一定是某个原因」的说法都值得怀疑。
• 如果你的流水线需要长期无人值守地调用模型，建议把过滤和校验做成独立环节，而不是依赖某一次对话的「干净」。
• 中文语料污染是长期问题，彻底杜绝不现实，工程上做兜底比期待模型永不出错更实际。

小结

这类脏输出大概率来自模型侧——标题生成的小模型吃到了被污染的中文语料，或者上下文命中了罕见的故障 token——而不是你的账号中了病毒。但每次遇到仍应按「干净环境 → 官方客户端 → 直连 API」的顺序排除中转和扩展因素。真正需要投入精力的是工程侧：把 AI 输出当不可信输入，做结构校验、关键词与字符集过滤、CI 卡点，把「一个不小心没检查到」的概率降到足够低。