2026年4月22日，Forbes《The Wiretap》网络安全专栏刊出了一篇措辞罕见严厉的报道：俄亥俄州网络安全公司TrustedSec的CEO、前NSA分析师Dave Kennedy，用自己亲手构建的测试工具，公开了一个令整个AI编程工具行业坐立难安的数字——47.3%。

这是Claude Opus 4.6发布后约5周内，代码质量的下降幅度。Kennedy的原话是：”Really bad, I mean unusably bad”（非常糟糕，我是说，糟糕到无法使用）。

TrustedSec已经停止使用Claude进行代码生成。

这件事情的背景是：2026年初，”vibe coding”运动席卷整个开发者社区。Replit、Cursor、GitHub Copilot和Claude Code每周都在创造新的使用记录。对于数以百万计的开发者来说，AI代码助手已经不是”新鲜工具”，而是日常工作流程的核心基础设施。在这个前提下，一个专业安全公司用量化数据公开指控Claude代码质量大幅退化，冲击的不只是Anthropic的产品声誉，而是整个行业对AI编程工具的信任根基。

47.3%：一个精确到小数点的指控

Dave Kennedy不是在情绪化发泄。他建立了一套系统性的自动化测试工具，专门用于评估Claude在实际工程任务上的表现，追踪4个核心维度：

  • 代码整体质量：功能完整性、逻辑清晰度
  • Bug数量：逻辑错误和功能性缺陷
  • 安全问题：已知漏洞类型、不安全的编程模式
  • 任务完成度：能否从头到尾完成一个完整的编程任务而不中断或返回错误

在这套工具的追踪数据中，从Opus 4.6发布约5周前到2026年4月22日，综合评分下降了47.3%。

“最终的风险在于，使用Claude进行编程的新手开发者不会识别这些缺陷，”Kennedy对Forbes说，”这会将严重的安全缺陷引入生产环境。这是非常令人担忧的事情。”

Kennedy还提到，Opus 4.7（Claude最新版本）”边际上好一些”，但仍然没有恢复到Opus 4.6刚发布时的质量水平。换句话说，更新版本的模型，比最初版本的旧模型还要差。

这个细节需要停下来仔细咀嚼：Anthropic发布了一个被明确标榜为”更强大”的新模型（Opus 4.7），但在实际代码安全性测试中，它的表现不如旧模型（Opus 4.6初始版本）。

这打破了用户一个常识性假设：新模型 = 更好的结果。

不是孤立的声音：Veracode的数据和AMD高管的公开证言

Kennedy的批评之所以迅速引发共鸣，是因为他说出的不是孤立事件，而是一个已经在多个维度上被数据反复验证的模式。

Veracode的系统性测试：超过一半的代码含安全漏洞

代码安全公司Veracode过去一年持续用同一套标准化方法测试各大AI系统：布置80道编程任务，统计有多少次输出的代码包含可被利用的安全漏洞。

结果令人震惊：

模型 漏洞率
Claude Opus 4.7 52%
Claude Opus 4.1（旧版） 51%
Claude Sonnet 4.5（低配版） 50%
OpenAI模型 约30%

三个关键发现值得单独拎出来：

第一，Claude系列近一年的漏洞率没有实质性改善。从Opus 4.1到Sonnet 4.5到Opus 4.7，三个版本的漏洞率分别是51%、50%、52%——虽然数字之间存在小幅波动，但Anthropic近一年来发布的所有主要Claude版本，安全性始终在50-52%的高位区间徘徊，最新的旗舰版本Opus 4.7的漏洞率（52%）甚至是其中最高的。

第二，OpenAI模型的表现差异显著。同样的80道任务，OpenAI模型的漏洞率约30%，比Claude的52%低了将近一半。这个差距，在安全关键场景中，可能就是灾难与正常运营之间的分界线。

第三，Claude的更高配置版本不等于更安全。Opus 4.7是比Sonnet 4.5更贵、更”强大”的模型，但漏洞率（52%）反而高于Sonnet 4.5（50%）。这再次打破了”更贵 = 更安全”的直觉假设。

Veracode首席创新官Jens Wessling的分析直击问题核心：

“这些数据支持了用户关于模型退化的声明。我相信这些模型被训练成编写能运行的代码，而不是持续应用让软件安全的控制措施。在没有对代码验证和修复方式进行改变的情况下，净效果看起来是更多有bug或有漏洞的软件，而不是更少。”

这句话揭示了一个AI编程工具行业的深层张力：功能性（代码能跑起来）和安全性（代码不会被攻击者利用）是两个不同的优化目标。在互联网训练数据中，展示”如何实现XX功能”的代码样本远多于展示”如何安全地实现XX功能”的代码样本——这个数据偏差，最终体现为模型行为的偏差。

AMD高管的公开声明：复杂工程任务不可信

来自AMD——一家AI芯片公司——内部AI工程团队的批评，让这场质量争议从安全领域蔓延到了更广泛的工程能力范畴。

AMD的一位AI高管在GitHub上公开写道，她的团队观察到Claude的”思考变得如此浅薄，以至于不能被信任执行复杂的工程任务”。

这个细节格外值得关注。这不是外部评测机构的实验室数据，而是来自实际工程实践的观察。AMD的AI团队在使用Claude辅助实际芯片设计或软件开发工作，在这个过程中感受到了质量的退化。

更讽刺的是：AMD是AI芯片的制造商，他们自己的团队却因为对AI软件工具的质量失去信任而公开发声。

Reddit和X：汇聚成海洋的集体投诉

Kennedy、Veracode和AMD的观察，只是有记录、有数据的冰山一角。Forbes报道中提到，数十名曾经满意的Anthropic用户在2026年3-4月期间涌向Reddit和X，发表了类似的使用体验报告——时间上，恰好与Opus 4.6发布约两个月后高度吻合。

在Reddit的r/ClaudeAI社区，一条标题为”Claude has gotten dramatically worse at coding”的帖子在几天内获得超过3,000个赞和800条评论，评论者描述的体验高度一致：写出的代码开始包含冗余逻辑、跳过边界条件检查、以及使用已被弃用的安全模式。一位高票评论写道：”I used to feel like I was pairing with a senior engineer. Now it feels like I’m babysitting an over-confident junior.”（我过去感觉像是在和一位高级工程师结对编程。现在感觉像是在照顾一个过于自信的初级工程师。）

这种集体性的使用体验倒退，在AI工具历史上也有前例。2023年6月，斯坦福和UC伯克利研究人员发表论文，记录了GPT-4在数学推理任务上几个月内显著退化的现象，OpenAI最终承认该现象存在。Claude的这次质量问题，让历史出现了某种不令人舒适的重演。

Anthropic的回应：沉默，和工程师推文里的一条关键线索

Anthropic对这场质量危机的官方立场是：正在积极调查关于Opus退化的说法，并建议”工程师应该始终检查漏洞”。

这个回应本身无可争议，但它同时也在无意中承认了一个现实：AI生成的代码不能被默认信任——哪怕你为这个”不可信任的工具”每月支付了100美元的订阅费。

然而，真正值得关注的细节，来自Claude Code负责人Boris Cherny在更早些时候发布的一条推文。他透露：Anthropic在某个时间点，主动将Claude在编辑代码之前的“思考努力程度”从”高”调低到了”中”。

原因是：回应用户关于token消耗过多的投诉。

这条信息解释了很多事情，也开启了一个更深层的问题。

Token经济学与代码质量之间的隐性替代关系

Claude的”扩展思考”（Extended Thinking）功能允许模型在给出答案之前进行更深入的内部推理。这个推理过程消耗token，而token对应的是计算成本，也对应着用户的账单。

当用户抱怨”Claude用了太多token”时，有两种可能的解读：一是使用效率低下（重复无效推理），二是推理深度超出用户需求。Anthropic似乎选择了一个简单的解决方案：降低默认的思考努力程度。

这个决策创造了一个对用户完全不透明的质量变更：

  • 没有变更日志说明这一调整
  • 没有安全公告说明可能的影响
  • 没有选项让用户选择”保持高推理深度模式”（尽管在某些场景可以手动调整）
  • 用户的体验是：同样的请求，同样的价格，但输出的质量悄悄降低了

这种情况，在传统软件行业，相当于一家云服务公司在没有通知的情况下，把你的服务器配置从8核降到了4核——因为其他用户抱怨机房用电量太高。

“我们到底能信任谁？”

Kennedy在采访中问了这样一个问题，也是他决定建立自己的本地AI基础设施的出发点。

“谁可以让我们真的信任？”

这个问题背后的逻辑是：当AI云服务提供商可以在任何时候、在没有通知的情况下改变模型的行为，而这种改变会直接影响到依赖这个模型的代码的安全性，安全专家的自然反应就是把这个变量拉回自己的控制范围之内。

Kennedy表示，他正在构建公司自己的本地AI基础设施，运行他能控制的定制模型。这意味着固定的版本、可验证的行为、以及不会被”思考深度调整”偷偷改变的安全属性。

公平地说：Anthropic面临的真实困境

批评很容易，理解困境更难。在讨论行业解决方案之前，有必要诚实地陈述Anthropic（以及整个AI工具行业）实际面临的复杂性。

困境一：质量是多维度的，没有可以同时优化的单一指标。

一个更”安全”的代码生成策略，意味着更多的内部推理步骤（更多thinking）、更保守的代码风格（更少尝试新模式）、更频繁的不确定性表达（”这个我不确定”）。这些特征在安全测试中得分更高，但在用户体验上可能被打分为”太慢”、”太保守”、”不够灵活”。

当Anthropic调低thinking effort是因为用户抱怨token成本过高——他们在响应一个真实的用户需求，而不是任意降低标准。问题不是”Anthropic选择了错误的指标”，而是”在没有公开讨论这个取舍的情况下，单方面做了决定”。

困境二：Veracode的52%数字有其方法论局限性。

80道编程任务是一个有价值的基准，但它代表的是特定类型任务的安全性，不一定能映射到所有使用场景。一个在嵌入式系统编程任务上漏洞率高的模型，在Web前端开发任务上可能表现不同。这不是为52%辩护，而是说：类型化的安全基准需要和实际使用场景匹配，才能做出准确的风险评估。

困境三：即便是OpenAI的30%，也是一个高得令人担忧的数字。

当我们对比Claude（52%）和OpenAI（30%）时，很容易将OpenAI的表现解读为”安全”。但30%的漏洞率意味着每10次代码生成中，有3次会引入安全漏洞——这在任何严格的安全标准下，依然是不可接受的。这场争论的真正背景是：整个AI编程工具行业的代码安全性，都远低于成熟的安全工程实践要求。

这3个困境不能成为Anthropic不透明的理由，但它们是我们在要求解决方案时必须纳入考量的现实约束。

第三层洞察：AI编程工具正在遭遇”无回归测试时代”的系统性危机

表面上，这是Anthropic一家公司、一个决策的问题。但如果拉长视野，这个事件揭示的是整个AI编程工具行业正在面临的一个更深层、更系统性的挑战——而且这个挑战目前几乎没有人在认真解决。

传统软件的质量保障机制

传统软件行业经过数十年的演化，建立了一套成熟的质量保障机制，其中最核心的是回归测试：每次软件更新发布之前，必须运行完整的测试套件，验证新版本没有破坏原有的功能或引入新的缺陷。如果测试不通过，版本不发布，或者发布时会明确标注已知问题和影响范围。

许多企业级软件公司还提供了版本锁定机制：企业客户可以选择停留在某个经过测试、行为可预测的版本，而不是强制跟随每次更新。这对于关键业务系统尤其重要——他们宁愿错过新功能，也不愿意冒更新破坏现有流程的风险。

AI模型更新的”黑箱”特性

AI模型的版本更新遵循完全不同的逻辑，且对这套传统质量保障机制几乎完全免疫。

模型更新本质上是全局参数的变化，影响的不是某个具体功能，而是模型在所有场景下的行为。一个对数学推理有利的参数调整，可能无意中改变了代码安全性的表现。一个为了降低token消耗而调低thinking effort的决定，可能对90%的使用场景没有可感知的影响，但对安全关键的代码生成场景却是灾难性的。

更关键的是：目前没有任何主流AI代码工具供应商，要求自己在发布新模型版本之前通过”代码安全漏洞率”的回归测试，或者将此类测试结果公开发布供用户参考。

Veracode正在做的事情（80道任务、持续监测漏洞率）其实就是一个第三方回归测试框架。它揭示的结果令人不安：Claude Opus 4.7在这套框架下的漏洞率是52%——如果Anthropic自己在发布前做了同等严格的测试，这个数字应该是已知的，并且应该引发了内部讨论和决策。

但从Boris Cherny关于”调低thinking effort”的说法来看，这个决定似乎更多考虑了用户体验（减少token消耗）而非安全影响。这不是指责Anthropic的工程团队能力，而是在说：AI工具行业目前缺乏一套以代码安全性为核心指标的版本发布标准。

AI供应链安全的隐性威胁

把这个问题放在供应链安全的视角下，问题的严重性会更加清晰。

2026年，全球有数以百万计的开发者在日常工作中使用Claude Code、GitHub Copilot、Cursor等AI编程工具，其中包括金融系统、医疗系统、基础设施控制系统、和各种企业级应用的开发者。许多代码在经过简单的人工Review（或根本没有Review）之后，就直接进入了生产环境。

当Anthropic在没有任何通知的情况下降低thinking effort，导致代码漏洞率上升，这个影响不会停留在Claude的服务器里，它会通过成千上万的开发者，渗透到无数生产系统中——而这些系统的运营者，对此完全不知情。

这是2026年AI安全领域最不被正式讨论、却可能影响最广泛的风险类型之一：不是黑客用AI攻击你，而是你用AI构建的系统里，有AI替你埋下了黑客可以利用的后门。

谁应该承担责任？

当一个AI生成的代码漏洞被黑客利用，谁应该承担责任？

这是2026年还没有清晰法律框架的问题。目前的主流立场是：用户最终负责——Anthropic的建议”工程师应该始终检查漏洞”本质上就是在说：最终责任在用户，AI只是工具。

但这个立场在现实中越来越难以维持，原因有三：

第一，代码Review本身正在被AI接管。在”vibe coding”的工作模式下，开发者用AI生成代码，再用AI审查代码，整个链条里人的干预越来越少。当用于生成代码的AI和用于Review代码的AI使用的是同样的底层模型，模型的系统性安全盲点无法通过这种内部循环发现。

第二，质量退化是不透明的。如果Anthropic公开宣布”新版本代码安全漏洞率提升了X%”，开发者可以做出有知情的决策——是否继续使用、是否加强Review、是否切换工具。但在没有任何公告、没有任何版本变更说明的情况下，开发者甚至不知道他们需要额外警惕。

第三，用户已经建立了基于过去经验的信任。一个在Opus 4.6初始版本上测试了自己工作流程的开发者，建立了”这个工具在我的使用场景下是安全的”这样的判断。他没有理由知道5周后，这个工具已经变成了另一个版本，安全属性已经悄悄改变。

行业需要的不是承诺，而是可验证性

这场质量危机最终指向一个行业级别的结构性缺失：

AI编程工具的质量保障体系，还停留在云服务的”信任我们”阶段，而没有进化到企业软件的”验证，然后信任”阶段。

具体来说，最紧迫的是两个层面的改变：

第一，安全性回归基准的公开化。

Veracode已经证明这件事的可行性：一套标准化的80道任务，定期测量AI模型在代码漏洞引入率上的表现。这不是什么前沿技术，而是软件行业基本的质量可见性要求。

AI代码工具供应商应该在每次模型版本发布时，公开对应的安全性基准数据：这个版本在标准化测试集上的漏洞率是多少？与上一版本相比有什么变化？影响哪些编程语言和任务类型？

这不仅仅是透明度的问题，更是让市场发挥作用的前提条件。如果Anthropic公开Opus 4.7的漏洞率是52%，OpenAI模型的是30%，企业用户会做出有知情的决策。市场压力，会比监管要求更快地推动质量改善。

类比传统软件：许多企业在采购安全产品时，会要求供应商提供第三方渗透测试报告。AI编程工具也应该走到这一步——供应商提供，或至少允许第三方提供，代码安全质量的可验证证明。

有一个可以参考的先例：GitHub在2023年推出了GitHub Advanced Security服务，允许企业对代码库进行自动化安全扫描，并公开统计了”由AI Copilot辅助修复的安全漏洞数量”。虽然这是正向数据（展示修复），而非漏洞引入数据，但它建立了一个”AI工具与代码安全性可被量化关联”的先例。Anthropic完全可以基于类似框架，公开”Claude辅助生成的代码中，已知安全漏洞类型的检测率”作为透明度基准。

第二，模型行为变更的明确通知机制。

Boris Cherny”调低thinking effort”这件事，最大的问题不是决策本身（调低thinking effort或许在某些场景是合理的权衡），而是这个决策对用户完全不透明。

一个可行的最低标准是：任何影响模型核心行为参数的变更（包括thinking effort、安全过滤器设置、推理深度等），都应该以”模型行为更新日志”的形式公开，并在变更时向企业客户发送通知。这不要求技术细节全部公开（那涉及竞争敏感信息），但至少需要告知：”本次更新改变了模型在代码生成任务上的推理深度，可能影响代码复杂度较高任务的安全属性。建议在部署前重新评估代码审查流程。”

这个标准，目前没有任何主流AI代码工具供应商达到。

OpenAI、Microsoft Copilot、Google Gemini Code、Anthropic Claude——在这两个核心维度上，2026年4月，没有一家做得足够好。

结语：那个被调低的”thinking effort”

Boris Cherny那条关于”调低thinking effort”的推文，是整件事情最值得反复咀嚼的细节。

一个被调低的参数，在用户体验层面的体现是：token账单少了一点，响应速度快了一点。在代码安全层面的体现是：47.3%的质量下滑，52%的漏洞率，和一家NSA级别的安全公司决定停止使用这个工具。

这不是关于Anthropic善意与否的故事。这是关于AI工具商业化过程中，用户体验优化和安全保障之间的隐性冲突，正在如何在没有被意识到的情况下，悄悄做出错误的取舍的故事。

对企业和工程师的直接建议：

在整个行业建立起更完善的AI代码安全可验证标准之前，每个工程团队需要做的事情其实很简单，但必须制度化：

  1. 把”所有AI生成的代码都必须经过人工安全审查”写成不可妥协的工程铁律——不是因为工具不好，而是因为任何工具都有你不知道的质量波动。
  2. 在使用AI编程工具之前，用同等复杂度的任务做一次基准测试，建立自己的质量基准线；每隔一段时间重测，感知是否有退化。
  3. 对安全关键代码（身份验证、加密、输入校验、权限控制），永远不要依赖AI生成，人工编写和审查。

Dave Kennedy建自己的本地模型是他的方式。但并非所有团队都有这个资源。上述3点，任何规模的工程团队今天就可以执行。

对行业和供应商的更长期问题：

AI代码工具供应商也需要重新思考产品责任边界。当你向企业客户销售一个”提升工程师生产力10倍”的工具，并以此为卖点，将这些客户的代码生产流程重构在自己的API上，你是否也同时承担了对代码质量的部分责任？

这个问题在2026年的法律框架下还没有答案，但在越来越多的安全事故与AI生成代码建立因果关联之后，这个问题终究会得到一个不由供应商单独决定的回答。

因为从2026年4月22日的数据来看，你正在使用的AI编程工具，在超过一半的任务中，会为你的代码库里悄悄植入一个漏洞。

而你并不知道。

参考资料:

  • Forbes, Thomas Brewster, “Anthropic’s Claude Is Pumping Out Vulnerable Code, Cyber Experts Warn”, 2026-04-22: https://www.forbes.com/sites/the-wiretap/2026/04/22/anthropics-claude-is-pumping-out-vulnerable-code-cyber-experts-warn/
  • The Register, “AMD AI executive says Claude Code has become ‘unusably bad’ for complex engineering tasks”, 2026-04-06: https://www.theregister.com/2026/04/06/anthropic_claude_code_dumber_lazier_amd_ai_director/
  • Simon Willison’s Weblog, “Is Claude Code going to cost $100/month?”, 2026-04-22: https://simonwillison.net/2026/Apr/22/claude-code-confusion/