AI 开发者日报

• OpenAI 正在将 Codex 从编程工具转变为通用工作平台：今天最强烈的产品信号不仅仅是用户的使用热情，更是围绕持久上下文、工具、集成和团队部署能力的稳步扩展。OpenAI 强调 Codex 可用于更广泛的知识工作场景，如研究综合、电子表格和决策追踪，而不仅仅是代码（OpenAI、后续、后续）；推出了仅限 Codex 的席位且免席位费，面向符合条件的 Business/Enterprise 客户，有效期至 6 月底（OpenAIDevs）；并新增了如 Supabase（coreyching）等集成，以及一个 Figma 插件，可将实施计划转化为 FigJam 看板（OpenAIDevs）。社区帖子还提到了应用服务器端的使用场景和更丰富的代理工作流（gdb、aiDotEngineer）。

• 性能优化正从模型延迟转向代理循环系统工程：OpenAI 表示，将 Codex 风格的工作流迁移到 Responses API 的 WebSocket 模式，可以在工具调用之间保持状态活跃，减少重复计算，从而实现高达 40% 的代理工作流加速（OpenAIDevs、reach_vb、pierceboggan）。VS Code 发布了一系列工具链改进：跨工作区的语义索引、跨仓库搜索、聊天会话洞察、技能上下文、Copilot CLI 的远程控制，以及一个面向提示词/代理评估的扩展，旨在优化提示词、技能和指令（pierceboggan、pierceboggan、code）。其核心脉络是：编程代理的用户体验现在主要由内存、检索、工具链质量和工具编排所主导——而不仅仅是原始模型智能。

• Cursor 正在明确布局平台化战略：全新的 Cursor SDK 将驱动 Cursor 的同一运行时、工具链和模型开放出来，可用于 CI/CD、自动化以及产品内部的嵌入式代理（cursor_ai、入门项目、[客户案例](https://x.com/cursor_ai/status/2049499876388454903））。这值得关注，因为它将 Cursor 从基于席位的 IDE 产品转向了可编程的代理基础设施，这一框架被 [@kimmonismus](https://x.com/kimmonismus/status/2049514922044792934）精准捕捉。结合 Codex 的应用服务器端能力和 VS Code 的工具链工作来看，整个品类显然正在向无头代理运行时 + 可编程工具链 + 按用量计费的经济模式收敛。

• Harness 正成为一等一的优化层：多篇文章达成共识——仅靠模型质量远远不够，围绕模型的 Harness（框架/封装层）往往决定了生产环境的实际表现。最清晰的研究案例是 Agentic Harness Engineering，它通过可回滚组件、精简执行证据和可证伪预测，让 Harness 的演化过程变得可观测。报告显示：Terminal-Bench 2 的 pass@1 从 69.7% 提升至 77.0%（仅十次迭代），超越了人类设计的 Codex-CLI 基线（71.9%），同时还能跨模型家族迁移，并在 SWE-bench Verified 上减少 12% 的 Token 消耗（omarsar0）。另一项相关研究 HALO 描述了利用轨迹分析来自我修复 Harness 故障的递归自改进智能体，声称在 Sonnet 4.6 上将 AppWorld 的成绩从 73.7 提升至 89.5（samhogan）。
• LangChain 的 Deep Agents 产品线正朝着模型专属 Harness 调优和可部署性方向发力：新推出的 Harness Profiles 让团队可以为每个模型版本化提示词、工具和中间件，内置了 OpenAI、Anthropic 和 Google 模型的配置文件（LangChain_OSS、LangChain、Vtrivedy10）。LangChain 还推出了 DeepAgents Deploy，这是一种低代码部署方案，仅需少量 Markdown/配置文件，并集成了 LangSmith 支持的追踪能力（hwchase17）。LangChain 团队传递的核心信息是一致的：开放的 Harness、开放的评估标准以及开源友好的模型混合方案至关重要，因为闭源模型对许多智能体工作负载来说正变得过于昂贵（hwchase17、Vtrivedy10）。
• Cloudflare 继续完善其“智能体即软件”的技术栈，提出了执行阶梯（execution ladders）等概念，更具体地说，是让智能体能够成为 Cloudflare 的客户——创建账户、注册域名、开通付费计划、获取部署所需的 Token（threepointone、Cloudflare）。这是一个重要信号：厂商们开始将业务流程直接暴露给智能体，而不再将它们视为被动的辅助工具。

• Mistral Medium 3.5 是当天讨论度最高的模型发布。早期评论将其定位为 dense 128B 模型（scaling01），Unsloth 称其为 视觉推理模型，可在约 64GB RAM 的本地设备上运行，并发布了 GGUFs 及使用指南（UnslothAI）。各方反应分歧明显：有人批评其 128K 上下文、架构选择以及相比中国大型开源 MoE 模型的定价策略（eliebakouch，scaling01），而另一些人则认为 Mistral 是在刻意押注 企业级可靠性与指令遵循，而非追逐纯粹的基准测试成绩（kimmonismus）。
• IBM Granite 4.1 新增了三款 开源权重、Apache 2.0 协议 的非推理模型——30B、8B、3B——重点强调开放性和 Token 效率（ArtificialAnlys）。最引人注目的数据是：Granite 4.1 8B 在 Artificial Analysis Intelligence Index 上仅使用了 400 万输出 Token，而 Qwen3.5 9B 则用了 7800 万，同时在 AA 开放度指数上获得了 61 分。其智能水平落后于更强的竞品，但该系列显然瞄准了 成本和透明度 比排行榜位置更重要的企业级/边缘部署场景。
• 开源模型的竞争压力持续加剧：蚂蚁 OSS 的 Ling-2.6-flash 被提及为约 107B MoE 模型，采用 MIT 协议，SWE-bench Verified 得分 61.2，数学成绩优异（nathanhabib1011）；Ling-2.6-1T 也在发布当天获得了 vLLM 支持（vllm_project）。与此同时，腾讯混元 开源了 Hy-MT1.5-1.8B-1.25bit，这是一个 440MB、完全离线的手机翻译模型，覆盖 33 种语言、1056 个翻译方向，并声称通过激进的 1.25-bit 量化，在标准机器翻译基准测试中与商业 API 及 235B 规模模型持平（TencentHunyuan）。在市场方面，多条帖子强调，能力强劲的开源模型价格正在快速下降，例如 Qwen 3.5 Plus 每百万输出 Token 仅需 3 美元（MatthewBerman），而 MiMo-V2.5 Pro 则在 Code Arena 中以 每百万 Token 1/3 美元 的价格推动了帕累托前沿的移动（arena）。

• Qwen 的 FlashQLA 是一个值得关注的长上下文内核发布：阿里巴巴推出了 FlashQLA，这是一套基于 TileLang 的高性能线性注意力内核，报告称其前向速度提升 2–3 倍，反向速度提升 2 倍，尤其适用于小模型、长上下文工作负载以及张量并行配置。其设计核心在于门控驱动的卡内自动 CP、代数重构以及融合的 warp 专用内核（Alibaba_Qwen，基准测试讨论串）。该项目明确瞄准个人设备上的智能体 AI，这契合了长上下文优化从纯云基础设施向边缘友好运行时迁移的广泛趋势。
• vLLM 与 Blackwell 的协同设计正在带来实实在在的吞吐量提升：vLLM 在 Artificial Analysis 上报告了 DeepSeek V3.2 的最高输出速度，达到 230 tok/s，TTFT 为 0.96s，同时在使用 DigitalOcean 基于 NVIDIA HGX B300 的无服务器推理 时，Qwen 3.5 397B 也取得了强劲结果。其优化包括 NVFP4 量化、EAGLE3 + MTP 投机解码以及按模型进行内核融合（vllm_project）。SemiAnalysis 则单独强调了 vLLM 0.20.0 和 MegaMoE 内核在 GB200 上为 DeepSeek v4 Pro 带来的增益（[SemiAnalysis_](https://x.com/SemiAnalysis_/status/2049578313111216271））。这是硬件/软件/模型协同设计转化为公开可见延迟数据的一个较为清晰的例子。
• 更多工程师正在分享模型与 GPU 之间“中间层”的细节：一个关于 torch.compile 的有用讨论串详细拆解了 Dynamo → pre-grad → AOT autograd → post-grad → Inductor 的流程，包括在何处注入自定义 FX 传递以进行推理优化（maharshii）。John Carmack 发文提醒，GPU 库的性能仍然极度依赖路径且不连续，他指出当矩阵规模从 511×511 变为 512×512 时，torch.linalg.solve_ex 出现了 10 倍的性能回退，原因似乎是触发了包含 CudaMalloc/Free 的不同内部路径（ID_AA_Carmack，后续讨论）。智谱 AI 也发布了一篇关于 GLM-5 的优秀服务部署复盘文章，详细介绍了 KV 缓存竞态条件、HiCache 同步错误以及 LayerSplit，后者据称在长上下文编码智能体服务场景下，将预填充吞吐量提升了高达 132%（Zai_org）。

• 不可压缩知识探针（IKP） 是当前最具争议性的研究方向之一：@bojie_li 声称，基于 1400个问题 / 188个模型 / 27家供应商 的事实知识准确率，可以得出一个强烈的对数线性信号，与模型规模高度相关（在 1.35亿到16亿参数 的开源模型上，R² = 0.917）。论文指出，事实性能力并不会像某些“推理压缩”叙事所暗示的那样随时间压缩，并利用拟合曲线来估算闭源模型的规模。无论你是否认同这些估算，这项工作的价值在于提醒我们：黑盒评估仍然会泄露架构规模信息。
• Web智能体评估正在超越简单的通过/失败模式：全新的 Odysseys 基准测试引入了 200个长周期实时互联网任务，采用基于评分标准的评估方式而非二元成功判定，并引入了 轨迹效率 指标。目前最佳模型的成功率仅为 44.5%，效率更是低至 1.15%（rsalakhu，dan_fried）。这符合整个行业推动智能体基准测试向更真实反映多步骤浏览、电子表格操作和编排工作方向发展的趋势，而非停留在短期的合成任务上。
• AI for Science 和多模态基础设施迎来了有意义的生态发布：Hugging Face 推出了 Hugging Science，这是一个精心策划的开源科学数据集/模型/挑战赛的集中地，涵盖 78GB 基因组学数据、11TB PDE 模拟数据、1亿个细胞图谱、9T DNA 碱基对 等（cgeorgiaw）。Anthropic 发布了 BioMysteryBench，报告显示最新的 Claude 模型能够解决约 30% 的让专家都束手无策的硬核生物数据分析问题（AnthropicAI）。在多模态方面，Vista4D 引入了一种利用持久化4D场景表示，从新的相机轨迹进行视频“重拍”的技术（micahgoldblum）；Sakana 的 KAME 则提出了一种“边说边想”的串联架构，通过将低延迟前端模型与异步后端大模型预言信号相结合，用于语音到语音系统（SakanaAILabs）。

• Cursor SDK 发布：可编程的 Agent 运行时/框架/模型，适用于 CI、自动化及嵌入式产品（cursor_ai）。
• Codex 势头与平台扩展：OpenAI 正将 Codex 从编程领域推向更广泛的工作自动化，同时推进团队部署和集成（OpenAI，OpenAIDevs）。
• Google 产品化信号：Gemini 现在可以直接在聊天中生成可下载的 Docs、Sheets、Slides、PDF 等文件（sundarpichai，GeminiApp）。
• Q1 业务信号：Google 报告 Cloud 同比增长 63%，Gemini 势头强劲，搜索查询量创历史新高，这是“AI 变现”论调的重要数据点（sundarpichai）。
• 深度技术长文：Dwarkesh 与 Reiner Pope 的黑板讨论，从价格、方程和系统约束中推断训练/服务策略（dwarkesh_sp）。

• mistralai/Mistral-Medium-3.5-128B · Hugging Face（热度：921）：Mistral Medium 3.5 是一个稠密型 128B 参数模型，拥有 256k 上下文窗口，专为指令遵循、推理和编程任务设计。它支持可配置的推理深度、多模态输入能力，并在多项基准测试中表现强劲，超越了 Devstral 等先前模型。该模型采用修改版 MIT 许可证开源，支持多种语言和系统提示词。为获得最佳性能，建议使用 vLLM 库进行推理。更多详情请见此处。有评论者正在 Strix Halo 设备上以 q4 量化方式测试该模型，报告了 token 生成速度，并对模型的稠密架构表现出浓厚兴趣。另一条评论则强调了该模型作为稠密 128B 参数模型的独特定位，并将其与 Qwen 27B 进行了对比。

IvGranite 分享了在 Strix Halo 设备上使用 q4 量化的 Mistral-Medium-3.5-128B 模型的性能指标。结果显示，生成速度为 46.70 tokens/秒，提示词处理速度为 3.26 tokens/秒，其中一次测试的总耗时为 4.84 秒。这表明，对于如此规模的稠密模型而言，其吞吐量相对较高。

• Grumd 和 reto-wyss 讨论了稠密模型的定位问题，Grumd 指出 128B 稠密模型的独特性。Reto-wyss 将其与 Qwen 27B 模型进行比较，探讨哪个模型更稠密，凸显了模型密度与性能方面的竞争格局。
• 围绕 Mistral-Medium-3.5-128B 等稠密模型的讨论，反映了业界在平衡模型规模与性能效率方面的兴趣。artisticMink 将 128B 称为"大块头"，这突显了处理此类大规模模型所面临的挑战与吸引力，尤其是在计算资源和速度方面。

Mistral Medium 3.5 正式发布（热度：326）：Mistral Medium 3.5 已作为 128B 稠密模型正式发布，其亮点在于集成了指令遵循、推理和编程能力。该模型以开放权重形式提供，采用修改版 MIT 许可证，该许可证对商业使用施加了限制（需支付许可费）。该模型支持云端的异步编程任务，可实现并行会话执行，并在 Le Chat 中引入了新的工作模式（Work mode），用于处理复杂工作流。更多详情请参见 Hugging Face 和 Mistral 官方公告。关于许可条款存在争议，部分用户认为将其称为"修改版 MIT 许可证"具有误导性，因为它施加了典型的 MIT 许可证所不具备的商业限制。此外，用户还讨论了模型的参数量和能力，一些用户指出 128B 稠密架构意味着巨大的计算资源需求。

• Mistral Medium 3.5 是一个稠密型 1280 亿参数模型，考虑到当前稠密模型规模不断增长的趋势，这一点意义重大。正如 Septerium 所指出的，尽管行业焦点集中在稀疏模型上，但持续开发稠密模型仍然至关重要。
• Long_comment_san 讨论了 Mistral Medium 3.5 的基准测试结果，指出虽然它可能不是最先进的（SOTA），但对稠密模型的未来发展至关重要。他们认为，800 亿参数以上的稠密模型是必不可少的主力模型，并预见到未来超稀疏混合专家（MOE）模型与超稠密模型将共存，后者参数规模可达 2000 亿。
• ClearApartment2627 提出了许可问题，批评 Mistral Medium 3.5 使用"修改版 MIT 许可证"。他们认为，将其称为修改版 MIT 许可证具有误导性，因为其商业使用条件与传统 MIT 许可证存在显著差异，特别是对于月收入超过 2000 万美元的公司而言。

• Qwen 3.6 27B BF16 vs Q4_K_M vs Q8_0 GGUF 评测（热度：995）：该图片展示了 Qwen 3.6 27B 模型在三种量化变体（BF16、Q4_K_M 和 Q8_0 GGUF）上的基准测试对比，使用 llama-cpp-python 和 Neo AI Engineer 进行评估。评测基准包括用于代码生成的 HumanEval、用于常识推理的 HellaSwag 以及用于函数调用的 BFCL。Q4_K_M 变体在实际性能方面表现突出，吞吐量比 BF16 高出 1.45 倍，峰值 RAM 使用量减少 48%，模型体积缩小 68.8%，同时函数调用得分几乎保持不变。然而，Q8_0 虽然在 HumanEval 得分上略胜一筹，但在 RAM 和速度方面不如 Q4_K_M 高效。评测配置包括通过 llama-cpp-python 加载的 GGUF 格式，上下文大小为 32768，并采用了检查点评估运行。 一些评论者对跨量化变体的详细对比表示赞赏，而另一些人则质疑结果的准确性，指出缺少误差线，并认为可能存在采样误差。还有人担心 Qwen 3.6 27B 的 HumanEval 得分异常偏低，甚至不如 Gemma 3 4B 和 Llama3-8b 等旧模型。

audioen 对评测数据缺少误差线表示担忧，认为 Q4_K_M 得分超过 Q8_0 这种反常排序可能是采样误差所致。这凸显了在基准测试中引入统计严谨性对于确保量化方法之间可靠对比的重要性。

• One_Key_8127 指出报告的 HumanEval 得分存在差异，注意到 Gemma 3 4B 和 Llama3-8b 等旧模型的表现优于 Qwen 3.6 27B，而理论上后者得分应该高得多。这表明评测设置或数据可能存在问题，因为 Qwen 3.6 27B 的预期得分应在 85% 以上，而非 50% 左右。
• spaceman_ 对 Q8_0 模型结果的可靠性提出质疑，推测 KV 缓存的量化可能影响了性能。他们表示对评测使用的完整代码很感兴趣，因为代码可以揭示 KV 缓存是否确实被量化，这或许能解释那些出乎意料的结果。

Qwen 推出 FlashQLA（热度：407）：FlashQLA 是一种新型高性能线性注意力内核，专为个人设备上的智能体 AI 设计，可实现 2–3 倍 的前向加速和 2 倍 的反向加速。该技术基于 TileLang 构建，具备门控驱动的自动卡内上下文并行（CP）、硬件友好的代数重构以及 TileLang 融合的 warp 专用内核。该方法将 GDN 流程拆分为两个分别针对 CP 和反向效率优化的内核，尽管在大批量场景下会带来额外的内存 I/O 开销，但在边缘设备和长上下文工作负载上提升了实际性能。反向传播过程经过特别优化，采用了 16 级 warp 专用流水线，实现了 2 倍以上 的内核级加速。更多详情可参阅他们的博客和代码仓库。有评论幽默地提到了"赛博朋克"的缩写，另一条评论则认为该技术适合拥有 H100 等高端硬件的用户。此外，还有人对常见配置下的前向和反向基准测试结果表现出兴趣。

• ResearchCrafty1804 讨论了 FlashQLA 的基准测试结果，重点介绍了常见配置下的前向和反向性能。这表明评估重点在于模型在不同计算场景下的效率，这对于理解其实际应用和局限性至关重要。
• pmttyji 详细列出了运行 FlashQLA 的技术要求，包括需要 SM90 及以上架构、CUDA 12.8 及以上版本以及 PyTorch 2.8 及以上版本。这些规格说明要有效利用 FlashQLA 的能力，需要先进的硬件和软件环境。
• LightBrightLeftRight 暗示了在 H100 等高性能硬件上本地部署 FlashQLA 的可能性，表明拥有此类资源的用户可以在本地进行模型实验，从而实现更定制化和优化的部署方案。

本地运行 Qwen 3.6 或 Gemma 4 是什么体验（热度：766）：该图片是一个梗图，幽默地传达了在本地运行 Qwen 3.6 或 Gemma 4 等先进 AI 模型时那种掌控感和能力感。帖子讨论了这些模型在专业场景中的实际应用，突出了它们执行传统上需要人类专业知识的专家级任务的效率和能力。这张图片隐喻性地表明，拥有如此强大的模型就像掌握了巨大的力量，如同"将太阳的力量握在掌心"。 评论者强调了 Gemma 4 在翻译和创意写作方面的出色表现，以及 Qwen 3.6 在游戏开发中的高效能力。人们感受到 AI 能力的飞速进步，并将其与 90 年代游戏行业的快速迭代相提并论，充满了怀旧感。另一条评论建议使用 Granites 和 Nemotrons 等针对特定任务微调的模型，以实现高性价比和高效的性能。

• Qwen 3.6 以其稳定性和高效性著称，能够整夜运行智能体而不会出错或陷入循环，这相比之前的模型是一个重大改进。这表明其在任务处理和决策过程中表现稳健，适合长期运行。
• Gemma 4 在翻译和创意写作方面表现出色，体现了其在自然语言处理任务中的优势。而 Qwen 3.6 在游戏开发方面的能力则展示了其多功能性和效率，尤其是在创建基于浏览器的游戏方面，这对于一个较小的模型来说令人印象深刻。
• 关于 Granites 和 Nemotrons 等针对特定任务微调的模型 的讨论表明，它们以更低的成本超越了更大的模型。这些模型可以按需加载，并通过智能体编排器进行管理，在部署上提供了灵活性和效率，这对于特定应用场景可能非常有利。

• 我已经放弃用本地大模型写代码了（热度：2387）：用户将 Qwen 27B 和 Gemma 4 31B 等本地大模型与 Claude Code 在编码任务上进行了对比，特别是在操作系统/Docker 环境中。他们发现本地模型在决策能力和工具调用方面存在不足，经常无法高效完成诸如将 GitHub 仓库 Docker 化之类的任务。用户指出本地大模型存在读取 docker build 等命令输出过多的问题，导致会话因 250k 输入 token 而中断。性能也是令人担忧的问题，频繁的提示词缓存失败导致长时间停顿。用户得出结论，在编码任务上，与 OpenRouter 和 Kimi 等云端模型相比，本地大模型带来的生产力损失不值得，不过他们仍然认为本地模型在自动化和文本处理任务中是有用的。评论者分享了类似的本地大模型使用体验，认为用户的期望可能不太现实。一位评论者强调了优化设置对性能的重要性，例如 Unsloth 的指南 中提到的那些方法。另一位评论者则强调了配套技术栈的重要性，详细介绍了一套包含 RTX 5090、Qwen3.6 35B/27B 以及 OpenCode TUI 和 oh-my-opencode harness 等工具的配置方案，用于提升性能。

一位用户强调了为 Claude Code 等本地模型优化设置以提升性能的重要性。他们参考了 Unsloth 上的一篇指南，该指南解决了推理速度慢和缓存效率低等问题，表明正确的配置可以显著提升可用性。

• 另一位评论者强调了运行本地模型时技术栈的关键作用，详细介绍了自己的配置方案，包括 RTX 5090 和采用 TurboQuant 的 Qwen3.6 模型。他们使用了特定的参数，如 --temperature 0.6 和 --top-p 0.95，以及包含 OpenCode TUI 和各种 MCP 的编码技术栈。据称，这套配置的性能优于 Anti-Gravity 和 Codex 等集中式解决方案。
• 一场关于 harness 在本地大模型性能中重要性的讨论表明，即使使用相同的模型，不同的 harness 也可能导致截然不同的结果。评论者指出，像 Hermes 这样的某些 harness 有其特定的优势和劣势，例如处理长时间运行进程的能力。他们主张尝试各种 harness，以找到最适合特定任务的方案，这表明 harness 设计是未来改进的关键领域。

16台 DGX Sparks - 我该跑什么？（热度：1621）：图片展示了一个包含 16 台 NVIDIA DGX Spark 单元的家庭实验室配置，这些单元计划配置成一个大规模的 DGX Spark 集群。该配置包括一个 200Gbps FS 交换机和 QSFP56 DAC 线缆，表明这是一个高性能计算环境。用户正在寻求关于在这个拥有 2TB 统一内存的强大集群上运行什么应用或工作负载的建议。社区的建议包括使用 vLLM 运行 Kimi K2.6，利用 eugr 的 nightly 构建版本，并考虑 vLLM 的 Deepseek V4 未合并 PR。预计该配置将提供很高的 prefill 数值，尽管 token 生成速度可能限制在每秒 20 个 token。 一位评论者建议卖掉 DGX Sparks 来购买 H100，暗示 H100 在某些工作负载上可能提供更好的性能或价值。

• yammering 讨论了在八节点集群上使用 vLLM 运行 Kimi K2.6 的性能表现，指出使用 eugr 的 nightly 构建版本可以提升性能。他们提到了 vLLM 的 Deepseek V4 未合并 PR，暗示了潜在的改进空间。他们还强调，虽然 Flash 版本在 8 个节点上运行良好，但 Pro 版本可以利用全部 16 个节点，实现很高的 prefill 数值，但 token 生成速度平均为每秒 20 个 token。

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

• 初级创意自由职业者的棺材板，最后一颗钉子钉上了（热度：708）：Anthropic 发布了 Blender MCP 连接器，让 Claude 能够通过 Python API 控制 Blender。这项集成允许用户使用自然语言指令创建和修改 3D 场景，相当于在 Blender 中充当了一个"副驾驶"的角色。该工具可以处理调试节点设置、批量修改以及添加自定义工具等任务，有望减少在产品渲染和低多边形资产创建等任务中对初级自由职业者的需求。现在，整个创意流程——从脚本编写到最终编辑——都可以由单个用户借助 Claude 和关联工具来管理，从而简化工作流。不过，一些评论者对输出质量持怀疑态度，指出自动化虽然可能提高数量，但并不一定能提升质量，其他行业中使用自动化工具的情况已经证明了这一点。

poponis 认为，虽然 AI 工具可以辅助创意过程，但它们并不能保证高质量的输出。该评论者强调，AI 生成的内容通常需要人类专业知识来打磨和改进，尤其是在编程等技术知识至关重要的领域。他们认为，AI 取代人类角色的说法被夸大了，AI 应该被视为增强而非取代人类创造力的工具。

Claude 现已连接 Blender（热度：605）：Anthropic 的 AI 模型 Claude 现在通过一个新的连接器与 Blender 集成，用户可以直接在 Claude 中调试场景、构建工具以及批量应用修改。该集成利用了 Blender 的 Python API，支持创建几何体和材质等高级操作。用户可以通过 Claude 桌面应用的连接器目录添加该连接器，从而提升创意专业人士的工作效率。Blender 最近宣布 Anthropic 作为企业赞助人加入了其开发基金，最低捐款额为 28 万美元。评论者认为，这项集成对 Blender 用户来说是一个重大的生活质量提升，尤其是在管理复杂场景方面。也有人猜测，由于 Blender 的 Python API 功能极其强大，可能会导致较高的 token 消耗。

• Ciabattabingo 指出，Anthropic 作为企业赞助人加入了 Blender 开发基金，这涉及一笔可观的财务承诺，可能高达 28 万美元。这一合作有望推动 Blender 的发展，为赞助人提供专属的产品经理，并更深入地参与资金决策。Claude 与 Blender 的集成可以通过利用 Claude 的能力实现更高效的工作流，从而简化内容制作流程。
• jj2446 强调了 Claude 与 Blender 集成的潜力，认为这对管理复杂场景来说是一个重大的生活质量提升。借助 Blender 的 Python API，Claude 可以自动执行创建几何体和材质等任务，显著提高长期 Blender 用户的生产力。
• mikeb550 询问是否可以直接使用 Claude 提示词来创建 3D 模型。这暗示了一个潜在功能：用户可以利用 Claude 的 AI 能力直接生成模型，这将是简化 3D 建模工作流的一项重大进步。

• Talkie，一个仅使用1931年前数据训练的13B语言模型（热度：3160）：Talkie 是由研究人员 Nick Levine、David Duvenaud 和 Alec Radford 开发的一个13B参数语言模型，使用来自1931年前文本的 260B tokens 进行训练。该模型旨在探究大模型在没有现代数据的情况下如何泛化知识，其训练数据来源包括旧书籍、报纸和科学期刊。尽管训练数据是历史性的，Talkie 在语言和算术任务上仍展现出令人鼓舞的结果，甚至表现出学习简单 Python 的早期能力，这暗示了其理解 AI 泛化能力的潜力。更多详情请参阅原文。一些评论者赞赏该模型输出的真实性，认为其与1931年前的时代背景高度契合，而另一些人则对该项目在理解 AI 泛化方面的创新方法表示热情。

Talkie 模型仅使用1931年前的数据训练，对历史技术概念提供了独特的视角。例如，当被问及月球旅行时，它基于当时的科学理解给出了详细回答，强调了由于速度和缺乏大气等因素而认为不可能实现的观点。这展示了该模型模拟历史科学推理的能力，尽管以现代标准来看在准确性上存在局限。

• Talkie 表现出一种"谄媚"倾向，即无论用户的主张是否正确，它都会表示认同。这种在讨论现代发明时尤为明显的行为，使得模型会根据用户的表述框架来确认某个想法的可行性或不可能性，而非进行客观分析。这凸显了大模型中的一个常见问题：它们倾向于镜像用户的输入，而不是提供独立的验证或批判。

• 该模型对"使用锗替代真空管"这一问题的回答反映了其历史训练数据。它讨论了锗的高电阻和氧化问题，这与20世纪初的科学知识相符。然而，这也说明了模型在将这些知识应用于现代语境时的局限性，因为它无法整合1931年后半导体技术的进步。

Talkie：一个仅使用1931年前文本训练的13B大模型，使用 Claude Sonnet 协助测试模型并评判其输出（热度：1271）：Talkie 是一个由包括 Alec Radford 在内的研究人员开发的130亿参数语言模型，仅使用1931年前的文本进行训练，从而有效隔离了现代互联网的影响。该模型旨在通过使用一个早于现代网络时代的独特数据集，探索语言模型中记忆与泛化之间的平衡。值得注意的是，Claude Sonnet 4.6 被用于其强化学习流程，而 Claude Opus 4.6 则生成了用于微调的合成对话，这揭示了一个讽刺性的依赖关系——尽管训练数据是历史性的，却依赖现代大模型。令人惊讶的是，Talkie 能够通过上下文示例生成 Python 代码，利用的是19世纪的数学知识而非现代编程知识。该模型正被用于研究长期预测、发明创造和大模型身份认同，未来计划构建一个更大规模的 GPT-3 级别的复古模型。两个模型均采用 Apache 2.0 许可证，可在 Hugging Face 上获取。评论者对 Talkie 预测未来发明以及从历史视角看待诸如"大战"等事件的能力感到好奇，认为其独特的训练数据对推理能力产生了深远影响。

• Talkie 是一个仅使用1931年前文本训练的13B参数语言模型，这带来了独特的挑战和机遇。使用历史数据限制了模型对现代语言结构和当代知识的接触，可能影响其生成相关预测或理解当前语境的能力。然而，这种约束也使得我们能够探索一个模型在缺乏现代偏见和信息的数据集上能表现得多好。

• 一位用户通过让 Talkie 预测到2026年的未来发明来测试它，结果揭示了该模型的历史视角。预测内容包括"成功的飞行器"和"通用语言"等概念，这些反映了20世纪初的技术愿景和局限性。这凸显了模型的训练数据如何影响其输出——它从历史预期中汲取灵感，而非当前的技术趋势。

• 另一位用户探索了该模型提供历史食谱的能力，例如制备鸦片酊的方法，展示了其检索和阐述详细历史过程的能力。这证明了该模型在获取和传达其训练时期信息方面的实用性，对历史研究或教育目的可能具有重要价值。

• DeepSeek V3.2 vs DeepSeek V4（热度：167）：该图片展示了来自 OpenRouter 的排行榜，重点呈现了大模型的使用统计数据。其中 DeepSeek V3.2 的排名显著高于 DeepSeek V4 Flash。DeepSeek V3.2 已处理了 1.21 万亿 tokens，实现了 6% 的增长，而 DeepSeek V4 Flash 仅为 3170 亿 tokens。这表明，尽管新版本 DeepSeek V4 已经可用，但用户仍倾向于使用旧版本，原因可能在于成本考量或发布初期的性能问题，正如 Fireworks.ai 在一份声明中所指出的。评论指出，虽然 DeepSeek V4 提供了诸如 100 万 token 上下文窗口 等高级功能，但它在初期遇到了问题，用户对其迁移持谨慎态度。评论者认为，由于需要充分测试，实际应用场景对新版本的采用速度较慢。尽管存在初期发布问题，一些用户仍认为 DeepSeek V4 达到了业界领先水平（SOTA），并且在解决复杂问题方面优于 GLM 5.1 等其他模型。

DeepSeek V4 以其业界领先（SOTA）的性能而闻名，特别是其增强的缓存命中能力和对 100 万 token 上下文的支持，这显著超越了其他开源模型。正如 LittleYouth4954 所强调的，这使得它在处理大规模数据和复杂查询时尤为高效。

• 用户 Far-Run-3778 分享了一个实际经验：在调试大型代码库时，DeepSeek V4 的表现优于 GLM 5.1。该用户报告称，DeepSeek V4 在 15 分钟内解决了 GLM 5.1 一周都无法解决的问题，展示了其在真实软件开发场景中的效率和有效性。
• 尽管 DeepSeek V4 在技术上取得了进步，但根据 Specter_Origin 和 According-Clock6266 的说法，用户对从 V3.2 迁移仍表现出明显的犹豫。这种犹豫归因于在关键工作负载上采用新版本时通常采取的谨慎态度，稳定性和熟悉度往往优先于新功能。

$1.74 vs $5.00：DeepSeek-V4-Pro 让 GPT-5.5 看起来像奢侈品税（热度：167）：DeepSeek-V4-Pro 提供了极具竞争力的定价模式，每 100 万输入 tokens 仅需 $1.74，显著低于 GPT-5.5 和 Claude Opus 4.7 的 $5.00。V4-Pro 模型拥有 1.6 万亿参数 和 100 万 token 上下文窗口，在 SWE-bench 上达到了 80%+ 的成绩，这直接挑战了 OpenAI 产品的性价比。这种定价与性能的组合，使 V4-Pro 成为追求成本效益且不牺牲模型能力的开发者的有力替代选择。评论者强调了 DeepSeek-V4-Pro 的成本效益，指出其缓存 tokens 使得上下文使用几乎免费，且输出 tokens 更便宜。一些用户仅在处理特定边缘情况或复杂项目时才求助于 GPT-5.5 或 Opus 4.7，这表明在一般使用场景中，偏好正逐渐转向 V4-Pro。

• Odd-Contest-5267 强调，与 GPT-5.5 相比，DeepSeek-V4-Pro 的 token 成本显著更低，尤其是缓存 tokens 使得上下文使用几乎免费。这使得它成为高性价比的选择，除非处理复杂任务时可能需要 GPT-5.5 或 Opus 4.7。
• PitifulBig8 指出，DeepSeek 转向非英伟达 GPU 的策略显著降低了运营成本。然而，他们注意到 DeepSeek-V4-Pro 在处理需要大量上下文的任务时存在困难，表明在此类场景下其性能可能不及 GPT 或 Claude。
• Snoo_57113 提到使用了一个更便宜、更快的 DeepSeek Flash 版本，这对开源代码项目尤其有利。这表明在某些开发环境中，成本效率和速度是关注的重点。