背景在 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 ...

验证码是用来干什么的验证码的核心作用就一个：提高自动化滥用的成本。 让机器不能以极低成本去暴力枚举。说白了就是让非法的请求尽早被拦截，不要让它打到数据库。 这个定义反过来也成立：如果一个验证码实现，不能在前置阶段拦截非法请求，而是让请求先查一次数据库再校验验证码，那它就没起到验证码的作用。 不幸的是，我们的验证码实现就是这样。 先查数据库，再校验验证码验证码校验逻辑在网关的一个 Filter 中实现。简化的流程是这样的： 123收到登录请求 → 判断用户名是不是手机号 → 是：跳过用户查询，直接用手机号校验验证码 否：先通过用户名查询用户信息（DB 查询！） → 再校验验证码 关键代码（脱敏后）： 1234567891011121314151617if (!Validator.isMobile(username)) { // 通过帐号查询手机号（登陆名不一定是手机号） CompletableFuture<Response<LoginUser<?>>> completableFuture = Comple ...

从零开始：怎么实现一套应用层加解密在讲实际项目之前，先把问题简化：假设你有一个前后端分离的 Web 应用，已经部署了 HTTPS，但现在要求在应用层再做一层加密。你会怎么设计？ 为什么是混合加密先想一个问题：能不能全用对称加密（比如 AES）？ 可以。前端和后端约定一个固定的 AES 密钥，请求和响应都用它加解密。但问题是——密钥写在前端代码里，浏览器 Sources 面板一搜就有。密钥泄露后，所有人都能解密所有流量。而且这个密钥没法换——一换，所有前端代码都要重新构建部署。 那全用非对称加密（比如 RSA、SM2）呢？ 也可以。前端用公钥加密数据，后端用私钥解密。公钥泄露无所谓，没有私钥解不开。但问题是——非对称加密很慢。RSA-2048 加密 1KB 数据的时间能做几百次 AES 加密，而且非对称加密对数据长度有限制（RSA-2048 最多加密 245 字节）。你要加密一个 JSON 请求体，可能几 KB 甚至几十 KB，根本塞不进非对称加密的明文长度上限。 所以业界标准做法是混合加密——用非对称加密保护对称密钥，用对称密钥加密业务数据： sequenceDiagram ...

背景：脚手架的价值边界变了 最近我一直在想一个问题：当 AI 已经可以稳定生成 Controller、Service、DTO、Mapper、测试、文档和脚本时，一套 Spring Boot 脚手架还剩下什么价值？ 如果脚手架的价值只剩“少写几行样板代码”，那它确实会越来越弱。过去开发者需要模板、生成器和 Starter 来节省重复劳动，现在这些工作大模型几分钟就能完成，而且还能顺手补一份 README 和测试样例。 但这个判断只说对了一半。 AI 让“写代码”变便宜了，却让“约束代码”变重要了。代码生成速度越快，架构边界、模块职责、异常语义、接口契约、配置规范、日志标准、测试策略、发布纪律这些东西就越关键。没有这些约束，AI 不是提高工程质量，而是更快地放大混乱。 这也是我现在重新看 Zeka Stack 3.0 的核心出发点：它不应该是一次普通升级，也不应该只是给框架加几个 AI 功能，而应该是一次定位变化。 Zeka Stack 过去主要是一套面向开发者的底层框架。3.0 之后，它应该成为一套面向开发者和 AI 的工程底座。 当前状态：不是从零开始接 AIZeka Sta ...

bootstrap.yml 为什么不在了我在第五篇文章里写了 @Value 到 @ConfigurationProperties 的迁移。那是配置管理的”内容”层面——配置怎么写、怎么校验、怎么分类。这篇文章说的是配置管理的”机制”层面——配置文件本身是怎么被加载的，以及从一个机制迁移到另一个机制时要面对的坑。 先说背景：Spring Cloud 2020+（对应 Spring Boot 2.4+）废弃了 bootstrap.yml。 很多人可能都没注意到这件事。因为如果你的项目是那之前创建的，你的 bootstrap.yml 还在正常工作——Spring Cloud 还保留着向后兼容的能力。但如果你从 Spring Boot 2.3 跳到 3.x，或者像我一样在做架构迁移，就会发现 bootstrap.yml 被官方标记为”不推荐使用”。 为什么要废弃？官方的理由有三条： 额外的上下文。 bootstrap.yml 和 application.yml 是两个独立的 ApplicationContext。bootstrap.yml 先加载，形成一个”引导上下文”（Bootstrap ...

前言这篇我想聊一下最近折腾博客发布流程的过程。 不是那种“我写了一个脚本，所以效率提升了”的记录，而是从一个很实际的问题开始：我发现自己写文章的时间还好，发布文章反而越来越烦。 我的博客主站是 Hexo，另外还有一个 dev-site。文章写完之后，并不是点一下发布就结束了。我要补 front matter、生成列表页封面、处理正文头图、同步到 dev-site、转换图片、检查路径、跑构建。每一步都不难，但每一步都容易漏。 一开始我想的是：那就写脚本吧。后来发现，脚本只能解决一部分问题。再后来我开始把 AI 加进来，让它不只是“帮我写正文”，而是参与整个发布流程。最后这套东西慢慢固化成几个 skill，再用一个总控 skill 串起来。 这篇文章就按这个脉络写：我遇到了什么痛点，中间尝试过哪些方案，为什么最后会变成多个 skill 协作，以及这套流程最后带来了什么收益。 痛点：发布文章比写文章还容易出错先说我原来的发布方式。 一篇文章写完后，我通常会按这个顺序处理： 手动补 front matter：title、abbrlink、description、keywords、t ...

前言因为现在的机场都不太稳定，而且还有 IP 污染这个坑，最近我在用 Claude Code 和 Codex 的时候总觉得有封号风险。折腾来折腾去，我索性在 GCP 买了一台虚拟机，准备自己搭个节点玩玩儿。 这篇记录就是我在 macOS 上配置 GCP 实例 SSH 登录时走的一遍完整流程，目标很简单：不依赖临时密钥，直接用本地固定私钥登录 Compute Engine。 为了方便后面复用，我把关键命令和排查点都整理到一篇里，照着走基本可以一次打通。 环境信息 项目 值 GCP Project ID <your-gcp-project-id> Zone us-west1-b Instance Name <your-instance-name> External IP <your-instance-external-ip> 本地公钥 ~/.ssh/dev/gcp.pub 本地私钥 ~/.ssh/dev/gcp Google 账号 <your-google-account-email> OS Lo ...

缘起：一根涨价的内存条前段时间 DDR 内存又开始涨价。不是那种温吞吞的 5%、10%，是肉眼可见的”今天不买，明天再贵 15%”的涨法。我盯着家里那台常年挂在客厅角落的 x86 服务器看了一会儿：48G 内存、二手 Intel U、跑着几个不痛不痒的小服务，功耗一天十几度电。 算了下账： 这台服务器里的内存、硬盘、平台，按现在的行情出掉正好能贴一台 Mac Studio M2 Ultra 的钱； 一台 Mac Studio 的待机功耗不到原服务器的三分之一； 更关键的是，M2 Ultra 能跑 32B / 70B 的大模型，我那台 x86 不行。 于是冲动下单了。拆机、清灰、寄出、到款、拿新机，全流程一周搞定。 拆完之后盘点了一下现状，家里现在一共有 3 台 Mac： 机器 用途 大致算力 Mac Studio M2 Ultra（新到） 主力推理 24 核 GPU，70B 级别量化模型能流畅跑 Mac mini M4 Pro 常驻开发 + 备用推理 7B–32B 小模型毫无压力 Mac mini M2 跑各种乱七八糟的小服务 3B–7B 够用 ...

一个奇怪的现象上一篇讲到版本兼容性验证。等我把 Spring Boot 3.4.7 和 Spring Cloud 的版本问题解决之后，开始仔细看原来 2.1.0 微服务架构中的 Feign 接口关系，发现了一个让我困惑的现象。 同一套架构里，Feign 接口有两种完全不同的实现方式。一部分 Feign 接口由服务提供方维护，通过独立 jar 包对外发布——比如 sctelcp-user-api-starter，里面封装了 UserApiService 这个 Feign 接口以及相关的 DTO、枚举、常量。业务方引入这个依赖就能直接注入使用。这是第一种方式，很标准的”契约优先”做法。 另一部分 Feign 接口由业务方自己写——比如 sctelcp-infrastructure-service 自己维护了一个 UserApiService，用于调用用户服务的接口。同一个 UserApiService，在不同的服务里有不同的实现，甚至类名都一样。 于是我问了自己一个问题：为什么不全部用第一种方式？ 答案是”以前出现过业务方乱调用 Feign 接口的情况，出了问题第一时间找架构组，所以就同 ...