单表过了千万行，查询变慢、索引胀、删旧数据删到手酸，这几件事经常一块来。第一反应往往是「要不要分表、分库分表」——其实 PostgreSQL 原生分区（L1）往往就够：应用里还是查一张 orders，库在底下拆成很多小表；查某个月，就只碰那个月的小表。

下文分两段：§1 先在同一维度上区分 L1 分区 / L2 同库分表 / L3 分库分表，环境按 PostgreSQL 14+。

1. 以为是 5 分钟升级，最后花了半天

这次升级 Gitea，我原本只想顺手把自建 runner 改成 ephemeral 模式。

预期很简单：Gitea 升到 1.26，act_runner register 加一个 --ephemeral，runner 跑完一个 job 自动退出。这样就不用再让 Fargate task 空等 30 分钟。

实际不是。

先是 runner 启不来，接着 job 卡在 queued，再接着发现 webhook 没发对事件，最后翻出两百多个 offline runner。问题单个看都不大，串起来就吃掉半天。

Agent 看起来很神秘：它能读代码、改文件、跑命令，遇到错误还能换一种方式重试。但把最小实现拆开，核心并不复杂——一个能工作的 Agent，最小内核只有三件事：模型、循环、工具。

这篇文章不停留在概念层面。读完以后，你应该能看懂任何 Agent 框架的核心循环，能判断一个 SDK 帮你封装了什么、省掉了什么、藏了什么坑。

每次打开 git log --graph，看到那些七拐八绕的线。先要回答两件事：

• Git 底层到底存了什么，
• 以及 分支的 提交和合并 真正指向哪些对象。

新人入职第一天打开 AWS 控制台。30 多个 EC2、十几个安全组、几个 RDS。没人能说清哪个资源谁开的、什么时候开的、为什么开的。也没人敢删——万一是关键服务呢？

这就是手点基础设施的代价。新人接手两眼一抹黑，变更全凭口口相传。Terraform 的承诺只有一句：

所有云资源用代码描述，所有变更走 Git。

自建 Gitea 需要 CI/CD 能力。在 EC2 上 24 小时跑 act_runner 既浪费又难维护。本文记录如何用 ECS Fargate 实现按需启动的 Serverless runner——有 job 时拉起容器，跑完即销毁，零闲置成本。

背景一句话：我们想让团队的 AI Coding Agent 直接把写好的代码部署到 AWS，不需要人工介入。于是做了一个内部工具 Runway——runway deploy 一条命令，从代码到运行。

给 Claude Code 写了很多自定义 Skill，用了几个月，直到按官方规范做了一次全面审计，才发现每一个 Skill 的 description 都踩了同一个坑。

这个坑不是语法错误，不是功能缺陷，而是一个认知陷阱：我一直在告诉 Claude “ 我是谁 “，而不是 “ 什么时候该找我 “。

非设计师如何借助 AI Agent 完成高质量 UI 设计？本文整理了目前的最佳实践，涵盖方法论、工具链、Skills 和可执行的工作流。

用 React 做了一个网页扑克游戏。菜单、弹窗、计分板都很顺，但一到牌桌——50 张牌同时做动效——帧率掉到个位数。试着优化 React 渲染，没用；试着减少 DOM 节点，还是没用。问题不在代码，在于 DOM 本来就不是为这种事情设计的。

这篇文章解释一个解法：把 UI 交给 React，把牌桌交给 PixiJS，用 Vite 把它们连起来。