我本周发布了六篇文章。一篇关于 PostgreSQL，另一篇关于人工智能代理的，一篇关于上下文管理的教程，一篇自动化的教程，一篇调试案例分析，最后一篇是关于为评估 MVP（最小可行性产品）设计对抗性建议的。

这些并非有计划发布，而是每一篇都从一篇论文、一场演讲，或是一个某种程度上让我感到有趣的项目衍生出来的。可当我将它们汇聚到一起时，却发现了一个自己在写的时候没有注意到的“共同主线”。

这六篇文章说的是一回事。

不经意间发现的模式

最开始是在看 Bohan Zhang 关于 OpenAI 如何扩展 PostgreSQL 的文章得出的结论。这篇文的结尾非常震撼——8 亿用户，只用一个 primary，没有分片。PgBouncer（发布于 2007 年）。只读副本（90 年代的概念）。这世上最无趣的技术，却支撑了历史上应用最广泛的一个服务，至今依旧“仍在很好地运行”。

接着是 Michael Bolin 解析 coding agents（代码代理）构造的文章。不管是 Codex CLI，还是 Claude Code，剖开内部，你会发现它们其实是一个 带 LLM 的 while 循环。没有知识图谱，没有符号规划。有的只是一个循环、一些工具，还有模型决定该停止的时间点。它的“魔法”其实就是一个 while True。

之后是 OpenAI 的关于 上下文工程（Context Engineering） 的 Cookbook 文章。事实是，模型看到的内容比模型本身更重要。而这些技术并不新鲜：启动时注入上下文（相当于一个 README 文档），剪切历史记录（类似循环缓冲区），压缩旧的内容（通过总结）。这些方法早在 2000 年代的聊天系统中就已出现。

然后是那个 自动化教程，更是对此的有力印证：OpenAI 的 Codex Automations 是 cron + curl + 一个 LLM。完全字面意义上就是这样。Unix 系统中最老套的调度器接口，调用当今世界上最前沿的模型。这基础设施已经存在了 40 年，而这“脑袋”才开发了两年。

接着还有两个非基础设施主题的帖子。那个 Jane Street 的谜题 中，一个神经网络有 2500 层，但结果证明它只是一个 MD5。这解法靠的是传统的调试思维：观察数据形式、逐步缩小范围、叠加约束条件，直到剩下唯一可能的答案。工具可能是新的（SAT 解算器，ChatGPT），方法却是老的（有条不紊地假设排除法）。

最后一篇是关于 用对抗性建议评估 MVP 的文章：用 LLM 模拟 5 个专家去评估创意的可行性，这听起来很高科技，直到你发现它其实就是一种 战争推演方法。从 50 年代开始军队就在用了，产品团队也称之为 预死因分析（pre-mortems）。创新之处无非在于，现在只用 2 美元在云端即可串联这些分析，而用不到雇佣 5 万美元的顾问了。

这背后的观点（不是我的）

我并没有说什么新鲜观点。从 2015 年 Dan McKinley 在演讲《Choose Boring Technology》中开始，就不乏类似的说法。每当有人提议用 Kubernetes 搭建一个 CRUD，DHH 都会重申这一点。而 Fred Brooks 在 1975 年也提出了“没有银弹”这一概念。

但本周我却发现，这六个独立的案例同时在不同的领域证明了同样的道理：

领域有效的“乏味”技术看似更棒的“新技术”
数据库PostgreSQL + PgBouncer具备分片功能的分布式数据库
人工智能代理while 循环 + 工具带有调度器的多代理架构
上下文管理YAML + README + 循环缓冲区带向量存储的检索增强生成（RAG）+ 嵌入流水线
自动化cron + bash + curl云原生编排平台
调试观察 → 缩减问题 → 假设 → 验证端到端的可解释性工具集
点子评估带预定义框架的结构化小组讨论使用市场数据的研究平台

左侧的内容是那些负责解决大规模问题的团队实际在使用的技术，而右侧的是那些在技术会议上被宣传的新方法或工具。

这一切的原因

这并不是说新技术一无是处，而是说新技术往往解决的是大多数团队并没有的问题。

OpenAI 并未使用分片，因为他们的访问模式中 95% 是读取操作。一个主节点（primary）能够处理所有的 writes，因为他们做了细致的分析，把会造成性能消耗的任务移到了其他地方。这技术并不“性感”，更像种外科手术般的精准切割。

编写代码的 AI 代理不需要复杂的架构，因为模型本身足够智能，能够在简单循环中决定使用哪种工具、何时终止。调度器的复杂程度往往与模型智能性呈反比。

cron 不需要替换，因为 99% 的自动化任务都是“每 N 小时执行一次”。如果你的任务需要更复杂的处理——事件溯源、故障补偿、带退避的重试——是的，你可能需要更复杂的方案。但大部分情况下并不需要。而不需要的复杂度，就是多余的负担。

工匠的陷阱

有一种叫 复杂性偏见（complexity bias） 的认知偏误，解释了我们为何总是在寻找“魔法工具”。我们天生倾向于选择复杂的解决方案，因为它们“看上去”更能解决问题。

如果你的数据库性能变慢了，“把写操作移到其他地方”听起来像是临时修补。而“用一致性哈希和自动平衡算法实施分片”则听起来很有“工程思维”。作为工程师，我们本能地更偏爱那些看似需要更多技术含量的解决方案。

但真正有用的“修补”远胜于从未经受检验的“完美工程”。

OpenAI 本可以花 6 个月时间实现分片。但他们选择了将一部分任务转移到 Cosmos DB，他们用节省出来的时间，为 8 亿用户开发了新功能。

用通俗的话说：选择优雅方案的机会成本，是你在此期间无法完成的真实解决方案。

这对你的启示

并不是说你不应该学习新的技术，而是说在落地之前，你应该先问自己：

“这个问题是现有的、成熟的技术无法解决的吗？”

如果答案是“没有，但新的技术更现代”，那么你其实是在缺乏收益的前提下增加了复杂性。而这种复杂性最终往往要你“买单”——不管是在错误上、开发周期上，还是夜晚加班的时间上。

但如果答案是“因为我需要 X，而 PostgreSQL 无法实现”，很好，那就尝试新的技术吧。但是要具体明确地指出，X 到底是什么。

“我能不能用现有解决方案，加上一点点基础的纪律来解决问题？”

OpenAI 使用 PgBouncer 解决了连接问题。他们没有换数据库，也没有重写数据访问层，他们只是在前端加了一个 connection pooler。令人印象深刻的是，他们精准地找到了真正的问题，而不是他们“以为”需要解决的东西。

“我是在解决一个实际问题，还是一个假想问题？”

“它不会扩展”这句话是软件工程里最昂贵的一句。因为它几乎总是技术上成立的——事实上，任何东西都无法无限扩展。但在实际环境中，99% 的项目在需要扩展前就已经停运了。而那 1% 能跑出来的项目，总会有时间和钱，在未来去有效解决问题。

纪律，没有光环

不是说，分布式数据库、用 Rust 写的、带有自定义共识协议的库不好。它们确实很酷，适合做演讲，也能为简历增光添彩。

但如果你真正需要的只是带 connection pooler 的 PostgreSQL 和优化查询，那么分布式数据库可能只是一个没有收益的额外成本。而这个成本不仅仅是技术上的——更是你注意力上的。每一小时花在配置集群上的时间，都是从理解数据、优化查询，或者与用户沟通中夺走的。

乏味的纪律——简洁的查询、合理的超时设置、隔离任务负载、执行脚本的 cron、保持更新的 README、系统化的调试方式——不会成为技术会议的主题，没有商标，也没有自带光环的专属大会。

但它才是真正一切都失灵时依然有效的方法。

本周的六篇文章，只是在同一时间点再次提醒了我这个道理。有时候，主线会自然显现。你只需留心观望。

本周的六篇文章：