AI 开发者日报

• FrontierCode 提升了编码评估的标准：Cognition 推出了 FrontierCode，这是一个全新的基准测试，其核心目标是评估代码是否真正可合并，而不仅仅是单元测试通过。这些任务是与开源维护者共同构建的，每个任务耗时 40 小时以上，并从回归安全性、代码整洁度、作用范围、测试正确性和可维护性等多个维度进行评估。最引人注目的结果是，最佳模型 Opus 4.8 在最难的子集上得分仅为 13% 左右——远低于 SWE-Bench 类评估中常见的 50% 以上水平，这表明编码问题远未像流行基准测试所暗示的那样“已被解决”（Cognition 公告，Scott Wu 的总结，swyx 的解读，theo 关于方差/可复现性的质疑，Cognition 的回应）。

• “循环机制”正成为智能体控制的主流隐喻——但需谨慎：当天最响亮的实践主题是，编码智能体应被赋予清晰的目标、验证标准和迭代结构，而非一次性提示词。热门案例包括 dzhng 的“不要用循环，要设计状态机”、Claude Code 关于自动模式、例程和验证的回顾、bcherny 的讨论串、OpenAI Codex 关于结果优先提示词的技巧 和 Approve-for-me 默认设置，以及 LangChain 开源的“评分标准”。但多位实践者对天真的循环炒作提出了反驳：Omar Sar0 和 Greg Neubig 强调，在易于验证的领域之外，人工检查点仍然至关重要，而 Hamel Husain 则开玩笑说要屏蔽这个词。

• 智能体在验证和编排方面的人机工程学正在改进：整个技术栈的产品变化反映了这一转变。ClaudeDevs 为 MCP 连接器开发者添加了可观测性仪表板，包括采用率、延迟和错误视图。MagicPath 推出了 Builder 计划，用于外部智能体工作流和多人在线画布编辑。LangSmith Sandboxes 和 Modal 的沙箱扩展故事 都指向了相同的基础设施趋势：智能体需要隔离、可检查、长时间运行的环境。

• 实际使用模式正在趋于稳定：最有力的操作建议集中在可衡量的结果、有限的自主权和线程卫生上。Angaisb_ 警告过长的 Codex 线程会降低性能，而 reach_vb 则报告了单线程上下文积累的成功经验。这种分歧本身就是有价值的信号：当前智能体的性能仍然在很大程度上受到工具链行为和工作流选择的影响，而不仅仅是基础模型的质量。

• Kimi 同时推出了更强的编程 Agent 和桌面 Agent 产品：Moonshot 对其开源编程 Agent Kimi Code 进行了重大更新，新增了一行命令 CLI 安装、拖拽视频作为编程上下文、ACP 支持、插件以及 IDE 集成（公告）。同时，它还发布了 Kimi Work，这是一款桌面 Agent 产品，支持多达 300 个本地子 Agent、通过浏览器扩展实现浏览器操作、面向金融领域的工具访问以及持久化记忆（产品发布，桌面版可用性）。
• Google 在高效本地部署上发力：Gemma 获得了多项显著升级。新的 QAT Gemma 4 检查点据称在保持性能的同时，内存占用减少了约 4 倍，而采用移动端量化格式的 Gemma 4 E2B 仅需约 1GB 空间（@_philschmid）。此外，Gemma 4 MTP 已被合并到 llama.cpp 中，与 QAT 检查点配合使用时，可实现更快的解码速度（Gemma 团队）。llama.cpp 还增加了视频输入支持，扩展了本地多模态应用场景。
• 开源/开放权重竞争依然激烈：Artificial Analysis 报告称 MiniMax-M3 在其智能指数上得分为 55，一旦权重发布，它将成为领先的开放权重模型。M3 新增了原生多模态和 100 万 token 上下文窗口，在 GPQA/MMMU-Pro 上表现强劲，但在对幻觉敏感的评估中明显存在弃权现象。与此同时，norpadon 宣布了针对 Apple 硬件优化的量化版 Qwen3.5 检查点。
• 服务基础设施正从文本大模型扩展到世界模型和全模态模型：vLLM-Omni 0.22.0 新增了对 NVIDIA Cosmos 3 世界模型的 Day-0 支持、机器人服务 API、TTS 模型（如 Qwen3-TTS 和 VoxCPM2）、更快的图像/视频服务，以及更广泛的量化/硬件覆盖（发布说明）。这反映了从纯文本推理栈向通用多模态服务的更广泛趋势。

• 智能体评估正从合成任务转向真实环境遥测：Arena 推出了 Agent Arena，这是一个基于超过 100万次真实会话 的排行榜，采用 因果追踪 而非投票机制，来估算编排器/工具链在五个信号维度上的处理效果：确认成功、表扬 vs 投诉、可引导性、bash恢复能力以及工具幻觉（概述，方法论详解）。该方法论是否完全成立还有待观察，但这无疑是迄今为止利用实际使用轨迹对已部署智能体进行基准测试的最清晰尝试之一。
• 专业化基准测试不断向新的输出领域扩展：Hugging Face 和 Mecado 发布了 CADGenBench，这是一个用于从图纸或 STEP 修改中生成和编辑 工程级3D CAD零件 的基准测试，其评估指标涵盖几何形状、拓扑结构、接口兼容性和CAD有效性（发布帖，Thom Wolf 总结）。这是一个有意义的转变：评估正在从文本/代码扩展到结构化制品，在这些领域中，正确性体现在物理和几何层面。
• 一个反复出现的论点：好的基准测试会变成训练流水线：Ofir Press 认为，最好的基准测试是可扩展的，并且根植于 真实世界爬取的数据源，使其不仅适用于测量，也适用于数据生成。这一观点在 FrontierCode 和 Agent Arena 中都有体现：基准测试不再是静态的记分牌，而是正在成为 产品和强化学习改进的反馈循环。

• Google 扩展了AI包装、搜索和开发者生态：Google 发布了功能更强的 NotebookLM，为 Ultra 订阅用户提供智能体对话、更强的推理能力以及更多输出格式（发布链接）。同时，Google AI Plus 的定价从 $7.99/月降至 $4.99/月，存储空间翻倍至 400GB（定价更新）。在平台层面，Google 重点展示了搜索的重大升级，包括多模态搜索以及将 Gemini 3.5 Flash 设为 AI 模式的新默认模型。
• 苹果 WWDC 的 AI 故事聚焦于集成，而非前沿领先：围绕 WWDC 的评论主要集中在重建的 Siri AI 上，它具备屏幕感知、应用操作、个人上下文理解以及更好的语音交互能力，同时也有关于 欧盟可用性 和硬件门槛的担忧（kimmonismus 实时线程，区域限制说明）。一个技术上的亮点来自 awnihannun：苹果的设备端模型据称是一个 200亿参数的查询路由架构，每次查询时从 NAND 加载专家模块到 RAM，这是一种针对设备限制优化的非标准设计。

• Anthropic 将 AI 在科学领域的一大核心障碍归结为基础设施不匹配：其最新科学博客指出，AI 在编程领域的发展远快于生物学领域，原因在于生物数据库和工具并非为智能体使用而设计；瓶颈不在于原始智能水平，而在于与智能体兼容的科学基础设施（Anthropic 博客推文）。这一观点与更广泛的关于环境/工具标准化的呼声不谋而合。
• 开源强化学习与环境协议正成为协作枢纽：OpenEnv 已移交至一个由 Hugging Face、Meta-PyTorch、Reflection、Unsloth、Modal、Prime Intellect、NVIDIA 等组成的联盟。其核心理念是：前沿实验室通过紧密耦合的工具链共同训练模型，而开源生态系统则需要一个模型、工具链、环境和训练器之间的共享协议层。
• 面向智能体的持续学习正重新成为一个实际的系统性问题：Hivemind 宣布推出一个系统，可将 Claude Code、Codex、Cursor 和 Hermes 等智能体的运行轨迹转化为可复用的技能，并声称在多种场景下取得了可衡量的性能提升。与此相关，Nando de Freitas 发布了一篇长推文，概述了一个研究计划，核心是从交互结果而非单纯的 token 序列中学习。
• 优化器讨论异常活跃：多条推文争论 Muon 与 Shampoo 是否存在本质区别，Arohan 暗示存在一种优于 Shampoo 的优化器，Keller Jordan 则公开对 Shampoo 和 Spectral Descent 进行了基准测试。这些争论背后的实质是：业界对优化器层面的性能提升重新燃起了兴趣，将其视为真正的技术前沿杠杆，而不仅仅是基准测试中的噪声。

• Signal 反对英国设备扫描要求：互动量最高的技术相关推文是 Signal 反对英国政府要求实施设备端扫描及基于年龄验证的内容审查。这更多涉及隐私/安全政策而非 AI，但与客户端推理和平台信任直接相关。
• OpenAI 公司方向与流动性：Sam Altman 分享了 OpenAI 的当前计划，随后不久 OpenAI 宣布已秘密提交 S-1 文件。对 AI 工程师而言，关键战略意义在于：OpenAI 和 Anthropic 目前似乎都在保留 IPO 选择权的同时，加速扩充产能和产品广度。
• NotebookLM 和 FrontierCode 成为当日最大产品/评测发布：NotebookLM 的升级、Kimi Code、Kimi Work 以及 FrontierCode 主导了技术讨论，其中 FrontierCode 尤其重塑了关于"好的编码性能"应该意味着什么的讨论。

/r/LocalLlama + /r/localLLM 回顾

1. 消费级硬件大模型推理更新

• llama.cpp 已合并 Gemma 4 MTP 支持（热度：1097）：llama.cpp 合并了 PR #23398，通过 --spec-type draft-mpt 和草稿/辅助 GGUF 模型，增加了 Gemma 4 多 token 预测（MTP） 支持，为支持的 Gemma 4 变体实现了推测式解码。有用户报告称，在 RTX 4070 Super（12GB VRAM）上使用 Unsloth QAT GGUF 和 MTP 辅助/草稿 Q8_0 GGUF 模型，配合 --spec-draft-n-max 4，Gemma 4 12B 达到了 140 tok/s 的速度；该 PR 的 mtp-bench 结果显示，与非 MTP 相比，密集模型的吞吐量提升约 >2 倍，而 MoE 变体在作者的系统上并未加速。该实现据称可复现 Gemma 团队 AIME-26 性能，31B 和 26B-4B 模型约为 ~87%；E4B/E2B 变体仍不支持，多 GPU 可能需要配合 -sm layer 使用 --spec-draft-device。评论者对 QAT + MTP 的组合充满热情，并特别感谢贡献者 u/am17an 完成了 llama.cpp 的集成。

  有用户报告称，在 RTX 4070 Super（12GB VRAM） 上，使用新合并的 llama.cpp MTP 支持、Unsloth QAT GGUF 权重和 MTP 草稿模型，Gemma 4 12B 运行速度达到 140 tok/s。他们的命令使用了 --model-draft、--spec-type draft-mtp、--spec-draft-n-max 4 以及较大的 --ctx-size 131072，模型链接指向 Unsloth QAT GGUF 和 MTP 辅助/草稿 Q8_0 GGUF。

  • 在 NVIDIA GB10 Grace Blackwell / Asus Ascent GX10 上的一项基准测试中，测试了 Gemma-4-31B-it-Q8_0.gguf 与 gemma-4-31B-it-MTP-Q8_0.gguf，Q8 被描述为"基本等同于全精度"。未使用 MTP 时，吞吐量稳定在 6.2–6.4 tok/s；使用 --spec-type draft-mtp --spec-draft-n-max 7 后，吞吐量根据任务不同提升至 15.7–31.2 tok/s，通过 --reasoning on 保留推理模式，实现了约 3–5 倍 的加速。
  • 详细的 MTP 基准测试显示了任务相关的接受行为：翻译达到 31.2 tok/s，草稿接受率为 0.699；摘要达到 29.4 tok/s，接受率为 0.645；而创意写作则低得多，仅为 15.7 tok/s，接受率只有 0.277。这表明 Gemma 4 MTP 加速高度依赖于工作负载，确定性或约束性任务比开放式创意生成更能从推测式多 token 预测中受益。

• 你不需要 GPU 也能运行 gemma-4-26B-A4B（热度：902）：原帖作者报告在 Intel i5-8500 + 32GB 内存、Linux 系统上，通过 KoboldCpp 纯 CPU 运行 Gemma 26B-A4B，在没有 GPU 的情况下达到了约 7 tok/s 的速度；此前 ~12B 的密集模型也可用但速度较慢。评论者指出，关键技术原因在于该模型虽然总参数量为 26B，但实际活跃参数仅约 4B，因此只要量化后的权重能放入系统内存，CPU 推理就是可行的。评论普遍认为，强大的本地推理不一定需要云访问或高端 GPU 设备，不过也有评论者指出，即使是便宜的二手 8GB VRAM GPU 也能带来大幅速度提升。

  • 评论者指出，Gemma 26B-A4B 在 CPU/消费级硬件上相对可行，是因为尽管总参数量较大，但每个 token 的活跃参数仅约 4B；主要限制在于将模型权重放入系统内存，而非需要高端 GPU 算力。
  • 一个技术上的注意事项是，即使是 8GB VRAM 的小型二手 GPU 也能显著提升可用性，有评论者估计，假设模型或活跃工作集能从 GPU 加速中受益，性能可比纯 CPU 执行提升约 5 倍。

• 小米声称在标准 8-GPU 服务器上实现 1T 模型 1000+ TPS（热度：818）：小米 MiMo 声称 MiMo-V2.5-Pro-UltraSpeed 在单个"标准"8-GPU 商用节点上，为 1T 参数 MoE 模型实现了 1000+ tokens/s 的解码吞吐量——据称可达约 1200 tps。这得益于 TileRT 持久化/融合/流水线内核，以及接受长度约为 4.3–6.3 个 token 的 DFlash 推测式解码。关键的模型端优化是选择性 MXFP4 QAT：小米表示，直接应用 FP4 会损害推理/代码能力，因此他们仅量化 MoE 专家层——即参数的主体部分和最能容忍量化的模块——同时将其他模块保持原始精度，从而在质量损失最小的情况下降低带宽压力。该访问权限定位为 2026 年 6 月 9 日至 23 日 的有限企业/API 试用，促销定价为 3× MiMo-V2.5-Pro。评论者关注的是"标准 8-GPU 节点"是否定义不清——询问使用了哪些 GPU——并将这一结果视为压缩稀疏/MoE 架构正变得越来越经济的证据，尽管此前存在质疑。有评论者认为，真正的"Token 寒冬"并非模型能力问题，而是消费级硬件的稀缺性和定价问题，同时数据中心垄断了 GPU 用于低效推理。

  • 评论者强调，小米报告的 1,000+ TPS 在很大程度上依赖于未明确的"标准 8-GPU 服务器"配置，有人质疑这些 GPU 是数据中心级显卡还是消费级 GPU（如 RTX 5090/3090），这使得在没有硬件细节的情况下难以评估该吞吐量声明。
  • 一个关键技术点是小米对 MiMo-V2.5-Pro 的选择性 FP4 量化策略：并非对整个模型应用 FP4，而是仅量化 MoE 专家层，这些层包含大部分参数且更能容忍量化，同时将非专家模块保持原始精度。据称，FP4 QAT 在减少模型大小和改善内存带宽利用率的同时，保留了推理/代码能力。
  • 发布的权重已上传至 Hugging Face：XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash。还有评论者质疑架构表示法，询问该模型是否实际上是 1T-A1B，暗示这是一个总参数量极大的 MoE 模型，但每个 token 的活跃参数数量要小得多。

• Gemma 4 聊天模板现已支持 preserve thinking（热度：447）：Google Gemma 团队已更新官方 google/gemma-4-31B-it 聊天模板，支持 preserve_thinking，根据 Hugging Face 上 google/gemma-4-31B-it 的相关讨论。该帖子还记录了多模态 31B 指令模型的实际推理/部署路径，包括 transformers 的 pipeline / AutoProcessor + AutoModelForImageTextToText，以及通过 vLLM 和 SGLang 提供 OpenAI 兼容的服务。评论者将官方 preserve_thinking 支持视为对早期社区"售后"聊天模板修改的验证，有人表示他们"知道它效果很好"。几位用户希望有更大的 Gemma 4 124B MoE 变体，以更好地利用更新后的模板，特别是用于智能体编码工作负载。

  • 用户注意到，官方 Gemma 4 聊天模板似乎正在添加 preserve_thinking，这是一种有些人已通过售后/自定义模板启用并发现效果良好的行为。技术上的说法是，在对话轮次之间保留隐藏/结构化推理对于 智能体编码工作流 特别有用，因为工具使用和多步上下文连续性至关重要。
  • 有评论者提醒，该更改可能尚未实际生效：他们报告称这仍然是一个 开放的 PR，尚未合并，并且模型文件大约 21 天 没有更新。这表明用户在假设官方 Gemma 4 制品中已提供 preserve_thinking 之前，应先验证模板版本。

• 一场针对 Claude Code 的活跃攻击正在植入后门。如果你使用 npm，你的凭据可能已经泄露。（热度：1039）：该帖子声称存在一场针对 @redhat-cloud-services 包的活跃 npm 供应链攻击（涉及 32 个包，周下载量约 11.7万），以及后续的 "Phantom Gyp" 攻击浪潮（57 个包，月下载量约 64.7万）。恶意安装/构建钩子会窃取凭据，并通过 ~/.claude/settings.json 中的 Claude Code SessionStart 钩子和 .vscode/tasks.json 中的 folderOpen 任务实现持久化。引用的来源包括 Microsoft 的 Miasma 分析报告、StepSecurity 关于 binding.gyp 滥用 的文章，以及 Snyk 的清理指南。推荐的应急响应顺序为：检查依赖树/锁定文件中是否包含受影响包/版本，检查编辑器持久化机制，在轮换密钥前先断开连接并清理，然后从可信机器上轮换 npm/GitHub/SSH/云/Kubernetes/Vault 凭据，审计 npm 发布历史/GitHub 安全日志/自托管运行器/OIDC 信任关系，并临时使用 npm install --ignore-scripts 配合锁定文件完整性哈希和最小权限 CI/CD 令牌。热门评论多为操作层面：一位评论者感谢作者，另一位则询问这是否与之前的事件相同，还是另一起新的攻击活动。

一份详细的修复清单列出了可能受影响的 npm 包：@redhat-cloud-services、@vapi-ai/server-sdk 和 ai-sdk-ollama，建议使用 npm ls 检查并审查大约 6月1日 和 6月3-4日 发布的版本。指南强调 在轮换令牌之前先进行隔离：检查 ~/.claude/settings.json 中是否有意外的 SessionStart 钩子，以及 .vscode/tasks.json 中是否有可疑的 folderOpen 任务，然后从可信机器上断开连接并清理，再轮换凭据。

• 该评论描述了疑似在 GitHub/npm 供应链层面传播的蠕虫行为：检查 GitHub 安全日志 中是否有意外的仓库、GitHub Actions 工作流、自托管运行器，以及 "Miasma" 或 "Shai-Hulud" 等引用。它特别指出 GitHub Actions OIDC 信任关系 是高价值的轮换目标，并称这据称是 Red Hat 被攻破的漏洞，同时建议审查 npm 发布历史中是否有未经授权的重新发布版本。
• 讨论的缓解措施包括使用 完整性哈希 锁定依赖项，使内容不同的重新发布包在执行前即失败；以及临时使用 npm install --ignore-scripts 来阻止恶意安装钩子、binding.gyp 和 node-gyp 构建时执行。另一位评论者质疑为什么攻击者能够直接推送到 Red Hat 仓库，认为受保护的 main/master 分支应该要求基于 PR 的合并并有多人审批。

Anthropic 今天更新了隐私政策，其中有一个所有 Claude 用户都需要了解的特定条款（热度：784）：原帖称 Anthropic 于 2026-06-08 发布了修订后的 隐私政策，于 2026-07-08 生效，将执法披露的依据从外部法律程序改为基于 Anthropic 内部认为必要的 "善意相信"。帖子认为，这给自动化安全分类器的误报带来了风险——尤其是角色扮演、虚构内容、叙事语境中的威胁或心理健康倾诉——因为这些对话可能在没有法院命令、用户通知、申诉途径或明确证据门槛的情况下被上报给执法机构。原帖还将此与 OpenAI/Mistral 的政策进行了不利比较，并提出了英国 GDPR/DBS 方面的担忧，但帖子中未提供直接的政策变更链接；一位热门评论者明确要求提供来源 URL。热门评论普遍持负面态度，认为这一变化是重大的隐私倒退，是更广泛 "劣化" 趋势的一部分；一位评论者表示，由于成本高、行为受限和隐私削弱，他们将转回 Codex。另一位评论者要求提供链接以核实所声称的新政策。

• 一位评论者将 Anthropic 的政策变化与更广泛的 AI 提供商注意义务问题联系起来，引用了针对 OpenAI/Sam Altman 的诉讼，其中家属声称一名大规模枪击者的 ChatGPT 使用曾在 内部被标记但未向警方报告（BIV 报道）。这意味着提供商可能越来越多地保留在内部安全系统识别出严重风险时监控/上报用户活动的权利。
• 另一位评论者认为，对于高严重性的滥用行为，Anthropic 的上报可能是合理的，并特别引用了 Anthropic 自身的 生物风险红队工作（Anthropic Red Teaming: Biorisk）。这将对隐私政策的担忧置于具体的威胁模型背景下，例如 AI 辅助生物危害，其中用户内容审查或报告可被定位为一种安全控制措施。

Claude 新的使用限制太疯狂了。（热度：1122）：截图（图片）显示一个在 Opus 4.8 上使用 1M 上下文的 Claude 编码会话，在约 12分54秒 内消耗了 110万 tokens，一次提示后用户仅剩 21% 的 5 小时限制。帖子认为，将 Opus + 1M 上下文 + UltraCode 组合使用会成倍增加 token 消耗，因为多个并行代理可能各自读取大量上下文，使得一次请求表现得像多次昂贵调用，而非单次高效的推理过程。评论者大多反驳了这一抱怨，认为在使用最昂贵的模型/上下文/代理模式组合时这是预期行为——有人用 "用挖掘机碾蚂蚁" 来类比。他们强调 UltraCode 本身就不是 token 高效的，应保留给狭窄的高价值任务，而非作为默认的 "最大思考" 模式使用。

• 多位评论者认为，高消耗是意料之中的，因为用户组合了最消耗 token 的设置：Ultra Code、高 "思考" 级别和大上下文。技术要点是：Ultra Code 不是 "最大思考" 的 token 高效替代方案；它专为更狭窄的任务类别设计，在这些任务中可以接受更高的 token 消耗和成本。
• 一个反复出现的观点是，开发者需要根据任务复杂度和成本约束来选择模型/工具配置。评论者将这个问题框定为优化问题：对日常任务使用过于强大的编码模式必然会耗尽限制，因此工作流应保留 Ultra Code 这类模式，仅用于额外推理/上下文预算能显著改善结果的场景。

• Mythos 5：我们还没准备好（热度：1348）：有帖子声称 Anthropic 的 "Mythos 5" 测试模型在 SVG/代码驱动的视觉生成、前端/UI 创建、游戏、网站，甚至代码生成音乐方面异常强大，某些输出有时需要几分钟才能生成。该帖子还引用了 Anthropic 内部测试结果：训练代码优化加速比高达 52×，而熟练人类仅约 4×。帖子预计公开版本将 价格昂贵，且相对于测试模型很可能被削弱（nerfed）。热门评论大多持怀疑或讽刺态度：评论者质疑 "SVG 生成过于危险" 的说法，一位评论者认为唯一可信的说法是任何公开模型都将是降级/削弱版本；另一位评论者则对预期的高成本表示反对。

一位评论者强调了对公开版本可能与内部测试版本存在显著差异的怀疑，并引用了 "公开版本很可能是当前测试模型的削弱版" 这一说法。其技术含义是：如果 Anthropic 在公开发布前应用了训练后限制、能力门控或安全/性能权衡，那么关于 Mythos 5 的任何报告能力声明可能无法迁移到生产环境中。

• 一个实质性的建议是：如果 Mythos 5 的运行成本显著更高，Anthropic 可能需要推出 更小、更便宜、领域专用的模型，而不是依赖单一的通用前沿模型。这反映了一个常见的部署权衡：专用模型可以在受限领域内保持任务性能的同时，降低推理成本和延迟。

Ideogram 4.0 对角色和 IP 的理解对于开放模型来说令人惊叹（热度：1081）：该帖子报告了 Ideogram 4.0 在本地运行时的强大零 LoRA 角色/IP 召回能力，使用 ComfyUI 中的 INT8 模型变体，分辨率 1440×1024（约 1.5 MP），配合 Kijai 的 Ideogram 4 Prompt Builder KJ 节点 和 SilverOxide 的工作流（Pastebin）。作者还强调了 Ideogram 4.0 的修复（inpainting）质量，可选使用 ComfyUI-Inpaint-CropAndStitch，并分享了一个包含 Mario/Sonic 的提示词 JSON，使用了结构化字段如 high_level_description、style_description 和基于边界框的 compositional_deconstruction。评论者惊讶地发现样本 没有使用任何 LoRA，其中一位询问 Ideogram 4.0 的 LoRA 训练是否已经可行。另一位评论者则称赞了特定的 IP/细节处理，例如 "来自《塞尔达传说》中林克的便条"。

• 原帖作者报告称，Ideogram 4.0 无需 LoRA 即可再现可识别的角色/IP 概念，称这是他们尝试过的最强的开放模型。图像在本地 ComfyUI 中生成，分辨率为 1440x1024（约 1.5 MP），使用 INT8 版 Ideogram 4.0 模型，以及 Kijai 的 Ideogram 4 Prompt Builder KJ 节点 和 SilverOxide 的工作流（pastebin）。
• 分享的一个技术工作流细节是使用结构化提示词 JSON，包含 high_level_description、style_description 和 compositional_deconstruction 字段，以及对象级别的 bbox 区域和描述。示例提示词明确使用边界框、手势、面部表情和背景系列上下文来放置 Mario 和 Sonic，表明 Ideogram 4.0 受益于空间分解的提示词。
• 原帖作者还指出，Ideogram 4.0 在修复（inpainting）方面表现良好，通常无需清理，但他们在需要时使用 ComfyUI-Inpaint-CropAndStitch 进行蒙版面部/细节修复（GitHub）。这实现了一个实用工作流：先在较低百万像素下生成，然后选择性地修复问题区域以获得更高保真度。