个人网页

我之前基本一直在使用 MySQL，最近有些场景会使用 PostgreSQL，其中大部分东西照搬就能用，但总有那么几个地方，按 MySQL 的老习惯会有一些问题或者不适配。 这篇文章就是记录一下这些内容：其中的内容主要分三类——建表时定下的（事后极难改），静默丢数据与错结果（你以为对了，其实没有），静默变慢（资源被悄悄吃光）。全文按这三类分组，你可以按分类跳着看。 所有数字都是我在自己的 PG 18.6 上实测验证过的（10 核 / 7.8 GB Docker 容器，百万行级实验表），不是抄文档。绝对值会随机器配置浮动，倍数关系不受影响。 一、建表时定下的：事后极难改 表上的其他东西，选错了都能慢慢补救：索引可以后加，SQL 可以改写，连接池可以调。唯独类型和命名不行，它们是写在建表语句里的，事后想改代价很高。改列类型，PG 一般要把整张表重写一遍（放宽 varchar 长度这类纯元数据调整除外），大表上锁几个小时是常事。 更麻烦的是这些错误大多不会立刻报错。它们会安静地工作一段时间，然后在一次跨时区报表、一次金额对账上暴露出来。 # 维度 MySQL 直觉 PG 该写 为...

写了多年 Java，IDEA 一直是我的主力。但这两年实际写代码的时间，被 AI 吃掉了一大半——我更多是在读：读 AI 生成的实现、读别人提交的 PR、读一个陌生模块怎么串起来的。 这个阶段 IDEA 的很多重量级能力（重构、Inspections、Database 工具窗）反而用不上，启动慢和内存占用却是实打实的。所以我把它换成了 VS Code。 这篇是我自己的迁移速查表，只覆盖读代码这条线：跳转、搜索、看结构，而重构、生成代码、调试这些“改代码”的能力有另一套逻辑，这篇不写。 一、先装什么 扩展 ID 用途 Extension Pack for Java vscjava.vscode-java-pack 一条装齐六件套：Language Support for Java（Red Hat / JDT LS）、Debugger、Test Runner、Maven、Gradle、Java 项目管理 Spring Boot Extension Pack vmware.vscode-boot-dev-pack Spring Boot Tools / Dashbo...

它走的不是最好的路，是它看得见的那条。而它看得见什么，由你决定。 上周要写一个销售数据的导入脚本，先得把业务方给的那张真实表读顺：五家分公司，三个 sheet，合并单元格、日期、货币格式、公式一样不少，底下还有一张汇总。我要先把它们并成一张、跟汇总对一遍，再拆成三份喂给系统。这活儿在 Excel 里点一遍，我自己二十分钟能完；交给它，想着几分钟该够了。它跑了 12 分钟。 12 分钟不算离谱。让我后背发凉的是它为什么走了这条路。 我盯着它一步步往下走，越看越不对——它没有打开 Excel，它在解压文件：把 xlsx 当成压缩包解开，从里面几个 XML 文件里捞出文字和数字，再拼回一张表。十几步。 我第一反应是没装库吧。查了一下：openpyxl、pandas 都在，只是装它们的那个 python 不在 PATH 上。PATH 是系统找命令时按顺序翻的目录列表——它调的那个 python3，恰好是没装库的那个。 我不信邪，让它 pip install（python 装包的命令），撞墙了： 1error: externally-managed-environment 意思是：这个...

上一篇讲的是让 AI 替你点网页：点登录、点下单、点保存，最后把截图和接口记录交回来。文末那个例子里，它记了一笔 50.5 元的交通费，账本页上那一行清清楚楚。 可截图只证明页面画出了这一行。它证明不了库里存的是 5050 还是 50.5，证明不了这笔钱落在哪张表、状态对不对、有没有重复记两次。要确认这些，只能去查数据库。 于是会点网页之后，很自然的下一个想法是：让它也会查库。 对研发来说，这件事的用处比“查询”两个字大得多。日常这三件事都要连库，而且都离不开代码： 场景 具体在问什么 数据探查 我改的这个字段，线上到底有哪些取值？哪个占大头？有没有历史脏数据 操作后的结果验证 页面点了保存、提示成功，库里真的改了吗？改对表了吗 测试数据构造 造之前得知道有哪些唯一约束、哪些枚举、哪些字段非空 以前这三件事的办法是：切到数据库客户端，找到连接、写 SQL、把结果复制回对话里。一次两次还行，一天二十次就很难受。 这篇讲怎么把这一步接上，以及接上之后怎么不出事。核心一句话：难的不是连上，是连上之后还看得懂、改不坏。 一、给 agent 加数据库能力，路子...

先说两个画面。 一个是后台运营。 每天早上要做同一件事：把前一天的两百多条订单，逐条改成“已发货”。每条要点开、改两个下拉、填一个单号、点保存。一条二十秒，一轮下来一个多小时。做到第一百条的时候，手一抖改错行的概率明显往上升。 一个是研发测试。 每次发版前，要把三十个功能点挨个点一遍，看有没有被改坏。这件事有个正式名字，叫回归测试。点完还得截图留证，不然说不清验的是哪一版。 两件事的共同点很扎心：操作本身没有技术含量，但不能不做，而且只能靠人一条一条点。 为什么只能靠人？要么系统根本没有接口可调；要么有接口，但得写脚本——而脚本很脆，页面一改就得重写，对“只做一次”的活也不划算。 现在多了第三条路：让 AI 打开浏览器，替你点。 这里得说清一件事：这些系统不是“忘了给程序留接口”，而是做出来的时候，还没有 AI 这个用户。界面就是给人点的，压根没打算让程序去调它。等 AI 能读文档、能调接口了，存量系统也不会为了它重新改造——成本摆在那儿。有些新系统已经开始补（发 API token、接 MCP），但大多没有。 这篇讲三件事：什么场景值得这么干、怎么把它跑通（这部分可以直接照着做...

大模型变聪明的速度，比它变「懂我」的速度快得多。它可以一次读完十万行代码、把一个陌生模块讲得头头是道；但换台机器，或者隔两周再来，它对我一无所知：我喜欢什么写法、我踩过哪个坑、我强调过什么不能做——全部归零。 我们习惯把这件事叫「没有记忆」。但真去给自己的助手补记忆时会发现，难的既不是存储，也不是检索，而是回答一个问题：到底该记什么。 因为「记忆」这个词把太多不同的东西装进了同一个口袋：我的偏好像是记忆，项目里的命名约定也是记忆，上周排查某个报错的过程还是记忆。可这三样东西多久变一次、记错了会有多麻烦、什么时候该出现在对话里，完全不一样。 更麻烦的是，连「记下来的东西该怎么用」这件事，现成的答案都是彼此矛盾的：有人把记忆压到几千字符，每次开始新对话时整块塞给模型；有人一条都不塞，等模型自己想起来去查。研究界也没给出统一答案——现在最主流的几个「记忆考试」，考的其实是「能不能回答一段长对话里问过的事」，而不是「能不能用记住的东西把活干对」。 问题因此不在「存了多少」，而在「存的是什么、以及它什么时候该出现」。既然现成的答案互相矛盾，值得先把这个坐标系立起来。这篇文章有两个判断： ...

MCP（Model Context Protocol）解决的是很实际的问题：以前给 agent 加工具，得给每个工具单独写对接代码，改一次要改好几处；有了 MCP，写一次 server，所有支持的 agent 都能接上。 麻烦也出在这里：接起来容易，就容易接多。连几个 server，还没开始打字，上下文里已经堆了两万多 token——全是还没用到的工具说明书。 一、MCP 带来的三个新问题 第一，工具定义本身要占地方 我实测了两个最常见的 server：折算按 4 字符 ≈ 1 token 估算。 工具数 定义体积 折算 token filesystem 14 13.1 KB ~3,300 memory 9 11.1 KB ~2,800 合计 23 24.2 KB ~6,000 六千 token 不算大，但它是每次请求都要带上的。128k 的窗口，这两个 server 固定占掉 4.7%。pi 的作者 Mario Zechner 实测过：Playwright MCP 21 个工具 13.7k token、Chrome DevTools MCP 26...

想象一下：你面前是一个完全陌生的代码库——可能是刚入职接手的老系统，可能是内部转岗换了方向，也可能是公司合并后塞过来的项目。几十万行代码，文档要么不存在，要么三年前写的。你在终端里敲了一行 prompt，让 AI 帮你实现第一个需求。 这大概是当下最典型的开局。也是最容易出问题的开局。 问题出在哪？三件事同时撞在一起了。 第一，你对这个系统一无所知——它的代码风格、历史约定、哪里埋过坑，你都不知道。第二，AI 也不了解你的项目——它只会给你通用的写法，而不是这个项目里最安全的写法。第三，你看不出 AI 给的方案靠不靠谱——因为你脑子里没有判断的参照物。 这三个条件凑在一起，结果不是「效率低了一点」。是你越靠 AI 交付得快，你离真正懂这个系统越远。理解力债务从第一天就开始滚雪球了。 这篇文章想讲清楚一件事：在面对不熟悉的代码库时，加速理解和替代理解是两个方向。同一个工具，相反的结果。以及，你应该怎么走第一条路。 理解力债务是什么 在展开之前，先把这个贯穿全文的概念讲清楚。 你用过导航软件吧？跟着导航走，左转右转，顺利到达目的地。但如果关掉导航让你原路返回，你大概率做不到。你到...

我是后端开发。最近一年，AI 编程 agent 已经成了日常开发的主力——Claude Code、Pi、Codex，经常同时开好几个，让它们各干各的。 单个 agent 用得都挺顺手，但 agent 一多，它们之间的配合就开始让人头疼了。 任务分派断裂 一个需求经常要动好几个仓库。我在某个项目目录（或者几个仓库的共同父目录）里跟 agent 讨论了半小时，方案终于敲定了——然后呢？ 我得自己记住「order-service 要做 A、user-service 要做 B」； 手动打开新终端、cd 到对应仓库、再起一个 agent； 把刚才讨论的结论复制粘贴过去，还要祈祷上下文没丢； 然后对第二个仓库重复一遍…… 沟通的现场和执行的现场是分离的，中间靠人肉搬运上下文。每个终端里的 agent 都是孤岛，不知道其他 agent 的存在，更谈不上协作。 最近我试了一个叫 Herdr 的工具。它是一个终端工作区管理工具，和同类工具最大的区别是：它提供了一套 CLI 和本地 socket API，让 agent 之间可以互相操作——需求讨论完，主 agent 直接在自己的终端里创建 ...

这算是一个不成熟的想法，想先记录下来，接受大家的检验和讨论。 故事要从我的日常说起。 自测的一天 我是一个后端开发，技术栈主要是 Spring Boot。一个典型的需求开发流程大概是这样的： 1理解需求 → 编码 → 自测 → 联调 → 提测 每一步都还好——除了自测。 自测意味着：我需要证明这个接口在各种业务状态下行为正确。为了达到这个目标，我通常需要： 准备数据：手动往数据库里插各种状态的用户、订单、账户 部署服务：把改动部署到测试环境（或者本地跑起来） 构造请求：部署后在页面上一个场景一个场景地操作，模拟各种用户行为 验证结果：检查返回值、检查数据库落库、检查下游是否被正确调用 发现问题 → 修 → 重新部署 → 重新造数 → 重新验证 协调上下游：有些数据自己造不了，得找对应的同学帮忙——或者自己搭 Mock 服务 写自测文档：如果团队有这个要求——把测试场景、测试数据、测试结果整理成文档，附到需求上 这一套走下来，大半天甚至一天就过去了。而且这还没算上中途被拉去开个会、被各种消息打断的碎片化开销。 更糟糕的是：下次需求变了，这套流程从头再来一遍。 上次构造的测试数据...