AIOps on 最后的DBA

当 PostgreSQL 成为 AI 的双手——Bruce Momjian 的 MCP Server 实战

Wed, 27 May 2026 00:00:00 +0000

原文：Building an MCP Server Using Postgres，Bruce Momjian，PGDay Armenia 2026，CC BY 4.0。

本文AI率80%

Bruce Momjian（PG core team，写了 20 多年发行注记的那位）最近在 PGDay Armenia 2026 做了一个演讲：Building an MCP Server Using Postgres。70 页幻灯片，信息密度极高。有理论，有实践，是一个不错的借鉴。

直接读是比较费劲的，哪怕是直接让AI解读一下估计也不知道说的是什么，我也是看了一会问了几个问题后才算看明白了。

这 70 页可以清晰地切成两层——前半部分是理论教学，后半部分是实战 demo。两层之间，关系不大。

理论层：用 Transformer 解释 RAG → MCP 的演进（Slide 1-33）
#

理论层占了近一半篇幅，从 LLM 基本原理讲到 MCP 的工作方式。Outline 很清楚：

RAG vs MCP：一句话说清
#

RAG 的流程大家都熟了：程序员决定查什么数据 → 检索结果拼到 system prompt → LLM 读完后生成回答。预编排——LLM 能看到什么，在用户提问之前就定好了。

MCP 不一样。工具描述注册给 LLM，LLM 在生成过程中自己判断要不要调工具、调哪个。动态决策——程序员只负责暴露工具，LLM 负责编排。

Bruce 用一句话总结：

RAG 只能做程序员预设的事。MCP 可以根据输出质量动态调整，可以迭代调用多个工具，还可以触发外部任务。

“是词还是 MCP”——那套向量嵌入图解
#

Slide 18-33 是理论层最核心的部分。Bruce 画了一套详细的 Transformer 内部流程图：

他的逻辑是：把每个 MCP tool 的描述文本（比如 “Return the radiation level (CPM) at 13 Roberts Road…"）用文本嵌入模型向量化，塞进 attention 层的向量空间里。然后在每一步推理时，output vector 去匹配最近似的向量——

“The closest vector might be a word or an MCP.”

这个模型对吗？
#

这是我最疑惑的地方，以下是我的浅见。

Bruce 这 15 页 slides 画得很好看，但如果当工程实现去理解，是有问题的：

① MCP tool 不需要"嵌入”。 实际工程中，tool 定义是作为文本直接写在 system prompt 里的。LLM 读到 “你有这些工具：geiger()、get_pretzel_inventory()…"，靠语义理解决定什么时候调。不需要把 tool 描述算成向量，不需要和词向量做余弦距离比较。Bruce 这套教学模型的本质是把"LLM 决策"解释成"向量最近似匹配”，这更像 retrieval 的范式而不是 generation 的范式。

② Attention 不产出"查最近似"的操作。 output = Σ(softmax(Q·K) × V)，产出的是一个加权混合后的上下文向量。没有"在词向量表和 tool 向量表里二选一"这一步。LLM 选工具的实际机制是 attention 产出 hidden state → LM head → softmax over 词表 → 输出 tool call JSON。从来没有在"词和 tool 之间二选一"，只有在整个词表上做 softmax。

③ system prompt 和 user prompt 在 attention 里没有边界。 Token 序列就是 token 序列，attention block 对所有 token 一视同仁做 Q·K 点积。不存在"system 区"和"user 区"。

所以这 33 页理论层，可以看作 Bruce 给非 AI 背景的 DBA 做的一个教学简化模型——好看、好懂，但别当架构图用。MCP 真正革命性的地方在协议标准化（统一的 tool 注册/发现/调用规范），不在向量化的 trick。

实践层：两个能跑的 demo（Slide 34-69）
#

从 Slide 34 开始，风格突变——全是代码、终端输出、硬件照片。理论层那套 Transformer 向量模型完全消失了，取而代之的是 curl、psql、Perl 脚本。

两层之间的唯一联系是"它们都在讲 MCP"，但理论层画的向量匹配机制和实战中的实现方式几乎是两套逻辑。这可能正是 Bruce 演讲的张力所在——理论层让你理解 MCP 为什么比 RAG 强，实践层告诉你现在怎么落地。

Demo 1：让 ChatGPT 读取真实世界的盖革计数器
#

Bruce 在自家院子里架了一台 GQ GMC-800 盖革计数器（测辐射的），USB 接树莓派，每 15 分钟测一次环境辐射。先看 ChatGPT 用 MCP 调用真实数据的效果：

MCP 可以调用外部工具获取实时数据——这是 RAG 做不到的。

接上硬件：

用 fastmcp 写了 Python wrapper：

from fastmcp import FastMCP

mcp = FastMCP("Geiger counter MCP server")

@mcp.tool
def geiger() -> int:
 """Return the radiation level (CPM) at 13 Roberts Road, Newtown Square, PA, USA"""
 return subprocess.check_output(
 "/var/lib/postgresql/tmp/geiger", shell=True, text=True
 )

底层是一个 Perl 脚本，往串口发 <GETCPM>> 指令，读回 4 字节 CPM 值。Apache 做 443 端口反代（OpenAI 只跟 443 通信），注册到 ChatGPT 后：

User: 13 Roberts Road 的辐射水平是多少？
GPT: 我没有这个位置的公开数据……

User: 用我的 custom app
GPT: [调用 geiger tool] → 14 CPM。正常环境背景辐射（5-25 CPM）。

User: 测五次，给我平均值
GPT: [调用 ×5] 15 16 13 15 15 → 平均 14.8 CPM

两个关键行为：

LLM 可以迭代调工具做计算——RAG 是一次性塞数据，MCP 是"调 → 拿结果 → 判断 → 再调 → 算"
用户必须显式授权——第一次问的时候 ChatGPT 没说"我有你的盖革计数器数据"，直到说 “use my custom app” 才触发 tool call。安全模型很保守

Demo 2：用 PG 做椒盐卷饼店的库存系统
#

从硬件回到软件。建一个椒盐卷饼（pretzel）库存库：

CREATE TABLE pretzel (
 quantity INTEGER CHECK (quantity >= 0)
);
INSERT INTO pretzel VALUES (0); -- 初始库存 0

MCP tool 直接用 psql 操作 PG：

@mcp.tool
def get_pretzel_inventory() -> int:
 """Return the number of unsold pretzels"""
 return subprocess.check_output(
 "psql --tuples-only -c 'SELECT quantity FROM pretzel;' -d mcp",
 shell=True, text=True
 )

@mcp.tool
def sold_one_pretzel() -> str:
 """Call this when a pretzel is sold; reduces inventory by one"""
 return subprocess.check_output(
 "psql --tuples-only -c 'UPDATE pretzel SET quantity = quantity - 1;' -d mcp",
 shell=True, text=True
 )

@mcp.tool
def baked_6_pretzels() -> str:
 """Call this when a tray of 6 pretzels is baked; increases inventory"""
 return subprocess.check_output(
 "psql --tuples-only -c 'UPDATE pretzel SET quantity = quantity + 6;' -d mcp",
 shell=True, text=True
 )

交互流程：

User: How many pretzels available?
GPT: 0 pretzels.

User: I just baked a tray → 6 pretzels
User: I sold two → 4 remaining
User: I sold four → 0 remaining

User: I sold one pretzel → ERROR! CHECK constraint 阻止了 quantity 变负数

LLM 不直接写 SQL，而是调你预先定义的受控接口。PG 的 CHECK 约束天然构成了一个安全兜底——即使 LLM 被诱导调了不该调的函数，数据库层的约束还能挡一道。

但也暴露了问题：LLM 忠实执行了 sold_one_pretzel，但不会预判"库存已经是 0 了调了会报错"。MCP 是执行层，不是推理层。

生产还差多远
#

Bruce 在最后一页坦承了当前实现的局限：

没有认证——谁都可以调你的 MCP Server
没有参数化——三个 tool 都是无参函数，现实中的 tool 需要传参数
动态 SQL 没做安全限制——工具描述声明了语义，但 LLM 可能被注入恶意内容
连接池、事务管理、频率限制——一概没考虑

两篇值得读的实践经验：

两层之间
#

回头看这 70 页幻灯片，最有趣的不是任何一个 demo，而是MCP的理论思路和动手说明MCP能做什么：

理论层用 Transformer 向量空间解释"LLM 如何在词和工具之间做选择"——这是教学模型
实践层用 psql、curl、Perl 脚本去落地——这是工程实现

而真正的 MCP 机制——tool 定义当文本塞 system prompt、LLM 靠语义理解决定调哪个、输出 tool call JSON——应该是不需要理论层那套向量嵌入模型。两层之间，Bruce 没有画出来连接线。这可能不是 bug，是 feature。

AI时代下的DBA、写作、学习和未来

Wed, 21 Jan 2026 00:00:00 +0000

AI率：本篇文章AI率约60%，与AI battle回合约20次

推荐理由：有一些对AI ops的思考和洞察，所以推荐

AI时代的写作
#

AI对写博客、写公众号的作者来说，可能是一个致命的打击，因为AI写作实在是太简单。因为我自己就写文章，我自己对AI影响写作习惯也有很多纠结的地方，我也很难受。这里再把以前的对写作的思考拿出来：

为什么写作？

为自己，巩固知识。输出才可以加强输入，看一眼和写一遍是完全不一样的，写作的时间可能是看一遍时间的好几倍。就比如，看到一句有道理而且自己很懂的话，自己在写一遍时，你会发现这句话里面有非常多的细节。
为自己，合理利用他人偏见。主要是为了利用他人偏见让自己坚持写作以及提升内容的可信度，自己看的知识可能差不多就得了，写给公众看就要字斟句酌对他人负责。（相对的，不是真·字斟句酌）
为自己，提升知名度。这就很依赖写作水平了。
为他人/社区，传播知识。好东西要拿出来大家一起看和使用，这是Postgres开源社区的内核所在。鼓励分享，不鼓励藏着掖着，这也是我一直秉持的理念。
结交圈子。我不是为了这个来，但确实认识了一些小伙伴

人力写作已经很难了，在AI时代人力写作约等于地狱模式，就像没有目标地逆行，看不到光在哪，而人们都在往反方向走。我自己当然体验过AI解读、翻译、写成文章，但总感觉那不是我的，或者失去了训练我自己的初心，或者更深层次一点，我想感受到作品的生命力。

整个DBA圈子的文章可以用鱼龙混杂来形容，写啥的都有。而我自己一直都喜欢内容性文章，偏PG原理和运维的，比如灿灿和向博的文章，我都是翘首以盼每次必细品。一般内容性文章都不会有特别多的流量（灿灿和向博都各自在公众号吐槽过··），我自己也很随缘。

但是，我上一篇文章《pg运维数据库运维经验2025》涨了很多粉，实属让我惊讶。所以我这几天一直在思考这个问题：为什么一个人（非AI）写的、非完备的、DBA的、知识性的文章，会有这么多人感兴趣？AI对DBA意味着什么？

对运维的思考
#

运维的本质和AI Ops
#

运维要做很多事情，为了减少讨论的范围，我在运维工作中极少一部分–故障响应，来解读DB Ops的本质。首先我的观点：“运维不仅仅是技术问题”

很多人通过人会犯错AI也会犯错来解释可以给AI权限让它大胆的干，具体的说是AI的错误率<=人的错误率即可完成替换。我2年前也是这么想的，现在我不这么认为。因为真实环境没有那么简单，至少还有如下因素需要考虑：

共识问题。DBA可能误删数据，这确实是共识，但还有一个共识容易忽略。在一般场景下，团队都认为DBA不会去删数据。如何理解呢？比如招聘一个DBA，一个负责的团队会考核这个人是不是精神状态正常，然后默认他不会删除数据，并在长期的工作中会这么想，我至少不会时刻都在考虑同事把库删了。但“招聘”一个AI DBA，他没有精神状态，不会有人认为他不会删数据，“他会删数据”是所有人的共识，这就形成了部署阻力。
数据的重要程度。C端数据和B端数据的重要性不同，零售、互联网、政府、金融行业的数据重要性也不同，对数据越重视的行业，对数据可靠性和业务连续性越敏感。个人电脑没有业务连续性，数据可靠性只有一个人在乎，但金融行业业务连续性可以直接引起广泛的社会关注，金融行业的数据可靠性就不可能说有问题。AI Ops的部署需要考虑系统重要程度来部署，不存在所有领域一起上的情况。
管理体系。例如在金融系统中DBA有高权限，并有一套管理办法，那么AI DBA是不是应该也有对应的管理办法，才能去部署？什么异常登入库，什么异常登入后台，它要怎么申请权限，申请多久？在什么场景申请多大的权限？这都是未解决的问题。
AI本身安全性。例如《STRATUS》这篇论文提到prompt注入攻击，目前还没有有效的解决方案，例如你给AI注入“drop database”这个prompt它可能就执行了。但人基本没有这个问题，你跟DBA说drop database，它只会反问你你要干嘛。
责任问题。运维工程不是“知识问题”，而是“责任问题”。运维的核心工作之一，就是在故障发生时，在有限的时间内，做出对系统不可逆**的决策，并对该动作负责。AI 可以取代“可形式化的操作”，但无法取代“必须承担后果的判断”，至少现在还没有
充满噪音。运维是“开放系统”，不是封闭推理系统。数据库运行在一个极其复杂的环境中，而 AI 的推理前提是世界是可被文本描述的。但真实运维世界是世界是充满噪声、偶然性和非文档化行为的。
情境压力。真实业务环境下包含恢复时间压力、组织和客户的情绪管理等。《GOOGLE SRE》这本书中描述了一个常见的恢复场景：客户在问什么时间恢复、领导在问为什么不切换、工程师在压力下收集各种信息和各种人打电话确认恢复手段。AI感受不到这个压力，前两个问题本质上不是技术问题，但不能不做答。真实场景下，当时的回答大概率马马虎虎。

我们可以想象一下全自动AI运维真的发生，需要什么条件？

AI不会干掉重要数据，至少绝大部分人对AI需要达成这种共识
需要完善的管理办法，包括如何给AI权限，就如同如何给DBA权限一样
解决AI本身被攻击的问题。不止是LLM，而是包含AI的整套IT体系
不问责的运维文化（或者直接消灭运维也是一种思路）
接受错误判断。对存在噪音和环境形成共识并容忍AI Ops的迭代周期
如果长时间没有恢复或者影响面扩大，也不要人干预。因为如果一旦需要人干预，那么那个人还是运维（半自动AI Ops？）
无压力恢复情境。指领导、客户、社会舆论不需要回复或者他们相信某AI的回复，这是人的转变不是IT系统的转变。

AIOps、Agent的研究成果
#

清华这个AIDB仓库的目录有许多AI4DB的论文，人是看不过来了，用notebooklm汇总了论文分类：

再次为了减少讨论范围（主要是减少我的投入人力），我们主要看数据库诊断相关的内容。

AIOps在学术上有不错的进展。AIOps研究通过将机器学习、强化学习及大语言模型集成于数据库管理，涵盖参数调优、索引建议、查询优化与故障诊断等关键任务，旨在构建具备自感知与自修复能力的“自动驾驶”数据库系统，在显著提升复杂工作负载性能与运维效率的同时，推动DBA从低效的手动干预转型为高层级的架构监管者。

关于“DBA（数据库管理员）是否会被淘汰”的问题，目前的科研趋势和工业实践（尤其是自动驾驶数据库和大语言模型的应用）显示，DBA的角色正在经历一场从“手动操作者”向“高级管理者/监督者”的深刻转型，而非简单的被取代。DBA核心价值将转向管理AI运维策略、确保数据安全合规、以及处理AI无法解决的极端异常场景。

另一篇AI Ops前言综述的文章对Agent这样描述：

“这说明AI Agent并非银弹，要应用Agent不只需要模型和agent层面的进步，还需要需要整个被运维系统具备足够的支持能力比如类似Kubernetes的声明式接口、良好的可观测性、可逆的操作设计。Stratus的初步实验证明了Agent在自动运维上的潜力，但距离生产部署在性能、可靠性和安全性上仍有巨大的问题。”

开发领域因为如火如荼的vibe coding，要明显比AI在运维领域的应用快很多。我也很想有个confirm、redo的运维遥控器，问题是现在确实没有。即使我们现在幻想有一天有vibe maintaining，应该也没有几个运维会打开yolo模式。

DBA的价值
#

DBA的价值是拍板背锅侠吗
#

背书好像确实不能通过AI解决。那么DBA的价值就是拍板背锅侠吗？毕竟dba的知识远低于AI，只是AI不能拍板罢了。

瞬时上下文

“DBA 的知识远低于 AI”，这在通用知识（比如如何优化一个 SQL，或者某个配置参数的含义）上确实是事实。但 AI 缺少瞬时上下文（Runtime Context）。 AI 知道数据库原理，但它不知道你公司双十一流量激增的瞬间，那个负载均衡器后面藏着的陈年历史债。DBA 拥有的是关于“这台特定机器、这个特定业务、这些特定人”的非结构化经验。在极端故障面前，AI 给出的是“概率最高的建议”，而 DBA 给出的是“在这个特定压力下，最能保住命的那个操作”。

“混沌系统”的最后闸门

数据库是所有 IT 架构中最脆弱、最不容错的部分（代码坏了可以回滚，数据丢了公司可能就倒闭了）。AI 的逻辑是基于历史数据的推演。当出现从未见过的底层硬件坏道、极其罕见的分布式死锁，或者黑客的新型攻击手段时，AI 的“建议”往往会失效甚至造成二次伤害。“拍板”的核心不是“选哪个方案”，而是**“承担风险的对冲”。这种对极端情况的掌控力**，是目前的AI无法提供的。

信任链

DBA是信任链的维护者：例如让 AI 审计 AI，那么谁来审计 AI 的审计逻辑？在数据安全、合规和伦理层面，必须有一个拥有最高权限且可追责的人类作为信任链的终点。

我们反过来想，如果 DBA 真的只是“知识较少的拍板背锅侠”，那么企业其实早就会把 DBA 的拍板权交给SRE或者架构委员会、甚至AI等等责任主体。但现实是在真正关键的时刻，企业仍然会把电话打给“那个人”。这说明问题从来不是“谁更聪明”，而是谁能在不确定性中，为组织承担后果。DBA 是数据库这个混沌系统中，最后一个拥有止损权、责任权和信任终结权的人类。

那么拍板都是DBA说了算吗？显然不是。DBA 并不拥有“目标决策权”，而是拥有“风险否决权”——他们不能决定业务要不要冒险，但可以决定系统不能承受哪些冒险。在简单、低风险、可回滚的场景下，拍板往往由流程或系统自动完成；只有当决策进入高风险、不可逆、责任必须收敛的区间时，DBA 才会被推到台前。

Postgres DBA的特殊性
#

针对 Postgres (PG) DBA 这个特定群体，其特殊性会更加显著。

在现代技术组织中，DBA 并不天然拥有架构决策权，也不垄断索引或参数的制定。架构师可以设计方案，开发可以编写 SQL，AI 甚至可以给出看似完备的最佳实践建议。但这些决策大多发生在抽象层、设计层和概率层，它们假设系统是可回滚、可重放、可修正的。

Postgres 的特殊性在于，它将大量自由度交给使用者，而这些自由度最终都会转化为真实系统中的长期副作用：写放大、IO 模式变化、Vacuum 失衡、WAL 膨胀以及难以预测的性能退化。这些副作用无法在设计阶段完全预演，也无法被单一角色分包处理，更无法在事故发生后简单“撤回”。当系统进入不可暂停、不可重放的状态时，唯一仍需对整体结果负责的人，往往就是 DBA。

因此，Postgres DBA 的价值不在于“替别人做决定”（当然也可以啦），而在于在所有决定已经发生之后，持续管理它们在现实世界中的后果。“架构师定义理想，开发实现功能，AI 预测未来；而 DBA 守护真实。”

这个守护真实的能力是基于PG DBA拥有足够了解Postgres、足够了解系统真实环境、足够了解系统的历史和足够的即时上下文。在AI的时代，还需要再增加一个，足够了解AI。

为什么还要学习
#

这两年听到读书无用论比以往多了许多，说这种话我一般都嗤之以鼻。借此机会好好盘一盘。

数据库基础知识还有没有价值？答案是：价值更高了。我们从解释权、主动学习和为什么我还在反复看经典来解读。

1.问题的解释权

基础知识让你做到三件事：

提前识别“系统性必炸点”
把判断逻辑讲清楚
把“我拍脑袋”变成“这是系统决定的结果”

学数据库基础知识的真正意义，不是为了“多干活”，而是为了：

划清责任边界
提升话语权
让系统为你的判断背书

2.主动学习成为更稀缺的能力

在 AI 时代，知识获取的“技术壁垒”趋近于 0。主动学习能力是稀缺的。为什么“主动学习”在 AI 时代反而更稀缺？这点很反直觉，但非常现实。AI 让“被动学习”极其舒服，随问随答、无需长期投入、不必承受认知不适。但是导致的结果是，越来越多的人停留在“即时满足层”，不愿意再去学习基础知识。当所有人都在倒退时，你发现你走的更快了。

3.为什么还在反复看《The Internals of PostgreSQL》这种经典？

技术人员需要看书，是因为书不是在给答案，而是在帮我建立一个可以反复运行、不断修正的认知模型；而 AI 目前更擅长回答问题，而不是塑造这种模型。AI 很难成为这种“长期对话对象”，它的回答是不稳定的。

另一个方面，从认知经济学 + 信息论 + token 成本的视角来看书的价值。首先，你不用跟 AI battle 来 battle 去，battle 的真正成本不是钱，而是你的注意力和上下文维护能力。其次，书中的几十万字不仅不需要你输入大量的prompt，也不需要你付出过多的tokens。再次，这个书籍的知识经过了作者和读者的反复验证，是已压缩过的知识，是最容易学习的。所以，经典书籍 = 极低 token 成本下，获得高密度、被人类反复验证过的专注知识的压缩结果。

4.学习AI本身

这不需要我说了。

跟AI的battle，让我得出一个有趣的关于“为什么还要看书”的结论：

在 AI 时代，知识是廉价的，判断力才是昂贵的 => 而判断力，来自于稳定、可校准的认知模型 => 稳定的认知模型，本身是“长期高质量知识摄入”的副产品。

另一个可以佐证读书有用论的一个现实证据是，我现在这篇文章依赖于我读过的一些书、论文、其他文章和资讯，如果没有这些，这篇文章不会与各位见面。

为什么大家还爱看"人"写的文章
#

偏爱漏洞的心理
#

人类写的技术文章，难免漏洞百出，我自己看我去年写的运维经验2024，就可以找到很多漏洞。即便是前几天刚完成的运维经验2025，我也认为这篇文章是不完备的，跟AI写的东西差别很大。但是为什么读者还是喜欢这种漏洞百出的技术文章呢？

原因可能是人类不是被“信息正确性”吸引，而是被“可共情的不完美心智痕迹”吸引。从《智力简史》这边书中可知，人类的智力模型本身就包含自我试错式的探险和观察别人的行为并映射自我这两种模型，这是一种学习过程，是人类与生俱来的。我们的大脑默认会扫描文本中的的犹豫、不确定、逻辑断裂、表达不顺、情绪泄漏等等，这些在 AI 文本中被系统性地忽略。在文字的漏洞和情绪中，读者可以感受到作者的思考和情绪，而AI只是给出了结果，读者几乎不会与AI有情绪共鸣。一般来说，只有真实经历过的人，才会留下这种“不好看”的痕迹。

所以我相信很多人跟我一样，一眼纯AI的技术文章（不保证100%判断正确），一般不会有情绪读下去。但如果是人类认真写的，会认真读下去，去感受作者的感受，去抓他的不足或场景缺陷。

当然，作者也可以喂一些提示词模仿之前文章的口吻或者故意留漏洞，不过我没有认真这么做过，简单试过生成了几篇，感觉情绪带入还是比较差。后面也不想再继续深入尝试了，再试下去意义也不大。

白嫖大神的ATTENTION
#

AI文章和大神文章的核心差异不是“写得好不好”，而是经济性问答、行业领先的Attention的问题。大神写作是在替读者分配注意力，AI 写作是在避免遗漏任何可能相关的信息。这不是能力问题，而是目标函数不同。真正高价值的技术文章，不是告诉你所有正确答案，而是替你挡住 80% 你现在不该关注的东西。

大神为什么敢“删”，AI 为什么不敢？因为他们为你的理解结果承担认知责任，AI不承担你学错、用错的后果。于是大神会刻意过滤那些目前不需要注意的细节。这种过滤，本身就是专家价值。对人类来说，学习的瓶颈不是信息不够，而是注意力有限、不知道先看哪里。大神的文章直接把结果给你对你说，你就看着这个。但你面对LLM的时候，你知道该找什么东西吗？

这并不是在否定 AI 文章的价值。AI 擅长的是“在你已经知道问题边界时，快速铺开信息空间”，而大神文章擅长的是“在你尚未建立判断框架时，替你先收缩问题空间”。前者适合查漏补缺、横向扩展，后者适合建立主干认知和关键直觉。真正高效的学习方式，并不是二选一，而是先借助大神完成 Attention 对齐，再利用 AI 在被限定的空间内做放大搜索。

这不是在说AI的东西没有用，或者人类写的东西没用，而是各自有用。

AGI能解决所有问题吗？
#

驳Musk
#

最近Musk又在画大饼，看完以后我并不赞同。

共同富裕还是无用阶级？

无用阶级是尤瓦尔在《未来简史》中的观点，他认为当AI的生产力超过普通人的时候，用AI干活会替代让普通人干活。这些人就成为了无用阶级。资源会愈发集中在少数精英和大公司手中，大部分人会失业，但是失业情况目前没有有效政策可以为之兜底。这个观点刚好与马斯克式的共同富裕有出入，马斯克认为当AGI实现时，所有人都不需要担心生存、教育、医疗，生产力高到政府会给大部分人兜底。我目前支持尤瓦尔的观点。其实从身边感知性统计也可以看出来，无用阶级的人数正在上升。

高生产力可以制造乌托邦吗？

一个支持我不同意AGI乌托邦的理论来自于另一本书《进化心理学-择偶标准》。其中有一个观点令我印象深刻：出于社会分工和生物培育良好后代的考虑，男性偏爱年轻、健康的女性，女性偏爱健康、有资源的男性。这个刻在我们基因里的默认筛选，导致了人是不会平等生活的，你不想成为被淘汰的那个。所以一个不攀比、没有竞争的、资源平等的乌托邦如果能够维持下去，生产力只是必要条件之一，还有许多必须解决的社会问题容易被大众忽略。这里不是狭义的单指进化心理学，有些东西没有被仔细讨论，比如《黑猩猩政治》中的权力纷争，其实也应该被考虑。

卡尔霍恩的老鼠乌托邦实验

1972 年，动物行为学家约翰·B·卡尔霍恩John B. Calhoun）设计并详细描述了一个著名的实验环境——“宇宙 25 号”。这是一个专门为老鼠打造的实验室“乌托邦”，几乎在每一个方面都力求完美：食物、水源和筑巢材料充足；居住环境定期清洁；没有捕食者威胁；温度通过风扇与供暖保持在 20℃至 31℃之间，稳定舒适。

老鼠数量走向灭亡看起来有些疯癫，我选择只看过程部分：1)暴力增加 2)不再追求异性 3)同性行为增加 4)独处行为增加 5)男性爱打扮自己 6) 冷漠等等。当然这个实验会有一些缺陷，从《智力简史》中描述的智力模型来看，老鼠和人的智力模型还差着一个灵长类动物，它不能代表人类社会。但是至少可以看出，乌托邦会引起新的社会问题，人们不会老老实实的过日子。

基于经济学的社会

从现代经济学的角度来看，AGI 是否能够实现“共同富裕式乌托邦”，可分为两种类型来看：保留现代经济和不保留现代经济。

如果保留现代经济，AGI 可以被视为一种极端高效的“通用生产要素”。它显著降低了知识生产、决策支持、组织协调和边际劳动成本，提高了全社会的生产率上限。在这一前提下，财富分配、公共服务供给和社会保障机制，仍然依托市场、价格信号、激励机制和制度约束运行。AGI 的作用更多体现在扩大“可分配蛋糕”的规模，而非自动解决分配问题。换言之**，**共同富裕依然是政治经济学问题，而不是技术问题，AGI 只能降低实现目标的成本，却无法替代制度设计。

那么，如果不保留现代经济，而是试图绕过市场、价格与激励体系，直接依靠 AGI 实现某种“技术乌托邦”，是否可行？

答案几乎可以确定是否定的。

没有现代经济的乌托邦，在 20 世纪 60–70 年代已经被反复验证为失败。其根本原因并不在于当时“技术不够先进”，而在于信息与激励问题的结构性不可解： 即便拥有强大的集中式计算能力，也无法替代分散个体通过价格机制传递的偏好信息，更无法在长期内维持创新动力、责任约束和资源配置效率。AGI 可以提高集中决策的计算能力，但无法消除“谁为决策负责、谁承担后果、谁拥有选择权”这一经济学基本问题。

因此，AGI 并不是现代经济的替代者，而是现代经济框架下的放大器。任何脱离市场机制、激励结构和制度约束的“技术乌托邦”，无论是否引入 AGI，本质上都会重演历史上的失败路径，只是失败形式更加隐蔽、成本更高。

生产力（包括 AGI 带来的智力提升）只是乌托邦所需条件之一，而且远远不是最关键的那一个。乌托邦不是算力问题，也不是智力问题，而是人类行为在制度约束下的稳定性问题。

AI解决不了所有问题的数学基础
#

以下抄自吴军的《数学之美》：

“1900年，希尔伯特提出了许多问题，其中一个是：‘任意一个（多项式）不定方程，能否通过有限步的运算，判定它是否存在整数解’。如果对希尔伯特这个问题普遍答案是否定的，那么就说明很多数学问题其实上帝也不知道答案是否存在，因为不定方程求解问题还只是数学问题中很小的一部分。对于连答案存在与否都无法判定的问题，答案自然找不到的。正是希尔伯特对数学问题边界的思考，让图灵明白了计算的极限所在····马蒂亚塞维奇严格地证明了，除了极少数特例，在一般情况下，无法通过有限步的运算，判定一个不定方程是否存在整数解。这个问题的解决，对人类认知上的冲击，远比它在数学上的影响还要大···如果连解都不知道，就更不可能通过计算来解决他们了”

“理性状态的图灵机可以解决的问题，只是有答案的问题中的一部分··很多工程上的问题并非人工智能问题···今天，我们所要担心的不是人工智能或计算机有多么强大，更不应该觉得他们无所不能，因为他们的边界已经清清楚楚地由数学的边界划定了···世界上还有许多需要由人来解决的问题，如何利用好人工智能工具，更有效地解决属于人的问题，才是应该给予更多关注的。“

（看吧，读书有用吧，直接给你讲明白，你大概率问不出来也拿不到这么通俗易懂的答案；看吧，关注硬核技术up有用吧，我帮你筛选了，快“点关注”⭐）

总结
#

作为一个写技术文章的博主，写此类社会问题是比较少的。本来就想简单写写上一篇文章为什么有流量，结果为了解释这个现象有点把问题扩大化了😓。

本篇的局限性：

只讨论了DBA工作的很小一部分–故障恢复，没有讨论其他工作的智能化问题。
GPT太了解我了，看上去在PUA我。它确实说的很有道理，但我无法给它说的东西背书。这就有点套娃了，AI帮我确认AI不能背书，这个输出本来就无法背书。从我自己的视角来看，它的思路确实不错，金句频出。

有些Ops场景当然是容易AI化的，但通过这篇文章的讨论，在故障恢复这个领域搞AI化，难度还是有的。我从来没有放弃用AI，也从来没有放弃用人脑，我只是喜欢识别AI在什么场景下好用，什么场景下不好用，什么场景下用不了。这让文章的基调看起来对AI的未来很悲观，其实我的想法不是悲观。

这篇文章的开头你可以看到 AI率是50%，实际上我还跟几个小伙伴讨论过类似问题，也包含自己的思考，所以这篇文章真正的智力比例是：

AI率50%，其他人脑率10%，我的人脑率40%

所以这篇文章也算是”不放弃使用AI，也不放弃使用人脑“的一个典型案例了。

最后用几个问题简单表面我的观点：

为什么人们还是爱看人写的文章？心理偏好和注意力对齐

读书有没有用（不只是书）？有用，而且比以往还有用（烂书比以往更没用，知识品味比以往更重要）

AIOps会不会实现？会，但还要时间，而且并不容易。这需要学术突破和运维（含DBA）的思考和实践

DBA会不会被替代？不会，跟软件开发者一样，会经历工作模式的改变，但不会消失

留下来的DBA是哪些人？“懂DB又懂AI，不依赖AI，又不放弃判断的人”

AGI会不会实现？会

AGI会不会实现全面富裕？不会

如果想跟我讨论AI Ops或者文章中的问题，可以在各个PG群里找我，应该好找，或者给我留言也可以。

ref
#

https://github.com/TsinghuaDatabaseGroup/AIDB

https://mp.weixin.qq.com/s/urqh4NZDmkXvDllBCCdZDA

Zhao, Y., et al. (2025). “STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds”.Advances in Neural Information Processing Systems (NeurIPS)

https://zhuanlan.zhihu.com/p/631632685

《数学之美》

AIOps on 最后的DBA

当 PostgreSQL 成为 AI 的双手——Bruce Momjian 的 MCP Server 实战

理论层：用 Transformer 解释 RAG → MCP 的演进（Slide 1-33） #

RAG vs MCP：一句话说清 #

“是词还是 MCP”——那套向量嵌入图解 #

这个模型对吗？ #

实践层：两个能跑的 demo（Slide 34-69） #

Demo 1：让 ChatGPT 读取真实世界的盖革计数器 #

Demo 2：用 PG 做椒盐卷饼店的库存系统 #

生产还差多远 #

两层之间 #

AI时代下的DBA、写作、学习和未来

AI时代的写作 #

对运维的思考 #

运维的本质和AI Ops #

AIOps、Agent的研究成果 #

DBA的价值 #

DBA的价值是拍板背锅侠吗 #

Postgres DBA的特殊性 #

为什么还要学习 #

为什么大家还爱看"人"写的文章 #

偏爱漏洞的心理 #

白嫖大神的ATTENTION #

AGI能解决所有问题吗？ #

驳Musk #

AI解决不了所有问题的数学基础 #

总结 #

ref #