如何给 Claude 或 Cursor 写的应用加上管理后台

过去一年我见过几十次同样的模式，自己也亲身经历过：你打开 Claude 或 Cursor，描述一个应用，一个周末后你就有了一样真东西——电商站、预约工具、内容站、一个你念叨了好几个月的 SaaS。AI 写了前端、路由、表结构，全部。

然后到了没人给你准备的那部分：管理后台。

不是面向用户的那部分——那部分已经完成了。我说的是后台办公室。你用来批准退款、编辑商品、看这周谁注册了、修一条被人弄坏的记录、翻一眼昨天数据的那堆界面。如果你用 agent 构建的应用，你很可能一样都没有。你只有 agent 创建的数据库，里面堆着越来越多的真实数据，却没有好办法去看它。

这篇讲你在这个处境下真正有的选择，以及我反复回到的那个。

为什么 AI 构建的应用缺管理后台

Agent 构建应用时，它优化的是你要求的东西：面向用户的体验。它很乐意生成登录页、给你的客户用的仪表盘、结账流程、用户会碰到的部分的精致 CRUD。它几乎从不会生成（除非你明确要求）内部界面——你用来运营业务的那些界面。这不是 agent 的失败；人快速开发时也一样。管理后台无聊、不可见、容易拖延。「以后再建」变成了"以后"是六个月的手动改数据库。

与此同时你的数据库装满了要紧的东西：订单、用户、退款、工单、内容。每一行都是一个等着你做的决定——要发货的订单、要批准的退款、要发布的草稿。而你处理它们的唯一工具是一个 SQL 提示符，或一个只显示 status: "pending"、没有任何上下文的原始数据库客户端。

人们解决这个问题的四种方式（以及各自的代价）

我看过人们用四种不同的方式处理缺失的管理后台。都有效。都有代价。

方式一：手写 CRUD 界面

经典做法。你撸起袖子建一个路由文件、一个表格组件、一个表单组件，然后对你关心的每张表重复一遍。你职业生涯里大概已经干过一次——大多数内部工具在 AI 之前就是这么建的。

优点：完全可控。长成你想要的样子。不花钱给任何厂商。

缺点：花的是你的时间，而时间正是你用 agent 想省下的东西。每张表都是一套新界面。每次表结构变更都是一轮修改。对独立开发者来说，每个应用要花好几天——而这个应用本身才花了一个周末。给 AI 构建的应用手写管理后台，是用最贵的方式完成项目里最便宜的部分。

方式二：用框架自带的后台

Django 有 Django Admin。Rails 有 ActiveAdmin。Laravel 有 Filament。如果你的 agent 用了这些框架之一构建应用，你通常一个下午就能打开一个生成好的后台。

优点：它存在。它绑定你的模型，所以知道你的表结构。数据零离开你的机器。

缺点：它绑定框架。一旦你的技术栈不是 Django/Rails/Laravel——而很多 agent 构建的应用是 React + API + Postgres，或静态前端加 serverless 后端——就没有东西可以打开。而且框架后台是给开发者用的，不是给"批准这笔退款"这种工作流用的。你还是得定制。

方式三：用云后台 SaaS

Retool、Budibase、NocoDB 的托管版、Airtable——这些是打"几分钟搭好内部工具"广告的工具。把它们指向你的数据，它们就生成一个界面。

优点：快。精致。适合团队。

缺点：你把生产数据库凭证交给第三方，运营数据流经他们的服务器。对副业项目只是烦；对任何有真实用户的东西，是一场你不想做的合规谈话。而且你要永远按席位或按编辑者付费，为的只是一个本质上就是 CRUD 的界面——如果他们改价或停服，你的管理后台跟着消失。

方式四：连到你现有数据库的本地管理面板

这是我围绕它建了 Basevolt 的方式，也是我给自己用 agent 交付的每个应用实际使用的方式。它是一个桌面应用。你把它连到你应用已经在用的数据库——agent 创建的那个 PostgreSQL、SQLite、MySQL 或 Cloudflare D1 数据库。它原样读取你的表结构，不迁移、不导出，把它变成一个可用的运营面板：网格、看板、画廊、仪表盘、Webhook。

优点：数据永不离开你的机器。没有按席位定价，没有云账号。它直接用在已有的数据库上——不用迁移或重建任何东西。而且因为它架在同一个你应用在用的数据库上，面板里看到的和应用里用户看到的完全一致。

缺点：它是桌面应用，所以设计上是单人的——如果你需要五个人登录、在浏览器里编辑同一批记录，这不是那个产品。而且你需要自己连一下，大约一分钟。

改变我看法的那部分：让 Agent 来配置

让方式四真正成立的是这一点。你用 agent 构建了应用——为什么不让 agent 也构建管理后台？

Basevolt 在你机器上跑一个 MCP 服务器。写你应用的同一个 Claude 或 Cursor 可以连上它，替你配置面板：字段类型、表与表之间的关系、贴合你工作方式的视图。你说"给我配一个订单后台"，agent 读取你的表结构，替你做完本来要手动点的那些设置。

如果你在想"我已经可以让 agent 写后台代码了"，区别在这里：agent 配置 Basevolt 不是在生成重新实现你数据库的代码——它是在配置一个读取你数据库的面板。没有要维护的新代码，没有部署，没有会跟真实表结构脱节的东西。你的表结构变了，面板跟着反映。这就像生成一张房子的照片 vs 走进这栋房子。

配置过程（大约一小时，大部分是 agent 在干活）

让我用前面提到的商城应用当例子，走一遍实际流程。

第一步——连上 agent 创建的数据库。

下载 Basevolt，添加数据源，指向你应用用的同一个数据库。Postgres 是主机、端口、库名、用户名、密码。SQLite 直接选 .db 文件。它原样读取表结构——不迁移、不写配置文件。

第二步——打开 MCP，让 agent 配置面板。

打开 Basevolt 设置，启用 MCP 服务器，在 Claude 或 Cursor 里注册它（应用会给你显示每个客户端的准确配置）。然后在你的 agent 里说类似：

把商城数据拉进 Basevolt，给我配一个运营后台。客户要显示名字而不是 ID。状态要可读。我需要一个看板来看等待我处理的订单。

Agent 读取你的表结构、关联关系、给字段定类型、设置视图。以前我要花一晚上的点击，现在变成 agent 花几分钟替我做——而且它做的每一步我都能在面板里实时看到。

第三步——真正用它运营。

第二天早上，不再打开 SQL 提示符，你打开面板。等着你的订单是一块看板。待处理的退款是一个队列。昨天的数字是一个仪表盘。需要你决定的时候——批准、发货、退款——你点一个按钮，Webhook 把动作送到你现有的 API。这就是完整闭环：agent 构建了应用、配置了面板，你来运营。

诚实的权衡

我直说局限。如果你在给一个团队建内部工具——五个人需要登录、权限、共享的浏览器工作区——本地桌面应用不是正确答案，你该看 Retool 或自托管 NocoDB。如果你的应用真的没有任何管理面，比如没有数据库的静态站，那也还没有东西可以挂面板。

但针对那个越来越常见的*"我用 agent 建了应用，现在需要运营它"*的情形——有真实数据、没有后台的独立开发者——架在现有数据库上的本地面板是最快的路，让写应用的同一个 agent 配置它，闭环就完整了。管理后台是应用里没人想写的部分。用这个方式，你根本不用写。