中后台的下一站，是 CLI 和 Skill

最近看后台表单看得有点烦。

不是某个页面特别难用，也不是哪个组件库又做出了奇怪的交互。烦的是另一件事：很多后台看起来模块很多，拆开以后其实都在重复同一种动作。

打开列表，点新增，填名称、时间、范围、优先级、预算、素材、跳转地址，保存，提交审批，等生效。换一个业务模块，字段变了，流程没太变。再换一个技术配置平台，也差不多：改开关、调阈值、选环境、看 diff、发布、回滚。

中后台当然不是只有表单。它有列表、图表、审批流、权限、导入导出、日志、数据看板。但真正高频的操作，最后经常还是回到那几个朴素动作：

读一批数据，改一批配置，触发一次任务。

说得再直白一点，很多中后台就是给接口套了一层人能操作的壳。

这层壳过去非常有必要。不能让运营拿着 curl 改活动，不能让客服连数据库改状态，也不能让业务同学记几十个接口参数。页面把风险挡住，把字段摊开，把权限和校验加上，让人至少知道自己在干什么。

但 AI agent 出现以后，这个前提有点变了。

页面还是要有，但页面不该是平台能力唯一的入口。

English version: The Next Step for Admin Platforms Is CLI and Skill

后台是在保护人

我以前做后台时，对表单复杂这件事还算宽容。

一个活动配置页有几十个字段，并不一定是产品经理作恶。活动本来就有时间、库存、渠道、人群、素材、预算、风控、灰度和兜底。页面如果不把这些东西摊开，人就更容易出事故。

很多看起来啰嗦的后台，其实是在保护操作人。

它把“这个字段不能为空”“这个城市不能投”“这个预算要审批”“这个资源位不能同时挂两个活动”写进页面和后端校验里。运营点得慢一点，总比线上活动配错强。

问题是，这套设计默认了一件事：所有细节都要由人一步一步完成。

在没有 AI 的时候，这个默认没什么毛病。人不填表，谁来填？人不点发布，谁来发布？但现在 agent 已经可以读文档、读接口、生成参数、跑命令、看结果，再让人确认。继续把所有能力都藏在页面后面，就有点浪费。

更尴尬的是，让 agent 操作 GUI 往往很别扭。

按钮在哪、弹窗有没有出来、表格滚动到哪一页、字段是不是被折叠了，这些对人来说是界面问题，对 agent 来说是噪声。它不需要一个精致的侧边栏，也不需要一个 8px 圆角的按钮。它更需要一个稳定的入口：

ops campaign preview --id 123 --format json
ops campaign publish --id 123 --dry-run
ops campaign rollback --id 123 --reason "库存配置错误"

这类命令不好看，但它适合机器读，也适合人查。

CLI 比页面更适合 agent

开发工具领域已经把这件事演示过很多遍了。

git status、pnpm test、kubectl get pods -o json、gh pr create 这些命令没有什么产品包装，但 agent 用起来很顺。原因很简单：输入是文本，输出可控，失败有退出码，过程能记录，命令之间还能串起来。

中后台如果只是给人用，GUI 是最自然的选择。

但如果后台也要给 agent 用，CLI 就很难绕开。

CLI 的好处不是“高级”，而是足够土。它可以被 shell 调，可以被 CI 调，可以被日志系统记录，可以在本地复现。出了问题，不需要回忆“我当时点了哪个按钮”，而是能看到哪条命令、哪个参数、哪个 request id、哪次审批。

这对后台很重要。

后台操作通常不是玩具。一个配置可能影响活动收入，一个开关可能影响用户路径，一个策略阈值可能影响风控。agent 可以执行，但执行过程必须留下痕迹。CLI 在这件事上比 GUI 自动化靠谱得多。

所以我越来越觉得，中后台未来应该有两套入口。

GUI 给人看，CLI 给 agent 跑。

不是互相替代，而是分工。

运营确认方案，不是填字段

这里还有一个更大的变化：运营到底应该负责什么。

现在很多后台流程里，运营承担了太多机械工作。业务目标是“做一个五一活动”，最后落到后台里，变成填写一堆字段，复制一堆素材地址，对照文档检查一堆开关。

人真正应该判断的，其实不是每个参数怎么拼。

人应该确认的是方案：活动给谁看，什么时候开始，预算有多少，库存够不够，会不会和别的活动冲突，出问题怎么停，哪些动作需要审批。

至于这个方案最终要创建几条记录、调几个接口、同步几个系统，完全可以交给 agent 做。

更合理的流程应该是这样：

运营说目标，agent 生成配置方案；
CLI 跑 dry-run，列出会改什么；
人看影响范围、风险和回滚方式；
审批通过后再执行；
执行完继续检查结果。

这不是把人踢出流程，而是把人从填表机器的位置上挪出来。

以前手工运维也是这样。一个人登录机器敲命令，后来变成脚本、流水线、审批、回滚。人还在，只是人不再负责记住每一个细碎步骤。

运营后台大概率也会走这条路。

Skill 才是经验

只有 CLI 还不够。

CLI 只能说明“能做什么”。但后台麻烦的地方，常常不在能不能调接口，而在什么时候该不该调。

比如创建活动这件事，命令可能很简单：

ops campaign create --name "五一活动" --city shanghai --start 2026-05-01 --end 2026-05-05

真正难的是别的东西。

新用户活动能不能和召回活动叠加？预算超过多少必须审批？灰度城市能不能直接扩到全国？资源位上线前要不要检查素材尺寸？改策略之前要不要先看上周数据？某个字段页面上能改，但老同事为什么总说“这个别碰”？

这些东西过去散在很多地方：PRD、飞书文档、群聊、页面提示、代码注释，还有一些说不清楚但大家都知道的经验。

这才是 Skill 应该接住的东西。

我理解的 Skill，不是把帮助文档换个名字。它应该更像一份操作规程：遇到这类任务，先查什么，再跑什么命令，哪些参数要停下来问人，哪些输出必须核对，失败以后怎么恢复。

没有 Skill，agent 只是会调用接口。

这很危险。

它可能知道怎么创建活动，却不知道晚上十点以后不能发某个渠道；知道怎么批量更新，却不知道更新前先导出；知道怎么改风控阈值，却不知道这个阈值背后挂着一条线上投诉链路。

后台真正该沉淀的，不只是页面和接口，还有这些带着坑味的判断。

技术配置平台也一样

这件事不只发生在运营后台。

技术配置平台也一样，而且可能更急。

AB 实验、网关路由、推荐策略、风控规则、权限系统、监控告警、CI/CD、任务调度、feature flag，这些东西表面上是给研发、算法、运维、数据同学用的工具，本质上也有大量配置动作。

很多平台最后都会走向一个熟悉结局：再做一个后台。

页面不是错。错的是只有页面。

技术平台的使用者本来就不怕命令行，平台也通常更重视 API、权限和审计。结果能力却被包在一个个页面里，agent 想接进来，只能绕路。

更现实的问题是，技术配置往往跨系统。

一次上线可能要改 feature flag，更新配置中心，刷网关，确认监控，挂告警，准备回滚。人靠经验在几个系统之间跳来跳去，agent 如果没有统一的 CLI 和 Skill，就只能靠猜。猜这种事，放在生产系统里听着就不吉利。

所以这个判断可以放宽一点：

凡是通过接口改配置、改数据、触发任务的平台，都应该考虑 CLI + Skill。

不一定一步到位，但方向值得定下来。

工具怎么选

落地时要分清楚场景。

如果平台本来就有稳定 API，尤其是已经有 OpenAPI，那么先从 API 契约生成 SDK 或 CLI 是最顺的。Speakeasy 和 Stainless 都有从 OpenAPI 生成 CLI 的能力。OpenAPI Generator 也能生成客户端代码，只是离一个好用的业务 CLI 还差一层设计。

如果没有稳定 API，或者面对的是现成软件、桌面工具、遗留系统，那可以看看 HKUDS/CLI-Anything。它更像是在给已有软件补一层 agent 能用的 CLI harness，而不是专门给后台接口生成 CRUD 命令。它强调 JSON 输出、测试、预览和 Skill，这几个点比“能不能自动生成命令”更重要。

MCP 也值得接，但我不想把 MCP 当成唯一入口。

MCP 是给模型接工具的好方式，CLI 则更像平台自己的操作面。CLI 能被人跑，被脚本跑，被 CI 跑，也能被 agent 跑。能力沉到 CLI 以后，再接 MCP 或其他 agent 平台都比较自然。

我现在更倾向的顺序是：

先把 API 契约整理清楚，再做 CLI，然后写 Skill，最后再接 agent 平台。

顺序不绝对，但最好别一上来就把能力绑死在某个模型平台里。后台系统的寿命通常比一代 agent 框架长。

登录别偷懒

CLI 一旦能改后台数据，登录和权限就不能偷懒。

最省事的做法，是给用户发一个长期 token，让他放到本地配置文件里。这个方案短期舒服，长期难受。token 泄露、权限过大、离职回收、审计对人，哪个都不是小事。

更靠谱的方式，是把 CLI 当成正式客户端。

本地能打开浏览器，就走 OAuth/OIDC 的 Authorization Code + PKCE。远程机器或无浏览器环境，可以考虑 Device Authorization Grant，也就是 device code flow：CLI 给一个短码，人去浏览器里确认。

token 尽量放系统 keychain 或凭据管理器，不要明文扔在项目目录。高风险命令只生成计划，不直接执行；或者必须带审批单、二次确认、影响范围和回滚方式。

权限也不能图省事。

运营能建活动，不代表能改风控。能灰度发布，不代表能全量上线。能回滚，不代表能删历史数据。agent 应该继承当前人的权限，而不是拿一个“超级运营”的万能账号到处跑。

这个边界如果守不住，CLI + Skill 就不是效率工具，而是事故加速器。

后台不会消失

我并不觉得中后台页面会消失。

相反，很多页面会变得更重要。

只是页面的重心会从“让人输入所有字段”，慢慢转向“让人看懂方案和风险”。AI 准备改哪些对象，影响多少用户，为什么这么配，审批到哪一步，执行后结果是否正常，这些都需要好的 GUI。

人不适合在一堆 JSON 里承担业务责任。真正要拍板的时候，页面仍然是很好的认知工具。

但那些高频、规则明确、可验证、可回滚的配置动作，不应该永远困在表单里。

以前做后台，是把接口包成页面，让人可以操作系统。

下一步更重要的，可能是把操作变成可审计、可授权、可回放的能力，让 agent 可以执行，让人负责判断。

GUI 继续服务人，CLI 服务 agent，Skill 沉淀经验，审批和审计兜住风险。

这套东西听起来不复杂，真正落地时肯定会有坑。命令怎么设计，权限怎么切，Skill 怎么维护，哪些场景允许自动执行，哪些必须停下来问人，都要一件件试。

我自己正好也有一个管理后台，后面应该会拿它做一轮实验。

如果跑下来证明这事只是想得美，那也值得记一笔。至少现在看，中后台继续堆表单的路已经不太够用了。AI 时代的后台，不该只给人点，也该给 agent 跑。