猫鱼周刊 vol. 095 谨防赛博夺舍
关于本刊
这是猫鱼周刊的第 96 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
INIT
好久不见。这张照片是某天下午下楼摸鱼的时候拍的，公司之前的楼下转角处有个茶餐厅，在角落这里搞了个小狗幼儿园，图片里的两位是店里的，时常能看到不少小狗在这里聚会玩耍。我不是很喜欢狗的人，但是在工作累了的时候下楼看到小狗在阳光下奔跑玩耍，还是很治愈的。以至于公司要搬走了，我的第一想法居然是，啊那我再也不能摸鱼下楼看小狗了。
Anyway，最近这段时间也挺忙的，开始学车，也尝试写了一下 iOS App。后面慢慢细聊。
STDIN
Apifox 供应链投毒攻击 — 完整技术分析
Apifox 因未严格启用 sandbox 参数，并暴露了 Node.js 的 API 接口，导致攻击者可通过 JS 控制 Apifox 的终端，启动过程中加载了一个被投毒的脚本，采集了用户的 .ssh 目录以及命令行历史等。
本来我很久都不使用 Apifox 了，最近偶然做需求打开了几次，没想到就中招了。我写了一个脚本，根据文章的描述，识别是否有文章中提到的 IoC 和本地痕迹，以及本地有什么高风险的凭据材料需要轮换。运行之后发现我是妥妥中招了，所以这周一个非常蛋疼的事情就是找到一个方式可以避免这种攻击，然后轮换全部的密钥。
最近类似的事情还有 LiteLLM 也遭到了类似的供应链投毒攻击，这种针对开发者的攻击防不胜防，不管你使用商业软件还是开源软件都避免不了，防范的手段还是控制本地不要留存这种敏感凭据。另外有个大家可能都很容易忽视的点，那就是避免在命令行中明文输入密码，就是例如通过 -p xxx 这样去传递密码参数，这样你的密码就会留存在历史中，可以用环境变量或者 interactive 的方式去输入。
当 AI 陷入沉思：长时程思考下的有效交互设计研究
当 LLM 出现思维链之后，大家发现如果让 AI 不断「自言自语」，可能会得到更加完善的结果，所以「深度思考」应运而生。对应的界面交互上，从一开始全部流式展示，到后面逐渐迭代出一些动画、结构化过程等等，这篇文章做了很深入的思考和研究。
不得不说，文章中多次提到 Claude，在实际使用中，我确实也觉得是 Claude 的使用体验最佳，不过这种交互体验实际上算是「锦上添花」，不算得上非常重要的选购因素。
另外我觉得有一个交互的点可能暂时没有人考虑到，以及由于现在龙虾类产品的出现，可能令这个问题加剧—— AI 什么时候完成了工作。作为「略懂」的人，我会知道结束的边界在于模型输出 EOS token，一般的实现就是到这里就不再刷新，然后气泡底部出现交互。这看起来没什么问题，但是复杂情况就在于，如果这时候用户让 AI 做一些很复杂的事情，但是 AI 并没有这个能力，却又像模像样地骗用户自己正在做 ppt，并且通过邮件发给他，不少用户信以为真，而且在发现 AI 做不到这个之后产生巨大的挫败感。对于传统的在线聊天式 AI，只要生成结束了，气泡不再刷新了，那就是结束了，再发消息就是一轮新的交互。而龙虾又复杂化了这个事情，因为它有后台进程，甚至不管你有没有发消息，它其实都在工作，所以这时候你发消息问进度是有意义的。
我们如何在 Cursor 中比较模型质量
Cursor 团队搞了个 CursorBench 来评测不同的模型，任务来自真实的 Cursor 用量，而不是公开代码仓库，CursorBench 不仅更能区分不同模型，也比公开基准更贴近开发者的真实结果。他们发现现在的公开基准存在不少局限，在前沿水平上，这些基准已经无法区分那些对开发者而言实用价值截然不同的模型。他们构建的 CursorBench 会使模型的区分度更大，更加能体现 coding 场景的能力。
评测的结果倒是没什么特别意外的，GPT 5.4 最强，其次是 Opus 4.6，倒是声称对标 Opus 4.5 的 GLM-5 实际的差距还蛮大。比较意外之前传出来他们的 Composer 2 使用的微调 Kimi K2.5 居然没有出现在榜单里。
他们的实践说明，在实际使用的时候，还需要根据具体的场景来构建 benchmark，光看各种模型吹得天花乱坠意义不大，大家在公开基准上都很卷，你的实际场景用起来很可能又不是那样。
STDOUT
把 SSH 私钥放进 YubiKey
在 Apifox 供应链投毒事件之后，我目前风险最大的就是本地使用的 SSH 密钥。这个东西自从配开发环境的时候就生成了，然后一直放在那里，很少再去管它。在跟 ChatGPT 探讨之后，它给我几个方案，要么使用例如 1Password SSH Agent 之类的方案去管理 SSH 密钥，要么使用 FIDO2 SSH key，或者用 Yubikey 的 PIV/OpenPGP。第一种方案需要另外投入成本，而 Yubikey 我手头就有好几个，用 GPG 签名也很久了，所以最终使用了 gpg-agent 的这种方案。另外值得一提的是，FIDO2 这种方式其实非常好，主流服务也支持，但 *-sk的公钥还是在很多地方有兼容性问题，所以用不了。
说实话，这个折腾起来还挺麻烦的，如果你之前没有 Yubikey，硬件投入也不少，然后把整套流程跑通也花了我大半天。之后每次使用的时候，还要把 Yubikey 插入电脑并输入 pin。好处是以后我大概再也不用担心 SSH 私钥被盗的事情了。
回应标题，如果你的 SSH 私钥就这么生成之后被遗忘在 .ssh，你很容易就被「赛博夺舍」，我这个方案不妨考虑一下。
Marked
尝试用 Swift 写了一个原生 iOS App，至此，前端后端安卓 iOS 我都有成型的作品了，虽然在这个过程中主要的功臣是 AI。总之，这是一个记录类型的 App，除了简单记录某件事件以外，还可以填入一些自定义字段，例如健身时练的部位、有氧的事件等等，后续可以根据自定义字段来做分析；还有一个有意思的功能是，可以记录「已经多久没做 x 事」这种戒断类型的事件，除了培养好习惯，戒掉坏习惯同样重要。如果你对 Marked 感兴趣，它现在还没有上架，你可以在 Testflight 体验。
顺便也分享一下我的开发经验。
一开始，我打算用 Figma AI 或者谷歌的 Stitch 之类先出一版设计稿，然后改下交互之类的，我最终选择了 Stitch 来尝试，主要是因为它的免费额度比较多，而且支持 MCP。我先尝试了直接在网站上输入我的简单需求，让他设计好界面以及对应的交互，但是发现它一开始只会生成首页的交互，里面具体的交互需要你一步一步跟他聊天才会有，而且具体的字段每个页面可能都不一样。倒是有一个很突出的点，它会先生成一个 DESIGN.md，所以所有界面都可以获得比较一致的设计风格。我的改进方式是先把我的初始需求写成一个 init.md，然后跟模型讨论，让他生成出一个 PRD，并且带有每一个页面的交互和字段的描述，再根据这个文档，让他调用 MCP 来生成页面，最终能生成出全部页面，字段设计等看起来也没什么大问题。
但是最后我实现的时候，发现这个设计稿完全没有作用，我的工作流程里不涉及 UI 设计，我的交互其实文字已经描述清楚了。更糟糕的是，这个设计稿里的每一个 screen 其实只是一个 html，Figma 的也是类似的设计，而我要写的是 Swift 的原生 UI，设计稿没法反映苹果原生的 UI，而且生成出来的 screen 经常出现一些无意义的边框或者评论等，修改起来也很费劲。
另外踩的一个坑是，有一个 Emoji 选择器，一开始用的是一个开源的包，但是在新版本 iOS 上有个 bug，会导致下面的类别选择器有异常。AI 卡了很久都没有解决，直到我在 GitHub issues 里找到一个对应的问题，并且顺藤摸瓜找到了一个修复的 fork 才解决。现在 AI 很大的问题就是经常遇到问题无法解决，需要人类介入。我觉得 Skill 也许是这个问题的解决方案，因为「开源的包遇到问题-去翻翻 issues」这个流程其实是我的经验，本质上这些操作它也可以完成的。另一方面大家也许可以不那么焦虑被 AI 取代，因为它们遇到小小的问题可能就会卡住。
MISC
Humanizer-zh
一个用于去除文本中 AI 生成痕迹的 Skill。之前做了很多关于 AI 生成检测的研究，看到这个感觉还是挺有意思的，让 AI 生成更加拟人。
project-nomad
一个离线的知识库，打包了 AI 助手、离线地图等工具，不过安装时仍然需要联网。整个项目的背景有点「末日风」，而且部署的成本还不低（根据项目的推荐硬件，甜点配置大概需要 500-800 刀，需要本地能跑 LLM），实用性不算很强。不过如果你已经花了很多钱搞末日地堡，这个价格估计你会承受得起（x。
CanIRun.ai
一个自动检测你的硬件配置，并计算你的电脑能运行什么 AI 的工具网站。比较有意思的是，它除了会给你预估的 VRAM 需求，还会根据你的设备的具体硬件配置（VRAM、RAM、内存带宽等）估算不同量化下的输出速度，以及不同量化的效果来供你评估。
EOF
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。