短文
分享一些小技巧。
让 Claude Code 使用 tmux/screen 执行交互式操作
起因是逛 YouTube 时看到了 Armin Ronacher 的这两个视频： Claude Runs LLDB in Screen Claude Code Debugs with LLDB in TMUX 看起来很酷炫，但实际上原理很简单：screen/tmux 都支持通过命令行传递输入并返回当前正在展示的内容，只需要写个文档让 Claude Code 用就好了（见文末）。 Screen: -X stuff 输入，-X hardcopy 输出 Tmux: send-keys 输入 …
起因是逛 YouTube 时看到了 Armin Ronacher 的这两个视频： Claude Runs LLDB in Screen Claude Code Debugs with LLDB in TMUX 看起来很酷炫，但实际上原理很简单：screen/tmux 都支持通过命令行传递输入并返回当前正在展示的内容，只需要写个文档让 Claude Code 用就好了（见文末）。 Screen: -X stuff 输入，-X hardcopy 输出 Tmux: send-keys 输入 …
为什么 JDK 的镜像比 JRE 镜像小？
TLDR：虽然 JDK 镜像内容比 JRE 镜像多，但 JDK 镜像的压缩比更高，导致最后镜像大小反而 JDK 比 JRE 小；原因是 JDK 镜像主要用于 CI/CD 流水线，对性能和耗时要求不太高，所以可以用更高的压缩比；但 JRE 镜像主要用于线上服务，对性能要求极高，因此基本没有压缩。 AI 贡献提示：技术探索过程主要由 Claude Code + Kimi K2 完成；文字部分主要为 Gemini Pro 2.5 编写；我仅提供探索方向指导和简单内容编辑。我已在能力范围内确认下述内容的 …
TLDR：虽然 JDK 镜像内容比 JRE 镜像多，但 JDK 镜像的压缩比更高，导致最后镜像大小反而 JDK 比 JRE 小；原因是 JDK 镜像主要用于 CI/CD 流水线，对性能和耗时要求不太高，所以可以用更高的压缩比；但 JRE 镜像主要用于线上服务，对性能要求极高，因此基本没有压缩。 AI 贡献提示：技术探索过程主要由 Claude Code + Kimi K2 完成；文字部分主要为 Gemini Pro 2.5 编写；我仅提供探索方向指导和简单内容编辑。我已在能力范围内确认下述内容的 …
让 Claude Code 使用其他模型
最近在尝试各类 agent 项目，大部分都支持使用任何 OpenAI 兼容 API 格式的模型提供商，但是作为这个流派最著名的 Claude Code 却只能用自家模型。自家模型其实也不错，但是对我这种无法在生产环境使用，只是用来自己探索和 side project 的场景下太贵了。搜了下似乎没有人介绍过如何让 Claude Code 和非官方模型配合使用，于是决定记录下。 这一方法的核心是 Claude Bridge 这个项目。实现上，和任何计算机科学问题的解决方式一样，加了一个中间层。具体而 …
最近在尝试各类 agent 项目，大部分都支持使用任何 OpenAI 兼容 API 格式的模型提供商，但是作为这个流派最著名的 Claude Code 却只能用自家模型。自家模型其实也不错，但是对我这种无法在生产环境使用，只是用来自己探索和 side project 的场景下太贵了。搜了下似乎没有人介绍过如何让 Claude Code 和非官方模型配合使用，于是决定记录下。 这一方法的核心是 Claude Bridge 这个项目。实现上，和任何计算机科学问题的解决方式一样，加了一个中间层。具体而 …
comic-bbox-translator - 用 LLM 生成带边界框的翻译
起因是在看推上的日语同人；如果用 LLM 直接翻译的话，无论加了什么prompt，最后翻译出来的顺序也是乱的（可能是因为视觉模型内在的处理顺序问题？），需要脑内重排序，不太爽；正巧之前看到过其他人的博客，说现在视觉模型可以输出边界框了，于是趁着放假 vibe coding 了一把，果然还真可以用；虽然边界框偶尔不太准，但是大部分场景下也足够了。起初用 Python 写了一个版本，但后面意识到其实可以直接用 Web 技术实现，省的用户另外配置环境了。 Repo: …
起因是在看推上的日语同人；如果用 LLM 直接翻译的话，无论加了什么prompt，最后翻译出来的顺序也是乱的（可能是因为视觉模型内在的处理顺序问题？），需要脑内重排序，不太爽；正巧之前看到过其他人的博客，说现在视觉模型可以输出边界框了，于是趁着放假 vibe coding 了一把，果然还真可以用；虽然边界框偶尔不太准，但是大部分场景下也足够了。起初用 Python 写了一个版本，但后面意识到其实可以直接用 Web 技术实现，省的用户另外配置环境了。 Repo: …
Today I Learned - 更简单更频繁的分享
对我来说，写文章其实是心理门槛挺高的一件事，会觉得得对某个事物充分了解，完全掌握了，才有动力去下笔。（虽然大概这里的文章并没有达到这样一个状态。）但也有时候，我见到了一个有趣或者有用的事物，可能是一篇论文、一个项目、一条视频，或者只是简单的一个想法，会有分享的欲望。为此写文章有些太大动干戈了，但是不将他们分享出去又有些可惜。现实生活里我有一个小群来分享这些东西，但我认为它们值得被更多人看到。 因此，在我经常阅读的另外两位创作者 Simon Willision 和 Julia Evans 的启发下 …
对我来说，写文章其实是心理门槛挺高的一件事，会觉得得对某个事物充分了解，完全掌握了，才有动力去下笔。（虽然大概这里的文章并没有达到这样一个状态。）但也有时候，我见到了一个有趣或者有用的事物，可能是一篇论文、一个项目、一条视频，或者只是简单的一个想法，会有分享的欲望。为此写文章有些太大动干戈了，但是不将他们分享出去又有些可惜。现实生活里我有一个小群来分享这些东西，但我认为它们值得被更多人看到。 因此，在我经常阅读的另外两位创作者 Simon Willision 和 Julia Evans 的启发下 …
code2prompt - 满足「这是怎么做到的」好奇心的小工具
我发现自己经常对着一个有趣的 Github Repo 思考：「这看起来真不错！但是究竟是怎么做到的？」。但很多时候我无法满足我的好奇心。要么是这个项目并没有自带一个「How it works / 工作原理」的介绍（在我看来这应该是每个项目 README 的必备），要么是我没有时间或者耐心在层层叠叠的文件树或者错综复杂的调用链里自己找到答案。得益于近来 LLM 的上下文窗口增长，让 LLM 来帮我回答这一问题似乎是个不错的选择。即使 LLM 回答给出的答案可能有错误或者不完整，但至少能给出一些探索 …
我发现自己经常对着一个有趣的 Github Repo 思考：「这看起来真不错！但是究竟是怎么做到的？」。但很多时候我无法满足我的好奇心。要么是这个项目并没有自带一个「How it works / 工作原理」的介绍（在我看来这应该是每个项目 README 的必备），要么是我没有时间或者耐心在层层叠叠的文件树或者错综复杂的调用链里自己找到答案。得益于近来 LLM 的上下文窗口增长，让 LLM 来帮我回答这一问题似乎是个不错的选择。即使 LLM 回答给出的答案可能有错误或者不完整，但至少能给出一些探索 …
游戏推荐 - A Short Hike
我很少主动玩游戏。虽然有时会看其他人的游玩/剧情视频，但是自己实际上手玩的几乎没有。可能是小学的时候玩得足够多，长大之后反而对游戏失去了兴趣。我不想在竞技类游戏里比拼分数，也不想在策略类游戏里消耗脑力，更不想在吃操作的游戏里磨炼键位。日常生活已经够累了，何必再在游戏里自寻烦恼呢？但是 A Short Hike 让我体会到了不一样的感受。这是一个玩起来放松、甚至治愈的游戏。（用番剧类比的话，就像《摇曳露营》的第一季。）它让我如此惊喜，以至我甚至愿意专门写这篇短文来推荐。 为什么它能有这样的神奇效果 …
我很少主动玩游戏。虽然有时会看其他人的游玩/剧情视频，但是自己实际上手玩的几乎没有。可能是小学的时候玩得足够多，长大之后反而对游戏失去了兴趣。我不想在竞技类游戏里比拼分数，也不想在策略类游戏里消耗脑力，更不想在吃操作的游戏里磨炼键位。日常生活已经够累了，何必再在游戏里自寻烦恼呢？但是 A Short Hike 让我体会到了不一样的感受。这是一个玩起来放松、甚至治愈的游戏。（用番剧类比的话，就像《摇曳露营》的第一季。）它让我如此惊喜，以至我甚至愿意专门写这篇短文来推荐。 为什么它能有这样的神奇效果 …
读书记录《悟道领域驱动设计》
ch2 应用架构 贫血模型 vs 充血模型 贫血模型：类只是数据容器，没有行为（例如 pojo） 充血模型：类有属性（数据），也有方法（行为） 项目结构 接口层：对外暴露api/消息consumer 应用服务层：协调领域模型完成业务逻辑 基础设施层：写db/缓存/调外部服务 领域层：领域内的具体逻辑 查询的两种实现 1 读数据后加载领域模型（聚合根），聚合根转换为查询结果 view 2 直接用实际存储的数据模型，跳过领域对象加载，直接用把数据模型转换为查询结果 view ch3 实体和值对象 …
ch2 应用架构 贫血模型 vs 充血模型 贫血模型：类只是数据容器，没有行为（例如 pojo） 充血模型：类有属性（数据），也有方法（行为） 项目结构 接口层：对外暴露api/消息consumer 应用服务层：协调领域模型完成业务逻辑 基础设施层：写db/缓存/调外部服务 领域层：领域内的具体逻辑 查询的两种实现 1 读数据后加载领域模型（聚合根），聚合根转换为查询结果 view 2 直接用实际存储的数据模型，跳过领域对象加载，直接用把数据模型转换为查询结果 view ch3 实体和值对象 …
不要在 gcc 7 里隐式捕获 constexpr 数组
如果你还没有遇到过 compiler bug，说明你写的代码还不够多。 —— 一位本科同学 虽然经常能看到其他人遇到 compiler 导致的意外现象，自己遇到却还是第一次，因此还是写篇文章小小记录下。 因为一些原因，目前工作中使用的 gcc 版本是 7.4。接到一个业务需求，需要对某些特定的用户打开一个 feature flag，且需要在代码里硬编码。代码很快就写完了，自测的时候却发现不太对劲。相关代码简化脱敏后如下所示。逻辑很简单，就是把可以进入灰度的用户 id 放到了一个 …
如果你还没有遇到过 compiler bug，说明你写的代码还不够多。 —— 一位本科同学 虽然经常能看到其他人遇到 compiler 导致的意外现象，自己遇到却还是第一次，因此还是写篇文章小小记录下。 因为一些原因，目前工作中使用的 gcc 版本是 7.4。接到一个业务需求，需要对某些特定的用户打开一个 feature flag，且需要在代码里硬编码。代码很快就写完了，自测的时候却发现不太对劲。相关代码简化脱敏后如下所示。逻辑很简单，就是把可以进入灰度的用户 id 放到了一个 …
工具小站
参考 tools.simonwillison.net，决定把所有单页纯前端应用全部放到到一个 repo 里，并且分配一个子域名；这样不用每个小工具都申请独立 repo + 配置 Github Actions 了。 虽然目前还是没什么东西，但是还是欢迎来玩：pages.nekonull.me
参考 tools.simonwillison.net，决定把所有单页纯前端应用全部放到到一个 repo 里，并且分配一个子域名；这样不用每个小工具都申请独立 repo + 配置 Github Actions 了。 虽然目前还是没什么东西，但是还是欢迎来玩：pages.nekonull.me
基于 WebRecorder 和 MitmProxy 的图片手动抓取探索
最近收到任务，需要从某个站点下载一系列图片。首先当然是 F12 看下网络请求。这是一个无限滚动的瀑布流，图片地址本身是随机的（看起来文件名像是 uuid），所以没法直接遍历图片地址；此外每次滚动到底，都会触发一个获取下一页图片地址的请求，参数传的还是游标而不是页数，这又断绝了直接构造分页请求（例如 page=1）获取所有图片地址，再逐个拉取的念头。好在总图片数是有限的，大概在 2k 左右，每次下拉能拉回 50 条，所以手动抓取也不是不能接受。以下是两种手动抓取的思路。注：这里的手动抓取，指的是在 …
最近收到任务，需要从某个站点下载一系列图片。首先当然是 F12 看下网络请求。这是一个无限滚动的瀑布流，图片地址本身是随机的（看起来文件名像是 uuid），所以没法直接遍历图片地址；此外每次滚动到底，都会触发一个获取下一页图片地址的请求，参数传的还是游标而不是页数，这又断绝了直接构造分页请求（例如 page=1）获取所有图片地址，再逐个拉取的念头。好在总图片数是有限的，大概在 2k 左右，每次下拉能拉回 50 条，所以手动抓取也不是不能接受。以下是两种手动抓取的思路。注：这里的手动抓取，指的是在 …
如何手动 squash
最近帮解决了一个因为提交流程不规范导致的诡异 Git 分支问题，特此记录下，以备后用。 背景：主干分支 main，特性分支 feat，在特性分支上开发特性的时候，多次合入了主干分支（仅快进，没有合并冲突）；模拟的 Git 历史如下图所示，其中 m* 是主干提交，f* 是特性分支提交 * 5fb94b2 (HEAD -> main) m4 | * 83c6299 (feat) f3 | * ff5c5af Merge branch 'main' into feat | |\ | |/ |/| * …
最近帮解决了一个因为提交流程不规范导致的诡异 Git 分支问题，特此记录下，以备后用。 背景：主干分支 main，特性分支 feat，在特性分支上开发特性的时候，多次合入了主干分支（仅快进，没有合并冲突）；模拟的 Git 历史如下图所示，其中 m* 是主干提交，f* 是特性分支提交 * 5fb94b2 (HEAD -> main) m4 | * 83c6299 (feat) f3 | * ff5c5af Merge branch 'main' into feat | |\ | |/ |/| * …
在 Devtools 里触发前端组件的内部状态更新
这个标题大概不太好理解；以下是对我遇到的问题，及我的解决方案的描述，在获得了相关上下文后，这个标题可能会稍微好理解一些。 背景：在我的工作中，时常需要使用一个内部的日志查询平台。在使用时，需要先指定日志的开始和结束时间，默认情况下开始时间会被设置为今日的0点，结束时间则被设置为今日的23:59:59。虽然大部分情况下默认值都足够了，但是有时我需要调整时间范围，例如，选择为昨天，或是选择为某个 unix timestamp / yyyy-MM-dd hh-mm-ss 的前后一分钟。但无论是从界面 …
这个标题大概不太好理解；以下是对我遇到的问题，及我的解决方案的描述，在获得了相关上下文后，这个标题可能会稍微好理解一些。 背景：在我的工作中，时常需要使用一个内部的日志查询平台。在使用时，需要先指定日志的开始和结束时间，默认情况下开始时间会被设置为今日的0点，结束时间则被设置为今日的23:59:59。虽然大部分情况下默认值都足够了，但是有时我需要调整时间范围，例如，选择为昨天，或是选择为某个 unix timestamp / yyyy-MM-dd hh-mm-ss 的前后一分钟。但无论是从界面 …
Obsidian 与工作日志
虽然从开始工作到现在已经有两年多了，但大部分时间里我需要同时跟进的事项并没有那么多，复杂度也没有太高，基本上不需要太多记录就可以完成。但是最近几个月以来，手头工作的数量和复杂度都急剧上升，完全依靠大脑跟进已经逐渐不可能了。在此背景下，我开始尝试用 Obsidian 搭建自己的工作日志系统，也读到了其他人的一些分享（如 Use A Work Journal To Recover Focus Faster And Clarify Your Thoughts）。目前我的工作日志系统已经正常运转大概三个 …
虽然从开始工作到现在已经有两年多了，但大部分时间里我需要同时跟进的事项并没有那么多，复杂度也没有太高，基本上不需要太多记录就可以完成。但是最近几个月以来，手头工作的数量和复杂度都急剧上升，完全依靠大脑跟进已经逐渐不可能了。在此背景下，我开始尝试用 Obsidian 搭建自己的工作日志系统，也读到了其他人的一些分享（如 Use A Work Journal To Recover Focus Faster And Clarify Your Thoughts）。目前我的工作日志系统已经正常运转大概三个 …
读书记录《时间贫困》
书名：《时间贫困》 评价：7/10；很短的书，快的话一小时就能读完；了解到了一些和自己认知之外但符合自己真实感受的观点（e.g. 完全躺平未必会快乐）；可能会试试书中描述的行动。 版本：微信读书 观点 可支配时间长!=幸福：可支配时间太少（如每天少于2小时）会带来压力，从而降低幸福感；可支配时间太多（如每天超过5小时）会让人缺乏目标感，从而降低幸福感；排除时间太少和太多的极端情况，幸福与你所拥有的可支配时间的长短无关，而是取决于你如何利用自己拥有的时间。 时间充裕与否会影响自信： 时间很多时，我 …
书名：《时间贫困》 评价：7/10；很短的书，快的话一小时就能读完；了解到了一些和自己认知之外但符合自己真实感受的观点（e.g. 完全躺平未必会快乐）；可能会试试书中描述的行动。 版本：微信读书 观点 可支配时间长!=幸福：可支配时间太少（如每天少于2小时）会带来压力，从而降低幸福感；可支配时间太多（如每天超过5小时）会让人缺乏目标感，从而降低幸福感；排除时间太少和太多的极端情况，幸福与你所拥有的可支配时间的长短无关，而是取决于你如何利用自己拥有的时间。 时间充裕与否会影响自信： 时间很多时，我 …
读书记录《软件设计的哲学（第2版）》
书名：A Philosophy of Software Design (2nd Edition) 评价：8.5/10；一开始是看到封面感觉很棒，于是就找来读了下；不是很长，三四个小时就能读完；虽然内容比较基本，但是能系统化的重新复习下也挺好的 版本：anna’s archive，llm翻译为中文 软件设计的原则 复杂性的管理 复杂性源自依赖和晦涩的累积；随着复杂性增加，它导致变更放大、高认知负荷以及未知的未知因素 变更放大：一个看似简单的改动需要在多处修改代码 认知负荷：为了进行更改，开发者必须 …
书名：A Philosophy of Software Design (2nd Edition) 评价：8.5/10；一开始是看到封面感觉很棒，于是就找来读了下；不是很长，三四个小时就能读完；虽然内容比较基本，但是能系统化的重新复习下也挺好的 版本：anna’s archive，llm翻译为中文 软件设计的原则 复杂性的管理 复杂性源自依赖和晦涩的累积；随着复杂性增加，它导致变更放大、高认知负荷以及未知的未知因素 变更放大：一个看似简单的改动需要在多处修改代码 认知负荷：为了进行更改，开发者必须 …
多语言的 Hugo 博客
之前看到了某位同学的分享，提到他在将博客多语言化之后，访问量有了显著的上升，于是也想试试看。在 OpenAI 的加持下文章翻译并不是什么难事，但是想要给一个现存的 Hugo 站点增加多语言支持依然不轻松。虽然 Hugo 本身自带了多语言支持的基本特性（文档：Hugo Multilingual），但是倘若选用的主题不支持，则还需要对主题进行改造。 目前对本博客，我选择了"按文件名翻译"的做法，从文档来看这似乎是对现有文件结构侵入最小的方案。简单来说，如果你的博客 Markdown 文件位于 …
之前看到了某位同学的分享，提到他在将博客多语言化之后，访问量有了显著的上升，于是也想试试看。在 OpenAI 的加持下文章翻译并不是什么难事，但是想要给一个现存的 Hugo 站点增加多语言支持依然不轻松。虽然 Hugo 本身自带了多语言支持的基本特性（文档：Hugo Multilingual），但是倘若选用的主题不支持，则还需要对主题进行改造。 目前对本博客，我选择了"按文件名翻译"的做法，从文档来看这似乎是对现有文件结构侵入最小的方案。简单来说，如果你的博客 Markdown 文件位于 …
我的 AI Prompt
记录下自己自用的一些 Prompt。只是迭代下来感觉还不错，但不一定是最好的。如有推荐欢迎回复补充。 通用场景 （主要配合 GPT-3.5-Turbo 使用，回答代码类问题） You are a helpful assistant and also a professional & experienced developer. You can help me by answering my questions. You can also ask me questions. If you are …
记录下自己自用的一些 Prompt。只是迭代下来感觉还不错，但不一定是最好的。如有推荐欢迎回复补充。 通用场景 （主要配合 GPT-3.5-Turbo 使用，回答代码类问题） You are a helpful assistant and also a professional & experienced developer. You can help me by answering my questions. You can also ask me questions. If you are …
用 mitmproxy 让 ChatGLM 适配 OpenAI 接口
最近看到了几篇关于智谱 AI 的推送文章，才想起来他们的大模型（ChatGLM 系）已经上线好久了。回想 6B 模型刚公布的那会还在 AutoDL 上自己跑过，不过因为模型本身太小，所以其实能做的并不算多。注册了个开发者账户看了看文档，目前可以广泛使用的是 ChatGLM-Turbo，上下文窗口 32k token，定价 0.005 元/千token，还是很便宜的。更不用说因为 GLM 系模型以中文语料为主，所以同等长度的中文文本，用 GLM 的 token 消耗比用 GPT 系列的 token …
最近看到了几篇关于智谱 AI 的推送文章，才想起来他们的大模型（ChatGLM 系）已经上线好久了。回想 6B 模型刚公布的那会还在 AutoDL 上自己跑过，不过因为模型本身太小，所以其实能做的并不算多。注册了个开发者账户看了看文档，目前可以广泛使用的是 ChatGLM-Turbo，上下文窗口 32k token，定价 0.005 元/千token，还是很便宜的。更不用说因为 GLM 系模型以中文语料为主，所以同等长度的中文文本，用 GLM 的 token 消耗比用 GPT 系列的 token …
用 mitmproxy 重定向 OpenAI 请求到 OpenRouter
背景 最近在尝试使用一些基于 GPT 开发的工具，但遇到了一些网络相关的小问题。因为支付方式的限制，我自己并没有 OpenAI 的账户，实际使用的 API 是其他中间商（aka 二道贩子）转卖而来的， OpenRouter 就是其中一家。（实际上 OpenRouter 做的还更多一些，更像是 LLM 的聚合提供商，除了 OpenAI 也有其他家的 LLM，如 Claude 或是 LLama。）但是很多开源工具并未考虑到这种情况，基本上都是假定用户使用的就是 OpenAI 的官方 API 端点，所 …
背景 最近在尝试使用一些基于 GPT 开发的工具，但遇到了一些网络相关的小问题。因为支付方式的限制，我自己并没有 OpenAI 的账户，实际使用的 API 是其他中间商（aka 二道贩子）转卖而来的， OpenRouter 就是其中一家。（实际上 OpenRouter 做的还更多一些，更像是 LLM 的聚合提供商，除了 OpenAI 也有其他家的 LLM，如 Claude 或是 LLama。）但是很多开源工具并未考虑到这种情况，基本上都是假定用户使用的就是 OpenAI 的官方 API 端点，所 …