Marico's space

最近折腾 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 幂等性不是"锦上添花"的优化项，而是必须做的基本功。 这篇文章

最近折腾了一个叫 orkestr Functions 的平台，踩了几个坑，这篇把问题说清楚。 没人调用的函数应该不花钱，一旦有人调用又能瞬间响应。这是 Serverless（无服务器计算）的设计初衷，也是大多数欧盟团队偷偷放弃的东西——为了数据驻留选 AWS Lambda，为了速度又得找个美国托管的备选方案。以前你必须二选一。但这周，orkestr Functions 换上了新的Serving引

最近折腾了 MCP 服务器，想让 AI agent 能帮创始人自动发布产品、推送更新、发 changelog。搭完之后想接入 Claude Connectors Directory，结果一头撞上了 OAuth 2.1 + PKCE + 动态客户端注册这堵墙。踩了几个坑，这篇把问题和解决方案说清楚。 思路：让 AGENT 干那些重复的活 我运营的是 BetaFinds，一个早期产品发现平台。每

核心问题从来不是"更多智能体就能更聪明"。关键在于：不能让同一个智能体同时扮演正确性的"作者"和"裁判"。这篇文章是写给想在自己技术栈上构建这套东西的人——一个可移植的参考架构，拿走就能用，不是我的机器日志。 你大概有过这种经历：让一个编程智能体从规划一路做到实现。能用——但你心里清楚风险：同一个智能体定义了什么是"正确"，又自己判断是否达到了正确。绿灯是自己给的，diff审查也是自己做。绝大多

前阵子踩了个坑，某iPaaS平台在Kubernetes上跑的集成运行时Pod频繁重启。排查了一圈，最初以为是集成逻辑的问题——消息处理正常、API响应稳定、平台看起来没什么异样。但就是有几个Pod一天能被拉起好几次。 第一反应是应用层的问题。平台要处理大量的数据转换、消息路由和连接器执行，就怕是哪个集成流创建了过多对象或者有内存泄漏。结果呢，堆内存占用率远低于配置上限，GC日志看着也很健康，Pr