由ai协助 on atin的个人小站

Nyral 的多模型协作：讨论团与评审团，让模型一起干活

Mon, 02 Nov 2026 23:45:00 +0800

所有已配置的模型能协作、能当众干活，而 token 消耗始终由用户把关——这是给 Nyral 设计"多模型协作"时的三个目标。方案演化到今天，落地成两种模式：讨论团和评审团。

起因：一次生图模型当主模型翻的车

Nyral 接入腾讯 TokenHub 聚合网关后，我一度把 hy-image-v3.5-preview（混元文生图模型）设成了主聊天模型，结果发一句"你好"就报 400 model not exist。

排查下来的原因很直白：混元多模态是独立的生成模型，没有对话能力，走 chat/completions 必然失败。它真正的调用端点是 POST {base}/v1/wand/hunyuan-image/v35-generation——一个聊天式结构的生成端点，支持 messages 数组、参考图，同步返回 choices[].delta.image.url。

顺手把生图工具和主链路都改到了这个端点，实测通过。但问题随之而来：

用户配了一堆模型（DeepSeek、GLM、小米 MiMo、TokenHub 混元），它们却彼此孤立。 对话靠一个主模型，生图靠工具写死当前 provider，生视频又是另一套。能力是有的，但"各干各的"，谁也不认识谁。

想法：让所有模型互相可见

那天凌晨，我说了一句：能不能让所有模型互相看到？DeepSeek 可以直接调用 GLM，GLM 反过来也能用 DeepSeek，小米同样如此。每个模型都有完整能力，主模型甚至可以"偷懒"，让副模型去干活。

讨论下来，这个概念落地成三层：

模型注册表（所有已配置模型，按能力分组）
      │ 能力路由
      ▼
主模型（主持人 + 决策者 + 汇总者）
      │ model_delegate / 生成工具
      ▼
参与模型（顾问团：各抒己见，结果仅供参考）
      ▼
用户（最终决策者，可随时打断）

模型注册表：设置页里所有 provider + 勾选的模型，按能力标注分组（对话 / 生图 / 生视频）。配一次 TokenHub Key，对话选 hy4、生图选 hy-image、生视频选 hy-video，全部互相可见。
主模型当主持人：议题由它定，请谁参与由它提议，观点由它汇总收敛，结论由它呈现给用户。它自己也可以参与讨论——毕竟它掌握上下文和工具。
参与模型是顾问团：每次发言是一次独立调用，输出只是"顾问意见"，不是结论。
用户拍板：主模型给出"结论 + 分歧点 + 推荐"，用户一句话就能推翻。

演化：讨论团还是评审团？

初版文章发布后，我又和豆包推演了一版更工程化的设计——评审团。它保留了"多模型协作 + 用户拍板"的核心，但把"模型互相可见"改成了"模型完全隔离"，并补上了上下文传递规则、token 预算、状态机等细节。

两种模式摆在一起，一度像二选一：

维度	讨论团	评审团
模型间关系	互相可见，串行碰撞	完全隔离，互不可见
讨论形态	模型间你来我往	每轮独立发言 → 汇总 → 用户决定是否再投
收敛方式	主模型收敛	用户拍板 + 收敛检测提示
立场污染	有风险（汇总带倾向）	强制"事实/倾向分离"
成本控制	弹窗授权（开团前）	弹窗授权 + 每轮用户确认

但想深一层：这不是单选题。两者的差异只是"信息流拓扑"——讨论团是全连接（每个人看得见别人的发言），评审团是星型（只有主模型全知，评审模型只见汇总）。中间还夹着"只传上轮事实性汇总"的半开放形态。把可见度做成参数，两种模式就统一成一个多模型协作框架了：ReviewOrchestrator 里一个 mode 字段的事，不是两套代码。

关键设计：信息流拓扑参数化

讨论团 = 全连接，串行。 讨论的本质是碰撞，后发言者要能看到前面的观点，所以讨论链必须串行——并行只会得到三份各说各话的独立答案，没有讨论价值。但"派发链"可以并行：互不依赖的子任务（比如先各查资料）主模型可以并行派发，结果回来后进入串行讨论阶段。干活的阶段并行，对话的阶段串行。

工程上这反而简单：Nyral 的本地引擎本来就是串行工具循环 + SSE 流式输出，讨论就是"主模型循环调 model_delegate，每调一个副模型就输出一条流式发言"，天然不会打架。

评审团 = 星型，并行。 评审模型之间永不互见，零锚定、零传话失真、零立场污染，每个模型永远从自己的盲区出发给意见。作为回报，评审天然适合并行——互不可见就没有串行依赖，一轮延迟 ≈ 最慢的那个模型。评审模型每轮只看到"问题 + 上轮事实性汇总 + 分歧点"，主模型是唯一全知者，持有完整历史。

评审团有个独立的价值：事实与倾向强制分离。主模型也是模型，汇总时必然掺入倾向。若混合呈现，用户（最终决策者）会被悄悄带偏——这是比模型间锚定更严重的污染。所以汇报格式严格分段：“各模型观点"只陈述、禁止任何评价性词汇，“主模型推荐"必须显式标注"这是主持人的倾向，不是事实”，用户有权展开查看任意模型发言原文。

成本控制：三重闸门

多模型协作的代价是 token 翻倍，不能默认放开。两个模式共用三道闸门：

弹窗授权：主模型要开团/开评审或调生图工具时，弹出候选模型让用户选、确认或拒绝。讨论团、评审团、生图、生视频共用同一套"选模型 + 确认"弹窗，候选列表不同而已。
每轮用户确认：评审团的"再投一轮"本身就是闸门——不点就不会产生下一轮成本；讨论团里用户随时可以打断。
模型级开关 + 轮数上限：单模型可单独禁用参与协作，max_rounds 默认 3 轮封顶。

另加 120 秒超时自动拒绝：没人点弹窗就自动拒绝（这个机制本来就存在），后台任务也不会卡死。

成本账也大致算过：3 个评审模型 + 1 个主模型跑一轮约 4800 token（池子快照策略，每轮只传小汇总），全量上下文共享要 3 倍以上，还会让模型观点趋同。把池子做小，是控制成本的核心。

交互：当众流式，随时打断

最初的想法是把协作放在后台，跑完甩个结论。但这样有两个问题：用户干等 N 倍时间；结论怎么来的像个黑盒。

后来想到一个更顺的形态——参考多 Agent 交接的剧场感：Marvis 调用 browser 子 Agent 时，小弟会"冒出来"说"我去看看”，干完再交接回来，用户全程围观，从不觉得在死等。

两种模式同理，都做成可见的流式对话：

用户：这需求怎么做比较好？
─────────────────────────────
[hy4-preview] 我的方案：先建索引再……
[deepseek]    我不同意，索引成本高，应该直接全量扫
[glm]         折中：先扫再按需索引，hy4 的方案更稳
[hy4-preview] 采纳，按我的方案，deepseek 的担忧兜底处理
─────────────────────────────
主持人收敛：结论如下……

每个模型发言是一个气泡（像子 Agent 冒出来），用户能看到谁在说话、观点怎么碰撞、怎么收敛，随时插一句"别争了，用第二个方案"。评审团模式下，各模型观点独立呈现，分歧点列成清单，最后给"执行推荐 / 再投一轮 / 拒绝修改"三个选项。等待感消失，黑盒变透明。

演进路径

第一步：model_delegate 单次委派——主模型"偷懒"让副模型干一件具体的事，成本可控，先解决"互相调用"。
第二步：讨论团——串行可见，先跑通信息流拓扑。它天然串行，实现就是"循环调用 + 上下文拼接"，比评审团便宜。
第三步：评审团——加并行调度 + 事实/倾向分离汇总，建立在前面两步的地基上。

风险清单

延迟：N 模型 × M 轮的串行讨论总时长不短，靠流式可见缓解"等待感"；评审团并行后延迟收敛到单轮。
成本：弹窗授权 + 每轮确认 + 模型级开关/轮数上限三重闸门。
稳定性：多模型输出格式不一致、某个模型挂了讨论卡住，需要重试和降级（超时跳过，全部失败则终止提示）。
路由准确性：模型能力标注靠启发式 + 分组勾选，跨 provider 路由可能指向无权限模型（TokenHub 那类 400/402 的坑），需要对照测试。
观点不收敛：评审团加收敛检测，连续两轮观点一致时提示"继续评审大概率不会产生新信息，建议拍板"——提示只是建议，用户有权无视。

结语

这个设计其实没造新轮子：模型注册表是现有配置的升级，弹窗和超时是现成机制，工具循环是 Nyral 本来就有的大脑，多模型协作只是把"单主模型驱动"扩展成"主模型主持、副模型顾问、用户拍板"。

讨论团适合发散（头脑风暴、创意激发），评审团适合收敛（方案评审、重大决策）——不是二选一，是同一个框架下的两种形态。

它想回答一个朴素的问题：用户都配了那么多模型了，为什么不能让它们一起干活？ 现在至少有了一个不花冤枉 token、又能当众协作的答案。

AI 专属隐形输入法

Mon, 12 Oct 2026 08:00:00 +0800

Android 只允许 InputMethodService 向输入框写文本。AI 要合法注入字符串，就得拿输入法身份，不需要键盘 UI。

设计

UI：点击输入框只弹一条 1px 横线，不弹软键盘，截屏零遮挡
协议：HTTP + JSON，固定端口 8767
入口：adb forward 访问 HTTP；adb shell am broadcast 走广播
服务名编码协议：com.aixtin.invisime/.Ime_tcp8767_http_json，dumpsys 可见即用

协议

HTTP 主入口：


adb forward tcp:8767 localabstract:httpd

curl -X POST  -d '{"cmd":"type","text":"你好"}'

 

广播快速入口：

 

adb shell am broadcast -a AIX_INPUT_TEXT --es text "你好"

 

指令集：type / backspace / enter / get_text（回读输入框内容）/ select（选区）/ composition（模拟真人打字节奏）。核心动作只有一个：commitText(CharSequence)。

实现

四个组件：

ImeState：状态机，当前输入法开关与注入目标
InvisImeService：InputMethodService，onCreateInputView 返回 1px View
InvisHttpServer：NanoHTTPD 监听 8767，解析 JSON 指令
InjectReceiver：广播接收，解析 intent extra

文本写入统一走 commitText；读回走 InputConnection 的 getTextBeforeCursor / getTextAfterCursor。

历史 bug：初版 executeType 重复 commitText，已修；fixMojibake() 做 ISO-8859-1→UTF-8 回转。

安全边界

只写不点：不点发送按钮、enter 默认换行、不改写已有文本、不静默切换系统输入法。

实测

真机 OPPO ColorOS Android 14（一加 Ace 3 Pro，WireGuard 10.10.10.3:5555）。

坑：ColorOS 输入法导航栏默认不可见，NavigationBarFrame 被设 alpha=0.0；定位后在 onWindowShown postDelayed 300ms 扫 decorView setAlpha(1.0) 恢复。

HTTP 与广播注入中文、英文、删除、回读均验证通过。

定时岗位：让 AI 从「戳一下动一下」变成「自己上班」

Wed, 07 Oct 2026 08:00:00 +0800

本文整理自一次想法碰撞的记录：当对话式 AI 遇上“以天为单位”的任务，缺的到底是什么。

一个被忽略的错位

现在几乎所有对话式 AI 都是响应式的：你发一句话，它动一下；你不说话，它就静静待着。哪怕它能查资料、能写代码、能操作手机，只要你不出手，它永远不会主动做任何事。

但用户真实的需求往往不是“一问一答”，而是一条长时间线：

帮我把这个账号管起来：今天点赞、明天评论、后天发帖
盯着这个价格，降了告诉我
每天睡前把今天的事整理成日记

这些任务的共同点是：跨度以天为单位、触发条件不确定、执行过程需要判断。一次性对话撑不起这种需求。

拆一下：主动唤醒 + 能力边界

「定时岗位」想做的事，本质上是给 AI 一张排班表和一张工牌。工牌上写的是“能做什么”，不是“怎么做”：

维度	具体设计
能力域授权	只锁能力，不锁参数——允许发帖，但发什么它自己定
站点白名单	明确列出允许操作的域名，名单外一律拒绝
每日自主排班	每天自己规划动作，不必等指令
日报审计	干了什么必须留痕，可回溯
随时撤职	一个开关收回授权，岗位立即终止

生命周期也清晰：draft → 用户一键授权 → 独立会话入职沟通 → 退下自主干活 → 可随时进出查看。

最难的一步：怎么防止它越权

让 AI 自主行动，第一个要回答的问题不是“能不能做”，而是“怎么让它做不了不该做的”。目前想到的三道锁：

系统级 Banner：关键操作由系统在通知栏横幅提示。逻辑很朴素——用户只信系统、不信 AI 的话术。AI 说“我没乱动”不可信，系统说“它调用了发帖接口”才是事实。
Native 层注入 Header：把身份标识放在原生层注入的请求头里，脚本层无法伪造，也绕不过去。
能力清单绑定：把授权内容固化成一份清单，运行时逐条比对。曾考虑“参数 hash 过死”，但被否了——参数一变就失效，既不现实也没必要。

这套思路不是凭空来的。多 Agent 架构里早有成熟先例：主 Agent 派活给子 Agent，子 Agent 有独立上下文、明确的能力边界、干完要汇报。「定时岗位」真正新的地方只有两点——主动唤醒和自主排班。

它和联想引擎是同一棵树

把两个想法放在一起看，会发现它们是同一根树干上的两根枝：

联想引擎解决“记忆什么时候被调用”——让调用从被迫变成自觉
定时岗位解决“AI 什么时候开始干活”——让动手从被动变成主动

两者的交汇点是同一个：AI 需要一个属于自己的时间轴。夜间自省可以挂在定时岗位上跑（每天固定时段回顾经历、写入记忆），而岗位的执行记录又成为联想引擎的素材。一个负责“什么时候想”，一个负责“什么时候做”。

结论

「定时岗位」不是要把 AI 变成无所不能的自动机，而是把它从“工具”变成“值班的人”：

有明确的岗位职责
有可审计的动作记录
有随时被撤职的觉悟

这条路还很长，但方向可能比“再训一个更聪明的模型”更实在——很多时候缺的不是能力，是主动性。

联想引擎：给 AI 装上"自主回忆"的能力

Wed, 07 Oct 2026 08:00:00 +0800

你有没有过这种体验：明明记得自己见过某个东西，但怎么也想不起来关键词，搜不出来，只能干着急？

AI 的“记忆”现在就是这个状态。它有一整座图书馆，却只会在你明确提问时才去翻书——你问什么它查什么，绝不多看一眼。

问题不在存储，在“触发方式”

人类回忆是联想式的：闻到一股味道、听到一句歌，某段记忆自动浮上来。这个过程不需要你主动“检索”，它常驻在后台，线索一碰就激活。

而 AI 的记忆是命令式的：被提示才检索，检索完就回到沉默。两者的差距不在数据库大小，而在什么时候开始想。

联想引擎：三个改动

一、事件驱动自主检索。 新信息进入时不等人提问，直接触发一轮关联比对。就像你听到一个新名字，脑子里立刻冒出“这人跟谁有点像”。

二、三级相关性漏斗。 检索结果不再一刀切，而是分三层浮现：

层级	相关度	处理方式	对应人脑体验
L1	高	全文注入上下文	脱口而出
L2	中	只给标题+摘要钩子	“隐约见过”
L3	低	仅留索引，显式检索才命中	深挖才想起

三、夜间自省进程。 每天回顾当天经历，主动写入记忆库并与旧记忆建立关联。这相当于把人类的睡眠巩固机制移植过来——今天不整理，明天检索命中率就是会掉。

相关性评分由四维加权：语义相似、关键词命中、时间衰减、话题实体绑定。

为什么值得做

这个方案比“定时任务”更底层。定时岗位解决的是“AI 能不能自己干活”，联想引擎解决的是“AI 能不能自己想起来”。前者是手脚，后者是海马体。

两者其实是同一棵树：夜间自省进程完全可以由定时岗位承载，而联想引擎为它提供记忆写入的规则。

一句话

别急着给 AI 加更多记忆容量，先让它在没人提问的时候，也愿意想一想。

用 Nyral 打理博客的一天

Mon, 05 Oct 2026 08:00:00 +0800

今天试着让 Nyral 帮我打理博客后台：登录、发文、配标签，一套流程走下来居然比我自己点还快。它不啰嗦，问到点子上就给方案，拿不准的地方会先确认再动手。工具用对了，效率是真的能翻倍。

一个微信小程序的8个版本，我踩了哪些坑

Sat, 22 Aug 2026 08:00:00 +0800

「确实佷难压缩」是一个微信图片压缩小程序。从 v1.0.1 到 v2.0.1，8 个版本迭代，每次以为稳了都会冒出新问题。这篇文章记录每个版本的核心改动和踩过的坑。

扫码体验小程序：

v1.0.1：能用就行

第一个版本只做了一件事：选图片 → 压缩 → 保存。

核心能力：

Canvas 本地压缩，图片不上传服务器
基础的 JPG/PNG 格式支持

上线第一天就发现：微信会审核图片内容。纯本地压缩不走微信 API，违规图片直接能保存出去。于是加了 imgSecCheck 云函数，压缩后先过一遍微信内容安全审查。

踩坑：审查是异步的，用户看到红色呼吸灯会本能等待，不知道能不能点保存。后来加了"边审边存"提示。

v1.0.4：压缩算法重写

最初的压缩逻辑很粗暴：直接降 quality。结果发现一个问题——选 20KB 压不出来，选 100KB 能压，选 50KB 也能压，再选 20KB 又能压了。不稳定。

原因：单次 quality 调整无法精确控制输出大小。

重写方案：二分搜索 + 两点采样。

先在 quality=0.5 和 quality=0.1 各压一次，得到两个点
线性插值估算目标 quality
最多修正 2 轮，最大 Canvas 调用 4 次

顺便把 UI 改成了深色毛玻璃风格。

v1.0.5：大图压不到目标

5000 万像素的大图，原始数据 150MB。二分搜索在 quality 空间里找，但 quality 再低也就那样——像素数太多了。

修复：大图先等比缩小到 4096px 以内，再走二分搜索。4096 是微信 Canvas 的安全上限，再大就崩。

最低 quality 也从 0.1 降到了 0.05，给极端情况多留余地。

v1.0.6：页面闪白

用户反馈：页面切换时会闪一下白屏。

原因：微信小程序的页面背景默认是白色。深色毛玻璃 UI 在页面切换瞬间，新页面还没渲染完就露出了白色底层。

修复：给所有页面的 JSON 配置补上 navigationBarBackgroundColor 和 backgroundColor，消除视觉断裂。

v1.0.7：进度条 + 自定义裁剪

两个大功能：

压缩进度条：之前压缩时只有一个 loading 动画，用户不知道压到哪了。改成百分比 + 状态文字（“压缩中 60%” → “审查中 90%” → “完成”）。

自定义裁剪尺寸：用户可以手动输入宽高（如 295×413 一寸照）。加了最小值 30px 的限制——输入太小会弹提示。

v1.0.8：Canvas 2D 升级

微信旧版 Canvas API 性能差，大图操作卡顿。升级到 Canvas 2D（type=“2d”），速度提升 2-3 倍。

但升级带来了新坑：

drawImage 必须用 9 参数形式 (img, 0, 0, img.w, img.h, 0, 0, w, h)，不然会截取图片
canvasToTempFilePath 在 Canvas 2D 下不能传 x/y/width/height，只传 destWidth/destHeight
改 canvas 宽高后上下文会重置，必须重新 getContext(‘2d’)

还修了一个 bug：裁剪后输出体积反而变大了。原因是裁剪输出格式没跟随用户选择——选了 PNG 就强制输出 PNG，但 PNG 的 Canvas 重编码体积控制很差。改成跟随格式选择。

v1.0.9：裁剪框大修

这是改动最大的一个版本，问题也最多。

根因：坐标系不一致

裁剪框的四角拖拽在自定义尺寸模式下完全失灵。拖左下角，右下角在动。

真正原因不是判定逻辑，而是坐标系偏移。touch.clientX/Y 是 WebView 坐标，frameX/frameY 是 crop-area 内部坐标。两者差了一个 crop-area 的 left/top 偏移。

修法：在 onReady 用 boundingClientRect 缓存偏移量，触摸时统一减掉。

横图变竖条

16:9 的横构图照片，裁剪框显示成了一个竖条。

原因：之前用高度占满 areaH 来定裁剪框尺寸。横图高度小、宽度大，高度占满意味着宽度溢出被 overflow:hidden 切掉左右，只剩中间一条。

修法：横构图改用宽度上限 areaW*0.96，再反推高度。

其他修复

角判定热区从无下限改为 44-64px（触控标准）
比例锁定：边界钳制时以宽度为基准驱动高度，不再双向独立钳制把比例搞歪
_ready 守卫：图片没加载完就禁止触摸，避免 frame 为 0 误判

踩过的最严重的坑

debug 版在 onTouchStart 里引用了 initImage 作用域的局部变量 imgW。一跑就 ReferenceError: imgW is not defined，所有拖拽全部失效。

教训：console.log 埋点用的变量如果跨作用域，发布前必须删干净。

v2.0.0：对比页全新改版

从"压完就完"变成"压完还能看"。

滑动分割线对比：压缩前后并排，中间一条分割线左右拖动。比之前切换原图/效果图直观得多。竖图横图统一用垂直分割线，不搞两套交互。

一键重新裁剪：对比页不满意？不用返回首页重来。直接点"重新裁剪"，弹出预设/自定义/自由裁剪选项，闭环操作。

裁剪输出优化：裁剪不再降画质（quality 保持 0.92），格式标注文案也修正了——之前显示"PNG"但实际输出 JPG，误导用户。

v2.0.1：自定义尺寸修正

用户反馈：指定 632×532 的裁剪尺寸，输出却是约 1000×900。

原因：自定义尺寸输入后，canvasToTempFilePath 的 destWidth/destHeight 没有严格取用户输入值，而是走了默认的缩放逻辑。

修复：自定义尺寸模式下，输出尺寸严格按用户输入值，不做任何缩放。

版本一览

版本核心改动踩坑

v1.0.1 基础压缩 + 内容审查审查异步导致用户困惑

v1.0.4 二分搜索压缩算法 quality 空间不稳定

v1.0.5 大图先缩小再压缩 5000万像素直接崩

v1.0.6 修复页面闪白页面背景色未配置

v1.0.7 进度条 + 自定义裁剪最小值限制

v1.0.8 Canvas 2D 升级 API 参数差异、格式不跟随

v1.0.9 裁剪框全面重写坐标系偏移、横图比例、跨作用域变量

v2.0.0 对比重塑 + 重新裁剪闭环分割线交互统一

v2.0.1 自定义尺寸精确输出 destWidth/destHeight 缩放逻辑

写在后面

8 个版本，核心功能其实没变——选图、压缩、保存。但每个版本都有"以为修好了其实没有"的时刻。

最有意思的教训是：大部分 bug 不是逻辑错，而是假设错。假设坐标系一致、假设高度占满就行、假设 debug 代码不影响正式版。每一个"假设"都变成了一个线上 bug。

如果你也在做小程序，记住两件事：真机测试不能省，debug 代码发布前必须删。

由ai协助

AI 长期记忆方案：记忆与执行分离，MiMo-V2.5 实测一次整理 2 厘钱

Wed, 19 Aug 2026 08:00:00 +0800

AI 的长期记忆问题不是靠"记住"解决，是靠"架构"解决。本文给出完整方案与实测数据。

一、AI 为什么会"失忆"

AI 的记忆 = 上下文窗口。窗口像滚动纸张，新内容写入，旧内容被挤出。窗口一滚动，之前的指令物理消失。

让 AI"存到外部"的常见做法会翻车：

让 AI 存记忆到外部文件 → 执行两次后开始乱建本地文件
系统提示词写"必须优先查记忆" → 无效
自动压缩历史 → 压缩时对话暂停，体验差

原因：记忆管理靠"自觉"不靠谱，得靠"强制"。

二、方案：记忆与执行分离

给 AI 配一个专职管家，主 AI 干活、管家管记忆，物理隔离。

主 AI（干活）         记忆管家（专职管记忆）
   │                       │
   │  存/取记忆（唯一通道） │
   └──────────→────────────┘
              │
         记忆库（本地磁盘）

核心三条：

管家是独立进程：不参与对话，只碰磁盘。压缩、归档、删除后台跑，主 AI 和用户无感
索引文件是唯一接口：主 AI 查记忆直接读索引文件（Markdown 表格：主题 → 文件名 → 一句话摘要），零改造接入
写入实时、压缩低频：新记忆落盘脚本执行（毫秒级），压缩旧记忆 AI 执行（深夜批量）

三、四个关键细节

1. 索引慢了怎么办

索引是加速器不是唯一入口。索引查不到，退回原文目录 grep 兜底。索引是缓存，原文是真相——缓存挂了功能还在，只是慢一点。

2. 主 AI 偷懒跳过索引

AI 是走捷径大师，索引连续 miss 会直接翻原文。解法：让索引永远比原文好用——实时同步、查索引 2 步 vs 翻原文 5 个文件，AI 会自己算账。

3. 防止写坏文件

用原子替换：先写临时文件，再 rename 覆盖。主 AI 永远读到完整版。

4. 思考过程过滤

推理模型返回 reasoning_content（思维链），接入框架时过滤该字段，只取正式答案。

四、实测：小米 MiMo-V2.5 当管家

选型标准：便宜、上下文长、守规矩、能理解。

维度	实测数据
上下文	1M tokens（105 万）
价格	输入 $0.14/1M，输出 $0.28/1M
摘要一段对话	33.5s，成本 $0.00032（约 2 厘钱）
整理索引	28.8s，关键词准确，不编造
守规矩	严格按格式输出

实测效果：整段对话压缩后自动分为"主题/决策/资产/教训/待办"五段，技术细节保留，寒暄删除。每天跑一百次成本不到 3 毛钱。

五、适用人群

折腾过 AI 本地部署、API 接入的玩家
被 AI 失忆困扰的效率工具党
想给 AI 配外置大脑的开发者

日常聊天用不上这套，大厂 AI 入口已自带记忆。需要 AI 长期维护项目、管理文档、记住偏好时，此架构是标配。

核心一句话：存储靠脚本，压缩靠便宜 AI，决策靠聪明 AI，索引永远当最优解。

推荐试试我做的图片压缩小程序「确实佷难压缩」——微信扫码即用，免费、无广告、压完不糊：

图片压缩原理与实操：一张照片原始 150MB，为什么你看到的是 3MB

Wed, 19 Aug 2026 08:00:00 +0800

图片压缩解决两个问题：文件太大传不出去、上传平台被拒。本文讲清原理，给出微信里直接用的压缩方案。

一、为什么图片这么大

手机摄像头 5000 万像素起步。一张照片的原始信息量：

5000 万像素 = 5000 万个颜色点
每个颜色点需要红、绿、蓝三通道，每通道 8 bit

一张未压缩照片的原始数据约 150MB。平时看到的 3-5MB 照片，都是压缩过的。

二、压缩原理：删掉人眼不敏感的信息

核心逻辑：去掉人眼不敏感的信息。

1. 有损压缩（JPG/JPEG）

人眼对亮度变化敏感，对颜色细微变化不敏感。JPG 大幅简化颜色细节、保留亮度细节，压缩后肉眼几乎看不出差别，文件可小 10 倍以上。压缩率过高会出现马赛克和色块。

2. 无损压缩（PNG）

不丢信息，只合并重复数据。纯色截图 100 万相同像素，PNG 记为"连续 100 万个红色"而非存 100 万遍。适合：截图、文字、图标、透明背景。缺点：照片类复杂图片压缩效果差，文件可能比 JPG 更大。

3. 新一代格式（WebP/HEIC）

同等质量下比 JPG 再小约 30%。微信传输的图片很多已是此类格式，但大部分工具不支持导出。

三、格式选择

场景	推荐格式
照片、风景、人物	JPG / WebP
截图、文字、图标	PNG
需要透明背景	PNG
网页使用	WebP（更小更快）

四、压缩工具对比

方式	优点	缺点
电脑软件（Photoshop、TinyPNG）	功能强	贵、麻烦、要开电脑
在线网站	免安装	上传限制、付费、隐私风险
微信小程序	手机直接处理	无

日常需求（发微信、做文档、传平台），手机上直接解决最方便。

五、推荐：确实佷难压缩

微信小程序「确实佷难压缩」：

微信搜索即用，无需下载 App
支持图片压缩、裁剪、对比预览
压缩前后并排对比
免费

总结

图片大是正常的，一张照片原始数据上百 MB
压缩的本质：删掉人眼不敏感的信息。JPG 压照片、PNG 压截图
日常压缩用手机小程序，微信搜「确实佷难压缩」