AI CLI 百万级项目部署实践分享

AI CLI 百万级项目部署实践分享

  • 使用 AI 的核心宗旨（最终目的）就是：全部用嘴说

  • 近几个月的心得体会几乎都在公司中标的这个项目中得到了实践，所以借着这个机会，写一篇阶段总结。

  • 现在使用 Claude Code CLI ，越来越少手动操作服务器、Word、Excel、飞书云文档等等，基本都是使用语音转文字输入法快速地把自己的思想通过语言说出来。一方面提高了表达的效率，可以给 AI 高质量、高信息密度的提示词。另一方面解决了因为手动打字太慢，本能选择最短路径而导致表达不清晰的问题（因为懒，只想打一两行字）。

环境说明

我使用的是 Claude Code ，还有其他的辅助编程智能体，比如 Codex ，使用方式都相同。

  • 个人笔记本：MacBook Air M1（需要能连接世界互联网）
  • Typeless 语音转文字输入法、豆包语音转文字输入法
  • Claude Code 账号
  • Claude Code CLI 工具
  • 生产环境服务器系统 Ubuntu 20.04 （2台）

AI 可以做什么

AI 智能体可以做哪些事情？

  • 操作本地电脑的各类文件：包括增、删、改、查。

  • 使用工具（CLI）：通过命令行下载各类已经写好的软件、小工具。如果市面已有的无法满足需求，那么 AI 会自己根据需求在本地环境编写代码完成任务。

  • 调用 API ：AI 能够快速阅读 API 文档，学会 API 的调用，完成相应的任务。

  • 命令行大师：熟悉所有命令以及其使用方法。

  • 语言大师：会所有的编程语言。“一言不合”就自己写工具来解决问题。

  • 百科全书：人类几千年总结的所有知识它全知道。

项目实战

服务器初始化

  1. 两台服务器到手之后，配置免密登录，然后由 AI 接管。（可以参考之前的文章： https://www.cnblogs.com/keepriding/p/20029144 ）

  2. 使用自然语言让 AI 登录服务器查看各项配置，汇总一下，初步了解服务器相关信息。

  3. 使用自然语言让 AI 配置磁盘挂载，挂载到 /data ；配置网络与 DNS。

  4. 使用自然语言让 AI 根据之前写的 Skill 优化系统环境。包括时间同步、防火墙关闭、Docker安装、内核参数调优、资源限制优化、history审计配置。（Skill 可以参考之前的文章： https://www.cnblogs.com/keepriding/p/20029144 ）

中间件数据库部署

  1. Claude Code CLI 切换到 Plan 模式，先收集信息定计划，然后再分步执行。（可以参考之前的文章： https://www.cnblogs.com/keepriding/p/19839809 ）

  2. 根据之前项目写的部署文档，让 AI 读取关于中间件数据库部署的部分。然后结合现在的服务器环境做对比，制定计划。几轮讨论之后，没问题就开始让 AI 执行。经过不长时间，MySQL、Redis、MinIO、Nacos、RocketMQ、Elasticsearch、Neo4j、Doris、MongoDB、Chroma 等中间件数据库就都部署好了。需要强调的是，这些都是符合业务需求的部署，而不是随便新启动一个程序。

  3. 根据部署文档的业务需求，AI 自己在

  • MySQL 建了对应的库和用户
  • MinIO 建了对应的桶
  • Nacos 建了命名空间
  • MongoDB 建了对应的用户
  • Doris 建了相应的用户和库、表

  1. 部署完成后，AI 自己根据规划，进行了对应的测试，包括连通性、可用性、存在性等等。

  2. AI 将部署信息（IP、URL、端口、账号、密码）同步至飞书共享表格，方便多人协同工作。而部署步骤则写到本地的 Markdown 文档中。进度、待办、注意事项等信息写到待办清单文档中（方便人控制进度和 AI 再次继续工作时不会遗忘）。
    附飞书 CLI 说明：

飞书 CLI
飞书 CLI 开源（官方）：2026 年 3 月 28 日 
官方网页：飞书CLI｜让AI直接操作你的飞书，一键安装开源工具 - 飞书官网
官方详细说明文档：飞书 CLI 能力介绍与最佳实践
飞书 CLI 解决的核心问题：让 AI 拿到你在飞书上沉淀的所有工作 context（消息、文档、日历、妙记、多维表格），同时给它操作这些东西的能力。既能看，也能动手。（注：能力覆盖消息、文档、多维表格、电子表格、幻灯片、日历、邮箱、任务、会议等 18 个业务域，提供 200+ 条命令和 26 个 AI Agent Skills。它把飞书开放平台 2500+ 个 API 封装成了精选命令）
支持范围：业内通用 Agent 平台均支持（Claude Code、Codex、Cursor......）。
感受：还有一点就是无需用户掌握底层命令、API调用。完全可以通过自然语言与 AI 对话操作。在官方文档安装飞书 CLI 步骤中，额外给出了一条通过自然语言安装的方法：“帮我安装飞书 CLI：# 飞书 CLI 安装指南 以下步骤面向 AI Agent，部分步骤需要用户在浏览器中配合完成。 ## 环境要求 开始安装之前，请确保环境中已安装: - Node.js(npm/npx) - Go v ”，这一点做（写）得真好。

AI 运维内容输出

AI 全程自己部署，需要有记录。因为 AI 的上下文有限，不可能记住全部做过的事情。而且一个项目可能会有很多人（AI）接手，所以需要保证项目的可维护性、可复现、故障可排查。所以在 CLAUDE.md 中，根据我的运维经验，写了一些 AI 运维的规范。
内容如下：

## 语言
使用简体中文

## 运维习惯
### 部署与问题排查
- 拿到一个新环境部署项目时，先查看磁盘挂载情况。如果有独立的数据盘，就把服务部署到独立的数据盘。如果没有，再部署到 / 系统下。
- 没有给出明确的环境信息的时候，排查问题或者部署的时候，先查看是否安装了 Docker 或者 Kubernetes。
- 如果使用 Docker 部署服务，要使用 Docker Compose。如果只是测试，用完就删除，可以使用 docker 命令行。
- 查找到服务后，启停时，优先查看是否有 YAML 文件或者脚本，验证脚本或 YAML 文件和正在运行的程序是否对应，如果没有再通过其他方式启停。
- 修改重要的配置文件前进行备份，备份的文件有时间戳，例如: /etc/fstab-2025-08-08
- 目录、文件命名尽量见名知意。减少无法理解的缩写命名，除非单词非常长。
- 构建或部署失败时，如果定位到是业务代码本身的问题（编译报错、依赖缺失、代码不同步等），排查到此为止：把报错的文件、行号、模块、错误信息讲清楚交给我，不要自己登录代码仓库服务器去底层翻代码。需要看代码时我会把仓库拉到本地再给你看。基础设施类问题（分支是否存在、凭据、网络、镜像仓库权限等）不受此限，正常排查即可。
- 一次任务收尾时（不论大小），先确认这个项目/这台机器是否已有对应的文档或台账（部署文档、资源清单、IP 规划等）；有就把本次改动同步进去，没有就问我要不要建，不要自行新建。账号密码类的表格只提醒我更新，你不要自己写入。

### 部署文档编写
- 在服务器上执行部署、配置等操作后，把实际执行的步骤同步写成 Markdown 文档，方便日后运维和交付客户。文档存放位置以各项目约定为准。
- 写作视角，文档要同时满足三个用途：
  1. 运维维护：甲方或乙方的运维人员可以据此进行日常维护（启停命令、日志位置、验证方法要写清楚）；
  2. 环境复现：在新环境中能完全复现部署（配置文件、初始化 SQL、命令收录全文，保持自包含，不引用外部资料）；
  3. 项目复用：其他新项目可以参考该文档重新部署环境（环境相关参数如 IP、UUID、密码来源要显式标注，便于替换）。
- 每个项目的所有部署内容集中写在一个文件里，文件名为「部署文档.md」，不按服务拆分成多个文件；每类操作作为文档中的一个二级标题章节，后续操作往同一文档追加。
- 部署文档写的是「最终应该怎么做」，不是变更日志：新增的操作类型才追加新章节；如果是发现之前的部署有问题、后续做了修补，直接改写原来那一节让它变成正确的做法，不要另起「更新记录」「补充说明」而把错误的步骤留在文档里，否则照文档复现的人会先踩一遍坑。踩坑经过属于内部信息，记到「待办清单.md」的注意事项里。
- Markdown 文档不使用一级标题（#），顶层从二级标题（##）开始。
- 同一类型的操作用三级/四级子标题分层收纳（如 ## 中间件部署 → ### MySQL → #### 安装/配置），不要大量同级标题平铺并排，避免文档目录树过长。
- 以上规范针对大型项目的部署场景；如果只是简单的问题排查类文档，不必严格套用这套要求。

### 重大项目部署
大型项目部署周期长、跨多天推进，除《部署文档.md》外，还要在其同级目录建一个「待办清单.md」，用于跨天接续工作、避免遗忘。

- 该文件是**内部备忘，不对外交付**，所以可以记录中转机、跳板机、CI 等我方内部信息；交付客户的内容一律只写在部署文档里。
- 内容分五块：
  1. **待确认**：需要用户或开发拍板的事项，每条注明卡住了后续什么工作；
  2. **待做的工作**：按建议的执行顺序排列，写清每步具体要动哪些文件、哪些配置；
  3. **注意事项**：已经踩过或确认过的坑，按配置类、运维类、文档类分组；
  4. **已完成**：简要回顾，便于随时看清进度；
  5. 开头注明用途与最后更新日期。
- 每完成一项就同步更新（勾掉或移入「已完成」），新踩到的坑随时补进「注意事项」，不要等到最后才补。

编写 CICD 流水线

  • ToB 项目无法搭建完整的 CICD 流程，但是可以让 AI 来完成整个流程 。步骤如下：
    拉取代码 ---> 构建打包 ---> 上传镜像仓库/上传下载服务器 ---> 登录服务器执行部署脚本

  • 生产环境使用的是 Jenkins

  1. 首先需要让 AI 可以操作 Jenkins 各种功能。将账号的 API Token、访问地址、登录用户名写到本地的隐藏文件中，接着告诉 AI 文件路径，让其进行登录操作测试。成功后写成 Skill 方便后续调用。（顺便提一句，AI 还自己写了 Python 程序用来操作 Jenkins，这样后续 AI 使用的时候会更加便捷）

  2. 让 AI 查看以前一个项目的流水线内容，根据本次的项目具体的环境情况写一个新的流水线。多个就写多个。

  3. 最后，研发将代码仓库地址、分支同步到飞书的协同文档中，告诉 AI 读取文档进行流水线构建测试。如果测试中发现代码编译出现问题（非流水线问题），可以让 AI 将问题现象收集后发到项目群里，交由研发处理。

配置文件基线

同一个产品可能需要多次部署，而每次环境都不同，所以我准备了一个各类配置文件部署相关的代码仓库，存放 Nacos、Nginx 等配置文件模板。之后交给 AI 来维护：

  • 拉取代码，从模板分支检出新项目分支。
  • 根据实际情况修改配置文件，同步到新环境的服务器上部署。
  • 提交代码，保持各个项目配置文件的更新。

给 AI 写的 README（已脱敏）

# 部署资料仓库

本仓库用于存放项目部署相关的配置与文档资料。

## 说明

- 以某标准化私有化部署项目作为**基线**,保留其 Nginx 配置文件和 Nacos 业务配置文件各一份版本。
- 后续所有项目的部署,均以该基线为起点;部署文档也基于基线文档,按各现场的实际需求进行修改。
- 其他文档与资料可持续补充到本仓库中。

## 约定

- **请勿直接在基础分支上修改**,请新建分支后提交。
- Nginx 仅保留主要配置文件;日志、前端程序、图片等无关内容已删除,以保持仓库最小化。
- 标记为「基线副本」的文档为归档版本,无论是否存在错漏、后续是否有新增内容,该副本一律不再修改;变更请新建文件。

我们继续

  1. 让 AI 根据基线仓库检出新项目分支。

  2. 接着让 AI 分析 Nacos 、Nginx 配置文件中的内容，列出已经确定可以修改的内容和待修改内容，经过几轮沟通确认后，制定好计划，开始执行。

  3. 最后让 AI 提交到代码仓库并将 Nginx 配置文件推送到线上，业务配置文件推送 Nacos 对应的命名空间。

  4. 让 AI 部署 Nginx 并测试。完成部署后触发前端构建，然后部署到线上，并进行测试。

  5. 最后部署后端。AI 分析相关文件 ---> 根据具体环境修改配置文件参数 ---> 配置文件上传服务器 ---> Jenkins 构建镜像 ---> 根据 Docker Compose 启动 ---> 持续观察容器状态 ---> 有错误 AI 自行查看日志排查（部署问题自行解决，代码问题发项目群） ---> 启动完成

补充（持续更新）

  1. 服务都运行之后，进入联调阶段。在这个阶段中，服务的发布更新、问题排查都可以全部交给 AI 。AI 部署的项目交由 AI 来运维，这样才能保证信息的全面与准确。
posted @ 2026-07-31 16:11  清葵雨露  阅读(45)  评论(0)    收藏  举报