AI 开发者日报

• OpenAI 将 Codex 进一步融入日常工作流：本轮最重磅的产品发布是 ChatGPT 移动应用中的 Codex 集成，用户可以在手机上启动任务、审查输出、批准命令并远程操控执行，而 Codex 则在笔记本电脑、Mac mini 或开发机上持续运行。OpenAI 还提到，远程 SSH 现已全面可用，适用于托管远程环境；随后又增加了 hooks 以及面向企业/商业自动化的 编程访问令牌，用于 Codex 工作循环（OpenAI、OpenAI 后续、@OpenAIDevs 关于移动工作流、@OpenAIDevs 关于远程 SSH、@OpenAIDevs 关于 hooks/令牌）。此外，OpenAI 还发布了一篇关于 Codex Windows 沙箱 的技术文章，重点讨论了编程智能体在实用性与受限机器访问之间的权衡（OpenAI Devs、@gdb）。
• 更广泛的 IDE/应用生态正在向“智能体优先”的用户体验靠拢：GitHub 宣布了 GitHub Copilot 应用 的技术预览版，将其描述为一个支持并行工作流、仓库/PR 生命周期管理以及模型灵活性的桌面环境（GitHub、@adrianmg、@OrenMe）。VS Code 推出了全新的 Agents 窗口，支持多智能体、多项目工作流，通过 vscode.dev/agents 支持浏览器和移动端，改进了 BYOK 功能，并引入了终端输出压缩等令牌效率特性（VS Code、远程/浏览器支持、BYOK 更新、终端压缩）。在开源方面，Nous/Hermes Agent 新增了 Codex 运行时集成，实际上是通过 Codex CLI/应用服务器路由 OpenAI 支持的交互回合，并在 Hermes 会话中复用 ChatGPT 订阅支持的执行能力（Nous Research、@Teknium、@HermesAgentTips）。Kimi 也推出了 Kimi Web Bridge，这是一个浏览器扩展，为 Kimi Code CLI、Claude Code、Cursor、Codex、Hermes 等工具提供类人的网页交互能力（Moonshot AI）。

• LangChain 的发布栈是迄今为止最具实质性的 Agent 基础设施发布集群：SmithDB 是一个专为 Agent 追踪数据 构建的数据库，而 LangSmith Engine 则消费这些追踪数据，聚类失败模式，识别可能的代码问题，并提出修复方案和评估方法——将可观测性从被动检查转变为主动改进循环（@hwchase17，@caspar_br 谈 Engine，@bentannyhill）。社区评论强调，SmithDB 在架构上转向了对象存储，并为这种工作负载形态定制了存储/查询路径（@caspar_br 谈 SmithDB，@ngates_，中文总结）。
• LangChain 还宣布了 LangChain Labs，这是一个围绕 Agent 持续学习 的应用研究方向，其核心理念是：生产环境中的追踪数据应成为训练信号、评估依据和长期定向能力改进的来源（LangChain，@jakebroekhuizen，@willccbb，Prime Intellect 合作）。
• Agent 的执行隔离能力持续成熟：W&B/CoreWeave 推出了 CoreWeave Sandboxes，用于强化学习、工具使用和评估工作负载的隔离执行环境，并明确测试了诸如 rm -rf / 这类破坏性命令的大规模运行（Weights & Biases）。类似地，开源/本地开发工具也在 Agent 调试领域崭露头角：@benhylak 介绍了一套免费的本地 Agent 调试栈，可将追踪数据暴露给 Codex/Claude Code，用于自动生成评估脚本。

• 生态系统中反应最激烈的，是 Anthropic 对 Claude Code 使用方式的限制与重塑，尤其是针对第三方封装工具和高频程序化工作流。Theo 的帖子成为了焦点：他声称 T3 Code 的用户尽管通过官方支持的集成路径接入，却遭遇了大幅的速率限制削减；随后他取消了订阅，并鼓励其他人发布取消订阅的截图，转而向开源项目捐款（@theo 初始帖子，取消订阅，捐款号召，T3 Code 澄清）。其他知名开发者纷纷附和，抱怨 Anthropic 实际上切断了开源开发者/应用的路径，并破坏了围绕 claude -p 构建的工具链（@theo，@andersonbcdefg）。

• 另一方面，也存在更具战略性的反驳观点：一些用户认为，Anthropic 并没有义务为第三方应用提供高额补贴的固定费率 token；生态系统很可能会转向更明确的 API 计价模式，以及在昂贵与廉价模型之间进行更智能的路由选择（Sentdex，@tadasayy）。尽管如此，可见的用户流失信号不容忽视，有用户估算仅回复帖中的取消订阅行为就造成了可观的 ARR 损失（@thegenioo，Uncle Bob Martin，Theo 后续）。对于 Agent 工程师而言，实际教训非常明确：基于订阅的工具链并非稳定的平台原语；供应商/模型抽象层以及自带密钥（BYOK）路径正变得越来越不可或缺。

• Figure 的直播主导了机器人领域的讨论。该公司首先展示了 8 小时完全自主、无需人工干预的工作，随后扩展为 24/7 不间断直播，最终报告了 连续 24 小时以上无故障自主运行，在小包裹分拣任务上达到了 接近人类水平的吞吐量，并且由 完全在端侧运行的 Helix-02 驱动，针对分布外（OOD）情况具备自动重置能力——明确声称 无远程操控（Figure CEO Brett Adcock、24 小时更新、详细技术澄清、第二天直播）。反复出现的 "Bob、Frank 和 Gary" 更新虽然略显花哨，但核心信号是：在接近生产环境的运行时长下实现了持续自主运行。
• 解读出现了分歧：一方是对 Figure 本身的怀疑，另一方是对机器人技术加速发展的广泛看好。一些评论者认为，批评者低估了这些演示对近期劳动力替代的潜在影响，而另一些人则指出，质疑更多是针对 Figure 这家公司，而非 机器人技术这个整体类别（@cloneofsimo、@iScienceLuvr、@kimmonismus）。无论如何，这都算是该批次中最清晰的"持续运行时间"演示之一。

• 几个技术上意义重大的模型/研究发布值得关注：

Zyphra 的 ZAYA1-8B-Diffusion-Preview 声称相比自回归生成实现了 4.6–7.7 倍的解码加速，且质量损失有限，再次印证了扩散语言模型能够实现更经济的推理部署和更丰富的生成模式这一观点（Zyphra）。

• Datadog 的 Toto 2.0 发布了 5 个开源权重的时间序列预测模型，参数量从 4M 到 2.5B，采用 Apache 2.0 协议，声称在 BOOM、GIFT-Eval 和 TIME 基准上排名第一，更重要的是，这证明了扩展定律可能终于可以干净地适用于时间序列基础模型（Datadog、@atalwalkar、@ClementDelangue）。
• Goodfire 的可解释性文章认为，Llama 在算术运算中使用了一种几何式的“形状旋转计算器”/类傅里叶特征机制，其证据基于引导式干预而非纯粹的事后描述（GoodfireAI、后续）。

在强化学习/搜索和优化器方面的进展，有几条线索值得关注：一篇综述将大模型强化学习重新定义为 “推理工程”，涵盖 生成 / 过滤 / 控制 / 回放 四个环节，而不仅仅是 PPO 与 GRPO 之争（The Turing Post）；教学式强化学习利用特权信息主动寻找有用的推理轨迹（Souradip Chakraborty、@lateinteraction）；以及 Prime Intellect 在 nanoGPT 速度跑分基准上的自主优化器搜索，其中 Opus 4.7 达到 2930 步、GPT-5.5 达到 2950 步，在经过约 1 万次运行/约 1.4 万 H200 小时后，击败了 2990 步的人类基线（Prime Intellect、@eliebakouch）。同样值得注意的还有：Kimi K2.6 被报道为 Finance Agent Benchmark V2 上排名第一的开源权重模型（Moonshot AI），而 Ring-2.6-1T 在发布当天就获得了 vLLM 的原生支持（vLLM）。

• OpenAI 发布 Codex 移动端：从互动量和实用性来看，这是本周最亮眼的产品。用户可直接通过 ChatGPT 移动端远程控制/审查正在运行的编码代理会话（OpenAI）。
• Theo 对 Claude Code 的吐槽引发热议：围绕平台风险和基于订阅的代理工作流，开发者情绪出现了明显转变（@theo，@theo 捐赠相关讨论）。
• Figure 的人形机器人自主分拣直播：这是本周讨论度最高的具身 AI 演示之一，尤其是当直播超过 24 小时，并详细展示了其板载策略执行且无需远程操控后，热度持续攀升（Brett Adcock）。
• GitHub 的 Copilot App 和 LangChain 的 Engine/SmithDB/Labs：对于代理工程师来说，这是本轮周期中除 OpenAI 之外最重要的工具发布（GitHub，LangChain，@hwchase17）。
• Prime Intellect 的自主优化器搜索结果：这是一个值得关注的案例，展示了编码代理如何被用于开放式的机器学习优化，而不仅仅是应用开发（Prime Intellect）。

• Qwen 在 LLaMA.cpp + TurboQuant 上的多 Token 预测（MTP）（热度：514）：一个经过修改的 llama.cpp 分支为 Qwen 添加了 多 Token 预测（MTP） 支持，并集成了 TurboQuant。在 MacBook Pro M5 Max 64GB 上，报告显示速度从 21 tok/s 提升至 34 tok/s，MTP 接受率声称达到 90%；需要注意的是，原始加速比约为 62%，而非 40%。代码已发布在 AtomicBot-ai/atomic-llama-cpp-turboquant，Qwen 3.6 27B/35B 的 GGUF MTP 量化版本可在 AtomicChat/qwen-36-udt-mtp HF 集合中找到。评论者对 TurboQuant 的定位提出质疑，认为它通常比 f16、q8 或 q4 更慢；有人指出，TurboQuant 向 llama.cpp 提交的 PR 已被拒绝，因为现有的 Q4 KV 量化旋转支持已经覆盖了大部分收益，TurboQuant 的优势主要体现在 Q3 级别，而该级别下质量下降已成为问题。其他人则要求提供质量/评估数据，因为更高的推测性/MTP 接受率和 tokens/s 并不能单独证明输出质量的一致性。

多位评论者认为，TurboQuant 在 llama.cpp 中并非普遍更快，有人指出它可能比 f16、q8 或 q4 更慢。此前 TurboQuant 向 llama.cpp 提交的 PR 据称已被拒绝，原因是 llama.cpp 已经实现了 Q4 KV 缓存量化的旋转操作，标准 Q4 更快且几乎没有额外收益；TurboQuant 可能仅在 Q3 级别有帮助，但伴随明显的质量下降。

• 用户区分了速度、质量和上下文之间的权衡：建议使用 不带 TurboQuant 的 MTP 来提升速度，而标准 Q4_1 或 Q4_0 量化则推荐用于更长的上下文和更好的质量保留。有评论者质疑 TurboQuant 是否具有 Mac 特定的优势，暗示其收益取决于硬件或工作负载，而非广泛适用。
• 有评论者推荐使用 dflash 替代内置 MTP，声称其速度快 30–40%。他们还提到，相关的 PR 已经存在，暗示该实现工作可能与之前 llama.cpp 的集成工作重复。

我们真的都能成功，不是吗？双 3090 配置。（热度：487）：一套 双 RTX 3090（总计 48 GB 显存，无 NVLink） 配置，运行 club-3090，据报告从 WSL2 下约 30 tok/s 的生成速度和约 400 pp/s 的提示处理速度，提升至 原生 Ubuntu 下的约 113 tok/s 和约 4000 pp/s。作者表示，近期修复的 “sse-session drop bug” 和工具调用问题使得本地工作流变得可行，Qwen “3.6” 27B 在 262k 上下文下，在消费级 GPU 上进行编码、猴子补丁和代码审查时，感觉“几乎达到了 Sonnet 级别”。评论者认为这证明了本地 AI 已从演示阶段跨越到实用的编码工作负载，并归功于更快的运行时、基础设施和小模型的质量提升。人们持谨慎乐观态度，认为领域特定的前沿级模型可能在 1–2 年内 适配专业消费级硬件，同时有用户建议避免双系统启动，而是运行专用的 Ubuntu GPU 服务器/API 盒子。

• 评论者注意到本地推理能力的重大飞跃：消费级双 RTX 3090 配置现在被描述为可用于 接近 Claude-Sonnet 级别的编码工作流，而不仅仅是玩具般的 7B 摘要演示。讨论将其归因于 运行时/软件优化、小模型能力以及本地推理基础设施的超预期进展，并推测领域特定的前沿质量模型可能在 1–2 年内 适配专业消费级硬件。
• 有用户描述在车库中运行一台 2x RTX 3090 的 Ubuntu 机器，GPU 利用率达到 100%，同时远程提供 API 调用服务，这暗示了一种实用的本地服务器部署模式，而非桌面双系统启动。这凸显了从实验性使用向使用消费级 GPU 构建始终在线的本地推理基础设施的转变。

我不理解量化，我在 iq3 下完美运行 Qwen3.6-27b，这说不通（热度：325）：发帖者报告使用 bartowski GGUF 量化版本运行 Qwen 27B 密集编码能力模型，量化级别约为 IQ3，在 16GB 显存中适配了约 90k 上下文，生成速度约为 30 tok/s，同时在 Godot/GDScript 任务上表现良好。他们观察到低比特量化几乎没有明显的质量下降，并假设这种强劲结果可能来自 Pi 框架 加上 Context7/ContextQMD 的检索/检查机制（针对当前语法），因为同样的模型在其他框架（如 Opencode）中尽管工具连接类似，但表现较差。

• TextGen 现已推出原生桌面应用：LM Studio 的开源替代品（前身为 text-generation-webui）（热度：1092）：oobabooga/textgen 已从长期运行的 text-generation-webui 重新打包，成为一款便携、免安装的 Electron 桌面应用，支持 Windows/Linux/macOS 平台。该应用采用自包含的 user_data 存储，并通过 GitHub releases 提供针对 CUDA、Vulkan、纯 CPU、Apple Silicon/Intel macOS 以及 ROCm 的发布版本。作者将其定位为私密、开源的 LM Studio 替代品，强调零出站请求，支持 ik_llama.cpp 及更新的量化格式（如 IQ4_KS/IQ5_KS），兼容 OpenAI/Anthropic API（包括通过 ANTHROPIC_BASE_URL=http://127.0.0.1:5000 实现 Claude Code 兼容），此外还内置了网页搜索、通过 PyMuPDF 实现的 PDF 提取、trafilatura 页面清理、Jinja2 聊天模板渲染，以及通过 Python 文件或 MCP 服务器实现的工具调用功能；源代码采用 AGPLv3 协议，托管于 github.com/oobabooga/textgen。热门评论普遍积极且偏向非技术层面，主要表达了对更注重隐私的 LM Studio 竞品的兴奋之情，以及对早期 text-generation-webui 时代 oobabooga 的认可。

一位用户指出，text-generation-webui/oobabooga 帮助他们认识到，大多数本地大模型前端本质上最终都是暴露或消费一个 OpenAI 兼容 API，这意味着前端的选择往往取决于用户体验、打包方式以及本地模型/运行时的集成，而非根本性的服务抽象差异。

• 有评论者报告称，这款新的桌面应用已成功运行 Gemma 4 31-B，认为其直观且足以满足他们的工作流程。他们还提到，现在相比 KoboldCPP 更偏爱这款应用，这表明对于希望使用本地桌面前端而非网页 UI 或独立 llama.cpp 风格运行器的用户来说，该应用可能具有竞争力。

• DramaBox - 基于 LTX 2.3 的最具表现力语音模型（热度：405）：Resemble AI 发布了 DramaBox，这是一款基于 LTX 2.3 的开源情感化语音/TTS 模型。代码托管于 GitHub，权重文件可在 Hugging Face 获取，同时还提供了在线演示 HF Space。该帖子将其定位为一款高度情感化的语音模型；评论者认为它可能对独立游戏配音和其他角色对话工作流非常有用。热门评论普遍对其表现力给予积极评价——“听起来真的像真人在表达情感”——但有一条技术性评论指出，该模型在说话人/角色相似度上达到了约 95%，但由于存在机械感或低质量伪影，音频自然度仅感觉在 60% 左右。

• 一位评论者评估该模型在语音相似度上达到了约 95%，但在无机械感/低质量音频伪影方面仅约 60%，这意味着 DramaBox/LTX 2.3 可能具有强大的说话人相似度和表现力，但在音频保真度和自然度方面仍需改进。

• 多条评论认为该模型对独立游戏开发具有实用价值，尤其是因为它被描述为一款开源模型，能够比典型的 TTS/语音模型提供更接近人类的情感表达。

• 一位用户提到了创作者之前的帖子，并感谢他们发布了代码，这表明该项目是一个持续进行的公开实现，而不仅仅是一个演示。

本地大模型工作流的检索瓶颈

• 随着谷歌关闭免费搜索索引，以及 Cloudflare 等流量防御者在每个网关挑战 AI，网络搜索的性能正在急剧下降。我们有哪些选择？（热度：838）：该帖子认为，AI 代理的网络搜索/检索管道正在退化，因为谷歌将免费站点特定/自定义搜索限制为 50 个域名，并设定了 2027-01-01 的遗留截止日期，而 Cloudflare 默认在客户站点上挑战 AI 爬虫，据报道还通过与 GoDaddy 的合作进一步扩展。评论者指出了现有的替代方案：去中心化的 YaCy、自托管的元搜索引擎 SearXNG、用于非实时批量网络数据的 Common Crawl、拥有独立索引且每月提供 2,000 次免费查询的 Brave Search API，以及诸如 Wayback Machine、archive.today 和 Jina Reader 等检索回退方案。主要的争论在于经济层面而非纯粹的技术层面：评论者预计将转向付费搜索，因为机器人/API 流量无法通过广告变现——"当没有人类眼球来观看广告时，你如何通过搜索变现？" 短期内可能的方案被视为付费或联邦搜索 API 加上缓存/阅读器服务，而不是无限制的免费谷歌搜索。

几位评论者将这个问题归结为基础设施/经济层面的转变：API 驱动的 AI 搜索没有广告展示，因此商业索引的免费高并发访问很可能不可持续。建议的替代方案包括：SearXNG 作为基于 Bing/DuckDuckGo/Brave 的自托管元搜索层，Brave Search API 拥有独立索引且免费层为每月 2,000 次查询，以及 Common Crawl 用于非实时场景，可以在本地索引 PB 级的公共爬取数据。

• 一个技术上重要的区别在于搜索和内容检索之间：搜索 API 仍然可以返回 URL，但 Cloudflare 式的机器人挑战主要破坏了后续的抓取/获取步骤。提出的缓解措施包括缓存或存档源，如 Wayback Machine API、Google Cache（如果可用）、archive.today，以及旨在检索简化页面内容的阅读器/提取服务，如 Jina Reader（r.jina.ai）。
• 一位评论者指出 YaCY（yacy.net，维基百科）是一个运行已久的开源 P2P 去中心化搜索引擎，认为集中式索引变得付费或受限可能会使分布式爬取/索引更具相关性。另一位提出了一个更激进的变体：一次性抓取内容，打包成可分发的存档，并通过 P2P 共享，以减少对源站点的重复带宽消耗。

有没有人真的把本地大模型当作日常知识库来用？不是为了编程，而是为了生活琐事。你的配置是什么？（热度：719）：该帖子询问本地大模型是否可以作为日常个人知识库，用于管理私人笔记/PDF，并围绕 RAG 可靠性、量化/模型选择、框架复杂性和上下文增长提出了担忧。报告的最具体配置是：M3 Max 36GB，通过 Ollama 运行 Qwen3-32B，使用 bge-m3 嵌入，以 Obsidian 作为数据源，使用 Postgres + pgvector，以及约 300 行自定义 Python 代码（而非 LlamaIndex）；关键实现细节包括基于标题的 Markdown 分块（带有标题/父标题前缀）、混合 BM25+稠密检索（使用 RRF）、强制来源引用/引用块，以及每晚约 4 分钟内对约 3000 条笔记进行全量重新索引。另一位评论者描述了一个非知识库但实用的本地 AI 工作流，使用语音转文本/翻译、截图转视觉翻译、剪贴板自动化、TTS 以及未来的文档提取功能用于业务任务跟踪，并指出 Whisper 级别的 ASR 和视觉模型比旧的语音/OCR 管道更可靠。最强烈的技术观点是检索质量比上下文长度或模型选择更重要："你不需要 200k 上下文……你需要的是在 8k 上下文中放入正确的 6 个块"，而大上下文通常被用来掩盖糟糕的检索。他们还警告说，将日常日记与参考笔记混合会降低检索质量，因为情感碎片会在事实查询时浮现，建议在查询时路由到不同的索引。

• 一位评论者描述了一个在 36GB M3 Max 上运行了 8 个月的日常本地 RAG 设置，使用 Qwen3 32B 作为答案模型，bge-m3 嵌入，Obsidian 作为数据源，Postgres + pgvector 用于索引，Ollama 用于服务，并使用手写的 Python 检索器（而非 LlamaIndex）。他们的主要技术发现是：基于 Markdown 标题的分块（带有前置的文档/父标题上下文）显著提高了召回率，BM25 + 稠密混合检索配合 RRF 融合以约 +50ms 的代价修复了专有名词失败问题，并且需要引用/引用块来检测幻觉性断言。
• 同一位 RAG 用户认为，非常长的上下文窗口通常是在补偿糟糕的检索："你不需要 200k 上下文。你需要在 8k 上下文中放入正确的 6 个块。" 他们通过 cron 每晚重建索引，处理约 3000 条 Obsidian 笔记大约需要 4 分钟，并发现日常日记应与参考笔记分开索引，因为带有情感色彩的日记片段会污染事实性检索结果。
• 另一位评论者构建了一个本地化的多语言游戏助手，结合了语音转文本、视觉翻译、剪贴板自动化和 TTS：按住鼠标中键录制语音，翻译成西班牙语，并复制到游戏聊天中；一个热键截取聊天区域并发送给 AI 视觉模型进行翻译，因为 OCR 不可靠。他们特别指出 Whisper 语音识别足够准确，以至于他们没有注意到转录错误，并且他们正在将类似的文档摄取思路扩展到扫描员工任务表、提取文本、创建数据库任务和生成摘要。

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

1. Claude SDK 信用额度引发用户反弹

• Anthropic 刚刚坑了所有人，还装出一副友善的样子（热度：2761）：图片是 ClaudeDevs/X 公告的截图，内容显示从 6月15日 起，付费 Claude 计划可以为通过 Claude Agent SDK、claude -p、Claude Code GitHub Actions 以及第三方 Agent SDK 应用的编程式使用，申请专属月度信用额度。Reddit 帖子认为，这实质上是对定价/使用限制的削弱：之前 Claude Code 的编程式使用受益于不透明且大幅补贴的订阅限制，现在则被纳入固定的美元信用额度，对于重度 SDK/CLI 用户来说，实际价值从大约 "$2000 的 token 量" 降到了 $200。评论者普遍认为这一变化是伪装成福利的降级，尤其是对于自主运行的 claude -p 工作流，其信用额度消耗速度可能比交互式订阅使用更快。有用户表示，这促使他们转向"永久本地模式"，反映出对 Anthropic 让云端编码 Agent 工作流变得不再经济的担忧。

评论者重点关注了对 Claude Code / claude -p 自主编程式使用的影响，认为现在运行可能受限于一个独立的月度信用池，而非有效共享订阅访问权限。有用户指出，这些信用额度的消耗速度"比订阅使用更快"，这将严重影响那些需要大量重复 CLI/API 调用的 Agent 工作流。

• 多位用户指出了 Anthropic 关于 "编程式使用的专属月度信用额度" 表述中的模糊之处，特别是这究竟是否改变了正常的 Claude Code 使用，还是仅针对自主或脚本化使用。问题在于，模糊的产品/使用计费边界使得用户难以估算成本，也难以决定是否要尽早迁移到本地模型。

《时间规划局》（2011）其实是 Claude Pro 用户的纪录片，只是没人告诉我们（热度：5292）：图片是一个非技术性的梗图，将电影《时间规划局》中发光的生命时钟机制与 Claude Pro 的 token/消息限制联系起来，展示了一个前臂计数器，显示 剩余 Token：125（图片）。该帖子将付费大模型的使用上限比作生产力时代的生死倒计时，调侃说"贾斯汀·汀布莱克只是个试图在窗口关闭前完成 PR 的家伙"。评论大多延续了这个玩笑，但有一位评论者提出了更广泛的批评，认为 AI 公司正在剥削用户的数据和集体人类智慧，并指出高质量的人类生成的真实世界数据才是类似于电影中"时间"的稀缺资源。

• 一条评论围绕 AI 训练数据和人类生成的智慧构建了"资源开采"的类比，认为大模型的进步依赖于高质量的真实世界人类数据，而非递归地在大模型输出上进行训练。该评论者特别指出，模型*"无法通过在其他大模型上训练而变得更聪明"*，AI 公司实际上是在竞相开采稀缺的高信号人类生成数据。

• Twitter用户发了一张真实的莫奈画作，却声称是AI生成的（热度：3110）：这是一个非技术性的迷因/社会实验：截图显示某X/Twitter用户将一幅据称是克劳德·莫奈（Claude Monet）的真实睡莲画作标注为“AI生成”，随后评论区涌现出大量自信满满的回复，指出所谓的AI缺陷，如深度不足、画面不连贯、笔触问题以及缺乏“情感”。其深层意义在于揭示了AI艺术讨论中的认知偏差——一旦观众被告知某幅图像是AI生成的，他们就会反向推导出各种批评，即便这幅作品实际上出自人类之手。图片链接 热门评论将其视为确认偏误和意识形态驱动感知的典型案例，网友们调侃道“突然间人人都成了印象派专家”，并警告不要把这个帖子发给反AI社区的人看。
• 我去……（热度：2856）：这是一个非技术性的迷因，关于AI图像编辑模型在处理手部矢量化请求时的翻车现场：它先是生成了一个多指畸形的手，然后“修正”时又把手势改成了竖中指。这生动展示了生成式图像在手部/手指拓扑结构方面的常见失败模式，以及模型在迭代编辑过程中糟糕的指令遵循能力。图片