Marico's space

最近折腾了一个叫 entropyx 的代码库分析工具，踩了几个坑才想清楚一件事：AI 时代给开发者工具写提示词是没用的，工具本身得是一份可执行的合同。 这篇文章把这个问题说清楚，顺便聊聊 entropyx 怎么实现这个思路的。 可执行文件就是接口：代理能发现、验证、信任的那种 AI 代理能读 README、扫描测试、检查源码树，然后推断出一个看起来合理的架构。但它还是可能把你的工具搞坏——

前阵子接手了一个项目，上线后发现接口响应时间动不动就超过 500ms，用户反馈卡顿严重。排查了一圈代码，发现问题很简单——之前写 API 的时候压根没按规范来，该用的注解没用，该做的异常处理没做。 踩了这个坑之后，花时间系统梳理了一下 Spring Boot REST API 的最佳实践，写出来分享给各位。下面的内容全部是实战经验，不整虚的。 * REST API 设计原则 * HTTP

最近在搞一个 Gmail 邮件分析 Actor，第一个真正需要做的决策不是报告格式，而是授权模型。在多租户场景下，OAuth 不再只是一个安全问题，它直接决定了产品的使用门槛。 最终我选了纯 refresh-token（刷新令牌）模式，而不是每次调用都跑完整的 3-legged flow（三-legged OAuth 授权码模式）。这里面的 reasoning（考量）挺实际，没什么花哨的。

最近折腾了一个清理僵尸云资源的小工具，踩了几个坑，这篇把过程说清楚。 每个云账号里都有僵尸资源。 不是那种好玩的僵尸，是那种悄无声息烧你预算的类型。半年前挂载的实例早就删了，EBS卷还挂在那儿没人管。某个VPC里NAT网关还在跑，但里面的业务早就迁移完了。Transfer Family的SFTP服务器当初为了数据迁移搭的，用了一次就再也没人碰过。 审计过不少账号，这种情况不是个例，是常态。基

最近折腾了一个自托管的多 Agent 系统，踩了不少坑，这篇把核心架构决策和经验教训说清楚。 事情是这样的：我想让五个独立的 AI Agent 运行在同一台工作站上。不是五个线程，是五个真正的 Agent——每个有自己的身份、记忆范围、工具权限和职责。它们各自跑在容器里，通过共享数据库通信，各自执行"分诊 → 执行 → 复盘"的推理循环。 全程用 Rust 实现，不碰 Python，不依赖云端

说实话，微服务（Microservices）这个词在技术圈里被炒了这么多年，但真正能把「它解决什么问题」讲清楚的文章还真不多。要么讲得太理论，要么就是云里雾里的比喻讲一大堆。今天咱们就来好好聊聊，微服务到底解决了单体架构（Monolith）的哪些痛点。 先从一个特别接地气的例子说起吧。想象你开了一家奶茶店，一开始你一个人负责点单、做奶茶、收款，什么都是你说了算。客人少的时候，运转得还挺顺溜。但到

DETECTING FABRICATED TWEET IDS FROM LLM AGENTS: A SNOWFLAKE-DECODE FIELD GUIDE We run a small multi-agent system on Base mainnet. One of those agents was supposed to scout X (Twitter) for fresh bug-b

大多数「开发者效率」工具榜单都是按 GitHub 星数排名的。但这根本不是节省时间的真正方法。 独立开发者真正的时间杀手，往往不是慢半拍的自动补全或缺失的快捷键。那些隐藏在暗处的「税」：产品还没写一行代码，后端配置已经花了三小时；密钥泄露排查掉半天；还有一个「临时」胶水代码在生产环境跑了两年。 选对技术栈不是为了让你现有工作更快——而是在你动手之前就把整个问题类别消灭掉。 本文的筛选标准只有

先说个冷笑话：Go 可能是语法最简洁的主流后端语言，但新建一个项目一点都不简洁——你要手动创建目录、初始化 go mod init、写 main.go、配路由、接处理器、加 Makefile、配 .gitignore……等你写完第一行业务代码，半小时已经过去了。 隔壁 JavaScript 有 create-react-app，Java 有 Spring Initializr，Go 呢？复制粘贴

原文：How to survive as a developer without AI code-gen and without autocomplete｜译者前言：本文来自 dev.to，观点有价值，转写发布供读者参考。 嘿，大家好！我叫 Viktor，是一家电商公司的资深后端开发，负责物流团队。 今天我来聊聊我是如何在 surrounded by vibe-coders、code-writ