前言几个月没更新博客，这段时间基本都花在开发一款原生 macOS 应用上。 这是我做的第一款 macOS 应用。我从 2015 年开始使用 Mac，很喜欢 macOS 简洁的界面和系统体验，也一直想亲手做一款原生应用。 过去十年我主要写 Java 后端，熟悉的是 Spring Boot、数据库和服务器，对 SwiftUI、App Sandbox、签名、公证和 StoreKit 基本没有接触。这次只能边做边学，从界面和数据存储，一路做到签名、公证、支付和上架。 这款应用就是 Starcat。现在它已经以 Starcat for GitHub 的名字上架 Mac App Store，也可以通过官网 DMG 和 Homebrew 安装。写这篇文章时，App Store 和 Direct 的公开版本都是 1.3.0。 最初准备写这篇文章时，我想从架构入手，把 SQLite、本地搜索、RAG、双渠道分发和海外支付梳理一遍。但回头翻完整个开发记录，很多问题并不属于架构本身。需求没有讨论清楚，后面的设计和实现就会反复调整；UI 规范没有统一，不同 AI 会按照各自的理解完成页面；自动化测 ...

背景其实需求很简单，就是想在 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& ...

背景最近我在看博客 CDN 访问日志时，发现静态资源的访问量异常增多。 一开始只是觉得有点不对劲：博客本身访问量没有明显上涨，但 CDN 流量消耗却比平时快了不少。继续往日志里翻，发现大量请求都来自一个叫 YisouSpider 的爬虫，而且请求的还不是文章页面，而是博客里那些 JS、CSS 静态资源。 这篇文章记录一下完整的排查过程、问题原因，以及最后为什么我把拦截规则放到了 CDN 层，而不是只在源站 Nginx 里处理。 问题现象在 Nginx / CDN 访问日志里，可以看到大量类似下面的请求： 12320260507164510 124.239.12.111 cdn.dong4j.site /source/static/index-imgloaded.css 1379 1069 2 200 https://blog.dong4j.site/ 215 "YisouSpider" "(null)" GET HTTPS miss 5833520260507164510 116.132.218.241 cdn.dong4j. ...

背景随着业务不断扩展，系统服务数量和访问压力持续增长，当前整体架构已逐步暴露出性能瓶颈与资源竞争等问题，影响了核心业务的稳定性和扩展性。系统采用微服务架构，目前共计 17 个微服务，分布在多个业务域中，运行一段时间后主要暴露出以下典型问题： 部分核心服务资源占用高，影响其他服务的稳定运行； 统计类服务存在大量复杂查询，导致数据库压力集中，查询响应缓慢； 存在分布式事务、大事务与表锁并发问题，在高峰期容易造成请求阻塞或死锁； 缺乏读写分离、异步化、缓存等优化手段，导致部分非关键路径也占用大量系统资源； 系统在监控、限流、容灾等方面存在不足，缺乏针对高并发场景的应对策略。 为全面提升系统性能与稳定性，我们计划从架构优化、数据库治理、慢 SQL 缓解、中间件调优、Spring Boot 优化、连接池/线程池、异步请求等多个方面，逐步推进整改工作，以提高系统稳定性与高并发要求。 项目基础情况技术架构: Spring Cloud Alibaba 微服务架构基础框架: RuoYi 微服务框架核心业务: 用工需求发布、派工管理、支付结算、数据统计 技术架构技术栈 后端: Spri ...