前作处理了 lsd 大量消耗 CPU 的问题。排查的过程中顺手看了一眼磁盘：这台 MacBook Pro 的数据卷一共 466 GB，已经用掉 389 GB，可用的只剩 42 GB，占用 91%。用 du 逐层往下看，~/Library/Caches 一个目录就有 106 GB，其中 102 GB 在 CloudKit 底下。
清掉这些缓存不难，难的是弄清楚它们是怎么来的。下面先交代清理的过程，再回头讨论三件事：这些缓存从哪来，以后怎么尽早发现，以及怎么避免再攒出这么多。
解决 macOS 上 lsd 与 syspolicyd 大量消耗 CPU 资源的问题
手头这台 2020 款 MacBook Pro 用的是 Intel 的 i5-1038NG7，4 核 8 线程，16 GB 内存，系统是 macOS 15.7.3。最近发现，手上的活并不重，风扇却一直在狂转。用 top 看了一眼，load average 在 10 到 17 之间，排在前面的是 lsd、syspolicyd、trustd、duetexpertd 这几个系统进程，没有一个是我自己打开的应用。其中 lsd 长时间稳定在 50% 上下。
这台机器已经连续运行了 74 天，我不太想重启它；Setapp 也还在用，不打算卸载。所以下面的处理都没有重启系统，也没有卸载任何软件。把 CPU 压下来以后，我又回头翻了一遍导出的数据，想弄清楚三件事：问题是怎么来的，下次怎么一眼认出来，以及能不能让它不再发生。
把 item 压成 KV：gist 能不能用在相关性任务上
设想这样一个搜索相关性模型：用一个 0.5B 量级的小模型，把 item 和 query 拼成一条序列送进去，取最后一个 EOS 位置的隐状态，接一个 MLP 做相关性分档。item 侧拼着标题、属性、详情，动辄上千个 token；query 侧只有几十个。同一条 item 会在许多不同的 query 下被召回，每一次都要连同 query 从头算一遍。于是我们自然会想，能不能把 item 预先压成一小段 KV 存下来，在线只让 query 对着这段 KV 做注意力，把 item 那上千个位置从在线计算里拿掉。
这个想法与 gisting 很接近（Learning to Compress Prompts with Gist Tokens，Jesse Mu、Xiang Lisa Li、Noah Goodman，NeurIPS 2023）。此篇前半讲这篇论文做了什么，后半讨论把它搬到相关性任务上以后，哪些地方成立，哪些地方要改，哪些地方搬不过去。
魔高还是道高？iOS 越狱检测与反检测的攻防大战
越狱的 iPhone 上，APP 进程中可能被插入任意代码。对于聊天软件来说，这最多意味着多出几个主题或手势。这属于功能上的定制，无伤大雅。但对于金融 APP 来讲，这意味着用户可见的界面和实际执行的逻辑之间，不一定再有可靠的对应关系。
例如说……
- 注入代码可以读 App 沙盒里的任意文件，其中包括被错误地留在磁盘上的机密信息。
- 可以读取键盘事件，把用户的每次输入上传到攻击者的服务器。
- 可以在用户按下转账确认的那一瞬间改掉收款账号。
- 可以制作一个和登录页一模一样的假界面，把密码骗到手。
- 也可以绕过证书验证，让整个会话以明文暴露给中间人。
这些威胁在现实中都能找到对应的黑灰产，相关产业的规模比多数开发者估计得大。因此，监管对金融 APP 移动客户端的安全检测一直有明确要求。从这个角度看，检测越狱既正当，也必要。
下面按攻防的次序，把这两年处理过的十来款 App 归纳一遍。每个回合先看攻击方做了什么，再看检测方可以怎么补。
某银行 APP 的越狱检测体系
某银行 APP 在越狱设备上启动后，大约五百七十毫秒便会退出。围绕这次退出，我们进行了二十几轮分析与干预。最终没有得到可用的绕过方案，不过这些实验揭示了一件更值得记录的事：检测环境、保护检测代码和阻止异常启动，是怎样共同起作用的。