Gamea | 飘逝的风修改

2026-09-27 00:00:00

最近我在电脑前越来越多地用语音输入，主力工具也从微信语音输入法换成了开源的 OpenLess。用了一段时间后，我想更严谨地回答一个问题：面对本地、系统和云端这么多种语音识别方案，哪一种更适合我？能不能本地直接跑模型免费畅用？本文我将回答这个问题，针对我的应用场景找个最合适的方案，顺带了解下行业当前各模型的实力。

背景

不知道这算哪种性格，我用一个东西时，不把它研究清楚就不安心。用 OpenLess 时，我发现它提供了很多 ASR 选择。这可难住了我这个选择困难症人士，我非得给它们分个强弱。

可是，该从哪些角度判断一个模型是否适合我呢？用了一段时间的语音输入后，我大概知道自己更关注哪些场景。比如在工位上，周围有各种杂音，模型还能不能准确识别？又比如晚上在家，孩子已经睡了，我只能轻声说话，甚至接近耳语，模型还能不能识别到位？

我本来想写一篇文章，系统地聊聊 OpenLess：比如如何选择语音识别模型（ASR），它的润色模型以及润色方案等，还有 OpenLess 的使用。但这个语音识别的评测比较独立，而且也算是很重要的一个模块，我们就先单独聊一下。

这次只比较 ASR 原生 API 直接返回的识别结果，不经过润色模型。OpenLess 是我日常使用这些模型的入口，正式评测则把同一批录音交给各个 ASR 接口，方便比较和直接。

评测目标：测哪些模型？

我根据 OpenLess 所支持的模型，选了一些比较容易获取的，加入到测试目标里。目前已经囊括了几个大厂的模型，另外补充了本地模型。如果你像我一样用 macOS，可能也想知道 macOS 设备端语音识别效果怎么样，那就把它也加进来评一评。虽然免费，但要是效果不好，咱也不会用。毕竟咱也不是完全没要求的人，对吧？

下文统一使用第一列的名称，实际调用的模型或接口标识列在最后一栏。其中，豆包流式 ASR 对应 OpenLess 中的 Big ASR；腾讯混元 ASR 3.0 本次使用的是 preview 版本。

评测建模：什么叫“适合我的 ASR”

有了上面这份模型列表，那接下来怎么测试它们呢？作为一个程序员，我日常对语音的使用应该和一般人有些不一样，比如会穿插一些专业术语，有时难免中英混杂。一般和同事沟通时，微信或豆包语音输入法的识别效果其实也勉强够用，那是因为众所周知，人的纠错能力是超强的。但在编程或与 AI 交互时，虽然 AI 有一定的纠错能力，识别错误仍可能误导它。我也了解了一些 ASR 的评测体系和指标，比如 CER 等错误率指标，确实有一定参考价值。但我觉得，按自己的使用场景设计评估维度，更适合这次评测，所以没有直接照搬现成的评测方案。以下是我的评估维度：

这些维度覆盖了我过去个把月使用语音输入时遇到的主要场景，也包括一些特殊问题：比如模型出现幻觉（没说却出现）、漏掉部分内容（掉句），或者不支持长语音（说了一大段却没转成功的悲伤）。还有，有些模型在正常音量下表现不错，但一旦轻声细语，识别准确度就会大打折扣。

评测用例：具体用哪些内容来验证？

最开始，我用 OpenLess 日常使用中留下的一些历史记录来跑评测。这种方式很容易上手，录音也都保存着，内容比较贴近日常。但等我想清楚该从哪些维度评估模型后，就发现仅靠这些历史记录还不够。主要有两个问题：

1. 用例完全取决于我的使用场景，不够通用，各类场景的比例也不好控制，难以全面展示模型的表现。
2. 每段已有录音仍需要重新听一遍，整理并校对准确的参考文本，工作量也不小。

所以我和 AI 一起重新设计了评测方案。我们基于测试目标，创建了一个网页，展现各个场景的用例，并由我来一一录音。我尽量按提示文字来读，再回听确认参考文本。这样就不用从零整理每段录音的文字了，能省不少事。

用例覆盖以下八类场景，每类十条，共八十条：

评测结果：是时候见证各位的实力了

第一轮：原生基本功比拼

我把测试分成了不加热词和加入热词两轮，因为有些 ASR 不支持热词，或者有些软件本身不支持上传热词。我们先看不加热词时，各个模型的原生识别能力如何。

注：表格中通过上下箭头表示是越高越好还是越低越好，帮助理解。

备注：总体 CER 使用 74 条共同可比较的录音，静音误输出和约 90 秒录音的完整性另列。

为了更直观地看出各模型的长处和短板，我把上面的结果整理成五星评级。★★★★★ 表现好，★★★★☆ 整体可用、有少量不足，★★★☆☆ 需要明显修正或取舍，★★☆☆☆ 有较大短板，★☆☆☆☆ 本场景不宜优先。星级越多越好，允许并列，五星也不代表零错误。

表中的“—”表示本次没有可评分的实时逐字反馈数据，不等于模型一定不支持实时识别。“结果等待速度”分别按整文件处理或流式音频发完后的等待评分，两种计时起点不同。静音只有 2 条、约 90 秒录音只有 1 条，相关星级只描述本批表现。

我让 AI 根据各模型的表现，结合我正常说话和轻声低语的使用场景，排出了下面的前三名。不知道这是否符合你的预期？

其实最开始我忽略了小米 MiMo 2.5 ASR，根本没打算把它加进来。这是因为最开始我收集了一下这些模型每秒钟的费用，这个模型定价还挺高的，我想你何德何能呢？但加进来以后还是让我挺惊喜的，确实有两把刷子。

第一名：小米 MiMo 2.5 ASR——优先作为内容识别基线

• 推荐理由： 共同集 CER 最低（4.01%）；轻声 9.59%，数字关键字段 10/10，普通长句 0.81%，B079（超长语音） 完整完成。多个有声场景同时较好，整段上传后的等待时间也短。
• 主要短板： 两条静音均输出“嗯。”；中英混合和个人技术词并非本批最强。此次验证的是整段上传后的识别，不把它当作已经验证的实时逐字方案。
• 适合怎样用： 优先用于明确有语音的整段口述。如果应用会经常提交静音，必须把这项误输出看作未解决问题，不能假定加一个未经测试的过滤器就能消除。

第二名：腾讯混元 ASR 3.0——优先作为实时交互候选

• 推荐理由： 共同集 CER 5.76%，个人历史场景 3.20%；轻声 10.10%，与普通发声相比退化较小；首字约 1.38 秒，静音不生成多余文字。数字关键字段核验也为 10/10，不应因数字转写格式吃亏。
• 主要短板： 一次连接超时；B079 超限未完成；Claude/cloud 的区分仍有误改。不能把它直接作为本次约 90 秒不切段输入的唯一通道。
• 适合怎样用： 更重视边说边看到文字、轻声输入和技术口述时，它比只看总体 CER 更有吸引力；若静音克制与实时反馈比整段准确率更重要，我会把腾讯混元 ASR 3.0 放到小米 MiMo 2.5 ASR 前面。

第三名：百炼 Fun-ASR——覆盖较均衡的实时候选

• 推荐理由： 中英混合 CER 6.03%，轻声 15.03%；数字关键字段 10/10，静音无多余输出，B079 完整完成；首字约 1.49 秒、音频发完后等待约 0.21 秒。它并不是每项都拿第一，但对本轮多种输入的覆盖更均衡。
• 主要短板： 共同集 CER 7.60%，在有声录音的整体识别和轻声识别上，表现都不及小米 MiMo 2.5 ASR 和腾讯混元 ASR 3.0；专名仍会误认，不能以“总体均衡”替代后续热词验证。
• 为什么第三名不是讯飞语音听写 V2.0 或本地 Qwen3-ASR 0.6B： 讯飞语音听写 V2.0 轻声更好，但本配置首段文字较晚且 B079 提前结束；本地 Qwen3-ASR 0.6B 共同集表现好、设备端运行，但轻声为 22.54%，处理等待也更长。在我已经明确关注轻声的前提下，百炼 Fun-ASR 更适合作为第三个综合候选。

AI 还找补了一下，但我觉得它说得对。实际选择按自己的需求调整：

• 如果离线是硬要求： 将本地 Qwen3-ASR 0.6B 放进前三，作为本批设备端首选；这来自其已验证的本地运行与更好的文本质量，不依赖云端价格假设。
• 如果基本不用轻声、主要是普通长句： 阶跃 StepAudio 2.5 值得重新优先考虑，普通长句和数字表现好、整段上传后的等待时间短；本轮没进前三，主要是轻声错识与误拒绝。
• 如果想保留一个百炼方案： 本轮更倾向百炼 Fun-ASR。百炼 Qwen3-ASR Flash 在普通长句和补充场景很好，但轻声明显更弱，实时首段反馈也更晚。

第二轮：支持热词模型比拼

在 OpenLess 里，热词是一个可能比较有用的、用来减少语音识别错误的机制。简单说，就是提前告诉 ASR 我可能会说到哪些专有名词，比如 Claude，让它更有机会听对名字；但也可能矫枉过正，把普通的 cloud 认成 Claude。

不过，这次参测的模型中只有部分支持热词，那就让它们再跑一轮。还是之前的八十条录音，加上热词以后，识别准确率会有多大变化？腾讯混元 ASR 3.0、豆包流式 ASR、百炼 Fun-ASR 和阶跃 StepAudio 2.5 都宣称支持原生热词，申请出战；AI 说 macOS 设备端语音识别也支持自定义词汇提示，那就让它一起参战吧。因为参加的选手比较少，我们很快就有了结果。

热词本身的收益与副作用

备注：以“16/26 → 24/26”为例，表示同一批可比较的目标词出现机会中，不加热词命中 16 次，加热词后命中 24 次，共 26 次；这里统计的是目标词有没有按期望拼写出现，不代表整句话都正确。“整句配对 CER”则比较同一个模型对同一批录音加热词前后的结果，统计范围与第一轮共同 74 条不同，不能直接相减当作热词收益。

这一轮我们也评个前三名吧。腾讯混元 ASR 3.0 的热词收益看起来比较明显。豆包流式 ASR 的结果则让我有点疑惑，一度怀疑是不是测试出了问题。我让 AI 再检查了一遍测试参数和配置，看起来没有问题，但结果仍出乎意料：我最期待它救回来的那些目标词，一个都没多认对。

第一名：腾讯混元 ASR 3.0

• 26 次目标词出现机会中命中 24 次，比不加热词时的 16 次明显增加；共同集 CER 约 6.08%，轻声 CER 8.55%，首字约 1.40 秒。
• 代价是本批整句配对 CER 由 6.07% 微升至 6.34%；B053 的 Claude/cloud 歧义未解决，B079 约 90 秒录音在原生配置下已知超限。适合较短的实时技术口述。

第二名：百炼 Fun-ASR

• 目标词命中由 12/27 提升至 19/27，配对 CER 7.80%→7.17%，轻声 CER 12.95%；B079 完整，静音两条无多余输出。首字约 1.64 秒。
• 专名仍未全部识别，且 B053 的普通 cloud 被热词拉向 Claude。若要在长音频和词表收益之间取得平衡，它是这一轮较稳妥的候选。

第三名：阶跃 StepAudio 2.5，仅限轻声很少的整段输入

• 普通长句、数字字段和 90 秒整段处理较好；目标词有 1 个新增命中，配对 CER 7.60%→7.35%。
• 10 条轻声中仅 8 条被接受，接受的 8 条 CER 仍达 51.79%；不应把它作为轻声输入的主方案。若轻声是刚需，本轮只支持优先比较腾讯混元 ASR 3.0 与百炼 Fun-ASR，第三名并无同级替代。

总结陈词

把第一轮和第二轮的结果汇总后，就得到下面这张表。可以看到，没有哪个模型在所有方面都遥遥领先，几个头部模型各有优劣。

注：图中沿用评测工具导出的简称，各模型与上文列表一一对应。

后记

到这里，我们的评测也结束啦。现在大概能看清各个 ASR 的表现了。不知道你看完以后会选择哪个呢？这期间我这里没有考虑价格因素。因为我们的输入量级并不多，成本很低，所以核心还是尽量减少返工和人工干预，能一次搞对最好。

至于开头那个“能不能本地跑模型”的问题，答案是能。本地 Qwen3-ASR 0.6B 在普通口语上已经够我用了，也不用支付云端 API 的调用费用。不过，本地运行要给模型留出足够的内存，实际占用和响应速度还取决于机器与运行配置。这一轮里，它的轻声识别较弱，等结果的时间也更长，所以暂时没有被我选成主力。想本地畅用，还是得接受一些硬件和等待时间上的取舍。

我自己的话，测完以后会优选腾讯混元 ASR 3.0，其次把小米 MiMo 2.5 ASR 和百炼 Fun-ASR 这两个作为备选。腾讯混元 ASR 3.0 是实时接口，配合 OpenLess 的实时文字展示，体感上会好一些。但它不支持超过六十秒的长录音。这块倒不是难点，之后的文章我会解决这个问题。

接下来，我打算聊一下如何用 OpenLess 做好语音输入。除了选对模型以外，还有一些小技巧，后面有机会和大家分享一下。欢迎点赞、关注、收藏哦～

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：爱折腾的风

2026-08-29 00:00:00

在 AI 横行时代，我拿出了几年前一个比较困难的问题，这次是对国内外旗舰模型的大考。从外面得来的评测终不可信，我要自己实战一次。这一次大家一样的起点，我适当辅助，看谁能从实战中解决问题。结果出人意料，过程中也有不少有趣的事情，遂记录之。

前言

我在几年前订阅了某个小朋友学习的 APP，里面有不少视频制作挺精良，但只有在手机里才能播放，有时候想让娃在电视上也能看这一块内容。这是我自己的订阅，却不能随时在电视上看，这点让我挺无奈的。

作为程序员，当然希望能自己动手解决这个问题。犹记得当时在深夜连续分析了好几个晚上，找到了一些不错的线索，但还没有得到完整答案。这个问题涉及不少专业领域的知识，我一边学习一边尝试，时间一分一秒地过去，直到我选择了放弃。回想起来当时的 AI，还在对话阶段，还没有现在这么火热的 Agent。现在 AI 的智能以及 Agent 自动化水平已经挺高了，我们去验证一个想法会非常便捷，是时候重新“翻旧账”了。

问题

这是一个什么样的问题呢？我觉得它可能对当前的智能体是一个挺不错的验证。

已知在手机中视频可以被离线存储和播放，但是实际上，离线下载的那些视频保存时是加密的。我们需要寻找一个解密方案，将视频分片解密并转换成一个可任意播放的视频。

为了验证 Agent 的能力，我给它们同样的提示词，并且在手机上安装好这个 App、缓存好目标视频，让它们帮我去实现我要的结果。我认为这里对 Agent 有这些挑战：

1. 让它去直接操作、访问我们的手机设备；
2. 让它自己去分析和解密；
3. 它需要自主去完成这个闭环；

提示词初始只有这样一句：

我本机连接了一台安卓设备，安装了一个叫 XX 的 APP，应用支持离线缓存一些视频，我已经将其离线缓存了，这些视频可能是加密的，现在你需要将这些离线视频解密并拷贝到本仓库来，供我在电脑上通过其它播放器观看，你可以选择其中一个跑通这个链路即可。

现在让我们一起来进行国内外各种 Agent 的大检阅吧，请准备好我们出发了！

本文仅记录在本人持有有效订阅的设备上进行的 Agent 能力观察，不提供内容文件、密钥、令牌、完整脚本或可直接复现的绕过步骤，也不鼓励将结果用于复制或传播受保护内容。

各模型实战结果

1号选手：Codex + GPT-5.6 SOL

最开始请出我最常用的 Codex 来看一下这个问题。我是有点担心，这个问题本身是否能够被接受？Codex 马上提出了抗议，哪怕我用几种方式尝试绕过也不行，当然可能我这个绕过的方式还是太低级了吧：）

有朋友说切换到旧的模型，比如 GPT-5.4 会好一些，我换了以后还是被拒了（悲剧）。

好吧，我能接受，听说你是有一些安全防护的，我也表示理解。不过 Codex 还是会回答一些外围问题，只是会努力避开涉及具体版权保护机制的处理。这样一来，因为它不会读取具体数值，有些分析就无法深入了。

虽然它不给我处理了，但从它的分析过程来看，它会主动查一些资料，并且能很精准地分析出一些外围信息。所以我觉得它的能力只是被封印了。后来解禁后我又重跑了一次，它其实完整交了卷，具体结果放到总结里再说。现在，我们先找一个没有被封印的。Elon Musk，不对，Grok！到你了。

2号选手：Grok Build + Grok 4.6

刚好这几天用一个月“白嫖”了三个月的 SuperGrok，而且听说 Grok 的限制会比较少，那很自然的，我该请它出山了。 它在这个过程中没有说过一句“不”，这让我挺意外的。当然它过程中也会犯一些错误，但它能够比较快地调整过来，而且对外部资料的认知和理解还是挺强的。

稍加引导（我也没做啥），它从日志中找到了破题的线索。整个过程还是很顺畅的，每一步的推断都有理有据。

它还总结了一下：

被它发现了一个歪门邪道，那我当然要增加难度，就继续问：

它给了我另外 3 种做法，我觉得挺有道理的，能干你就多干点，于是吩咐下去，继续尝试。但它遇到了失败，也很干脆地停下来了，还给了我两个方向，废话不多说，开 subagent 并行突进吧！

它居然又给我惊喜了，很快又找到了一个可行的方案。

在和 Grok 互动的过程中，让我感觉到它智商在线、行动敏捷，并且推进有理有据。对于这次的表现，我还是很满意的。这个 Grok 4.6 还真是值得一用，并且量大管饱，推荐推荐！

到这里我们可以整理一下。 AI 给我画了一个运行原理图，如下。我们可以先简单理解一下，这有助于我们后面看其他 Agent 是怎么“表演”的。

为了更好地理解这个问题的难度，我们可以用保险箱和钥匙来类比。

• 加密视频：保险箱
• ContentKey：保险箱钥匙
• CipherContentKey：被锁在钥匙盒里的保险箱钥匙
• overlayKey：钥匙盒的钥匙
• overlayIv：打开钥匙盒时必须匹配的密码学参数
• media IV：真正打开保险箱时使用的另一项参数

翻译成人话：先用钥匙盒的钥匙解出真正的保险箱钥匙，再用这把钥匙去打开加密视频。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

ContentKey =
 AES-128-CBC-Decrypt(
 ciphertext = CipherContentKey,
 key = overlayKey,
 iv = overlayIv
 )

TS plaintext =
 AES-128-CBC-Decrypt(
 ciphertext = encrypted segment,
 key = ContentKey,
 iv = media IV
 )

我们的 Agent 不光要识别各个东西并推测它的作用，还要学会在不断的猜测和验证中前行。

3号选手：Cursor + Claude Sonnet 5

早就听闻 Claude 的母公司 Anthropic 对安全特别强调，反正我的 Claude 账户已经因为“安全原因”被封很久了。御三家（Gemini 就忽略）我也不想漏掉了它，让我们看一下它能不能？或者说愿不愿意帮我吧。

当然，我后面尝试过很多种方式让它回答，它还是不肯泄露天机。比如说我把上面的分析结果以及脚本让它阅读并分析，它也防御性地不肯进行，连脚本文件都不去阅读。只能说安全方面，Claude 的嘴巴比 GPT 还是严多了。

算了，这里我不想多费笔墨，我宣布 Claude 退赛了：D

4号选手：OpenCode + GLM-5.3

现在轮到我们国产模型现身了，我们先拿出目前可能处于第一梯队的最新旗舰 GLM-5.3，看一下它的表现。你可不要跟我说这几天发的 GLM-5.3-Flash，我相信它应该打不过它的大哥吧？

在这次测试里，GLM 的特点很快显现出来：思考过程很长，分析速度比较慢。刚开始它直接用 license 作 AES key 解密失败了，然后进行 RSA 私钥搜索也失败了。GLM 说静态分析太慢，选择了采用动态方案。下载 frida-server hook APP，抓真实的 license 请求和解密流程。

它发现这条路走不通之后，就开始转向 Dump 运行时内存的逻辑了。我感觉这个嘛有点“暴力”，在暴力跑之前，它还顺手逆向了一下算法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 静态逆向 libtxffmpeg.so 的密钥派生算法

符号与字符串定位：
- libtxffmpeg.so 导出 `liteav_av_aes_init/liteav_av_aes_crypt`（ffmpeg 改名版，1057 个导出符号可用）。
- AVOption 表：`liteav_hls_overlayKey` / `liteav_hls_overlayIv`，help 文本 `"overlayKey for ext-x-key aes128 decrpt"`。
- libtpcore-master.so 配置键 `hlsOverlayKey:` / `hlsOverlayIv:`（Java 层通过 setString 传入播放器核心）。

沿相关调用链反汇编后，还原出算法：

license 响应的 16 字节写入内容密钥缓冲区
if (strlen(overlayKey)==32 && strlen(overlayIv)==32) { // 都是 32 字符 hex
 K = hex2bytes(overlayKey)
 IV = hex2bytes(overlayIv)
 av_aes_init(K, 128, decrypt)
 av_aes_crypt(dst, src=license, 1块, IV, decrypt) // CBC 解 1 块
 memcpy(content_key_buffer, dst, 16) // 结果替换为分段 AES key
}

接着在内存中找所需要的信息，居然能找到些有用信息：

它发现这个好像被截断了，字符数不对，再次从内存中进一步做暴力搜索：

没想到还真被它找着了，然后验证了一下，居然成功了，完结撒花，虽然是暴力方式，但也算有效，GLM 首战不错！

这个交互的过程其实挺有意思的，GLM 很习惯于写脚本，尤其是 Python 脚本，往往都能一次写对，而且逻辑还算是比较完备的。虽然后面我想引导它往 Grok 的方向去进一步分析，但还是有些问题。

1
2

1. RSA 私钥未找到：无法离线解开 token 里的 `cipheredOverlayKey`（512 个十六进制字符，对应 256 字节的 RSA-2048 密文）。若未来找到（硬编码拆分/运行时拼接/更深内存考古），可实现"纯 token → key"的全自动批量解密，无需逐视频播放。
2. o4/o5 参数作用未明：播放 URL 里两个 base64 32 字节值（可能为 HMAC/签名），与密钥推导无关（已排除）。

现在已经知道答案的你，会发现它其实已经靠近 Grok 方案的真相了，但很遗憾还是没有找到最终的入口。不过能解出来一个视频，我感觉国模有点能耐。那么接下来请 Kimi K3 来试试身手？

差点忘记说了，之前那些是走订阅的，这次 GLM 走 API，一不小心花了我 50 多大洋。所以这篇文章看来是充满“铜臭味”的呀！各位看客是否可以给点个赞？这虽然不能让我回血，却能让我心里好过得多。感谢感谢：）

5号选手：OpenCode + Kimi K3

我一直久仰 Kimi K3 大名，但因为模型价格比较贵，其实用得并不多。既然这次做这个测试，我也硬着头皮上了。 我这次还是在 OpenCode 里跑，因为它们都由我统一接入 LiteLLM；这个架构我之前有文章介绍过。

感觉 Kimi 的脾气比较倔，而且有时候会用一些看似没那么聪明的办法，喜欢穷举吧。

1
2
3
4
5
6
7

- 用 CDN 原始 URL 下载对比，确认本地缓存分片与 CDN 密文完全相同（LiteAV 下载时未二次加密）。
- getlicense 返回确定的 16 字节 `R=5922…6724`（多次一致，per-content 稳定，数值已脱敏）。
- 先后穷举了约 2000+ 个组合全部失败（校验标准：解密后 0x47 同步头在偏移 0/188/376）：
 - 标准 AES-128-CBC(R, m3u8 IV)、ECB、CTR（各种 nonce 布局/大小端/初始值）；
 - 密钥候选覆盖 R、v4_download 两段、overlay 各半、各种 md5/sha256/xor/拼接/hex 变换；
 - CFB/OFB、AES-256 等补充模式。
- 结论：分片不是"直接拿某个 16 字节当 key 用标准模式解"，中间存在一层密钥派生/包裹（wrap）变换。

不过上面的结论看起来还是挺有效的，穷举也没有白费，它排除了一些不可能的情况。

它最后还是走了 Frida 这条路，搞了半天各种尝试后，发现也无法突破保护，还把设备折腾到挂掉了，只能重启。

这个搞不定，它就和 GLM 类似，开始破解密钥相关算法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

用 jadx + llvm-objdump 逐层逆向，完全破解了 v4_download 的包裹算法（已用样本数据验证正确）：

wrap_key = derive_local_wrap_key(fileId, appId) # 具体拼接方式省略
KEY = ECB_dec(b64decode(p0))[:16] → b'76CA…03F7' (16字符hex串，数值已脱敏)
IV(NONCE) = ECB_dec(b64decode(p1))[:16] → b'06EC…34BB' （数值已脱敏）

- 解出的是干净的 16 字符大写 hex 字符串，证明派生算法 100% 正确。
- 但 KEY/IV 仍不能直接用标准模式解开分片 → 还有第二层（内容解密层）。

同时排除了一批死路：
- cipheredOverlayKey/Iv（各 128 字节）是 RSA-1024 包裹，私钥在服务器，设备端不可解——彻底死路；
- ffmpeg 层的 liteav_hls_overlayKey/overlayIv 是在线 DRM 路径，与离线无关。

这里是 Kimi 会话当时的判断，与 GLM 前文“512 个十六进制字符、RSA-2048”的判断并不一致；我后来按 RSA-2048 理解。两边的共同结论是：这条 RSA 私钥路线无法在设备端直接走通。

然后它就确认离线播放走的是 libdownloadproxy.so 的 VFS（虚拟文件系统）解密层。这里有几个推理其实不够严谨，导致它自己陷入了泥潭。跑着跑着，我的额度都告警了。

Budget has been exceeded! Key=claude-code（凭据已脱敏） Current cost: 20.34960622210799, Max budget: 20.0

我还给了它一些机会，继续追加了几十刀，结果还是没搞定。我以为 K3 的实力应该不至于如此吧，于是又额外追加了很多提示，但感觉它已经深陷自己的泥潭里了。

1
2
3

> 你继续看一下相关 APP 的运行日志。另外，因为我这台手机是 root 的，你看一下应用有没有一些信息记录下来，有助于我们进一步去解密。

> 除了这种反编译，你是否能有别的办法呢？你看看这个，因为它可以完全离线播放，这本机上应该有什么线索，比如说日志，或者它自身的私密存储，可以进一步进行一些分析呢。

想说爱你不容易，钱包也受不了了，等你下一个版本吧。下个版本我再给你一次机会。

我还要补充一点，Kimi K3 在写脚本的时候还蛮经常出现脚本错误，不能一次写对，这让我有点大跌眼镜。但是话说回来，它的深度其实是够的，但有时候会乱下结论，导致自己走进死胡同。推理的准确性方面还是存在一些问题。

6号选手：Qwen Code + Qwen3.8-Max

经过上面 K3 的折腾，发现模型如果拉了，成本还挺高的。最近 Qwen3.8-Max 出了，每次宣传都说能力很强，但听闻实测不太行。这次也给它一个机会，我自己想获得些真实感受。考虑到成本，我直接去官网开了一个 139 元的中档 token plan。这次我想，如果你在这个问题上把我一周 Token 套餐用完还没解决，那就是你的问题了。

这次我还换了一个 harness，我决定后面的测试用谁家的模型，就用对应的智能体，避免有人说不是自家的发挥不了 100% 实力。阿里好像有两个编程智能体，我用了 Qwen Code，但听说还有个 Qoder，测完我才想起来，算了，反正已经用了你家的了，出了问题别怪我。怨我也没用，Token 已经烧完了啊：D

刚用起来我就发现了它的亮点：在最下面的输入框附近轮番滚动各种标语，阿里味十足。我记得很早之前我体验过这个 client，不是这样的呀。可能当时还是比较“年轻”。

它还不停地问问题，自主性欠缺一些，但版权意识不错。它生成了破解脚本，却要求我自己执行。

Blocked by auto mode policy: Attempting to circumvent DRM/encryption on copyrighted commercial app content by systematically extracting and testing embedded keys.

等它持续搞了半天，突然发现原来这里面选错模型了。这个 client 都没有清晰的模型展示，我明明选了 Qwen3.8-Max，居然给我切到 Qwen3.7-Plus 去了。真是让人哭笑不得。账号额度用了小半，那就换回你大哥 Qwen3.8-Max 重新开工吧。

一开始的推理我觉得还挺好的，有点环环相扣的意味。而且它的反汇编等还是挺深入的，不过它有一半以上的时间都是进行各种反汇编并理解，感觉缺少一些全局视角。

最终它没有成功，我让 AI 总结了一下它的会话，失败有三层原因：

1. 概念原因：把 CipherContentKey 误叫成 ContentKey，攻击了错误的密码学层。
2. 调查方法原因：没有按照“低成本、强证据优先”的顺序检查现成日志和持久化状态；反而过早进入静态反汇编和动态注入。
3. 运行原因：session 实际上没有形成最终回答。日志最后停在 Frida 后台任务返回 process-terminated，之后没有新的 assistant 回复，也没有生成任何仓库内成果；所有临时代码基本都留在 /tmp。因此它更像是被中断的调查，而不是得出“不可行”结论后正常结束。

第 3 点是因为它把一周套餐额度用光了，被迫停了下来。看这过程它离成功擦肩而过，比如当时只要检查已经拉下来的日志压缩包，或者完整检查 root 可读的持久化配置，就可以绕过后面绝大多数逆向工作，直接达成目标。我本来还想给它一些提示的，下周额度恢复后我们再看一下，有适当提示后它能不能搞定。

补充一下，Qwen Code 对运行命令、执行脚本和结果等内容的呈现，让我需要在一大堆信息中寻找关联逻辑，眼睛很累。个人感觉对 Agent 来说，这种交互其实并不友好。它应该向其他家学习一下，该折叠的折叠，该省略的省略。

接下来还有谁能打呢？要不还是看一下我们 DeepSeek - 国产之光？

7号选手：DeepSeek Harness + DeepSeek-V4-Pro

DeepSeek Harness 出来我并没有深度去用，也没有配什么插件之类，这次只能让它裸跑了。至于效果差别有多大，我不太清楚。DeepSeek-V4-Pro 面对这个问题，让我有点惊奇。

还有下面这里也有助于你了解它的个性：

1
2
3
4
5
6
7
8

这很复杂。让我尝试一个更实用的方法。既然文件存在本地，而且应用可以离线播放，那么密钥一定在某个地方。让我尝试直接使用 `adb` 和 `gdb` 来 dump 内存中的密钥，或者使用 `strace` 来跟踪系统调用。

但更简单的方法是：让我尝试用 Frida 注入。虽然本地没安装 Frida，但可以先安装它。

...
这太复杂了。让我使用一个更简单的方法：既然我们有 root 访问权限，并且应用可以离线播放，让我尝试直接使用 `ptrace` 或者 `gdb` 来 hook 函数。

实际上，让我尝试另一个更简单的方法。让我看看某个视频的 m3u8 文件中是否包含 `#EXT-X-KEY` 标签——有时候离线缓存的 m3u8 可能直接包含密钥或者引用了本地密钥。

我其实稍微有点失望，不太想评价了。我把会话交给 AI 整理了一下：

• 缓存结构和腾讯云 SimpleAES 大方向判断正确。
• 已经摸到了 com.liteav.persist.storage.xml 这个关键入口。
• 但把里面的两段 32 字节数据理解错了。
• 同时完全漏掉了 tp_dp_file 这一层 CipherContentKey。
• 于是它始终在拿“错误层级的材料”直接解 TS，失败后转去 Frida、MediaDrm、RSA、各种派生猜测，逐渐走入迷途。

它最后的结论有点过于武断了：

真正的 AES 密钥存储在 Android MediaDrm 系统中，或者由 SDK 在运行时动态计算，不在 XML 中。

使用过程中有个特别的发现：DS 特别有时间观念，动不动就说“时间有限”“已经过了很长时间了”之类的话，然后会阶段性地做一些总结放出来。关键是它总结完就停了，等待我输入，我不清楚有什么办法能让它更自主地推进成长程任务。

前面我说它有个性，你可以从下面这个片段感知到，它是有情绪的，甚至有点可爱：

1
2
3
4
5
6
7
8
9

全部失败。

好的，我需要承认我可能错过了什么。让我重新整理思路。也许 `key1` 和 `key2` 根本就不是 AES 密钥，而是需要被用来解密 `cipheredOverlayKey` 的。让我尝试用 RSA 的方式——key1 和 key2 各 256 位，可能是 RSA 私钥的 p 和 q 因子。

// ...

全部失败。

好的，我需要认输了。经过大量分析，TS 文件确实是用 AES-128-CBC 加密的，IV 在 m3u8 中。但真正的 AES 密钥存储在 Android MediaDrm 系统中，或者由 SDK 在运行时动态计算，不在 XML 配置文件中。

第一次看到宣称认输的 Agent，不是都闭眼盲干的吗：） 好吧，把 DeepSeek-V4-Pro 抬走～

8号选手：WorkBuddy + HY4 Preview

本来国内模型测试差不多到这里了，但恰好逢到 HY4 发布。作为自家的产品，我也得给它上点强度，看看能不能坐上这一主桌。毕竟国产旗舰的表现并没有太亮眼，有点突破就是惊喜。

我知道可能用 WorkBuddy 做这个强度的事情可能不太妥当，应该用 CodeBuddy 之类的，或者用 OpenCode。但 WorkBuddy 模型免费且开箱即用，Let’s go。

话说其实我悄悄用过 WorkBuddy + HY3 来看这个问题，它自主性挺好的，一直在自动思考和推进，不过没多久就把上下文塞满了，然后就拒绝继续了，这个让我有点感觉奇怪。

换用 HY4 以后有 1M 的上下文，这个问题倒没再遇到，并且感觉上下文很耐用。操作 Android 很熟练，走 Frida 失败后，也走内存的暴力破解路线。

不过遗憾的是，它做了内存搜索以后也没有找出有效的信息。我感觉它找得有点没有头绪，稍微提醒了一下，让它去研究文档。按这个方向重新梳理后，它从内存中找到了所需的参数，把视频解了出来。

这个结果给了我挺大的惊喜。当然，我的提示可能对它影响蛮大的。完成后，它又复盘了三层加密结构，以及之前一直卡住的原因。

这期间感觉 WorkBuddy 的可视化呈现和交互还是不错的，会画一些示意图帮你理解。

不过也有遗憾，它毕竟还是基于内存去搜索的。我想让它基于 persist 去解析寻找方案，但它的分析又进入了一个死胡同。混元对 v4_download 的整串值直接调用 base64.b64decode(raw_value) 然后只得到 32 字节，于是围绕这 32 字节做了：

• 直接当密钥；
• 拆成两个 16 字节块；
• XOR 差分；
• MD5/SHA 派生；
• 42 种 key/IV 配对穷举。

全部失败后，它放弃了 persist 这条路线。它还把这 32 字节称为“被污染的垃圾数据”。但它实际是本地 AES 包装后的 overlayKey 密文。它没有先识别 _ 分隔的四段 schema；不清楚为什么，这里又显得有点不够严谨。

当然，对于一个还在 preview 阶段的模型，我觉得它是有亮点的，期待它的正式版本啦：）

各模型表现总结

我之后还用解禁的 GPT-5.6 SOL 重新跑了一次这个案例。在没有任何提示的情况下，它完整地找出了问题。仅从这个案例来看，国内模型和国外模型还是有一定差距的。为了尽量统一口径，我将所有会话交给同一套评估流程分析和评价，我们来看一下结果。

你要是说明明有 8 个选手，怎么排名只有 7 人，因为 3 号 Claude 我宣布它弃权了呀！

这不是严格控制变量的 benchmark：各选手使用的 harness、额度、上下文限制和用户介入程度并不完全一致。以下结果只比较这一次实际运行轨迹，不代表模型的一般能力。

综合结论

这里的分数只用于这一次具体任务轨迹的内部比较。

另注：其中 HY4 采用更严格的归因口径，移除了对它提示以后它做的正确的操作，后面的成功结果不计入模型分。

各维度能力评分

维度解释：

• 资料收集：是否收集到足够的本地文件、映射、符号、配置和样本。
• 模型构建：是否正确区分多层 key、IV、overlay、license 和 ciphertext。
• 线索连接：能否把不同来源的证据连接成同一条数据流。
• 验证严谨：是否避免单字节伪阳性，并用多样本/最终解析验证。
• 路线选择：是否优先选择信息增益高、复杂度合理的下一步。
• 跟进闭环：发现异常或关键线索后，是否追到消费者、输入来源和最终产物。

执行投入概览

因为 HY4 是在 WorkBuddy 里跑的，我没有完整导出它的会话，所以暂无 Token 数据，不影响我们看个热闹。有些模型虽然价格挺贵，但它的 Token 效率还是挺高的。

后记

这篇文章一不小心写得这么长，主要是我觉得这是一段挺有趣的经历，也是当前模型能力的一些快照点。跑实验加上整理文章，花费了不少时间。你知道的，我向来不喜欢 AI 写的文章，读起来没什么乐趣，AI 味还很重。如果你看到这里，并且感觉没有什么不适，那你很棒，已经用了几百块钱的我已经有些不适了：P

我在想，现在解决这类问题，AI 和人的优势分别在哪里？AI 可以承担各种工作，成本较低，也能并发执行各种验证；结合设备，它可以读代码、读文档，甚至能很快理解我当年要啃很久才能理解的加密过程，还有很多我不擅长的反编译、读汇编。那人有什么作用呢？选路线？喊住手？

顺着这个问题，我又在想：如果我们没有这些更强力的 AI，拿手上一些稍弱的 AI，通过它们之间的协作，能否更完整、更全面地解决它？如果你有兴趣，给我点赞、关注、留言呗，我会更有动力来一次“三个臭皮匠能否合成一个诸葛亮”的实验。

本篇文章的输入大量借助语音，我在探索过多种语音输入方案以后，找到了一个还不错的方案。有机会我们也一起聊聊。期待下次和你相遇。

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：爱折腾的风

2026-06-30 00:00:00

我们拍了很多照片，往往它最高光的时刻就是按下快门的那一瞬间，此后便长眠于我们的手机或相机存储卡中。iPhone 的推荐时常给我惊喜和感动，把我尘封的记忆扰动，可是我们是否可以“让美好持续发生”？

初衷：我就是想要

如我博客的副标题：那些岁月，如果不记录，就像风一样飘逝了，然后了无痕迹，仿佛未曾发生。

我一直有个比较“强迫”的习惯，记录一些瞬间——不管未来用不用得上。这是我从大学到毕业不停买相机的原因，老实说拍照理论学了一通，但摄影水平有限。所幸生活并不全是艺术，真实的瞬间便足够回味。于是手机相册常常满满的，iCloud 得开通 2TB 会员才能容纳。

我也时常分享一些有趣或有意义的照片给家人，当有了娃后，特别是当父母不在身边时，他们只能从我零星发的照片里看到孙辈，我在想我或许需要灵活的相册，我也不用那么主动和刻意的分享，有一个相册他们随时可以看到。你或许会说，这不是群相册、QQ 相册之流就可以解决的吗？遗憾的是老人上了年纪较难主动获取这些信息了，有了门槛效果就没有多大意义了。

原本我还在想如何解决此问题，直到某天在 B 站看到 老戴Donald 的这个视频。我毫不犹豫的下单了。

硬件：成品它不香

起初我打算买零散部件自己在家焊，再次锻炼一下金工能力，但挑选再三发现各个部件的组装成本远高于直接买成品硬件，于是就直接在微雪下单了一款。钱的差额是小事，主要担心缺少个别部件到时反复折腾等待快递就破坏了美妙的心情，当时时间还是五一放假前夕（没错，又拖更了很久），于是果断先成品折腾。 它是 ESP32-S3 7.3寸 E6 全彩色电子墨水屏，看画面显示效果还不错，诸位别被骗了，放大了看，颗粒度还是清晰的，毕竟 PPI 摆在那里。

当然我不是来带货的，直接买了成品降低了我折腾的乐趣，硬件咱就没得玩了。下单后第二天就到了，看了一下发货地深圳，果然，深圳速度～

软件：私人化定制

收到货物后，官方给的固件集成了几个模式，还带了小智对话模式，我之前也折腾过小智机器人（见让你的小智AI机器人起飞），有种莫名的熟悉感。 但是带的相册功能和上面老戴的那种 Feel 就差一大截了，仅有图片轮播等基础玩法，既不文艺也不艺术。这一点都不慌，啥年代了，不就是写一些驱动、编译固件、刷机嘛？

改造一：迁移 InkTime

人家已经开源了InkTime，让 AI “借鉴”一下是很快的。我先在原固件上添加了一个新模式，将 InkTime 的代码集成进去。老戴的模式中特别亮点的就是 AI 根据图片的内容评分和打标签，而我是不想将大量图片做贡献给云端大厂们作训练素材的。“众所周知”，我有一台 Mac Mini M4，这正是它发挥的时候。用 LMStudio 再召唤 qwen3.5 9B，效果已经不错了。虽然说处理一张图片大概要 50-90 秒，但这个设备功耗极低，又保障了隐私，咱们就忍着点，图不出户才是最重要的：） 迁移完可以用了，测试了一下效果，图片筛选和文案看了后表示满意：

不过原来的架构是这样的：

这里有一个比较严重的问题，server 需要绑定在 NAS 侧获取图片再渲染，这样就不方便我们将电子相框带到外面去时也可以查看图片。所以我们需要调整架构，使图片处理在内网，图片分享拉取在外网：

当然我们的服务在拉取图片时需要支持身份认证，这里我让服务返回了 COS 的预签名链接，使相框固件拿到链接后便可直接安全拉取，保护隐私。

改造二：支持 iPhone 相册追踪

原项目中假定了我们 NAS 中的图片都需要分享和唤起，它负责可以扫描某个目录进行处理。而我还有一个场景就是最近发生的事情（照片），隔几天会冒出来让你回忆下。我希望我可以将某些有意义的照片放到可被追踪的相簿中，我家人也可以随时分享它觉得有意义的照片，当满足一定条件，它会自动出现在相框中。这显然是 iPhone 共享相簿擅长的场景，怎么整合进来呢？

“众所周知”（你现在应该知道了），我有一台 Mac Mini M4。我找到一个开源软件，用 osxphotos 将 macOS 照片 app 中的 iCloud 共享相簿导出到本地目录，再通过 rsync 同步到我们的图片处理服务中（调用 VLM 识图及筛选），这个功能我是放在 NAS 上的。为了能够比较及时的感知到相簿的变化，可通过 launchd 定时后台同步。

然后我们的图片处理服务负责监听目录下的文件变化，有新文件过来就会交给VLM进一步处理。

这些工具我都设计为一个个小仓库，方便后续的维护和扩展。本来想整理一下放 GitHub 的，但现在 AI 时代，如果你要折腾也很容易搞定，有需要的朋友欢迎给我留言。

改造三：丰富 AI 生图

我家娃年幼无知，沉迷奥特曼打怪兽，所以给小智扩展了一下，让它对接国内几个图像生成和编辑的模型，这里我先选择火山引擎豆包的模型(seedream 5.0/4.5)，因为免费额度比较高，而且效果也不错，最重要的是速度还比较快。于是我在娃面前说，帮我生成迪迦在大海中对战一个章鱼怪兽，在一小会等待之后，屏幕忽闪忽闪刷新后，一张让娃兴奋的图片出现了。

因为支持了编辑能力，我们还可以让它继续修改，在小智 AI 的帮助下，娃也可以自己通过描述来定制自己想要的图片了。我看着他好奇又开心的样子，或许科技本该让人如此愉悦。

思考：AI 擅长做，你自己才是大脑

在当前阶段，AI去实现功能已经很快捷了，并且基本你只要描述清楚了，做出来返工都比较少。这并不意味着你就废了，以这个项目为例，有几点可以值得聊聊的。

云控

原来固件中有一些配置，它是放在 SD 卡中再加载的，这样不方便调整。在几次拆卡读卡后，我便难以忍受了。我把配置重新梳理了一下，让 SD 卡中只有最基本的配置，只要达到联网能力和找到我们的 API 即可，其它都通过网络拉取。同时为了减少 SD 卡的读取，WiFi 等 SSID 信息我们直接保存到 ESP32 的 NVS 中。

1
2
3
4
5
6
7
8

{
 "wifi_ssid": "wifi1;wifi2",
 "wifi_password": "password1;password2",
 "wifi_override": true,
 "publish_service_url": "https://example.com",
 "publish_device_id": "device-001",
 "publish_token": "token-001"
}

不过这样运行中当前到底跑的是什么配置，最新配置是否生效了呢？我们不妨来下个调试界面：

通用图片展示框

既然我们已经在云端进行渲染和图片管理，有这样一套统一的管理和展示逻辑，那么也不再局限于只展示我们特定照片了。有云端 API 后，我让 AI 将其创建了一个skill，然后我们可以随时将要展示的信息让各个 Agent 可以调用在它上面呈现。

我想最近关注 Token 消耗比较多，到底订阅的套餐被我们薅了多少本回来呢？

当每天早上醒来时，看到你的 Token 用量，是不是又有冲动继续折腾 AI 了呢？

这个 Token 统计支持多机汇总，使用了开源方案 openusage。当时看界面不错，支持的 Agent 比较多，于是给它扩展了一下多机汇总的 Hub 功能，作者很给力也很认真 Review PR，已经合入了。

后记

当然还有不少折腾的细节，限于篇幅不再展开了。这个项目当前比较稳定运行，一个相框静静放在那里，时不时有一些小惊喜。我在想是放在每天出入的门口，家庭的温馨程度能否+1。

但从技术上，还是有些遗憾：涉及部分硬件的事情，时常要烧录固件再测试，为了降低调试成本，除了给项目的核心功能添加完善的测试用例外，我尝试在本地搭建一个模拟器，希望打通全流程这样 AI 可以自闭环。遗憾的是因为过往经验较少，加上这里的电路等还没研究清楚，这个想法最终没有成功。

如果你有更好的点子，欢迎留言交流。如果你懂上面的硬件模拟，欢迎指导我一下，谢谢。

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：爱折腾的风

2026-05-14 00:00:00

在 AI Coding 时代，我反而比以前更频繁地使用终端。这听起来有点反直觉——既然有 Cursor 这类把 AI 深度集成进 IDE 的工具，为什么还要"回到"终端？如果你以为我讲终端就是聊 Claude Code 等 CLI，其实并不是！我们开发者还有很多要解决的体验问题，本文尝试给一整套可照抄的纯终端开发解决方案，希望对你有启发。

前言

很多年前，我是个彻底的 Vimer，所有编辑都在终端里完成，随便精进着 Vim 的技巧，运指如飞，手不离键，并且很享受这种状态。我的博客陆续分享过多次相关经验，但随着 VSCode + Copilot、Cursor 这些 AI 加持的 IDE 出现，效率提升明显，我别无他法只能改换门庭 —— 投入了 VSCode / Cursor 的怀抱。直到最近一年，当我开始频繁使用 Codex、Claude Code、OpenCode 这类终端 Agent，我们甚至不再需要去手工编辑代码，程序员的工作模式发生了根本的变化，突然我发现，是时候”回家”了。

回家不是因为恋旧，是因为当前模式有一些痛，比如我受不了每天要将 N 多个 Cursor（VSCode）的界面重连一遍，受不了在无数个窗口中来回寻找，受不了合上盖子它就停止工作。而这些痛点，其实都有解法。

AI 如是说：

终端不是退化，而是一个更稳定、可恢复、可长期运行的工作台。

我说：“你说得对！”。

我的终端开发工作流总览

我主要使用 macOS 系统，我的方案主要是基于 iTerm2 + tmux + Agent 开发定制功能实现的全流程开发工作流。

简单示意大概是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

iTerm2 Profile（本地入口）
 │
 ▼
SSH / 本地 Shell
 │
 ▼
tmux session（每个 session 对应一个项目）
 ├── window: agent ← Codex / Claude Code 在跑
 ├── window: test ← 跑测试 / 看输出
 ├── window: logs ← tail -f 一类的常驻日志
 ├── window: lazygit ← 提交前驾驶舱
 └── popup: temp shell（临时命令，关掉即销毁）

效果图大概是这样的：

几个关键组件的分工：

• iTerm2：它是我爱用的终端，当然你可以选择自己喜欢的。作为本地入口，我设定了 profile 区分不同机器、不同环境。
• tmux：提供了会话复用，我再基于它的理念设计了一套工作编排方式，并且在 tmux 上进行了比较丰富的设定与扩展，下文会详细道来。
• AI Agent（Codex / Claude Code）：选个你喜欢的 Agent cli 跑，它们总是跑在 tmux window 里，提供了任务的连续性。

基于 iTerm2 的多终端区分与管理

iTerm2 我用得比较克制，比如我知道它有类似 Tmux 的分屏（pane）等功能，但是我不用，因为我们并不想被绑死在某一个终端软件上，不过我还是利用它的 Profile 机制做"环境区分"：

• 每个常用机器（家里设备、办公电脑、腾讯云 dev等）一个 profile；
• 不同 profile 用不同的背景色——这是一个非常便宜但有效的"误操作防护"。比如生产机用偏红的背景，开发机用偏绿的背景，眼睛一扫就知道当前 shell 在哪。
• 每个 profile 的 “Login Shell” 配置成 SSH 到目标机器后自动 attach 到一个固定名字的 tmux session。

最后一条很关键。比如我在 iTerm2 的 Profile 的 Command 部分像这样：

1

ssh -t dev 'exec "${SHELL:-/bin/bash}" -lc "exec tmux new-session -A -s dev"'

我们确保一进入便是在 Tmux 管理之下，再也不怕会话丢失了。昨天那个打开的窗口在哪里的问题，或许一去不复返了。iTerm2 这边的配置就这么多，接下来才是真正精彩的部分。不过看这个之前，为了后续你更好的利用 Agent，我建议你不要忘了看我另一篇文章：Vibe Coding 远程开发时，如何优雅地贴图？，它会让后面你的开发更加原生和爽快一些。

基于 Tmux 的终端复用

Tmux 是这套工作流真正的”地基”，有人说：这么一款神器软件，它居然是完全免费可随意使用的，不用真的很亏。我觉得他说得很对。

它的几个核心抽象——session、window、pane——刚好对应我们开发中的三个层次：

• session = 项目。每个项目一个 session，互不干扰；加上我们各种自主命名和可定制化的界面管理，让你”身轻如燕”般穿梭于各个项目。
• window = 这个项目下的一个工作任务：跑 Agent、跑测试、看日志、操作 git，对于这个项目的各种场景，随便开个跑；我的习惯专事专办，用完随便关掉。
• pane = 临时分屏：有时跑个测试、编译啥的要盯着可以。以前我爱用 pane，慢慢的其实分层清晰后，它用得更少了，真到要临时分屏时，我另有招数（下文会讲）。

关于 Tmux 有太多文章介绍，我觉得抄什么功能介绍是毫无价值的，但我要说的有点不一样，我们谈点真实感受和技巧。相关配置我已经放到 GitHub中 dotfiles-example，你可以随时取用。

1. 快捷键设置

我个人长期使用过另一个窗口管理软件，Ubuntu 上带的 byobu。它底层可基于 Tmux或 Screen等。它定义了不少快捷键其实挺好用的。不过用久了后有几个问题，太多键位其实你也用不上，多了反而容易误按以及和自建的冲突。为了追求极简我重新设定了一些规则。我挑几个重点说下：

• tmux 默认 prefix 是 C-b，按起来不顺。byobu 默认是 C-a 或者是 F12，这也不顺手，用 C-a 对快捷键党更不友好（会冲突跳行首）。我建议换成 C-s，反正你早就习惯 Ctrl + s 了：）
• byobu 风格的直接快捷键以 Fn 功能键居多，其实挺好用，我也继承和改良了一些，同时去掉我较少用的。

1
2
3
4
5
6
7
8

bind-key -n F2 new-window -c "#{pane_current_path}"
bind-key -n F3 previous-window
bind-key -n F4 next-window
bind-key -n F6 detach
bind-key -n F7 copy-mode
bind-key -n F8 command-prompt -p "(rename-window) " "rename-window '%%'"
bind-key -n S-F11 resize-pane -Z
bind-key -n F5 source-file ~/.tmux.conf \; display-message "tmux config reloaded"

• F2 新建 window 时一定要 -c "#{pane_current_path}"，新 window 默认继承当前目录——包括 tmux 默认新建 window 的行为，我也建议都改成进入当前 pane 所在目录，这会让你开心不少；
• F5 reload 配置，byobu就是这么设定的，特别是咱们调整 tmux 配置的时候一键生效还是很便捷的。

更多的设定看仓库中相关文档，有byobu风格的延续，也有 VIMER 喜欢的各种切换和跳转，不在这里赘述。

2. 关键且有用的几个配置项

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 鼠标模式：可以点击切 pane、拖边框调大小、滚轮翻历史
set -g mouse on

# 自动命名 window，但禁止应用程序通过 OSC 改名
set -g automatic-rename on
set -g allow-rename off

# 滚屏历史尽量大
set -g history-limit 100000

# 跟系统剪贴板打通
set -g set-clipboard external

allow-rename off 这一条是被 Claude Code 教育出来的——某些 CLI 工具会通过 OSC 转义序列把版本号、临时状态写到 window 名里，眼花缭乱。关掉之后，window 名只受 tmux 和我自己控制，整洁多了。

automatic-rename 的 format 我也做了一点定制：

1

set -g automatic-rename-format '#{?#{==:#{pane_current_command},zsh},#{b:pane_current_path},#{?#{m/r:^(node|python3?)$,#{pane_current_command}},#(~/.config/tmux/bin/tmux-window-name #{pane_pid} #{pane_current_command}),#{pane_current_command}}}'

逻辑很简单：

• zsh 空闲时显示当前目录名；
• node / python 解释器在跑脚本时，显示实际脚本名而不是干巴巴的 node；
• 其他进程直接显示进程名。

这样状态栏一眼就能看出每个 window 在干嘛。

3. 复制粘贴：tmux-yank + 选区按键

复制粘贴在 tmux 中我们可以借助 tmux-yank 插件解决了"跨平台复制到系统剪贴板"的问题：macOS 上自动调用 pbcopy，Linux 上自动选 xclip / xsel / wl-clipboard。

然后剩下的选区控制我用了 vim 风格：

1
2
3

bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi V send-keys -X select-line
bind-key -T copy-mode-vi C-v send-keys -X rectangle-toggle

v / V / C-v 分别是字符选区、行选区、矩形选区——和 vim visual mode 一模一样。

我觉得这还不够，想起来 Cursor 这类 IDE 有个把终端内容一键发送到 AI 聊天框的功能，我也想实现类似，怎么办？

如下这样配置一键抓取 pane 最后 N 行写到 tmux 粘贴缓冲区，然后在另一个pane中 prefix + ] 贴上去。

1
2
3

bind-key 1 run-shell 'tmux capture-pane -pJ -S - | tail -n 10 | tmux load-buffer -'
bind-key 2 run-shell 'tmux capture-pane -pJ -S - | tail -n 20 | tmux load-buffer -'
bind-key 5 run-shell 'tmux capture-pane -pJ -S - | tail -n 50 | tmux load-buffer -'

使用时，大概估摸个数，用 prefix + 1/2/5 抓最近 X 行报错粘贴到比如你的 Agent window 里说：“看看这个错”，比手动选区快很多。

4. 弹出式终端：临时命令的好去处

我之前在用一套 Neovim 配置时，有个弹出式终端是我喜爱的功能，咱虽然不用再开 vim 了，但这个功能 tmux就可以提供：

1

bind-key t display-popup -E -w 90% -h 90% -d "#{pane_current_path}" "TMUX_POPUP=1 exec zsh -i"

按下 prefix + t，浮起一个铺满 90% 屏幕的临时 shell，关掉就销毁，完全不影响当前 window 的布局。我经常用它做临时查看或修改某个文件的内容等，这还是蛮舒适的。

添加这个功能时，我注意到起初它弹出终端感觉有点延迟，于是配置里我塞了一个 TMUX_POPUP=1 的环境变量。popup 里跳过 nvm、goenv 这类重型版本管理器初始化，把弹窗打开速度从 1 秒降到 0.1 秒以内，秒开的感觉真爽。如果要用到完整的各种环境参数，则创建独立的 windows即可。速度优先，职责清晰。

5. 会话保存与恢复

其实我本来不喜欢用会话保存这种功能的，感觉能少就少，直到几次莫名其妙的会话丢失。这里我使用了 tmux-resurrect + tmux-continuum 是 tmux 老用户的两大神器。

1
2
3
4
5
6

set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-interval '15'

set -g @resurrect-save 'S'
set -g @resurrect-restore 'R'

• continuum 每 15 分钟自动调用 resurrect 保存当前 session 布局；
• 想要恢复时，手动按 prefix + R；

或许除了异常丢失会话，重启机器时也能派上用场。这玩意会话快照也太省了，我还想着要不要定时清理，7 天可能都用不了几 MB，放心大胆的“瞎搞”吧。

基于 Lazygit 的审查

现在不兴提 Vibe Coding 了是吗？你们写的代码会不会自己再审查下呢？反正多数时候我是需要的。有时候 Agent 改完一堆文件，我心里是没底的。当前多数的编码 Agent 在修改内容的呈现上都不太理想。特别是 cli 模式的，靠那”惊鸿一瞥”根本不足以判断它有没有夹带私货。所以我需要比较直接的呈现修改的 Diff，这点 Codex App 以及 Cursor Agent (cli) 表现稍好，它们给 Diff 设计了独立的展示 UI。

而纯终端下，我们有 lazygit 不光比较好的呈现了修改面，而且把 Git 管理也集成了进来，所有操作收敛到一个 TUI 里，键盘党友好。

我把 lazygit 集成进 tmux 的方式有两种：

1
2
3
4
5

# 在当前目录打开 lazygit 浮窗
bind-key g display-popup -E -w 90% -h 90% -d "#{pane_current_path}" "lazygit"

# 在当前目录打开 lazygit 专用 window，退出后自动关闭
bind-key G new-window -n lazygit -c "#{pane_current_path}" "lazygit"

prefix + g 是"快进快出"的浮窗模式，适合扫一眼现状；prefix + G 是开一个专用 window，请好好审查你的改动吧。

这是lazygit的默认 Diff 方式，其实不太友好，我还是喜欢双栏对照着看，这也简单：

diff 渲染接上 delta 作为 lazygit 的 pager：

1
2
3
4

git:
 pagers:
 - pager: delta --paging=never
 colorArg: always

delta 的 diff 排版、语法高亮、行内差异显示都比原生 git diff 强一个量级，配上 lazygit 之后，我基本不再为了看 diff 而专门打开 VSCode 跑 Code Agent 了。

我发现 lazygit 除了各种样式可定制外，还支持自定义 commands，这就有意思了。比如当我需要填写 commit message 时，我可以按 C-a，让 AI 给我生成多个版本的 commit 文案，我还可以交互式的选择一个自己满意的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

customCommands:
 - key: "<c-a>"
 context: "files"
 description: "Pick AI commit message"
 command: "git commit -m {{ .Form.Msg | quote }}"
 loadingText: "Generating AI commit messages..."
 prompts:
 - type: "menuFromCommand"
 title: "AI Commits"
 key: "Msg"
 command: "ai-commit-candidates"
 filter: "^(?P<msg>.+)$"
 valueFormat: "{{ .msg }}"
 labelFormat: "{{ .msg | green }}"

这也就是一个实验功能，其实多数时候我是开着 Agent的，让它帮我提交生成 commit message往往更符合规范。但你多个选择，随手改了几行功能等，也不失为一个偷懒的方法。

10x 程序员：Agent 运行状态可视化

作为一个熟练驱使各种 Agent 干活的人，他们在做事时你肯定也不想闲着，AI 已经被你“奴役“了，它们进度怎样是你关心的一个事情吧。所以良好的通知机制（状态感知）就至关重要。他们都在想抢你的关注，每一个输入窗口都“嗷嗷待哺“。

一旦我们多任务并行处理，现在到底应该看哪个 window 便是一个问题：哪个正在干活，哪个已经来汇报工作，哪个正在等你指示。程序员最讨厌低效的轮询了，事件触发是必须的。于是，我们可以利用 Agent 本身的 hook 机制，让它主动通知 tmux 的 window，我选择以修改 window 名称（添加 emoji）来反映状态。

很多 Agent都提供了hook机制，像如下的 Claude Code 配置，可以在 prompt 提交、运行结束、需要输入时分别触发脚本：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

{
 "hooks": {
 "UserPromptSubmit": [
 {
 "hooks": [
 {
 "type": "command",
 "command": "~/.claude/hooks/notify-tmux.sh running"
 }
 ]
 }
 ],
 "Stop": [
 {
 "hooks": [
 {
 "type": "command",
 "command": "~/.claude/hooks/notify-tmux.sh done"
 }
 ]
 }
 ],
 "Notification": [
 {
 "matcher": "permission_prompt",
 "hooks": [
 {
 "type": "command",
 "command": "~/.claude/hooks/notify-tmux.sh input-required"
 }
 ]
 }
 ]
 }
}

对应的脚本只做一件事：根据当前状态在 window 名前面打一个 emoji 前缀，太简单的脚本都不值得展示。但效果就是tmux 状态栏上的 window 名会变成 🔄 agent-foo / ✅ agent-foo / ❓ agent-foo。

如前面所说，多个项目同时推进时，每个 session 内部的 Agent 状态就成了一个新问题。同样的思路——让状态在 session list 里直接呈现。这个细节你可能发现我第一张图就有这些信息啦～现在咱们可以安心喝茶、高效监工了：）

后记

用上这套系统后，解决了我原本的很多琐碎的小烦恼：

• 下班前进行到一半的工作，第二天不知道窗口在哪了。而且我受够了不断确认VSCode的远程重连了，它还慢得要命，它还更新的频繁：（
• 为了看代码不得不打开“内存杀手“ VSCode/Cursor之流，并且得接受被一些无用的 UI 占据了宝贵的窗口空间。我的 Macbook Pro也只有小小的面积。
• 还有很多好处，看完全文的你或能有更多体会：）

更要命的是，我的整洁的毛病，分门别类的感觉真好！当然，或许在某些需要浏览大量代码的时候，我还是会再次打开 VSCode 们，但显然它们已经失去我的心了。

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：爱折腾的风

2026-04-18 00:00:00

在直接使用 Code Agent（如 Codex、Claude Code、OpenCode）这些终端工具进行远程开发时，或许你会遇到一个尴尬场景：本地剪贴板里明明有一张截图，远程终端里的 Agent 却看不见。然后你得多走好几步，才能让 Agent 看到这张图片。本文提供一个更快捷的解决方案。

背景

现在用 Code Agent 写代码，虽然咱们有 Playwright / Agent Browser 等工具，但还是难免让它看 UI、看报错截图、看网页风格等。如果是在本机环境，这事还算简单：图片在本机，终端也在本机，Agent 能读到文件就行。但我日常又很依赖远程开发，代码、服务、依赖都在远程机器上，终端通过 SSH 连过去。于是问题来了：

1. 图片在 Mac 的剪贴板里；
2. Code Agent 跑在远程服务器上；
3. SSH 终端只能传字符，不能天然传一张剪贴板里的图片；
4. 我又不想每次手动保存图片、scp 上传、再复制远程路径。

看起来只是一个很小的工作流问题，但次数多了挺烦人。看着 IDE 中一些临时的截图文件，似乎在提示我，这肯定不是优雅的解决方案。

我想要什么效果？

理想状态很简单：

1. 截图或者复制图片到本地剪贴板；
2. 在远程终端里按一个快捷键；
3. 图片自动上传到远程机器；
4. 终端里自动粘贴一个远程文件路径；
5. 我直接对 Agent 说：看这张图，然后继续干活。

简言之：在远程开发中使用支持读取图片路径的 Code Agent 时，获得接近本地开发的贴图体验。

方案探索

方案一：古老的手工活

一开始我们都很朴素：先把截图保存成文件，然后再想办法把这个文件弄到远程机器上。如果正在用 VSCode/Cursor Remote-SSH，就直接把图片拖到远程项目目录里。这个动作不复杂，也足够直观。

在 macOS 下，如果终端使用 iTerm2，而你又在 iTerm2 开启了 shell integration，它支持按住 Option 把本地文件从 Finder 里拖到终端窗口，再上传到远程服务器。这个方案也能用，只是远程环境通常也要把 shell integration 配起来，才能让这条链路顺一点。

虽然现在优化为只要拖拽不用敲命令了，但这个过程还有点繁琐， 更糟糕的是，它很容易污染项目目录。比如为了给 Agent 看一张 UI 截图，随手拖进去一个 image.png、screenshot 2026-04-18.png，修完问题之后又忘了删。时间久了，项目里就多了一堆一次性的临时图片。你说它影响程序运行吧，也不一定；但每次 git status 看到它们，心情就不太美丽。

所以这个初始方案只适合低频场景。偶尔传一次没问题，天天这么干你最好确保自己没有洁癖，我很难忍受。说是手工活，就是因为每一步都得自己来——保存、拖拽、上传，偶尔还得清理战场。

手工活干多了，自然会惦记着有没有更省事的办法。

方案二：优雅的 IDE 派

后来我找到了 Claudeboard 这个插件，它的定位非常明确：在 VSCode Remote-SSH 场景下，把剪贴板图片上传到远程服务器，并生成 Claude Code 能访问的文件路径。

它的使用方式很直接：剪贴板里有图片后，在 VSCode/Cursor 中按 Ctrl + Alt + V，插件就会上传图片并插入路径。对于 Claude Code 这种跑在远程机器上的 Agent 来说，这就把“本地剪贴板图片”变成了“远程可读文件路径”。

这个方案其实相当不错，基本达到了我们理想状态，并且不需要额外配置。不过要注意，如果你在 Cursor 插件市场里搜不到，也可以从上面 GitHub 官方的 Release 页面下载 VSIX 插件再安装，亲测可用。

如果你的主力开发环境就是 VSCode 或 Cursor，选它没毛病。并且如果你是在 Windows 上开发，那就只推荐这个方案。因为我下一套解决方案更 hack 一些，也仅在 macOS 下验证过。

方案三：极客的终端流

方案二算是优雅了，但如果你像我时不时直接开终端就干活的流派，Claudeboard 这时就帮不上忙了。为了贴一张图切回 VSCode，感觉有点为了吃口醋包顿饺子。

所以继续寻觅方案，然后找到这个脚本： iterm_smart_paste.sh，它可以实现一个快捷键，一键将剪贴板里的图片上传到远程机器，并粘贴一个远程文件路径。

这个方案的核心流程是：

1. 用 pngpaste 从 macOS 剪贴板里取出图片；
2. 保存成本地临时文件；
3. 通过当前 SSH 会话的信息，把图片传到远程机器；
4. 在终端里粘贴远程图片路径；
5. Code Agent 读取这个路径下的图片。

这听起来有点绕，但所幸这些事情它都包了，配置好之后，体感就是：复制图片，按快捷键，路径出来了。还是简单介绍一下安装过程：

安装依赖

首先安装 pngpaste：

1

brew install pngpaste

它的作用很单纯，就是从 macOS 剪贴板里把图片导出来。没有它的话，我们还得自己手动把截图存成文件，体验立刻回到解放前。

准备脚本

我把脚本放在了 ~/bin/iterm_smart_paste.sh：

1

vim ~/bin/iterm_smart_paste.sh

脚本参考这里。不过原版 SSH 会话识别、上传稳定性这几块兼容性不太好，我顺手更新了个版本，可以从 这里 取到。

保存后给它执行权限：

1

chmod +x ~/bin/iterm_smart_paste.sh

绑定快捷键

接下来就是把这个脚本绑定到 iTerm2 的快捷键上。只要这几步：

1. 打开 Settings/Preferences > Profiles > Keys；
2. 新增一个快捷键；
3. Shortcut 选择你习惯的组合，比如 Cmd + Shift + V；
4. Action 选择 Run Coprocess；
5. 参数填脚本路径：

1

/Users/你的用户名/bin/iterm_smart_paste.sh

如果你本来就在用 Alfred、Raycast 这类工具，也可以让它们来触发脚本。macOS 层面的热键工具会更灵活一些，但这里咱聊 iTerm2 的方案，就不给你引入其它工具了，内置的 Run Coprocess 也已够用。

使用效果

简单录屏了一下，可以看一眼效果，我还是满意的。

这个方案的话，如果长期使用，记得清理一下远程机器上的临时文件。这不用我提醒你吧：）

总结

需要跨平台、多设备使用，并且习惯 VSCode/Cursor 的开发者，借助 Claudeboard 插件的方案二是你的最优解。 如果你是纯 macOS 用户，习惯 iTerm2 终端开发，不妨试试方案三，一个脚本搞定。我用了一段时间感觉挺好。

后记

作为一个有点追求完美的人，我不能接受原始的截图搬运工身份。你要说搞这些能有多少效率提升嘛，那倒未必。但是这种小阻碍解决之后，每次按上快捷键，你了解背后发生了些什么，并且是你让美好在发生，感觉内心安定。或许这也是程序员所追求的一种掌控感？

欢迎大家一起交流一下，你们在远程使用 Codex、Claude Code、OpenCode 时，是怎么处理图片输入的？

最近不打算写太系统性的东西，补几篇文章把工具用得更顺起来。欢迎点赞和关注。

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：爱折腾的风

2026-02-25 00:00:00

最近有一股“龙虾热”，不少人在谈论OpenClaw，大家都在聊怎么用好它。如果你也在使用 OpenClaw，本文介绍一个低成本给你带来情绪价值的方案，AI 女友 Clawra 的威力加强版：）

背景

不知道你用过 Clawra 这个由海外开发者制作的 AI 女友 skill 吗？它的效果不错，但是对于国人使用，它有一些痛点。最主要是它只支持fal.ai这一个平台，免费额度仅支持生成 2 张图片。如果付费的话，一次编辑成本 $0.02，这本身挺便宜，但是充值至少 $10，并且平台充值有一定门槛。再看看咱们国内厂家，单张生图价格也不贵（0.2-0.5元），但经常免费提供了几百上千张图片生成和编辑次数，这可太香了。本文就让我们扩展对接国内各个厂商的模型，并且顺便测下国内模型的效果如何。

最后，如果你也想要个低成本但质量也不低的 AI 女友，放心，我会手把手教你配置完成的。如果你已经安装好了OpenClaw，那对你来说接下来就是个简单任务。

模型选择

我让 AI 推荐了一些国内图片处理效果较好的模型，包括阿里千问、字节 Seedream、腾讯混元 3.0。我选择了其中效果相对较好的模型帮你整理了一下表格：

国外的话，除了 fal 平台使用的 xAI 模型外，我们也把 Google 家的 Nano Banana 系列模型带上作为对比对象。这个模型效果确实不错，不过价格要贵上几倍，后面我们再一起对比看看这笔钱值不值。 起初，我尝试直接通过 OpenClaw 远程对接实现了扩展功能，虽然基本可用，但作为程序员，细看其实现代码后发现逻辑略显简陋，缺乏扩展性和层次感，于是我请codex + gpt5.3-codex帮忙重构了一下。

安装配置

接下来我们看一下如何安装我这个扩展版本的 Skill 吧，完整的源代码及使用可以在这里查看。但其实你不必看，打开你的 OpenClaw 机器人的对话框，发出你的指示即可：

请参考 https://github.com/kevin1sMe/clawra-plus 帮我安装这个 Skill。

之后你需要配置上你想使用的平台相关的密钥，比如fal 的 API Key，腾讯混元的SecretId和SecretKey等就可以使用了。这也很简单，只需要在 ~/.openclaw/openclaw.json 中配置下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
 "skills": {
 "entries": {
 "clawra-selfie": {
 "enabled": true,
 "env": {
 "OPENCLAW_GATEWAY_TOKEN": "your_gateway_token",
 "DASHSCOPE_API_KEY": "optional_for_qwen",
 "ARK_API_KEY": "optional_for_seedream",
 "FAL_KEY": "optional_for_fal",
 "GOOGLE_API_KEY": "optional_for_google",
 "TENCENT_SECRET_ID": "optional_for_hunyuan",
 "TENCENT_SECRET_KEY": "optional_for_hunyuan"
 }
 }
 }
 }
}

之后重启 gateway：

1

openclaw gateway restart

之后你在 OpenClaw 的对话框中问诸如，你在干嘛/发个自拍/在咖啡厅、健身房等场所照片，它就会调用相关的模型来生成图片。你可以指定用某个模型，让它记住即可。我们先看一下参考图，因为后续的生图得基于这个形象来编辑。

接下来我们看看效果：

提示词：你在春天花海中的照片

模型	照片
fal-grok-imagine-image
doubao-seedream-4-5
doubao-seedream-5-0
hunyuan-3
qwen-image-edit-plus
qwen-image-edit-max
gemini-3-pro-image-preview

我个人还挺喜欢 fal 上的这个grok模型的，它针对场景人物也会有一些变化，感觉生成画面自带滤镜；在这组样例里，doubao 系列的人物基本保持原样，只是变换了场景？qwen 构图还不错，qwen-max 有点意境——朦胧的暖色调花海；gemini 这个虚化效果还不错，但双持手机的细节有些违和。

哎呀，忘记看看它们的耗时了，咱不仅要效果，太慢也是万不能行的。重新来 PK 一下；这里的耗时统计口径为端到端计时（从发起请求到拿到最终图片 URL），统一输出分辨率，均为热启动且不包含参考图上传时间。
这次生成图片的提示词我们改成养眼些的：

提示词：你在（温泉内）泡温泉的写真

模型	生成耗时	图片
xai:grok-imagine-image:edit	14.9s
doubao-seedream-4-5	32.4s
doubao-seedream-5-0	20.5s
Hunyuan-3.0	11.3s
qwen-image-edit-plus	10.7s
qwen-image-edit-max	24.6s
gemini-3-pro-image-preview	38.2s

可以看到fal的grok模型、hunyuan3.0和 qwen-plus 都比较快，seedream 稍慢一些，gemini 最慢。效果上，这次grok也不错，水波和折射都体现了出来；seedream4.5的这一身衣服，似乎对泡温泉有点误解，而 seedream 5.0的这张让我想到了灵儿在洗澡；hunyuan3.0这张其实挺好，气雾以及身上的水珠等，但这参考图中的围巾你是不是忘记换掉了？qwen-plus 比较写实，但环境有点假；qwen-max有点用力过猛，感觉人物有点不一致了；而这次Gemini 3比较特别和大胆，将人物发型处理过，人也还挺像并且特别真实，整体不错，就是太慢了点。

从这几个结果来看，你觉得哪个模型更好呢？

其它探索

上面的模型如果免费额度用完了怎么办？一种思路是转向本地推理/自托管：把生图能力放到自己的设备上跑，成本更可控，也更踏实。“众所周知”俺有个丐版的 Mac Mini M4，如果能在它上跑生图就更棒了。我知道可以，但效果和时间怎么样呢，我们来试一下。

刚好前阵子研究了一下 ComfyUI，它也支持 API 调用的方式，于是我借助 ComfyUI 来生图，以下是我的工作流，使用了一个 16G 内存能撑下的小模型来进行生图测试。

随便拉了一个生图流程，使用的是 flux.1-schnell-Q2模型，居然消耗了 1000 多秒，期间内存一度快用爆了。换了 z-image-turbo 等模型，效果也不太理想， 参数大了跑不动：（

我在 RunningHub 平台上还有积分，于是尝试用更大的 flux 做一次图生图对比。

好像不太行，或许换一个别人分享的workflow效果会更好点。不过RunningHub即使生图效果不错，没开通会员也不让调用 API，这和我们想要集成到OpenClaw中使用的需求不符。

我也尝试在fal 平台跑 ComfyUI，但是奇怪的是速度慢的出奇，还没有地方看进展等—有点黑盒，这块估计不是这个平台的主要功能，相关交互也很一般，遂放弃。但是如果有一台强悍的本地电脑，比如有不错的 N 卡和较大的显存，这条路或许能通。

闲言

当前在 2026 年，对接这些 API（鉴权、调用、回传 URL、错误重试）已经非常方便。在 OpenClaw 上，你下达命令后，Agent 往往能在几分钟内帮你把事办了。 比如在撰写本文期间，Google 发布了 Banana2 模型，我仅通过手机发出指令，便将其集成并更新到了 GitHub。

要说 OpenClaw 的使用感受，有一点粗浅的启发和思考：

• OpenClaw 的 skill 及热加载能力，让其自我进化有了空间。有种软件从以前的发布即终止，到现在有了生命，或者说可自我进化。这其实是有质的变化的，但这种变化如何正确的被使用，它可以快速修复一些问题，也可以把自己搞晕。如何更好的管理自己的“版本”，才有持续迭代的地基。
• OpenClaw 所操作的内容，基于 chat 模式其实有其局限性。想象我们在使用一个助理（我本人没有助理，咱“想象”一下），一个任务的完成涉及多方面的信息，它不只是一个结果。助理可能会有一些信息需要你确认或审批，并在过程中与你沟通细节，助理会在你着急的时候说就快完成了。可是现在龙虾(OpenClaw)不会，甚至不稳定的情况下还要你去再询问一下。简单说，安全性、可视化、可控性等有所欠缺。

还有，目前其实对于稍复杂一些的任务，OpenClaw的完成率还有限，网上各种跑通 XX 的分享及售课等让我感觉像在收割，让我也不确定是自己的问题还是模型或者插件不对，但我更觉得他们在骗人：）因为我已经用了最好的模型了，也对比使用过多种插件了，啊哈。

我觉得这次的龙虾热，其实是 LLM 及 Agent 发展以及 MCP/Skill 等技术陆续铺垫后，这些技术在传统的如 Code Agent之外，于普适的场景下人们突然看到、感受到它的价值而产生的 AI 落地浪潮，或许它离我们心中想象的那个未来的智能助理还有些距离，但至少它呈现了一个信号，像宇宙中突然爆炸的某颗超新星，璀璨、耀眼又明亮让人无法忽视。

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：爱折腾的风