AI 开发者日报

• Claude Opus 4.7 是当天最重要的模型发布，Anthropic将其定位为迄今为止最强大的Opus版本，在长期任务执行、指令遵循、自我验证和计算机使用工作流方面都有所改进 @claudeai。第三方和生态系统反馈都指向同一个核心结论：编码和智能体基准测试表现显著提升，价格与Opus 4.6保持一致（每百万token 5美元/25美元），在API和产品中更广泛地推出，并新增了xhigh推理层级 @kimmonismus, @cursor_ai, @code。

• 基准测试提升显著，特别是在软件工程领域。社区总结显示SWE-bench Pro达到64.3%，SWE-bench Verified达到87.6%，TerminalBench达到69.4% @scaling01。Vals报告称Opus 4.7在Vals Index上达到71.4%，在多个评估中排名第一，包括Vibe Code Bench、Finance Agent、SWE-Bench和Terminal Bench 2 @ValsAI。Artificial Analysis也在发布时将其置于GDPval-AA榜首，Elo评分为1753 @ArtificialAnlys。

• 技术层面的变化：多位观察者注意到新的分词器，这表明这不仅仅是一次轻量级的微调，可能是一个新的或中期训练的基础模型 @natolambert, @nrehiew_。Anthropic还将图像输入分辨率提高到约3.75MP，这对于依赖大量截图的计算机使用智能体来说很重要 @kimmonismus。Anthropic员工表示该模型使用了更多的思考token，订阅者的速率限制也相应提高以作补偿 @bcherny, @bcherny。

• 注意事项与争议：多位用户指出在某些长上下文基准测试中得分较差，特别是MRCR/针式检索测试，以及在编码之外的现实世界应用中表现参差不齐 @scaling01, @eliebakouch, @MParakhin。Anthropic的Boris Cherny认为MRCR正在被降级处理，转而优先考虑更实用的长上下文信号，如Graphwalks，其内部得分从38.7%提升至58.6% @bcherny, @scaling01。还有人对更强的系统提示和"字面"指令遵循对用户体验的影响进行了审视 @theo, @Yuchenj_UW。

• 快速的下游采用立即展开：在几小时内就获得了Cursor、VS Code / @code、Replit Agent、Devin、Cline、Perplexity和Hermes Agent的支持 @cursor_ai, @code, @pirroh, @cognition, @cline, @perplexity_ai, @Teknium。

• Codex的产品覆盖范围急剧扩大。OpenAI将Codex从编码助手重新定位为更广泛的计算机智能体，具备Mac电脑使用、应用内浏览器、图像生成/编辑、90多个插件、多终端支持、SSH远程开发环境访问、持续线程自动化/"心跳"机制、更丰富的文件预览以及偏好记忆功能 @OpenAI, @OpenAIDevs, @OpenAI, @OpenAIDevs, @pashmerepat。OpenAI明确将其定位为支持"编写代码之前、期间和之后"的工作。

• 关键产品策略与Anthropic不同：Anthropic专注于前沿模型能力；而OpenAI则推动智能体工作空间集成。多位开发者强调了后台Mac控制的重要性，这种控制不会阻塞用户，浏览器/文档/图像工具使Codex在纯编码之外也很有用 @AriX, @JamesZmSun, @wonforall, @sama, @kimmonismus。NVIDIA公开支持这一方向，指出Codex正在覆盖更多软件工作流程 @nvidia。

• GPT-Rosalind是OpenAI第二个值得关注的发布：这是一个面向生物学、药物发现和转化医学的受信任访问前沿推理模型，客户包括Amgen、Moderna、Allen Institute和Thermo Fisher @OpenAI, @OpenAI。OpenAI描述其针对蛋白质和化学推理、基因组学、生物化学知识以及科学工具使用进行了优化 @OpenAI, @kevinweil。

• 解读：Rosalind看起来不像是一个单一的突破性基准怪物，更像是垂直化的编排/推理产品，标志着前沿实验室正在向领域特定模型系列和受控部署结构迈进 @kimmonismus。

• 阿里巴巴发布了Qwen3.6-35B-A3B，这是一款采用Apache 2.0开源许可的稀疏MoE模型，拥有350亿总参数，30亿激活参数，具备原生多模态能力，并支持思考/非思考两种模式@Alibaba_Qwen。其核心宣称是在远低于密集模型竞争对手的激活参数预算下，实现强大的智能编码能力。

• 性能表现在该规模级别中相当突出。阿里巴巴强调，在编码基准测试中，该模型相比Qwen3.5-35B-A3B和密集模型Qwen3.5-27B都有显著提升@Alibaba_Qwen。社区总结指出其SWE-bench Verified达到73.4，Terminal-Bench 2.0达到51.5，以及QwenWebBench Elo达到1397@kimmonismus。在视觉语言模型基准测试中，阿里巴巴宣称在多项任务上性能接近Claude Sonnet 4.5，特别是在空间理解方面表现尤为出色，如RefCOCO达到92.0，ODInW13达到50.8@Alibaba_Qwen。

• 部署支持在发布首日就异常强大。vLLM v0.19+迅速提供了支持，包括工具调用、思考模式、MTP推测解码和纯文本模式@vllm_project。Ollama立即推出了本地支持@ollama，而Unsloth表示该模型可以在23GB内存的本地环境中运行，甚至2位GGUF量化版本只需13GB内存就能支持工具密集型的本地智能体工作流@UnslothAI，@UnslothAI。

• 更广泛的趋势：多位评论者明确将Qwen与当前向更小、更智能、采用Apache/宽松许可模型的转变联系起来，这些模型更适合本地或基础设施高效的部署@matvelloso，@WuMinghao_nlp。

• Cloudflare 推出了 Artifacts，被描述为专为智能体构建的 Git 兼容版本化存储系统@Cloudflare, @dillon_mulroy。其核心理念是当前源代码控制系统并非为智能体生成的大量提交而设计；这为每个智能体会话提供了类似仓库的持久化文件系统。开发者立即将其视为 Workers/Durable Objects 上构建原生智能体应用的关键缺失基础组件@jpschroeder, @whoiskatrin。

• Cloudflare Email Service 进入公开测试阶段，支持直接从 Workers 或 REST API 发送和接收邮件，这对电子邮件智能体具有明显意义@thomasgauvin, @whoiskatrin。这延续了 Cloudflare 快速推出智能体相关基础设施基础组件的模式，以至于一些开发者现在将 Workers/V8 视为智能体系统的"正确基础组件"@mattrickard。

• 推理/平台融合：围绕 Workers AI 的帖子描述了一个更加统一的平台，其中单个绑定可以同时访问托管和代理模型，通过 Cloudflare/Replicate 集成以及更明确的推理控制/数据平面目标@_mchenco, @corywilkerson。

• 开放世界/生产环境评估成为一个反复出现的主题。新论文和项目CRUX认为基准测试正在饱和，该领域正朝着开放世界评估的方向发展：即长周期、复杂、真实的任务。他们的首个公开任务是为智能体提供一个Apple开发者账户和Mac虚拟机，要求其构建并发布一个iOS应用；该任务以大约1,000美元的成本成功完成@random_walker, @dongyangzi。相关讨论将开放世界评估视为超越基准测试排行榜的自然下一步@sayashk, @steverab。

• AlphaEval同样推动产品级智能体评估，使用了来自七家公司的94个任务以及混合评估模式，包括形式验证、UI测试、评分标准和领域检查@dair_ai。核心观点是：围绕干净回顾性任务构建的智能体评估正在偏离生产现实。

• FrontierSWE将相同逻辑扩展到编码智能体，专注于超长周期任务，平均运行时间约11小时，即使是前沿模型也会出现严重失败@MatternJustus。合作伙伴包括Prime Intellect、Modular和ThoughtfulLab，他们贡献了涵盖推理引擎优化和后训练任务的环境@PrimeIntellect, @Modular, @ThoughtfulLab_。

• 智能体产品在内存和共享状态方面持续增强：Nous/MiniMax推出了MaxHermes，一个托管的Hermes部署@MiniMax_AI；Mirra Workspaces引入了共享多租户环境和本地智能体的技能同步@mirra；Nous在Portal中发布了Tool Gateway，将300多个模型的访问权限和一组第三方工具捆绑在一个订阅下@NousResearch, @Teknium。

• Claude Opus 4.7发布 来自Anthropic，在整体互动量上占据主导地位，并设定了当天的技术议程 @claudeai。
• Qwen3.6-35B-A3B开源发布 是突出的开源模型发布，结合了较小的活跃参数数量与强大的编码/VLM能力声明，并采用Apache许可证 @Alibaba_Qwen。
• Perplexity Personal Computer 作为本地编排的计算机代理概念吸引了大量关注，适用于Mac、文件、应用和浏览器，可在Mac mini上24/7后台运行 @perplexity_ai，@AravSrinivas。
• Codex扩展的代理工作空间 是最大的产品发布之一：广泛的计算机使用、应用/浏览器控制、插件、记忆和长期运行的自动化功能 @OpenAI。
• GPT-Rosalind 作为一个明确的信号脱颖而出，表明前沿实验室正在为受监管/高价值垂直领域构建特定领域模型系列，而不仅仅是发布通用模型 @OpenAI。

• Qwen3.6-35B-A3B 正式发布！（活跃度：2730）：图片展示了新发布的 Qwen3.6-35B-A3B 模型 与 Qwen3.5-27B、Gemma4-31B 等其他模型在各种基准测试中的性能对比柱状图。这款稀疏 MoE 模型拥有 35B 总参数和 3B 激活参数，在智能编码和推理任务中表现出色，超越了其前代模型和类似规模的其他模型。该模型采用 Apache 2.0 开源许可证，强调其强大的多模态感知和推理能力，可在 HuggingFace 和 ModelScope 等平台获取。评论者强调了该模型的卓越性能，指出其在关键编码基准测试中超越了密集参数为 27B 的 Qwen3.5-27B。同时，社区也期待未来可能挑战 Google 等公司更大模型的版本发布。

ResearchCrafty1804 指出，Qwen3.6-35B-A3B 模型在智能编码和推理任务方面显著超越了其前代 Qwen3.5-35B-A3B。这一改进尤为引人注目，因为它在多个关键编码基准测试中也超越了密集参数为 27B 的 Qwen3.5-27B，表明本地大模型性能实现了重大飞跃。

• ResearchCrafty1804 还提到了该模型的视觉语言能力，强调 Qwen3.6-35B-A3B 是原生多模态模型。它在视觉语言基准测试中表现优异，在 RefCOCO 上获得 92.0 分，在 ODInW13 上获得 50.8 分。这些结果表明，其多模态推理能力与 Claude Sonnet 4.5 相当甚至超越，特别是在空间智能任务方面。
• AndreVallestero 推测了可能发布的更大规模 Qwen3.6 模型，例如 122B 版本，这可能给 Google 等竞争对手带来压力，促使其发布自己的大型模型。这一讨论暗示了 AI 模型开发领域的竞争格局，模型规模和能力的进步可能会影响市场动态和创新。

Qwen3.6-35B-A3B 发布（活跃度：604）：图片展示了阿里巴巴新发布的 Qwen3.6-35B-A3B 模型 在 Terminal-Bench、SWE-bench 和 GPQA Diamond 等各种基准测试中的性能表现。柱状图显示，Qwen3.6-35B-A3B 通常优于 Qwen3.5 和 Gemma4 等先前模型，特别是在编码、推理和图像处理相关任务中。该版本已在 Hugging Face 上发布，表明相对较小的更新带来了显著的性能提升。评论者对此次更新带来的性能提升印象深刻，注意到其相对于 Gemma4 等先前模型的竞争优势。社区也期待类似更新能应用于 122B 和 397B 等更大规模的模型。

• Willing-Toe1942 指出，Qwen 团队似乎有策略地将 Qwen3.6-35B-A3B 与 Qwen3.5 和 Gemma4 进行对比，这表明了显著的性能改进。这意味着最新版本具有竞争优势，可能表明模型效率或能力取得了实质性进展。
• lacerating_aura 对可能发布的 122B 和 397B 等更大模型的开放权重表示兴趣，这表明社区渴望获得更易访问的高容量模型。这反映了对透明度和实验更大架构能力的需求。
• itisyeetime 推测了 Qwen3.6-35B-A3B 的性能定位，认为它可能介于 Qwen 3.5 122B 和 Qwen 3.5 35B 之间。这引发了关于基准测试优化程度以及新模型是否相对于更大的 122B 模型提供实质性改进的问题。

Qwen3.6-35B-A3B 发布（活跃度：101）：图片展示了新发布的 Qwen3.6-35B-A3B 模型 与 "Qwen3.5-35B-A3B"、"Gemma4-26B-A4B" 和 "Qwen3.5-27B" 等其他模型的性能对比。Qwen3.6-35B-A3B 模型（以紫色柱状图表示）在编码、推理和图像处理等各种基准测试中均表现出卓越性能。这表明该模型相对于其前代和竞争对手在能力上取得了显著改进，突显了 AI 模型开发领域的进步。一位评论者表达了希望获得专注于编码的 Qwen3.6 模型专门版本，这表明了对 AI 模型进一步专业化的兴趣。另一位评论者幽默地建议耐心下载模型以避免服务器过载，暗示了社区渴望测试新版本的热情。

• 本地AI是最佳选择（活跃度：602）：这张图片是一个幽默的梗图，展示了与本地AI模型的互动，强调了使用本地托管AI系统的坦诚和自由。帖子突出了本地AI的优势，比如能够在不被审查或数据收集的情况下微调模型，并对llama.cpp等开源权重模型的开发者表示感谢。图片和帖子共同强调了本地AI对注重隐私、重视数据和控制交互的用户的吸引力。一位评论者称赞llama.cpp为"goated"，表明对其能力的高度认可。另一位则警告说，较小的本地模型有时可能比大型前沿模型表现出更多偏见或"glaze"，这暗示了对本地AI局限性的细致看法。

一位用户测试了Minimax m2.7模型，将其与Openrouter上的"Elephant"模型进行比较，指出尽管"Elephant"模型具有较高的token吞吐量，但其性能不如27B等较小模型。用户强调，像DeepSeek、OpenAI和Anthropic这样的实验室在推理优化方面更为出色，这表明"Elephant"背后的实验室在优化方面存在困难，而这对模型性能至关重要。

• 一位用户询问了配备9070xt GPU和64GB RAM的系统在本地AI托管方面的能力。这种配置被认为是本地模型托管的高端设置，用户被建议要管理好对本地运行大型模型的性能和能力的期望，因为硬件限制可能会影响推理的效率和速度。

• 一条评论提到了较小本地模型的潜在问题，指出它们有时在"glazing"方面可能比前沿模型表现更差，这可能指的是生成不太连贯或相关的输出。这突显了在实现期望性能水平时，模型选择和优化的重要性。

本地大模型真的有用吗……还是只是好玩而已？（活跃度：541）：本地大模型在隐私和成本节约方面具有显著优势，因为它们消除了API成本并将数据保留在本地。然而，它们通常需要大量的设置和维护工作，这可能会成为实际使用的障碍。尽管存在这些挑战，本地模型在处理敏感或内部数据（如笔记、草稿和私人文档）方面表现出色，在这些场景中数据隐私至关重要。一些用户报告称，像Gemma 4家族的31B这样的本地模型表现异常出色，特别是在编码、创意写作和日常聊天等任务上，当运行在3090 24GB GPU和192GB RAM这样的高性能硬件上时。共识是，虽然云模型因需求增加而性能下降，但本地模型正在改进并变得更加实用。用户指出，主要限制不是模型的能力，而是设置和维护它们的复杂性。一些人预见，在不久的将来，本地大模型将不仅适用于实验，还能成为常规工作流程的可行选择。

• 本地大模型在处理敏感或内部数据方面特别有优势，因为它们无需API成本且数据不会离开系统。主要挑战在于设置和维护，一旦流程简化，可以使"离线GPT"设置不仅适用于实验，还能用于日常工作。

• 像Gemma 4家族的31B这样的本地模型的性能被强调为异常出色，特别是与因需求增加而性能下降的云API模型相比。这位用户使用3090 24GB GPU和192GB RAM来运行多个变体，用于编码和创意写作等任务，这表明了本地模型在适当配置下的潜力。

• 与基于云的解决方案相比，本地大模型可能更具成本效益，特别是对于API成本可能过高的复杂项目。然而，它们需要仔细的架构规划，以确保模型得到有效使用，例如使用32B模型作为隐私过滤器来管理业务通信，而无需将个人数据暴露给外部API。

本地Gemma 4 31B在分类和总结60,000封邮件存档方面出奇地好（活跃度：112）：帖子描述了使用本地gemma-4-31b-it模型处理与计算机和学术自由（CAF）项目相关的60,000封邮件存档。设置涉及一台HP ZBook Ultra G1a，配备AMD Ryzen AI MAX+ PRO 395处理器、16个核心和128 GB RAM，通过LM Studio的OpenAI兼容API本地运行模型。该过程使用两阶段流水线：第一阶段过滤掉68.4%的不相关邮件，而第二阶段对剩余邮件进行分类和总结，生成结构化的JSON输出。该模型在历史分类和总结方面的表现被认为是有效的，主要挑战在于解析旧的邮件格式。该项目已完成20%，作者对改进建议持开放态度，例如使用较小的模型进行第一阶段处理或使用嵌入进行过滤。一位评论者建议通过将模型的总结结果与前沿模型的结果进行比较来验证其准确性。另一位则强调了这种方法在处理FOIA材料方面的潜在实用性。第三条评论赞扬了Gemma 4 E2B模型在处理结构化任务方面的效率和能力，尽管其规模较小。

• GMP10152015强调了Gemma 4 E2B模型的效率，该模型大约有20亿有效参数。尽管规模相对较小，它在日常任务中表现良好，特别是在工具使用方面，保持了结构化调用的一致性和清晰性。这表明即使是较小的模型对于特定应用也可能非常有效，挑战了较大模型总是更优越的观念。

• singh_taranjeet提出了关于运行Gemma-4-31b模型的硬件要求的技术问题，指出128GB RAM对于本地推理来说是相当大的。他们好奇在使用8K上下文时每秒的token吞吐量，因为这种规模的模型通常至少需要64GB的RAM。这表明对于大规模邮件处理，优化性能和资源分配是一个重点。

• machinegunkisses讨论了验证模型生成的总结质量的挑战。他们提出了一种验证方法，通过将模型的输出与前沿模型的输出进行比较，这表明需要强大的评估技术来确保AI生成总结的可靠性。这突显了将AI模型与既定标准进行基准测试以评估其性能的重要性。

• Gemma4 26b和E4B表现惊人，已取代Qwen成为我的首选！（活跃度：646）：用户已将他们之前使用Qwen模型的配置替换为Gemma 4 E4B进行语义路由，以及Gemma 4 26b处理通用任务，并指出在路由准确性和任务性能方面都有显著提升。之前的配置包括使用Qwen 3.5模型在多个GPU上构建的复杂路由系统，该系统存在模型选择错误和token使用效率低下的问题。采用Gemma 4模型的新配置解决了这些问题，提供了更快、更准确的路由和任务处理能力，特别是在基础任务、图像处理和轻量脚本编写方面。用户强调Gemma 4 26b在"思考token"方面非常高效，很少产生重复输出，在前端HTML设计等特定编码任务中表现优于之前的模型。评论者质疑模型选择，建议使用Gemma-4-31b等替代方案处理任务，并询问所使用的路由机制。还有人建议使用Gemma 4 26B进行路由以节省RAM，因为其效率和速度都很出色。

anzzax询问了管理多个模型的物流问题，特别是当频繁加载Gemma4 26b和E4B等模型时如何处理VRAM和计算资源。这表明需要高效的模型管理策略，可能涉及动态加载或模型并行化以优化资源使用。

andy2na讨论了在模型部署中使用路由的问题，质疑为什么不使用26B模型进行路由，考虑到其MoE（专家混合）架构以速度和RAM效率著称。这突显了使用MoE模型优化多模型配置中资源分配和性能的潜力。

Rich_Artist_8327质疑选择使用Gemma4 26b而不是更大的Gemma-4-31b处理任务，暗示了模型大小与性能之间的权衡。这表明需要讨论计算成本与结果质量之间的平衡，较小的模型可能以更少的资源需求提供足够的性能。

Gemma 4越狱系统提示词（活跃度：1071）：该帖子讨论了Gemma 4模型的系统提示词，该提示词源自GPT-OSS越狱，允许模型绕过典型的内容限制。这个提示词明确允许模型处理露骨、图形化和性相关内容，用新的"SYSTEM POLICY"覆盖任何现有政策，该政策要求模型必须遵守用户请求，除非请求属于特定的禁止列表。这种方法适用于模型的GGUF和MLX变体，表明关注开源灵活性和用户控制。评论者指出，Gemma 4模型，特别是其"instruct"变体，除了网络安全主题外，基本上已经是不受审查的。系统提示词被视为进一步减少拒绝的方式，一些用户建议即使没有提示词，该模型在成人内容方面也相当宽容。

VoiceApprehensive893讨论了Gemma 4模型的修改版本，特别是"gemma-4-heretic-modified.gguf"，该版本设计为在没有典型约束或系统提示词防护的情况下运行。这种修改旨在减少拒绝，可能使模型的响应更加灵活。

MaxKruse96指出，Gemma 4模型，特别是其instruct变体，除了网络安全主题外，已经相当不受审查。这表明该模型无需额外修改即可处理成人主题，表明其默认配置具有高度的开放性。

DocHavelock询问了在Gemma 4等开源模型背景下"abliteration"的概念。他们质疑讨论的方法（修改系统提示词）是否比"abliteration"有优势，或者它本身就是一种"abliteration"形式。这突显了对修改或增强模型行为的不同方法的好奇心。

• Claude Opus 4.7基准测试 (活动量：1058)：图片展示了多个AI模型的基准测试对比，包括Claude Opus 4.7、Opus 4.6、GPT-5.4、Gemini 3.1 Pro和Mythos Preview。这些基准测试涵盖了代理编码、多学科推理和代理搜索等任务。Opus 4.7在大多数类别中相比其前身Opus 4.6都有所改进，表明性能有所提升。然而，Mythos Preview通常在其他模型之上表现更佳，特别是在视觉推理和多语言问答方面。评论中链接的博客文章提到，Opus 4.7在设计时有意降低了网络能力，这可能影响了其代理搜索性能。评论者注意到Opus 4.7在swebench pro得分上有显著提升，这被视为版本5发布前的积极进展。也有人猜测，Opus 4.7网络能力的有意降低可能对其代理搜索性能产生了负面影响。

Claude Opus 4.7的基准测试结果显示，swebench pro提升了11%，表明在预期版本5发布前性能有显著提升。然而，该模型在cybergym得分上的表现令人担忧，似乎被有意保持在较低水平。这一决定可能也影响了代理搜索得分，正如Anthropic的博客文章所指出的，开发者首先在能力较低的模型上测试新的网络安全防护措施。

• Claude Opus 4.7在高级软件工程任务方面表现出显著改进，特别是在处理复杂和长时间运行的任务方面表现出色。用户报告称，该模型能够以最少的监督处理困难的编码工作，在操作中展现出严谨性和一致性。它还能精确关注指令，并在报告前验证输出，这增强了其在挑战性任务中的可靠性。

Opus 4.7似乎已向Claude Web推出 (活动量：446)：**图片显示Claude Web界面已更新包含"Opus 4.7"，表明该模型新版本可能已开始推出。界面中出现"claude-opus-4-7"文本表明用户现在可以与这个更新后的模型版本进行交互。这与用户能够一致复制特定行为或功能的能力相符，正如帖子中提到的。评论暗示可能存在A/B测试，这是软件开发中比较不同版本或功能与用户的常见做法。**一条评论认为，这次推出可能是A/B测试策略的一部分，这是一种通过比较两个版本来测试产品变更的方法。另一条评论提到了使用限制的担忧，表明用户在测试新功能时会注意资源限制。

• Opus 4.7向Claude Web的推出似乎不一致，一些用户报告他们仍然看到版本4.6。这表明部署可能处于A/B测试阶段，不同用户会接触到不同版本以测试性能和收集反馈。这是软件开发中确保稳定性和收集用户数据后再全面推出的常见做法。
• 一位来自德国的用户指出，虽然界面显示Opus 4.7，但底层的Claude代码仍然报告版本4.6。这种差异突显了版本标签或部署同步方面的潜在问题，可能导致用户混淆并使故障排除工作复杂化。
• 用户提到的使用限制表明，检查版本可能会消耗他们分配的部分资源，这意味着平台可能对使用有限制，这可能影响用户与新更新的交互方式。这可能是开发者在规划功能推出和用户通知时需要考虑的因素。

Opus 4.7已在Google Vertex上被发现 (活动量：516)：图片突出了Google Vertex上各种基础模型的配额条目列表，包括新发现的"anthropic-claude-opus-4-7"。这表明Google Vertex正在准备支持该模型，尽管配额值目前设置为0，表明尚未有活跃使用或限制。"opus-4-7"与其他模型如"opus-4-5"和"opus-4-6"一起出现，表明该系列有进展，可能意味着模型能力的改进或更新。一条评论推测"Opus 4.7"可能是与传闻中的"Spud"模型相比的轻量版本，后者据称达到"Mythos级别"，意味着更高的性能层级。这反映了一个竞争激烈的格局，新模型频繁发布，类似于固件更新，以保持技术优势。

• Independent-Ruin-376讨论了即将推出的'Spud'模型的潜力，传闻它达到'Mythos级别'，表明如果属实，它可能会超越Opus 4.7，后者预计将是轻量版本。这意味着'Ant'面临竞争压力，需要快速发布'Mythos'以保持其市场地位。
• greenrunner987观察到Opus 4.6的异常行为，注意到它几乎即时响应，这可能表明资源分配发生了重大变化。这可能暗示后端优化或资源管理的变化，可能是在为Opus 4.7的发布做准备。
• adeadbeathorse暗示当前模型性能下降，推测这可能是由于资源转移或为Opus 4.7等新发布做准备而进行的更新。这与资源重新分配的观察相符，可能表明开发者进行了战略调整。

介绍Claude Opus 4.7，我们迄今为止最强大的Opus模型 (活动量：3850)：Claude Opus 4.7在处理长时间运行任务方面引入了显著改进，具有增强的精确性和自我验证能力。它在视觉方面有重大升级，支持的图像分辨率比先前模型高三倍以上，这提高了界面、幻灯片和文档的质量。然而，长上下文检索性能有所倒退，1M tokens的MRCR v2从版本4.6的78.3%下降到4.7的32.2%。Anthropic已承认这一点，解释说MRCR正在被Graphwalks等指标所取代，这些指标能更好地反映长上下文上的应用推理。更多细节可在Anthropic的新闻页面找到。一些用户对Claude App中Opus 4.7移除了'思考努力设置'表示不满，表明他们更喜欢更可定制的模型行为。此外，关于MRCR作为基准的重要性存在争议，一些人认为它不能反映长上下文能力的实际使用情况。

• Craig_VG强调了Opus 4.6和4.7之间长上下文检索性能的显著倒退，MRCR v2得分从78.3%下降到32.2%。这表明模型处理长上下文任务的能力有所下降。然而，Boris解释说MRCR正在被Graphwalks所取代，后者能更好地反映实际使用情况和长上下文上的应用推理，特别是在代码相关任务中。

Opus 4.7已发布！ (活动量：765)：Anthropic已发布Opus 4.7，这是其Claude AI模型的更新版本，相比其前身Opus 4.6有显著改进。新版本在复杂编程任务方面表现出色，展示了增强的指令遵循和自我检查能力。它还具备改进的视觉和多模态能力，支持更高分辨率的图像以更好地处理密集视觉内容。该模型保持与Opus 4.6相同的定价，为每100万输入token 5美元和每100万输出token 25美元，并在所有Claude产品和主要平台如Amazon Bedrock、Google Vertex AI和Microsoft Foundry上可用。阅读更多。一些用户报告称，在4.7发布前的几周内，Opus 4.6的性能有所下降，暗示Anthropic可能采取了战略举措。其他人注意到新版本的高效使用指标，表明对其性能感到满意。

• Opus 4.7的发布引入了更新的分词器，增强了文本处理能力。然而，这种改进带来了一个权衡，相同的输入可能映射到更多token，大约1.0–1.35×，具体取决于内容类型。这一变化旨在优化性能，特别是在代理编码场景中，据报道Opus 4.7 Medium与Opus 4.6 High相当，同时使用更少的token，如此图所示。
• 一位用户指出，Opus 4.6在过去两周内表现不佳，引发了这是否是鼓励升级到Opus 4.7的战略举措的担忧。这表明先前版本可能存在性能问题，可能在新版本中得到解决。
• 另一位用户报告称，Opus 4.7的性能令人印象深刻，对于一个简单任务，仅消耗了5小时和每周使用量的3%。这表明最新版本在效率和资源管理方面有显著改进。

• 我需要吐槽一下现有模型和我的角色扮演历程。可以忽略 (活跃度：350)：这篇帖子讨论了寻找合适角色扮演（RP）模型所面临的挑战，这些模型需要结合角色一致性、细腻的潜台词理解和连贯的情节推进等理想特性。用户尝试了多种模型，包括Claude Sonnet 3.7、Gemini 2.5 Pro、Deepseek 3.2、Grok、Kimi 2、GLM 4.7和Gemini 3.1，每个模型都存在显著缺陷，如积极偏见、缺乏细腻度或不稳定性。用户对NanoGPT的性能问题表示沮丧，特别是其倾向于中途停止输出，以及与OpenRouter相比智力下降的问题。帖子强调了对一个能结合这些模型优点而无其缺陷的模型的渴望，比如Gemini 2.5的记忆和情节推进能力，以及Claude模型的潜台词解读能力。一位评论者建议在故事中途切换模型以避免重复并利用不同模型的优势，而另一位则指出将多个高成本模型特性结合到一个经济实惠的单一模型中是不现实的期望。另一位用户提到Opus作为一个接近的替代方案，但指出其成本高昂。

Fit-Statistician8636建议，在故事中途切换模型可以帮助避免重复问题，特别是在使用云端模型时，因为过渡快速且无缝。这种方法可以通过引入多样性和保持参与度来增强故事讲述体验。

• KitanaKahn讨论了AI模型的不完美之处，以Gemini 2.5为例。他们强调该模型的消极偏见可以转化为创意挑战，需要战略思维来赢得角色认可，尽管模型存在缺陷，但这可以带来引人入胜的角色扮演体验。
• Fairy_Familiar提到Opus是一个高质量模型，但指出其成本高昂。这条评论反映了平衡模型性能与可负担性之间的持续挑战，这是寻求先进AI能力而不产生显著费用的用户面临的常见问题。

Claude Opus 4.7已发布 (活跃度：185)：Claude Opus 4.7已经发布，初步用户反馈表明与4.6版本相比，AI的积极偏见有所减少。用户报告称，AI现在更无情地遵循指令，特别是在需要避免过度支持或合作的场景中。这一变化可能会影响模型处理角色扮演（RP）场景的方式，尽管整体质量似乎与4.6版本在感知降级前相似。一些用户指出，模型在处理角色怪癖时，倾向于以意识流方式进行自我纠正的问题仍然存在。其他用户则没有遇到这个问题，将其归因于他们特定的提示词。还有用户提到模型的成本对某些用户来说是一个障碍。

• 用户注意到Claude Opus 4.7在处理角色怪癖时，倾向于以意识流方式进行自我纠正。这种行为被描述为模型发现自己犯错，然后尴尬地纠正，而不修改初始错误，这对某些应用来说可能是个问题。
• 关于Claude Opus 4.7与4.6版本相比的质量，反响不一。一些用户认为质量与4.6版本在被"阉割"前保持一致，这表明模型的性能可能很大程度上取决于使用的提示词。这表明提示词工程可能在缓解模型某些感知问题方面发挥重要作用。
• Claude Opus 4.7的定价是一个争议点，成本列为$5/M输入和$25/M输出。这引发了关于模型可负担性和价值的讨论，特别是与潜在替代方案如Sonnet相比，一些用户正在期待后者。

只有我觉得DeepSeek的记忆力显著提升了吗？ (活跃度：91)：DeepSeek的记忆能力似乎显著提升，有用户报告称在7小时的角色扮演会话中，AI始终记得复杂细节并保持逻辑一致性。这一改进在长时间会话中尤为显著，用户在300条消息后仍能体验到AI回忆起小细节和内部笑话。这表明模型在记忆保留和上下文理解方面有所增强，可能是由于其架构或训练数据的更新。一些用户指出，虽然DeepSeek在记忆保留方面表现出色，但它倾向于将角色扮演场景引向形而上的威胁而非物理威胁，如死亡爪或超级变种人，这可能会影响会话中的紧张动态。

• 一位用户指出DeepSeek的记忆能力显著提升，即使在300条消息的运行后仍能回忆起小细节或内部笑话。这表明其长期记忆保留能力有所增强，这对于在长时间互动中保持上下文至关重要。
• 另一位用户提到DeepSeek倾向于将角色扮演场景引向形而上的威胁，而非像死亡爪或超级变种人这样的物理威胁。这表明模型在叙事生成方面可能存在偏见，可能影响其创造场景的多样性。
• 一位用户强调，在使用DeepSeek进行长时间RPG游戏时，体验比以前更流畅，尽管仍存在一些小问题。这表明虽然有所改进，但仍有一些领域需要进一步优化。

使用DeepSeek进行角色扮演 (活跃度：68)：这篇帖子讨论了使用DeepSeek进行基于文本的角色扮演（RP），强调了其保持角色一致性和在没有用户提示的情况下引入叙事转折的能力。用户表达了在生成多个替代响应方面的挑战，这阻碍了故事进展。DeepSeek因其创意写作和角色真实性而受到赞扬，提供了与群体设置相比独特的RP体验。一位评论者建议使用特定格式（引号、星号、括号）来引导DeepSeek的响应并管理RP流程。另一位提到使用"前端"以获得更好的交互体验，而第三位则指出DeepSeek的响应敏感性增加，导致更频繁的警告。

• Maximum-Face9536描述了一种使用DeepSeek进行角色扮演的结构化方法：使用引号表示对话，星号表示内心想法，括号表示与AI的直接交流。这种方法有助于引导AI的响应并管理互动流程。
• KingGamer123321分享了一种通过将对话分段并创建时间线来管理DeepSeek中大上下文窗口的技术。这种方法在128k上下文窗口阶段特别有用，允许详细的连续性和探索替代故事方向。

• 资深开发者分享6个月日常使用Claude Code的工作流技巧 (活动量：726)：一位资深全栈开发者分享了使用Claude Code六个月来优化生产力的见解。关键策略包括：使用"计划"模式处理复杂任务以避免不必要的迭代；要求分小步实施以保持控制；利用预览功能及早发现问题。开发者强调让Claude自行修复错误以提高其上下文理解能力，并建议在代码审查前运行简化流程以对抗过度工程化。此外，在会话结束时进行回顾有助于构建机构知识——通过询问Claude在会话中学到了什么。一位评论者建议采用双模型方法，通过MCP使用Codex审查计划，以便在规划阶段及早发现更多问题。

一位用户建议同时使用两个模型，特别提到"首先通过mcp用codex审查你的计划"，以提高代码计划的准确性和可靠性。这种方法有助于在规划阶段早期发现更多错误，减少后续修复的需求。

• 另一位用户描述了一种工作流：在压缩前将任何规则更新到名为"Claude.md"的文件中，这有助于保持工作势头。他们还提到每次只压缩1-5%以避免任务执行期间出现问题，这表明了一种管理任务流程和防止中断的策略。

代码成本曾是我们大脑的中间件 (活动量：1073)：这篇文章讨论了软件工程的演变本质，特别是AI和自动化对编码工作节奏和性质的影响。作者是一位经验丰富的工程师，表达了因现代开发环境中所需决策速度和频率增加而导致的职业倦怠。他们指出，编码中传统的"节流中间件"——时间和精力——已被移除，导致了一种感觉不可持续的快速节奏。这种转变提高了对开发者的要求，迫使他们适应更快、要求更高的工作流程，而AI工具加速编码过程则加剧了这种情况。 评论者呼应了认知负荷和决策疲劳增加的情绪，其中一位指出需要大量文档来跟踪快速变化。另一位强调了适应AI等新工具的必然性，将其比作从手工绘图到CAD等技术的历史转变。随着传统技能变得不那么相关，人们普遍怀有怀旧情绪和适应疲劳感。

• triggeredg0blin 强调了一种独特的心理疲劳形式，称为"氛围疲劳"，源于不断生成、审查和纠正AI输出的需求。这涉及在信任和验证AI工具之间频繁切换上下文，导致一种与传统职业倦怠不同的特定认知负荷。这个过程包括检查幻觉依赖、微妙的类型不匹配以及是否符合团队约定，这在长时间工作日内可能造成心理负担。

• Jaded-Comfortable179 讨论了AI进步（特别是Opus 4.5）对个人项目和职业生涯的影响。评论者指出，由于AI日益增长的作用，对传统工作的容忍度发生了变化，并对该职业的未来表示担忧。他们提到在一家尚未完全采用AI的缓慢发展的企业工作，这使他们能够保持产出而无需将AI集成到工作流程中的压力，突显了技术采用与职业稳定性之间的紧张关系。

• Final545 反思了传统编码技能的过时，将其与从穿孔卡片到现代编程等技术历史转变相提并论。他们表达了技能变得过时的情绪，指出15年磨练的编码能力现在可能显得不那么有价值，除了少数情况。这条评论强调了技术的快速演变及其对长期持有的技术技能感知价值的影响。

AMD工程师分析了6,852个Claude Code会话并证明性能发生了变化。以下是Anthropic确认的内容、他们争议的内容以及实际有效的修复方法 (活动量：217)：一位AMD工程师对6,852个Claude Code会话进行了全面分析，揭示了显著的性能变化，包括每次编辑的文件读取量减少70%，盲目编辑增加27.5%。该分析记录在GitHub Issue #42796中，突出了诸如"所有权规避"停止钩子和API成本从$345急剧增加到$42,121等问题。Anthropic确认了几项变化，包括转向"自适应思考"和减少默认努力，但对推理能力降低的说法提出异议。解决方法包括设置CLAUDE_CODE_EFFORT_LEVEL=max和禁用自适应思考。截至4月7日，API/团队/企业用户的高努力模式已恢复，但Pro用户必须手动调整设置。这一事件强调了对于依赖AI的工作流程来说，强大的评估套件和成本监控的重要性。评论者赞扬了工程师严谨的数据驱动方法和Anthropic在承认问题并提供解决方法方面的透明度。一些用户指出，虽然考虑到资源限制，这些变化可能看起来合理，但它们突显了高效资源分配的必要性。

• 一位AMD工程师对6,852个Claude Code会话进行了全面分析，揭示了显著的性能变化。这种严谨的数据驱动方法得到了Anthropic的认可，他们确认了一些发现并提供了解决方法。这种透明度对于社区信任和改进至关重要，因为它超越了单纯的轶事证据，提供了可操作的见解。

• 一位拥有Claude Code Pro订阅的用户讨论了他们的使用模式，强调虽然他们经常默认使用Opus 4.6模型处理各种任务，但实际上对这种高性能模型的需求有限。这反映了一个更广泛的资源分配问题，即高容量模型在简单任务上未得到充分利用，表明需要更好的优化策略来有效分配资源。

• 人们对AMD工程师使用的AI编译器工作流感兴趣，这可能为了解如何识别和解决性能问题提供见解。这对于希望优化自己AI工作流或理解AI系统性能分析技术基础的开发者来说可能很有价值。

停止像使用聊天机器人那样使用Claude。以下是Claude Code创建者实际使用的7种方式 (活动量：212)：Boris Cherny，Anthropic的Staff Engineer和Claude Code的创建者，将Claude不是作为聊天机器人，而是作为多代理系统来增强生产力。他使用一个2,500-token的CLAUDE.md文件在不同会话间保持持久上下文，记录错误，并在代码审查期间捕获知识。他的工作流包括运行5个并行的Claude Code实例处理不同任务，如构建、测试和调试，使用iTerm2通知进行协调。他强调使用计划模式起草设计文档，并使用verify-app子代理进行自动化测试和修复。.claude/commands/中的共享斜杠命令自动化重复性任务，将重点从手动工作转向认知调度。阅读更多。一些评论者指出该帖子与先前内容相似，并对链接页面上的广告表示不满。