Jacob Jackson 在 ByteofDev 做了一个只能称为“令人钦佩地不负责任”的项目：claudegres。它把自己描述成一个“PostgreSQL”，但关键点并不是让 Claude 调优数据库，也不是让 Claude 替用户编写 SQL 或查询数据库，而是让 Claude 直接充当整个后端。
这个想法之所以有趣，恰恰在于它故意打破了数据库系统的职责边界。传统 PostgreSQL 依赖解析器、执行器、存储引擎、索引和事务系统；claudegres 则把“理解请求、维护数据、决定结果”都交给语言模型。标题中的 “Ontogeny Recapitulates the Relcache” 也因此带着 PostgreSQL 内部机制的戏谑意味：一个数据库系统似乎在用最不传统的方式重新演化自己。
它改变的不是查询层，而是系统边界
常见的 AI 数据库方案通常有两种形态：
- Claude 帮助用户生成 SQL，然后由真正的数据库执行。
- Claude 观察数据库状态，负责调优、解释计划或辅助运维。
claudegres 的设想更激进：数据库本身的行为由 Claude 解释和生成。换句话说，模型不是数据库旁边的智能助手，而是数据库服务端的一部分，甚至可以说是全部后端。
这种设计把数据库最基本的几个问题重新暴露出来：
- 表和记录如何表示？
- 一次写入之后，后续请求如何看到一致的数据？
- 查询结果由什么规则决定？
- 相同请求是否一定得到相同结果？
- 崩溃后能否恢复？
- 多个客户端同时写入时，谁先谁后？
在传统数据库中，这些问题由明确的算法、数据结构和协议处理。把它们交给语言模型后，系统会获得极强的表达能力，却也会失去许多开发者默认依赖的确定性。
“Claude 是后端”意味着什么
可以把这个实验理解为一种极端的自然语言数据库：客户端发送的可能不再是严格 SQL，而是一个包含数据、意图和上下文的请求；模型读取当前状态，推断应该如何处理，然后返回结果和新的状态。
这带来几个很有吸引力的特性。
第一，数据模型可以非常灵活。用户不一定要提前设计完整 schema，模型可以根据请求理解字段和关系。第二，复杂的自然语言操作可能变得直接，例如“找出最近三个月没有续费、但使用量仍然很高的客户”。第三，原本需要查询解析器、执行计划和多个业务服务共同完成的行为，可以收敛成一次模型调用。
但代价同样明确。语言模型输出具有概率性，提示词会影响行为，模型升级可能改变结果，长上下文会增加成本和延迟，而且模型无法天然提供 PostgreSQL 所承诺的事务、锁、索引和崩溃恢复语义。
因此，claudegres 更适合作为系统设计实验或交互原型，而不是生产数据库的直接替代品。它的价值不在于证明“数据库已经不需要数据库工程”，而在于让我们观察：当数据库的核心约束被拿掉后，哪些能力会显得神奇，哪些基础设施会立刻变得不可替代。
一个最小的概念实现
下面的示例不是 claudegres 的源代码，而是一个可以运行和改造的最小概念版本。它假设使用 Anthropic API，把内存中的 JSON 数据和用户请求交给 Claude，并要求模型返回严格 JSON。示例用于展示“模型充当后端决策者”的边界，不提供真正的 SQL、事务或持久化能力。
运行前准备：
export ANTHROPIC_API_KEY="your-api-key"
python -m pip install anthropic
创建 claude_backend.py：
import json
import os
from anthropic import Anthropic
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
state = {
"users": [
{"id": 1, "name": "Ada", "active": True},
{"id": 2, "name": "Linus", "active": False},
]
}
SYSTEM = """
你是一个实验性的数据库后端。你只能操作给定的 JSON 状态。
返回一个 JSON 对象，格式必须是：
{
"answer": "给客户端的简短结果",
"new_state": {"users": [...]}
}
不要添加 Markdown，不要使用 JSON 之外的文本。
如果请求无法安全执行，保持 new_state 不变，并在 answer 中说明原因。
"""
def handle(request: str) -> dict:
prompt = {
"request": request,
"current_state": state,
"rules": [
"只允许修改 users 数组中的记录",
"不能删除用户",
"不能伪造不存在的用户",
],
}
response = client.messages.create(
model="claude-3-5-sonnet-latest",
max_tokens=500,
system=SYSTEM,
messages=[{"role": "user", "content": json.dumps(prompt)}],
)
result = json.loads(response.content[0].text)
if not isinstance(result.get("new_state"), dict):
raise ValueError("模型返回了无效状态")
state.clear()
state.update(result["new_state"])
return {"answer": result["answer"], "state": state}
if __name__ == "__main__":
print(handle("把 Ada 标记为 inactive，然后告诉我当前有几个 active 用户。"))
执行：
python claude_backend.py
这个小程序已经体现了核心思路：请求不是交给 SQL 执行器，而是交给模型；模型同时决定操作结果和下一份状态。真正可用的实现还必须增加 schema 校验、版本号、写前检查、审计日志、超时重试、状态持久化以及人工可解释的拒绝策略。
尤其要注意，不能因为模型返回了合法 JSON，就认为状态变化是正确的。JSON 只保证了格式，不能保证约束、权限、唯一性或业务规则。生产系统通常需要让模型提出操作计划，再由确定性的代码验证并执行，而不是直接接受模型生成的新状态。
这类实验适合放在哪里
claudegres 最适合以下场景：
- 验证自然语言是否能成为某类内部工具的主要接口。
- 快速制作数据探索、原型管理后台或一次性分析工具。
- 研究模型如何维护带有上下文的结构化状态。
- 测试“数据库协议”和“数据库实现”之间到底有多大距离。
它不适合直接承载支付、库存、权限、账务或高并发写入。凡是要求精确一致性、可审计变更和稳定延迟的系统，都应把 Claude 放在数据库之外，作为解释器、规划器或辅助运维组件。
一个更稳妥的落地路径是分层：让 Claude 负责把自然语言转换成受限的操作计划，让应用代码验证计划，再由 PostgreSQL 执行最终写入。这样仍然能获得自然语言交互，却把事务、约束和恢复交还给专门为此设计的系统。
结语：实验可以激进，边界必须清楚
“Claude 作为整个数据库后端”听起来像是对成熟数据库工程的挑衅，但它真正提供的是一个很有价值的压力测试：数据库的哪些部分只是历史包袱，哪些部分则是可靠软件不可省略的基础设施？
claudegres 的答案还不需要立即成为生产方案。开发者可以先检查四件事：
- 模型是否只处理低风险、可回滚的数据。
- 状态是否有确定性的校验和持久化层。
- 请求是否允许审计、重放和故障恢复。
- 关键写入是否仍由真正的数据库和事务机制完成。
当这些边界被明确后，Claude 可以成为数据库体验的一种新入口；在边界消失之前，它更像一场聪明而危险、但非常值得观察的系统实验。