用 Skills 代替运营后台页面

[artshooter]

我的产品上线后，和大多数开发者一样，下一步就准备搭运营后台。用来查看数据，做一些维护操作。
但搭着搭着，我停了下来。我在想：这些页面做的事情无非就是在帮我调后端接口。那我为什么不直接让 AI 调接口呢？
所以我做了一个 Skills ，用自然语言去执行我的后台管理场景，替代了运营后台。

---

举个例子，我有一个 管理激活码的场景：

传统的运营后台模式： 我会有一个页面，里面有个表格展示所有的激活码及其剩余额度。右上角有个"创建激活码"的按钮，点开后填写表单，大概就是这样。

Skills 模式： 我做了一个 Skills 。使用时，我只需要告诉它："帮我生成一个 1000 分钟的激活码。"它就会根据我这句话里的目标去调用接口，使用对应的参数，最后把结果返回给我。

在这个过程中，我从"在页面上操作"转变为"用自然语言描述需求并得到结果"。

我发现这样做有两个好处：

1. 更简单

像我这种个人的小项目，再也不需要为了管理而专门搭建一个只有我自己用的应用了。 如果增加新功能，我不需要把接口和前端各开发一遍，只需要开发几个核心接口，然后在 Skill 里简单配几句话，就能使用新的管理功能。

2. 更强大

用 Skills 做管理除了更简单，上限也更高。 这一点，在我的产品里场景感受不明显，因为我的产品比较简单，但是放到一个复杂系统里就很突出了。

比如一个 ERP 系统中排查问题的场景：某个入库单数量不对，传统做法是我先打开入库单页面查详情，再根据关联的采购单号跳到采购单页面，再通过采购单追溯到采购计划，一层一层找到底哪一步出了问题。

而用 Skills 方式的话，我只需要说"入库单 XX-001 的数量跟实际不符，帮我查一下哪里出了问题"，它就会沿着入库单→采购单→采购计划自动追溯，直接告诉我问题出在哪一环。

传统后台每个页面是孤立的，你得自己在页面之间跳来跳去拼凑线索。而 Skill 能顺着数据关系自动追溯，帮你串联信息。它不只是替你点按钮，它替你串联和判断。

---

再往深一层看，我觉得这背后原因是：以前开发资源有限，做一个新页面或新模块耗时很长，所以后台系统会更倾向于开发一个独立的功能，而非一个业务链路（因为业务链路复杂且多变，开发的 ROI 可能不高）。
传统的运营后台本质上是 "基于功能" 的。系统提供一个个基础功能，至于怎么把这些功能组合成一套完整的业务流程，全靠运营人员自己去串联和操作。

而如果使用 Skills 去操作业务的话，极大降低了开发难度，开发者只需要提供核心接口。很多后台页面可以不用再做。运营或产品 自己就能根据实际需求去编排 Skills ，把基础接口组合成 "基于业务" 的流程——既更高效，也更贴合真实场景。

---

但是老实讲，现在用 Skills 来做管理，确实还有些局限，比如：

数据可视化： 网页上可以看趋势图、看图表看板，但目前是在命令行里用 Skills 的话，界面没那么直观。

复杂的页面操作： 传统后台可能会有一些复杂页面不止是靠获取信息，调用接口就能实现业务的。比如要配置某个工单流转引擎，这种场景就比较复杂，光靠和 AI 交互 可能处理不清楚。

---

回到话题本身，我觉得针对小产品的管理场景。比如个人产品或者创业公司管理，我觉得 Skills+后端接口就够用了

至于大公司或者复杂的生产级系统，我觉得可以尝试用 Skills 把一些复杂流程串接起来，让它能快速操作，起到类似自动化的效果。

后台页面的本质是人和接口之间的翻译层。在 AI 能直接理解你意图的今天，这个翻译层对很多项目来说，可能已经是多余的了。

[journalistFromHK]

后台接口都写好了 大头都做完了 告诉 ai 怎么获取参数 哪些参数是必须的 类型应该是什么 还不如直接随便让 ai 弄个表单糊弄糊弄得了😏

[HotieCutie]

但是有页面，自己的记忆会非常深，知道要点哪里，要输入什么参数，而且还可以做参数提示，错误提醒，各种数据展示都很直观

[imagecap]

有调试 ai 的功夫，说不定人都已经搞完了。

[afstyle]

但是其实 AI 有时候受限于回复速度，展示内容效果不如直接 Web 页面点点点快速直接。比如我要查个东西，页面上点点点可能 2 秒就看到结果了，让 AI 去执行可能得 10 秒甚至更久。

[ynhao0o]

感觉这确实是一个很好的思路, 应该可以用在其他地方

[KinBob]

后端的接口也需要有一些技术背景才能学会用的，直接拿去给运营写 skill 怕不是给自己找更多的活

[op351]

对部分原生 web ，并且二次开发和 api 文档写的比较好的系统应该是不错的解决问题的思路
但这种系统好少
对 C 端系统或者 api 不开放的系统来说，RPA 加多模态模型做 GUI 自动操作，后续把操作流程部分或全部固化为程序脚本来加快操作速度并减少 token 使用应该也是不错的思路

[calming]

最大的问题是可能会污染很多数据,小系统还行,大系统一整个崩溃了

[abc0123xyz]

2 个问题

接口都好了，页面随便糊弄一下不就完了。
接口没好的话，直接给数据库只读账号，如果 ai 发癫数据搞错也不知道。

最重要的是 token 也要钱啊。

[ooee2016]

平行世界的另一位开发：咱们现在的系统中，每次运营有什么问题都需要自己描述问题，然后让程序去理解并处理，这样的话如果第一次提问程序误解了问题，就会导致后续很容易陷入错误的循环中。我发现了另一种模式，就是将系统数据抽象成一个一个的接口，系统中的数据都可以通过接口查询并展示到页面中，这样当你有问题的时候就可以一步一步的去不同的页面中查询数据，这样就可以直观的知道是哪里出现了问题。

[0x4b0082]

有点意思 真的有点 TUI -> GUI -> HUI 的路径的感觉了

[AnroZ]

很好的思路，基于当前的技术潮流，很多交互 UI 其实是可不需要了。不仅仅是后台管理，很多系统功都可简化人机交互界面了。

[artshooter]

@journalistFromHK
@imagecap
@afstyle
@abc0123xyz

我想了想，
在我的场景下，其实这个 Skills 不只是解决了我后台页面的代码开发问题，还解决的是一整套的前端系统 构建/维护 问题（路由、部署、登录等各方面）

如果要这个运营后台页面的话，我就得从头开始搭建 做一套新的前端出来。

用 Skills 的话，我只需要把核心接口做出来。通过自然语言去调用这些接口，就能完成大部分运营操作，相当于直接省掉了一整套运营后台的前端部分。

[artshooter]

@abc0123xyz
token 的钱好说。开掉一个前端就有了
（🐶狗头保命，我也是前端）

[abc0123xyz]

@artshooter #14
还有个问题是，怎么保证准确性。
接口吐出来的数据是准确的，ai 嚼了一遍之后吐出来，可不一定准确了。

数据不变的情况下，ai 嚼了一遍之后，不能确保每次吐出来的数据都是一致的。

[azhangbing]

已经做了 把我们几个后台全部扒了 现在直接发命令处理

[mosesyou]

可以加上 GenerativeUI,感觉在某些场景是思路是对的

[artshooter]

@KinBob 那就让 PM 去搞这些。


@ooee2016 技术圈～技术圈～技术是个圈🤪

不过 如果真要严肃讨论这个问题的话 -- “咱们现在的系统中，每次运营有什么问题都需要自己描述问题，然后让程序去理解并处理，这样的话如果第一次提问程序误解了问题，就会导致后续很容易陷入错误的循环中”

我会觉得，要解决这个问题 得继续往业务的上游去挖掘。
“运营在什么情况下需要这个数据？” “运营为什么要去做这件事情？” ...

拿 ERP 中的采购备货 举例，比如每年换季的时候 运营需要去创建 不同种类衣服的采购单。
运营下单的逻辑是依赖于“换季”这个备货策略的。

那么 有没有可能把 备货策略 到 下采购单这个过程中的逻辑整理出来，然后自动化处理。
再往上 有没有可能把 营销活动/打折促销/换季售卖 这些动作 到 备货策略的逻辑 也整理出来。
再往上 有没有可能把 “什么情况下需要去打折促销” “什么情况下需要去搞换季售卖” 的触发条件 也整理出来。

有点理想化🤣，但或许是个方向 hahhhhh

[tanxnative]

AI 最终改变的还是输入 和输出

[artshooter]

@abc0123xyz 是个好问题。我得想想🤔

[ano]

为了用 AI 而用 AI 。你这不是解决问题，是制造新问题。

[fengxsong]

还是 token 太富裕了

[nickfox5880]

@artshooter #14 如果能保证准确性的 当然可以
但是目前并不能的 按性价比来说 人更合适
等到准确性可以了 是不需要后端接口的 根据功能，拼接 sql 开放查询权限，直接查询就可以了

反正是未来趋势吧 但是现在做这些没有什么意义 时间还没到

[johnnyNg]

让 AI 写个运营后台也很快的吧

[momo1999]

> 如果要这个运营后台页面的话，我就得从头开始搭建 做一套新的前端出来。

这个 AI 不是分分钟就做好了吗。

[zangai]

解决了系统太稳定不需要维护的优点，解决了非技术无法批量消耗 token 的问题，利好算力股

[OrangeAdd]

感觉是个很不错的想法，后面模型在进化一下，稳定性感觉不是问题了😋