Marico's space

最近折腾了一下给 AI Agent 跑财务流水的问题，踩了几个坑，这篇把 OpenLedger 这个项目说清楚。 Attri 把 OpenLedger 开源了——一个本地优先的复式记账系统，上面套了一层 MCP（模型上下文协议）服务器。Python 3.11+、SQLite、aiosqlite。通过 MCP 暴露 15 个工具。事务不可变。纠错靠红字冲销。所有的变更操作都把审计日志行和变更本身写

最近给项目上了LLM（大型语言模型）可观测性，仪表盘全绿，延迟正常，token消耗在预算内。结果用户反馈AI客服的回答过时了——产品功能早就改了，AI还在一本正经地引用旧文档。 模型调用成功了，每个指标都漂亮。但答案错了整整六个月。 这就是以模型为中心的可观测性的盲点：它只能告诉你最终传给模型的上下文是什么，无法告诉你系统搜索的是不是对的关键词、有没有漏掉新文档、为什么选了这个结果而不是那个。

最近折腾 PostgreSQL 的 COUNT(*) 性能问题，踩了几个坑，这篇把问题说清楚。 COUNT(*) 看起来是个再简单不过的操作： SELECT COUNT(*) FROM orders; 查询只要返回一个数字，但 PostgreSQL 可没法从某个内部计数器里 O(1) 地读出来。 要得到精确数量，PostgreSQL 必须确定哪些行对该查询可见。在大表上，这部分工作量会成

大多数医美机构流失客户，问题往往不在于技术，而在于从客户发起咨询到最终确认预约这中间发生了什么——或者干脆什么都没发生。带自动化功能的医美CRM能补上这个缺口：它能抓取每一条咨询、秒级响应发送预约链接，然后持续跟进，直到客户完成预约、明确拒绝或者主动退订。 这篇文章只聚焦一个问题：如何把咨询转化为预约。自动化负责沟通，但它替代不了临床护理、医疗判断或者病历记录。 为什么医美机构在首次咨询后会

最近在给一套客服系统做认证层改造，踩了几个坑才把JWKS（JSON Web Key Set）缓存和实时会话自省这两个机制的边界搞清楚。这篇把结论说清楚，不绕弯子。 简短回答：JWT签名在本地用缓存的JWKS验证，但刷新令牌轮换、被盗会话撤销、账户连续性决策这些场景——光有有效签名是不够的授权信号——必须在API网关做实时会话自省。两个边界要划清楚：本地验证保可用性和延迟，可控的实时检查则限制攻击

最近在搞数据库迁移项目，甲方要把Oracle数据库里的代码往其他数据库上迁。Oracle有个PIVOT函数用得还挺爽的，但目标数据库不支持这语法，遇到一堆代码要改，手工一个个翻不仅累还容易出错。踩了几次坑之后，试了试ZGLanguage这个开源工具，发现批量处理还挺香的，这篇把实战经验分享出来。 先说背景：跨数据库迁移时，SQL语法不兼容是常事。碰到大量代码需要重写的情况，手工处理费时费力还容易

安全不只是技术活，更是一道资源分配的数学题。 一个AI平台，架构设计图画得再漂亮，如果缺了下面这些东西，照样千疮百孔： * 足够的安全工程师 * 靠谱的监控 * 漏洞处理能力 * 事件响应团队 * 安全测试 * 云安全控制 * AI安全评估 * 备份基础设施 * 合规支持 * 培训 * 长期维护资源 所以安全这件事，必须认真做预算和规划。 目标不是： > 在安全上花

大多数网站和SaaS产品都在被一个隐形的转化杀手慢慢耗死：移动端性能烂得一塌糊涂。 在顶配Mac上用光纤宽带跑Lighthouse，拿个95分简直轻松加愉快。但一旦切换到移动端——也就是Google模拟的那台低端安卓机，限速4G网络，往返延迟150ms——分数直接崩到四五十。 给Klickspell做性能审计的时候，我们遇到了熟悉的困境：桌面端99分，移动端却只有四五十分，绘制慢、渲染阻塞、布

在2026年的Web开发领域，架构选型早已不是什么新鲜话题，但真正能在实际项目中做出正确选择的团队仍然寥寥无几。我见过太多创业公司在初期选了微服务结果被运维成本拖垮，也见过传统企业为了赶潮流强拆单体，最后系统复杂度翻了几倍却没换来任何实质收益。这篇文章不聊虚的，直接从业务和技术两个维度把模块化单体和微服务的取舍讲清楚。 核心问题与业务/技术影响 架构决策的核心矛盾其实很直接：既要快速交付功能

前几章把数据库、认证鉴权、API 基础设施讲清楚了，这章聊聊文件存储这个子系统。 AI（人工智能）平台要处理的用户数据种类不少： 图片 视频 音频 文档 PDF 文件 文本文件 生成式媒体 处理后的输出 临时处理产物 这类二进制数据直接塞进 PostgreSQL 是不行的。 正确的做法是分离： 元数据 ↓ PostgreSQL 大文件二进制数据 ↓ 对象存储 最终架构是这样：