Marico's space

第66天的 DevOps，第16天的 Azure（微软云）。今天的两个任务都指向同一个问题：名字必须完全正确。我把 PersistentVolumeClaim（持久卷声明）建错了名字，结果 Pod 永远调不上来——没有容器，也就没有日志可看。Azure 存储账户的名字要求全局唯一，因为它会被当作主机名来用。 一个 Kubernetes 任务，一个 Azure 任务。在持久卷上跑 MySQL，把凭

大多数 SQL 教程讲到 SELECT、WHERE 和 GROUP BY 就停了。真正做数据分析需要更多：给患者排名、比较相邻就诊记录、关联多个表、把复杂问题拆成几步来解。这篇文章聊聊四个让这些成为可能的工具： 1. 窗口函数：跨相关行做计算，但不折叠这些行。 2. JOIN：关联表。 3. 公用表表达式（CTE）：给中间结果起名字。 4. 子查询：嵌套在其他查询里的查询。 每个例子都

最近折腾 Archon 这个开源工作流引擎（就是驱动 Claude Code、Codex、Pi 这些 AI 编程工具的后端），结果发现一个挺离谱的漏洞：CVE-2026-111322。简单说就是它的控制 API 默认没有任何认证，而且监听在所有网络接口上。这篇把问题说清楚，顺便给出一套临时加固方案，不需要改代码，10 分钟搞定。 2026 年 10 月 15 日，VulnCheck 公布了这个漏

最近折腾 AI 应用构建工具，发现大多数评测基准都停留在"这道算法题能不能做出来"这个层面。说实话，这跟真实场景差距挺大的。 真实用户的需求往往是混乱的：截图、视频、PDF、半个写好的项目、互相矛盾的后续需求、或者用户已经拍板的设计方案全混在一起。AI 代理得自己判断是应该先讨论、规划、原型还是直接开干，然后还要保持之前决策的一致性、产出能跑的结果、做测试、用户改方向时还得能兜住。 Eazo

最近在处理 webhook 幂等性的问题，踩了一个很有意思的坑——24小时的 TTL（生存时间）看起来很安全，实际上会把程序崩溃变成永久丢失的事件。这篇把问题说清楚，也记录一下我们最终的选择。 Munchable 有两个 webhook 端点：一个是处理 Stripe 支付回调的，一个是处理入站邮件的。两个都是"至少一次"投递，都有可能产生不能重复执行的副作用，处理流程开头都一样： const

最近系统学习了应用AI工程，踩了不少坑，这篇把核心问题说清楚。 之前以为Prompt就是往ChatGPT里敲个问题，测一次就完事。实际做项目才发现，这套在生产环境撑不过三天。下面是从第一章整理的笔记和图表，关于怎么让LLM（大语言模型）输出稳定可靠，最后还有一个我设计的实时核查系统。 TLDR：稳定Prompt的5条黄金法则 Temperature = 0 确实能让答案一致，但如果模型不知道

最近在搞分布式系统的上线验证，踩了不少坑。这事说大不大说小不小——测试环境跑得好好的，一上生产就崩，数据库慢查询、内存泄漏、Schema不兼容，一个比一个恶心。传统那套 mock + staging + canary 的打法，越来越觉得是在自欺欺人。 所以花时间研究了 TrafficMirror 这个流量镜像方案，确实有点东西，这篇把核心原理说清楚。 1. 现代 QA 体系的结构性困境 先

最近读了篇论文，发现一个挺反直觉的问题：Agent基准测试里的"用户"其实是个模型，而这个模型的失误能让成功率虚高到让你误判。这个坑值得单独写一篇。 在某个基准测试中，有个人口角色代理（User Proxy）开场第一句话就是"对了，我叫John Smith，电话是555-123-2002。"这个任务的本意是测试Agent在处理账户信息前是否会主动要求验证身份，但代理直接就把信息交出去了，完全没等

搞微服务测试这几年，被 Mock 这个问题坑过太多次了。传统方案要么硬编码 JSON 响应，要么维护一套脆弱的 WireMock 配置，费时费力还容易出幺蛾子。最近折腾了 MockForge，一个 Rust 写的有状态 API 虚拟化引擎，体验下来确实有点东西，这篇把它的设计思路和实战用法说清楚。 分布式测试的瓶颈在哪 工程团队普遍面临"测试环境悖论"：越是复杂的分布式系统，测试成本越高。问

最近折腾了个个人项目，踩了几个网络延迟的坑，这篇把问题说清楚。 我的 ASP.NET Core 9 应用部署在一台机器上，SQL Server 放在另一台共享托管的服务器上——完全不在同一个机房。每次查询都要跨过我控制不了的网络。 首页的冷启动读取耗时 200 到 1000 毫秒，问题不在 SQL 查询计划慢，而在物理距离。 现在热读取响应时间稳定在 2 到 3 毫秒。没有用 C++ 重写任