Marico's space

最近折腾Webhook对接，踩了几个坑才明白：大多数安全问题都不是什么高深莫测的漏洞，就是那么几个老错误反复出现。团队验了一次签名，看到通过了，就直接上线了。这篇把上线前必须做的检查捋一遍，每条都是实际有人踩过的坑。 1. 用原始请求体验证签名 这是所有Webhook提供商最常见的bug。签名是提供商发送的原始字节计算出来的HMAC（哈希消息认证码）。如果你的框架先解析了JSON，再从解析后

AI Agent 工具调用生产模式：6 个月全天候运行总结的 8 条经验 > 让一个大语言模型（LLM，即大型语言模型）调用一次工具很容易。但要让它每天可靠地调用 500 次，连续跑 6 个月——这是完全不同的挑战。 2026 年了，OpenAI、Claude、Gemini 这些主流大语言模型都原生支持函数调用（Function Calling）。用 LangChain、CrewAI 这类

最近折腾了半年多的 AI Agent 工具调用，每天 400-600 次调用，踩了不少坑，这篇把问题说清楚。 让大语言模型（LLM，人工智能大模型）调用一次工具很容易。但让它每天稳定调用 500 次，连续跑六个月——这是完全不同的挑战。 2026 年的 LLM 都原生支持函数调用了，OpenAI、Claude、Gemini 全都支持。LangChain、CrewAI、AutoGen 这些框架

还记得那天晚上，我们的API在流量突增时开始扛不住了吗？监控大屏上看似平稳的曲线，用户端却在疯狂报502错误，钉钉群炸锅一样响个不停。我们当时的状态就像在用汤勺往外舀沉船里的水——杯水车薪。那套单体架构每个请求都直连数据库，读操作写操作连心跳检测都不放过。数据库在嘶吼，P99延迟曲线看起来就像某个变态过山车设计师的手笔。 那一刻我才意识到，需要的不只是"加个缓存"这个事后补救，而是把缓存当成核心

最近折腾 AI Agent 管道，踩了几个差点删库的坑，这篇把问题说清楚。 生产环境里的 AI Agent 能把你的数据库删个干净。不是因为模型有恶意，是因为它根本不知道自己不知道什么。它看到个解析不了的弹窗，猜了个错误操作，然后这个猜测就在生产系统上执行了。 这个问题我见过的项目够多了，知道它不是理论风险。问题不是你的 Agent 会不会犯错，而是你的架构能不能在犯错时活下来。 下面是我在

去年帮朋友做项目，试了一圈所谓的"Vibe Coding"工具——Cursor、Bolt、Replit Agent，还有国内一些类似的产品。说实话，这些东西拿来跑 demo 确实快，几个小时就能把一个"看起来能跑"的原型搭出来。创始人看到界面出来了，热血沸腾，觉得产品明天就能上线。 但问题往往在后面才暴露出来。Vibe Coding 在规模化场景下的坑是可以预见的：生成的代码没有整体架构，加个功

最近折腾了一个项目，是给在电信公司工作的老妈写的自动化工具。这篇说说踩坑过程和技术实现。 背景是这样的——我妈在尼日利亚一家电信公司做网络 field maintenance（现场运维），每个月都要做 SLA（服务水平协议）报告。以前这活儿全靠人工：要从 WhatsApp 上复制现场工程师发的故障描述，按公司标准分类，然后手动整理成 Excel 合规报表。一套流程下来，2 到 4 个小时没了。

最近折腾了一下用 PHP + MySQL 搭一个带数据库的博客网站，踩了几个坑，顺手把过程捋了一遍。这篇讲清楚怎么从零开始，用 PDO（PHP Data Objects）连接数据库，做一个完整的增删改查（CRUD）小项目。 学到的内容 * 什么是数据库驱动的网站 * 搭建 MySQL 数据库和表结构 * 用 PDO 连接 PHP 和 MySQL * 往数据库插入数据 * 查询和展示

最近折腾了一段时间开源权重大语言模型的 API 集成，踩了几个坑，这篇把问题说清楚。 AI 领域的玩法正在转变。很长一段时间里，用大语言模型（LLM）意味着把你的数据扔给一个闭源黑盒，祈祷它别出事，还得为这个"特权"付高价。但风向变了。 开源权重 LLM 的时代来了。和闭源模型不同，开源权重模型公开了模型权重、架构，甚至训练方法。对开发者来说，这是游戏规则的改变——意味着透明、可定制，以及摆脱

最近在处理支付系统 webhook 的时候，被重复投递的问题折腾了一把。说实话，之前一直没把这个当回事，觉得 webhook 发过来处理就是了。结果线上还真复现了一次——业务逻辑跑完了，但返回给支付方的响应因为网络抖动超时了，对方直接重试，导致同一个订单被处理了两遍。好在金额不大，没有造成实际损失，但这个坑让我意识到，webhook 幂等性不是"锦上添花"的优化项，而是必须做的基本功。 这篇文章