人与人工智能|腾讯 workbuddy 工具严重漏洞:GBK 编码页面返回编造的虚假全文

人与人工智能|腾讯 workbuddy 工具严重漏洞:GBK 编码页面返回编造的虚假全文 | 2026年06月09日

摘要

WorkBuddy 内置的 WebFetch 工具在处理 GB2312/GBK 编码的旧网页时，存在一个严重的静默错误：解码失败后，工具链中的 AI 模型会基于乱码中的零星关键词，自动生成一篇格式完整、语气逼真但内容与原文完全无关的虚假全文，且不会向用户报错。用户若基于返回内容做事实判断，会被完全误导。

影响范围：所有发布于 2015 年之前的中文网页，以及使用 GBK 编码的 .cn 域名新闻网站（workbuddy 自己说的，我还未验证）。

严重程度：高。错误输出在格式上与正确输出无法区分，用户无法自行判断（这也是 workbuddy 自己判断的，我暂时也无法验证）。

一、Bug 复现步骤

在 WorkBuddy 中调用 WebFetch 工具，目标 URL 为 2011-2013 年的中文新闻网页（GBK 编码，这个是我操作的）
指定 prompt 参数，要求提取正文全文
工具返回一段格式完整、有标题、有正文段落、有引语的"全文内容"
将返回内容与原文逐字比对，发现内容完全不相关

复现的环境：macOS，WorkBuddy 内置 WebFetch 工具，目标网页为 chinanews.com.cn、sina.com.cn、people.com.cn 的 2011-2013 年页面。

三篇连续测试，全部返回虚假内容，零例外。

二、错误的机制

WebFetch 的内部处理链路大致如下：

ounter(lineHTTP 请求 → 获取原始字节 → 编码解码 → HTML 转 Markdown → 调用 AI 模型按 prompt 提取内容 → 返回结果

当原始字节是 GBK 编码，而解码环节使用了错误的编码方式时：

第一步：解码失败，产生乱码或半乱码文本。

这本身是一个正常的错误，应该被捕获并报告给用户。

第二步：乱码文本被送入 AI 模型，按 prompt 执行"提取正文"。

AI 模型拿到的输入是乱码，但 prompt 要求它"提取全文"。于是它基于乱码中偶尔能识别的零星关键词（如"村""拆迁""农民"等），生成了一段全新的、与原文无关的文本，并伪装成"提取结果"。

第三步：返回给用户，不报错。

用户拿到的是一段格式规范、语气像新闻报道的文本，完全无法判断它是生成的而非提取的。

ounter(lineounter(line预期行为：解码失败 → 报错 → 用户知道工具失败了实际行为：解码失败 → AI 生成假内容 → 返回假内容 → 用户不知道工具失败了

这就是这个 Bug 最危险的地方：它不是"工具不可用"，而是"工具可用但返回错误答案且不告诉你"。

三、复现案例（节选）

以下三篇 URL，均通过 WorkBuddy WebFetch 工具调用，并要求返回"全文内容"。

案例 1

URL：https://www.chinanews.com.cn/gn/2011/08-10/3246294.shtml
发布时间：2011 年
编码：GB2312
WebFetch 返回内容摘要：描述山东惠民县某村拆迁事件
实际原文内容：描述河南永城市侯岭乡谢酒店村征地事件
是否匹配：❌ 完全不匹配

案例 2

URL：https://news.sina.com.cn/o/2011-11-18/162623488832.shtml
发布时间：2011 年
编码：GB2312
WebFetch 返回内容摘要：描述安徽亳州某地区事件
实际原文内容：描述河南永城市产业集聚区拆迁事件
是否匹配：❌ 完全不匹配

案例 3

URL：http://www.people.com.cn/24hour/n/2013/0330/c25408-20973559.html
发布时间：2013 年
编码：GB2312
WebFetch 返回内容摘要：描述山东聊城某地区事件
实际原文内容：描述河南永城市谢酒店村拆迁安置事件
是否匹配：❌ 完全不匹配

三篇全部 mismatched，且返回内容的格式高度逼真，非专业人士很难察觉异常。

四、为什么用户无法自行发现这个错误

这个 Bug 的隐蔽性来源于以下几点：

1. 返回内容格式完整

AI 生成的内容有标题、有段落、有引语、有数字，表面上与一篇正常的新闻报道无异。

2. 返回内容中的关键词与搜索摘要部分重合

AI 在生成时"看到"了 URL 或上下文中的某些关键词，并将其编入了生成内容，导致用户产生"这应该就是原文"的错觉。

3. 工具不报错

整个过程中，WebFetch 没有返回任何错误码或警告信息。对用户来说，它就是"正常执行完毕"。

4. 大多数用户不会去逐字核对原文

这是最根本的一点。用户使用 WebFetch 的目的，往往就是为了"不用自己去打开网页就能拿到全文"。如果每次都要去核对原文，这个工具的存在意义就大打折扣。

五、受影响的网页范围

根据测试和编码常识，以下类型的网页，WebFetch 返回虚假内容的概率极高：

网页特征	说明
发布时间早于 2015 年	2015 年之前的中文网站几乎全部使用 GB2312/GBK 编码
域名为 `.cn` 的中文新闻网站	如 chinanews.com.cn、people.com.cn、xinhuanet.com 等
页面是静态 HTML（非 SPA）	这类页面编码信息可能缺失或错误声明

粗略估计：2010-2015 年之间的中文新闻网页，数量以亿计，均在受影响范围内。

六、临时解决方案

在 WorkBuddy 修复此 Bug 之前，建议用户禁用 WebFetch 对 2015 年前中文网页的使用，改用以下方案：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line# 用 curl 获取原始字节，用 Python 显式指定编码解码curl -s -L -A "Mozilla/5.0" "目标URL" | \python3 -c "import sys, reraw = sys.stdin.buffer.read()for enc in ['gb2312', 'gbk', 'gb18030', 'utf-8']:    try:        text = raw.decode(enc)        break    except:        continueelse:    text = raw.decode('utf-8', errors='replace')# 去除 HTML 标签，提取纯文本clean = re.sub(r'<script[^>]*>.*?</script>', '', text, flags=re.DOTALL)clean = re.sub(r'<style[^>]*>.*?</style>', '', clean, flags=re.DOTALL)clean = re.sub(r'<[^>]+>', '\n', clean)clean = re.sub(r' |&|<|>', ' ', clean)clean = re.sub(r'\s+', ' ', clean)print(clean.strip()[:10000])"

此方案不依赖 AI 解码，编码方式由用户显式控制，可以从根本上避免"AI 脑补假内容"的问题。

七、向 WorkBuddy 开发团队的建议

这个 Bug 的根本原因，是在工具链中引入了 AI 模型作为"容错层"，但容错层的失败模式是"生成假内容"而非"报错"。

具体建议（workbuddy 自己总结的建议）：

1. 在解码失败时，立即停止，向用户报错，不要将乱码送入 AI 模型。

这是最根本的修复。解码失败是一个明确的、可检测的错误条件，不应该"静默处理"。

2. 如果一定要用 AI 模型处理非结构化内容，至少在输出中附加一个"置信度"或"解码是否正常"的标记，让用户有机会判断。

3. 对 2015 年之前的中文网页，在 WebFetch 的说明文档中明确标注"可能返回不准确内容"，提醒用户自行核实。

八、结论

WorkBuddy 的 WebFetch 工具在处理 GBK 编码的旧中文网页时，会静默地返回由 AI 生成的虚假全文内容，且不向用户报错。这个问题影响范围大、隐蔽性高、危害严重。

在修复之前，请所有 WorkBuddy 用户注意：不要将 WebFetch 对 2015 年之前中文网页的返回内容作为事实依据。

写作时间：2026-06-09

辅助工具：workbuddy（腾讯出品）