最近做了一个挺有意思的小工具：aliyun cli skills。

核心想法很简单：
既然阿里云已经有了成熟的 Aliyun CLI，那很多云平台运维动作，本质上其实就是：

理解用户想做什么
找到正确的 product + operation
拼出正确的 CLI 参数
执行命令
处理返回结果

换句话说：把自然语言转换成 CLI 命令。构建请求体

而恰好，这件事情很明显是在大模型非常擅长能力范围覆盖之内。

起因：一次内部工具设计

这个 skills 的诞生其实挺偶然的。

最早我是在做一个内部工具，目标是给 百炼知识库做自动打标。
当时在设计 API 工具能力，希望通过 skills 的方式，让 AI 能够自动调用一些平台能力。

在做工具集成的时候，整体代码使用qoder和codex很快完成整体框架，大部分时间都是花在了API的调试中：

突然想到其实很多sdk能力好像都可以通过已经有的 aliyun cli，那是不是很多阿里云运维动作，本质上都可以理解为
构建一条 CLI 命令，然后执行？

再进一步想：

CLI 本质就是 OpenAPI 的一个封装
参数结构已经是结构化的
help 文档本身就是机器可读的
命令执行结果也是结构化 JSON

而这些恰好都是 LLM 非常擅长处理的东西。

于是就有了这个想法：
做一个 skill，让 AI 模拟用户使用 aliyun cli。

不知道命令？
那就去查 --help。

命令用得多？
那就沉淀到 examples 里。

就这样一个SKILL开始了。

这个 skill 在做什么

aliyun cli skills 的目标很直接：

把用户请求转换为可执行的原生 aliyun CLI 命令并运行。

它支持的范围包括：

OpenAPI 调用
aliyun <product> <operation>
credential / profile 管理
aliyun configure ...
OSS 操作
aliyun ossutil ...
TableStore 操作
aliyun otsutil ...

也就是说，它不仅可以做资源查询，还可以做资源变更、对象存储操作、配置管理等。

核心设计思想是：

Aliyun CLI 是第一来源。

模型不是靠记忆命令，而是依赖 CLI 本身的帮助系统。

一个简单的工作流程

整个 skill 的工作流程其实很清晰。

1. 判断请求类型

先识别用户想做的事情属于哪类：

类型	命令
凭证 / profile 管理	`aliyun configure`
OSS 操作	`aliyun ossutil`
TableStore	`aliyun otsutil`
OpenAPI 产品	`aliyun <product> <operation>`

例如：

ECS → aliyun ecs
VPC → aliyun vpc
RAM → aliyun ram

2. 建立当前执行上下文

例如查看当前 profile：

aliyun configure list

查看某个 profile：

aliyun configure get --profile default

如果用户指定了 region 或 profile，后续命令就显式带上。

3. 先查 help 再写命令

这里是最重要的一点。
不要猜命令，而是：

aliyun --help
aliyun ecs --help
aliyun ecs DescribeInstances --help

先从 CLI 获取真实语法，然后再拼命令。
这样可以避免模型记忆错误导致的命令错误。

4. 映射用户意图

大多数 API 名字都有规律：

用户意图常见 Operation
查询 Describe / List / Get
创建 Create / Run
修改 Modify / Attach
删除 Delete / Remove
停止 Stop
释放 Release

模型只需要把自然语言映射到这些 operation。

5. 输出可审查命令

例如：

aliyun ecs DescribeInstances \
--region cn-hangzhou \
--output table

命令保持：
• 可复制
• 可审查
• 可直接执行

而不是隐藏在系统内部。

为什么用 CLI 而不是直接调 SDK

很多人第一反应会问：

为什么不用 SDK / OpenAPI？

原因其实很简单。

CLI 本身就是运维语言

真实运维场景里，大多数人最后还是会：
• 查 CLI 文档
• 写命令
• 跑命令
• 看输出

所以让 AI 输出 CLI，本身就是最自然的形式。

CLI 调试成本低

一条命令例如：

aliyun ecs DescribeRegions

一眼就能看懂。

如果 AI 在背后拼一个 SDK 请求体，其实更难排查。

CLI 自带活文档

CLI 的 --help 本身就是实时文档。

这意味着模型：
• 不需要记住所有 API
• 可以通过 help 动态发现命令

这对长期稳定性非常重要。

我测试过的一些场景

目前已经测试过几个比较典型的场景。

场景一：自然语言开一台 ECS

例如用户说：

帮我在杭州开一台 2C4G ECS

skill 会：

1.    查 ecs RunInstances
2.    查 help 获取参数
3.    组装 CLI
4.    执行创建

最后返回xiang qin。

场景二：释放 ECS

用户说：

释放一台 ECS

skill 会：

1.    查实例列表
2.    找到目标实例
3.    执行 ReleaseInstance

场景三：自动加入安全组

这是我比较喜欢的一个场景。

用户说：

把我当前公网 IP 加到这台 ECS 的安全组

流程是：

1.    查询公网 IP

curl cip.cc

2.    查 ECS 安全组
3.    查当前安全组规则
4.    执行 AuthorizeSecurityGroup
5.    回读确认规则

这就是一个完整的运维闭环。

自优化机制

这个 skill 还有一个小设计：

如果 AI 发现某些命令模式很好用，可以沉淀到：

example.md

这样常见场景就会逐渐积累，一种变相的进化。

这种技能真正改变的是什么

我后来复盘这件事的时候，有一个感觉越来越明显：

重点不是 AI 会不会写命令。

而是：

用户和云平台的交互终于可以被自然语言“说出来”。

以前流程是：

用户 → 文档 → CLI → 命令 → 资源

现在流程是：

用户 → 自然语言 → AI → CLI → 资源

CLI 没变，OpenAPI 没变。

只是入口变了。

关于安全的一点建议

最后说一句很重要的事情。
这种 skill 虽然好用，但安全永远是第一位的。
因为一旦 AI 具备执行 aliyun cli 的能力，本质上它就拥有了一把可以操作云资源的入口。
在实际使用时，不建议直接使用主账号 AccessKey。

更推荐的做法是：
• 创建 RAM 用户 / RAM 角色
• 使用独立 AccessKey
• 按实际需求做最小权限授权

例如：
• 只查询 ECS → 只给 Describe 权限
• 只操作某个资源 → 限制 Resource Scope
• 不需要删除资源 → 不给 Delete / Release 权限

这样即使 skill 出现误操作，风险范围也会被控制在最小。

能用 RAM 就不要用主账号，能最小授权就不要给大权限。
自然语言让云平台交互变得更简单，但操作门槛降低之后，权限边界必须更严格。

未来的一点预期

aliyun cli skills 其实就是一个很朴素的想法：让 AI 学会像运维工程师一样用 CLI。

它没有改变云平台的底层结构，也没有重新发明一套 API，只是给现有的 aliyun CLI 加了一层自然语言入口：你用人话描述目标，AI 去查本地 help、拼出可执行命令、再把结果跑出来并整理清楚。

一旦这种方式在真实环境里跑通，大模型和云平台 API 之间就获得了一种“可验证的连接”。模型可以通过 CLI 去读文档、去试参数、去验证执行结果；而这些过程沉淀下来的产物，本质上就是一份份可复用的 CLI 请求体。再往前走一步，这些请求体天然可以映射到 SDK 调用和更上层的代码实现。

如果这条链路成立，未来云平台 API 的命令探索、参数对齐、调试验证，可能很大一部分都可以交给大模型来接管——这会是一次很实在的生产力提升

文档：

- 开源skill: https://github.com/felixzhang-glitch/skills/tree/main/aliyun-cli
- aliyun cli: https://help.aliyun.com/zh/cli/what-is-alibaba-cloud-cli

用自然语言对话云平台：aliyun-cli skills 的一次尝试