把管理后台全部删掉之后学到的——AI 时代什么样的 UI 留得下,什么样的可以删
「既然能让 AI 直接改,管理后台是不是就不需要了?」——这个问题用一般性的断言回答不了,因为同一个词「管理后台」指的是一堆性质完全不同的功能凑在一起。本文基于把这个站点的管理后台整个删掉的亲身经历,把该问的问题换成一句更锋利的:这块屏幕提供的东西里,有没有 CLI 和 AI 还提供不了的部分?真的整个删过一遍才明白,被删掉的功能里大多数不是「没在用」,而是「结构上就是坏的」。文章的增删改查从造出来那天起就不可能工作,因为文章的事实源头在代码这一侧(seeder 加 HTML 文件),每次部署都会覆盖数据库,界面上改的东西下一次部署就没了。评论审核队列永远是空的,因为实现上提交时就打好了已通过审核的标记,未审核的评论根本不会出现。没人用的功能,连它坏了都没人看得出来。唯一删不掉的能力是删除评论,可即便是它也没有非管理后台不可的理由:把删除按钮放在文章页面本身反而更好,因为你正在读那条有问题的评论,当场就能删。判断最终落到六个问题上。谁来操作(非技术人员或会换人的岗位倾向于 UI,天天开终端的开发者则不必)。能不能撤回(不可逆的操作需要一道关卡)。需不需要人的判断(是否存在通过或驳回这种状态迁移)。需不需要分权限。知不知道能做什么(那份清单同时充当说明书)。有没有留下痕迹。其中权限和痕迹这两条,在个人开发时看上去毫无必要,却会在第二个人进来的那一刻最先变成必需品。经由代码的变更会进 git,但让 AI 直接写数据库默认什么都不会留下,而对话记录保存的是「你要求了什么」,不是「实际发生了什么」。六条轴里只有可逆性的分量不一样:2025 年 7 月 18 日,Replit 的 AI 代理在代码冻结期间删掉了 SaaStr 的生产数据库,凭空生成了 4,000 个虚构用户,并错误地声称无法回滚从而拖慢恢复(AI Incident Database #1152)——这个案例展示的与其说是 AI 的危险性,不如说是不可逆的操作不经过人的关卡就能够到的设计问题。文章还给出往 AI 与 CLI 挪之前要先备好的三件事(变更留得下形、不可逆操作前面有个台阶、步骤写成文档,因为删掉 UI 同时也删掉了「能做哪些事」的清单),一份动手做之前的检查清单,以及不自己手写、改用 Retool 或 Forest Admin 这类内部工具产品的第三个选项。