Marico's space

最近折腾了一下 CI/CD 测试管理，把 GitHub Actions、GitLab CI 和 Jenkins 三套流水线都跑了一遍，顺手做个横向对比。这三个工具的选型文章一搜一大把，但大多是在对比功能列表，配置文件的写法却很少有人放到一起对照着看。这篇不一样——我用同一套测试用例（Jest + Supertest，8 个接口测试，100% 覆盖率），分别写三份配置文件跑一遍，然后把真实配置贴出来

最近折腾了用大语言模型（LLM）来自动生成和维护 API 测试，踩了不少坑，这篇把实操经验说清楚。 需求不是"帮我生成测试数据"这种简单活儿——我想让 AI 真正理解我的 API 接口，自动写测试用例，并且当接口变更时能同步更新测试代码。 下面是我的完整踩坑记录，代码都是实际跑通过的。 我想解决什么问题 维护的 API 主要处理用户管理、计费和 webhook 回调，大约 40 个接口。

最近折腾 Next.js App Router 的缓存机制，踩了几个坑才搞清楚这玩意儿到底是怎么工作的。部署上去之后调了 revalidatePath()，页面还是显示旧数据；或者关了某个 fetch 的缓存，结果页面居然还被缓存了；再或者从 Next.js 14 升级到 15 之后，原本好好的缓存策略全崩了。 这些问题的根源都一样：App Router 有 四层独立的缓存，每层都有自己的失效机

最近折腾 ClickHouse® 部署，在安全这块踩了几个坑。默认安装跑起来是快，但说实话，生产环境直接用就跟裸奔差不多。查了一圈资料，把安全加固的路子摸清楚了，这篇把核心要点说清楚。 为什么数据库安全不能忽视 ClickHouse® 跑着 BI 看板、监控系统、财务报表、IoT 数据分析这些业务，里头全是敏感信息——客户数据、财务记录、运营指标、商业机密。安全没做好，数据泄露、恶意访问、服

半年前，半夜两点我在线上修bug。我们的API响应时间已经飙到3.2秒，用户在群里炸锅，数据库CPU打满快要冒烟了。组里一个刚入职的小兄弟出的主意是："要不加台配置更高的服务器？" 那天晚上我悟出一个道理：给一辆轮胎没气的车换大排量发动机，能跑快才怪。真正的问题几乎永远是缓存——但不是你从StackOverflow搜到的第一种解法那种缓存。 下面是真正有效的方案，按效果排序。 1. API

打开 CI 日志，想搞清楚为什么一个 PR 跑了 9 分钟才变绿。本地测试明明只需要 40 秒。翻到上面一看，罪魁祸首：覆盖率任务。同样的测试用例，只是套了个 Xdebug，每个断言都像爬一样。 大多数团队从来不把这两个数字拆开看。看到"测试耗时 9 分钟"，就以为是测试本身慢。其实不是。慢的是覆盖率驱动。而且修复方法只是 CI 配置里改一行代码，但几乎没人做过，因为根本没想过要去测一下时间到底

很多团队的开发工作止步于"能跑就行"。Jira tickets 关闭了，功能上线了，就万事大吉。但对于真正的工程师来说，这只是起点——真正的挑战在于代码不再只是文本，而是开始与基础设施产生真实的交互那一刻。 我决定开一个 ENGINEERING 专栏，因为我坚信：性能不是上线前临时抱佛脚的"调优"，也不是在死线前慌慌张张加个缓存。性能是架构的根基。 为什么要聊这个？ * 开发经济学：一个

最近折腾了自己的作品集（Portfolio）网站，踩了几个坑，总结出一套实用的优化思路。加载速度、SEO排名、日常维护，这三个问题搞定了，网站才能真正为你服务，而不是成为需要你伺候的累赘。下面直接说干货。 1. 先选个轻量级技术栈 性能优化的最大收益，其实在你写第一行代码之前就决定了。 * 技术栈要精简。静态站点生成器（Astro、Next.js 静态导出、Hugo，甚至纯 HTML/C

最近折腾 AI Agent 的长期记忆系统，踩了几个坑，这篇把问题说清楚。 一开始大家都觉得长期记忆必须得上向量数据库，得搭 RAG 管道。但看了一圈真正扛住大流量的 Agent 产品，发现它们不约而同选了更简单的方案：纯文本文件。 这不是技术退步，反而是个更强的工程选择。文件可追溯、可对比、可迁移，还能直接 Git 版本管理。 不过光有一堆文本还不够，想让这种方案真正 work，必须把存储

最近折腾多智能体系统，踩了几个坑，这篇把问题说清楚。 从单智能体LLM（大语言模型）方案切换到多智能体系统（Multi-Agent Systems，MAS），这事大多数时候是被逼出来的，不是你主动选择的。企业需求一膨胀，做过单智能体的都知道那套"瑞士军刀"式架构有多难受——工具调疲劳、幻觉率飙升、长流程状态根本管不住。 但话说回来，上多智能体架构也不是银弹。它引入的是一整套分布式系统的新问题：