别再让后端手写脚本了：我搭了一套可复用的企业 CLI 基座，命令扩展靠 YAML

Sat, 18 Apr 2026 12:00:00 +0800

内部工具越堆越多，每个新服务都要重新写一遍登录、鉴权、日志、错误处理。

新来的同事拿到一堆脚本，不知道哪个能跑、哪个已经废了。测试环境和生产环境的 token 混着用，一不小心就把测试数据写到生产。

这是我搭这套 CLI 基座的真实原因：不是为了让工程师更极客，而是为了把内部能力收敛成一个人和 Agent 都能调用的统一入口。

这个项目我已经用在企业内部，核心代码公开。看完你能照着自己搭一套。

一、我为什么把企业后台能力做成 CLI

先说判断。

GUI、API、CLI 这三层，很多企业只做了前两层：后台页面给人点，API 给系统调。但中间那层——对人足够友好、对脚本足够稳定、对 Agent 足够结构化——一直是空的。

后果就是：

业务同学要操作后台，点到手软
工程师要写脚本，每个脚本都重新处理一遍认证、日志、错误
Agent 要调用业务，得直接拼 API，参数错了都不知道怎么报错

CLI 正好卡在中间。

但企业 CLI 不是把几个 API 包成命令就完了。我搭这套基座时，核心就一个原则：稳定层先代码化，业务层再规格化。

什么意思？

认证、环境、HTTP 请求、Header 注入、打包发布——这些是稳定层，一次搭好，长期复用。

业务命令——这些是变化层，用 YAML 规格化，扩展时不改核心代码。

这样搭出来的 CLI，命令越多，扩展越快。而不是命令越多，代码越乱。

二、这套 CLI 基座的骨架

项目结构长这样：

.
├── cmd/ # Cobra 命令入口
│ ├── root.go # 根命令，加载 YAML 动态命令
│ ├── auth_login.go # 登录回调
│ ├── token_refresh.go # Token 刷新
│ └── oauth_injected.go # OAuth 凭据注入（构建时生成）
├── internal/
│ ├── auth/ # 认证层：登录、token、device_id
│ ├── httpx/ # 请求层：HTTP client、Header 注入、401 refresh
│ ├── runtime/ # 执行层：YAML 解析、Cobra 命令注册、请求执行
│ └── store/ # 存储层：profile、token 本地持久化
├── specs/
│ ├── groups/ # 业务命令规格
│ │ └── order/
│ │ ├── group.yaml # 订单组配置
│ │ └── commands/
│ │ └── list.yaml # 订单查询命令
│ └── embed.go # go:embed 把 YAML 编译进二进制
└── scripts/
 └── build-with-oauth.sh # 多环境、多平台打包脚本

核心分层：

工程架构 on Zampo Blog

别再让后端手写脚本了：我搭了一套可复用的企业 CLI 基座，命令扩展靠 YAML

一、我为什么把企业后台能力做成 CLI

二、这套 CLI 基座的骨架