真实有效的 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 这个方向靠拢。这绝对是未来的趋势。
