我的 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 接口的情况，出了问题第一时间找架构组，所以就同 ...

关掉检查就行了吗前八篇文章写了研发底座的架构全景、工程规范、Response 设计、缓存重构、配置管理、代码质量、MyBatis 组件化、网关性能调优。这些内容基本上是在同一个架构底座上逐步优化出来的。但现在我们要聊一个更底层的变动——从单体架构再切回微服务架构。 先交代一下背景。这不是一个从零开始的设计。研发底座最早是微服务架构（v2.1.0），后来因为某些项目场景需要，把它改造成了一个单体架构（代号 cirrus-1.0.0）——主要就是把原来的 Feign 远程调用改成了 JVM 内部调用，用一个聚合组件收敛依赖。然后到了 9 月，业务上又有微服务的需求了，于是我们从单体架构出发，再做一次微服务化改造，版本定为 v3.1.0。 问题是，这中间的 Spring Boot 版本变了。 单体架构改造时，根据业务方需求选择了 Spring Boot 3.4.7。这个版本号本身没问题——它是当时可用的最新稳定版。但当我们想在这个版本上加入 Spring Cloud 依赖时，启动直接炸了： 123456789101112131415***************************AP ...

从一个错误日志说起某天下午，前端同事反馈”页面加载很慢，偶尔直接白屏”。切到服务器上看 Nginx 日志，刷屏的是： 123452025/09/15 17:57:48 [crit] 24950#24950: *4354733 connect() to 127.0.0.1:9090 failed (99: Cannot assign requested address) while connecting to upstream, client: 192.168.0.184, server: _, request: "GET /api/user/api/resource/list/tree HTTP/1.1", upstream: "http://127.0.0.1:9090/user/api/resource/list/tree", host: "192.168.0.10:3000" Cannot assign requested address。这个错误的意思是——没有可用的本地端口了。 当时的 Nginx 配置是这样的： ...