中年男人的三大爱好：充电头、NAS、软路由。这三大爱好不仅为我们的生活带来了便利，也成为了我们生活的一部分(🤡)。 作为一个软件开发者，我一直梦想着拥有自己的服务器，而 NAS 和软路由则是我通往这个梦想的桥梁。 自从购买了我的第一台 NAS 以来，便打开了一扇新世界的大门。NAS，即网络附加存储（Network Attached Storage），它不仅提供了一个安全的数据存储解决方案，还让我能够实现数据的备份和共享。随着时间的推移，我陆续购买了其他硬件产品，如软路由器、服务器等，逐步搭建起了属于我的 HomeLab。 今天，我想和大家分享一下我搭建 HomeLab 的过程，希望能够帮助到那些同样有志于搭建 HomeLab 的朋友。在接下来的博客文章中，我将详细介绍如何选购合适的 NAS 设备、软路由器以及服务器，并分享我在搭建过程中遇到的挑战和解决方案。 HomeLab 并非遥不可及，只要我们用心去探索和实践，就能开启属于自己的个人云端实验室之旅。让我们一起学习、交流和成长，共同打造一个属于我们的数字王国。 前提说明虽然关于 HomeLab 的文章已经很多了，但我还是想记录下自 ...

github.com starcat-app/Starcat GitHub - starcat-app/Starcat: A native macOS app that turns GitHub Stars into a searchable, organized, AI-powered personal knowledge base. A native macOS app that turns GitHub Stars into a searchable, organized, AI-powered personal knowledge base. 各位佬友们好，占用大家一点时间，主要是介绍一些最近花了 2 个月写的一个 GitHub Star 管理工具，但是 Star 管理只是基础功能， 我想做的是将我们 Star 过的项目转变为可用的知识库。 且听我细细道来。 作为一个开发者，我经常到 GitHub 去看一些有意思的开 ...

首发于 少数派: AI 助力改造非智能升降桌：智能升降、语音控制、多端联动…… 1 背景早在 2019 年搬入新家之后，就一直在迭代优化我的办公桌, 现在应该是 V3 版本了: 这个桌子从搬入新家就一直陪伴着我, 它承载了太多太多…. 是的, 就是字面上的意思: 后来因为工作的原因有点轻微腰椎间盘突出, 所以决定给它换一个”躯干”, 桌板还是用的原来的, 毕竟好一点的升降桌都要 3000+ … 最终选择了一款非智能的双电机版本, 升降范围是 64~129cm, 因为我确信凭借自己对硬件的热爱, 可以很容易的改装成智能控制, 但是可能对自己的技术太自信了, 这个想法拖到近段时间才得以实现, 一是有充足的时间, 二是有 AI 的加持. 我的升降桌之前只能通过原厂控制面板操作，面板上有上升、下降和四个档位键: 有时候会出现 B12 错误码, 不过同时按住上下键 5 秒就能重置. 我最初想增加一个旋钮，顺时针旋转升高，逆时针旋转降低，按下旋钮停止。 动手前，我看了少数派的《从零开始，改造一张可以用 Siri 控制的升降桌》，也研究了开源项目 Upsy Desky。它们使用的通 ...

背景其实需求很简单，就是想在 hammerspoon 里加个功能：当我连着公司的 iHome WiFi 时，鼠标高亮用 home.png；到了别的地方换成 work.png。WiFi 名大概长这样：ihome.6500.5g、ihome.ax9000.5g 这种。 踩坑过程第一次尝试：hs.wifi.currentNetwork()想着这不是很简单嘛，搜了一下官方文档，直接调 hs.wifi.currentNetwork() 不就行了： 12local ssid = hs.wifi.currentNetwork()print("当前 WiFi ssid:", ssid) 结果一跑，nil，啥也没打印出来。加点打印确认一下： 1当前 WiFi ssid: nil 行吧，这条路走不通。 尝试 airport 命令Mac 上传统获取 WiFi 信息的方式是 airport 命令： 12/usr/local/bin/airport -I/System/Library/PrivateFrameworks/Apple80211.framework/Versions/ ...

一份文档, 两类读者我维护 Zeka Stack 这套开源框架已经几年了, 它做的事情和大部分公司里的 Spring Boot 脚手架差不多 —— 一堆 cubo-*-spring-boot-starter, 每个 Starter 提供自动配置、统一的异常 / 响应 / 日志 / 配置语义, 让业务项目少写样板代码、多走规范轨道。 过去几年, 我一直把这件事看成”给开发者写文档”。Starter 写完之后, 配套一份 README.md、几个示例工程、一份 docs/ 目录, 同事或开源用户引入 starter, 翻一翻文档, 就能上手。 但去年开始, 我越来越清楚地意识到一件事: 文档的读者变了。过去文档只给开发者看, 现在 AI 也是一种用户 —— 而且会是越来越主要的那种。当业务项目里的同事让 Cursor / Claude Code 写一段 REST Controller 的时候, AI 不会去翻我的 README, 也不知道我这个 starter 自动装了哪些 Bean, 不知道哪些 Bean 可以覆盖、哪些不应该绕过, 不知道 ...

作为一个天天泡在终端里的开发者，我对 Gemini CLI 这类 AI 编程助手是有依赖的。但问题来了——我之前订阅的 Gemini 即将到期，偏偏因为学生认证的限制没法续订。于是我用另一个账号重新订阅了 Gemini Pro，这下手头就有了两个付费账号。两个账号放着不用太浪费，但在不同项目间手动切换实在折腾：关掉当前任务、切换认证凭据、重新跑命令，节奏一断思路也跟着断了。gcam（Gemini CLI Account Manager） 就是来解决这个问题的——它让你的多个账号组成一个池子，需要时自动切换，整个过程对使用者完全透明。项目落地页在 gcam.dong4j.site。 背景：为什么需要多账号管理Gemini CLI 的付费订阅（Google AI Pro）每天大约有 1500 次请求配额，每分钟也有请求频率限制。对于日常开发来说这个量通常够用，但当你像我一样因为续订限制而持有两个付费账号时，手动管理就变成了一个麻烦事——更不用说在多个项目间频繁切换的场景了。 手动切换账号的流程本身并不复杂：改个配置、重新认证一下就好。但问题在于它把一个本该自动化的决策强加给了使用者。你得 ...

翻车现场我自己写过的 Agent Skill, 现在回头数, 大概在十几份的量级。这十几份里面, 至少有一半在写下来的当下就是错的。 举几个典型: name 字段写得很随意, 跟父目录名对不上 —— Agent 加载的时候按目录名走, 但匹配按 name 走, 我调了快一小时才发现 skill 根本没被识别。description 写成 “helper” 或者 “tool” 就交差了, 等到真的去用, Agent 完全不知道该在什么场景触发它, 因为没有任何触发短语 (“use when”, “when to use” 之类), AI 看了等于没看。一段 rm -rf 当时只是放在正文里当示意, 完全没想到 Agent 会把它当成可以执行的步骤直接跑。一段 references/api-design.md 的 link 引用我写完之后忘了真的把文件建出来。还有一个最尴尬的, 我把 api_key="sk-..." 直接硬编码到 skill 里某个示例脚本, 然后 push 到了开源仓库。 每一条都是低级错误, 每一条都是”如果有人在 IDE 里提醒我一句, ...

背景最近在找工作。 我觉得自己的简历写得还算可以——项目经历、技术栈、工作职责，该写的都写了。但 BOSS 上投出去，十有七八已读不回。姑且不说「HR 只是占坑不拉屎」，我更偏向于: 简历是不是写得不够 match JD？ 我倾向于相信：一份简历应该「面向 JD 定制」，而不是用同一份简历广撒网。所以每次投递之前，我都会根据 JD 重排技能关键词、调整项目侧重点。但问题是：如果每个公司都这么手动来，工作量太大了。 另一方面，我有个习惯——投递之前会先去意向公司的官网看看，顺便试用一下他们的产品，然后用一些合理的技术手段了解一下公司用的技术栈，甚至看看有没有什么常见的漏洞。这些信息对写简历有帮助，但收集起来是个体力活儿。 所以我想：能不能把这些重复劳动自动化？ 每次看到感兴趣的 JD，跑一条命令，自动生成一套材料：公司调研、JD 匹配分析、定制简历、打招呼话术、面试追问——全部搞定。 前提：个人 Wiki 知识库但这里有个前提：如果想让 AI 生成有质量的定制简历，AI 必须「了解你」。如果只是让 LLM 从零开始编，它要么瞎编，要么写出来的东西跟市面上千篇一律的简历没什么区别。 我的 ...

背景最近我一直在重新思考一个问题：在 AI 已经可以大量生成代码的今天，Spring Boot Starter 这类工程脚手架的价值还剩下什么？ 过去做 Starter，主要是为了减少重复配置。开发者引入一个依赖，就能获得自动配置、默认 Bean、统一异常处理、统一响应模型、消息队列封装、接口文档集成等能力。它解决的是“少写样板代码”和“统一工程规范”的问题。 但现在 AI 已经能很快生成 Controller、Service、DTO、Mapper，甚至配置文件和测试代码。单纯减少样板代码，已经不再是框架最核心的竞争力。 真正的问题变成了：AI 写出来的代码，是否理解你的工程体系？ 它知道项目为什么要用统一响应模型吗？它知道某个 Starter 已经自动装配了哪些 Bean 吗？它知道哪些 Bean 可以覆盖，哪些不应该绕过吗？它知道同一个组件下 Servlet Starter 和 Reactive Starter 应该怎么选吗？它知道团队约定的异常处理、配置方式、日志方式和扩展边界吗？ 如果 AI 不知道这些，它写得越快，偏离工程规范的速度也越快。 这也是我在思考 Zeka Sta ...

统一管理本地 Code Agent 全局规则：从 AGENTS.md 到 Synology Drive 同步最近一段时间，我在本地同时使用了几类 Code Agent 工具，比如 Codex CLI、Claude Code、opencode、Gemini CLI，再加上平时也会用 Cursor。这些工具确实能显著提升开发效率，但用得越多，一个问题也越明显： Agent 很强，但如果没有稳定的规则约束，它很容易“过度发挥”。 比如： 让它给一个实现建议，它直接开始改代码； 明明只是一个小需求，它生成一堆复杂抽象； 原本只需要局部修改，它顺手重构了一大片； 新增文件没有注释，没有上下文说明； 不同工具之间行为不一致，同一个需求在 Claude Code、Codex、Gemini 里表现完全不同； 一个工具记得“先给方案再修改”，另一个工具上来就落盘。 这些问题单看都不大，但在日常工程开发里会不断累积成摩擦：你需要反复提醒、反复纠偏、反复 review AI 生成的无关改动。 于是我今天做了一次整理：把多个 Code Agent 工具的全局规则统一起来，放到一个可同步的全局规则文 ...

背景在 IDEA 或其他开发工具里，生成 Git 提交记录已经是一件很简单的事情。 比如我在 IDEA 里会用 IntelliAI Changelog 插件，点一下图标，就可以让 AI 根据当前变更生成一条比较准确的 commit message。对日常开发来说，这个体验很顺手：不用手动翻 diff，也不用纠结这次到底该写 fix、docs 还是 chore。 但到了终端里，事情就稍微麻烦一点。 我本机有不少本地仓库，不全是正式项目。有些是 Surge 配置，有些是 Wiki 知识库，有些是博客依赖目录，还有一些是个人小工具。它们都用 Git 记录变更历史，但我不想每个仓库都手写提交记录。 一开始最直接的办法，是把 staged diff 丢给 Claude： 12345678git diff --cached | claude -p '根据 git diff 生成一条中文 Conventional Commit message。只输出 commit message，不要解释。格式：<type>(<scope>): <subject>&l ...

原帖链接：https://x.com/dotey/status/2052929093461528903?s=20 使用 Claude Code：HTML 难以置信的奇效【译】 原文： Markdown 已经成为 AI 智能体 (AI Agent) 与我们沟通时最常用的文件格式。它简单、便携、具备一定的富文本 (Rich text) 能力，而且极其容易进行人工修改。你甚至会发现，Claude 已经变得极其擅长在 Markdown 文件里用 ASCII (美国信息交换标准代码，这里指用纯文本符号拼凑成图表) 字符来画图了。 但是，随着 AI 智能体变得越来越强大，我开始觉得 Markdown 变成了一种束缚。面对动辄上百行的 Markdown 文件，我根本没有耐心读下去。我想要更丰富的视觉展现、明亮的色彩和直观的图表，而且希望能够轻松地把它们分享给团队。 另外，我现在越来越少亲自去编辑这些文件了。我更多是把它们当作需求文档 (Specs)、参考资料或是头脑风暴的输出结果。即使需要修改，我通常也是直接写提示词 (Prompt) 让 Claude 去改。这就让 Markdown 最核 ...

我的 AI Native 开发者画像（2026） 基于 196 天的本地 Claude Code + Codex 对话数据自动生成 · 2026-05-08T15:18:22+08:00默认对外分享版：项目名已匿名，敏感字段已清洗。 一览 在 196 天里完成 481 次 Claude sessions + 296 次 Codex threads，共 1.9万 条 Claude 消息 日均产出：20.69 commits / 8.1万 行代码变动 / 28.23 GitHub contributions 同时维护 18 个本地仓库，横跨 74 类语言/文件扩展 同期 GitHub：2,155 commits / 1 PRs / 30 issues / 2,682 总贡献 本地 git：1,966 commits / +5.24M / -2.46M AI 投入：27.24M Claude 新付费 token + 1.46B Codex token；复用 215.98M 缓存（占 Claude I& ...