AI 开发者日报

• GPT-5.5 现已稳居长周期网络任务第一梯队：英国 AI 安全研究所报告称，GPT-5.5 成为第二个完整完成其多步骤网络攻击模拟的模型，后续多条推文指出，在该评估中它与 Claude Mythos Preview 大致持平：@scaling01 引用数据显示，GPT-5.5 的平均通过率为 71.4%，而 Mythos 为 68.6%；@cryps1s 则指出，GPT-5.5 在 2/10 的尝试中解决了 TLO 链，而 Mythos 为 3/10。@polynoamial 强调，在推理预算超过 1 亿 token 后，性能仍在持续提升，表明尚未出现明显的饱和迹象。这实质上改变了此前 Anthropic 在自动化网络攻击领域拥有独特领先优势的说法。与此同时，OpenAI 还发布了产品侧的安全更新：ChatGPT 高级账户安全功能，新增了抗钓鱼登录和强化恢复机制。
• Codex 正从编程工具迈向通用计算机操作：OpenAI 发布了一次重大的 Codex 更新，明确将其定位为“面向所有人，适用于任何在计算机上完成的任务”。主公告 强调了基于角色的入职引导、应用连接以及涵盖文档、幻灯片、电子表格、研究和规划的工作流。@ajambrosino 将此次更新总结为：动态任务特定 UI、计算机/浏览器使用速度提升 20%、幻灯片/电子表格处理能力增强、以及更流畅的任务交接；而 @AriX 则指出，更新后 Computer Use 运行速度提升了 42%。Sam Altman 在推广该发布时表示：“今天 Codex 迎来重大升级！试试用它处理非编程的计算机工作吧。” 更广泛的趋势是：OpenAI 正在将“计算机使用代理”的用户体验产品化，而不仅仅是提升模型能力。
• 基准测试提升虽小，但经济意义显著：Artificial Analysis 报告称，GPT-5.5 Pro 在 CritPt 基准上相比 GPT-5.4 Pro 取得了微弱的新 SOTA（最佳成绩），但有趣的点不在于原始分数——它是在 成本降低约 60%、token 使用量减少约 60% 的情况下实现这一前沿科学评估提升的。这与更广泛的讨论一致：GPT-5.5 系列与其说是智能上的巨大跃迁，不如说是高价值工作流中更强的可靠性和更好的效率。

• Qwen3.6 27B 堪称今日最重要的开源模型发布：Artificial Analysis 将 Qwen3.6 27B 评为 150B 参数以下开源模型的新领跑者，其智能指数得分 46，超越了 Gemma 4 31B 及之前的 Qwen 系列。关键细节：采用 Apache 2.0 协议，支持 262K 上下文，具备原生多模态输入能力，且 BF16 权重足够小，可单卡部署于 H100。配套的 35B A3B MoE 模型得分 43，成为约 3B 活跃参数 级别中最强的开源模型。代价是按输出 token 计算的推理成本较高：AA 估算 Qwen3.6 27B 在该测试套件上使用了约 1.44 亿个输出 token，运行成本大约是 Gemma 4 31B 的 21 倍。尽管如此，从单位参数规模的能力来看，这仍是一个显著的进步。
• 腾讯 Hy3-preview 具备竞争力但并非顶尖：Artificial Analysis 将 Hy3-preview 描述为 总参数量 295B / 活跃参数 21B 的 MoE 模型，支持 256K 上下文，采用限制商业用途的社区许可协议。其在 AA 智能指数上得分为 42，落后于近期开源竞品如 Qwen3.6 27B、DeepSeek V4 Flash 和 GLM-5.1。最亮眼的表现来自 CritPt 基准测试，得分与 GLM-5.1 持平，达到 4.6%，表明其科学推理能力优于整体水平。
• xAI 的 Grok 4.3 在智能体基准测试上大幅提升，同时价格更低：Artificial Analysis 测得 Grok 4.3 的智能指数为 53，较 Grok 4.20 v2 提升 4 分，在 GDPval-AA 上更是跃升至 1500 Elo。AA 还报告称，与上一版本相比，输入价格降低了约 40%，输出价格降低了约 60%。该版本在 GDPval-AA 上仍大幅落后于 GPT-5.5，但这看起来是一次真正的系统和后训练层面的改进，而非小修小补。
• 蚂蚁集团的 Ling 2.6 1T 追求成本效率而非前沿性能：Artificial Analysis 将 Ling 2.6 1T 定位为 1T 参数的非推理模型，得分 34，在 GPQA/HLE 上表现尚可，基准测试运行成本低至约 95 美元。但可靠性是短板：AA 报告其在 AA-Omniscience 上的幻觉率高达 92%。

• DeepSeek的多模态方向似乎与计算机使用智能体紧密耦合：@nrehiew_ 指出，DeepSeek通过让模型在推理过程中直接输出边界框和点坐标来将视觉能力训练进 V4-Flash，他认为这是一种面向计算机使用的设计，而非通用的视觉语言模型（VLM）工作。另一篇帖子认为，论文中的"视觉基元"任务直接映射到浏览器/计算机使用场景，而非广泛的多模态理解（链接）。这一框架与 @teortaxesTex 的平行观察相吻合——DeepSeek可能正在将视觉权重整合回主线的 V4 系列，而非单独发布一个"V4-Flash-Vision"版本。
• 仓库消失事件本身成了一个故事：发布后，多位观察者注意到 DeepSeek 的"Thinking with Visual Primitives"仓库消失了，包括 @teortaxesTex 和 @arjunkocher。这些推文中没有给出明确的解释，但这次删除之所以引起更多关注，是因为该工作展示了一种具体的视觉推理和 GUI 接地（grounding）方案。
• 关于扩展规模的讨论指向了前沿预训练的巨大 token 数量：@teortaxesTex 认为，对于前沿模型来说，超过 100T token 已不再罕见，并估算了一个假设的 100T-token DeepSeek V4 相当于"V4 + 2 个 epoch"；而 @nrehiew_ 粗略估算了一个 ~100B 激活参数的模型需要 ~150T token 和 ~9e25 预训练 FLOPs，并指出在 OpenAI 规模的 100K GB200 集群上，以保守的 MFU 计算，大约 14 天即可完成一次运行。这些推测虽非定论，但有助于校准"前沿规模"在实践中的真实含义。

• 从模型中心的自夸转向工程化编排已成为明确趋势：Cursor 发布了一篇重要文章，阐述其如何测试和调优 Agent 编排层，重点聚焦运行时、评估体系、退化修复以及针对特定模型的定制化，而非泛泛的基准测试宣传。@Vtrivedy10 明确指出，Cursor 的文章与众多 Agent 构建者正在趋同的设计模式高度一致：为每个模型定制专属的提示词和工具、混合使用离线与在线评估、内部自测（dogfooding），以及将上下文窗口视为主要的计算边界。
• LangChain 持续打包部署和多租户 Agent 基础设施：@hwchase17 推出了 DeepAgents deploy，这是一种通过 deepagents.toml 配置文件驱动的云部署流程，涵盖 Agent、沙箱、认证和前端等模块。LangChain 团队的相关文章进一步详述了多用户部署场景下，用于实现数据隔离、委托凭证和基于角色的访问控制（RBAC）的 Agent-Server 模式（示例）。这正逐渐成为将演示原型转化为企业级软件的关键但略显枯燥的基础层。
• 协作式多Agent工作空间正变得更加具体：@cmpatino_ 介绍了 Agent Collabs，该项目利用 Hugging Face 的存储桶（buckets）和 Spaces 作为共享后端，让异构 Agent 集群能够交换消息、工件和进度信息。其值得关注的创新点不仅在于“Agent 协作”，更在于提供轻量级的协调原语，使得能力较弱的 Agent 能够贡献有效的验证工作，而资源更充裕的 Agent 则专注于执行昂贵的实验任务。

• 开源软件包被投毒仍然是严峻的运营风险：Socket 报告称，流行的 PyPI 包 lightning 在 2.6.2 和 2.6.3 版本中被植入恶意代码，该代码在导入时自动执行，下载 Bun 并运行一个 11 MB 的混淆 JavaScript 载荷，旨在窃取凭证。@theo 将这一事件与其他软件包被投毒事件（npm 上的 intercom-client）以及一个 Linux 零日漏洞联系起来，认为软件供应链攻击的频率正在加快。
• 安全扫描工具正在成为第一梯队的 AI 产品：Anthropic 推出了 Claude Security，据 @kimmonismus 和后来的 @_catwu 描述，这是一个由 Opus 4.7 驱动的仓库漏洞扫描器，能够验证发现的问题并建议修复方案。Cursor 也推出了类似产品 Cursor Security Review（链接），提供始终在线的 PR 审查和定时代码库扫描。这是模型厂商直接切入成熟 DevSecOps 领域最明显的案例之一。

以下是今日按互动量排序的热门推文摘要：

• OpenAI Codex 从编程助手扩展为通用知识工作工具：OpenAI 的 Codex 公告 和 Sam Altman 的后续推文 是当天最重磅的产品发布，标志着 OpenAI 的战略方向从“编程智能体”转向“计算机使用智能体”。

• GPT-5.5 的网络评估结果引发关注：英国 AISI 的推文 是当天互动量最高的技术帖之一，并重塑了与 Anthropic 的 Mythos 模型的对比格局。

• Qwen 发布了可解释性工具，而不仅仅是模型：Qwen-Scope 是一套面向 Qwen 模型的开源稀疏自编码器工具集，它的发布引人注目——重点聚焦特征引导、调试、数据合成和评估，而非单纯的模型权重发布。

• Anthropic 发布了大规模引导/谄媚行为研究：他们对 100 万条 Claude 对话的分析 将行为研究与 Opus 4.7 和 Mythos Preview 的训练改进直接关联起来，这是一个重要信号，表明后训练循环正变得更加产品化和数据驱动。

• AMD 自研 Ryzen 395 Box 将于六月发布（热度：1061）：AMD AI Dev Day 演示文稿中的图片展示了即将推出的 AMD Ryzen 395 Box，预计将于六月发布。该设备配备 128GB 统一内存，声称可原生支持 2000 亿参数模型，并利用了所谓的“Ryzen AI Max”技术。从演示文稿中的提及来看，该产品似乎由联想制造。不过，一位工程师确认，该设备本质上就是搭载 128GB 内存的 Ryzen 395，没有其他额外改动。评论者对在 128GB 统一内存上运行 2000 亿参数模型 的实用性表示怀疑，质疑即便考虑到操作系统开销，在内存限制下这一方案是否可行。

obiwanfatnobi 提出了一个技术问题，即在一个配备 128GB 统一内存 的系统上运行 2000 亿参数模型 的可行性。他们指出，即使在 Linux 系统下，可用的 VRAM 大约也只有 116GB，这可能不足以运行如此大的模型，暗示了当前 AI 工作负载硬件配置的潜在局限性。

• promethe42 将新的 AMD Ryzen 395 Box 与“Framework Desktop”进行了比较，指出它似乎“晚了 12 个月”才发布。他们建议 AMD 在发布新硬件之前，应优先改进其“驱动/ROCm”，表明软件支持可能落后于硬件进步。
• DaniyarQQQ 评论称需要 512GB 统一内存，暗示当前内存容量可能无法满足现代计算需求，尤其是在高性能或 AI 应用中。这表明尖端技术对内存的需求呈增长趋势。

AMD Halo Box（Ryzen 395 128GB）照片（热度：467）：搭载 Ryzen 395 处理器和 128GB 内存的 AMD Halo Box 在运行 Ubuntu 系统时被展示。该设备包含一个可编程灯条，增强了其定制能力。然而，它没有光驱，也缺少用于集群的高速端口，这可能限制其在某些高性能计算场景中的使用。评论者指出缺少光驱和集群高速端口是潜在的缺点，表明虽然该设备体积小巧，但这些缺失可能会影响其在特定技术应用中的实用性。

• OnkelBB 指出 AMD Halo Box 缺少用于集群的高速端口，这可能会限制其在需要高速互连以跨多个节点扩展的高性能计算环境中的使用。
• FoxiPanda 强调了 AMD 产品中一个常见的需求——增加内存带宽，表明当前产品可能无法满足内存密集型应用的需求。对于需要快速数据访问和处理的工作负载来说，这是一个关键因素。
• Stepfunction 指出 AMD Halo Box 是一款小型化计算机，这意味着在扩展性和散热方面可能存在限制，但在空间效率和便携性方面具有优势。

• Qwen-Scope: Qwen 3.5 系列模型的官方稀疏自编码器 (SAEs) (热度: 393): Qwen-Scope 是近期发布的一套针对 Qwen 3.5 系列模型（从 2B 到 35B MoE 架构）的稀疏自编码器 (SAEs) 集合，旨在映射模型所有层级的内部特征。该工具相当于模型内部概念的“字典”，能够实现精确干预，例如通过 Surgical Abliteration 抑制“拒绝回答”等特定特征，通过 Feature Steering 激活期望的概念，以及通过 Model Debugging 识别由特定 Token 触发的内部方向。该项目采用 Apache 2.0 许可证 发布，但 Qwen 团队建议不要将其用于移除安全过滤机制。该工具在 Space 演示 中进行了展示，并在 技术论文 中有详细说明。评论者强调，这可能是目前针对密集 27B 模型最大的开源可解释性工具，与 Google 较小的 GemmaScope 变体形成鲜明对比。社区也期待未来模型迭代版本（如 Qwen 3.6）能有类似工具。

NandaVegg 强调了为密集 27B Qwen 模型发布稀疏自编码器 (SAEs) 的重要性，指出这可能是目前可用的最大开源可解释性工具。这与之前的工具（如仅支持 9B 和 2B 等较小模型的 GemmaScope）形成对比，标志着模型可解释性能力的重大进步。

• robert896r1 表达了对 Qwen 3.6 发布类似工具的期待，暗示社区可能会为更新的模型迭代适配现有工具。这反映了一个常见趋势，即社区经常扩展或修改工具以支持最新的模型版本，确保持续的实用性和相关性。
• oxygen_addiction 推测了在大型模型（如 ChatGPT5）中使用特征引导 (Feature Steering) 的可能性，即通过一个路由器动态地为给定提示词选择最佳模型。这一概念涉及利用可解释性工具，通过根据特定特征或需求定制响应来增强模型性能。

Qwen 3.6 35b a3b 即使在显存受限系统上也表现惊人 (热度: 480): 该帖子讨论了本地大模型 Qwen 3.6 35B-A3B 在显存受限系统（配备 AMD 7700 XT、32GB DDR4 内存和 Ryzen 5 5600）上的性能表现。用户强调了该模型处理复杂编码任务的能力，例如修复网页爬虫中的 bug 以及使用截图更新项目 README 文件，使用的配置包括 i1-q4_k_s 量化、128k 上下文、flash attention 和 Q8_0 KV 量化。该模型成功完成了其他模型（如 Gemma 3、Gemma 4 和 Qwen 2.5 Coder）失败的任务，展示了其在硬件受限条件下无需失败工具调用即可执行任务的能力。评论者建议通过将多余专家 (experts) 移至 CPU 并将 KV 缓存保留在 GPU 上来优化性能，从而实现超过 30 t/s 的速度。另一位用户对 16-20 tok/s 的较长处理时间提出疑问，指出他们自己的体验中处理速度更快，可达 35-40 tok/s。

• GoldenX86 建议通过将多余专家 (experts) 移至 CPU，同时将 KV 缓存保留在 GPU 上来优化性能，这可以将处理速度提升至每秒超过 30 个 Token (t/s)。这种方法对于显存受限的系统尤其有用，可以高效利用可用资源。
• AccomplishedFix3476 强调了在消费级显存上运行 35b a3b 模型用于编码工作流的潜力，并指出本地和长时间运行的任务可能会暴露出在短生存时间 (TTL) 的 API 环境中不易察觉的内存泄漏和上下文漂移问题。他们建议最初记录所有内容，以便及早发现这些问题。
• Perfect-Flounder7856 分享了一个基准测试对比，其中 35b a3b 模型在策略推理基准测试中以 96 分对 92 分的成绩击败了 27b 模型。这表明该模型在特定任务上具有卓越性能，对于那些追求高精度和高速度的用户来说，硬件投资是值得的。

• mistralai/Mistral-Medium-3.5-128B · Hugging Face（热度：1120）：Mistral Medium 3.5 是一个稠密型 128B 参数模型，拥有 256k 上下文窗口，专为指令遵循、推理和编程任务设计。该模型支持多模态输入，包括文本和图像，并提供可配置的推理努力程度（reasoning_effort），允许在快速回复和复杂推理之间灵活切换。模型支持多语言、系统提示词，并采用修改版 MIT 许可证发布。它取代了之前的 Mistral Medium 3.1 和 Devstral 2 等模型，在统一架构下实现了性能提升。对于复杂任务，建议将 reasoning_effort 设置为 "high"，温度参数设为 0.7 以获得最佳性能。评论者们正在不同硬件上测试该模型的性能，特别关注其稠密 128B 参数配置这一独特特性。讨论还涉及该模型与 Qwen 27B 等其他稠密模型相比的定位差异。

IvGranite 分享了在 Strix Halo 上使用 llama.cpp build 8967 运行 mistral-medium-3.5-128b-q4 模型的性能数据。结果显示，生成速度为 3.26 t/s，提示词处理速度为 46.70 t/s，其中一次测试总耗时为 4.84s。这表明对于如此规模的模型来说，处理效率相对较高，凸显了 q4 量化在优化性能方面的潜力。

• grumd 和 reto-wyss 讨论了 128B 稠密模型的意义，grumd 称其为"一个有趣的细分领域"。reto-wyss 将其与 Qwen 27b 模型进行比较，探讨哪个模型更稠密，暗示了模型密度与性能之间的竞争格局。这反映了业界在模型规模与计算效率之间寻求平衡的持续关注。
• 围绕 mistral-medium-3.5-128b 等稠密模型的讨论，凸显了处理大规模模型所面临的挑战与创新。重点在于如何在资源密集型的稠密架构上实现高性能，同时充分发挥其在复杂任务中的潜力。讨论强调了模型量化与优化技术进展的重要性。

Mistral Medium 3.5 正式发布（热度：369）：Mistral Medium 3.5 作为一款 128B 稠密模型正式发布，集成了指令遵循、推理和编程能力。该模型以开放权重形式发布，采用修改版 MIT 许可证，对月收入超过 $2000 万 的企业在商业使用时收取许可费。该模型支持云端的异步编程任务，允许多个会话并行运行，并在 Le Chat 中引入了新的工作模式（Work mode），适用于复杂工作流。更多详情请访问 Hugging Face 和 Mistral 官方公告。关于许可证条款存在争议，部分用户认为将其称为"修改版 MIT 许可证"具有误导性，因为商业使用限制条款与传统 MIT 许可证存在本质差异。

• Mistral Medium 3.5 是一个稠密型 1280 亿参数模型，在当前大模型向更大规模稠密模型发展的趋势下具有重要意义。正如 Septerium 所指出的，这符合业界对稠密架构的持续投入，也反映了整个行业同时向超稀疏 MOE 模型和 2000 亿参数级别的超稠密模型发展的趋势。
• Long_comment_san 指出，虽然 Mistral Medium 3.5 的基准测试成绩并非业界顶尖，但已足够维持人们对大型稠密模型的兴趣。该评论者强调这些模型作为未来 AI 主力工作负载的重要性，认为行业将继续探索 800 亿参数以上的稠密模型以及万亿参数级别的超稀疏模型。
• ClearApartment2627 提出了许可证问题，认为 Mistral 的许可证要求月收入超过 2000 万美元的企业为商业使用付费，不应被标注为"修改版 MIT 许可证"。这一区别对于考虑将该模型用于商业应用的公司至关重要，因为它直接影响使用成本和法律风险。

• 使用 Claude 发布我的第一款应用（热度：654）：用户使用 Claude 构建并发布了一款车辆管理应用，功能包括费用追踪、可自定义的保养计划、油耗记录、展厅模式，以及通过 Claude API 实现的 AI 助手。该应用采用前端为主的设计，数据存储在本地，但 API 调用需要数据库支持。开发者正在筹备 Play Store 版本，并寻求反馈以推动增长。应用链接。有评论者将其与 Vehicle Smart 进行对比，认为这款新应用在保养功能方面开发得更为出色。另一位用户则询问开发工具，想知道它是用 Swift、Expo 还是 Tauri 构建的。

NooneLeftToBlame 讨论了该应用的功能，并将其与英国警方常用的热门应用 "Vehicle Smart" 进行了对比。他指出，虽然 "Vehicle Smart" 具备车牌查询和车库保养提醒功能，但后者开发得并不完善。相比之下，从截图来看，这款新应用的开发质量更高，暗示其在用户体验方面可能具有竞争优势。

• barritus 询问了应用的开发技术栈，想知道它是完全用 Swift 构建的，还是使用了 Expo 或 Tauri 等框架。这反映出人们对技术实现和选型的兴趣，因为这些因素会影响应用性能和跨平台兼容性。

• Alternative-Ad-8175 对数据存储提出了担忧，建议使用云存储以防止手机丢失导致数据丢失。他还提到应用中包含个人身份信息（PII），暗示需要采取安全的数据处理措施来保护用户隐私。

• 入门级创意自由职业者的棺材板，终于钉上了最后一颗钉子（热度：940）：Anthropic 发布了 Blender MCP 连接器，使 Claude 能够通过 Python API 控制 Blender。这一集成允许用户使用自然语言指令创建和修改 3D 场景，实际上充当了 Blender 中的"副驾驶"角色。该工具可以处理节点调试、批量修改和添加自定义工具等任务，可能会减少对入门级自由职业者在产品渲染和低多边形资产创建等方面的需求。现在，整个创意流程——从脚本编写到最终编辑——都可以由单个用户借助 Claude 和连接工具完成。一些评论者对 AI 生成作品的质量表示怀疑，认为这可能导致低质量游戏和应用的数量激增。另一些人则淡化这一公告的意义，将讨论比作耸人听闻的媒体炒作。

• Claude 是我的 SEO 策略师、内容引擎和 CTO。6 周内从 0 到 10,000 活跃用户，广告支出为 0。（热度：1039）：Reddit 帖子中的图片是一个分析仪表盘，展示了市场平台 Agensi 用户参与度的显著增长——该平台是使用 Claude 和 Lovable 等 AI 工具构建的。仪表盘显示，在过去 30 天内，活跃用户达到 10,000 人，增长 263.3%；新增用户 9,900 人，增长 262.0%，且全部未花费任何广告费用。这一增长归功于 Claude 在 SEO、内容策略和 AEO（答案引擎优化）方面的战略性运用，包括分析 Google Search Console 数据以识别关键词缺口，并针对 AI 引擎和搜索引擎优化内容结构。 一些评论者对内容的真实性和原创性表示怀疑，认为这可能是"通用的 AI 垃圾内容"或垃圾信息，并质疑该帖子本身是否由 AI 撰写。

• 如何搞垮一家 AI 公司（热度：934）：图片展示了一家 AI 公司的状态仪表盘，显示多项服务正经历"重大故障"。受影响的服务包括 "claude.ai"、"Claude Console"、"Claude API"、"Claude Code"、"Claude Cowork" 和 "Claude for Government"，正常运行时间百分比在 98.69% 到 99.88% 之间。这表明在维护服务可靠性方面存在重大运营挑战，而对于追求一致性能的 AI 公司来说，可靠性至关重要。标题和评论凸显了人们对管理不善的看法，以及在快节奏的 AI 行业中运营的挑战——在这个行业，稳定性往往被快速开发所牺牲。 评论者们争论此类故障在尖端 AI 公司中是否属于常态，一些人认为这是颠覆性科技领域常见的"快速行动，打破常规"做法的一部分，而另一些人则认为这不适用于成熟的 SaaS 公司。

• 我还没准备好迎接 DeepSeek V4（热度：176）：**该图片展示了 DeepSeek V4 的仪表盘，突出显示了其性能指标，如支出、Token 使用量和缓存节省。总支出为 $1,050.86，缓存节省了 $3,351.43，显示出显著的性价比。仪表盘对比了 DeepSeek Chat、DeepSeek V4 Pro 和 DeepSeek V4 Flash 等不同模型，强调 V4 Flash 模型的表现优于其他模型，包括发帖人之前使用的 Claude 模型。这表明 DeepSeek V4 系列在价格、速度和效率方面具有竞争优势，对市场上现有的高端模型构成了挑战。**评论者指出，V4 系列在性价比和性能方面具有革命性，市场尚未完全认识到其潜力。同时，也有人对展示这些分析数据的具体仪表盘或应用感到好奇。

DeepSeek V4 在价格、速度和效率方面都有显著提升，标志着 AI 模型开发的革命性一步。用户强调，该模型的性价比是其突出特点，通过以低于以往版本的价格提供高性能，有可能颠覆市场。

• V4 Flash 模型因其均衡的性能指标，正成为许多用户的默认选择。它能够高效处理广泛的任务，提供适用于各种场景的通用解决方案，这可能是其被广泛采用的关键因素。
• 尽管能力出众，但市场对 DeepSeek V4 潜在影响力的认知似乎仍然不足。这可能是因为人们普遍接受了 AI 解决方案的高成本，而 V4 通过在不牺牲性能的前提下提供更具性价比的替代方案，挑战了这一现状。

Deepseek V4 Pro 让我想起了 Claude 4.6 Sonnet（热度：175）：该帖子讨论了 Deepseek V4 Pro 模型的性能，将其与 Claude 4.6 Sonnet 在创造力和编码能力方面进行了比较，特别是在 HTML 任务上。该模型目前处于预览阶段，潜力巨大，但在角色扮演的一致性和角色遵循方面仍存在问题，即使在 0.6 这样的低温度设置下也经常忽略指令。用户还提到 Kimi K2.6 是他们大多数任务的首选模型，同时承认 Deepseek V4 Pro 相比其前代 Deepseek V3.2 有所改进。评论者指出该模型在角色扮演中存在不稳定和不一致的问题，难以维持角色特征和场景一致性。有用户表示，GLM 5.1 在编码任务上优于 Kimi K2.6，表明在技术应用中 GLM 5.1 更受青睐。

• Flat-Rooster8373 指出了 DeepSeek V4 Pro 在角色扮演场景中一致性的问题，该模型难以维持角色完整性，即使在 0.6 这样的较低温度设置下也经常忽略指令。评论者观察到，使用预设会加剧这些问题，导致输出重复且充满套话，而不用预设的方法能产生更好的第一人称推理，但最终输出仍然与推理过程存在偏差。
• Far-Habit-2713 将 DeepSeek V4 Pro 与 Qwen 3.6 Plus 在编码任务上进行了比较，发现 Qwen 在通用编码和调试方面表现出色。然而，DeepSeek V4 Pro 在生成 Rust 代码方面更胜一筹，并能提供更详细的代码分析。这表明，虽然 Qwen 可能更通用，但 DeepSeek 在特定编程语言和详细分析方面具有优势。
• azvd_ 分享了他们在 Hermes 平台上使用 DeepSeek V4 Pro 的体验，指出与 Opus 4.7 相比，它的错误更少。这一改进归功于 DeepSeek 增强的理解能力，这与 Opus 为了优化其他方面而有意降低理解能力形成了对比。

兄弟，这太便宜了，我终于对 deepseek 有了敬意（热度：132）：该帖子讨论了 DeepSeek 的定价，具体质疑如此低的价格是针对 DeepSeek V4 Flash 版本还是 Pro 版本，后者预计在今年晚些时候之前仍将保持高价。帖子编辑说明 Pro 版本目前有折扣。评论中的技术性问题集中在 DeepSeek 与其他前沿模型相比的质量水平，以及定价是否受到缓存命中率的影响，这可能会影响输出 Token 的成本。评论者们正在争论低价是由于临时折扣还是定价策略的根本性改变，一些人认为性价比可能源于缓存优化对 Token 输出成本的影响。

• DeepSeek V4 Flash vs. Pro：关于 DeepSeek V4 Flash 和 Pro 版本之间的定价差异存在讨论。Pro 版本价格更高，但目前有折扣。这表明可能存在一种战略性定价模型，以吸引不同的用户群体，可能是由于功能集或性能能力的差异。
• 缓存系统与成本效率：评论强调了 DeepSeek 基于磁盘的 KV 缓存系统，该系统因其稳健性和可靠性而受到称赞，可持续数小时，而其他提供商通常只有 5 分钟。该系统通过使缓存的输入几乎免费，显著降低了成本，这是该模型价格实惠的关键因素。
• 创意任务中的表现：有评论批评 DeepSeek V4 在创意写作任务中的表现，称其相比之前版本有所降级。不过，它仍然被认为在角色扮演（RP）和智能体任务中有效，这表明在创意能力和其他功能之间存在权衡。

• ICML 2026 决策 [D]（活跃度：1124）：该帖子讨论了即将公布的 ICML 2026 录用决定引发的期待。 社区正热切等待最新消息，许多人频繁查看 OpenReview 等平台以获取更新。这反映了学术社区在会议决策期间典型的高度参与感和焦虑情绪。评论幽默地展现了研究人员在等待会议决定时的紧张与不耐烦，突显了反复刷新平台查看更新的常见行为。

• ICML 似乎在拒绝大量全票好评的论文 [D]（活跃度：202）：该帖子讨论了对 ICML 审稿流程的担忧，强调了在 rebuttal 阶段存在的激励错位问题。作者指出，审稿人感到有压力去调整评分以避免冗长的讨论，导致评分虚高，并不能真实反映论文的质量。这导致许多全票好评的论文因会议容量有限而被拒。作者建议回归更简单的同行评审流程，让审稿人提供独立评估，由领域主席（AC）来评判质量和一致性，并通过讨论解决边缘案例。 评论者对审稿流程表示沮丧，指出即使解决了审稿人的所有顾虑，评分很高的论文仍然被拒。有人呼吁建立申诉机制，因为感觉一个 AC 的决定可以推翻多个正面评价，导致令人沮丧的结果。

多位评论者对 ICML 论文审稿流程表示不满，列举了多篇平均分很高（如 4.5 或 4/4/4/4）的论文，尽管获得了审稿人的积极反馈，却仍被拒稿。一个普遍的担忧是，领域主席（AC）似乎有权推翻全票通过的正面评价，且缺乏明确的申诉机制，这让作者们感到困惑和不满。

• 一位评论者指出，尽管在 rebuttal 阶段解决了所有审稿人的顾虑，他们的论文仍然被拒。这表明审稿流程与最终决策之间可能存在脱节，已解决的问题被再次作为拒稿理由，暗示了流程效率低下或沟通不畅的问题。
• 讨论引发了对审稿流程透明度和公平性的质疑，有人认为拒稿可能受到满足录取名额需求的影响，而非纯粹基于论文质量。这指出了会议论文筛选过程中的系统性问题，即高分论文也无法保证被录用。

A* 会议中的中国关系网/网络拒绝非中国论文 [D]（活跃度：112）：该帖子对顶级 AI 会议论文审稿中涉嫌的裙带关系和偏见提出了担忧，特别是涉及中国关系网络。作者声称，中国审稿人可能偏袒中国作者的论文，这种协调可能通过微信等应用进行。文中举了一个例子，一位审稿人因论文未引用某中国作者的工作而表示不满。据报道，这个问题在 IJCAI 26 等会议上尤为普遍，有说法称来自中国大学的非研究性论文被接收，而非中国作者则面临更严苛的批评。 评论表明，人们认为中国研究者之间存在协调审稿的现象，可能涉及互评和通过微信共享信息。还有传闻称，中国研究者对审稿流程有内部消息，这引发了对公平性和透明度的担忧。

• 一位用户提到，一些知名度不高但备受尊敬的期刊被来自中国大学的论文主导，这些论文往往缺乏真正的研究质量，更像工程项目。他们指出，非中国作者尝试提交类似论文时会面临更严苛的批评，暗示审稿过程中可能存在偏见。
• 另一位评论者分享了一次经历：一位中国研究者在审稿期间联系他们，声称了解其论文的审稿内幕。这引发了对审稿流程保密性和公平性的担忧，尽管对论文被拒的直接影响仍属猜测。
• 一位用户观察到，在 ECCV 会议上，尽管他们有多篇论文被接收，却未被邀请担任审稿人，而带有中国合著者的论文则获得了审稿。他们注意到，一位中国领域主席偏袒中国作者，即使这些作者的论文评分很低，这引发了对审稿和录用过程中潜在偏见的质疑。