Marico's space

最近在给客户搭建本地大语言模型（LLM）推理服务时，被问到一个经典问题："模型跑在自己服务器上，数据不就不会泄露了吗？"这话听起来没毛病，但实际上，本地部署只是把风险边界从网络层挪到了提示词（Prompt）接口层。配置不当的本地 LLM 栈，可能同时面临提示词注入、工具滥用、对抗性推理攻击等威胁。 这篇聊点干货，拆解一下用 SGLang（高性能 LLM 推理引擎）和 Olares（本地 AI 编

最近在折腾自动化攻击工具，踩了个特别尴尬的坑——它会一本正经地告诉你"成功了"，其实毛都没有。 拿个工具扫目标，最 naive 的成功判断就是字符串匹配——看到 uid=0(root) 就当拿下 shell。但 banner 可以直接打印这行字，tarpit 可以在连接时自动推送出来。一旦成功信号本身就是假的，后面全完蛋：报告、"哪些主机沦陷了"的状态、下一步行动，全都被这个错误信号带偏。就是个

先说几句 这是一个系列，记录的是正在进行的工作的阶段性成果，不是已经完结的故事。不是什么学术论文，就是实实在在的工程经验总结，过程中踩过的坑、积累的心得，我都写下来。 为什么项目还没结束就急着写？因为细节容易消散——那些技术决策、那些中间观察、当时做决定的上下文，都会随时间模糊。趁还在做就写下来，也是我保存这些上下文的方式。这些上下文很重要，提醒我过去每个决策——不管是我的还是别人的——在当时

最近折腾 React 性能优化，踩了几个坑，这篇把问题说清楚。 React 性能优化这个话题，坊间流传着太多迷思。开发者动不动就给所有组件套 React.memo，给所有函数包 useCallback，结果应用还是卡顿、内存还是爆炸。 过早优化反而会让性能变差、代码变乱。要构建真正快的 React 应用，得针对实际的性能瓶颈来下手：无谓的重渲染、状态位置不当、包体积过大、主线程阻塞。下面分享

大多数聊天机器人都存在一个很典型的问题：用户问一些稍微超出训练数据范围的内容，它们要么一本正经地胡说八道，要么给你一个毫无用处的"我不知道"。问题不在语言模型本身，而是系统架构。RAG（检索增强生成）通过让聊天机器人基于真实、最新的知识来回答问题，而不是完全依赖模型在训练时"记住"的内容，从根本上解决了这个问题。 这篇文章里，我们用 RAG、向量数据库和 Laravel 后端来搭建一个真正的智能

最近折腾了 AWS Lambda，配合 Python 写无服务器应用，踩了几个坑，这篇把问题说清楚。 做后端开发久了，总觉得运维是个甩不掉的包袱——服务器要维护、弹性伸缩要配置、流量高峰还得提前扩容。2018 年接触 Lambda 之后，这事儿就简单多了。代码写完往云上一扔，有人访问才计费，没人访问就是零成本。对于个人项目或者初创产品的 MVP 阶段，这个思路很实用。 Python 又是 La

最近折腾了 Glue Data Catalog 和 S3 Tables 的 Iceberg REST API（应用程序接口），把两边的权限模型对照着看了一遍，踩了几个坑，这篇把发现整理出来。 之前写过两篇文章，直接访问 Iceberg REST Catalog，对比了 Glue 端点和 S3 Tables 端点的设计差异： * Hitting the Iceberg REST Catalog

Magento 2的数据库就是整个系统的命根子。每次加载商品、浏览分类、修改购物车、下单付款，走的都是MySQL。当你的商品数量超过5万个SKU、流量开始爬坡的时候，那些没优化的SQL查询就成了隐性杀手——页面加载慢、结账超时、客户直接关页面走人。 大多数Magento开发者知道Redis缓存和Varnish，但很少有人深挖数据库这一层。实际上真正的性能提升往往就藏在这儿。这篇说说Magento

Lightsail 挺适合托管单个小型容器的：定价简单、带宽包含在内、不用折腾 VPC 和安全组那些破事。唯一的坑是，从亚马逊 ECR（弹性容器注册表）拉取私有镜像这件事上，标准 Lightsail 实例不像 EC2 那样能直接认证。这篇把完整流程捋一遍。 整体链路是这样的： docker build ──push──> ECR (私有仓库) ──pull──> Lightsail 实例 ──

最近在生产环境里跑 Claude Code，发现这玩意儿的成本控制比我想象中复杂得多。大部分费用超支都来自看不见的上下文堆积和缓存失效，而计费面板压根不显示这些。等发现账单的时候，往往已经多烧了好几万 tokens。 这篇文章说说怎么在请求级别硬性限制 token 预算，怎么让 prompt 缓存真正省到钱，以及生产环境中那些计费面板不会告诉你的隐藏成本。实测下来，做好这几点，账单能降一大截。