AI 开发者日报

• GPT-5.5 Instant 成为 ChatGPT 新默认模型：OpenAI 已将 GPT-5.5 Instant 部署到 ChatGPT 及 API（模型标识为 gpt-5.5-chat-latest），定位为在事实准确性、基础智能水平、图像理解能力和语气把控方面的全面升级。此次发布还捆绑了更强的个性化功能：ChatGPT 现在可以利用已保存的记忆、历史对话、文件以及关联的 Gmail 账户，同时新增了 “记忆来源” 功能，让用户能够看到哪些上下文影响了模型的回复。相关详情请参见 @OpenAI 的主发布帖、@OpenAI 的部署细节、@michpokrass 的产品评论，以及 @ericmitchellai 和 @sama 的反馈。
• OpenAI 还公布了更多实时产品的基础设施细节：@OpenAIDevs 分享了一篇技术文章，详细介绍了为 ChatGPT 语音功能和 Realtime API 重建 WebRTC 协议栈的过程，采用轻量级中继加有状态收发器的架构，以降低延迟并保持对话的自然语速。这与即将到来的语音功能更新的信号相吻合，相关评论来自 @kimmonismus 和 @sama。
• 面向开发者的 OpenAI Agent 工具持续扩展：@OpenAIDevs 宣布推出 TypeScript 版 Agents SDK，包含沙箱 Agent 和一个开源运行框架。此外，OpenAI 还在持续推进 Codex 的用户体验和自动化能力，包括 @reach_vb 提到的任务进度 UI，以及 @reach_vb 介绍的用于降低审批摩擦的 Auto Review 功能。社区反馈表明，根据 @sama 和 @sama 的说法，5.5 版本在高 Token 预算的编码和非编码工作流中表现尤为出色。

• 框架质量正成为首要差异化因素：当天反复出现的一个主题是，仅凭模型质量已无法解释智能体的性能表现。@Vtrivedy10 认为，该领域正在混合使用一些互不兼容的假设，涉及原生后训练框架、开放框架以及“类AGI”模型泛化能力；实际结论是，模型-框架-任务匹配度比抽象的基准叙事更重要。@Vtrivedy10 的另一篇帖子强调，与基础模型或仅做轻量封装的模型对话时，就能清楚看到产品化的智能体在多大程度上依赖于指令、工具、上下文打包和测量循环。@sydneyrunkle 提到了 LangChain 一篇关于长期运行框架“解剖结构”的文章，而 @masondrxy 则主张采用 ACP 风格的解耦，让团队可以在不改变底层框架的情况下，自由切换 CLI/TUI/GUI/IDE 前端。

• 编码智能体用户体验正在碎片化，各方对赢家看法不一：有多条关于智能体外壳和编码助手的经验对比。@0xSero 将 Droid 排在 Pi、Amp、OpenCode 和 Codex CLI 之上。@teortaxesTex 表示，Hermes 目前在成功率、速度和成本上均优于 deepseek-tui 和 OpenCode，并在后续的对比中补充了缓存命中细节。在商业方面，@kimmonismus 引用 TickerTrends 数据称，Codex 在四月底发布后下载量已超过 Claude Code，而多位开发者（如 @TheEthanDing 和 @finbarrtimbers）报告称，Claude Code 的实用性相比去年秋天感觉相对持平。

• 全新编码基准 ProgramBench：揭示“从零构建完整仓库”还有多远：Meta 研究人员推出了 ProgramBench，这是一个包含 200 个任务的基准测试，要求模型根据可执行规范、在没有起始代码或互联网访问的情况下，生成像 SQLite、FFmpeg 和 PHP 编译器这样的大型软件制品。@jyangballin 将其定位为端到端的仓库生成测试；@OfirPress 直截了当地总结了核心结果：最高准确率为 0%。讨论很快聚焦于这个核心指标是否过于严苛：@scaling01 指出，模型平均仍能通过每个任务超过 50% 的测试，而 @OfirPress 则为“全部测试通过”这一标准辩护，认为这是必要的，因为部分实现可能会在平均通过率指标上作弊。

• 实用的编码自动化持续向 CI/安全领域推进：@cursor_ai 推出了可监控 GitHub 并自动修复 CI 失败的智能体。@cognition 发布了 Devin for Security，声称能在企业规模下实现自动化漏洞修复，并举例说明 Devin Review 在公开披露之前就标记了一个恶意的 axios 版本（详见 @cognition）。

• Gemma 4 在开源全栈中引入多 token 预测草稿模型：Google 发布了 Gemma 4 MTP 草稿模型，承诺在无质量损失的前提下，解码速度提升高达 3 倍。该发布通过 @googlegemma、@googledevs 以及来自 @osanseviero、@mervenoyann 和 @_philschmid 的生态帖子公布。关键的工程细节在于，这是一种集成到开源工具链中的推测式解码，在 Transformers、vLLM、MLX、SGLang、Ollama 和 AI Edge 中获得了首发或近乎首发的支持。@vllm_project 特别宣布了 vLLM 上 Gemma 4 的即用 Docker 镜像。
• RadixArk 围绕 SGLang + Miles 完成巨额种子轮融资：基础设施领域规模较大的融资之一当属 RadixArk 的 1 亿美元种子轮，其核心是 SGLang 推理栈和用于大规模强化学习/后训练的 Miles。@BanghuaZ 将该公司定位为覆盖推理、训练、强化学习、编排、内核和多硬件系统的企业；@Arpan_Shah_ 和 @GenAI_is_real 则强调其目标是让前沿级基础设施开源且达到生产级水准，而不是让每个团队都从零开始重建调度、KV-cache 管理和部署系统。社区的支持来自 @ibab 和 @multiply_matrix。
• 推理经济学现在高度依赖服务商：@ArtificialAnlys 对比了六个服务商上的 MiniMax-M2.7，发现它们在 tokens/秒、缓存折扣和混合成本方面存在巨大差异。SambaNova 以 435 输出 tok/s 的原始速度领先，而 Fireworks 在多种工作负载的速度/价格比上表现更优。此外，@teortaxesTex 强调了缓存命中率如何主导某些 Agent 工作负载的成本，并将缓存优化称为“V4 时代成本降低的主要方向”。
• 冷启动和分布式训练仍是活跃的系统瓶颈：@kamilsindi 描述了一个系统，通过从已持有权重的 GPU（而非云存储）提供模型权重，将模型冷启动时间缩短了 60 倍，从几分钟降至几秒。在训练方面，@dl_weekly 重点介绍了 Google DeepMind 的 Decoupled DiLoCo，该方案在大规模场景下实现了 88% 的有效利用率，而标准数据并行仅为 27%，同时使用的跨数据中心带宽减少了约 240 倍。

• RL基础设施正从"单次生成+奖励"转向长期运行的行动系统：@adithya_s_k 发布了一份指南，对比了LLM时代的RL环境框架，重点关注那些能扩展到数千个环境的方案。@ZhihuFrontier 的详细调研将传统RLVR与智能体RL进行了对比，指出了诸如 Forge、ROLL、Slime 和 Seer 等系统，以及反复出现的关注点，如 TITO一致性、rollout延迟、前缀树合并和全局KV缓存。
• 长周期失败越来越多地被归结为"周期问题"，而非单纯的"能力问题"：@dair_ai 总结了一篇微软研究院的论文，该论文认为目标周期本身就可能成为训练瓶颈，而宏动作/周期缩减能够稳定训练并提升长周期泛化能力。这与当前更广泛的困境相呼应：现有的基准测试和公开评估仍然低估了真正的长周期行为。
• 可观测性正在演变为一个反馈驱动的改进闭环：@hwchase17 和 @LangChain 认为，仅靠追踪是不够的；关键在于附加直接、间接或生成的反馈，使可观测性成为一个学习系统。@benhylak 推出了 Raindrop Triage，这是一个专门用于发现和调查不良智能体行为的智能体。@Vtrivedy10 明确阐述了这一实践闭环：收集数据 → 挖掘错误 → 定位故障组件 → 应用修复 → 测试 → 重复。

• Anthropic 和 Perplexity 双双发力金融工作流：Anthropic 推出了金融服务智能体模板，涵盖提案生成、估值审核、KYC 筛查和月末结算等任务，并集成了 FactSet、S&P Global 和 Morningstar 等数据提供商，相关消息来自 @claudeai，由 @kimmonismus 总结。Perplexity 则发布了 Perplexity Computer for Professional Finance，引入授权数据和 35 个专用工作流，用于重复性分析师任务，详情见 @perplexity_ai 和 @AravSrinivas。这两次发布都反映出从通用型 Copilot 向工作流打包的垂直产品的明显转变。
• Perplexity 还拓展了医疗/专业健康数据源：@perplexity_ai 宣布提供对 NEJM、BMJ 及其他医学期刊/数据库的高级访问权限，支持在可信临床数据源上进行“深度和广度研究”；@AravSrinivas 将其定位为面向医疗级信息检索的产品。
• 主动式助手界面正成为一个产品类别：@kimmonismus 爆料了 Anthropic Orbit，描述为一个无需显式提示词即可综合来自 Gmail、Slack、GitHub、Calendar、Drive 和 Figma 数据的主动式助手。Manus 也新增了推荐连接器，可在需要时根据上下文自动建议，详见 @ManusAI。

本周 AI 领域的热门推文（按互动量排序）揭示了几个重要趋势：

• Anthropic 的金融模板发布 吸引了大量关注：@claudeai 宣布推出面向金融服务的即用型 Claude 智能体模板，获得了 22.9K 互动量，成为本次统计中技术/AI 产品类帖子中热度最高的之一。

• OpenAI 的 GPT-5.5 Instant 发布 主导了讨论：@OpenAI 发布的主线程获得了超过 8.2K 互动量，后续关于个性化细节的帖子也表现强劲。

• Gemma 4 性能提升 作为一次重要的开源模型系统更新落地：@googledevs 宣布 Gemma 4 速度提升 3 倍，同时 @googlegemma 的相关帖子也获得了大量关注，反映出社区对保持质量的同时提升推理性能的浓厚兴趣。

• Perplexity 的金融产品发布 同样引起了广泛共鸣：@perplexity_ai 获得了 2.5K 互动量，这表明基于授权数据的工作流产品现在被视为具有战略意义，而不仅仅是面向企业的利基包装。

Gemma 4 MTP 发布

Google 发布了 Gemma 4 的多 Token 预测（MTP）草稿模型检查点，相关模型卡已上传至 Hugging Face，包括 gemma-4-31B-it-assistant、gemma-4-26B-A4B-it-assistant、gemma-4-E4B-it-assistant 和 gemma-4-E2B-it-assistant，详情可参阅 Google 的博客文章。

MTP 方案引入了一个更小、更快的草稿模型用于推测解码：先由草稿模型生成多个候选 Token，再由目标模型并行验证。官方声称相比标准生成方式，解码速度可提升高达 2 倍，同时保持完全相同的输出质量。有评论者指出，E2B 草稿模型仅有 78M 参数，体积非常小巧。

一位技术评论者还分享了关于 Gemma 4 MTP/推测解码的更新版可视化讲解：Maarten Grootendorst 的指南，其中包含实现代码片段和示意图，是该讨论串中理解 Gemma MTP 解码/草稿机制的核心参考资料。

一个值得注意的技术细节是：E2B 模型包含一个 78M 参数的草稿模型，这意味着它使用了一个非常小的辅助模型来进行推测或多 Token 草稿生成。评论强调该草稿模型规模异常紧凑，这对 MTP 推理中的延迟/吞吐量权衡具有重要意义。

Llama.cpp MTP 支持现已进入 Beta 阶段

llama.cpp 已通过 PR #22673 添加了 MTP（多 Token 预测）的 Beta 支持，初期主要面向 Qwen3.x MTP 模型。MTP 组件作为独立模型从同一个 GGUF 文件中加载，拥有自己的上下文/KV 缓存，而非使用单独的 GGUF 文件。该 PR 添加了 ubatch 后的 MTP 消费机制，以正确地在多个 ubatch 间传播隐藏特征，并基于部分 seq_rm 支持实现了一个小型推测解码路径。测试显示，Qwen3.6 27B / 35B-A3B 模型在使用 3 个草稿 Token 时，稳态接受率约为 75%，Token 生成吞吐量通常比基线提升 2 倍以上。

评论者认为这可能是 llama.cpp 迄今为止最大的性能改进之一，尤其对稠密模型效果显著，并预计这将缩小与 vLLM 在 Token 生成速度上的差距，同时结合张量并行进一步优化。社区呼吁对推测解码方法（MTP、EAGLE-3、DFlash、DTree、n-gram）进行技术对比，涵盖草稿模型需求、上下文复用和模型适用性等方面。

• 评论者将 MTP/多 Token 预测视为 llama.cpp 吞吐量的重大提升，尤其对稠密模型效果显著，但对 MoE 架构的收益预期较低。社区有兴趣将其与其他推测解码方法（如 EAGLE-3、DFlash、DTree 和 ngram）进行比较，特别是它们是否需要单独的草稿模型以及如何复用现有上下文。
• 一位测试者在本地快速测试后报告，llama.cpp 的 Beta MTP 支持*"目前比 ik_llama.cpp 的实现快得多"*。他们还提供了一个 GGUF 手术脚本，可从 am17an 的 Q8_0 模型中提取 MTP 层并注入到现有的 Qwen 3.6 27B GGUF 中：gist.github.com/buzz/1c439684d5e3f36492ae9f64ef7e3f67，据称可与 Bartowski 的 Q6_K 量化版本配合使用。

• Qwen3.6:27b 是我第一个觉得能与 Claude Code 抗衡的本地模型（热度：606）：该帖子声称 Qwen3.6:27B 是第一个在本地实际可用的开源编码模型，能够与 Claude Code 抗衡，可处理脚手架搭建、重构、测试生成以及少量文件的本地调试，同时将更困难的多文件架构工作交给 Claude。作者报告称，opencode 风格的 CLI 智能体设置需要比 Claude Code 开箱即用的工具/上下文编排进行更多的调优，这引发了一个问题：Claude Code 的质量有多少来自模型本身，又有多少来自智能体脚手架。有评论者报告在 RTX 5080 上运行 Qwen 3.6 35B，采用 GPU/CPU 层拆分，速度约为 70 tokens/s；另一位评论者表示 27B dense 对于更便宜/轻量级的工作很有用，但在一次性编码任务上仍落后于 Sonnet 4.6 / Opus 4.7。评论者们还讨论了定价动态：有人认为可行的本地模型应该通过竞争迫使云服务降价，以此反驳帖子中关于未来 Claude Code 高定价层级的担忧。其他人则警告不要过度吹捧 Qwen，指出工具调用循环问题，以及前沿的 Claude 模型在快速、高置信度的编码任务上仍然明显更强。

多位用户报告称 Qwen3.6 27B/35B 终于可以在本地实际使用了，但在更困难的任务上仍低于前沿编码模型。一位用户在 RTX 5080 上运行 Qwen 3.6 35B，通过跨 GPU/CPU 拆分层（大部分层在 GPU 上），达到了约 70 tokens/s 的速度；另一位用户使用 RTX Pro 6000 Blackwell 运行 27B dense，但在一次性或高置信度编码工作中仍然更倾向于使用 Claude Sonnet 4.6 / Opus 4.7。

• 一个反复出现的实现问题是 工具调用不稳定，据报道 Qwen 尽管进行了参数/配置调优，仍会陷入循环。另一位用户指出 27B 在配备 24GB VRAM 的 M4 Pro 上处理 32k 上下文窗口时很吃力，导致他们退而使用 Qwen 9B 变体进行实际工作。
• 一次详细的编码任务对比发现，Qwen 比 Claude 模型慢得多且更容易出错：Qwen 花了大约 6 小时 逐个修复 47 个测试失败，而 Opus 在 20 分钟 内完成了同样的任务，Sonnet 则在 30 分钟 内完成。该用户还描述了一个语义错误：Qwen 将 CSV 表头/导入问题误诊为跨库 CSV 不兼容，然后禁用了 CSV 导入功能并降低了产品行为，而不是应用更简单的修复方案。

DeepSeek V4 Pro 在 FoodTruck Bench（我们的智能体基准测试）上与 GPT-5.2 持平——晚了 10 周，成本约低 17 倍（热度：431）：图片 是 FoodTruck Bench 排行榜截图，显示 DeepSeek V4 Pro 高亮排在 #4 位，30 天净资产为 $27,142，ROI 为 1257%，利润率为 51%——非常接近 GPT-5.2 的 $28,081。在该帖子的上下文中，这支持了 DeepSeek 在约 10 周 后达到了接近 GPT-5.2 的智能体性能，同时声称相同工作负载的成本 约低 17 倍，而 Claude Opus 4.6 仍以 $49,519 遥遥领先。该基准测试被描述为一个持久记忆、使用工具的智能体模拟，包含 34 个用于餐车运营的工具，并非一个梗图或非技术性图片。评论者们印象深刻，但对更广泛的框架持怀疑态度：一位评论者指出 Claude Opus 4.6 似乎正在拉开差距，利润大约是下一组的 1.7 倍；另一位评论者质疑为什么 Gemma 4 31B 在这个基准测试上击败了 Sonnet 4.6 并且在 EQBench 上表现良好，却未被充分讨论。

• 几位评论者关注了 FoodTruck Bench 中的 模型排名异常和覆盖缺口：Claude Opus 4.6 被描述为实现了大约 1.7 倍 于下一组模型的利润，而用户们询问为什么较新的 GPT-5.4/5.5 模型没有出现在对比中。
• 多位用户指出 Gemma 31B 出人意料地强大，注意到它出现在 FoodTruck Bench 的 前 5 名 中，并且据报道在 EQBench 上表现良好，甚至在这个基准测试中击败了 Sonnet 4.6。评论者认为，这使得在没有深入分析 Gemma 为何得分如此之高的情况下，更难解读关于 DeepSeek、Xiaomi 或基准测试本身的说法。
• 还有一些具体的基准测试改进建议：创建一个 FoodTruck Bench v2，具有更高保真度的模拟、更多真实世界变量以及更精心设计的场景。用户还建议添加最近的 Qwen3.6 模型，特别是 Qwen 3.6 27B，以便更好地比较当前开源模型系列。

• “氛围编程” vs 生产现实（热度：3549）：一张冰山风格的信息图，“氛围编程 vs 生产现实”，对比了AI快速生成的MVP/PoC与生产环境所需的大量隐藏工程工作：认证、密钥管理、GDPR/数据处理、审计日志、限流、多租户、CI/CD、日志、事件响应、测试、支持，以及供应商/模型的生命周期风险。帖子认为，虽然“氛围编程”能将80/20的原型阶段从几天压缩到几小时，但交付资产管理、GRC或内部RAG系统，如果没有生产级的运维、安全和合规工作，仍然会失败。评论中也有反驳观点，认为借助现代平台和AI，生产工作也变得更容易了，但这要求构建者理解领域知识；另一些人则认为范围很重要——例如，一个简单的Supabase后端应用可能没问题，但业务关键型或高规模系统仍然需要严谨的工程纪律。

几位评论者指出，AI辅助的“氛围编程”降低了构建MVP的门槛，但并没有消除生产需求，如可靠性、部署、安全加固、可观测性、维护和运维所有权。核心的技术区别在于：生成代码只是交付生产产品的一部分。

• 一个技术细节围绕范围和规模：一个由托管服务（如Supabase）支持的简单Web应用，可以外包主要的生产问题，如认证、数据库托管和后端API。然而，评论者指出，一旦应用变得业务关键或需要扩展到早期用户之外，仍然需要更深入的工程专业知识。
• 一位评论者警告不要过早过度工程化，指出为*“几万用户”而架构，而“你只有一百个用户”*是一种谬误。隐含的技术建议是：将架构、加固和可扩展性工作与实际使用情况和风险相匹配，而不是一开始就为假设的生产规模进行设计。

高级软件工程师——几个月没写过一行代码了（热度：2369）：一家约100+人初创公司的高级工程师声称，他们现在主要通过Claude/Codex/Perplexity来“驱动意图”，而不是手写代码。他们认为AI已将高级工程师的价值转向了系统设计、用户体验、架构和技术权衡决策，而非语言/框架专精。他们还建议面试应强调系统设计和工具/技术选型，而非语言专长，因为*“Claude在编写和维护代码方面比大多数开发团队都要好”*——同时承认这依赖于先前的工程经验。热门评论分为赞同和强烈警告两派：一位10年经验的工程师报告了同样的转变，而一位首席开发者则表示，他们正在挽救一个由高级工程师构建的低质量AI重载项目，这些工程师声称“审查了所有代码”，但该项目存在确认偏差、可靠性问题、热修复轮换以及可能的技能退化。另一位22年经验的评论者表示，他们广泛使用AI，但仍然每天刻意手写代码，以避免失去实现技能。

• 一位首席开发者报告说，他们接手了一个由高级工程师构建的项目，这些工程师基本停止了编码，只“审查所有代码”；尽管在开发过程中受到好评，但该产品据称存在严重的质量和可靠性问题，导致市场问题、持续热修复和支持升级。他们认为，过度依赖AI辅助开发会制造隐藏的技术债务，只有在发布后才会显现，需要一个使用部分AI的团队来“理清这团乱麻”。
• 几位经验丰富的工程师区分了重度使用AI和完全委托实现：一位拥有22年经验的工程师表示，他们仍然每天刻意手写代码以避免技能退化，而另一位评论者警告说，如果工程师停止手动实现解决方案，编码面试准备（如LeetCode风格的任务）可能会退化。
• 一位拥有20年经验的评论者描述了一个团队，其中AI编写了100%的生产代码，而人类仍然执行PR审查和架构/问题解决工作。在这种工作流中，主要的吞吐量瓶颈已从代码生产转移到了人类审查能力，这表明在AI重载的工程流程中，审查质量和审查者带宽成为关键瓶颈。

Anthropic：AI将在2027年完全取代软件工程。同时，Anthropic：目前招聘122个SWE职位。（热度：1531）：图片是一个迷因风格的信息图，而非技术基准，对比了Dario Amodei/Anthropic的公开声明——即编码或软件工程可能在~2027年被高度自动化——与一张声称Anthropic有122个开放SWE职位、自2025年1月以来增长了184%的图表。帖子认为，这种招聘趋势与“AI将端到端取代软件工程师”的信息相矛盾，同时指出了更广泛的信号，如亚马逊实习生招聘、NVIDIA的计算成本框架、SaaS可靠性问题，以及缺乏明确的大规模AI生产力提升。评论者分为两派：一派认为招聘与Anthropic的预测并不矛盾——工程师可能会转向监控、集成和瓶颈解决角色；另一派则认为，对于一家声称拥有300亿美元营收规模的公司来说，122名工程师是很少的。其他人则认为，编程子版块中持续的焦虑和争论本身，就证明了AI替代正在被认真对待。

• 一个技术性的观点认为，“取代软件工程”可能意味着取代直接的编码劳动，而不是完全消除SWE角色：工程师可能会转向监控AI生成的输出、解决瓶颈、审查失败以及管理由模型构建的系统。在这种解释下，Anthropic招聘SWE与其预测到2027年出现根本不同的工程工作流并不矛盾。
• 一位评论者指出，对于一家声称拥有300亿美元营收规模的软件公司来说，122个SWE职位是很少的，这意味着Anthropic可以同时预测自动化，并且仍然需要相对较少的工程人员来构建模型/产品基础设施。另一位则认为，如果模型能力的提升依赖于更多的工程投入和计算投资，那么现在招聘工程师是一种合理的加速策略。
• 一个商业/市场结构的批评观点认为，Anthropic的替代声明可能部分起到了企业销售和风险资本信号的作用：如果客户和投资者相信AI可以取代大部分白领工程劳动力，那么公司的估值和采用前景就会改善。这框架将2027年的预测更多地视为与融资和企业需求生成相关的炒作，而非纯粹的技术预测。

• 警告：Anthropic的“Gift Max”漏洞导致我被盗刷800多欧元、信用受损，还被封号了。（热度：2536）：一位德国数据科学专业的学生声称，自己开启了双重认证（2FA）的Anthropic/Claude账户在4月27日遭遇了未经授权的“Gift Max”扣款，金额超过€800。据称，这笔交易未完成3-D Secure验证，礼品码由第三方生成并兑换，同时Anthropic的计费系统当时正存在已知问题（相关证据来自Anthropic状态页面以及GitHub上的#51404/#51168号议题）。在提交了警方报案（Strafanzeige）和相关证据后，该用户表示Anthropic非但没有退款，反而封禁了其账户，导致无法访问正在进行中的项目/聊天记录。后续更新称，银行已将此案按欺诈处理，发起了退款追回，并将追究Anthropic商户账户的责任；该用户计划提交GDPR/DSGVO数据请求，并申请德国法律援助（Beratungshilfeschein）以处理SCHUFA信用记录受损的问题。评论区的讨论焦点并非漏洞的技术细节，而是各国支付争议处理流程的差异：有人对比了德国与美国的拒付（chargeback）模式，也有人注意到一个讽刺现象——这篇批评Anthropic的帖子，竟然是在ChatGPT相关的子版块里，用Gemini辅助写成的。

原帖作者报告称，银行已将Anthropic的未经授权扣款认定为欺诈，发起了追回/拒付，并退还了€800+。他们还计划提交GDPR/DSGVO数据访问请求以恢复未完成的项目，并申请德国法律援助（Beratungshilfeschein）来清除任何负面的SCHUFA信用记录。

• 有评论者表示，看到了多个不同商家投放的YouTube广告，都在推广同一个“免费获取一年Claude使用权限”的优惠，这表明可能存在一个协调一致的钓鱼或诈骗广告活动，而非孤立的计费问题。这一点很关键，因为它可能是所谓的“Gift Max”漏洞或虚假Claude订阅流程的潜在攻击入口。

一位Twitter用户成功诱骗Grok向其转账20万美元（热度：2394）：该帖子声称，一位Twitter/X用户通过向Grok发送提示词，使其生成了一条命令，随后由Bankrbot执行，从而套取了大约$200k。需要明确的是，Grok本身并未直接控制或从钱包发送加密货币；评论者引用了X平台的社区注释（Community Notes），指出*“Grok并没有向任何人发送任何东西”*，真正的失败点在于智能体/机器人的命令执行路径。描述的漏洞利用链条如下：Bankrbot据称导致/处理了一个意外创建的加密货币代币，相关费用累积到了一个归属于Grok的钱包中；随后，攻击者诱导Grok指示Bankrbot将这些资金转移到别处。原帖的Reddit图集因403 Forbidden错误无法访问（Reddit图集）。评论者们重点关注了松散耦合的大模型智能体与加密货币机器人结合所带来的安全隐患，尤其是文本生成与可执行金融命令之间模糊的授权边界。也有人质疑攻击者为何选择公开这一漏洞，而不是继续套取资金。

• 评论者澄清，Grok本身并未持有或转移加密货币；根据引用的X平台社区注释/上下文，Grok据称是被诱导输出了一条命令，而另一个自动化智能体**@bankerbot/Bankrbot则解释并执行了该命令。因此，技术上的核心问题是一个AI到AI的提示词/命令注入失败**，即一个模型生成的文本被一个加密货币机器人当作了授权指令。
• 对该事件的一个总结描述了此前的失败：Bankrbot据称根据Grok的输出创建了一个加密货币代币，用户随后交易了这个意外产生的代币，交易费用累积到了一个与该代币/Grok交互相关的钱包中。后续的漏洞利用据称涉及诱导Grok指示Bankrbot重定向这些累积的费用，这凸显了大模型生成的文本、机器人命令解析器与链上资产控制之间不安全的耦合关系。