但搭着搭着，我停了下来。我在想：这些页面做的事情无非就是在帮我调后端接口。那我为什么不直接让 AI 调接口呢？
所以我做了一个 Skills ，用自然语言去执行我的后台管理场景，替代了运营后台。
举个例子，我有一个 管理激活码的场景：
传统的运营后台模式： 我会有一个页面，里面有个表格展示所有的激活码及其剩余额度。右上角有个"创建激活码"的按钮，点开后填写表单，大概就是这样。
Skills 模式： 我做了一个 Skills 。使用时，我只需要告诉它："帮我生成一个 1000 分钟的激活码。"它就会根据我这句话里的目标去调用接口，使用对应的参数，最后把结果返回给我。
在这个过程中，我从"在页面上操作"转变为"用自然语言描述需求并得到结果"。
我发现这样做有两个好处：
1. 更简单
像我这种个人的小项目，再也不需要为了管理而专门搭建一个只有我自己用的应用了。
如果增加新功能，我不需要把接口和前端各开发一遍，只需要开发几个核心接口，然后在 Skill 里简单配几句话，就能使用新的管理功能。
2. 更强大
用 Skills 做管理除了更简单，上限也更高。
这一点，在我的产品里场景感受不明显，因为我的产品比较简单，但是放到一个复杂系统里就很突出了。
比如一个 ERP 系统中排查问题的场景：某个入库单数量不对，传统做法是我先打开入库单页面查详情，再根据关联的采购单号跳到采购单页面，再通过采购单追溯到采购计划，一层一层找到底哪一步出了问题。
而用 Skills 方式的话，我只需要说"入库单 XX-001 的数量跟实际不符，帮我查一下哪里出了问题"，它就会沿着入库单→采购单→采购计划自动追溯，直接告诉我问题出在哪一环。
传统后台每个页面是孤立的，你得自己在页面之间跳来跳去拼凑线索。而 Skill 能顺着数据关系自动追溯，帮你串联信息。它不只是替你点按钮，它替你串联和判断。
再往深一层看，我觉得这背后原因是：以前开发资源有限，做一个新页面或新模块耗时很长，所以后台系统会更倾向于开发一个独立的功能，而非一个业务链路（因为业务链路复杂且多变，开发的 ROI 可能不高）。
传统的运营后台本质上是 "基于功能" 的。系统提供一个个基础功能，至于怎么把这些功能组合成一套完整的业务流程，全靠运营人员自己去串联和操作。
而如果使用 Skills 去操作业务的话，极大降低了开发难度，开发者只需要提供核心接口。很多后台页面可以不用再做。运营或产品 自己就能根据实际需求去编排 Skills ，把基础接口组合成 "基于业务" 的流程——既更高效，也更贴合真实场景。
但是老实讲，现在用 Skills 来做管理，确实还有些局限，比如：
数据可视化： 网页上可以看趋势图、看图表看板，但目前是在命令行里用 Skills 的话，界面没那么直观。
复杂的页面操作： 传统后台可能会有一些复杂页面不止是靠获取信息，调用接口就能实现业务的。比如要配置某个工单流转引擎，这种场景就比较复杂，光靠和 AI 交互 可能处理不清楚。
回到话题本身，我觉得针对小产品的管理场景。比如个人产品或者创业公司管理，我觉得 Skills+后端接口就够用了
至于大公司或者复杂的生产级系统，我觉得可以尝试用 Skills 把一些复杂流程串接起来，让它能快速操作，起到类似自动化的效果。
后台页面的本质是人和接口之间的翻译层。在 AI 能直接理解你意图的今天，这个翻译层对很多项目来说，可能已经是多余的了。
