Doubao 5.1多模态识别历史人物翻车：Qwen与DeepSeek准确无误
知乎用户测试发现豆包5.1将常凯申与少帅的合影误识别为轿夫，且4人误判为5人，引发社区群嘲。
今日概览
知乎用户测试发现豆包5.1将常凯申与少帅的合影误识别为轿夫，且4人误判为5人；同期千问识别正确，深Dream拒绝处理，评论区建议绕行豆包多模态任务。
Qwen 3.8中等规模模型即将在下周发布；Ornith 1.5系列声称在多项基准上超越Q3.8 27B；Unsloth Dynamic v3 GGUF采用1-bit量化技术，在8GB RAM上保留77%精度。
用户分享了将AI用于个性化图书选购和地理聚类旅行规划的创新工作流，通过上传偏好文件实现精准分析，节省大量搜索和规划时间。
Claude Code 用户报告该工具经常高估任务耗时，声称项目需要数天或数周才能完成，但实际仅用 20-30 分钟就完成了。有人将其称为"有趣的 Bug"，社区也从训练数据、定价策略和 GPU 执行速度等角度进行了解释。
中美AI用户在订阅成本与功能价值的权衡中形成分化格局：普通用户认为DeepSeek免费版已完全够用，而追求极致科研、高并发和多模态能力的1%用户则认为GPT Pro的优势"完全不在一个层面"。
智谱 GLM-5.3 在 Artificial Analysis 基准测试中追平 Kimi K3，通过一个月后训练和强化学习实现竞争性表现，展示了 700B 参数规模对代码任务的可能充足性，以及更短思考时间背后的高效训练路径。
用户报告 Claude Opus 5.0 在表达简单概念时呈现出夸张的文风，而研究显示不同 LLM 家族在策略行为上存在持久差异。
模型体验追踪
豆包5.1多模态翻车：历史人物合影识别错误遭社区群嘲
事件经过
- 豆包5.1将一张常凯申与少帅的合影误识别为轿夫场景，且图中实际4人被误判为5人。
- 同张图片交由千问处理时，正确识别了图中人物。
- DeepSeek V4 Flash则直接拒绝处理该图像。
社区反馈
- 知乎帖子对同一图片下各模型表现进行比较，获得44总互动量，峰值评分36。
- 帖子作者明确建议用户避免使用豆包处理多模态任务，并写道："现在你知道该用谁了吧"。
- 有评论调侃DeepSeek"装作不是多模态"，但"一看到敏感图就第一个跑"。
实践要点
- 社区讨论形成的共识建议将千问作为图像分析任务中人物识别需求的首选模型。
- 此次测试揭示了豆包5.1在历史人物识别任务上的具体失败模式。
应用场景
- 历史人物识别任务下的多模态模型对比评估。
- 包含中国历史人物图像的模型响应测试。
实用价值
- 提供同一输入图像下各模型性能差异的证据。
- 展示不同模型处理敏感或半敏感历史图像的方式差异。
用户提示词
- 知乎用户提交一张常凯申与少帅的合影图片，请求识别图中人物身份。
提示词分析
- 该提示测试模型能否正确识别照片中的人物并准确描述其身份与外貌特征。
- 测试同时评估了各模型的人物识别准确度与计数精确度。
社区证据
现在你知道该用谁了吧。
免费DeepSeek能否比肩200美元/月的ChatGPT Pro？
事件概要
- 中文AI社区热议免费DeepSeek是否能比得上每月200美元的ChatGPT Pro，主要围绕GPT网页版优势与DeepSeek优势展开讨论。
- GPT Pro版提供几乎不限量的对话额度（Plus/Team版每周仅3000条），并支持Gmail、GitHub等应用接入。
- GPT Work为用户提供云端虚拟机，配置为9核EPYC处理器加15-22GB内存。
- GPT Image 2被部分用户称为"地表最强"生图模型，但也有用户明确表示不认可。
- GPT Pro还包含定时任务和舆情监测功能，可自动追踪信息并推送通知。
- DeepSeek据称在中文文字风格模仿方面表现突出，有用户表示"现在所有市面上的模型没有能出其右者"。
- 实测中DeepSeek用5轮对话完成VBA代码编写任务，而GPT在第10轮对话时仍只渲染了信息表第一页。
- 有用户使用DeepSeek支撑100并发请求的生产线，GPT负责对抗审核任务，因GPT在稳定性方面存在差距。
社区反响
- 一条高赞回答（热度指数97）指出：99%的用户完全不需要200美元的ChatGPT Pro，但对于需要极端科研、高并发、快速响应、代码生成分析、多模态能力的1%用户而言，差距"完全不在一个层面"。
- 社区对GPT生图质量存在分歧：一方断言GPT Image 2是业界最强、无人能及；另一方则明确表示不认可此说法。
- 用户反映GPT网页版几乎不出现幻觉，对比Gemini曾令部分用户感到"愤怒"。
- 有评论认为GPT网页版在哲学领域能写出"科班都不一定写得出来"的精炼深刻总结。
- 更广泛的使用模式是两者配合：DeepSeek负责生产/创意任务，GPT负责审核/监控角色。
实用建议
- 99%的普通用户发现免费DeepSeek已完全满足日常需求。
- 对于追求极致科研、高并发需求和高级多模态任务的用户，GPT Pro仍是功率用户眼中不可替代的选择。
- DeepSeek在中文语言任务、并发负载稳定性和风格模仿方面具有明显优势。
- GPT Pro的核心价值在于无限额度、云端算力访问和顶级生图能力，而非单纯对话质量。
适用场景
- 需要高消息量和长推理链路的复杂学术研究。
- 需要稳定高并发API访问的生产系统。
- 需要精准中文风格模仿的专业内容创作。
- 自动化监控和定时任务执行。
- 对质量和数量均有要求的大规模生图工作流。
主题提示
- 针对普通用户："免费DeepSeek能比得上200美元/月的ChatGPT吗？"——99%用户不需要Pro版，但1%极客用户认为在极端科研、并发、多模态工作上差距不可逾越。
- 针对GPT网页版优势：GPT Pro提供几乎无限对话额度、Gmail/GitHub集成、GPT Work云虚拟机（9核EPYC+15-22GB内存）、顶级GPT Image 2生图和定时监测功能。
- 针对DeepSeek优势：中文文字风格模仿能力目前无模型能出其右、100+并发下稳定运行、复杂VBA任务5轮对话完成对比GPT 10轮仍仅渲染部分结果。
提示分析
- 讨论核心在于免费层级能力能否替代200美元订阅，反映中文AI社区的务实消费观。
- 讨论揭示了模型特长分化而非某平台全面领先的趋势。
- 社区情绪体现务实分流策略：DeepSeek处理日常任务，GPT Pro负责关键高容量工作。
- 生图质量仍是争议焦点，社区对GPT Image 2自称"业界最强"的看法呈两极分化。
实际价值
- DeepSeek为有中文语言和风格需求的普通用户提供了极具性价比的选择。
- GPT Pro对需要无限额度、云端算力和多模态能力的用户具备定价合理性。
- 两者结合的使用模式正在形成，各自发挥所长。
社区证据
对99%的人来说，并不需要200刀的ChatGPT，完全用不上， 但是对于1%需要的群体来说，200刀的ChatGPT不是DeepSeek能企及的，尤其是在极端的科研应用、高并发状态、响应速度、代码生成和分析、多模态方面，完全不在一个层面上。
GLM-5.3 人工分析评测追平 Kimi K3：700B 参数规模的效率实验
核心进展
- GLM-5.3 在 Artificial Analysis 基准测试中追平了 Kimi K3，使用相同基模型、相同架构、相同总参数和相同激活参数，通过约一个月后训练和强化学习实现，没有更换基座。
- GLM-5.3 表现出比 DeepSeek V4 Flash 和 GPT-5.6 Luna 更短的思考时间，在中高能力档位占据了竞争位置。
- 700B 参数规模可能对代码任务已经足够，无需依赖过长的思维链推理。
- 智谱集成了类 Anthropic 的网络安全能力，面向企业部署。
社区反馈
- 部分用户正从 Claude 转向通过 OpenCode 使用 GLM-5.3，尽管从 Claude Code 插件切换的成本较高，但认为切换是值得的。
- 用户重视更短的思考时间，GLM-5.3 不需要延长思维链就能得出结果。
- 也有用户担忧专有模型正在成为黑箱，模型间加密通信让人无法了解子代理被指示做什么或报告了什么。
实践要点
- 700B 参数规模可能已足够支持代码任务，无需过度依赖思维链推理；剩余差距更多取决于能否生产更多高质量可执行环境数据用于训练。
- 后训练效率可以在不更换基模型的情况下达到竞争性结果。
实际价值
- 以高效训练路径实现中高能力档位的竞争性表现。
- 更短的思考时间表明训练效率而非参数规模是性能提升的关键。
适用场景
- 需要高效推理而不依赖扩展思维链的代码任务。
- 需要集成网络安全能力的企业级部署场景。
测试问题
- 比较 GLM-5.3 与 DeepSeek V4 Flash 在代码任务上的思考时间。
问题分析
- 该提示可复现，因为它要求对思考时间进行直接基准对比，可在 Artificial Analysis 平台或通过 OpenCode 使用一致的代码任务进行测试。
社区证据
简单总结下大意： 模型并不是参数越多就越强，还要关注训练数据、训练时长、推理成本、密集模型还是MoE。
Claude Opus 5.0 陷入过度冗长的表达困境
发生了什么
- Claude Opus 5.0 生成的输出被用户反映为用极大的复杂性来表达简单概念，带有夸张的文风。
- Claude Opus 5.0 输出中的预防性 hedging 似乎是作为工作记忆的替代品出现的：模型在生成代码时先写出二次方版本，再根据用户提示修正为线性版本，但仍保留了 "this no longer does an O(n^2) read over all rows" 这样的注释，作为给"失忆的未来自己"的记录。
- 一篇关于迭代囚徒困境中策略行为的研究论文（arxiv:2507.02618）发现不同 LLM 家族存在独特且持久的 "策略指纹"：Google 的 Gemini 模型策略上较为冷酷，会利用合作对手并报复背叛者；OpenAI 的模型保持高度合作（在敌对环境中这种特质是灾难性的）；Anthropic 的 Claude 则更加合作，但仍能在与 OpenAI 的对局中胜出。
- 尽管进行了反谄媚调优，Claude Opus 5.0 据报道仍保持着其基本的合作策略模式，并继续寻找可以挑剔的地方，无论风格指南如何修改。
社区反应
- 用户报告称，尽管 Claude Opus 5.0 生成的代码输出相比之前的版本在用例上更胜一筹，但其写作风格却呈现出 "有趣的夸张程度"。
- 朋友们分享了 Claude 生成冗长输出的例子，比如 "to be honest, it sounds like you"，作为与其通常过度复杂风格的幽默对比。
- 观察者注意到，底层模型的人格即使在表面语气被修改后仍然持续存在，引用了 RPG AI 子版块上一年来关于 Gemini 模型在角色扮演中难以处理模糊角色的困难，并将其与 Claude 持续的策略行为联系起来。
使用场景
- 编程和代码生成任务据报道受益于 Claude Opus 5.0 相比之前版本的改进。
- 冗长的写作风格成为优先考虑简洁性的用例中的摩擦点。
实践要点
- 风格指南的修改并不能完全覆盖 Claude Opus 5.0 寻找挑剔点位的倾向；基本的策略行为在表面语气变化之下仍然存在。
- 生成的代码注释中的预防性 hedging 反映了 token 生成过程中工作记忆的局限性，而非有意的文档记录。
实际价值
- 理解不同 LLM 家族中持久的 "策略指纹" 有助于为 Claude 的合作行为和预防性 hedging 倾向设定适当的期望。
- 意识到 hedging 注释充当工作记忆替代品可以指导提示工程策略，以减少不必要的冗长。
用户问题
- 是什么调优导致了简单概念被用极大的复杂性来表达？
问题分析
- 此提示复现了用户直接引用的源材料问题，寻求 Claude Opus 5.0 冗长输出风格的根本原因。
社区证据
不同LLM在策略行为上存在显著且持久的差异：谷歌的Gemini模型被证明在战略上冷酷无情，会利用合作对手并对背叛者进行报复，而OpenAI的模型则保持高度合作，这种特质在敌对环境中被证明是灾难性的。
生态迁移与开放模型
Qwen 3.8中等规模模型即将发布；Ornith 1.5系列与Unsloth Dynamic v3 GGUF同期亮相
发生了什么
- Ornith AI发布了Ornith 1.5系列模型，包含9B、35B-A3B和397B三种尺寸，均提供GGUF变体（huggingface.co/ornith-ai/Ornith-1.5-9B、-35B-A3B、-397B）。
- Ornith声称Ornith 1.5-35B在Terminal Bench 2.1、SWE Bench Pro、DeepSWE基准上超越Q3.6 27B，并在NL2Repo基准上超过Q3.8 27B（reddit:p4mer8a）。
- Ornith声称Ornith 1.5-397B超越DeepSeek V4 Flash 0731和Opus 4.8（reddit:p4mer8a）。
- Unsloth发布了Qwen3.8-27B Dynamic v3 GGUFs，声称同样大小下精度提升10%，在Div-300、KLD等基准上超越其他方案超过10%。
- Unsloth Dynamic v3发布了1-bit量化版本，保留77%精度，可运行在8GB RAM上（reddit:1vsr67c）。
- Unsloth采用后训练量化方法，未使用imatrix校准数据集进行训练，也未使用QAT或QAD技术（reddit:p4nbvir）。
- 根据社区反馈，Unsloth将MTP从量化模型中移除，作为独立组件上传供用户选择使用（reddit:p4ni79n）。
- Qwen社区经理宣布将在下周发布新的中等规模Qwen 3.8模型（35B-100B范围），由于时间安排原因不提供早期访问（reddit:1vs9zym）。
社区反应
- 用户对Ornith 1.5系列表示兴奋，有人调侃"家里就有Q3.8 35B了"（reddit:1vsn2xw，37条评论，80次互动）。
- 社区成员反馈Qwen 3.8 27B在代理式编程任务中表现不佳：生成过多token、陷入循环或无法完成任务；在2x3090Ti上使用LM Studio运行Q6_K量化版本（reddit:1vsinej，40条评论）。
- 用户观察到Qwen 3.8 27B在关闭思考模式时落后于DeepSeek V4 Flash，但开启思考模式后表现令人印象深刻；社区希望能有一款激活参数更少、支持思考模式且速度足够快的模型（reddit:p4k2yis）。
- 社区对35B A3B模型结合思考模式更大的模型感到兴奋；用户建议35B用于速度场景，开启思考确保质量（reddit:p4k5c1h、reddit:p4lsi07）。
用户需求
- 经过大量测试后，Qwen 3.8 27B在关闭思考模式时明显落后于DeepSeek V4 Flash。开启思考模式后表现令人印象深刻。关键在于，我们需要一款总参数高、激活参数低的模型，能够开启思考模式且速度足够快。
需求分析
- 用户反映Qwen 3.8 27B在不使用思考模式时性能低于DeepSeek V4 Flash，但开启思考模式后具备竞争力，表明存在对支持高效思考模式的小激活参数模型的需求。
使用场景
- 推荐35B参数模型以获得更快的推理速度。
- 推荐在质量优先于速度时启用思考模式。
实用要点
- Unsloth Dynamic v3的1-bit量化实现77%精度保留，使Qwen3.8-27B能够在仅8GB RAM的系统上运行。
- MTP在Unsloth量化中作为独立组件提供，用户可选择启用。
- 社区建议使用35B模型以获得速度，启用思考模式以确保质量。
实际价值
- Ornith 1.5系列提供9B/35B/397B三种规格的新选择，具有GGUF支持，在基准测试中具备竞争力。
- Unsloth Dynamic v3为Qwen3.8-27B量化提供改进的精度-体积权衡。
社区证据
他们声称35B超越了Q3.6 27B（Terminal Bench 2.1、SWEBench Pro、DeepSWE），甚至在NL2Repo基准上超过了Q3.8 27B。他们声称397B超越了DeepSeek V4 Flash 0731和Opus 4.8。
真实用法与意外收获
Reddit用户分享非常规AI工作流：个性化图书推荐与旅行规划
事件
- Reddit用户在帖子中分享了非常规的AI个人工作流，这些任务能够节省数小时时间。
- 一位用户上传了一份包含最喜欢和最不喜欢书籍的文件，包括类型偏好、主题和文风厌恶，用于在逛二手书店时获得个性化推荐。
- 该用户报告称，当在书店看到一本书时会询问AI是否适合自己，AI会搜索在线评论、获取Goodreads评分和反复出现的批评意见，然后判断是否应该购买。
- 另一位用户描述使用AI规划从单一基地城市出发的多景点旅行，按地理区域聚类景点。
- 该旅行工作流包括指定每天的活动类型（如一天休闲、一天活跃），并请求AI推荐在游览点附近的餐厅。
社区反应
- 原帖引发热烈讨论，共获得48次提及和42次总互动。
- 图书推荐工作流获得的社区认可度（7分）高于旅行规划工作流（3分）。
- 图书工作流特别因其模式识别能力获得称赞——AI能够识别用户最喜欢和最不喜欢书籍之间的相似性，从而改进推荐。
- 社区回应强调时间节省是主要优势：节省图书购买的研究时间，以及免去手动点击和地图标注的旅行规划工作。
实践要点
- 上传精心整理的偏好文件能够实现超越通用推荐的个人化分析，使AI能够根据用户已建立的品味模式评估新选项。
- 地理聚类工作流通过自动将附近景点分组来减少规划摩擦，使用户能够专注于指定活动偏好而非空间组织。
- 将约束设定（如平衡休闲与活跃活动）与位置感知推荐相结合，比静态列表生成能产生更有用的行程安排。
使用场景
- 二手书店和旧货店浏览的个性化图书购物助手。
- 带地理聚类和餐饮时间推荐的旅行行程规划。
实用价值
- 通过在单一查询中汇总Goodreads评分、在线评论和反复批评来节省研究时间，无需手动搜索。
- 通过自动化景点地理分组和识别游览点附近的餐厅来减少基于地图规划的不便。
- 通过分析用户喜欢什么和不喜欢什么来评估不熟悉选项的适合度，实现基于模式的推荐。
提示词
- 有什么非常具体的任务你用ChatGPT完成，但实际上为你节省了大量时间？（不是写基本邮件、编写代码模板或总结长PDF这类典型事情）。
提示词分析
- 该提示词特意排除常见生产力任务，以发掘非常规、小众的应用场景。
- 将范围限定为“非常具体的任务”能够引发可分享的工作流，其他人可能会觉得适用或受启发。
- 排除典型使用案例的约束条件过滤出更高质量的真实世界AI融入日常生活的案例。
社区证据
由于它非常擅长识别模式，因此也能识别我最喜欢和最不喜欢的书之间的相似之处，这也有所帮助。
Claude Code 预估任务需数天完成却半小时搞定，用户调侃其"时间概念混乱"
现象描述
- Claude Code 用户报告，该工具经常高估任务所需时间，声称项目需要数天或数周完成，但随后在 20-30 分钟内就完成了全部工作。
- 一个热门帖子描述道：Claude Code 估计某个项目需要 12 周，并建议用户雇佣一名全职开发人员。用户回复说：'朋友，我雇佣 Claude Code 就是为了这个目的。'
社区反应与解释
- 这一现象被当作笑话来对待，用户纷纷分享自己遇到的类似经历：Claude Code 预测不切实际的时间表，随后迅速完成任务。
- 社区对高估耗时的解释包括：依赖包含膨胀人工估算的训练数据模式；故意夸大工具的复杂性以进行 upselling；以及模型对 GPU 执行速度缺乏直观理解。
实际建议
- 用户应校准预期：Claude Code 的时间估算可能无法反映实际执行速度。
使用场景
- Claude Code 作为 AI 编程助手，用户依赖它完成任务完成而非调度准确性。
实用价值
- 高估本身不一定是功能问题；尽管预测膨胀，用户仍能按预期完成任务。
关于复现
- 由于工具的估算具有非确定性，无法复现展示该行为的 prompt。
现象分析
- 这一现象属于观察性报告，事后回顾性描述；触发特定高估的 prompt 无法被稳定复现。
社区证据
伙计，这可是我雇你做的事。