最近"CLI 化网站"这个方向突然热了起来。港大的 cli-anything、卡比卡比写的 opencli、还有 bb-browser，三个项目实现思路各有侧重——有从前端源码逆向接口的，有通过 Chrome 插件在运行时探测网络请求的——但最终目标高度一致：把网站原本给浏览器用的 API，重新包装成给 AI 调用的 CLI。
从用户视角看，这类工具最直接的价值是打通 C 端孤岛。各个平台的数据和操作，不再被 GUI 困在浏览器里，而是能被脚本编排、被 AI 驱动、被流水线串联。对于做互联网运营的人来说，这类工具确实是如虎添翼。
反制与猫鼠游戏
对于主动建数据孤岛的互联网公司来说，这当然不是什么好消息。最近国内的平台已经在认真研究怎么识别 CDP 指纹、怎么检测自动化行为、怎么封号了。我猜用不了多久，C 端系统的普遍行为范式会变成：检测到你的浏览器挂着 bridge 插件、开着 remote debug 端口、或者 headless 特征过于明显，就先弹个确认框，要求你关掉才能继续访问——就像现在一些平台检测到 VPN 就拒绝服务一样。这场猫鼠游戏会越打越复杂，反制手段也会越来越精细。
到时候如果应验了，记得回来 at 我。
但这篇文章真正想聊的，不是 C 端的攻防，而是另一个更值得关注的方向——把 CLI Everything 的理念用在内部系统上。
散装基础架构：大多数公司的真实处境
除了头部的大厂，大多数中小公司的内部基建说实话都挺惨。监控系统、日志平台、代码仓库、CI/CD、工单系统、配置中心……每个系统都是独立部署、独立 GUI、独立登录，彼此之间几乎没有任何自动化互联。干活的人每天像在拼乐高，把这些散装积木用复制粘贴和肌肉记忆强行黏合在一起。
一个典型的排障流程是这样的：
- 监控告警触发，打开 Grafana，找到异常时间段
- 复制时间戳，切到日志系统，手动输入 traceId 搜索
- 找到关联请求，复制服务名，切到代码仓库，翻对应版本
- 发现疑似问题，想看最近的发布记录，切到 CI/CD 系统
- 中途来了条消息，复制 traceId 的剪贴板被 2FA 验证码覆盖，从头再来
这不是极端案例，这是绝大多数公司工程师每周都在经历的日常。
CLI 化之后，世界会不一样
如果我们把这些内部系统都 CLI 化——每个系统暴露出稳定的命令行接口——再加上 AI 作为中间层，整个协作方式会发生质变。
# 把刚刚这个分支部署到测试环境
cli deploy feat/add-feature-for-user-avatar --env staging
# 查看这次部署的构建日志
cli ci logs --branch feat/add-feature-for-user-avatar --last
# 生产环境出了告警，让 AI 自动采集现场
cli diagnose --alert-id ALT-20240312-0042 --attach-code
AI 排障的场景尤其典型：AI 拿到告警信息之后，自动通过 CLI 从监控系统拉指标、从日志平台捞 trace、从代码仓库关联最近的变更记录、从 CI/CD 系统查对应的发布历史，最后结合代码上下文给出分析结论。整个过程不需要工程师在五个系统里反复横跳，也不需要手动对齐时间窗口。
下面再展开几个更具体的场景：
场景一：跨系统的权限变更审计
安全团队想知道过去一周有哪些账号做了生产环境的权限变更，并且关联了哪些工单。传统方式要分别去权限系统、堡垒机日志、工单系统三个地方查，然后手动 Excel 对表。CLI 化之后，一个命令加 AI 分析，三分钟出报告。
场景二：发布前的影响面评估
开发提了一个 PR，想知道这次改动会影响哪些下游服务、哪些接口的调用量较高、历史上类似改动有没有引发过告警。以前这种评估要么凭经验靠感觉，要么拉一堆人开会对齐。CLI 化之后，AI 可以自动查代码依赖图、调用链路、监控历史，给出一份结构化的影响面分析。
场景三：成本异常溯源
云账单突然涨了 30%，但没有人知道是哪个业务、哪次变更导致的。把云厂商账单系统、Kubernetes 资源用量、CI/CD 发布记录都 CLI 化之后，AI 可以自动做时序关联，把成本突增和具体的发布事件对应起来，而不是让财务和技术来回甩锅两周。
场景四：新人 onboarding
新同学入职，想了解某个核心链路是怎么工作的。以前要靠老人口耳相传、翻过时的 Wiki、或者自己一个一个系统去摸。CLI 化之后，AI 可以主动从代码仓库、调用链路、历史告警、变更记录里拼出一份"活的文档"，而且永远是最新的。
对基础架构团队的影响
在 CLI Everything 到来之前，跨系统的需求往往是这样被处理的：需求方提工单，基础架构团队以"排期满""优先级低""技术方案不成熟"为由拒绝或无限期推迟。双方都在这套低效的博弈里内耗，真正的需求被淹没在协作成本里。
但 CLI 化一个内部系统的 API，调试到稳定可用，现实的时间成本大概是半天到一天。这个事实，让"我们没有资源支持"这类回答在技术上变得站不住脚。
这并不是说基础架构团队要消失——相反，真正有能力把系统设计得"可 CLI 化"、接口语义清晰、权限模型合理的人，会变得更有价值。但那些靠着信息壁垒和 GUI 垄断来维持话语权的角色，确实会越来越难立足。
主动拥抱这个趋势，把自己负责的系统做成其他团队真正能用的工具，才是在这个时代里继续有意义的方式。
CLI 的归宿：统一框架 CLI
当公司内部的系统一个一个被 CLI 化之后，新的问题随之而来：这些 CLI 散落在哪里？谁来维护？怎么发现？怎么升级？
如果没有统一管理，最终的结果可以预见——每个团队各自维护一套命令行工具，命名风格不一致，认证方式各不相同，有的用 pip 装，有的要去内网 Wiki 找个二进制手动下载，有的文档已经半年没更新了。这和 CLI 化之前的 GUI 散装状态，本质上没有任何区别，只是从散装 GUI 换成了散装 CLI。
解决方案是：公司内统一的框架 CLI。
类比已经有了，而且就在我们身边——AWS 有 aws，GCP 有 gcloud，Azure 有 az，Kubernetes 有 kubectl，Heroku 有 heroku。这些工具的共同点是：一个统一入口，子命令按系统/资源维度组织，认证统一管理，版本统一升级，文档统一查询。
公司内部的统一框架 CLI 也应该遵循同样的逻辑：
# 统一入口，子命令按系统组织
corp deploy feat/add-avatar --env staging # CI/CD
corp logs --service user-api --trace abc123 # 日志系统
corp alert list --severity critical --last 1h # 监控
corp repo diff HEAD~1 --impact # 代码仓库
corp iam grant user@company.com --role staging-read # 权限系统
所有命令都在同一个二进制下，认证只需要做一次（SSO/LDAP 打通），权限模型统一收口，升级也只需要一条命令。
统一框架 CLI 带来的真正价值
可发现性。 工程师不需要去问"这个系统有没有 CLI"、"CLI 装在哪里"。corp --help 或者 corp <tab><tab> 就能看到公司内所有已接入系统的能力，自动补全即是文档。
统一的认证与鉴权。 散装 CLI 最头疼的问题之一是每个工具都有自己的 token 管理，有的 token 三个月过期，有的永不过期，有的存在 ~/.config 里，有的要设环境变量。统一框架 CLI 只需要维护一套身份上下文，权限变更在 IAM 侧收口，CLI 本身不持有任何长期凭证。
AI 的统一调用层。 这才是真正关键的一点。当所有内部系统都通过同一个框架 CLI 暴露能力时，AI Agent 只需要学会一套工具调用规范，就能操作公司内所有系统。不需要为每个系统写单独的 tool definition，不需要担心不同 CLI 的输出格式差异导致解析失败。框架 CLI 可以在设计层面保证：所有命令支持 --output json，所有错误码语义一致，所有操作有统一的 dry-run 机制。这让 AI 驱动的自动化从"能用"变成"可靠"。
审计与合规。 所有通过框架 CLI 执行的操作，天然有统一的审计日志入口。谁在什么时间对哪个系统做了什么操作，一条链路全部可查。这对于金融、医疗、或者任何有合规要求的公司来说，价值不言而喻。
框架 CLI 的演进路径
不需要一开始就做成大而全的平台。实际上合理的演进路径是：
第一步：先做规范，后做框架。 定义好子命令命名规范、输出格式约定、错误码语义、认证接入方式，让各团队按规范独立开发自己系统的 CLI 插件。
第二步：框架提供脚手架和公共能力。 认证、日志、配置管理、输出格式化这些横切能力由框架统一提供，各团队只需要实现业务逻辑。
第三步：插件注册与发现。 类似 kubectl 的 plugin 机制，各团队发布的 CLI 插件注册到内部的插件仓库，corp plugin install monitoring 即可安装，升级也统一管理。
第四步：AI 集成层。 当所有系统都有了稳定的 CLI 接口之后，在框架层统一生成 tool schema，暴露给内部 AI Agent 调用。
这个路径的好处是：每一步都有独立价值，不需要等整体完成才能产生收益，也不会因为某个系统迟迟没有接入而阻塞整体推进。
CLI 孤岛，还是 CLI 联邦
最终，散装 CLI 和统一框架 CLI 的区别，类似于微服务时代"散装服务"和"服务网格"的区别：单个服务可以独立工作，但只有统一的治理层出现之后，整体才能作为一个可靠的系统来运转。
统一框架 CLI，就是内部基础设施的服务网格——它本身不提供任何业务能力，但它让所有业务能力能够被可靠地发现、调用、审计和组合。
这也是 CLI Everything 这个趋势最终要落地的地方。单个系统的 CLI 化是战术动作，统一框架 CLI 才是战略基础设施。
CLI Everything 不是技术炫技，是一种基础设施的哲学：系统的价值不在于它有多好看的界面，而在于它能不能被其他系统、其他工具、其他智能体低成本地组合和调用。
这个标准，正在重新定义什么叫做"做好了一个系统"。
