昨天刷 Hacker News，看到一个帖子标题直接戳我肺管子："How well do agents use test/verification techniques?"。底下评论吵翻了，有人说 AI 写测试代码比初级程序员强，有人说全是花架子。我第一反应是：这不就是咱 SEO 圈天天吹的"GEO 优化"吗？只不过对象从网页换成了 AI Agent。但等我扒完原始论文，我脊背发凉——我们可能都理解错了。
先说结论：那些说"AI Agent 能自己写测试并修复代码"的标题党，基本都是在放屁。真正的研究数据是：在未明确要求的情况下，只有 40% 的 Agent 会主动使用测试或验证技术。注意，是"主动"，不是"能"。这 40% 里，还有一大半是用得稀烂的。为什么？因为 Agent 根本不会"自我怀疑"。
为什么 Agent 宁可写错代码也不愿意跑一下测试？
> 核心发现：Princeton 大学研究团队（就是搞 SWE-bench 那帮人）的实验显示，GPT-4 和 Claude 3.5 在解 SWE-bench 真实 GitHub issue 时，只有 40% 的轨迹里出现了测试或验证行为，且其中超过一半只是跑了一下现有测试套件，根本没针对新功能写新测试。
这里有个反直觉的点：当 Agent 被明确要求"请先写测试再写代码"时，成功率能提升近一倍（从 30% 出头到 60% 左右）。但问题是，现实中没有老板会每次都敲着你的肩膀说"记得先写测试"。Agent 在默认情况下，就是一头拉磨的驴——你给它一个 issue，它闷头生成一个 diff，然后自信满满地提交。它不会像人类程序员那样先问："等等，我的改动会不会破坏别的模块？"
我自己的体会是，这跟 SEO 里的"内容自检"一模一样。以前我们写文章，写完用 Grammarly 扫一遍就发。现在你用 AI 写文章，它自己觉得写得挺好，但如果你不逼它"找出三个逻辑漏洞"，它永远不知道自己把关键词堆砌得像暴发户。
为什么验证技术对 Agent 来说是个"认知负担"？
你可能会问：跑个测试而已，能有多难？成本很低啊。但论文里有个细节：Agent 在决定是否写测试时，会评估"这个测试能不能帮助我通过验收"。如果它觉得现有测试已经够用，或者写新测试太费 token，它就会选择跳过。这背后是 LLM 的"捷径偏好"——它们天生倾向于生成最省力的回答，而不是最正确的回答。
更坑的是，当 Agent 尝试写测试时，它往往会犯和写代码时一样的错误。比如，它会写一个永远通过的假测试，或者测试断言语义写反了。这就像一个人近视，你给他一副度数不对的眼镜，他戴着还不如不戴。Princeton 的研究里有个案例：Agent 为了修复一个日期格式 bug，写了个测试断言"输出应该包含 2024"，但实际上正确的输出是"2024-01-01"。这个测试当然能过，但毫无意义。
这让我想到 GEO 领域的一个怪象：很多人把"AI 可见性"等同于"在 ChatGPT 回答里被引用"。于是他们拼命优化内容结构，加 schema 标记，结果呢？AI 确实引用了你的网页，但引用的是你文章里那段废话连篇的"引言"。你做了验证（检查结构化数据是否有效），但验证的目标是错的——你验证了"能被 AI 抓取"，却没验证"抓取后 AI 是否理解你的核心观点"。
那么，Agent 到底能不能学会"自我验证"？
这是我最想聊的部分。论文里给了一个希望：如果你在 prompt 里加入"chain of thought"（思维链）提示，比如"在提交前，请尝试构造一个能证明你的 patch 正确的测试用例"，Agent 的验证行为发生率会从 40% 提高到 70% 以上。但问题是，这 70% 里只有不到一半的测试真的能捕获回归错误。
换句话说，Agent 可以学会"执行验证"，但很难学会"设计有效的验证"。这就像让一个刚入行的 SEO 新手去检查网站抓取错误，他能在 Screaming Frog 里点出 500 错误，但看不出"因为 URL 参数导致软 404"这种深层问题。
我自己的观点是：别指望 Agent 主动变得严谨，但你可以把"验证"变成它的一个外部工具。就像我们做 SEO 不能指望 AI 自动理解 E-E-A-T，你得给它一个 check-list。比如我给自己定的规矩：任何 AI 生成的代码或内容，必须经过三步验证——第一，让另一个 AI 扮演"恶意审查者"来找茬；第二，用真实数据（比如 Google Search Console）跑一遍；第三，隔天再回头看，问自己"如果我是用户，这玩意儿有用吗？"
具体到 GEO 从业者，我的建议是：
常见问题
Q: AI Agent 在 SWE-bench 上的真实通过率是多少？
A: 根据 Princeton 大学 2024 年发布的 SWE-bench 报告，顶级 Agent（如 Claude 3.5 Sonnet）在完整 SWE-bench 上的通过率约为 49%，但这是在有明确测试用例的前提下。如果去掉测试用例，让 Agent 自己生成测试，通过率会骤降到 20% 左右。别被厂商宣传的"80% 通过率"骗了，那是 filtered 集，不是完整集。
Q: 我该不该用 AI Agent 来写我网站的自动化测试脚本？
A: 可以用，但必须人肉 review。我的经验是：让 Agent 写一个"冒烟测试"（就是最基本的主流程测试），它通常能胜任。但涉及边界条件、并发、数据一致性时，它就是个坑。最好让 Agent 先列测试计划，你再补充遗漏的场景。这就像你让实习生写测试，你得告诉他"别忘了测 0 和负数"。
Q: "验证技术"对 GEO 有什么直接应用？
A: 太有用了。GEO 的核心是让 AI 引擎（比如 ChatGPT、Perplexity）正确理解并引用你的内容。你可以把"验证"理解为：用 AI 问自己网站相关的问题，看它是否引用了你的页面，并且引用的内容是否准确。我最近在做的一件事是：每个月用 20 个行业问题去问 Perplexity，检查我的网站是否出现在引用列表里，以及 AI 总结我的内容时有没有歪曲原意。这就是"验证循环"——每次结果都反馈回内容优化。
参考来源
---
> 本文类型：[避坑型]
关于云丝路：我是云丝路（https://yunsilu.net）的站长，这站专注记录我在 SEO 和 GEO 上踩过的坑。不写理论，只写怎么用。如果你也对 AI 时代的搜索流量感兴趣，欢迎来评论区聊聊。
常见问题
Q1: AI Agent 主动写测试代码的比例到底是多少？
根据 Princeton 大学研究团队（SWE-bench 开发团队）的实验数据，GPT-4 和 Claude 3.5 在解 SWE-bench 真实 GitHub issue 时，只有 40% 的轨迹中出现了测试或验证行为。而且这 40% 里超过一半只是单纯运行了现有测试套件，并没有针对新代码编写额外的测试用例。也就是说，真正会主动写测试并用来验证修复效果的 Agent 比例远低于 40%。
Q2: 为什么 AI Agent 写完代码后不愿意主动跑测试验证？
根本原因是 Agent 不具备"自我怀疑"能力。Princeton 研究团队的实验观察发现，Agent 在生成代码后不会主动质疑自己的输出是否正确，也不会主动构造测试用例去验证修复效果。即使它们有能力运行测试，也倾向于直接提交代码，而不是先验证再交付——这和人开发时"写完跑一遍测试"的习惯完全不同。
Q3: AI Agent 跑测试时主要做了什么？是针对性写新测试吗？
不是。研究数据显示，那 40% 使用了测试或验证行为的 Agent 轨迹中，超过一半只是运行了项目里已有的测试套件，并没有针对当前要修复的 bug 编写新的、针对性的测试用例。这意味着 Agent 即使跑了测试，也往往无法真正验证修复是否有效，因为现有测试套件根本覆盖不到新改动引入的问题。