枯燥的纪律战胜魔法的一周
发布: (2026年4月30日 GMT+8 23:41)
8 分钟阅读
原文: Dev.to
看起来您只提供了来源链接，而没有要翻译的正文内容。请把需要翻译的文本（除代码块、URL 和 Markdown 语法外）贴在这里，我会帮您翻译成简体中文。
Source: …
六篇文章，一个洞见
我本周发布了六篇文章：
- PostgreSQL
- AI 代理
- 上下文管理
- 自动化教程
- 调试分析
- 用于评估 MVP 的对抗性建议框架
这并非计划好的——每篇文章都来源于一篇论文、一场演讲或一个吸引我的项目。
但把它们放在一起看时，会出现一条共同的线索：
六篇文章都在说同一件事。
六个示例
| 领域 | “乏味”但可行的方案 | “新”承诺——更好的东西 |
|---|---|---|
| 数据库 | PostgreSQL + PgBouncer | 带分片的分布式数据库 |
| AI 代理 | while 循环 + 工具 | 带编排器的多代理架构 |
| 上下文管理 | YAML + README + 循环缓冲区 | 带向量存储 + 嵌入管道的 RAG |
| 自动化 | cron + bash + curl | 云原生编排平台 |
| 调试 | 观察 → 缩小 → 假设 → 验证 | 端到端可解释性工具 |
| 想法评估 | 使用已发布框架的结构化辩论 | 带面板数据的市场调研平台 |
左列展示了解决大规模问题的团队实际使用的方案。
右列展示了在会议上被推销的方案。
为什么“乏味”方案会赢
- PostgreSQL – Bohan Zhang 在 OpenAI 扩容案例中的文章展示了 8 亿用户使用 单主库，没有分片，仅靠 PgBouncer（2007）和读副本（90 年代技术）。
- AI 代理 – Michael Bolin 对编码代理的剖析：一个简单的
while True循环配合 LLM、工具和停止条件。没有知识图谱，没有符号规划器。 - 上下文工程 – OpenAI Cookbook 说明，注入 README、裁剪历史或对旧数据做摘要都是经典技巧。
- 自动化 – 教程演示了 OpenAI 的 Codex 自动化本质上是
cron + curl + LLM。调度器已有 40 年历史；大脑只有 2 年。 - 调试 – Jane Street 的谜题（2,500‑层网络 = MD5）通过经典调试手段解决：观察数据模式、简化、缩小选项。现代工具提供帮助，但方法是永恒的。
- 想法评估 – 用 LLM 模拟五位专家不过是廉价的兵棋推演——事后评估自 1950 年代就已存在；唯一的变化是成本（≈ 2 美元的 token 费用 vs. 5 万美元的咨询费）。
这些观察呼应了长期流传的智慧：
- Dan McKinley – “选择乏味的技术”（2015）
- DHH – “不要把 CRUD 应用 K8s 化”
- Fred Brooks – “没有银弹”（1975）
核心信息
新技术解决的是大多数团队根本没有的问题。
| 示例 | 为什么“不新”的技术已经足够 |
|---|---|
| OpenAI DB | 95 % 为读请求 → 单主库在将重写操作转移到其他地方后即可处理写入。 |
| 编码代理 | 模型可以在一个简单循环中决定使用哪个工具以及何时停止。 |
| 基于 Cron 的自动化 | 99 % 的自动化都是“每 N 小时运行一次”。只有边缘情况需要复杂编排。 |
复杂性偏见
我们倾向于偏爱复杂的解决方案，因为它们 感觉 更适合艰巨的问题。一个“黑客手段”（例如，将重写操作迁移）可能看起来像是捷径，而使用一致性哈希的分片则像是“真正的工程”。然而，这种黑客手段往往更能奏效。
Source: …
s faster and cheaper.
Opportunity cost: The time spent building an elegant, unnecessary solution is time not spent delivering value.
实际要点
自问：
我在解决什么问题是无聊的技术处理不了的？- 如果答案是“没有，只是新技术看起来更酷”，那你就在增加不必要的复杂度。
- 如果答案是“我需要 X，而 PostgreSQL 没有它”，就采用新技术——明确 X 是什么。
有纪律地利用现有工具：
- OpenAI 通过 PgBouncer 解决了连接瓶颈——没有新数据库，也没有数据层重写。
- 找出真实的问题，而不是你以为的那个问题。
记住复杂性的代价：
- 更多 bug，入职时间更长，凌晨 3 点的紧急抢修。
结束思考（未完）
我是在解决真实的问题，还是未来的问题…
(原稿中此句被截断。)
> “It won’t scale” is the most expensive phrase in software engineering.
> Because it’s usually correct — technically, nothing scales infinitely.
> But in practice, 99 % of projects die before scaling becomes an issue.
> And the 1 % that survives will have the resources to fix it when the time comes.
It’s not that using a distributed database written in Rust with its own consensus protocol isn’t cool.
It’s awesome. It makes for great talks. It looks fantastic on a résumé.
But if what you need is **PostgreSQL** with a connection pooler and properly written queries, the distributed database is a cost with no benefit.
And the cost isn’t just technical — it’s cognitive. Every hour spent configuring the cluster is an hour not spent:
- understanding your data,
- optimizing your queries,
- talking to your users.
Boring discipline — simple queries, aggressive timeouts, workload isolation, cron jobs running scripts, up‑to‑date READMEs, methodical debugging — doesn’t make the keynotes.
It doesn’t have a logo. It doesn’t get its own conference.
**But it works when nothing else does.**
And this week, six unrelated articles reminded me of that all at once. Sometimes, the common thread reveals itself. You just have to look for it.本周的六篇文章
- OpenAI scales PostgreSQL for 800M users with a single writer – 经受战斗考验的数据库，交付新一代技术承诺的结果。
- Your AI coding agent is just a while loop with delusions of grandeur – 拆解 Codex CLI 与 Claude Code 的魔法。
- Context engineering: the invisible skill – 模型看到的内容比模型本身更重要。
- Codex Automations, no Codex needed – cron + bash + LLM = 午夜代理。
- A 2,500‑layer neural net turns out to be MD5 – 经典调试遇上机器学习。
- Five non‑existent experts review your startup – 对抗性辩论作为决策工具。