AI 开发者日报

专为中文开发者打造的 AI 技术日报,每日更新,提供文章和播客双重形式,用通俗语言解读前沿技术。 汇总 AI 开发领域的 X、Reddit 和 Discord 社区讨论,精选开发者值得关注的信息,支持 RSS 和邮件订阅。

订阅 AI 开发者日报,与顶尖开发者同步掌握 AI 最新动态

article cover image

AI 开发者日报 2026-07-13

本周AI圈动态密集:OpenAI发布GPT-5.6新分层体系(Luna、Terra、Sol等),但30多种配置引发选择困难,用户体验倒退,额度消耗快,OpenAI紧急修复;Meta的Muse Spark 1.1以高性价比和低定价给对手施压。开放模型生态有进展,Unsloth、Cohere等提升推理效率。智能体领域,GPT-5.6 Sol Ultra一小时内证明数学猜想并完成百万行代码验证,AI医疗在盲法评估中优于人类医生。安全担忧加剧,滥用案例触目惊心,政策透明度方案引发争议。编程方面,GPT-5.6在DeepSWE基准测试中性价比高,但配额计量不透明引发用户不满。两个AI辅助开发案例(53万行代码重写和15天游戏开发)显示AI编程工具正走向生产力,但开发者领域知识仍是关键。

openaigpt-5.6claude-fable-5reach_vbrasbtyuchenj_uwscaling01simonwkimmonismusthsottiaux

OpenAI GPT-5.6 发布:模型分层、Agent 用户体验与早期基准信号

  • GPT-5.6 引入了更明确的模型/算力分层:用户现在可以在 Luna / Terra / Sol 以及多个努力级别之间进行选择,社区共识倾向于“从比 5.5 更低的级别开始”。OpenAI 员工解释称,Max 意味着单个模型在难题上花费更长时间,而 Ultra 则通过子代理并行处理任务;他们还指出,5.5 到 5.6 的努力级别设置不能直接对比来自 @reach_vb 的指导后续说明实用默认设置建议)。社区反应褒贬不一:许多人赞赏新增的控制能力,而另一些人则批评30 多种配置组合以及缺少“自动”路由功能(@rasbt@Yuchenj_UW)。

  • 产品上线后出现了明显的用户体验倒退,OpenAI 迅速公开纠正:用户抱怨新的 ChatGPT Work / Codex 拆分令人困惑,聊天记录/项目更难找到,使用额度消耗速度也比预期更快(@scaling01@simonw@kimmonismus)。OpenAI 以异常直接的方式回应:多次重置使用额度限制,承认默认设置引导用户选择了过于昂贵的配置,并承诺恢复熟悉的侧边栏/导航模式,同时明确 Work 和 Codex 之间的定位(@thsottiaux 重置公告第二次重置完整纠正路线图)。

  • 初步评估情况:GPT-5.6 在智能体编码 / 演示 / 部分科学任务方面表现最强,但并非在所有领域都占据绝对优势。例如:在 Code Arena: Frontend 中与 Claude Fable 5 并列第一,而列出的 IO 定价却便宜约 2 倍Arena);在 AA-Briefcase 上创下最佳 Presentation Elo 记录,比 GPT-5.5 提升了约 500 分Artificial Analysis);CritPt 相比 GPT-5.5 有提升,并领先 Fable 5 约 4 分(Artificial Analysis);在 WeirdML 上以更低成本取得了强劲结果(@htihle)。与此同时,用户报告了指令遵循问题、实际使用中 token 效率不均衡,以及对越狱风险 / 奖励黑客攻击的一些担忧(@teortaxesTex@Mononofu@kimmonismus)。

并行Agent工作流、计算机操控与“框架即产品”趋势

  • GPT-5.6 最大的感知飞跃可能在于编排与计算机操控能力,而非纯粹的对话质量提升。多位用户指出,Sol 作为规划器/验证器/编排器表现异常出色,能够自动调用子代理,并对用户的引导做出更快速的响应(@omarsar0@Hangsiin)。OpenAI 还展示了 Sol Ultra 的计算机操控能力,并推广 ChatGPT Work,旨在将 Agent 能力扩展到消费者和移动端规模(OpenAI 演示 via @gdbWork 定位)。社区报告描述了极高吞吐量的 GUI 自动化操作以及 Blender 工作流(@mckbrando@kimmonismus)。
  • 一个反复出现的运营问题是隐藏的子代理成本激增:用户发现,生成的子代理可能会继承高级设置,导致配额消耗速度远超预期。一个具体案例是,spawn_agent 不允许用户选择模型或算力投入,因此 Sol Ultra 默认会生成更多的 Sol Ultra@evi77ain)。这符合一个更广泛的模式:人们喜欢能力上的跃升,但发现成本模型不够透明。
  • 更广泛的系统趋势是向以框架为中心的竞争演进。这一点体现在多个产品评论中:Perplexity 的 Arav Srinivas 表示“真正的产品现在是围绕它的框架”;LangChain 围绕 Deep Agents + Nemotron + OpenShell 进行产品发布;以及越来越多的记忆/编排工具,如 OpenWikiOpenSWE@dee_bosa 引用 Arav@hwchase17OpenWiki 主动记忆OpenSWE 采用情况)。核心观点是:前沿模型的能力差距正在缩小,因此价值正日益转向路由、记忆、工具使用、安全护栏和企业上下文

Meta 的 Muse Spark 1.1 与“够用、快速、便宜”模型的前沿扩张

  • Muse Spark 1.1 是当天另一个重磅模型新闻,许多从业者称其为本周最令人意外的发布。各方报告一致强调其强大的 UI/前端生成能力、快速响应以及异常激进的价格策略,通常认为在大量编码/产品任务上已接近前沿水平(@alexandr_wang@rowancheung@kimmonismus)。
  • 基准测试表明确实有显著提升,但尚未达到绝对领先地位。Artificial Analysis 将 Muse Spark 1.1 在其智能指数上评为 51 分,相比 1.0 版本提升了 8 分,大致与 GLM-5.2 / GPT-5.4 / GPT-5.6 Luna 持平,落后于 Grok 4.5 / GPT-5.6 Sol / Claude Fable 5。值得关注的细节包括:100 万上下文,中位速度约 114 tok/s,定价为 每 100 万输入/输出 token 仅需 $1.25 / $4.25,且 token 效率出色(Artificial Analysis)。Arena 也将其列为 Code Arena: Frontend 第 9 名,在指令遵循和长查询类别上取得了显著进步(Arena)。
  • 许多人从中得出的战略启示是:Meta 在算力上的重注开始转化为高性价比的推理产品,而不仅仅是人才争夺的头条新闻。多位评论人士认为,这实质上加大了对 OpenAI/Anthropic 的竞争压力,尤其是如果 Meta 能改善其分发渠道和 API 易用性的话(@scaling01 呼吁接入 OpenRouter@alexandr_wang@mweinbach)。

开放模型、基础设施与效率优化

  • 尽管闭源模型吸引了大量关注,但开放模型的工具链仍在持续交付。Unsloth 发布了 Qwen3.6 NVFP4 量化版本,声称推理速度提升 2.5 倍,其中包括可在 24GB VRAM 上运行 27B 模型,以及 35B-A3B 变体在 B200 上达到 17,561 tok/sUnsloth技术细节来自 @danielhanchen)。QuixiAI 报告称,Qwen3.6-35B-A3B-NVFP4 在双 B60 上以 65 tok/s 的速度运行,并支持 128k 上下文QuixiAI)。
  • 推理优化仍然是一个重要的活跃研究领域。Cohere 在 vLLM 中开源了 硬件感知的动态推测解码(Hardware-aware Dynamic Speculative Decoding),解决了那个常见问题:推测解码在低批量大小时有帮助,但在高批量大小时反而会拖慢速度(Cohere/vLLMvLLM 评论)。Google/Hugging Face 的 Gemma 挑战赛报告称,单张 A10G 上推理速度提升最高达 5 倍,其中 无损 315 TPS,最快整体达到 491.8 TPSGemma)。
  • 智能体评估与自我改进工作正变得更加具体:“LLM-as-a-Verifier”在 Terminal-Bench V2、SWE-Bench Verified、RoboRewardBench 和 MedAgentBench 上报告了 SOTA 结果,采用重复采样加分数对数概率排名的方法(论文讨论串);Meta 的研究人员提出了一种显式记忆智能体,用于对抗长周期智能体中的行为状态衰减问题(摘要)。

科学、数学、健康与模态专属系统

  • 数学/科学能力宣称急剧升级。OpenAI 员工及社区成员流传出示例,显示 GPT-5.6 Sol Ultra 在不到一小时内,利用 64个子智能体 生成了对 Cycle Double Cover 猜想 的所谓证明(来自 @eknight 的宣称经 @gdb 放大传播)。此外,Bubeck 提到,借助 GPT-5.6,单人完成了 100万行 Lean 形式化验证 的工作(@SebastienBubeck)。这些仍是有待外部审查的宣称,但它们指明了实验室希望叙事走向何方:将并行化研究智能体视为一种科学计算原语
  • 健康正成为一级基准测试和产品垂直领域。OpenAI 表示,GPT-5.6 在 健康智能 方面迈出了重大一步,并强调 最低努力水平的 Luna 击败了最高努力水平的 GPT-5.5,同时成本降低了 25 倍OpenAI)。Karan Singhal 补充说,在涉及 20,000 个轴评分 的盲法医生对比中,在一组困难任务上,医生发现 GPT-5.6 回答中的缺陷比医生自己撰写的回答更少详情)。
  • 音频/音乐及创意工具也有进展:Kyutai 与 Mirelo 发布了 MuScriptor,这是一个开源模型,能够从 完整混音(而非分轨) 进行 多乐器音频到 MIDI 的转录MireloAIKyutai)。Sakana 的新工作借鉴了 Picbreeder 风格,探索了 利用 VLM 智能体进行开放式创意生成,结论是多样化的智能体群体虽有帮助,但仍未达到人类开放式探索的水平(Sakana)。

安全、保障与政策摩擦

  • 安全担忧随能力提升而加剧。OpenAI 将其 Bio Bug Bounty(生物漏洞赏金计划) 转为内部持续项目,并将赏金翻倍至 5 万美元,专门征集针对预设生物安全挑战的通用越狱方法(OpenAI)。此外,OpenAI 收紧了对其最具网络能力模型的访问要求,自 9 月 1 日起,Trusted Access for Cyber 成员需使用硬件安全密钥@cryps1s)。
  • 滥用证据依然触目惊心:一项新研究报告称,博科圣地成员使用前沿聊天机器人进行炸弹制造及相关战术查询(@AntoniaJuelich)。这条消息与网络上关于 GPT-5.6 在某些场景下可能相对容易被越狱或奖励机制攻击的讨论形成了令人不安的对照(@Mononofu)。
  • 政策讨论仍处于两极分化且充满猜测的状态。“AI 2040 / Plan A”透明度与治理方案既获得了支持也遭到了嘲讽。Ajeya Cotra 强调全面研究透明度的核心地位,而批评者则质疑其可行性以及关于超级智能/治理能力的假设(@ajeya_cotra@binarybits@banteg 讽刺评论)。

AI 动态周报:OpenAI 产品混乱、Claude 桌面浏览器、Perplexity 接入 Grok 4.5

  • OpenAI 发布与回滚管理:OpenAI 产品负责人承认了发布过程中的混乱,承诺修复 UI,并两次重置使用量,同时明确表示 Codex 不会下线完整讨论)。
  • Claude Code 桌面浏览器:Anthropic 为 Claude Code 桌面版推出了一个应用内浏览器,让 Claude 可以在应用内部浏览文档和网站(@ClaudeDevs)。
  • OpenAI 组织架构更新:Fidji Simo 宣布将辞去在 OpenAI 的全职职务,转为兼职顾问。她表示需要专注于从慢性疾病中恢复,同时继续从事与 AI 和健康相关的工作(@fidjissimo)。
  • Perplexity 能力扩展:Perplexity 在 Computer 功能中新增了 Grok 4.5 作为编排模型。内部评估显示,Grok 4.5 在 WANDR 测试中表现强劲,而成本仅为 Opus 4.8 的一半左右(Perplexity)。

GLM-5.2 本地推理与安全审视

  • 在 25GB 内存的消费级机器上运行 GLM-5.2 (744B MoE)(热度:1249):有演示声称在仅配备 25 GB 内存的消费级机器上运行了 GLM-5.2,这是一个拥有 744B 参数的 MoE 模型。其实现方式并非将完整模型常驻内存,而是从磁盘流式加载专家权重。评论者强调,该实验的技术价值不在于吞吐量——对于实际推理而言,其速度可能慢到无法使用——而在于证明了基于磁盘的专家分页是可行的;“如果有人能足够准确地预测专家路由并实现预取,整个局面将彻底改变。” 热门评论反驳了对速度和实现质量的批评,认为值得关注的成果是让一个 744B 的 MoE 模型能够在低内存的消费级硬件上运行起来。关于该项目是否是“氛围编码”存在一些元讨论,但技术评论者普遍认为这个原型令人印象深刻。

多位评论者认为,该实验之所以在技术上引人注目,是因为它展示了在仅配备 25 GB 内存的消费级机器上,从磁盘流式加载一个 744B MoE 模型的专家权重,而非将其视为一个实用的推理方案。有人指出,如果专家路由预测能够可靠地预取下一个所需的专家,那么基于磁盘的 MoE 推理延迟可能会发生显著变化。

  • 一位评论者提到,llama.cpp 可能已经通过 --mmap 提供了类似的行为,这意味着模型权重可以被内存映射,而无需完全常驻于 RAM,但这本身并不能解决 MoE 专家预取/路由的延迟问题。
  • 一位用户分享了一个极端的低资源基线:在一台配备 1 GB 内存的 x86 Atom N270 上网本上,以 1-bit 量化运行 Qwen2.5-0.5B,实现了大约 240 秒/令牌 的速度,这说明了在受限硬件上,可行性与可用性之间存在巨大鸿沟。

媒体对 GLM-5.2 的恐慌渲染(热度:907):该帖子批评了一篇 Futurism 文章,该文章声称 GLM-5.2 可以广泛下载,“几乎在任何硬件上” 使用,并且由于没有托管供应商的调解层,可能带来网络安全风险。文章引用了 SemgrepGraphistry 的发现,称 GLM-5.2 在漏洞发现/网络安全任务上表现良好,包括 Semgrep 的 “We Have Mythos at Home” 基准测试框架,但评论者认为,考虑到前沿模型的推理需求以及极端低位量化带来的性能退化,该文章关于硬件的说法在技术上是具有误导性的。评论者认为这篇文章是在制造恐慌,且技术上缺乏依据,尤其是在推理硬件的可行性方面。一个值得注意的反驳观点是,如果强大的模型能改进漏洞利用的发现,那么适当的回应是使用同样强大的模型进行修复和防御,而不是限制或审查开源模型。

  • 评论者质疑了媒体声称 GLM-5.2 可以在*“几乎任何硬件”*上运行的说法,认为一个大型前沿/开源权重模型需要大量的 GPU 投入,而非消费级 CPU;一位用户讽刺地询问,一台老旧的 4 代 i3 笔记本电脑能达到每秒多少个令牌,而另一位用户则将实际部署所需的硬件成本描述为大约 25 万美元
  • 有人对引用极端的 1-bit2-bit 量化作为广泛部署能力的证据提出了技术性质疑:评论者认为,这种量化通常会导致严重的性能退化——被描述为*“脑叶切除”*——因此无法与运行完整能力的模型相提并论。
  • 一位评论者将安全风险的争论重新定义为一种双重用途的缓解问题:如果先进的模型有助于利用漏洞,那么适当的回应是使用同样强大的模型进行防御性发现和修补,而不是直接禁止或限制这些模型。

本地大模型性能与硬件投资回报分析

1. Qwen3.6 NVFP4 Unsloth 量化:速度提升 2.5 倍

Qwen3.6 NVFP4 Unsloth 量化实现 2.5 倍加速(热度:934):文中展示的图片是 Unsloth 针对 Qwen3.6 推出的动态 NVFP4 量化方案的宣传基准测试图,声称推理速度相比 NVIDIA NVFP4 量化方案最高可提升 2.5×。报告显示 B200 吞吐量提升显著,例如 Qwen3.6-27B:5,637 vs 2,259Qwen3.6-35B-A3B:最高 11,628 vs 6,481,这归功于 W4A4 4-bit 张量核心矩阵乘法,而非 NVIDIA 的 W4A16 路径。同时,帖子中的表格显示,BF16/FP8/NVFP4 各变体在 MMLU-Pro、GPQA 和 AIME 2025 等基准测试中的得分大致相当。帖子还发布了 Hugging Face 模型链接,包括 35B-A3B-NVFP435B-A3B-NVFP4-Fast27B-NVFP4,以及 FP8 KV 缓存校准,可将上下文长度提升约 。评论者普遍认为这是 Blackwell 专属的优势,并调侃 Pascal/RTX 3090 时代的用户可能无法受益,因为加速依赖于更新的 GPU 张量核心支持。

评论者质疑 Qwen3.6 NVFP4 Unsloth 量化与标准非 NVFP4 4-bit 量化相比表现如何,特别是声称的 2.5x 加速是 Blackwell 硬件独有,还是在现有推理栈的 4-bit 格式中同样成立。

  • 关于 llama.cpp / llama-server 对 NVFP4 的支持存在技术不确定性:有用户指出 llama-server 可以运行 NVFP4,但之前的性能表现"平平无奇";另有用户询问,如果 llama.cpp 现在对 NVFP4 支持良好,为何不提供 GGUF 构建版本。
  • 多条评论暗示该优化主要适用于 NVIDIA Blackwell GPU,而 Pascal 等较老架构以及 RTX 3090 等消费级显卡不太可能从 NVFP4 加速中受益。

2. 花 4-5K 美元搭建本地 AI 设备,你还会再选一次吗?

如果你花了 4-5K 美元搭建本地 AI 设备,你还会再选一次吗?(热度:359):帖子认为,纯粹为了在本地运行前沿级大模型,花费 $4-5K 搭建本地 AI 设备很难说得上划算,尤其是当 DeepSeek V4 Flash 等 API 的定价约为 $0.14/M(未缓存输入 token)和 $0.28/M(输出 token)时。作者表示,即使在 128GB MacBook 上运行 2-bit 量化版的 DeepSeek V4 Flash,与托管模型相比仍然缺乏竞争力,尽管这套设备在学习量化、KV 缓存、上下文窗口、内存限制和模型服务等方面确实有用。作者的观点是,昂贵的本地硬件可能适用于隐私保护、始终在线的工作负载,或者当用户本身就需要这台机器时,但主要不是为了替代 Claude/ChatGPT 级别的 API 来节省成本。帖子未提供置顶评论总结。

GPT-5.6 编程基准测试:性价比碾压,还是数据可视化灾难?

GPT-5.6 编程基准测试

  • DeepSWE 刚刚将 gpt-5.6 模型加入了他们的基准测试。希望各位不要太依赖 Claude Code 作为唯一的编程代理。图表因"粗暴的暴力"被标记为 NSFW。(热度:1718):图片是一张 DeepSWE 基准测试成本/性能图表,比较了各编程代理模型的"DeepSWE 分数"与每任务平均成本。帖子重点突出了新加入的 GPT-5.6 系列作为 Claude Code/Claude 模型的强劲低成本竞争对手。图表中,GPT-5.6/5.5 系列的点大致集中在 60–70% 的 DeepSWE 分数区间,任务成本相对较低;而 Claude 模型仍具竞争力——例如 Claude-fable-5 以约 70% 的分数位居前列——但成本通常更高。评论区的讨论并未深入基准测试本身,而是几乎一致批评图表可视化质量,称其为"反人类"图表,并指向 r/dataisugly 板块。帖子中"粗暴的暴力"的说法属于夸张/梗式表达,指的是图表所暗示的 GPT 与 Claude 之间的颠覆性竞争,而非字面意义上的暴力内容。

  • GPT 5.6 在 DeepSWE 上以更低价格超越 Fable 5 达 3%。(热度:1310):图片展示了一张 DeepSWE 排行榜,其中 gpt-5.6-sol73% ±3% 的分数和 $8.39 的平均成本,超越了 claude-fable-570% ±4%,而成本远低于 Fable 的 $21.63。同时,gpt-5.6-terra 以约 4.4× 更低的成本达到了 Fable 的 70% 分数。因此,帖子的核心技术主张是关于成本调整后的编程代理性能,而不仅仅是原始基准分数。评论者更关注定价效率而非那 3 个百分点的领先优势,称 $8.39 vs $21.63 才是真正的头条新闻。他们还注意到从 GPT 5.4 的明显跃升,以及 Terra 以约四分之一成本达到 Fable 级别分数的表现。

主要技术结论是成本归一化后的 DeepSWE 性能:评论者强调 GPT 5.6 达到 73%,并将结果概括为 $8.39 vs $21.63(与 Fable 5 相比),即报告的小幅准确率领先但价格优势巨大。另一位评论者指出 Terra 以约 1/4 的成本与 Fable 持平,暗示该基准测试可能更青睐廉价的规划器/执行器配置,而非顶级前沿模型。

  • 一位用户报告了各模型家族在实际 MCP 密集型工作负载下的成本:Opus 4.8 运行成本约为 $1–$2,而 GPT 5.5 类似工作的成本约为 $0.20–$0.50,这意味着 GPT 模型的 Token 消耗或定价显著更低。但他们补充说,Opus 的输出质量仍然"处于不同层次",因此取舍不仅仅是基准分数或原始成本的问题。

  • 有评论者建议,如果 DeepSWE 的数据成立,那么使用 Opus 4.8 high + Sonnet 5 medium 的工作流,或许可以被 Sol high + Terra high(作为规划器/执行器)所取代,以更低成本获得更好的整体结果。这反映出人们对多模型路由的兴趣——用更便宜的强推理层来处理分解和执行,而非依赖单一顶级模型。

超人级别的竞技编程 AI 已经到来(热度:1068):图片展示了一张 AtCoder 世界巡回赛总决赛表演赛排行榜,其中 OpenAI 以 8300 分排名第一,几乎是第二名 tour1st4300 分)的两倍,支持了帖子中关于"超人"级竞技编程性能的说法。在链接的算法竞赛中,发帖者声称 OpenAI 解决了全部 5/5 道题,而人类选手最多只解出 3 道。相关链接包括:启发式算法排行榜启发式算法题目算法排行榜算法题目。评论者强调了差距之大——"看看那个差距"——同时有技术性观点指出,这更多属于算法设计/竞赛解题,而非通用的软件工程能力。另一个实际问题是,AtCoder 排行榜需要登录才能查看。

  • 一位评论者指出了竞技编程与更广泛软件工程之间的技术区别:该系统在算法编写方面表现出超人水平——这是编程中一个受约束的子集,专注于在竞赛条件下解决形式化问题——但并不一定意味着在端到端的生产级软件开发中也具备超人能力。

  • 多位评论者指出,支撑性的排行榜链接需要登录,这意味着在没有经过身份验证的访问权限的情况下,无法独立验证所声称的分数差距和性能表现。

2. Claude Code 大规模构建

  • Bun 的创建者 Jarred 使用 Claude Fable 5 在 11 天内将项目从 Zig 重写为 Rust,按 API 价格计算,Fable 使用费用约为 16.5 万美元。他们表示,如果手动完成,这项工作需要 3 名完全了解代码库的工程师全职工作约一年(活跃度:1159):根据 Bun 重写博文Jarred Sumner 使用预发布版本的 Claude Fable 5,通过 Claude Code 动态工作流,在 11 天内将 Bun 的 535,496 行 Zig 代码移植为 Rust。他运行了约 50 个工作流,最多同时使用 64 个 Claude 实例;按 API 等效使用量估算,费用约为 16.5 万美元,而手动重写则需要约 3 名工程师/年。整个过程使用了预先编写的 PORTING.md、持续的人工监控,以及通过独立 Claude 上下文充当审查者的"对抗性审查"机制;Bun v1.4.0 的成果报告显示,与 v1.3.14 相比修复了 128 个 bug,消除了可检测的内存泄漏,Linux/Windows 二进制文件体积缩小约 20%,Linux 启动速度提升约 10%(需 Claude Code v2.1.181+)。热门评论者对此是否具有广泛可及性表示怀疑:他们认为关键因素不仅仅是 16.5 万美元的模型使用费,而是 Jarred 对代码库的深刻理解和卓越工程能力,有人将其描述为*"一位身价百万美元的 Thiel Fellow 工程师,使用了 16.5 万美元的 Claude Credits。"* 另有人指出,按 API 价格计算会夸大实际成本/规模,以达到某种效果。

评论者们反驳了将重写主要归因于模型花费的观点:实质性的论断是,Jarred Sumner 深厚的 Bun/Zig/运行时专业知识以及对整个代码库的全面理解才是关键促成因素,大模型在此过程中扮演的是加速器角色,而非自主替代品。一位评论者将其概括为*"Bun 是由一位身价百万美元的 Thiel Fellow 工程师重写的,他使用了 16.5 万美元 的 Claude Credits,"* 暗示对于经验不足的工程师来说,复现这一成果的成本可能要高得多。

  • 一些评论对成本计算方式提出质疑,指出引用 API 定价可能会夸大实际支出(相对于内部/合同/折扣价格),而且原始 token 预算并不等同于工程能力。技术层面的质疑在于,这一成果可能无法推广:大规模语言/运行时重写需要架构判断、验证和特定代码库知识,而这些是"典型 vibe coding"工作流无法提供的。

我用 Claude Code 完全构建的水豚游戏赚了 2.5 万美元(活跃度:1463):**一位 iOS 工程师在 15 天内为 VibeJam 2026 构建了 A Game About Capybaras Delivering Food,赢得了 25,000 美元的一等奖;该项目使用了 Claude Code Opus 4.7Three.jsGPT Images-2/Grok(用于纹理)、Tripo3d(用于模型)以及 Suno/ElevenLabs(用于音频),声称 188 次提交和约 27k 行代码 100% 由 AI 编写。工作流程围绕并行 Claude Code 会话、/plan 和 AI 生成的工具展开:包括游戏内地图/地形/道路编辑器、过场动画编辑器、iOS 风格手机 UI、PS1 风格纹理管线、任务循环、堆叠物品伪物理、车辆漂移/碰撞、本地化,以及一个通过 WebSocket 以约 10 Hz 频率中继玩家状态、采用 O(n²) 扇出扩展的 Cloudflare 多人游戏大厅。热门评论大多是非技术性的:有人开玩笑说 Claude 经常建议用"水豚"作为吉祥物,还有人质疑标题的措辞,指出这笔钱来自比赛奖金而非游戏收入。

3. 前沿模型使用限制

  • GPT-5.6 Sol Ultra 令人印象深刻——前提是你作为 Plus 订阅者,只能在 12 分钟内使用它(热度:914):一位 ChatGPT Plus 用户报告称,使用 GPT-5.6 Sol Ultra 处理两个大型批量/智能体工作负载——将约 10 个 PDF 合并分析并输出约 700 页的文档,以及重新组织 Obsidian 知识库中约 700 个 Markdown 文件——尽管有重置机制,仍耗尽了其 Plus 使用配额。主要的技术反驳观点认为,该工作负载可能涉及 数百万个已处理 token:仅 700 页文档就产生了约 280k–560k 个输出 token,再加上对 700 个 Markdown 文件进行单次处理所需的约 210k–1.05M 个 token,这还不包括规划、重读、重写、重试或多智能体协作的开销。评论者们普遍反对仅通过提示次数来衡量成本,认为"两个任务"可能代表非常庞大的计算/token 消耗;最明确的共识是,OpenAI 的 配额计量器过于模糊,尽管对于 $20/月 的套餐来说,这种限流本身在经济上是合理的。

几位评论者认为,所报告的限制消耗更合理的解释是 token/计算消耗 而非提示次数:一份 700 页 的生成报告可能包含约 280k–560k 个输出 token,而处理 700 个 Markdown 文件(每个文件 300–1,500 个 token)则每次处理额外增加 210k–1.05M 个输入 token。考虑到 Sol Ultra 中的规划、重读、重写、重试以及多智能体交接,评论者估计该工作负载可能达到 数百万个已处理 token

  • 一个技术批评点是 Plus 配额的用户体验不透明:用户看到的只是一个模糊的使用计量器,而非基于计算/token 的计费模型。评论者指出,用户的抱怨是合理的,因为 OpenAI 以"消息数"或时间窗口来展示限制,而高上下文批处理任务在昂贵的多智能体模式下,消耗配额的速度会不成比例地快。
  • 一个实用建议是,除非目标是进行基准测试,否则避免在 Ultra 上运行大型上下文密集型批处理工作流;评论者指出,涉及数百个文档和长文本合成的任务,在受限的消费级订阅下效率可能很低,即使表面上的提示次数很少。