Marico's space

线上 AI 代理突然不响应了，日志里全是 503。代码没动过，配置没动过——但三个月前部署在 Cloud Run 上的那个 MCP 服务器已经不存在了。不是被废弃，是被迁移了、改名了，或者被新版本替代了，而新版本恰好不兼容。 这不是假设场景。这是我从一位日本开发者 ryoji9702 的详细博客里学到的，他记录了自己在一年内把 MCP（Model Context Protocol，模型上下文协议

最近折腾了 GitHub Actions 的缓存机制，踩了一个安全策略升级的坑，这篇把问题说清楚。 缓存是 CI（持续集成）流水线里没人会做威胁建模、直到它咬你一口才后悔的那部分。它快、方便，大家都当它是只读状态，偏偏它是流水线里少数攻击者可以在不克隆仓库的情况下写入数据的地方。（你做缓存的威胁建模了吗？） 2026年6月26日，GitHub 发布了一条更新："不可信触发的只读 Actions

大部分讲 API 测试的教程，都是测一个独立的接口。真实项目没这么干净：服务之间互相调 HTTP、共享 JWT 令牌、只有在全部跑起来才会出 bug。 这篇换个做法。我们来搭一个小型但真实的微服务系统——user-service（用户服务）、product-service（商品服务）、order-service（订单服务），然后用两套不同的测试框架写完整测试套件：Node.js 侧用 Jest

最近折腾 MySQL 8.4，在几套生产环境里踩了几个坑，这篇把问题说清楚，不整虚的。 MySQL 依然是国内最流行的数据库之一，从电商、ERP到各种后台系统，到处都在跑。但说实话，我见过太多服务器配置拉满却还是慢得像蜗牛的情况——问题往往不在硬件，在于那些没人管的配置和SQL。 MySQL 8.4 LTS 确实带来了不少改进：优化器更聪明了、统计信息管理更完善、对JSON的支持也顺手多了。但

先交代一下背景：做 TerraTier（一个 3 层 AWS 架构项目）的时候，我一直在想能不能换个方向折腾点不一样的东西。TerraTier 解决的是基础设施层的问题——网络、安全边界、密钥管理。那这个项目想解决的，是运维层的问题：Terraform 代码跑完之后，如果有人在 AWS 控制台手动改了一通，会发生什么？ 于是就有了 TerraGuard AI——一个事件驱动的漂移检测系统，核心思

最近折腾大规模 Web Scraping、动态价格监控和给大模型喂数据的管道，遇到最头疼的问题就是：代理流量费用这笔账到底怎么算。 每个主流供应商都会给你画同样的饼："99.9% 可用率保证、数百万住宅节点、超低延迟。" 但上了生产才发现，这些宣传数字根本不等于真实效果。上个月我们团队决定不猜了，自己搭了一套自动化测试沙箱，对几个企业级节点做了持续压力测试。 分析了几百万次请求之后，发现的情

你的 AI 编程 agent 写出来的东西看起来没问题。脑子里过一遍，编译通过了。然后你发现它调用了 user.getProfileById() —— 一个代码库里根本不存在的方法。 你从来没让它编造这个方法。它非常自信地在代码里塞了一个，中间部分反而写得挺正常。这就是最恶心的错误：不是明显崩溃，而是悄悄地、有偏差地不正确，你得自己抓出来。 如果你在真实项目里用过 Claude Code、Cu

最近帮人做技术尽调，遇到一个挺有意思的现象：很多公司的技术团队其实不清楚自己的系统到底"健康"到什么程度。你问他代码质量怎么样，他说"还行吧"；问他数据库设计合理吗，他说"能跑"；问他系统能扛住双十一吗，他说"应该可以吧"。 这种模糊的判断对企业决策来说是很危险的。我做技术审计这些年，逐渐摸索出一套12维度的评估框架，每个维度打分0-10，有对应的风险等级，最后汇总成一份有优先级的行动清单。这套

最近折腾了一下 RAG（检索增强生成）系统，把 Claude 和 ChatGPT 的 API 串起来用，踩了几个坑，这篇把关键点说清楚。 我们这套系统会把文档检索和两个大模型的能力结合起来：用户提问 → 从文档库拉相关资料 → 把上下文喂给 AI → 生成答案。这种玩法在客服机器人、技术文档问答这类场景很实用。 准备工作 * Node.js v18.0 或更高版本 * OpenAI A

最近折腾 Supabase Auth 的 E2E 测试，踩了一个很经典的坑：邮件验证。 Supabase 的注册流程会发送一封验证邮件，测试需要点击邮件里的链接或填写 OTP（一次性密码）。但问题是——邮件发出去了，你的测试脚本根本够不着它。 官方的建议是用 InBucket——Supabase 本地开发的邮件拦截工具。但这玩意儿依赖 Docker，得在 CI 流水线里跑一个完整的 Supab