2025-11-16 20:38:21
这是猫鱼周刊的第 86 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
好久不见。前两周比较忙，内容也不多，所以就没有写周刊了，也算是给自己放一个小假。
这张照片其实摄于一年多以前，在西乡红树林公园外的一个大草坪。这张算是我后期得比较多的照片，重新裁剪了一下让人占画面大概 1/3 的位置，然后拉暗了暗部的曝光增强剪影的效果。
这周水了一篇文章 Docker 服务器磁盘满排查思路，也是吐槽了一下现在在用的博客系统 Halo，最近博客频繁的访问不稳定，就是拜它所赐。过了几天才想起来，原来之前就写过一篇类似的 排查 Linux 空间占用，不过这次更加专注于 Docker 造成的空间问题和排查。
我强烈建议你先观看一下从没想过的问题？！影视飓风 1400 万粉丝 Q&A！ 这个原视频（至少看完相亲角部分的完整片段）再去看这个舆情解释视频，以及网上的各种评论。
不得不说，我看这个 Q&A 视频是因为在小红书刷到了很多关于「相亲角」的讨论，才去 B 站看了。我很赞赏影视飓风，但也算不上死忠粉，所以这类粉丝向的节目本身我不太感兴趣。视频看下来我都没觉得有什么问题，「初中学历」这个东西纯粹是整活，而「离异」这个也是事实，本质是整一下活，我没想到，我觉得 Tim 和他的团队也没想到，这居然能被人用来作为矛头攻击他。
利用矛盾制造情绪是自媒体获得流量的基本公式，而任何二元对立的事情就很容易用来制造矛盾激化情绪，例如贫富、性别等等。视频中说到，很多营销号就用「抽象化切片」来编一个离谱的故事激化矛盾。这是个非常操蛋的逻辑，但是偏偏平台和用户都很喜欢。另一个博主说到：
平台和舆论很傻逼怎么办？没办法。傻逼的共识也是共识。
无独有偶，之前 LTT 也陷入类似的舆论中。说实话，我觉得人无完人，我们不能要求公众人物个个都像圣人一样完美，更没必要反过来竭尽力气去挖人家的污点，这真的很「饭圈化」。
写到这里我想起我好像不是第一次谈这个话题了，今年初的时候，还是影视飓风，当时是跟评测相关的（via vol. 062）。我觉得影视飓风可以称得上国内版的 LTT，他们的商业模式很像，内容大部分也都非常对我胃口。之所以谈到商业模式，是因为在 LTT 公布过他们的收入组成，以周边售卖为大头，辅以赞助、广告等等；影视飓风我感觉也是类似的形式（他们的电商做得很不错），服装、电子产品都有不少原创的设计，我也买过不少；唯一有区别的可能是影视飓风还有一些视频制作相关的商单。这种商业模式的好处显而易见：
他们收入的大头不是广告推广，不是独家内容，而是售卖周边。我觉得这种变现方式就非常地健康，大头是周边产品售卖，热情的粉丝团体，为他们的创意且实用、有品质的产品付费；另外一边，多元的赞助商、广告位等，让他们不需要拍厂商的马屁，拥有相对的「评测自由」。
做评测的里面，顶级头部以及尾部博主其实都比较容易说实话，核心原因都是不需要拍厂商的马屁。腰部博主不好说，谁给得钱多就向着谁就完事了，哄不好金主就没饭开，「被包养就不要谈什么独立人格」。
很有共鸣。作者说到他在工作中极其需要反馈，包括业绩上的正反馈、负反馈，来自朋友同事的看法等等，而没有反馈则是很可怕的事情。
我也是一个很看重反馈的人，我在唱 K 的时候都会时不时降低音量确定自己有没有跑调。这倒不算是缺乏自信，我觉得这是一种提升自己的方式。当然读完这篇文章我也有一个新的想法，就是负反馈也是有益的，也比没反馈要好；但是这点很难去要求别人，没人喜欢说坏话。
在 Netflix 上看的一部电影，拍摄手法很有意思，从一件事的不同人的视角去展开，整部电影被分为好几章节，一个多小时，但是只对应世界时间线里的十几分钟，从一个未知来源的核弹发射到总统决定反击计划的瞬间。最神的是，一开始已经过了一遍整个故事，最后到那个总统决定反击计划的瞬间戛然而止，什么规模的反击、核弹有无爆炸、世界是否核平没有交代，原本剧情会像正常电影一样，全面反击，全球核平，但是从后面的章节开始，又换了一个视角，补充了前面没有交代过的一些信息，每个主角在其中的态度、反应刻画得更加细致。而一开始我很关注的世界核平到底有没有发生，到最后都没有交代，是个开放式结局。
（好像是周刊第一次推荐影视类的东西，为了不剧透写起来感觉有点混乱，欢迎留言反馈）
你的浏览器有多少个打开的标签页？我的可能有上百个，这已经给我造成了一定的焦虑，也一定程度上是我没有更新的原因。这些标签页，有的是我看了标题觉得感兴趣的文章，有些是觉得稍后需要参考的文档，还有一些感觉有意思想研究一下的项目、网站等等。但是一个现实是，如果用游戏中的耐力条来类比就是，人每天的总的精力是有上限的，恢复的速度也很慢（需要足够的休息、合理的饮食等），而每做一件事、看一篇文章、理解一个项目等都需要耗费不少的精力。现在的情况就是，我感兴趣的事情远大于我精力的上限。
道理我都清楚，其实没必要太纠结有没有深入去读一篇文章，纠结有没有错过什么，但是执行上有点难。Arc 有个很好用的功能，可以自动归档大于某个时间的标签页，我现在设置的是 30 天，我在考虑改到 7 天。如果一件事情，一个星期我都没时间去做，它显然不紧急，也很可能并不重要。
写到这里我删掉了下面的「项目」栏目，好像也是第一次周刊不推荐开源项目。如果非要我找的话，其实也还有存货，但确实没有想写的。周刊写了一年多，开始的时候很专注技术，最近发现近期周刊其实更多去分享生活，我自己最近也没有那么完全专注于技术了，也挺好。周刊的结构其实也想改变一下，初步想法是分成三块，一个输入的部分分享我看到的文章/视频等等，配上我的一些看法；一个输出的部分分享完全我自己的思考或者感想，也推荐一些书影音或者购买的东西等；还有一个栏目分享项目/工具/网站等等。稻草人周刊有个类似的结构，分别叫连接、当下和星群，蛮有意思。我在构思的命名是 INIT、STDIN、STDOUT、MISC、EOF，不知道大家有没有更好的意见，也许下周就能迎来这个重构。
Canva 收购了 Affinity 之后，Affinity 本体免费了，AI 功能可以通过 Canva 会员订阅使用。Affinity 算是 Adobe 的一个下位替代，本期头图就是用 Affinity 的 Raw 编辑功能导出的。这对业余创作者来说算是一个好事，比如我很少对照片做精修（不拍人像），核心就是裁切和调色，使用频率还很低（直出居多），所以单独为这个需求买正版的 Adobe 有点冤大头。
使用 Grok 重写的 Wikipedia。这种方式我觉得有点像 Simple English Wikipedia，其是一个用简单的单词、句法等来编写的百科全书，方便英语学习者、学生等阅读。到这里我有个想法，为什么不用 LLM 来补充 Simple English 的 Wiki 词条呢？
思路跟前面的 Grokipedia 类似，用 LLM 生成词条。作者的思路可以看这篇文章，挺有意思的。
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
2025-11-11 16:43:23
最近博客频繁出现不可访问的问题，但因为最近没怎么在写文章，所以倒没怎么管，直到收到博友圈发来的邮件：
登上去一看，发现服务器的磁盘居然满了（之前出现过内存满的情况，重启一下 Halo 的服务就能解决）。因为这台机器上都是用 Docker/Docker Compose 启动的服务，所以自然只需要去考虑 Docker 的问题。
当然，在这之前也是先用 df -h 看了一下，全都指向 /var/lib/docker/overlay2/xxx 和 overlay 这样的东西，所以能确定是 Docker 的问题。如果占用大的在其他目录，那就稍微复杂一点，可以用 du -h --max-depth=1 一点点去排查。
overlay 79G 57G 20G 75% /var/lib/docker/overlay2/89ed74e70d3e59b7c5de6e53522eece539a74e013c9c03c76fc7ac4d73045ed7/merged
其实到这里我就懵逼了，这些服务都没什么会落盘的，不应该一下产生很大的数据才是，所以找了 AI 帮忙，它建议我先运行：
docker system df -v
这里提醒了我两个问题，一个是我有很多镜像没有清理，二是有些卷没有清理，于是先执行了下面两条命令，先释放一点空间。这两条命令都只会清除没有使用的镜像和卷，所以是比较安全的。这一步清理掉了几个 G，但是磁盘还是很满。
docker image prune -a
docker volume prune
于是让 AI 帮忙写了个脚本，查一下到底是哪个容器的卷占用空间大：
echo "VOLUME_NAME SIZE CONTAINER(S)" && docker volume ls -q | while read vol; do size=$(docker volume inspect $vol --format '{{.Mountpoint}}' | xargs du -sh 2>/dev/null | cut -f1); containers=$(docker ps -a --filter volume=$vol --format '{{.Names}}' | tr '\n' ',' | sed 's/,$//'); [ -z "$containers" ] && containers="<unused>"; printf "%-40s %-10s %s\n" "$vol" "$size" "$containers"; done
最终找出来是 Halo 的容器。AI 建议我先考虑是容器日志的问题，用下面一条命令发现确实，于是又重启了一下容器，果然空间就被释放了。
find /var/lib/docker/containers/ -name "*.log" -exec ls -lh {} \; | sort -k5 -hr | head -10
但是这个方法治标不治本，它还顺便给我提出了限制日志大小的方法：
Docker
# 启动时添加日志选项
docker run -d \
--log-opt max-size=100m \
--log-opt max-file=3 \
[其他原有参数...]
Docker Compose
version: '3'
services:
your-service:
image: your-image
logging:
driver: "json-file"
options:
max-size: "100m"
max-file: "3"
全局设置（针对所有新容器生效）
# 编辑 /etc/docker/daemon.json
cat > /etc/docker/daemon.json <<EOF
{
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "3"
}
}
EOF
# 重启 Docker
systemctl restart docker
至此，这次磁盘爆满的问题就解决了。
因为 Halo 老是出现 OOM，所以其实这次日志把磁盘写爆是因为 Halo 的问题。一看有一个新版本 Release，说是解决了潜在的内存泄漏问题，更新完好像就再没出现 OOM 的问题了。
我在关于页面里说过，选择 Halo 是因为它丰富的插件生态，完善的主题，还可以的性能，以及部署和发布的便利，现在我倒有了一些微词：
最近也看了不少设计优秀的独立博客，自由度高很多，也更方便发挥，更多东西可以折腾，再做一个自己的博客的念头也慢慢浮现，也许呢。
2025-10-26 19:36:26
这是猫鱼周刊的第 85 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
这周终于又有头图。摄于深圳大梅沙滨海栈道，海水有时候是绿色，有时候是蓝色。沿着海岸线骑行，抬头一看外面海水闪闪发光。
这周没有太多别的产出，工作上的事情又开始多且有趣了一点，摸鱼时间少了一点，所以这期周刊大概也会稍短一点。
这周最大的事情可以说是 AWS 长达十几个小时的服务中断。是时候祭出这张图：
关于这个事故报告，网络上有很多解读，感兴趣可以自己找来看，我只谈谈我的想法。
第一个是「时间攻击」，也就是时间因素引起的 bug。这里有两个点都可以归到时间上，第一是「竞态条件」，这个是写并行程序中经常会遇到的问题，由于我们思考基本上是串行的，没有特地考虑并行的运行情况就会出现这个竞态条件。第二是「延迟增加」，我们通常认为一个操作可以「很快」完成，没有考虑过如果这个操作超时或者需要比较长的时间才能完成时，整体的逻辑是否还能成立。
还有一种时间因素这次没有出现，就是「定时」，这种更加隐蔽，但是更常见于业务系统中。例如某几个时间点数据会与预期不符，导致下游出错；或者更加干脆就是计算一个月前等逻辑，遇到特殊情况（go 的 time.Add），测试通常没法发现。
第二个是连锁反应，这是基础设施相互依赖、架构复杂的结果。从一开始的 DNS 故障，引发数据库故障，再到下游更多服务受到故障影响出现更多问题，作为下游的更多互联网服务更是也因此受到波动。架构越复杂，越容易被简单的问题拖垮。如果你的业务非常简单，可以考虑不要太过依赖云服务。
然后说说事故处置和 vendor lock-in 的问题。很多人觉得 AWS 「基本不可能出问题」，所以事故处置方案中根本没有考虑过这个，服务不可用的时候就完全瘫痪了。又相反地，有人在这次事故之后觉得需要做「多云部署」。我觉得这两种都不太可取，我的思路是参考这次的事故，审视自己架构中依赖了 AWS 的什么服务，如果其中某个服务故障，会对什么有影响，有没有方法减轻影响。当然，就算做了这些，很有可能还是会被一锅端，只是有预案的公司不会手足无措，在恢复时间上拉一坨大的。
说的是 Kindle 退出中国后，国内电子书生态和体验的问题。
在 Kindle 退出中国之后，国内平台只能走「低价包月」的路线，进入了一个恶性循环，导致出版社不愿意上新书，平台内容质量不断下降。反而直播带货还能卖出去不少实体书，所以出版社还比较有意愿发行实体书。另外国内的平台，包括微信阅读，都是以网文为主，严肃创作居少。
我不是网文的受众，当然我一年也不读几本书。我有 Kindle，找盗版书这件事对我来说倒也不算复杂，但是在 Kindle 还在国内运营的时候我会在商店买书，因为买到的排版好，而且省事，加上支持正版的思维。后来 Kindle 退出之后，会发现找新出的书特别困难（这点文章里也提到了，很多盗版来自于破解 DRM 后的 Kindle 商店版本）。到现在，我如果想要看某本书，还是直接去买实体书划算，很多畅销书只要二三十块就能买到，何苦折腾。
关于「提升电动车品牌效应」。
国产品牌很喜欢在技术以外的领域发力，例如公关、宣传，但就是不愿意在技术上多下功夫。我觉得道理很简单，价格战，加上公关宣传这些花销比技术研发低得多，所以现在的样子已经是「最优解」。
之前有不少关于新能源车的评测，也有不少人针对这些评测做很多争论。不知道诸位还记不记得罗永浩跟王自如的辩论，在评测中想要有点「倾向」实在再容易不过。现在做购买决定越来越多噪声，要做出理智的决定真的越来越难，很多时候还是很会倾向于自己喜欢的品牌。
深圳新出了「骑友巴士」，从市区到市内较偏的骑行点，人车一起上公交，定点发车，票价 20 元，周末开行。上车后，师傅会帮你固定好车，然后就是摇摇晃晃穿过市区几个站点（基本上除了终点站没有人上下车），然后到达终点。
这个设计非常好，有点像 2077 里面「跳过行驶阶段」的功能，直接到任务地点。在城市区域骑行真的很痛苦，非机动车道没有或很狭窄，在人行道上坑坑洼洼颠得手痛，要一直避让对向的电动车和路上的行人。而且像大梅沙，离宝安几十公里，以我的体力，骑过去可能就已经废了，更别提在那边骑长上坡，返程估计只能货拉拉。
接着说大梅沙骑行的体验，全程都有绿道，精华的一段维护得不错；后面有很长一段骑行道就没有专门的绿道了，要跟机动车共线，又很多急弯和长上坡下坡，有点危险。路线说是可以一直骑到大鹏那个最美 711，一共 35km，但是我骑了十几公里，经历一大堆连续上坡，心率连续拉满之后，就知难而退了。巴士站点附近有便利店和饮食，有个麦当劳，在里面边吃边等车的时候遇到了不少骑友。知难而退的路上还遇到了两个骑友，也是体力不足知难而退了，大家路上一起推了段车，聊天吹水，也很有意思。
我受够 poetry 了！这句话说出来有点好笑，因为我去年初才把原来的 pip 和 conda 等转到 poetry，还写了篇文章。
其实 poetry 也很好用，只是比较慢，而且 poetry update 的逻辑实在太诡异了，没法做到像 go get -u的效果。
这个项目可以把 pip 和 poetry 等项目迁移到 uv，好耶。
一种水印方法，可以抵抗旋转、裁剪、马赛克等编辑。
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
2025-10-19 20:11:07
这是猫鱼周刊的第 84 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
距离上次出门拍照又有一个多月了，这周还是没有头图，实在是有点苦恼。上次大芬油画村多少有点「诈骗」，坐一个小时地铁过去，看一个城中村，而且深圳就不乏这种虚无的「打卡点」。
下周五是 1024，「程序员节」，这里祝各位程序员读者节日快乐，bug--。
这周有一篇「产出」，这篇文章的来历有点神奇：在大概一年前，我因为做剪辑相关的工作，接触到了 FFmpeg 以及硬件加速相关的东西，在中文搜索结果里没什么人提到，有的文章也比较旧，只考虑到了 Intel 的 qsv 和 Nvidia 的 NVENC，没有 AMD 的 amf 和 Apple 的 VideoToolbox，正好当时折腾这个能适应不同平台自动启用硬件加速的功能，所以在博客的写作列表上列了。结果这篇文章一咕再咕，直到最近这个项目重新捡起来，于是我尝试用 Claude Code 结合我的代码库，帮我写成了这篇文章「FFmpeg 硬件加速小记」。
我在文章开头标明了「本文有 AI 参与编写」，之所以不说「由 AI 生成」，是因为文章的核心思路、代码都是以「我」为主导，是我自己思考得出的。
这种创作方式还挺有意思，因为很多时候在写完某个功能之后，会有很强的欲望想分享自己实现的方案，但是重新总结形成文字又是很消耗精力的过程（所以这篇才会被我拖了接近一年）。提供思路（文章大纲和代码），让 AI 代劳文字组织的过程，至少能形成一篇像模像样的文章。这跟「由 AI 生成」最大的区别就是，如果你让 AI 「写一篇 ffmpeg 硬件加速的文章」，这是没有你的功劳的。
一共是两篇文章，分别从创作者和受众的角度评价 AIGC。有些观点很耐人寻味：
快消层面的内容或许将会被 AI 完全替代，而深度哲思的部分仍然（暂时）归人类所有。
AI 替代的不一定是所有创作者，但一定会替代的是不再愿意创作的创作者。
重新理解 AI 的功能性，它是放大器，而人可以作为源头，只要源头保持流动性，AI 就无法彻底取代你。
他的思考很有深度，感兴趣可以看看原文。
在「受众」这一块，我每周大概会读到上百篇有长有短的文章，但是我从来不用 AI 去做什么「摘要」之类的事情，其实摘要在筛选「有兴趣的引发思考的」上有种多此一举，我往往在打开网页，看完标题和首段或者大致扫过整篇文章的结构之后，我就有定夺我是否感兴趣看完（参考Yay or Nay)。「节约时间」的论点其实不太成立，读完一篇表达流畅的文章通常也只需要几分钟，比起作者创作的数十分钟至数小时、数天来说算是一种基本的尊重。
作为「创作者」，我的核心原则是「原创性」，我始终觉得 AI 无法提出真正「原创」的东西。但是在创作的时候是否应该使用 AI，或者说使用 AI 辅助创作是否会失去这种「原创性」，我觉得没有简单直接的答案。在头条的例子中，我其实做了大多数原创的检索和思考，这跟简单让 AI 「写一篇 ffmpeg 硬件加速的文章」是不一样的。
很喜欢这种「好物推荐」类型的文章，当然这种类型已经被各种商单泛滥，所以看到这种认真在推荐的会觉得更有意思。
我之前也考虑过在周刊中加一个好物推荐的栏目，不过不是每周都会购物，写集合的文章我又懒得写，所以偶尔买到好的东西我会在「想法」的地方推荐一下（例如Quote/0、CyberBrick、拓竹 P1SC等）。
衣服这块我觉得值得提一下。有些户外的面料，不在意搭配的话其实日常穿也很合适，舒适度和实用性比传统的材料好得多。我现在日常穿迪卡侬的速干 T 恤，虽然说是「运动装」，干爽透气以及轻盈有弹性的面料，非常适合广东炎热潮湿的天气，穿着上班、健身都适合。
家居向的「好物推荐」。收拾、装饰家里真的是一个时不时做一下很舒服很解压的事情。
AI 编程落地业务开发的探索与实践
AI 代码评审在七猫的实践
AI 时代的 Code Review 最佳实践
一共有好几篇文章，合在一块说了。感觉这个技术团队非常有意思，很鼓励成员去探索 AI 编程的用法，而且很注重分享。
我在公司跟同事分享过这几篇文章，有一个很有意思的反应：「他们真的落地了吗」。背景是类似的东西（例如 AI Code Review）我在 2023 年就搞过，反正在我公司的环境，这个事情最终没有推行下去，从人的角度来说好像技术同事没有很拥抱 AI，从公司的角度这件事不见得有「价值」。所以这几篇文章让我觉得七猫这家公司的技术团队还是很有「工程师文化」，会鼓励成员去做一些「技术上很酷」的事情。
话说回来，AI Code Review 这件事，当时遇到的一些瑕疵（例如行号的识别、nit（可改可不改） 的把握等），居然到 2025 年，模型更新了两三代还是存在。
接着头条的话题。我比较喜欢「扫街」，我是很典型的 i 人，在街上游荡，捕捉一些小小的美好，是我比较喜欢的摄影风格。深圳这个城市就不是很友好，这个城市主要以「石屎森林」为主，缺乏自然风光（其实也有比较好的海边），最重要的是没什么文化沉淀、没什么多样性。
我觉得要提「扫街友好」，首先是香港。住在深圳，这算是最快到达能看到「异域风光」的地方，路牌、街景等等都跟国内有很鲜明的对比。文化沉淀就是，有一种很独特的风格，如果非要我概括的话，就是老旧和时尚毫不违和地融合，优雅又整洁。香港总会给人一种很旧的感觉，有很多东西从上个世纪一直沿用到现在，例如一些用语、标牌的设计等等，尤其是很多街道和建筑实际已经建成上百年仍未变更。另一方面这里的多样性也很足，一条路上可以有佛教寺庙、清真寺和教堂，路上有各色人种人来人往，这种景象在国内真的很少见。所以在这里做「人文摄影」会很有意思，我每次去香港都能拍很多照片。
再有就是广州。这是我土生土长的地方，所以说实话有一点点特殊加成。广州跟深圳最大的不同是有很多古迹，老城区很多地方都还是十几、甚至几十年前的样子，跟千篇一律的现代城市有很大反差。
还有一点是，香港和广州有这种景色的地方很多。例如在香港你可以深度去逛旺角、九龙、中环、坚尼地城、赤柱，在广州你可以逛公园前、东山口、上下九，每个地方都有不一样的景色。而在深圳，来来去去就是各种名字不一样但实际差不多的公园和商场。
当然，这几个地方只是我常去/熟悉的，不代表其他地方就不好。我之前去过潮州，有很多古迹，除了一些步行街以外商业化味道也不是很重，也算很出片。但是像长沙，城市的商业化味道就很重，到处是网红打卡点，但打卡这件事情本来就很千篇一律，反而是让我觉得有点反感（见城市旅游就是打卡吗？)。
也欢迎各位推荐一些深圳或者周边适合扫街的地方，真的很久没碰相机了。
用来分别设置鼠标和触控板滚动方向的工具。
macOS 这点真的非常蛋疼，多数人鼠标的习惯是滚轮向上、内容往下，而触控板的逻辑是「自然滚动」，即往上滑动、内容往下。其实这两种逻辑都是合理的，有点像游戏中是否需要反转输入方向的问题（感兴趣可以看这篇文章），只是多数人是先从 PC（Windows）学习使用电脑，也自然而然习惯对应的鼠标操控逻辑。
如果你是用的是罗技的鼠标，可以用自带的 Logi Options+ 设置鼠标滚动的方向，不需要这些软件。
也是一个类似的软件，除了可以单独设置鼠标和触控板滚动方向以外，还有平滑的功能，对习惯用触控板的人来说，临时使用鼠标的滚动体验会舒服很多。
从零开始训练自己的超小语言模型。比较有意思的动手教程，完全开源免费，写得也很详细有深度。
我觉得比传统词典更加「生动活泼」，具体的可以看作者的文章。
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
2025-10-13 02:37:42
本文有 AI 参与编写。
硬件加速是指利用计算机中的专用硬件（如 GPU、专用编解码芯片）来执行视频编解码任务，而不是仅依赖 CPU 进行软件编码。相比纯软件编码，硬件加速具有以下优势：
虽然硬件加速很快，但也有一些需要注意的地方：
Apple 的硬件加速框架，支持 macOS 和 iOS 设备。
# 编码器
h264_videotoolbox
hevc_videotoolbox
# 使用示例
ffmpeg -i input.mp4 -c:v h264_videotoolbox -b:v 2M output.mp4
特点：
NVIDIA GPU 内置的硬件编码器，从 GTX 600 系列开始支持。
# 编码器
h264_nvenc
hevc_nvenc
av1_nvenc # RTX 40 系列及以上
# 使用示例
ffmpeg -hwaccel cuda -i input.mp4 -c:v h264_nvenc -preset p4 output.mp4
特点：
Intel 集成显卡的硬件编码器，从第二代酷睿开始支持。
# 编码器
h264_qsv
hevc_qsv
av1_qsv # 12 代及以上
# 使用示例
ffmpeg -hwaccel qsv -i input.mp4 -c:v h264_qsv -preset medium output.mp4
特点：
AMD GPU 的硬件编码器。
# 编码器
h264_amf
hevc_amf
av1_amf # RX 7000 系列及以上
# 使用示例
ffmpeg -hwaccel amf -i input.mp4 -c:v h264_amf output.mp4
Linux 上的通用硬件加速接口，支持 Intel、AMD 等多种硬件。
# 使用示例
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i input.mp4 \
-vf 'format=nv12,hwupload' -c:v h264_vaapi output.mp4
下面是一个完整的 Python 实现，可以自动检测系统可用的硬件加速方式并选择最佳方案：
import subprocess
import logging
from typing import Optional, Tuple
logger = logging.getLogger(__name__)
def get_hardware_encoder(use_hwaccel: bool = True) -> Tuple[str, Optional[dict]]:
"""
检测可用的硬件加速器并返回合适的编码器设置。
Args:
use_hwaccel: 是否启用硬件加速
Returns:
(video_codec, hwaccel_options) 元组
- video_codec: 编码器名称，如 'h264_videotoolbox'
- hwaccel_options: 硬件加速选项字典，如 {'hwaccel': 'videotoolbox'}
"""
if not use_hwaccel:
return "libx264", None
try:
# 检查可用的硬件加速器
hwaccel_result = subprocess.run(
["ffmpeg", "-hwaccels"],
capture_output=True,
text=True,
timeout=5
)
hwaccels = hwaccel_result.stdout.lower()
# 检查可用的编码器
encoder_result = subprocess.run(
["ffmpeg", "-encoders"],
capture_output=True,
text=True,
timeout=5
)
encoders = encoder_result.stdout.lower()
logger.debug(f"Available hardware accelerators: {hwaccels}")
logger.debug(f"Available encoders: {encoders}")
def test_encoder(codec: str) -> bool:
"""测试编码器是否真正可用"""
try:
result = subprocess.run(
[
"ffmpeg",
"-f", "lavfi", # 使用虚拟输入
"-i", "testsrc=duration=1:size=320x240:rate=1",
"-frames:v", "1", # 只编码一帧
"-c:v", codec, # 指定编码器
"-f", "null", # 输出到空设备
"-"
],
capture_output=True,
text=True,
timeout=10
)
return result.returncode == 0
except Exception as e:
logger.debug(f"Failed to test encoder {codec}: {e}")
return False
# 按优先级检测硬件编码器
# 1. VideoToolbox (macOS/Apple Silicon)
if "h264_videotoolbox" in encoders and "videotoolbox" in hwaccels:
if test_encoder("h264_videotoolbox"):
logger.info("Using VideoToolbox hardware acceleration")
return "h264_videotoolbox", {"hwaccel": "videotoolbox"}
# 2. NVIDIA NVENC
if "h264_nvenc" in encoders:
if test_encoder("h264_nvenc"):
logger.info("Using NVIDIA NVENC hardware acceleration")
if "cuda" in hwaccels:
return "h264_nvenc", {"hwaccel": "cuda"}
return "h264_nvenc", None
# 3. Intel QuickSync
if "h264_qsv" in encoders and "qsv" in hwaccels:
if test_encoder("h264_qsv"):
logger.info("Using Intel QuickSync hardware acceleration")
return "h264_qsv", {"hwaccel": "qsv"}
# 4. AMD AMF
if "h264_amf" in encoders and "amf" in hwaccels:
if test_encoder("h264_amf"):
logger.info("Using AMD AMF hardware acceleration")
return "h264_amf", {"hwaccel": "amf"}
# 5. VAAPI (Linux)
if "h264_vaapi" in encoders and "vaapi" in hwaccels:
if test_encoder("h264_vaapi"):
logger.info("Using VAAPI hardware acceleration")
return "h264_vaapi", {"hwaccel": "vaapi"}
except Exception as e:
logger.warning(f"Error checking hardware encoders: {e}")
logger.info("Falling back to software encoding")
# 回退到软件编码
logger.info("Using software encoding (libx264)")
return "libx264", None
def get_system_info() -> dict:
"""获取系统硬件加速信息"""
try:
# 获取 FFmpeg 版本
version_result = subprocess.run(
["ffmpeg", "-version"],
capture_output=True,
text=True,
timeout=5
)
# 获取硬件加速列表
hwaccel_result = subprocess.run(
["ffmpeg", "-hwaccels"],
capture_output=True,
text=True,
timeout=5
)
# 获取编码器列表（只提取硬件编码器）
encoder_result = subprocess.run(
["ffmpeg", "-encoders"],
capture_output=True,
text=True,
timeout=5
)
hw_encoders = []
for line in encoder_result.stdout.split('\n'):
if any(hw in line.lower() for hw in ['nvenc', 'qsv', 'videotoolbox', 'amf', 'vaapi']):
hw_encoders.append(line.strip())
return {
"ffmpeg_version": version_result.stdout.split('\n')[0],
"hwaccels": hwaccel_result.stdout,
"hw_encoders": hw_encoders
}
except Exception as e:
return {"error": str(e)}
import json
# 获取系统硬件加速信息
info = get_system_info()
print(json.dumps(info, indent=2))
import ffmpeg
def encode_video_with_hwaccel(input_path: str, output_path: str, use_hwaccel: bool = True):
"""使用硬件加速编码视频"""
# 获取硬件编码器
vcodec, hw_options = get_hardware_encoder(use_hwaccel)
# 创建输入流
if hw_options:
# 使用硬件加速解码
stream = ffmpeg.input(input_path, **hw_options)
else:
stream = ffmpeg.input(input_path)
# 配置输出
stream = ffmpeg.output(
stream,
output_path,
vcodec=vcodec, # 使用检测到的编码器
acodec='aac', # 音频编码器
video_bitrate='2M', # 视频比特率
audio_bitrate='192k', # 音频比特率
preset='medium', # 编码预设（硬件编码器可能忽略此参数）
**{'crf': '23'} # 质量参数（硬件编码器可能忽略此参数）
)
# 执行编码
ffmpeg.run(stream, overwrite_output=True)
print(f"Video encoded successfully using {vcodec}")
# 使用硬件加速
encode_video_with_hwaccel('input.mp4', 'output.mp4', use_hwaccel=True)
# 强制使用软件编码
encode_video_with_hwaccel('input.mp4', 'output_sw.mp4', use_hwaccel=False)
def detect_macos_hwaccel():
"""检测 macOS 硬件加速"""
import platform
if platform.system() != 'Darwin':
return None
# 检测芯片类型
machine = platform.machine()
is_apple_silicon = machine == 'arm64'
# Apple Silicon 性能更好
if is_apple_silicon:
return {
'platform': 'Apple Silicon',
'recommended_encoder': 'h264_videotoolbox',
'performance': 'excellent',
'codecs': ['h264_videotoolbox', 'hevc_videotoolbox', 'prores_videotoolbox']
}
else:
return {
'platform': 'Intel Mac',
'recommended_encoder': 'h264_videotoolbox',
'performance': 'good',
'codecs': ['h264_videotoolbox', 'hevc_videotoolbox']
}
def detect_windows_hwaccel():
"""检测 Windows 硬件加速"""
import platform
if platform.system() != 'Windows':
return None
available = []
# 检测 NVIDIA
try:
result = subprocess.run(
['nvidia-smi', '--query-gpu=name', '--format=csv,noheader'],
capture_output=True,
text=True,
timeout=5
)
if result.returncode == 0:
available.append({
'type': 'NVIDIA',
'encoder': 'h264_nvenc',
'gpu': result.stdout.strip()
})
except:
pass
# 检测 Intel QuickSync（通过 FFmpeg）
vcodec, _ = get_hardware_encoder(True)
if 'qsv' in vcodec:
available.append({
'type': 'Intel QuickSync',
'encoder': 'h264_qsv'
})
# 检测 AMD
if 'amf' in vcodec:
available.append({
'type': 'AMD',
'encoder': 'h264_amf'
})
return available
def detect_linux_hwaccel():
"""检测 Linux 硬件加速"""
import platform
import os
if platform.system() != 'Linux':
return None
available = []
# 检测 VAAPI 设备
vaapi_devices = [f'/dev/dri/renderD{i}' for i in range(128, 140)]
for device in vaapi_devices:
if os.path.exists(device):
available.append({
'type': 'VAAPI',
'device': device,
'encoder': 'h264_vaapi'
})
break
# 检测 NVIDIA
try:
result = subprocess.run(
['nvidia-smi'],
capture_output=True,
timeout=5
)
if result.returncode == 0:
available.append({
'type': 'NVIDIA',
'encoder': 'h264_nvenc'
})
except:
pass
return available
以编码一个 1080p 60fps 视频为例：
| 编码器 | 相对速度 | CPU 占用 | 质量评分 |
|---|---|---|---|
| libx264 (软件) | 1x | 100% | 10/10 |
| h264_videotoolbox (M1) | 5-8x | 20% | 8/10 |
| h264_nvenc (RTX 3080) | 8-12x | 15% | 8.5/10 |
| h264_qsv (12 代 Intel) | 4-6x | 25% | 7.5/10 |
| h264_amf (RX 6800) | 6-10x | 20% | 7.5/10 |
自动检测并回退
选择合适的预设
# NVENC 预设
# p1 (fastest) -> p7 (slowest, best quality)
stream = ffmpeg.output(stream, 'output.mp4', vcodec='h264_nvenc', preset='p4')
考虑批量处理
监控编码质量
处理兼容性问题
def safe_encode(input_path, output_path):
"""带错误处理的编码"""
try:
# 尝试硬件加速
encode_video_with_hwaccel(input_path, output_path, use_hwaccel=True)
except Exception as e:
logger.warning(f"Hardware encoding failed: {e}")
logger.info("Retrying with software encoding")
# 回退到软件编码
encode_video_with_hwaccel(input_path, output_path, use_hwaccel=False)
def encode_with_debug(input_path, output_path):
"""启用详细日志的编码"""
vcodec, hw_options = get_hardware_encoder(True)
stream = ffmpeg.input(input_path, **hw_options) if hw_options else ffmpeg.input(input_path)
stream = ffmpeg.output(stream, output_path, vcodec=vcodec)
# 获取完整命令
cmd = ffmpeg.compile(stream, overwrite_output=True)
print(f"FFmpeg command: {' '.join(cmd)}")
# 执行并查看输出
try:
ffmpeg.run(stream, overwrite_output=True, capture_stdout=False, capture_stderr=False)
except ffmpeg.Error as e:
print(f"stdout: {e.stdout.decode()}")
print(f"stderr: {e.stderr.decode()}")
raise
# 查看所有硬件加速方式
ffmpeg -hwaccels
# 查看所有编码器
ffmpeg -encoders | grep -E "(nvenc|qsv|videotoolbox|amf|vaapi)"
# 测试特定编码器
ffmpeg -f lavfi -i testsrc=duration=1:size=1920x1080:rate=30 \
-c:v h264_videotoolbox -f null -
硬件加速是视频处理中的重要优化手段，可以大幅提升处理速度和降低系统负载。通过自动检测和回退机制，我们可以构建一个跨平台的健壮视频处理系统。
关键要点：
2025-10-12 20:26:36
这是猫鱼周刊的第 83 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
好久不见。前两周分别因为单休和国庆假期，而且也没太多内容，所以咕咕了。
放假前写了一篇 Colf 题解，讲的是一个叫Colf的编程挑战，使用最少的 token 数让 AI 通过类似 leetcode 的编程题。跟 AI 磨合了这么久，看起来确实比较有效果（目前还是排在 39 名）。
最近也在做一个叫 dotmate的项目，是之前买的 Quote/0的控制器，官方的 App 虽然能显示非常多信息源，但是编排、数据源没有自己实现来得灵活，所以自己搓了一个。
从这期开始尝试一个排版上的变化。因为之前有微信公众号的读者反馈「项目」部分的 gh-card 会被转成图片，导致最后外链部分排版混乱，所以从这期开始，去掉 gh-card，只提供项目链接。
假期前其实 AI 这块还挺多变动，除了 Claude Sonnet 4.5、DeepSeek-V3.2-Exp、GLM-4.6 扎堆发布之外，Claude Code 也来了一波更新。我觉得最亮眼的是两个，一个是原生的 vscode 插件，另一个就是 checkpoint。
首先说插件这块，这让 Claude Code 的体验真的更上一层楼，因为原来的交互就是开一个终端放在旁边，现在更加像 Cursor 自带的了。这里有个小插曲，插件刚上线的时候我发现了一个 bug，严重到我回退到命令行了，就是插件似乎监听了回车键，在中英文混输的时候按下回车就会发送消息，好在这周更新之后发现修复了。
checkpoint 也是一个我觉得很惊喜的功能。Cursor 中有类似的功能，这点很舒服，在你 vibe 了一大堆代码之后，如果觉得不满意，还能通过一种保险的方式回退到原来的代码（还有一种不保险的方式就是让 LLM 帮你恢复，取决于代码是否还在上下文里面，而且不一定能原样恢复）。这个功能之前我就调研过怎么让 Claude Code 也用上。网上有人做了一个 ccundo的项目，原理是去解析 Claude Code 的 session 文件，然后把状态保存下来。我自己倒是想到一个不一样的方法，通过 hooks触发一个工具，把变更保存下来。其实也有人提过 issue让官方实现这个功能，但是在几轮讨论之后就被冷落了，直到这次更新突然把这个功能端出来。
不得不感叹这个领域的变化真的很快，作为偏下游的用户，一些早些时间调研做不了或者很难的事情，说不定某一次模型的更新或者某个功能的实现就能解决了。
这个就是我上面提到的「不保险」的办法。
事情是作者写了一份草稿代码，实现了一个比较好的效果，于是开始重构成生产级别的代码，过程中出了点问题，再也没法复现原来的效果，他也没有 commit 过代码，所以无从下手。最后他想到 gemini-2.5-pro 有 1M 的上下文，也许它还记得最初的代码，于是让它还原了。
这个方法能成功有两个前提，一个是上下文还保存着，另一个是 AI 真的能原样恢复。「原样恢复」这个我有点钻牛角尖，但是 git 它是可以的，但 LLM 本身就不能产出「确定性」的结果，所以不能跟 git 相提并论。好的编程习惯在什么时候都是有用的，如果能在实现一个完整功能的时候 commit 一次，就没有这个麻烦了。
Cursor 推出了一个计划模式，它大概是这样：
当你指示 Agent 制定计划时，Cursor 会研究你的代码库以查找相关文件、审阅文档并提出澄清问题。当你对计划满意后，它会创建一个包含文件路径和代码引用的 Markdown 文件。你可以直接编辑该计划，包括添加或删除待办事项。
这其实跟我使用 Claude Code 的习惯非常像，我有一个 slash command 就是做这个事：
Read the demands in $ARGUMENTS and come up with a detailed implementation plan. You should:
1. Read the demands in $ARGUMENTS
2. Read relevant files in the codebase
3. Think hard about the best way to implement the demands
4. List the data structures, database tables you are about to add or modify(if any)
5. List API changes you are about to make(if any)
6. List every file you are about to add or modify, including what logics each file is about to implement
If you have any confusion, ask the user for clarification. DO NOT write any codes yet before given clear instruction to do so.
如题，版权问题就不放图了，原图大家点进去看看。
虽然有很多没接触过的语言，但是 C/C++ 那个真的太典了，完全是心目中会写 C 的人的形象。
接触到这篇文章是在我更新机器上的 openssh 之后，push 代码的时候出现了一个 warning：
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
简单来说，现在使用的密钥交换算法（ECDH，椭圆曲线 Diffie-Hellman）基于离散对数问题的困难性，传统计算机需要指数时间破解，但量子计算机可以在多项式时间内解决，把破解时间从几百万年降至几小时。但为什么要现在就开始防范呢？因为攻击者可以在现在就截获数据，然后等十到二十年后量子计算机成熟再解密（store now, decrypt later）。
而 OpenSSH 默认的交换算法 mlkem768x25519-sha256 是一种混合的方案，基于 ML-KEM-768 和传统的 X25519，足够对抗传统计算机和量子计算机的攻击。唯一的代价是密钥会更大而且计算开销更大一点，但对现代计算机没有显著的影响。
future-proof 真的是工程实践上一个非常有意思的事情。不仅是防范眼下可能的攻击，还要提前预知数十年后可能产生的威胁并提出对应的防范方案。
这个标题有点唬人，但是正好说明一个观点：过分清洗语料，过分强调「安全」会让 AI 严重降智，而且这也是各种「评测」体现不了的。
「华人与狗不得入内」是一个大家都熟知的事情，是当年上海租界一个种族歧视的标牌，算是「国耻」。但用这个问题去问 AI 会被拒绝回答：
目前只发现 DeepSeek 所有版本都拒绝回答，其他的一些国产 AI 例如 GLM、豆包、千问等都能正常回答，OpenAI、Anthropic 的模型也能正常回答，并未进一步测试更多模型。
所以在使用 AI 的时候，一定要自己做事实考证，不只是幻觉，伦理和安全的需求会让 AI 有意无意遗忘一些事情。
另一个是，种族歧视也好，不是信息也好，这都是我们人类的一部分，在训练时刻意去掉，只让 AI 看到一个乌托邦，是不是也会有问题？但让 AI 看遍人间邪恶，是不是也会有问题？这也是一个研究领域（AI Safety）。
DevTools 官方做的 MCP 工具，在这之前我用了很多个，有的还需要安装插件，而且也没办法获取 DevTools 里的信息，这个似乎是最好用的。
上面提到的给 Quote/0 写的控制器。我目前主要用这么三个视图：
效果大概是这样：
一个 Mac 的命令行垃圾清理工具，居然是用 shell 写的。不过由于是用 AI vibe 出来的，作者也建议如果数据非常重要，等更加成熟之后再使用。我建议是用 dry-run 先试试。
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
