OpenAI震撼发布GPT-Image-2:图像生成进入新阶段!断档领先!

今日头条是OpenAI的重大发布：GPT-Image-2。

经过数周的秘密测试与坊间猜测[1]，GPT-Image-2现已在API和ChatGPT上全面上线，旨在超越Nano Banana 2[2]等现有竞品，引领图像生成领域进入新纪元。该模型提供了“思考型”和“非思考型”两种变体。值得注意的是，此次发布是在Sora团队遭遇解散并有多人离职[3]的传闻后进行的，这表明图像生成仍是OpenAI的核心战略重点，令人既振奋又有些惊讶。幸运的是，这款模型的表现非常出色。我们强烈建议读者查阅团队发布的八个演示视频[4]

，以及官方博客文章、直播[5]和推特/博客推文[6]。

若要选择一个最令人印象深刻的演示，那便是其在矩阵示例[7]中对文本细节和一致性的惊人处理能力，

以及自定义的“Where’s Waldo”图片生成能力[8]。

一、AI推特热点回顾

OpenAI GPT-Image-2发布：图像生成重回产品焦点

• GPT-Image-2是当日最明确的产品发布：OpenAI在ChatGPT、Codex和API上推出了ChatGPT Images 2.0及其底层模型gpt-image-2。新模型在文本渲染、布局保真度、图像编辑、多语言支持以及“思考型”图像生成方面都有显著提升。OpenAI表示，结合思考型模型，它可以进行网络搜索、生成多个候选方案、自我检查输出，并能生成幻灯片、信息图、图表、UI原型和二维码等人工制品[13, 14, 15, 16]。该模型已被下游工具迅速集成，包括Figma[17]、Canva[18]、Firefly[19]、fal[20]和Hermes Agent[21]。

• 基准测试显示巨大飞跃，尤其在实用图像任务上：Arena排行榜显示，GPT-Image-2在所有图像Arena排行榜上均位居第一，其中文本到图像得分1512，单图像编辑1513，多图像编辑1464。在文本到图像任务中，其Elo评分领先第二名达+242[22, 23, 24]。独立反馈一致认为，这不仅仅是生成了更美观的艺术作品，更是一个适用于UI、模型、文档、生产力视觉效果和参考驱动设计循环的更实用模型[25, 26, 27, 28]。最有趣的系统性启示是，图像生成正成为编码代理的前端：生成一个UI规范图像，然后由Codex或其他代码代理根据该视觉参考进行实现。

• 

代理基础设施：Hugging Face的ml-intern、Hermes扩展及研究/运行时框架的崛起

• Hugging Face的ml-intern是本次最强大的开放式代理：Hugging Face推出了ml-intern，一个开源代理，可自动化训练后研究循环：阅读论文、跟踪引用图、收集/重整数据集、启动训练任务、评估运行并迭代失败[29, 30, 31]。报告的例子引人注目，因为它们是端到端循环，而不仅仅是编码演示：GPQA科学推理在Qwen3-1.7B上在不到10小时内从10%提升到32%，一个医疗设置据称在HealthBench上击败Codex达60%，一个数学设置编写了完整的GRPO脚本并通过消融从奖励崩溃中恢复。社区测试迅速表明，它能够自主微调并将人工制品发布回Hub[32]。

• Hermes正演变为更丰富的本地/开放代理平台：多条推文指出Hermes作为实用开放代理栈的势头：由Hermes代理自身生成的入门指南[33]、Skillkit[34]中的原生支持、名为Scarf[35]的新macOS GUI以及在本地工作流中的扩展使用。最具技术意义的更新来自Teknium[36]：Hermes子代理现在支持更大的生成宽度和递归生成深度，从而实现更深层次的层次分解。这与从“单一聊天循环”代理到具有内存、工具、权限和可重用技能的多进程编排系统的更广泛转变相符。

• 运行时框架正成为第一流的工程产品：推特上反复出现的一个主题是，代理系统的有用部分越来越是运行时/框架，而不仅仅是基础模型本身。DSPy 3.2发布了RLM改进，以及优化器链和LiteLLM解耦[37]；Isaac Flath认为RLM使笔记本再次成为相关的REPL原生跟踪/评估界面[38]；LangChain增加了自定义deepagents部署认证[39]；一篇关于Claude Code的论文摘要强调，大多数系统是框架逻辑而非原始“智能”[40]。

Kimi K2.6、KDA内核及开源编码模型系统级能力提升

• Moonshot同时推动模型能力和内核基础设施：旗舰Kimi推文声称K2.6以持续的自主性完成了长周期编码任务：一次运行在Zig中下载并优化了Qwen3.5-0.8B推理，经过4000多次工具调用和12个多小时，吞吐量从约15 tok/s提升到约193 tok/s，最终比LM Studio快约20%[41]。另一次运行据称重构了一个交换引擎，经过1000多次工具调用和4000多行代码更改，实现了185%的中等吞吐量和133%的峰值吞吐量提升[42]。这些仍然是厂商演示，但它们比基准测试截图更接近于系统工作。

• Kimi还开源了性能关键基础设施：Moonshot发布了FlashKDA，一个基于CUTLASS的Kimi Delta Attention内核实现，声称在H20上比flash-linear-attention基线实现了1.72×–2.22×的预填充速度提升，并且兼容作为flash-linear-attention的即插即用后端[43]。外部后续报告显示，K2.6 + DFlash在8x MI300X上达到了508 tok/s，比基线自回归设置提升了5.6×的吞吐量[44]。结合DSA/MLA/KDA变体的持续讨论，关键信号是中国实验室不仅发布模型权重，还越来越多地发布具有实际部署影响的注意力/内核级优化。

• 开源编码质量正在提高，但对性能差异仍有分歧：一些用户现在将Kimi K2.6视为最佳的开源/开放权重编码/代理模型[45, 46]，而另一些用户则认为领先的专有模型在WeirdML、长周期任务和可靠性方面仍保持巨大优势[47, 48]。实质性的结论并非“开源已经赶上”，而是开放权重模型现在已经足够可靠，基础设施、框架和部署质量决定了大量实际价值。

深度研究系统：谷歌拓展研究代理前沿

• 谷歌将深度研究升级为更可配置的API原语：谷歌/DeepMind通过Gemini API推出了更新的Deep Research和Deep Research Max，由Gemini 3.1 Pro提供支持，具有协同规划、任意MCP支持、多模态输入（PDF/CSV/图像/音频/视频）、代码执行、原生图表/信息图生成和实时进度流[49, 50, 51, 52]。

• 基准数据足以产生商业影响：谷歌强调Max变体在DeepSearchQA上达到93.3%，在BrowseComp上达到85.9%，在HLE上达到54.6%[53, 54]。比原始分数更重要的是工作流设计：谷歌显然正在将“隔夜尽职调查/分析报告生成”产品化，并将MCP支持的内部数据访问作为研究代理的标准部分。这也表明简单浏览代理和全栈研究代理之间存在越来越大的分歧，后者负责规划、搜索、执行代码、生成视觉效果并基于专有语料库进行基础验证。

检索、数据与评估：具备实际工程价值的开放发布

• LightOn在检索领域发布了有意义的开放成果：LightOn发布了LateOn和DenseOn，两者都是1.49亿参数的检索模型，采用Apache 2.0许可证。据报告，LateOn（多向量/ColBERT风格）在BEIR上的NDCG@10达到57.22，DenseOn（密集单向量）达到56.20，超越了体积大4倍的模型[55, 56]。他们还发布了一个整合后的数据集，包含14亿查询-文档对，以及基于FineWeb-Edu构建的更新网络数据集[57]。

• vLLM发布了实用部署知识层：[recipes.vllm.ai] [58]的重新设计比听起来更有用。它将模型页面映射到可运行的部署配方，包含交互式命令构建器，支持NVIDIA和AMD，涵盖张量/专家/数据并行变体，并为代理暴露JSON API。这正是那种能减少操作员部署新开放模型摩擦的基础设施文档层。

• 基准测试日益深入探测代理盲点，而非仅仅任务输出：值得注意的例子包括用于理解真实企业文档中图表的ParseBench[59, 60]，以及一项新结果显示代理常常忽略明确的环境线索，即使解决方案明确暴露在文件或端点中[61]。谷歌研究的ReasoningBank[62]也符合这一主题，将内存框架为从成功和失败轨迹中学习。

高互动推文精选

• OpenAI的图像发布： “Introducing ChatGPT Images 2.0”[13]是当日主导的技术发布推文，辅以深入的功能线程和快速的下游集成。

• HF ml-intern：akseljoonas[29]发布了当日最出色的代理/研究循环成果。

• Gemma本地并发演示：googlegemma[63]展示了Gemma 4 26B A4B在M4 Max上以约18 tok/s/请求的速度处理10+个并发请求，为本地服务经济学提供了有用的数据点。

• Deep Research Max：Sundar Pichai[51]和Google[49]推出了实质上更强大的研究代理API界面。

• Kimi内核发布：FlashKDA[43]是模型服务栈中最实质性的开放基础设施之一。

• 开源政策警告：Clement Delangue[64]警告称，限制开源AI的游说活动再次出现，这是少数对构建者有直接影响的政策推文之一。

二、AI Reddit热点回顾

Kimi K2.6模型发布与基准表现

• Claude Code从Claude Pro计划移除——现在是转用本地模型的最佳时机。[65]：图片显示了“Claude”服务不同订阅计划的对比图，突出显示了Pro计划中移除了“Claude Code”功能。这一变化意义重大，表明服务产品发生了转变，可能促使用户考虑Kimi K2.6或Qwen 3.6 35B A3B等替代本地模型。帖子讨论了转用这些本地模型的成本效益，强调OpenCode Go编码计划的价值，它比Claude Pro计划以更低的价格提供更多tokens。评论者对Pro计划中移除“Claude Code”功能表示难以置信和沮丧，一些人认为这可能是一个错误，另一些人则敦促公司在其产品页面上解决此问题。

  • korino11提出了一项成本效益分析，比较了20美元的OpenCode计划与Kimi上的19美元计划，认为后者可能提供更好的价值。这暗示用户需要评估不同AI模型订阅的成本效益，尤其是在功能被移除或更改时。

  • Apart_Ebb_9867指出Claude官方产品页面信息可能存在问题，暗示页面可能需要更新或纠正。这强调了依赖特定功能的用户对准确、最新文档的需求。

  • The-Communist-Cat提到网上没有关于Claude Code从Pro计划中移除的参考资料，表明公司可能存在信息不准确或沟通延迟。这强调了服务提供商需要清晰及时的更新，以避免用户混淆。

• Kimi K2.6是Opus 4.7的合法替代品[66]：Kimi K2.6被定位为Opus 4.7的可行替代品，能够以合理的质量执行Opus 85%的任务。虽然它在任何特定领域都没有超越Opus 4.7，但Kimi K2.6提供了视觉和有效浏览器使用等额外功能，使其适用于长期任务。尽管其规模庞大，但它暗示像Opus 4.7这样的前沿LLM可能并未提供显著的新进展。该模型支持本地部署，避免了使用限制等问题。评论者对快速测试和推荐过程表示怀疑，指出彻底测试通常需要更长时间。也有关于本地模型可负担性的讨论，一些用户对高成本表示沮丧。

  • InterstellarReddit强调了Kimi K2.6快速测试和部署过程，指出原作者在两小时内测试并向客户推荐了该模型。这与他们公司由四名工程师进行一周评估后才进行客户测试的流程形成对比。这凸显了小型团队或个人开发者在AI模型部署中的效率和敏捷性。

  • Technical-Earth-3254建议，如果Kimi K2.6达到Opus 85%的性能，它有可能完全替代Sonnet模型。这意味着Kimi K2.6被视为现有模型的可行替代方案，以潜在更低的成本或资源需求提供类似功能。

  • Blablabene讨论了Kimi K2.6等本地AI模型对市场的影响，强调它们对专有模型施加了降低成本的压力。评论还指出当前本地运行模型的成本很高，但预计未来随着技术进步和成本降低，可访问性将提高。

• Opus 4.7 Max订阅者转用Kimi 2.6[67]：帖子讨论了从Opus 4.7 Max转向Kimi 2.6的原因是性能和成本问题。用户指出Opus 4.7变得“懒惰”且昂贵，促使他们转用Kimi 2.6，后者被描述为快速且令人愉悦，尽管其上下文大小较小。用户强调Kimi 2.6有效管理其较小的上下文，表明在处理工具输出方面有所改进。一个请求[68]已提交，以改进Kimi与Forge的集成。评论者对Anthropic和OpenAI等专有模型的投资可持续性表示怀疑，因为像Kimi这样的开放模型正变得具有竞争力。也有关于中国模型潜力的争论，Kimi是1T模型，而Opus是5T，表明竞争格局正在发生变化。

  • Worried-Squirrel2023强调了Opus 4.7的一个关键问题，指出其倾向于“中途停止任务或在完成之前结束”，他们称之为“懒惰”。这表明任务完成可靠性存在问题，这在实际应用中可能是一个显著的缺点。他们还提到Kimi较小的上下文窗口问题较少，与Opus的承诺问题相比，他们特别关注“工具调用可靠性”，并认为Kimi和Opus之间存在显著差异。

  • sb5550指出Kimi和Opus模型大小的巨大差异，Kimi是“1T模型”，Opus是“5T模型”。这一比较突出了Kimi等小型模型的效率和潜力，尤其考虑到中国模型可能没有落后，反而可能在AI发展中领先。这引发了关于小型模型与大型模型相比的可扩展性和性能效率的问题。

  • Ok-Contest-5856讨论了对Anthropic和OpenAI等专有模型进行私募股权投资的财务影响，暗示像Kimi这样“旗鼓相当且便宜得多”的开放模型可能构成重大威胁。他们推测开放模型未来甚至可能超越专有模型，这表明AI开发竞争格局正在发生变化。

• Kimi K2.6发布（Hugging Face）[69]：Hugging Face发布的Kimi K2.6是一款前沿的开源多模态AI模型，针对长周期编码和自主任务编排进行了优化。它采用1万亿参数的专家混合架构，能够将提示转化为生产就绪的界面，并执行多种语言的复杂编码任务。该模型支持多达300个子代理进行并行任务执行，并在基准测试中表现出色，尤其是在vLLM和SGLang等平台上的主动编排和部署方面。更多细节可在原始文章[70]中找到。评论者指出1.1万亿参数的惊人规模，一些人对模型的规模表示惊讶。也有提到Cursor的Composer 2.1模型开始训练，表明该领域正在持续进步。

  • ResidentPositive4122强调，Kimi K2.6发布包括代码库和模型权重，采用修改后的MIT许可证。该许可证保留了MIT的“随心所欲”核心精神，但要求大型公司在使用时进行署名，这对于考虑集成或修改模型的开发者来说是一个重要点。

  • LagOps91对Kimi K2.6模型潜在的实际性能表示兴趣，指出虽然基准令人印象深刻，但真正的考验是这些如何转化为实际应用。这强调了评估模型除了理论指标之外，还需要评估其在现实场景中的实用性。

• Kimi K2.6[71]：图片展示了AI模型的基准比较图，突出显示了新发布的Kimi K2.6与GPT-5.4、Claude Opus 4.6和Gemini 3.1 Pro等其他模型之间的性能。Kimi K2.6在通用代理、编码和视觉代理等类别中表现强劲，尤其在“人类最终考试”和“DeepSearchQA”等任务中得分很高，表明其作为强大AI模型的潜力。评论者指出Kimi K2.6性能的重要性，尤其是在编码方面，并对其与闭源模型的竞争力表示惊讶。还提到Kimi的供应商验证器，该验证器标准化了第三方服务评估，突出了其在AI生态系统中的重要性。

  • Kimi K2.6模型引入了一种标准化第三方服务评估方法，这对于确保不同实现之间的一致性能和可靠性至关重要。这种方法可能显著影响开源模型与闭源模型的评估方式，可能拉平竞争环境。

  • 人们普遍期待Kimi K2.6可能超越竞争模型Opus。尽管其规模庞大，社区仍希望Kimi K2.6能在性能方面树立新基准，尤其与DeepseekV4等其他模型相比，后者曾寄予厚望但未能完全实现。

  • Kimi K2.6的发布通过在开源社区中设定高标准，提高了对未来模型（如GLM-5.1）的期望。这一发展表明竞争格局正在转变，开源模型正在日益挑战专有模型的主导地位。

Gemma 4模型能力与基准

• Gemma 4 Vision[72]：帖子讨论了通过调整Gemma 4模型的视觉预算参数来优化其视觉能力。--image-min-tokens和--image-max-tokens的默认设置分别为40和280，这对于详细的OCR任务来说被认为是不足的。作者建议将这些值增加到560和2240以提高性能，并指出此配置使Gemma 4在视觉任务中超越了Qwen 3.5、Qwen 3.6和GLM OCR等其他模型。此调整需要VRAM使用量显著增加，在最大上下文中，q8_0从63 GB增加到77 GB。帖子还提到了Ollama实现的一个限制，可能由于未解决的问题而不支持这些更改。一位评论者询问小型模型的最小token设置，质疑40 token的最小值是否仅适用于大型模型。另一位用户请求llamacpp和vllm的详细配置选项，表明需要更全面的设置指南。

  • Temporary-Mix8022讨论了使用来自约1.5亿参数小型模型的视觉编码器，提到70 token作为最小值。他们询问40 token是否是5亿参数大型模型的最小值，暗示token要求因模型大小而异。

  • stddealer分享了他们使用--image-min-tokens 1024和--image-max-tokens 1536设置的经验，这些设置是从Qwen3.5借鉴的。此配置导致对Gemma4视觉能力感知不足的困惑，表明token设置显著影响模型性能。

  • Yukki-elric建议将--image-min-tokens和--image-max-tokens都设置为1120，以获得最佳图像质量处理效果。此建议意味着在token分配和图像质量之间取得平衡，可能提供比其他讨论更可靠的配置。

• Gemma-4-E2B的安全过滤器使其在紧急情况下无法使用[73]：谷歌的Gemma-4-E2B模型，旨在作为本地、离线应急准备资源，因其过于激进的安全过滤器而受到批评，使其在紧急情况下无效。该模型以安全为借口，对紧急气道程序、水净化、机械维护和食品加工等关键生存主题发出“硬性拒绝”。这种限制在无法联系紧急服务的情况下（如战争或电网崩溃期间）存在问题。评论者认为，该模型由于其有限的世界知识，拒绝是合理的，暗示在紧急情况下依赖它可能很危险。一些人建议使用未审查版本或将模型与维基百科备份集成，以获取更可靠的信息。

  • Klutzy-Snow8016强调了Gemma-4-E2B模型的局限性，强调其缺乏全面的世界知识以及在紧急情况下依赖它的潜在危险。他们认为模型可能会产生不正确的信息，这可能危及生命。提出了下载维基百科备份并使模型能够查询它的实用建议，以增强其在关键情况下的实用性。

  • iliark指出，在某些情况下，Gemma-4-E2B模型提供了正确的建议，例如不要从伤口中取出弹片，这符合医疗指导方针。这表明，虽然模型可能存在局限性，但它仍能在特定情况下提供有价值的指导，前提是建议需通过可靠来源验证。

  • Illustrious_Yam9237反对使用Gemma-4-E2B等LLM提供紧急建议，认为存储相关PDF会是更可靠、更高效的解决方案。这反映了对LLM在高风险情况下（精度至关重要）实用性和可靠性的更广泛怀疑。

• Gemma 4 26B-A4B GGUF 基准[74]：图片是Gemma 4 26B-A4B GGUF模型在不同提供商之间平均KL散度的性能基准图。图表显示，Unsloth GGUF处于帕累托前沿，表明它们在量化后保持准确性方面表现最佳。基准显示，Unsloth模型在22种尺寸中有21种超越了其他模型，Q6_K量化更新使其更具动态性，无需重新下载。此外，引入了新的UD-IQ4_NL_XL量化，可在16GB VRAM内运行，为现有模型提供了中间选项。图片支持文本强调Unsloth在量化模型性能方面的有效性。一位评论建议包含推理速度基准，指出硬件变化带来的挑战，而另一位则强调UD-IQ2_XXS与ggml-org大型模型相比的效率。

  • qfox337提出了一个关于包含推理速度基准的恰当问题，指出可能因硬件而异。他们询问不同的压缩方案是否会显著影响性能，暗示基准可以为此提供清晰度。

  • Far-Low-4705比较了量化方法，强调UD-IQ2_XXS在9Gb时比ggml-org的Q4_K_M在16Gb时更高效。这表明模型尺寸效率显著提高，这对于资源受限系统上的部署至关重要。

  • -Ellary-讨论了不同量化方法的性能，指出虽然Unsloth Qs经常在基准中被突出显示，但他们自己的测试表明Bartowski Qs表现相似且提供更大的稳定性。这表明基准结果可能无法完全捕捉真实世界性能的细微差别。

Qwen 3.6模型更新与对比

• 每当新模型发布，旧模型自然会过时[75]：图片是一个梗图，形象地说明了AI模型的快速过时，特别是比较了“Gemma4”和“Qwen3.6”。该梗图幽默地描绘了用户倾向于放弃旧模型而选择新模型，即使旧模型仍有价值的应用。评论指出，虽然“Qwen3.6”可能更适合编码等某些任务，“Gemma4”仍受到创意写作和翻译的青睐，这表明不同模型在不同领域具有优势。评论者表示偏爱“Gemma4”在创意写作和翻译任务中的表现，而“Qwen3.6”则以其编码能力著称。也有人担忧“Qwen3.6”等新模型的可靠性和持续支持。

  • Gemma 4在创意写作任务中表现出色，用户强调其能够毫无争议地处理此类任务。这表明其架构或训练数据可能存在专门化或优化，有利于创意输出。

  • Qwen因其在翻译任务中的表现受到批评，用户指出它不及其他模型。然而，它在编码和开发方面的优势得到认可，这表明可能专注于技术语言处理。

  • 一个关于Qwen的技术问题凸显了其指令遵循能力。用户报告称，在处理几张图像后，Qwen遵循指令的能力显著下降，导致错误的工具调用和无法验证结果。这表明其上下文管理或指令解析机制可能存在局限性。

• Qwen3.6 35b-a3b和Gemma4 26b-a4b-it的非专业比较[76]：该帖子比较了两个AI模型，Qwen3.6-35B-A3B和Gemma4 26B-A4B-it，它们在配备16GB VRAM显卡的Windows LM Studio上运行，采用推荐的推理设置。这些模型在编码和通用任务中的性能得到了评估。Qwen3.6被描述为“A+学生”，能量充沛，而Gemma4则是“扎实的B学生”，表现可靠。这些模型以可比的速度运行，但Qwen被指出比Gemma更频繁地产生幻觉方法，而Gemma更适合复杂提示和后端脚本。帖子还强调了使用正确的系统提示来释放Gemma潜力的重要性，正如一位用户评论所演示的。评论者指出Qwen3.6擅长编程和工具调用，而Gemma4更适合对话、角色扮演和翻译。也有关于后端能力的争论，Qwen比Gemma产生更多幻觉。一些用户建议自定义微调或系统提示可以显著增强Gemma的性能，尤其是在前端任务中。

  • Sadman782强调，虽然Gemma4可以通过自定义微调或系统提示来改进其前端能力，但Qwen3.6经常在方法上产生幻觉，尤其是在后端任务中。他们指出Gemma4在复杂应用开发中表现更好，因为Qwen更容易产生错误。这表明Gemma4可能更可靠地处理复杂的编码任务，而Qwen3.6可能在后端一致性方面遇到困难。

  • Kahvana提供了比较分析，指出Qwen3.5/3.6擅长编程和工具调用，而Gemma4在对话、角色扮演和翻译任务中表现更优。他们提到，这两个模型各有优势，Qwen更适合技术任务，Gemma4更适用于通用或创意任务。这表明它们在最佳使用场景上存在明确划分，Qwen更偏向技术，Gemma4在语言类任务中更具多功能性。

  • BigYoSpeck讨论了Qwen模型的美学能力，指出它们能够创建具有“特色”的视觉吸引力设计。然而，他们警告说，这并不一定意味着更好的问题解决或指令遵循能力。他们建议用独特的挑战来测试模型，这些挑战需要超越其训练集进行适应，以真正评估其能力，而不是依赖可能无法完全展示其优势的通用任务。

• Qwen 3.6 Max预览版已在Qwen Chat网站上线。它目前在中国模型中拥有最高的AA智能指数分数（52）（会开源吗？）[77]：Qwen 3.6 Max已在Qwen Chat网站[78]发布，据AiBattle[79]报告，它目前在中国模型中拥有最高的AA智能指数分数52。鉴于前一版本Qwen 3.6拥有397B参数，该模型的参数数量估计在600-700B之间。然而，没有迹象表明Max版本会开源，因为历史上Max模型从未公开。评论者对Max模型开源表示怀疑，指出这些模型通常不对公众开放。更倾向于在消费级硬件上运行的小型模型，这表明Max模型应保持专有以支持公司收入。

  • 一位用户推测Qwen 3.6 Max模型的参数数量，认为鉴于前一版本Qwen 3.6有397B参数，其可能在600-700B参数之间。这表明模型尺寸显著增加，可能影响性能和资源需求。

  • 另一位用户表示偏爱能够在消费级硬件上运行的小型或中型模型，突出了AI开发中模型尺寸和可访问性之间常见的权衡。他们建议，虽然Max模型是收入引擎，但开源小型模型可以通过使高级AI更易于访问来造福社区。

  • 一条评论指出，最可能开源的最大模型是122B模型，因为该公司已停止开源其更大的397B模型。这反映了将大型模型保持专有的战略决策，可能是为了保持竞争优势或由于支持开源发布存在资源限制。

• Qwen 3.6和3.5（甚至9B）是本地深度研究的优秀模型[80]：Qwen 3.6和3.5模型，包括9B变体，因其在本地深度研究（LDR）基准[81]中的竞争性能而受到强调。这些基准是自报告的，经过一些人工审查，主要关注小型本地模型，因为计算限制。这些模型因其在消费级硬件（如配备3080显卡的笔记本电脑）上处理arXiv或PubMed等大型本地数据集的潜力而备受关注，这有助于减少对云服务的依赖。对于参数小于35B的模型有效性存在争议，一些用户对其性能表示怀疑，而另一些用户则认为Qwen 3.6/3.5等模型在本地文档处理方面具有潜力。

  • Qwen 3.6和3.5模型，包括9B变体，因其在本地深度研究应用中的潜力而备受关注。用户建议扩展数据集并纳入更多外部评估，以增强其鲁棒性和可靠性。这表明致力于通过多样化数据暴露来提高模型准确性和泛化能力。

  • 一位用户强调了Qwen 3.6和3.5模型在本地设置（如配备NVIDIA 3080 GPU的笔记本电脑）上的实际应用，用于处理arXiv或PubMed等大型数据集。这种方法旨在减少对云服务的依赖，表明这些模型足够高效，可用于本地计算，这对于研究工作流中的隐私和成本降低至关重要。

  • 对于参数小于35B的模型性能存在怀疑，一位用户对其局限性表示担忧。这反映了AI社区中关于模型大小和性能之间权衡的常见辩论，其中大型模型通常被认为具有卓越的能力，但代价是增加计算资源。

• 我们开源了Chaperone-Thinking-LQ-1.0——一个4比特GPTQ + QLoRA微调的DeepSeek-R1-32B，在约20GB显存下在MedQA上达到84%[82]：Chaperone-Thinking-LQ-1.0是一个基于DeepSeek-R1-Distill-Qwen-32B的开源推理模型，在MedQA上达到84%的准确率，接近GPT-4o的88%。该模型采用4比特GPTQ量化，将大小从约60GB减少到约20GB，并使用量化感知训练（QAT）和QLoRA在医疗/科学数据上进行微调。它以36.86 tok/s的速度运行，比基础模型快1.6倍，延迟降低约43%，适用于本地企业医疗保健应用。该模型在Hugging Face[83]上以CC-BY-4.0许可证提供。一位评论者指出，一个32B模型在20GB VRAM下达到如此高的MedQA分数令人印象深刻，并表示有兴趣在3090 GPU上测试其推理速度与完整权重模型相比。

  • Chaperone-Thinking-LQ-1.0模型在MedQA上取得了令人印象深刻的84%分数，考虑到其大小和效率，这非常值得关注。这种性能是通过对DeepSeek-R1-32B模型进行4比特GPTQ + QLoRA微调实现的，使其能够在约20GB的VRAM上运行。这使得它可以在NVIDIA 3090等消费级GPU上运行，这对于可访问性和实验性具有显著优势。

Veo与Kimi模型发布

• Kimi 2.6已发布[84]：图片是AI模型的性能比较图，突出显示了新发布的Kimi K2.6与GPT-5.4、Claude Opus 4.6和Gemini 3.1 Pro等其他模型。图表将性能分为“通用代理”、“编码”和“视觉代理”等领域，Kimi K2.6在“人类最终考试”、“BrowseComp”和“Toolathlon”等任务中表现出色。此次发布强调了Kimi K2.6的能力，尤其是在自主优化复杂系统方面，如其对exchange-core金融匹配引擎的全面改进，实现了显著的吞吐量提升。评论者对Kimi K2.6自主优化开源金融引擎的能力印象深刻，突出了其在系统架构和性能增强方面的先进能力。

  • Kimi K2.6通过执行12种优化策略，在13小时内自主优化了开源金融匹配引擎exchange-core。它进行了超过1000次工具调用，修改了4000多行代码，使中等吞吐量提高了185%，性能吞吐量提高了133%。这是通过分析CPU和分配火焰图以识别瓶颈并将核心线程拓扑从4ME+2RE重新配置为2ME+1RE来实现的。

  • 讨论强调了Kimi 2.6的开源性质，鉴于其在设计和网页开发任务中的先进能力，这一点意义重大。用户将其与Claude、GLM 5.1、GPT、Gemini 3.1和Qwen等其他模型进行对比，指出其在PowerPoint、PDF和网页演示等任务中无与伦比的性能。开源状态被视为一项主要优势，可能增加可访问性和创新。

  • 对Kimi 2.6的开源主张存在怀疑，用户寻求确认。尽管如此，该模型在设计任务中的性能受到赞扬，用户指出其在特定领域优于其他模型。如果属实，开源方面被认为是重大发展，可能促进其采用和进一步发展。

• 就在我们都期待Veo 4的时候！[85]：图片幽默地突出了视频生成工具“Veo 3.2 Lite”的发布，而人们正期待更高级的版本“Veo 4”。截图显示了该工具生成自行车比赛视频的通知，表明视频生成存在限制。这表明是增量更新而非重大版本发布，这可能会让期待AI视频生成重大进步的用户感到失望。评论反映了美国在AI视频生成创新方面落后的情绪，一些用户对硅谷与中国相比的停滞不前表示沮丧。也有人认为好莱坞可能正在影响AI发展速度。

• Nano将GLM 5.1和Kimi K2.6添加到订阅，并带有2倍乘数！[86]：Nano宣布将GLM 5.1和Kimi K2.6集成到其订阅服务中，并带有2倍的token消耗乘数，这意味着这些模型将以其他模型两倍的速度每周消耗6000万tokens。此更新由Milan在其Discord服务器上分享，似乎仅限于这两个模型。用户指出GLM 5.1已在z.ai Coding上运行良好。评论普遍支持这一决定，认为这是一种公平的临时措施，直到定价稳定。一些人赞赏Nano为提供价值和有效管理资源使用所做的努力，而另一些人则因未达到token限制而感到不受影响。

三、次级AI社区热点

此部分回顾了来自/r/Singularity、/r/Oobabooga、/r/MachineLearning、/r/OpenAI、/r/ClaudeAI、/r/StableDiffusion、/r/ChatGPT、/r/ChatGPTCoding、/r/aivideo等社区的非技术性AI讨论。

Claude Code与设计更新

• PSA：Claude Pro不再将Claude Code列为包含功能[87]：Claude Pro已从其Pro计划中移除Claude Code作为包含功能，这在其定价页面[88]上有所体现。支持文章[89]也反映了这一变化，表明Claude Code仅适用于Max计划。这一变化是在没有正式公告的情况下进行的，导致用户困惑。用户对缺乏关于这一变化的沟通表示沮丧和失望，一些人考虑由于Pro计划中移除该功能而退订。

  • 一位用户询问Codex与Claude Code的比较，表示有兴趣了解两者之间的技术差异和性能指标。OpenAI开发的Codex以其生成代码和协助编程任务的能力而闻名，利用了GPT-3模型的功能。相比之下，Anthropic提供的Claude Code专注于AI的安全性和可解释性，这可能会影响其编码辅助功能。

• 20年数据丢失创伤对一个女人的影响（Claude Code）[90]：该帖子描述了一个技术过程，用户在Terramaster F4-425 Plus NAS上使用Claude Code，从五个不同的硬盘中恢复并整合损坏的数据，到一个新的16TB RAID存储主库中。用户没有使用哈希和合并等传统方法，而是使用Claude Code分析和推断数十万个松散文件的原始文件夹结构，有效地重建了数据组织。这种方法突出了AI在数据恢复方面的创新应用，强调了该工具超越简单文件去重，推断上下文和结构的能力。评论者赞扬了Claude Code通过推理重建文件夹结构的创造性用途，指出这与典型的去重工具相比是一种新颖的方法。人们对重建的准确性和所用资源（如时间和token）感到好奇。

  • Extra-Organization-6强调了Claude Code在数据恢复方面的新颖用途，通过跨损坏驱动器推理重建文件夹结构。这种方法超越了典型的去重工具，通过确定文件的原始上下文和位置，这是数据恢复技术的一项重大进步。评论者好奇这种方法的准确性与原始文件夹结构相比如何。

  • EightFolding描述了使用Claude重新组织其整个用户目录结构，创建了一个根据实际使用和内容对文件进行分类的系统。这种重组涉及创建特定领域的文件夹和子文件夹，从而简化了他们的工作流程，并消除了对“待排序”文件夹的需求。该过程通过Max计划进行了几天，表明计算量虽然巨大但可行。

  • this_for_loona对使用Claude进行数据恢复的技术细节感兴趣，特别是询问过程中涉及的持续时间和token使用情况。这表明关注使用AI完成此类任务的计算资源和效率。

• Claude Code不再列为Claude Pro的功能[91]：Claude Code已从官方网站比较图上的Claude Pro计划功能列表中移除。这一变化表明Pro计划的功能产品发生了转变，可能影响依赖此功能进行编码任务的用户。该移除可能会影响用户的决策，特别是那些使用Claude进行业余项目的人，因为没有Claude Code，每月100美元的成本可能不再合理。一些用户对Claude Code的移除表示不满，表明由于缺乏此功能的Pro计划成本高昂，可能会转向Codex等替代方案。

  • Claude Code从Claude Pro功能列表的移除引发了对其价值主张的讨论，尤其是对于那些认为每月100美元费用不合理（没有此功能）的业余爱好者而言。这一变化可能促使用户转向OpenAI的Codex等替代方案，后者被认为是更具成本效益的编码任务解决方案。

  • Claude Code从功能列表中移除的确认得到了用户分享的视觉证据的支持，表明服务产品发生了重大转变。这引发了对现有订阅未来的担忧，一些用户希望有“祖父条款”政策以保留对以前可用功能的访问。

  • 讨论强调了用户偏好可能转向其他AI编码解决方案（如Codex）的潜在转变，因为没有编码功能的Claude Pro成本高昂。这表明竞争格局中，定价和功能可用性是影响用户决策的关键因素。

• 如何在Claude Code中管理“上下文腐烂”（Anthropic推荐的工作流）[92]：该帖子解决了Claude Code会话中“上下文腐烂”的问题，即会话退化为低效的错误修复循环。作者提出了几种缓解策略：将CLAUDE.md文件保持在200行以下以最小化token使用；使用谷歌的NotebookLM查询API规范而不是将其复制到会话中；主动使用/compact命令来管理上下文焦点；以及避免重复的错误修复尝试，使用/rewind或/clear命令重置会话历史记录。这些策略旨在优化会话管理并减少不必要的token消耗。评论者同意这些策略，指出使用检查点文件进行逻辑摘要有助于保持焦点。对大型上下文窗口持怀疑态度，倾向于模块化任务以改进调试和测试。一位评论者询问NotebookLM之外的API信息集成替代方案。

  • bithatchling建议使用包含当前逻辑的检查点文件来管理Claude Code中的“上下文腐烂”，因为它比冗长的聊天历史更好地处理专用摘要文件，尤其是在深度重构期间。

  • macebooks反对使用完整的100万上下文窗口大小，因为其昂贵且不可靠，主张模块化功能和任务以辅助调试和测试，这有助于AI专注于相关上下文。

  • baradas引入了一个名为“claude cot”的工具，旨在自动管理上下文腐烂，并提供了GitHub仓库链接供用户试用并提供反馈。

DeepSeek与Qwen模型发展

• DeepSeek的3个被低估的优势：1M上下文（已上线），新mHC架构论文，以及0.28美元/M token[93]：DeepSeek推出了100万token上下文窗口，允许大量数据输入而无需分块，这已上线并投入使用。其关于流形约束超连接（mHC）架构的新论文旨在增强训练稳定性和效率，尽管其主要影响训练而非推理。此外，DeepSeek的定价仍具竞争力，每百万token0.28美元，显著低于GPT-4o等竞争对手。这些进步使DeepSeek成为AI模型开发和成本效益方面的领导者。评论者指出，虽然mHC有所改进，但它不直接影响用户体验。100万token上下文归因于Engram和DualPath等创新，尽管一些用户报告API仍以128K上下文运行。DeepSeek在分享研究方面的开放性受到赞扬，其创新已被其他实验室采用。

  • mHC架构是对HC的改进，主要有助于训练，而非推理或用户体验。真正的游戏规则改变者是Engram架构，它与DualPath一起，可能实现了100万token上下文窗口。这种组合解决了上下文腐烂和NIAH等常见问题，如果实践证明有效，将是一项重大进展。

  • 尽管宣布了100万token上下文窗口，但当前的API仍以128K上下文限制运行，这让一些用户感到失望。这一限制影响了用户体验，因为预期的大上下文窗口优势尚未通过API访问。

  • DeepSeek的创新，如闪存索引、稀疏多头注意力及其MoE版本，已被其他主要实验室和开源模型广泛采用。这反映了DeepSeek的影响力及其研究论文的详细性质，这些论文为更广泛的AI社区做出了贡献，超越了他们自己的实现。

Veo与Kimi模型发布

• Kimi 2.6已发布[84]：图片是AI模型的性能比较图，突出显示了新发布的Kimi K2.6与GPT-5.4、Claude Opus 4.6和Gemini 3.1 Pro等其他模型。图表将性能分为“通用代理”、“编码”和“视觉代理”等领域，Kimi K2.6在“人类最终考试”、“BrowseComp”和“Toolathlon”等任务中表现出色。此次发布强调了Kimi K2.6的能力，尤其是在自主优化复杂系统方面，如其对exchange-core金融匹配引擎的全面改进，实现了显著的吞吐量提升。评论者对Kimi K2.6自主优化开源金融引擎的能力印象深刻，突出了其在系统架构和性能增强方面的先进能力。

• 就在我们都期待Veo 4的时候！[85]：图片幽默地突出了视频生成工具“Veo 3.2 Lite”的发布，而人们正期待更高级的版本“Veo 4”。截图显示了该工具生成自行车比赛视频的通知，表明视频生成存在限制。这表明是增量更新而非重大版本发布，这可能会让期待AI视频生成重大进步的用户感到失望。评论反映了美国在AI视频生成创新方面落后的情绪，一些用户对硅谷与中国相比的停滞不前表示沮丧。也有人认为好莱坞可能正在影响AI发展速度。

• Nano将GLM 5.1和Kimi K2.6添加到订阅，并带有2倍乘数！[86]：Nano宣布将GLM 5.1和Kimi K2.6集成到其订阅服务中，并带有2倍的token消耗乘数，这意味着这些模型将以其他模型两倍的速度每周消耗6000万tokens。此更新由Milan在其Discord服务器上分享，似乎仅限于这两个模型。用户指出GLM 5.1已在z.ai Coding上运行良好。评论普遍支持这一决定，认为这是一种公平的临时措施，直到定价稳定。一些人赞赏Nano为提供价值和有效管理资源使用所做的努力，而另一些人则因未达到token限制而感到不受影响。

参考链接

• [1] https://substack.com/redirect/52777346-cf23-4fe1-9bc5-647d55da4e96?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [2] https://substack.com/redirect/bd1fa431-7de0-4ddd-8b97-1317c7d1afbf?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [3] https://substack.com/redirect/a6e2819c-84a9-4eb1-ac76-1bfa9ef0fb73?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [4] https://substack.com/redirect/4d17e43d-b6e5-4ed4-aa86-53d85b65728b?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [5] https://substack.com/redirect/47c5afcc-a29c-44d2-8771-e17694e188b0?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [6] https://substack.com/redirect/b6c6818f-8a97-4c65-a0cb-f9b3abf4155a?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [7] https://substack.com/redirect/5502b0ff-8ab8-490a-bff5-d995a9132b11?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [8] https://substack.com/redirect/8dc52c64-810b-4e42-8b66-d311c695c5b1?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [9] https://substack.com/redirect/b7c11602-3320-4cc6-b5e0-b469d3f922ca?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [10] https://substack.com/redirect/9dc6fb65-fdaf-4358-8fc3-2fd6cf194220?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [11] https://substack.com/redirect/bf8416ff-68c2-4f35-8e43-f9bd4edc0026?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [12] https://substack.com/redirect/ac80850d-9258-46a4-ba51-62b043375d5d?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [13] https://substack.com/redirect/093a9c26-0bc3-4113-8694-e908c9dfad7b?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [14] https://substack.com/redirect/efa3e335-cec7-41be-9087-bab31b2bda59?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [15] https://substack.com/redirect/fbad5d58-3c9c-443d-88de-4f4ed0f5fcee?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [16] https://substack.com/redirect/d38d754e-1996-4e24-a6b9-d5d3030b0f15?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [17] https://substack.com/redirect/12c89989-2062-4ee8-99e8-ec1fb8a8849d?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [18] https://substack.com/redirect/9cb9edc6-7898-47f3-b3fe-05598f3acf24?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [19] https://substack.com/redirect/78ba80d2-084a-45bf-a48c-4b86d376bd58?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [20] https://substack.com/redirect/37b2ae88-18f5-4478-809a-848275836d9b?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [21] https://substack.com/redirect/99d02301-bea3-4d03-8877-7f1b2525929c?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [22] https://substack.com/redirect/ef771d6a-36a3-4bc7-8bb8-ca597489c43e?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [23] https://substack.com/redirect/398b4e22-e821-4540-87fe-b3198c7733d1?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [24] https://substack.com/redirect/06ae0ef6-ba8f-49a0-8dd5-5da01d994c33?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [25] https://substack.com/redirect/d22a433c-097f-4e00-b6cc-9433a472073f?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [26] https://substack.com/redirect/6616e0c9-f369-40c1-84f5-0747b0aff7e8?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [27] https://substack.com/redirect/9a6ab317-a4e8-4be7-81c7-a00743861429?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [28] https://substack.com/redirect/f2ff563a-98c4-4546-9529-1e400711c8e9?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [29] https://substack.com/redirect/dde30d22-985e-4f43-a7bd-3cf869524619?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [30] https://substack.com/redirect/887dd15f-091b-4bde-9499-99fdcb6bd648?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [31] https://substack.com/redirect/aad3f790-acd2-405e-b36d-6e42b46a364d?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [32] https://substack.com/redirect/5151352d-c897-4512-8eb0-e919ee24ce8b?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [33] https://substack.com/redirect/43a88abe-eb22-4fa9-98da-4ade88627eca?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [34] https://substack.com/redirect/a0844650-fa6c-4143-bdb0-dee381c5a0c4?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [35] https://substack.com/redirect/37ccc984-e050-4f67-bedb-730f1fb5be1e?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [36] https://substack.com/redirect/ab5a6be9-7341-4023-8d40-b3c56cbc73f3?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [37] https://substack.com/redirect/9804a8f5-dcec-42f7-a846-1265ec71b8c9?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [38] https://substack.com/redirect/1d798a73-5a33-47d3-84a1-5d3b99290667?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [39] https://substack.com/redirect/0dd59470-1157-4c66-8cd7-50438f8994ec?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [40] https://substack.com/redirect/9f1bbb55-8d99-4b09-9472-45e1e7b5f04a?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [41] https://substack.com/redirect/806166de-9769-4e75-9f42-ff42156a2e7c?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [42] https://substack.com/redirect/72821c9c-5074-490b-a729-6140aa90954c?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [43] https://substack.com/redirect/50931317-a8d0-4149-ba7b-3d58fbcd98d4?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [44] https://substack.com/redirect/d2246cdf-ed28-4d26-865a-15aa40b6c521?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [45] https://substack.com/redirect/f18006f0-032f-4c01-b892-1f56c3f09b01?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [46] https://substack.com/redirect/d1a9fa36-6d35-4ff4-8e75-7386be17f7a5?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [47] https://substack.com/redirect/801a9fa1-b43f-4ba5-b9d8-4aedc5f11e3a?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [48] https://substack.com/redirect/c156c5dd-883f-435b-9c87-9498b134de21?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [49] https://substack.com/redirect/d4fec0e8-7ad1-464d-afde-e54029b1b381?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [50] https://substack.com/redirect/17625875-766d-456a-bbcf-94a95465bf07?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [51] https://substack.com/redirect/61b5d17f-652e-48af-ab3b-f4a9bb191d83?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [52] https://substack.com/redirect/4c8bd523-1d98-4bb2-b1cb-d41798f3a69f?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [53] https://substack.com/redirect/61b5d17f-652e-48af-ab3b-f4a9bb191d83?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [54] https://substack.com/redirect/b887ccf3-6ade-4d21-b335-f73ed6c8a53b?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [55] https://substack.com/redirect/5242433c-1d5d-4cd9-912a-d082b978873d?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [56] https://substack.com/redirect/b4007d7e-af65-49b1-9304-7ca5f5b54dca?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [57] https://substack.com/redirect/da3f1d63-f2f1-4740-b1e9-08379b3f22c2?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [58] https://substack.com/redirect/36bc0fdc-25e3-459a-b9b5-4967b2ca1766?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [59] https://substack.com/redirect/2da556ca-c20f-4260-9045-0cedb5396fb8?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [60] https://substack.com/redirect/680d8983-c44a-4318-a576-49b54b0bad13?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [61] https://substack.com/redirect/a1128a58-2484-49b0-b0b5-5ecda8417c19?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [62] https://substack.com/redirect/01e29d36-b605-4f0f-8166-ed609fdf92ac?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [63] https://substack.com/redirect/196b8fca-b358-46a4-bc66-6e564ac7a898?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [64] https://substack.com/redirect/6ddb306d-3c9c-4b4d-a879-8a09cad3de7e?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [65] https://substack.com/redirect/32e5ca77-81ed-4a56-bcd1-396130a0ed9a?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [66] https://substack.com/redirect/13794147-fa3f-48cb-977e-b1363f6faf77?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [67] https://substack.com/redirect/1ce538b4-1aee-4aca-aeda-eabb6e40271b?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [68] https://substack.com/redirect/08740e02-650a-414f-8283-40ff563cc3ac?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [69] https://substack.com/redirect/4a0a16ee-bff8-41d2-b967-5ac9148f371a?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [70] https://substack.com/redirect/755748a2-c796-4b01-8304-250a565bf224?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [71] https://substack.com/redirect/38badd07-e498-4186-8b5d-c3ecae852693?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [72] https://substack.com/redirect/aa623942-0daf-4008-b04d-2b837b81ce7d?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [73] https://substack.com/redirect/720d01f2-95bd-4c48-aeff-232315f4c4a7?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [74] https://substack.com/redirect/7bbed647-de0d-4622-a061-e7e7f021d9ab?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [75] https://substack.com/redirect/ae23816e-f3be-4d5d-b6ed-c195d703771f?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [76] https://substack.com/redirect/5c061372-0b75-46ad-841c-3a5008d92345?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [77] https://substack.com/redirect/a38d739e-8e42-4a4b-b08f-b057d7713ed6?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [78] https://substack.com/redirect/fcacae3e-87ea-4d82-acc3-5b93d0b8052f?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [79] https://substack.com/redirect/357514d5-c83a-44f9-9bc9-1665fab23232?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [80] https://substack.com/redirect/d96c6183-f420-4bf2-baac-86cfb867866e?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [81] https://substack.com/redirect/070dd345-15e8-4f52-8acc-9e705ae94846?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [82] https://substack.com/redirect/c1237ca1-4578-4833-b023-d22239c5dec4?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [83] https://substack.com/redirect/37906664-7cc5-4678-9abd-fd3df82ea3c1?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [84] https://substack.com/redirect/e7e155f8-da40-4ffa-8aed-d899d72d1485?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [85] https://substack.com/redirect/605f185f-5d1d-4b82-acee-18a5c962127f?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [86] https://substack.com/redirect/5bf5966c-f781-44be-b0ef-09d14625ee23?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [87] https://substack.com/redirect/429a9cd7-f35e-4e78-8c33-5d7404f78fef?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [88] https://substack.com/redirect/816721d2-cea6-4552-bb95-d1ce51890767?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [89] https://substack.com/redirect/fb63a900-d3d8-49fe-81a9-a54717de420d?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [90] https://substack.com/redirect/1eaff6cc-3baf-4135-a0e9-d0b35914c77d?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [91] https://substack.com/redirect/e9175811-383d-43aa-b556-f7da5640305b?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [92] https://substack.com/redirect/3e36ba0f-168b-4658-9a21-7c3d7ea72780?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE
• [93] https://substack.com/redirect/22e5f46e-c0c4-4a29-9fd2-ace6cd7e0c2b?j=eyJ1IjoiNnFlZWh0In0.mj92BjIKLPtgM6aGb3Z5Km0aFgCAo08wXqvJ3k6bBeE