Marico's space

最近折腾 Next.js 的 Edge Middleware，踩了几个坑，这篇把问题说清楚。 做了这么多年 Web 开发，一直被一个老问题困扰：安全检查到底放在哪里做最合理？传统方案是请求先到中心服务器，验完身份再放行。但如果用户在广州访问托管在北京的服务器，光物理距离就要付出几十毫秒的代价。更憋屈的是，如果用户压根没登录，或者 Token 已经过期，这几十毫秒完全是白跑——服务器浪费算力处理了

测试内容

终于写到第 4 部分了，这个系列也该收尾了。简单回顾一下我们之前折腾的东西： 1. 搭了一个并行跑 Frontend（Angular）和 Backend（.NET）的流水线 2. 把 CI/CD 从收费云服务迁移到了自建的 Self-Hosted Runner（省钱才是硬道理） 3. 实现了 Tag 和 Changelog 的自动生成 到这一步，你的流程已经比很多中小厂要专业了。但如果你

最近折腾了一圈AI编程助手，发现一个挺有意思的矛盾：这些模型训练时看过互联网上几乎所有的公开代码，但偏偏对自己正在写的项目一无所知。行业里过去几年一直在靠"提示词猜测"——把附近几行代码塞进上下文窗口，赌LLM能自己猜出语义关系。这种做法脆得很，一旦涉及跨文件引用、隐式类型推导或者分散在多个模块里的逻辑，AI就开始瞎编。 解决方案不是更大的模型，而是更好的协议。LSP（语言服务器协议）就是静态分

最近折腾AI编程助手，踩了几个坑才明白一件事：当前这波AI代码工具，其实有个挺根本的矛盾——训练数据里塞满了全球的公开代码，结果对咱们自己项目里的代码结构反而一脸懵。 行业里通用做法是"靠提示词蒙"（Prompt Guessing）——把光标附近的代码片段塞给大模型，希望语义关联是"意会"的。这招太脆了。符号被import了不知道，类型推断不出来，跨文件的逻辑更是瞎子摸象。 解法不是上更大的模

Web 开发看起来像是独立于游戏开发的一个领域，但实际上现代 Unity 项目很少只存在于可执行文件里。账号体系、云存档、事件系统、客服工具、内容配置、内部仪表盘——这些都需要一个 Web 层。在游戏行业摸爬滚打 16 年，从 2016 年在 Ubisoft Montreal 做《Eagle Flight Arcade》的 Gameplay Programmer，到后来做《Meta Spirit

手动部署有个很明显的规律：平时一切正常，直到某个周五有人赶着下班改了个东西，测试没跑直接推了上去，结果 bug 在周末凌晨炸了生产环境。这不是纪律问题，是流程问题——压力最大的时候，恰恰是手动流程最容易挂的时候。 GitHub Actions 解决这个问题的思路是把流水线直接放在仓库里。没有独立的 CI（持续集成）服务器要维护，没有乱七八糟的外部集成要配置。工作流文件就躺在 .github/wo

最近折腾了一套新的开发者工具链，踩了几个坑，这篇把问题说清楚。 现代开发者工具领域正在经历一场安静但深刻的哲学转变。过去二十年，主流范式是高度抽象的：高级语言、托管运行时、动态脚本环境，这些东西优先考虑的是开发者速度，而非系统的可预测性。现在，一股反运动正在兴起，驱动力来自三个不同但正在汇聚的力量：Rust 这类系统级语言的内存安全保障、复古计算（尤其是 6502 架构）带来的严谨思维模型，以及

最近折腾微服务消息队列，在 Laravel 项目里集成 NATS（一个轻量级消息系统），踩了几个坑，终于把这块打通。这篇把问题和解决方案说清楚，顺便介绍下我做的 Laravel NATS 包。 做分布式系统，最大的挑战之一就是让服务之间可靠通信，又不搞出强耦合。Laravel 本身对队列、事件、广播、任务的处理已经相当完善，但涉及到 NATS 这个消息中间件，生态就比较匮乏了。 这就是我写 L

人人都能搭一个 AI Agent。 但能让它在生产环境里稳定跑起来的，凤毛麟角。 这是我在 2026 年最大的感悟。 折腾了几个月，把 AI Agent 部署上线、监控、优化，给真实用户用上之后，我发现一个让人意外的事实： 最难的问题跟 LLM（大语言模型）几乎没关系。 模型只是庞大分布式系统里的一个组件。 生产级 AI 工程不再是拼提示词，而是拼软件架构。 DEMO 做完，生产才