隐形 Unicode 字符可影响 LLM 输出

通过不可见的 Unicode 字符阻止 AI 读取你的文本，同时确保人类仍能理解其含义。

LLM（Large Language Model，大语言模型），例如 ChatGPT，实际上并不像人类一样阅读文本。它们只能理解被转换成一串数字的单词，这些数字称为「token」。英语中的每个单词都可以被拆分成多个 token，而在模型的训练数据中，每个 token 都与该单词（或单词的一部分）的含义相关联。然而，像 Gibberifier 使用的这些不可见 Unicode 字符，在真实文本中出现得不够频繁，不值得拥有专属 token。因此，tokenizer（将单词转换成 token 的算法）只能将它们表示为计算机中存储这些字符时使用的原始 UTF-8 字节数据（类似于「U+FE12」）。

当你对文本进行 gibberify 处理时，AI 看到的并不是「Hello」，而是类似于「H[U+FE12][U+FEB2][U+FE82]e[U+FB12][U+FE18][U+FE12]l[U+FE18][U+FE12][U+FB12]...」这样的内容。模型会接收到大量看似随机的字节 token，其长度超出了模型的「context window」（模型一次能够读取的文本量，通常大到无需担心），同时还会破坏 tokenizer 将完整单词组合成 token 的能力。想象一下：你每次只能读取一个字母，却还必须从一大堆毫无意义的数字中把它找出来。

还想进一步了解？可以查看 OpenAI 的 Tokenizer Demo，或与 Will Patti 交流。

针对 AI 模型的测试

结果：无法理解经过 gibberify 处理的文本——要么触发 context 限制，要么意识到出了问题，却对此无能为力。

结果：Claude 无法处理如此庞大的文本，会直接崩溃。

结果：Gemini 无法处理这些不可见字符，有时甚至会直接「抽风」。

结果：遇到经过 gibberify 处理的文本时，同样会崩溃或报错。

结果：在达到 context 限制后，会回复一些「有趣」的话，例如「有时候，少即是多」。

🕷️ Web Scraper 也会失效

经过 gibberify 处理的文本同样会让 AI 驱动的 Web Scraper 失效。

结果：Firecrawl 的 AI scraper 无法从经过 gibberify 处理的文本中提取任何内容。

结果：TLDR This 摘要工具无法正确处理经过 gibberify 处理的内容。