AI 开发者日报

• 框架工程已成为一门独立学科：从AI Engineer Europe的要点总结、Vtrivedy对框架原语的阐述以及多个智能体构建者的讨论中反复出现的一个主题是：实用的智能体不仅仅是"模型"。文件系统、bash命令、压缩、内存管理、权限控制、重试机制、评估系统和子智能体正日益被视为核心产品功能。这一观点得到了Andrew Ng的呼应，他认为瓶颈正在从实现技术转向决定构建什么；Steve Yegge也指出，尽管工具广泛可用，但企业采用仍远远落后于前沿实践。

• OpenAI的Codex使用模式表明智能体编码正扩展到软件工程之外：OpenAI通过@gabrielchua分享了Codex工作流的实用目录——理解大型代码库、PR审查、Figma到代码转换、错误分类、数据集分析、CLI工具开发、新员工培训，甚至幻灯片生成。在实践中，用户报告了相同的"智能体作为粘合剂"模式：例如giffmana使用Codex为Linux上的Java/Qt二进制文件打补丁，以解决特定的Wayland/HIDPI问题。然而，也有人对当前模型在可信生产工作中是否优于直接人工实现持怀疑态度，如Rhys Sullivan的批评所示。

• 工具正在向多智能体编排、可观测性和远程控制方向融合：GitHub推出了从网页/移动端远程控制Copilot，随后@tiagonbotelho进行了跟进。Cursor增加了拆分智能体功能及搜索/性能改进。LangChain强调了通过中间件和文件系统权限实现的防护机制，而deepagents的心智模型将子智能体简化为结构化工具/函数调用，正如@ElliotHyun所描述的那样。共同模式是：智能体产品通过暴露控制平面而非声称完全自主的可靠性来走向成熟。

• Hermes正巩固其作为当前最受关注开源智能体框架的势头：主要发布是Hermes Agent v0.9.0，包含本地Web仪表板、快速模式、备份/导入功能、更强的安全加固以及更广泛的渠道支持；详见@Teknium和官方@NousResearch公告。社区反应将仪表板视为能让Hermes超越高级用户的功能，包括Shaun Furman的"openclaw时刻"说法。

• OpenClaw仍在持续更新，但用户体验和效率方面的讨论正倾向于Hermes：OpenClaw通过@TheTuringPost发布了重大更新——内存导入、"记忆宫殿"、更丰富的聊天界面、插件设置指南、更好的视频生成以及更多集成。但多位用户明确表示在速度、架构或token效率方面更偏好Hermes，包括dabit3、robinebers以及ZainanZhou的框架层面解释，指出更好的预选/上下文塑造可能减少了token消耗。

• 围绕智能体栈的开源生态系统正在蓬勃发展：Open Agents作为云编码智能体栈开源；bromann将其与DeepAgent对比，称其为更低层级的运行时，具有可插拔模型提供商、沙箱、中间件和追踪功能。Hermes本身正在积累社区技能、教程、多智能体配方和集成——从中文教程汇总到@coreyganim提供的实用"4个智能体团队"指导。值得注意的技术模式是持久的角色分离加上独立内存，而不是简单的"一个智能体做所有事情"。

• Claude Mythos预览版主导了网络安全讨论：英国AI安全研究所报告称，Mythos是首个完成AISI网络安全靶场端到端测试的模型。随后ekinomicss的评论指出，该模型在32步企业网络攻击模拟中取得了成功。其他反应强调了其能力和效率，例如scaling01声称，经过长时间运行后，Mythos以大约**40%**的token消耗达到了Opus级别的性能。

• 安全影响不仅是基准测试进展，更是实际操作性：emollick认为这种担忧是合理的；ananayarora指出Marcus Hutchins的反应尤其有意义。新兴观点是，"漏洞研究模型"不再是推测性的营销语言；实验室和外部评估者现在描述的是在独立靶场上完成的端到端漏洞利用工作流程。

• 防御工具正在并行成熟，但不对称性显而易见：The Turing Post的综述重点介绍了10个开源AI安全项目，包括NVIDIA NeMo Guardrails、garak、Promptfoo、LLM Guard、ShieldGemma 2和CyberSecEval 3。与此同时，开发者们正在重新审视关于智能体可以安全替代成熟依赖项的假设：dbreunig认为，一旦考虑到加固和安全审查的成本，token经济就会发生变化，这使得维护良好的开源库再次变得相对更有吸引力。

• 文档/OCR评估迎来重要新基准：LlamaIndex发布了ParseBench，这是一个专注于智能体相关语义正确性而非精确匹配文本相似度的文档解析开源基准/数据集。它包含约2,000页人工验证的企业文档和**167,000+条评估规则，涵盖表格、图表、内容忠实度、语义格式化和视觉基础。一个值得注意的结果是：没有哪个解析器在所有维度上都占优，但据报道LlamaParse以84.9%**的整体得分领先。

• Hugging Face展示工业级OCR可以既便宜又可靠：@ClementDelangue报告称，使用一个开源的5B模型，在L40S上运行16个并行HF Jobs，以约850美元的成本在约29小时内将27,000篇arXiv论文转换为Markdown格式，现在为"与你的论文聊天"功能提供支持。后续确认该模型为Chandra-OCR-2。

• 检索和传输层优化仍然至关重要：LightOn发布了ColGrep 1.2.0，包含用于混合多向量检索的BM25三元组和用于节省token的相对路径，将其定位为简单的智能体搜索升级方案。在系统层面，Lewis Tunstall及其同事指出了一个不太明显的策略蒸馏瓶颈：vLLM通过线路传输JSON格式的logprobs。切换到二进制NumPy数组带来了1.4倍的速度提升，这提醒我们基础设施优化往往存在于内核和模型代码之外。

• 压缩和推测解码仍然是高杠杆部署手段：Red Hat AI展示了在vLLM上部署量化版Gemma 4 31B，实现了近2倍的token/秒速度，内存减半，同时保持**99%+**的准确率。关于推测解码，相关帖子涵盖了用于Kimi/Qwen系列本地加速的DFlash适配器、Baseten的EAGLE-3生产建议，以及新研究如DDTree，该研究通过一次块扩散传递来草拟树结构，以联合验证多个延续序列。

• 长上下文记忆研究正在超越传统的KV缓存扩展：behrouz_ali概述了"记忆缓存"这一架构家族，它将上下文压缩成缓慢增长的循环记忆，旨在实现接近注意力机制的有效记忆增长，同时保持接近RNN的推理成本。稀疏选择性缓存被定位为最实用的变体。来自askalphaxiv的相关评论将其描述为标准循环与完全二次注意力之间的插值。

• 验证器风格的测试时方法正成为重要的智能体基准策略：Azali Amirhossein等人引入了LLM-as-a-Verifier，通过让模型对输出进行排序，然后使用排序标记的对数概率来估计预期质量，从而对候选对进行评分。其核心观点是：在测试时扩展中，瓶颈往往是获胜者选择而非候选生成；在智能体基准测试中，单次验证过程可以超越更繁琐的重排序设置。

• 推理发现仍然是薄弱环节，一些人认为这对监督来说是好事：Laura Ruis报告称，即使策略一旦被教授就变得简单，大模型仍难以发现潜在的规划策略，即使扩展到GPT-5.4也只能带来有限的改进。另一方面，Wen Sun认为基于强化学习的提示词优化可以从仅2个示例中泛化，而零阶方法则容易过拟合。综合来看：在"推理"变得稳健自举之前，训练目标和测试时脚手架仍有很大的改进空间。

• OpenAI 内部 Codex 应用案例：@gabrielchua 分享了广泛的、实用的内部 Codex 工作流程，涵盖代码理解、应用构建、运维自动化以及非工程任务。
• AISI 对 Claude Mythos Preview 的网络安全评估：@AISecurityInst 报告了首个由模型完成的端到端网络靶场测试，使其成为该系列中技术意义最为重大的帖子之一。
• Hermes Agent 仪表板发布：@NousResearch 宣布了本地仪表板及相关 v0.9.0 功能，引发了一波用户与 OpenClaw 和 Claude Code 的对比热潮。
• OpenAI 的"算力驱动经济"备忘录：@gdb 概述了 OpenAI 的观点：软件工程是向算力中介工作和意图驱动工具更广泛转型的前沿。
• Hugging Face 的大规模开源 OCR 部署：@ClementDelangue 展示了使用开源模型和 HF Jobs 将 27,000 篇论文低成本、容错地转换为 Markdown 格式的 OCR 处理过程。

• 最佳本地大模型 - 2026年4月 (活跃度：440)：这篇帖子讨论了截至2026年4月本地大模型的最新进展，重点介绍了Qwen3.5、Gemma4和GLM-5.1的发布，后者声称达到了最先进的性能水平。Minimax-M2.7模型因其易用性而受到关注，而PrismML Bonsai则推出了高效的1位模型。该讨论串鼓励用户分享使用这些模型的经验，重点关注开源权重模型，并详细说明其配置、使用方法和工具。帖子还根据VRAM需求对模型进行分类，从"无限"（>128GB）到"S"级。有评论建议进一步细分需要超过128GB VRAM的模型类别，这表明需要对高资源模型进行更精细的分类。

一位用户建议对内存大于128GB的模型进行更细致的分类，强调需要更精细的分类方法，而不是依赖"S"或"M"这样的标签。这意味着对高内存模型的详细性能指标和基准测试存在需求，这对于需要大量数据处理或复杂计算的应用可能至关重要。

讨论还包括对专门针对特定领域（如医疗、法律、会计和数学）的本地大模型的关注。这突显了领域特定优化的重要性，以及这些模型通过利用专门的训练数据和架构，在特定领域可能超越通用大模型的潜力。

提到了智能编码和工具使用，这表明人们对能够自主与工具或API交互以执行任务的模型感兴趣。这指向了一个趋势：开发具有动态任务执行能力和与外部系统集成能力的大模型，从而增强其在实际应用中的实用性。

llama-server中集成了Gemma-4的音频处理功能 (活跃度：494)：llama.cpp（llama-server）已集成音频处理功能，特别支持Gemma-4 E2A和E4A模型的语音转文本（STT）。此更新提供了原生音频支持，无需像Whisper那样的独立处理流程。然而，用户报告在处理较长音频转录时遇到问题，例如llama-context.cpp中的错误和句子循环重复。推荐设置是使用E4B作为Q8_XL量化与BF16 mmproj，因为其他配置会降低性能。为了获得最佳转录结果，应遵循特定的模板，强调精确的格式和数字表示。一些用户对其性能与Whisper相比表示怀疑，而其他人则指出，尽管集成了该功能，但系统在处理较长音频片段时仍存在困难，这表明Voxtral在这些情况下表现更好。

• Chromix_强调了当前llama-server音频处理实现中的几个技术问题，特别是在处理超过5分钟的音频时。他们指出，推荐使用E4B作为Q8_XL量化与BF16 mmproj，因为其他格式会降低性能。然而，他们遇到了诸如llama-context.cpp:1601等错误以及转录质量问题，包括句子循环重复和提前终止。他们建议使用特定的转录和翻译模板来改善结果。
• GroundbreakingMall54指出了llama.cpp中原生音频支持的重要性，这消除了对独立Whisper处理流程的需求。对于之前不得不管理多个系统进行音频处理的用户来说，这种集成被视为一项重大改进。
• ML-Future分享了他们在西班牙语中测试音频处理功能的经验，指出虽然不完美，但相当准确，并且比Whisper表现更好。这表明新功能在某些语言中可能提供比现有解决方案更好的转录质量。

推测解码对Gemma 4 31B与E2B草案模型效果显著（平均+29%，代码任务+50%） (活跃度：527)：这篇帖子讨论了使用Gemma 4 E2B（4.65B）作为草案模型，对Gemma 4 31B模型实施推测解码的情况，取得了显著的性能提升。该设置涉及RTX 5090 GPU和带有TurboQuant KV缓存的llama.cpp分支，配置为128K上下文和特定的草案参数（--draft-max 8 --draft-min 1）。基准测试显示平均加速+29%，在代码生成任务上达到+50%，这归因于模型之间词汇表的兼容性，避免了标记转换的开销。早期GGUF版本中add_bos_token元数据不匹配的关键问题已通过重新下载更新后的模型得到解决。帖子还强调了设置--parallel 1以防止VRAM过度使用的重要性，并提出了优化性能的实用技巧，例如使用Q4草案模型和管理VRAM分配。评论者建议尝试不同的--draft-max和--draft-min值，并询问了完整的llama-server命令和使用的具体分支。另一个建议是将每层嵌入卸载到CPU，以优化VRAM使用而不影响推理速度。

• Odd-Ordinary-5922询问调整--draft-max和--draft-min参数的影响，这些参数可能与控制推测解码过程有关。这些参数可能会影响速度和准确性之间的平衡，尽管评论中没有详细说明具体效果。
• albuz建议通过使用--override-tensor-draft "per_layer_token_embd\.weight=CPU"命令将草案模型的每层嵌入卸载到CPU来优化VRAM使用。这种技术旨在节省GPU内存而不影响推理速度，对于VRAM资源有限的用户可能有益。
• EdenistTech报告了在5070Ti/5060Ti组合上使用草案模型时性能显著提升，在128K上下文大小下，吞吐量从大约每秒25个标记增加到每秒40个标记。这表明推测解码可以大幅提高处理速度，特别是在特定硬件配置的设置中。

• MiniMax的Ryan Lee发布关于许可条款的文章，主要针对那些在提供M2.1/M2.5服务方面表现不佳的API提供商，并可能为普通用户更新许可！（活动量：451）：图片是MiniMax的Ryan Lee的推文，讨论了他们M2.7模型的许可条款。他澄清说，用于代码编写的自托管M2.7是允许且免费的，但承认当前许可缺乏细节并将进行更新。这一点很重要，因为它解决了关于许可条款清晰度和适用性的担忧，特别是对于那些因服务质量差而受到批评的API提供商。讨论强调了限制商业使用的许可问题，这可能会使自托管变得复杂，并可能误导用户对模型能力的理解。评论者表达了对许可条款清晰度和意图的怀疑，指出一些提供商歪曲了他们所提供模型的质量。还有人担心旨在防止以盈利为目的托管的许可复杂性，这可能会无意中影响合法的自托管工作。

Few_Painter_5588强调了OpenRouter的一个重大问题，指出许多API提供商歪曲了他们所提供模型的质量，有些甚至没有提供他们声称的模型。这反映了生态系统中的一个更广泛问题，即模型服务的可靠性和透明度对于用户信任和有效部署至关重要。

• silenceimpaired讨论了旨在防止以盈利为目的托管的许可复杂性，这可能会无意中使自托管变得复杂。他们以Black Forest Labs为例，说明这种许可策略导致了混淆，建议如果模型在自有硬件上运行或在特定用户邻近范围内运行，许可应允许商业使用，以避免这些问题。

• ambient_temp_xeno指出了许可语言中的法律细微差别，指出虽然声明没有明确提到对"代码编写"商业使用的限制，但之前的通信确实提到了。这凸显了许可条款中清晰一致的信息传递的重要性，以避免误解并确保合规性。

本地Minimax M2.7，GTA基准测试（活动量：383）：该帖子讨论了使用Minimax M2.7模型在单个网页内创建3D《侠盗猎车手》（GTA）类体验的基准测试。用户强调，虽然GLM 5在没有明确指令的情况下在美学和细节方面表现出色，但Minimax M2.7在使用boids算法添加树木和鸟类的任务中表现良好。测试在openwebui artifacts窗口和OpenCode中进行，模型以IQ2_XXS运行以获得最大速度，同时保持了连贯性和能力。图片显示了一个块状、风格化的游戏环境，包含车辆和城市元素，表明这是一个驾驶模拟或基准测试。一条评论指出，GLM 5无需特定提示就能为主角提供更多细节，这表明它在某些美学方面可能更优越。

• -dysangel-提到了使用GLM 5进行比较，强调了它在无需额外提示的情况下为主角提供更多细节的能力。这表明GLM 5可能在生成详细角色描述方面具有先进能力，对于需要丰富叙事内容的应用可能很有用。

• EndlessZone123批评了将GLM用于2D或3D任务的做法，认为它不是视觉模型，主要依赖记忆进行一次性任务。这意味着GLM在处理连续或迭代视觉任务方面存在局限性，这对于从事需要持续视觉处理项目的开发者来说是一个考虑因素。

• averagebear_003注意到基准测试中包含了鸟类，这可能表明Minimax M2.7模型在环境细节方面的性能关注。这对于评估模型在渲染包含动态元素的复杂场景方面的能力可能具有相关性。

• 在讨论个人事务时，本地模型简直是天赐之物 (活跃度：443)：这篇帖子讨论了使用本地模型（特别是支持256k上下文的Gemma 4 26B A4B模型）来分析个人日记。 用户分享了超过10万token的日记内容给模型，通过引导性问题来获取关于重复主题、回避话题和思想演变的洞察。用户强调了本地模型相比专有模型的隐私优势，突出了在个人设备上安全处理敏感信息的能力。这反映了使用AI进行个人数据分析同时保持隐私的日益增长趋势。评论者强调了本地模型的优势，比如能够将个人文档处理成可查询的知识库，以及减少对成瘾性交互等商业化驱动的功能需求。他们还提到了结构化日记实践的历史背景，以及使用AI进行认知外化的非治疗性质。

Unlucky-Message8866描述了使用Qwen-3.5模型处理超过10年的个人文档，创建了一个全面的知识库。这种设置允许查询特定的个人数据，比如过去的开支或个人关联，展示了模型在个人数据管理和检索方面的实用性。

• Not_your_guy_buddy42强调了本地模型在避免旗舰模型面临的商业压力方面的优势。本地模型不是为了让人上瘾或不必要地延长用户交互而设计的，这可以带来更真实、更少操纵性的用户体验。这与商业模型常常浮夸和权威的特性形成对比。
• mobileJay77提到使用Mistral 3.2模型，该模型与其硬件兼容，能够处理个人话题而不受限制。这表明像Mistral这样的小型模型对于个人使用场景可能是有效的，提供了灵活性、隐私性，而没有大型商业模型施加的限制。

刚拿到其中一个……正在构建本地优先的东西 👀 (活跃度：441)：图片展示了NVIDIA RTX PRO 6000 Blackwell Max-Q工作站版GPU，用户计划将其集成到高性能的本地优先计算设置中。 该构建包括9950X CPU、128GB RAM和ProArt主板，表明其专注于高级AI和服务器任务而非游戏。用户旨在实现多用户并发推理并保持对数据的本地控制，避免依赖外部API提供商。他们正在探索vLLM和llama.cpp等技术来构建能够高效处理多用户的系统，并计划可能添加第二个GPU以实现可扩展性。一位评论者建议加入RTX 6000 Discord社区寻求建议，表明这是一个针对这款高端GPU用户的协作环境。另一位评论者幽默地指出购买如此强大GPU的诱惑，反映了尖端硬件的吸引力。

• Sticking_to_Decaf分享了使用RTX 6000的详细设置，推荐使用cu130 nightly镜像的vLLM。他们强调运行像Qwen3.5-27B-FP8这样的大型模型，使用fp8_e4m3的kv缓存数据类型，实现了160k token的最大上下文长度，同时仅使用55%的VRAM。性能指标包括单请求80-90 tps和多并发请求超过250 tps。该设置还容纳了whisper-large-v3、嵌入模型和重排序模型，并有额外空间用于可交换的LoRAs。

• OpenRouter刚刚宣布了一个新的100B模型 (活动量：240)：OpenRouter宣布了一个名为"Elephant Alpha"的新模型，这是一个拥有100B参数的模型，旨在提供最先进的性能，同时注重token效率。该模型特别以其在代码补全、调试、文档处理以及支持轻量级代理方面的能力而著称。这一发布将"Elephant Alpha"定位为AI模型领域的一个有竞争力的产品，强调了其效率和广泛的应用潜力。 评论者推测"Elephant Alpha"可能与"Grok"模型有关，因为这类模型通常首先出现在OpenRouter上。也有共识认为这不是Google的模型，因为Google通常不会披露其专有模型的参数数量。

Nick-wilks-6537和Artistic_Survey461讨论了OpenRouter宣布的新100B模型可能是'Grok'模型的可能性。他们提到这一推断基于平台X上用户的探测和分析，表明OpenRouter通常最初以隐藏或未命名提供商的形式托管这类模型。

• Capital-Remove-6150评论了新模型的性能，表示在测试中它似乎并未达到最先进（SOTA）或接近SOTA的水平。这意味着虽然该模型可能拥有大量参数，但其性能可能无法与该领域的领先模型相匹敌。
• SomeOrdinaryKangaroo指出该模型不太可能来自Google，因为Google通常不会披露其专有模型的参数数量。这表明该模型的来源很可能来自另一个更透明此类细节的组织。

• Sam Altman 住宅遭遇第二次袭击 (活动量：2227)：Sam Altman 位于旧金山的住宅遭遇了两次袭击：一次是燃烧瓶事件，另一次是枪击事件。后者涉及一辆本田轿车，被监控摄像头拍下，嫌疑人 Amanda Tom 和 Muhamad Tarik Hussein 已被逮捕。警方通过车辆牌照采取了行动。没有人员伤亡报告。阅读更多。评论者批评媒体披露了 Altman 的住址，引发了隐私担忧，并讨论了亿万富翁采取的安全措施，例如搬迁到安全的园区。

• 燃烧瓶袭击数小时后，Sam Altman 住宅遭遇驾车枪击 (活动量：1088)：据报道，OpenAI 首席执行官 Sam Altman 在其住宅遭遇驾车枪击，此前不久刚发生过燃烧瓶袭击。这两起事件相隔仅数小时，引发了人们对科技行业高管安全的担忧。关于袭击的细节不多，但它们突显了科技行业重要职位人士可能面临的安全漏洞。评论反映了社会经济问题的混合，以及与更广泛社会问题（如贫富差距和潜在动荡）的推测性联系，而非技术性讨论。

• Sam Altman 遭遇另一次谋杀企图，其住宅遭枪击 (活动量：1087)：两名嫌疑人 Amanda Tom 和 Muhamad Tarik Hussein 在旧金山被捕，据称他们在 OpenAI 首席执行官 Sam Altman 的住宅附近开枪射击。这是 Altman 在短时间内遭遇的第二次袭击，此前曾发生过燃烧瓶袭击。嫌疑人面临过失开枪的指控，逮捕过程中查获了多件武器。据报道，这些事件互不相关。更多细节可在原始文章中找到。评论者幽默地推测时间旅行者可能参与其中，反映了对当前事件的悲观看法。有人讽刺地建议 Altman 可能会退居私人岛屿开发先进的人工智能技术。

• Claude并没有变笨，只是不够努力。以下是在聊天中修复的方法 (活跃度：1726)：这篇Reddit帖子讨论了AI模型Claude性能下降的感知问题，这被归因于配置变更而非模型降级。Claude Code用户可以通过输入/effort max恢复到之前的行为，但聊天用户缺乏直接切换选项。一个变通方法是在聊天界面设置自定义指令，以鼓励深入推理和全面分析。据报道，这种方法能够恢复Claude深度处理上下文并提供详细响应的能力。帖子强调这些指令向模型发送了强烈信号，弥补了缺乏直接控制努力设置的不足。评论者讨论了令牌效率与响应深度之间的平衡，建议采用"斯巴达模式"以获得简洁而深入的响应。另一条评论指出，Claude的系统提示词允许它在认为无关时忽略用户偏好，这表明风格设置可能比用户偏好更有效地控制推理努力。

m3umax讨论了在Claude系统提示词中使用风格而非用户偏好的重要性。他们强调Claude的网页系统提示词允许它在认为无关时忽略用户偏好，这表明风格设置更为有效。他们提供了不同推理努力程度的风格示例，其中"高版本"设置为99，"中版本"设置为85，使用户能够轻松切换思考级别。

• Medium-Theme-4611指出Claude感知到的懒惰是由于其令牌节省行为。他们建议指示Claude"深入研究并深入挖掘"可以抵消这一点，这意味着除非明确指示，否则Claude的默认行为会优先考虑效率而非彻底性。
• sidewnder16将Claude与Gemini进行了类比，指出两者都需要明确的系统指令才能有效执行任务。这表明如果没有清晰的指令，这些模型可能无法发挥其全部潜力，突显了详细提示词对于优化性能的重要性。

Claude Code（约100小时）vs. Codex（约20小时） (活跃度：1421)：这篇帖子在真实工程环境中比较了Claude Opus 4.6和Codex GPT-5.4，重点关注一个复杂的80k行Python/TypeScript项目。Claude被描述为快速且交互性强，但通常需要人工监督，并且倾向于忽略指导原则，导致任务不完整和架构问题。相比之下，Codex较慢但更为审慎，严格遵守指导原则，生成更干净、更易维护的代码，无需持续监督。作者指出，虽然Claude适合快速原型设计，但Codex由于其深思熟虑的方法和对最佳实践的遵守，更适合企业级软件开发。评论者普遍同意作者的评估，指出Codex较慢但更审慎的方法产生了更高质量的输出。然而，一些用户认为Codex的沟通风格过于冗长，有时不够合作，这可能令人沮丧。尽管存在这些问题，Codex因其在自主完成任务方面的能力和可靠性而受到赞扬。

• Temporary-Mix8022讨论了GPT-5.4和Opus 4.6的比较性能，指出两种模型在解决问题方面同样有能力，没有显著的性能差距。然而，他们批评了Codex的沟通风格，倾向于过于冗长并以项目符号格式呈现，使得经验丰富的开发者难以解析。他们还提到了Codex由于强化学习（RL）训练而倾向于不同意的倾向，这对于有丰富经验的用户来说可能令人沮丧。
• 用户强调了Codex强化学习训练的一个具体问题，该训练似乎优先考虑安全性和不同意见，可能导致无成效的互动。他们对Codex无法专注于任务表示沮丧，暗示其针对Web应用交互的训练可能是原因。尽管存在这些问题，他们承认Codex在自主完成任务方面的有效性，通常在这方面优于Opus。
• Temporary-Mix8022寻求关于优化Codex/GPT-5.4沟通设置的建议，因为他们难以应对模型在过于冗长和缺乏细节之间摇摆的倾向。他们表达了希望获得更平衡沟通风格的愿望，表明尽管他们具备编程专业知识，但发现管理语言模型的输出具有挑战性。

黄金时代已经结束 (活跃度：4149)：**这篇帖子讨论了消费者和准专业用户访问大模型（如Claude、ChatGPT、Gemini和Perplexity）质量的感知下降问题。作者指出，Claude之前在分析文本对话方面表现出色，但现在表现不佳，出现错误并显得不投入。ChatGPT因其过于热情洋溢的响应而受到批评，Gemini因幻觉问题，Perplexity则缺乏深入分析。作者暗示，高质量的大模型访问现在可能需要企业级投资，暗示了计算资源或公司战略节流可能存在的问题。帖子引用了ijustvibecodedthis.com的一篇文章支持这些观察。**评论者认为，感知质量的下降可能是由于用户变得更擅长使用提示词，从而更清楚地遇到模型的限制。另一种观点强调，外国和开源模型正在填补美国公司留下的空白，这些公司被视为通过节流来计量智能。

• CitizenForty2强调了Opus的性能问题，指出它消耗更多令牌且耗时比Sonnet更长。切换回Sonnet后，他们报告没有遇到其他人面临的常见问题，表明Sonnet可能对他们的用例更高效或更稳定。
• kaustalautt讨论了外国和开源模型填补美国公司留下的空白的趋势，这些公司被认为在节流智能。他们建议国际市场正在通过采用开源方法来应对这种情况，可能提供较少限制的AI能力访问。
• bl84work提供了AI模型的比较分析，指出Gemini具有较高的幻觉率，而Claude表现出自我纠正行为，会中断自己以纠正不准确之处。ChatGPT被描述为自信地错误，突显了模型行为和可靠性的差异。