GLM-4实战：用AI统计Chrome 2025年在野漏洞，结果靠谱吗？

这两天想统计一下Chrome浏览器在2025年被公开确认的在野利用漏洞情况。我首先想到的方法是直接爬取官方的更新日志页面，于是用AiPy工具写了个简单的任务提示词：

https://chromereleases.googleblog.com/2025/01/ 这个是Google Chrome的升级日志URL，它会按月份生成对应的链接。我需要你从2025年01月到2025年12月，统计所有漏洞信息。注意，你要通过语义理解去阅读页面内容，而不是简单地用正则表达式匹配。需要全面统计漏洞对应的CVE编号、报告者、报告日期、漏洞基本信息以及是否存在在野利用等情况。结果按CVE编号去重，并保存到表单文件里。一定要全面，如果访问错误请务必重试直到成功。

初步测试跑出了106个漏洞，其中包含了7个在野利用漏洞。但我心里没底，无法确定这个结果是否准确，于是我让AiPy随机抽查了8月和6月的数据进行核对：

你帮我随机抽查下8月、6月的漏洞，看看是否对得上数据。

结果提示漏掉了好几个。接着，我让它重新核查所有被标记为在野利用的漏洞，发现之前的统计结果确实存在出入。分析后发现，问题主要出在数据格式不统一上。例如，数据中混杂着各种格式：

[$2000][384844003] Medium CVE-2025-0762:
[N/A][460017370] High CVE-2025-13223
[TBD][405143032] High CVE-2025-2783

而且，关于“在野利用”的描述也五花八门，比如 “in the wild”、“in wild” 等等。虽然我在最初的提示词里明确要求用“语义”理解，但大模型在实际处理时，往往还是倾向于使用正则匹配等规则化方法，几乎无视了语义理解的要求。

为了解决这个问题，我写了一个非常详细的“Skills”指令，并附上了大量例子进行说明。调整后的效果看起来有所改善，但我始终无法百分百确定数据的准确性，尤其是“在野利用”这个关键信息，抽查时老是不对。

我也尝试了用 ChatGPT 来执行这个任务。不过，它的解决方案有点让人哭笑不得——它直接写了个Python脚本让我在本地运行。这让我不禁想：如果要在本地跑脚本，那我直接用 AiPy 这类工具的意义何在呢？

更要命的是，我最终发现了一个根本性问题：直接访问 https://chromereleases.googleblog.com/2025/01/ 这个页面，其数据本身就是不全的，因为存在分页机制。这意味着你爬取的所谓“一月数据”，其实有一部分公告显示在下一页。这个发现从根本上否定了我之前设计的整个方法。

于是，我转换了思路：为什么不直接用搜索引擎的API进行定向搜索呢？

使用Google API搜索 chromereleases.googleblog.com 这个域名下，所有在2025年被标记为“在野利用”的漏洞及相关信息。

这次，大模型给出的结果是 9个 在野利用漏洞。

那么这个结果准确吗？为了交叉验证，我用 ChatGPT 执行了相同的搜索策略，它给出的数量也是9个。进一步对比 Google Project Zero 团队维护的公开数据表（ https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/view?gid=897725844 ），数据基本上能对上。只是在那个项目里，有两个漏洞被标记为影响 WebKit，而 WebKit 的漏洞同样会影响到基于它的 Chrome 浏览器。

所以，问题来了：在整个过程中，到底什么才是最重要的？是精心设计的 MCP/Skills 指令？是选择的工具或产品？是最终得到的那个“9”这个结果数字？还是对整个任务认知和方法的理解？

现阶段，AI工具的用户到底是谁？是会写提示词的工程师，还是需要结果但不懂技术的人？LLM 究竟取代了“搜索+整理”这个动作，还是取代了“思考如何正确搜索与整理”这个更深层的能力？

在纠结这些宏大问题之前，不妨先纠结一个更实际的问题：你能正常访问 https://chromereleases.googleblog.com 这个网站吗？这本身可能就是第一个需要跨过的障碍。

对了，我上面测试使用的模型是 GLM-4。这次踩坑经历也让我觉得，有时候技术问题的答案，往往藏在社区的经验分享和讨论里，而不仅仅是冰冷的工具输出中。