Marico's space

最近在搞航空毫米波雷达的信号处理架构，踩了不少坑，这篇把核心问题梳理清楚。 毫米波雷达装在飞机或无人机上，本质上是一个主动传感系统，用高频无线电信号探测、测量和跟踪目标。 但对开发者来说，最重要的是：这玩意儿不是一台只要输出目标坐标就完事的射频设备。 它是一个实时处理系统。 一个实用的架构大概是这样串起来的： 射频感知 → 数字化 → 信号处理 → 测量生成 → 导航对准 → 坐标变换

线上跑 PostgreSQL 时间长了，这个问题迟早会碰到： * 查询开始卡住不动 * 连接数蹭蹭往上涨 * 数据库响应越来越慢 * 连接数快要触及 max_connections 上限了 一个常见的原因就是某个会话把其他会话给堵住了。 典型场景就是连接处于 idle in transaction 状态——应用开了事务但既没 COMMIT 也没 ROLLBACK。 这篇文章聊聊怎么

最近折腾了一个定时运行的短视频脚本生成流水线，踩了几个坑，这篇把问题说清楚。 市面上的"自动化无脸YouTube频道"教程套路都差不多：拉一个RSS订阅源，用for循环遍历条目，把每个条目POST给大模型，塞一句"写一个40秒的TikTok脚本"，把返回结果写到文件。四十行代码，演示没问题。 然后你设好定时任务，那些没人写过的问题就开始冒出来了： * 模型大约六分之一的概率返回一段没有分段

最近折腾微服务本地开发环境，踩了几个坑才把流程理顺。这篇把问题说清楚：怎么用 Docker Compose 配服务拓扑，用 Taskfile 套一层命令壳，让团队成员能一键启动、跑检查、看日志、干净重置。不会把底层工具藏起来，也不会搞一堆脆弱的 Shell 脚本。 具体场景是一个 API 服务、一个 Worker 进程、加 PostgreSQL（数据库）和 Redis（缓存）。涉及到 Docke

最近在给公司重构GraphQL架构，踩了几个坑，这篇把问题说清楚。 团队刚上GraphQL的时候，那感觉是真的爽。前端想要什么字段自己拼，一次网络请求搞定，类型还自动补全。但业务一扩张，问题就来了——GraphQL服务器变成了一个巨无霸单体。 假设你维护着一个服务几千万用户的国内电商平台，单用一个Node.js或PHP服务处理整个数据图，那这个代码库得同时理解用户、商品、评价、库存、支付……所

最近在折腾 AI Agent（人工智能代理）的评估体系，踩了不少坑，趁着记忆清晰把 Amazon Bedrock 的 AgentCore Evaluations 好好研究了一番。这玩意儿解决了一个很实际的问题：团队里有人用 LangGraph，有人用 LlamaIndex，还有人在试 OpenAI 的 Agents SDK，每个框架自带一套评估逻辑，互相之间根本没法对比。AWS 的解法很有意思——

折腾 AI Agent 有一段时间了，调 system prompt、试 chain-of-thought、跑 ReAct、把 GPT-4o 和 Claude 3.5 Sonnet 比了个遍，结果呢？Agent 还是在第三轮对话就失忆、还是前后矛盾、用户第二天回来感觉像在跟一个新人聊天。 说句可能被喷的实话：你的 Agent 根本不是推理有问题，是记忆有问题。 现在的大模型在给定的上下文窗口内

最近折腾贷款技术栈的架构选型，踩了几个坑，这篇把问题说清楚。 你的工程团队用四到六周就能搭一个 API（应用程序接口）聚合层。它从征信机构、KYC（了解你的客户）供应商、文档服务、合作贷款方拉取数据，标准化响应格式，然后返回给前端一个统一的对象。跑得起来。 但放到贷款发起流程里，这就埋雷了。 贷款 API 编排和 API 聚合的区别，不是学术架构讨论。这是选择哪种模式真正匹配贷款业务流程结构

随着企业纷纷把GPT-4这类大语言模型（LLM，大语言模型）集成到自家平台，他们很快会遇到一个致命问题：LLM会一本正经地胡说八道。这种现象叫"幻觉"（hallucination），本质原因是LLM本质上只是个概率预测引擎。如果你问一个现成的LLM关于昨天刚写的某条绝密公司政策，它不知道答案——但它不会说"我不知道"，而是会自信满满地编出一段语法完美、逻辑通顺、但完全虚构的内容。 在企业软件领域

最近在搞AI评估平台，踩了不少坑，终于把事件驱动这套东西跑通了。这篇把GCP上Pub/Sub、Cloud Tasks和Cloud Scheduler的实际用法说清楚，不整虚的。 为什么需要事件驱动 AI评估平台有个问题，用REST API根本没法优雅地解决：一个评估任务跑5到30分钟，涉及6个不同服务，中间随时可能挂。 用同步HTTP：超时、重试撞上已经完成的任务、调试噩梦。换成事件驱动：