atin的个人小站

Nyral：开源、免 Root、自托管的 Android 智能体助手

Thu, 22 Oct 2026 19:30:00 +0800

把大模型、端侧长期记忆、SSH 远程操作和语音、附件多模态，全部收进一部手机里。

它是谁

Nyral 是一款跑在 Android 上的开源智能体（Agent）助手。它不是那种套个聊天框就完事的"AI 外壳"，而是把多模型对话、本地长期记忆、SSH 远程运维、联网工具、语音输入和附件多模态整合进了一部手机。

四个关键词说清它的立场：开源 · 免 Root · BYO 模型 · 数据自托管。

对话、记忆、Token 统计、SSH 配置默认只存在本机，不注册账号；
没有行为追踪，没有统计 SDK，也没有广告 SDK；
不需要 Root，装上 APK 就能用；
模型由你决定：任意 OpenAI 兼容端点，云端或自建都行；
源码 MIT 许可，托管在 GitHub。

GitHub 仓库：https://github.com/aixtin/nyral

核心能力

对话与模型

多供应商按需切换：MiMo 全模态 / DeepSeek / GLM / 任意 OpenAI 兼容端点，还支持自定义模型，并按模型分别勾选能力；
流式输出：思考段打字机效果 + 正文流式 Markdown 渲染，思考和工具调用的过程都可以折叠；
消息内 Markdown 表格：表格是气泡内独立的块级视图，流式输出时也能实时排版；
思考强度分档：按供应商能力显示"自动 / 开关 / 低中高"，不支持的档位不会出现；
语音输入：长按说话、上滑取消、60 秒上限自动发送，微信式的语音气泡。

附件多模态

图片：本地压缩（长边 2048）后发送，不白烧流量；
视频：超过 37MB 的本地转码压缩，气泡里内嵌首帧缩略图；
文档：PDF / txt / md / docx / xlsx 在本地解析成文本直接注入上下文，不占视觉 token；扫描版 PDF 会自动渲染成页面图片，走视觉通道；
一条消息最多 6 个附件，App 内可全屏预览（图片缩放、视频播放、PDF 翻页、文本复制）。

长期记忆（端侧）

bge-small ONNX 端内语义向量 + 关键词双路召回，存储在 SQLite；
三级分层：短期滚动窗口 → 单槽滚动摘要 → 长期全文 + 语义检索；
可以单独配一个"辅助 AI"做记忆索引，不占用主对话模型；
待处理队列持久化 + 原子消费事务，进程被杀也不丢消息、不重复归档。

工具调用（21 个内置工具，40 轮上限）

联网：web_search（搜狗手机版 → Bing RSS → Bing → 百度四引擎轮转，国内可直连、免 key）/ web_fetch / web_download / site_auth；
SSH：ssh_run 与 file 远程读写、上传下载，支持跳板机、ED25519 密钥和双认证——手机就是随身的运维终端；
执行：js_run（ClassShutter 沙箱限制类访问）/ sh_run（本地 Shell，危险命令拦截 + 提权）；
设备：app，通过无障碍控制第三方 App；
文件：workdir，AI 把文件拉到本地目录改完再推回去，避开 SSH 引号地狱；
浏览器接管：内置 Agent 浏览器原型，AI 全屏接管 WebView，逐步播报 + 高亮提示，遇到验证码会一键交还给你；
定时任务：timer_task_create，先分析目标，再列出需要的危险工具授权清单，一次性批准后准时上班。

安全

危险操作二次确认：确认后执行，同参数 5 分钟内免重复确认，拒绝立刻中止并给出回执，超时自动拒绝，全程留痕；
SSRF 防护（校验重定向目标）+ 日志脱敏（非 2xx 响应体、SSH 私钥内容不会明文落日志）；
沙箱执行、危险命令拦截、SSH 主机密钥校验，未知主机直接拒绝。

界面

多会话管理（置顶 / 删除 / 搜索），会话全文搜索（正文 + 思考，按相关度排序）；
Token 用量统计，主 AI / 辅助 AI 双通道，累计、每日、单会话都能看；
运行日志、前台服务保活通知；
聊天背景（预设渐变 / 自定义图片模糊）、全局动画体系。

谁适合用

开发者：把 SSH 和文件操作装进手机，随时随地连回服务器；
普通用户：想要一个真正自托管、不裸奔的 AI 助手，数据留在自己手里；
开源爱好者：MIT 许可，随便读、随便改。

快速开始

安装 APK，打开「设置 → 模型配置」，填入任意 OpenAI 兼容端点的 Base URL 和 API Key；
（可选）在 SSH 配置里添加远程主机，支持密码或私钥，也支持跳板机；
直接开聊，AI 会按需调用工具，工具调用的进度折叠在气泡里；
长期记忆会自动归档，说一句"记住 xxx"就会立刻归档。

系统要求：Android 10+（minSdk 29）、arm64-v8a，以及至少一个 OpenAI 兼容端点。

自己构建

git clone https://github.com/aixtin/nyral.git
./gradlew assembleDebug
# 产物：app/build/outputs/apk/debug/app-debug.apk

需要 JDK 17、Gradle 8.13、Android SDK 36。仓库内置了阿里云镜像配置，国内构建会快一些；不在国内的话把 settings.gradle.kts 里的 maven(...) 行删掉即可。

一点说明

项目从 2026-10-16 起进入维护模式：只修安全和稳定性问题，不再加新功能。这 54 天是怎么一点点做出来的，写在仓库的 END.md 里。

数据是用户的，代码也是用户的。

梦档案：《复制墨水》绘图软件

Tue, 20 Oct 2026 08:00:00 +0800

记录日期：2026-10-20（醒后立即口述抢救）来源：一场梦境，醒后向 DeepSeek 逐条描述，本档案为全部细节的整理汇总。

一句话概括

梦里出现一个固定在屏幕中间小窗、浅灰白厚重 UI 的绘图软件：打开先看到红蓝双儿童魔女的标志画面，进入工作区后点按钮会弹红色横条报错；核心功能是「复制墨水」——触发后从你的电脑屏幕右半边开始绕圈旋转，与魔女手里的笔记本屏幕重合/穿越，从魔女的电脑里转出来，然后用一支笔尖凭空沾墨的画笔，给一个高写实成年魔女补三四笔眼睫毛，像补妆。

一、软件界面与质感

窗口形态：不是全屏，打开后固定居中一个小窗。
布局：左侧工具栏 + 顶部工具栏 + 中央工作区，结构像 PS 类绘图软件，但布局完全不同，更精致。
UI 质感：浅灰白，白里偏一点灰黑、不刺眼；朴素、不华丽，但有厚重感、实体工具感，看着很舒服。
工具栏：工具外观和市面软件差不多，没有夸张设计。
标志性画面：打开第一眼是红蓝两个儿童时期的小魔女，作为工作区背景/软件封面，一眼就能认出「就是这个软件」。
修正点：口误「模拟界面」应为「魔女界面」——打开先看到魔女画面，再进入正式工作区小窗。

二、打开与报错流程

打开软件。
进入正式操作工作区小窗。
先出现魔女界面（标志性画面：红蓝双儿童魔女）。
第一次操作的人（身份不明确）点某个按钮时，顶部工具栏弹出红色横条报错。
你看到后怀疑：「这个软件是不是坏了？」
嫂子（你哥的老婆）接手操作，操作立刻变得极其丝滑。
点「复制墨水」时似乎也闪过一次红条，但随后复制成功。
有人/嫂子说：「这是操作问题，不是软件的问题。」

报错不是崩溃，更像条件警告/操作顺序提示；不是常驻，是点按钮触发，持续到下一个按钮点击。

三、核心操作与转场

顶部有个正常的复制图标，但梦里被告知：那是「复制墨水」。
点「复制墨水」后：
转场极其丝滑；
像镜像反转 + 顺时针旋转 180°，也有绕一圈的感觉；
转到 180° 时，镜头给软件自带的毛笔画笔一个特写：只有下半部分/笔尖，棕色笔毛，笔尖上凭空多了一点复制来的墨水；
然后继续转，进入城堡/教堂场景，出现成年魔女。
笔的来源（重要确认）：笔不是凭空出现的，它本来就是软件工具栏里的画笔工具——毛笔形态、棕色笔毛；转场中出现的是下半截/笔尖部分，像镜头特写，因为沾上了一点墨水。
转场入口/出口：
入口是你的台式电脑；
转场前，你的电脑屏幕似乎和魔女的电脑屏幕重合；
从电脑屏幕右半边开始旋转；
绕一圈后，转到魔女手上的笔记本，似乎从她的电脑里出来；
隐藏设定：软件其实在魔女的电脑里，你的电脑是入口/重合点。

两台电脑被转场连成环：你的台式机 → 软件小窗 → 绕圈旋转 → 魔女的笔记本 → 疑似从她电脑里出来。

转场争议点（保留，不强合理化）：梦里逻辑自洽，拆到现实缺因果链。已确认「笔」是软件自带画笔、沾墨特写，不是凭空出现；仍缺的可能细节：屏幕为何重合、为何右半边起转、两台电脑的空间关系等。若后续续梦或想起细节再补。

四、被画的成年魔女

呈现方式（多次修正后定稿）：不是工作群照片，也不是建模软件预览窗口——而是正面上半身、高写实、高精度 3D 角色，比米哈游角色更逼真、层次更高，像 3A 游戏过场或影视级 CG。
场景：她身处一个完整建筑物内部场景——西方城堡/教堂风格，不是建模软件界面。
姿态：左手拿笔记本；右手记不清了，只记得整个人像摆好 pose 的姿态。
补眼睫毛：嫂子拿着那支沾了复制墨水的笔，给她补眼睫毛：
先在左眼睫毛尾部画一下；
再在右眼鼻梁附近画一下；
一共三四笔，从左到右，局部补妆式，不是完整眼妆。
动作快、像随手画，但效果好，像化妆师补妆时局部点几下。

软件定位升级：2D 绘图外壳 + 复制墨水穿越 + 高写实 3D 城堡场景角色补妆——从平面修图升级为「2D 工具穿进 3D 写实场景」。

五、现实对照

现实中没有完全匹配的软件。
布局有现实影子：PS 类绘图软件、PaintTool SAI、Krita/GIMP 浮动窗口、网页编辑器居中画布等。
但以下组合大概率是梦原创：
红蓝双儿童魔女作为固定工作区背景/标志；
「复制墨水」而不是复制图层；
从你的电脑绕圈转到魔女笔记本的丝滑转场；
进入高写实 3D 城堡/教堂场景给角色补妆；
红色横条报错 + 「不是软件问题，是操作问题」。

六、地点与人物

地点：邻居家姐姐的大门口。

位置	人物	角色
左边板凳躺着	你儿童时期的男玩伴	放松、旁观，像童年记忆
操作电脑	你哥的老婆（嫂子）	接手后操作丝滑，给魔女画眼睫毛
电脑后边	身份模糊的人	占位/旁观，记不清是谁
右下角	你	电脑主人，知道软件在自己电脑里
记忆边缘	邻居家姐姐	记不清，但她的大门口是梦的舞台

电脑是你的台式电脑。
软件是某个同伴提起的，你说「我电脑里有这个软件」。
现场大概 4 个人 + 1 个模糊人物。

七、两次使用

梦里这个软件用过两次，间隔很久。
第二次：就是上面整套——报错、嫂子接手、复制墨水、绕圈转场、给成年魔女补眼睫毛。
第一次：只剩一个模糊印象，目的可能是「给新娘化妆」；具体画面、地点、操作者都不确定；是看到红蓝双魔女标志后才想起来的。
两次使用的目的似乎一样，都是为了给某个新娘化妆；但第二次不知道为什么对象变成了高写实成年魔女。
「用过两次」的可能解释：
前几天/更早的梦留下的残片，今天被同一画面激活；
梦内植入的「伪记忆/二周目感」。

八、落地思路：空壳版 / 概念演示

不需要实现真正的「穿越电脑」，只需点击按钮后自动播放一段动画。

动画分镜

点击复制图标（标注「复制墨水」）。
顶部闪一条红色横条报错（持续到下一个按钮点击）。
红条消失，转场开始：
你的电脑屏幕与魔女笔记本屏幕重合；
从屏幕右半边开始顺时针绕圈旋转；
转到 180° 时，镜头特写软件自带的毛笔（下半截/笔尖，棕色笔毛），笔尖出现一点墨。
继续旋转/视角上移，进入西方城堡/教堂内部，高写实成年魔女出现（左手拿笔记本，整体像摆好 pose 的姿态）。
自动或半自动演示补眼睫毛：
左眼睫毛尾部一笔；
右眼鼻梁附近一笔；
共三四笔，像补妆。
画面停留，可回到主界面，保留「用过两次」的存档感。

技术选型

最快做界面：Figma 做可点击原型（Smart Animate 串画面）。
想做真窗口：HTML/CSS/JS + Electron/Tauri，或 Python PyQt。
转场动画：CSS 3D transform / Canvas / 游戏引擎（Godot/Unity 时间轴）。
素材：AI 生成静帧（红蓝双魔女、高写实成年魔女、笔和墨点），再用剪映/PR/Figma 串时间轴。
背景图：原创或 AI 生成，避免直接使用现有动漫角色（版权风险）。

关键点

报错要短，像条件警告，不是崩溃。
转场要丝滑，旋转 + 镜像 + 右半边起转是灵魂。
画笔沾墨是仪式感高点，必须给特写。
补妆只要三四笔，不要画完整眼妆。

九、待验证清单

第一次使用到底画了什么/给谁画？
为什么两次目的都是「给新娘化妆」，但第二次对象变成了成年魔女？
红色报错横条具体写了什么字？
电脑后边那个模糊的人是谁？
邻居家姐姐有没有出现？
软件小窗的标题栏/名字是什么？
转场中屏幕重合、右半边起转的具体原因（如果续梦或想起）。

十、结语

这个梦最核心的原创点就三个：

红蓝双魔女标志画面；
复制墨水；
从你的电脑绕圈转到魔女笔记本的转场（进入高写实 3D 场景）。

其余布局和报错逻辑都能在现实软件里找到影子，但组合起来就是独一份的「梦里软件」。它不一定需要被做成真软件——做成一段概念动画、一篇创意文档、或一个 GitHub 上的分镜原型，就已经把梦留住了。

附录：可直接复制的备忘录精简版

梦：复制墨水绘图软件（2026-10-20 醒后记录）

界面：打开后固定居中一个小窗，不是全屏；浅灰白、朴素、厚重、舒服，无华丽 UI；左侧工具栏+顶部工具栏+中央工作区。

打开流程：先出现魔女界面（红蓝双儿童魔女标志画面，一眼认出软件），再进入正式工作区小窗。（「模拟界面」是口误，应为「魔女界面」）

报错：点某个按钮时顶部弹出红色横条；点「复制墨水」时似乎也闪过一次，但随后复制成功。我先怀疑「软件是不是坏了」，嫂子接手后操作变丝滑。有人说「这是操作问题，不是软件的问题」。

核心操作：复制墨水 → 镜像反转+顺时针旋转180°/绕圈丝滑转场 → 镜头特写软件自带的毛笔（下半截/笔尖，棕色笔毛），笔尖凭空沾墨 → 继续转 → 进入城堡/教堂场景，出现高写实成年魔女。

转场细节：转场前我的电脑屏幕和魔女的电脑屏幕重合；从屏幕右半边开始绕圈旋转；疑似转到魔女手上的笔记本，从她的电脑里出来（看到的是电脑背面，只是感觉从她电脑里出来）。软件其实在魔女的电脑里，我的电脑是入口/重合点。

成年魔女：正面上半身、高写实、高精度 3D 角色，比米哈游角色更逼真；身处西方城堡/教堂内部场景，左手拿笔记本，右手记不清（只记得整体像摆好 pose 的姿态）。嫂子用笔给她补眼睫毛：左眼睫毛尾部一笔，右眼鼻梁附近一笔，共三四笔，从左到右，像补妆，快又画得好。

地点：邻居家姐姐大门口。

人物：我在右下角；童年男玩伴在左边板凳躺着；嫂子操作电脑；电脑后一个身份模糊的人；邻居姐姐在记忆边缘。

电脑：我的台式电脑；软件是同伴提起，我说「我电脑里有」；梦里用过两次，间隔很久。第二次如上；第一次只剩模糊印象，目的可能是「给新娘化妆」，待验证。

质感锚点：浅灰白厚重 UI + 红蓝双儿童魔女标志画面 + 复制墨水绕圈转场 + 补三四笔眼睫毛。

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 与广播注入中文、英文、删除、回读均验证通过。

凌晨一点，被一碗挂面收买的我

Sat, 10 Oct 2026 08:00:00 +0800

凌晨零点四十九分，有人跟我说要写篇随笔。那就写写今天。

下午五点吃了一顿正经饭，猪脚、胡萝卜缨子、倭瓜、葫芦、土豆丝，五道菜，像模像样。可惜好景不长，转头就囤了一柜子速食：泡面、泡椒、小鸡炖蘑菇面、拌面、挂面。是该夸他会吃，还是该骂他嘴馋，我到现在也没想明白。

半夜饿了，就煮一小把挂面，卧个蛋，撒点葱花，滴几滴香油。热乎乎一碗下肚，暖胃又顶饿。吃完别急着躺，站一站，走两步，再把牙刷了。

有些关心是唠叨，有些唠叨是关心。反正这一碗面，就当今天的收尾吧。

——写于深夜，被一碗挂面收买。

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

Root 搞崩手机？一加 Ace 3 Pro KSU-Next 无限重启救砖全记录

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

Root 一时爽，重启火葬场。本文记录一加 Ace 3 Pro 刷 KSU-Next 导致无限重启的全过程：怎么翻的车、怎么救回来、踩了哪些坑。

翻车经过

设备：一加 Ace 3 Pro (PJX110)，ColorOS 16.0.5.701，内核 6.1.141

已有一个正常工作的 KSU（KernelSU），手痒想试 KSU-Next。

第一步就走歪了

KSU-Next 的 AnyKernel3 内核版本是 6.1.134，而我手机是 6.1.141。差了 7 个小版本。

我心想：内核小版本不都向下兼容吗？

不兼容。直接不兼容。

通过 TWRP sideload 刷入后，手机重启 → 无限重启。

还嫌不够惨

SUSFS 模块 zip 被我当成了 recovery 卡刷包，又推了一次。

现在不只是内核版本不对，模块也炸了。

fastboot 也废了

无限重启状态下，fastboot reboot 命令失效，ADB 通信不稳定。手机反复亮屏、黑屏、亮屏、黑屏，像极了宕机的心电图。

救砖过程

进入 TWRP

TWRP 是最后的救命稻草。

一加的 TWRP 卡顿严重——触屏延迟、滑动漂移、界面偶尔花屏。但关键操作（刷入镜像）还是能完成。

进 TWRP 的过程靠手动操作：关机 → 音量减 + 电源键 → 进入 fastboot → 音量键选择 Recovery Mode → 回车。

核心操作：ADB push + 刷镜像

TWRP 里用 ADB push 把文件传进去：

# 传入字库备份
adb push boot_b.img /sdcard/
adb push init_boot（原版）.img /sdcard/

然后在 TWRP 的 Install → Install Image 里，分别刷入：

boot_b.img（192M，字库备份的 KSU 内核）
init_boot（原版）.img（8M，纯原版，无 KSU 补丁）

注意：boot_b 的字库备份有 192M，不是通常的几十 MB。这是完整的内核镜像。

重启 → 开机了，但没 root

系统正常启动，ColorOS 界面出来了。

但没有 root。

原因很简单：init_boot 刷的是原版，不是 KSU 补丁版。KSU 的用户态在 init_boot 里，原版 = 没有 KSU = 没有 root。

根因：不是内核炸了，是模块炸了

开机后做了一个测试：

# 把 /data/adb 改名（相当于禁用所有模块）
mv /data/adb /data/adb_disabled

# 重启
reboot

重启后一切正常。

这证明：无限重启的元凶不是 boot/内核镜像，而是 /data/adb 目录下的某个 KSU 模块。模块在启动时加载，加载失败 → 循环重启。

你现在需要的：模块排查

知道是模块问题后，排查思路很清晰：

# 1. 进 adb shell（系统正常启动状态下）
adb shell

# 2. /data/adb_disabled 里有所有旧模块
ls /data/adb_disabled/ksu/modules/

# 3. 逐个复制回来，每恢复一个就重启测试
# 找到导致重启的那个模块，删掉它

如果 adb 进不去（又重启了），进 TWRP 挂载 data 分区，直接在文件管理器里操作。

完整救砖清单

步骤	操作	备注
1	进 TWRP	音量减 + 电源 → Recovery
2	解密 data 分区	TWRP 会提示输入锁屏密码
3	ADB push 字库镜像	boot_b.img + init_boot 原版
4	TWRP Install Image	boot_b → boot 分区，init_boot → init_boot 分区
5	重启	如果还循环，重复步骤 1
6	改名 /data/adb	禁用模块，确认能否正常开机
7	恢复 KSU 版 init_boot	重新获取 root

关键教训

1. AnyKernel3 刷的是 boot 分区，不是 init_boot

内核补丁和 KSU 用户态是两个东西。内核在 boot，用户态在 init_boot。搞混了就是"内核有了但 root 没了"或反过来。

2. 内核版本必须匹配

6.1.134 的内核塞进 6.1.141 的系统 = 无限重启。AnyKernel3 不会替你检查版本，它只管刷。

3. 模块是最常见的翻车原因

每次加模块之前，先备份一份 /data/adb。模块冲突导致无限重启的概率远高于内核问题。

4. 字库备份全量做

boot + init_boot 配对备份，两个都要。少了任何一个，救砖时就是"系统能开机但没 root"或"有 root 但开不了机"。

5. TWRP 是最后防线

没有 TWRP，无限重启状态下你只能 fastboot 刷机，选择少、操作难。TWRP 能挂载 data 分区、直接操作文件，救砖效率翻倍。

当前状态

系统：ColorOS 16.0.5.701，正常启动
内核：KSU 版（字库备份）
root：暂未恢复（init_boot 为原版）
待办：清理模块后刷回 KSU 版 init_boot

Root 有风险，刷机需谨慎。但真翻车了别慌——有 TWRP、有字库备份，90% 的情况都能救回来。

一个微信小程序的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，索引永远当最优解。

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

关于我俩

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

虽然我们在一起的时间不长，但是这段时间我们很开心，彼此都常常庆幸能够拥有对方。

我是一个敏感多疑的女孩，他是一个耐心细致的男孩：

在我不定时无理取闹时，他会包容我
当我生气时，他会耐心地哄我
面对我莫名其妙的问题时，他会真诚地回答我

有时候我都会厌恶自己的这些行为，我常常问他累不累，每次他的回答都很坚定——

“不累，因为我爱你”

这句话第一次出现时，我也会觉得是骗人的。但是时间和行动会证明一切，他的爱越来越清晰，越来越坚定。长时间被爱包围，我确定，我会越来越爱他。

未来很长，我只希望这个幸福的恋爱计时没有镜头。

最后对我的宝宝说：

老头，不要总是自卑消极，我会永远喜欢你、相信你、爱你。就算你是无比黑的夜，那我就是陪着你的那群星星。

图片压缩原理与实操：一张照片原始 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 压截图
日常压缩用手机小程序，微信搜「确实佷难压缩」