真实有效的 AI 方法论：02 拥抱 CLI + Skills

这是「真实有效的 AI 方法论」系列的第二篇文章，重点聊聊 CLI 和 Skills 这两个核心概念。

背景：CLI 和 Skills 在我们公司的落地

我们公司目前在运维周边组件上全面接入了 CLI 和 Skills，涵盖代码管理（CodeUp）、持续集成（Jenkins）以及各类辅助工具。这对整个运维板块是一次全面的效率提升。

举个例子： 以前发版的时候，需要在监控网页上逐个点击，再去找到对应的项目。到了项目后期，公司往往有几十个项目，而每个项目的代码文件夹名称、代码仓库名称以及 Jenkins 发布名称可能都不一样，查找和发布起来非常困难。还有一些场景，比如前端引入了新包、后端引入了 Python 的 Celery，都需要勾选特定的选项（比如重启），人工操作不仅繁琐，还容易出错。而使用 CLI 和 Skills 则是更高效的解决方案。

什么是 CLI？

CLI（Command Line Interface）相当于新时代的一种接口。它不是通过 HTTP 这类格式调用的，而是直接通过命令行调用。无论是 Windows、Mac 还是 Linux，CLI 基本上都是基于 NPM 打造的。

我们公司自己做的就是一个 NPM 包------你只需要安装相关依赖，通过 NPM 安装这个包之后，配置好环境，就可以直接用命令行的方式控制 Jenkins、CodeUp 这些工具，不用再在电脑上到处点点点了。

什么是 Skills？

Skills 其实是 CLI 的说明书。

如果把 CLI 比作接口，它只有出参和入参，所有的使用方式都需要通过 --help 命令查看。这对人工来说比较麻烦，而且 CLI 本身更多是给 AI Agent 使用的。配合 Skills，就可以开发出各种各样实用的工具。

Skills 主要有两种使用场景：

为重点命令编写独立说明 ------比如 Jenkins 发布到 develop 环境、查看项目状态等场景，都可以在 Skills 中明确说明具体的操作方式。这样 Agent 在使用时，就不需要每次都调用 --help 去翻找信息了。
搭建自定义工作流------比如在发布场景中，你可以设置发布前先将所有代码合并到 develop 分支并推送到远程仓库。通过 Skills 做一层封装，标明第一步干什么、第二步干什么、第三步干什么，然后整体打包成一个发布流程。调用 Agent 时，一句简单的命令就能让 AI 在内部完成一整套集成。

真实业务场景：反馈系统的 CLI 化

除了运维工具，CLI 和 Skills 在公司内部业务系统中也大有可为。而且这类工具不需要手动编写，直接让 AI 帮你完成就好，非常方便。

痛点：被吐槽的任务系统

我们公司内部的任务系统之前用的是钉钉的 Teambition。真正用过的人都知道它有多难用------我之前用过 TAPD、JIRA，都没有 Teambition 难用。它最让人头疼的就是没有全局 ID，无法有效查询和检索。每次创建分支都特别痛苦，自动生成的 ID 无法作为全局标识使用。项目多了之后，分支命名、发版合并都让人非常头疼。按照标准化流程，直接用一个全局 ID 来统一管理就好了，用 ID 关联代码分支和需求内容，用一套体系来完成相关操作。

解决方案：自建反馈系统 + CLI

后来我们自己开发了一套反馈系统，供业务人员提交反馈内容。那这和 CLI 有什么关系呢？

当客户或公司内部员工提交反馈后，需要专人处理。以前处理时，还要手动打开网页、查看上传的图片和评论区内容，效率非常低。

有没有办法让我直接在 Codex 里完成这一切？ 读取完整的反馈内容和消息，自动创建分支、自动参与讨论、编写符合需求的代码，还能自动在反馈系统里更新进度和评论，上线后自动处理任务状态？

当然可以。这就是 CLI 和 Skills 在真实业务中的应用场景。

具体实现

比如我想查看某个反馈 ID 对应的所有信息（评论、图片、视频、图文介绍等），可以编写一个与反馈系统对接的 CLI：

搭建一套完善的系统，让每个用户在系统里创建密钥
将密钥配置到本地 CLI 中
本地 CLI 调用接口和对应 ID，直接获取相关信息
Claude Code 拿到信息后，可以和我一起讨论，确定方案后完成代码编写和上线

修改和更新状态的流程也是同理。CLI 本质上就是一种非常高效的结构------你输入的命令相当于参数，执行后返回响应结果，AI 可以非常方便地调用它。

配套 Skills：针对不同场景定制流程

在 CLI 的基础上，还可以为不同场景编写专门的 Skills：

Bug 处理流程：

查清 bug 的原因
结合代码和线上数据库的 MCP 定位问题
撰写 bug 报告
提交评审
评审通过后出方案继续开发

需求类反馈处理流程：

调研反馈系统里所有类似的需求场景
梳理可复用的相似需求
对当前需求做优先级评级（高/低）
大致出解决方案、估算工时
制定开发规划

这是两种完全不同的流程，可以分别编写对应的 Skills 来应对。

拓展：面向外部系统的 AI 化改造

除了内部系统，我们也在针对一些外部系统做类似的优化。它的本质不一定是 CLI 和 Skills，但原理非常相似。

我们目前在做的规划，就是准备把自身的 APP 全部做成类似豆包那样的页面------一个聊天框界面，所有的场景和功能都可以通过对话的方式去了解、操作和执行。当然，之前的 GUI 页面也完整保留。我们用 Dify 搭建了一套工作流，目标是把整个入口用大模型封装起来，尽量不让用户再去操作那些需要到处点点点的复杂场景。用户只需要一句话，就能解决一个特定的问题。

展望：CLI 和 Skills 可能比我们想象的更重要

大家已经逐渐意识到 CLI 和 Skills 的重要性了，但可能还缺少一点直观感受------这个东西很有可能会像互联网的 HTTP 协议一样广泛。

CLI 可能成为新一代后端接口的规范

前端可能不再需要手动编写页面，根据 CLI 返回的结果，让 AI 针对性生成特定页面就足够了
大部分场景中，你只需要执行某个操作，AI 就会将相关信息查询出来并可视化展示
在需要用户确认时，AI 自动生成 GUI 页面来完成确认操作

仔细想一下，很多确认步骤对应的页面其实没有必要存在。

以点外卖为例

传统流程：领券 → 翻找菜品 → 选店铺 → 查看菜品 → 下单 → 付款。这些前置步骤大多是可有可无的，你真正关注的其实只有菜品、送达时间和金额这三样。

如果美团接入了优秀的 CLI，你直接语音告诉 AI 想吃什么，它就会自动帮你挑选商家、填好地址、告知总价，你只需要直接付款即可。有时候点外卖确实要花十几分钟挑选，但有了这样的工具，效率会大幅提升。

未来软件的新形态

这个概念很有可能是未来软件的新形态------不再依赖各种庞大的 APP 和大量的手动操作。阿里的通义千问已经在内部打通了淘宝、飞猪、高德等服务，你可以通过千问同时调用所有这些服务。虽然目前千问的体验还不够好，模型能力和调用准确性还有待提升，但我认为它已经是未来软件的雏形了。

我个人坚定地认为：未来的软件只是由大模型包裹的外壳，内置了大量的 Skills 供你调用。未来的软件生态都会是这样的模式，而不再是以页面为主、需要到处点击操作的场景。

所以，CLI 和 Skills 非常重要，甚至比我们预想的还要重要。

总结

如果你的公司有相关的业务场景------不管是公司内部业务、运维相关，还是自身软件的开发------都可以尝试往 CLI + Skills 这个方向靠拢。这绝对是未来的趋势。