
## 摘要

本文以 GEO Monitor 项目为案例，介绍一套从需求分析、代码实现、故障诊断到生产部署的 AI Ops 实践。
项目由 Next.js、FastAPI 和 SQLite 构成，部署在 AWS Lightsail，通过 Docker Compose 运行，使用 GitHub Actions 完成测试、镜像构建和自动发布。在整个过程中，AI 不只是生成代码或提供命令，而是持续读取需求、代码、日志和运行状态，参与方案设计、变更实施、故障定位、部署验证和知识沉淀。

这次实践最终形成了两个闭环：
- 应用闭环：品牌配置、问题生成、多模型测评、结果分析和例行监测；
- AI Ops 闭环：理解目标、检查环境、生成方案、执行变更、验证结果、处理异常和沉淀 Skill。

我们的核心结论是：AI Ops 的价值不在于让 AI 无限制操作生产环境，而在于把研发和运维过程转化为可观察、可验证、可恢复、可复用的工程流程。


----
## 一、为什么这个项目需要 AI Ops

GEO Monitor 是一套品牌生成式引擎优化监测系统。
系统需要把同一组问题发送给 ChatGPT、豆包、DeepSeek 等模型，分析：
- 是否提及目标品牌；
- 是否引用品牌相关页面；
- 是否明确推荐该品牌；
- 品牌在推荐列表中的顺位；
- 哪些竞争对手替代了目标品牌；
- 品牌表现是否随时间发生变化。

其业务链路如下：
```
品牌工作区
→ 行业与赛道识别
→ 搜索联想词采集
→ 场景化问题生成
→ 多模型评测
→ 回答与引用解析
→ 竞争分析
→ 建立基线
→ 例行监测
```
随着项目持续迭代，运维复杂度也快速增加：
- 前后端需要独立构建和运行；
- 多个模型需要配置不同 API Key；
- SQLite 数据必须在容器升级后保留；
- 生产服务器已经运行其他业务；
- 80 和 443 端口已被现有 Caddy 占用；
- 团队提交代码后需要自动部署；
- 部署失败必须能够恢复上一版本；
- 线上问题需要从浏览器、接口、容器和日志多个层面定位。

如果每次都依赖开发人员临时判断，项目很容易形成大量不可复现的“手工操作”。
因此，我们引入 AI Ops，不是单纯让 AI 帮忙写 Shell 脚本，而是让 AI 参与整个软件生命周期。


----
## 二、我们如何定义 AI Ops

在本项目中，AI Ops 是一个持续循环，而不是单个自动化脚本。
![mermaid-diagram.png](https://developer.qcloudimg.com/http-save/yehe-2615134/28f7fd275ecf609b687a838779e905d0.png)


这个流程包含七个核心动作：
1. 理解目标；
2. 收集上下文；
3. 建立假设；
4. 实施变更；
5. 自动验证；
6. 失败恢复；
7. 知识沉淀。

AI 并不只出现在“生成代码”这一步，而是贯穿整个闭环。


----
## 三、第一阶段：让 AI 理解系统，而不是直接执行命令

AI Ops 的第一个难点不是自动化，而是上下文。
用户最初提出的需求通常是局部的，例如：
- 增加一个按钮；
- 修复接口 500；
- 增加例行监测；
- 把系统部署到 AWS；
- 实现提交代码后自动上线。

如果只针对当前一句话修改代码，很容易破坏整体模型。
因此，每次重要变更前，AI 都需要组合读取：
- 产品需求文档；
- 前后端目录结构；
- 数据模型；
- API 定义；
- 测试代码；
- Docker 配置；
- Git 提交记录；
- 线上日志和服务状态。

例如，“例行监测”看起来只是增加定时任务，实际涉及：
```
问题集版本
→ 数据集类型
→ 基线关系
→ 执行平台
→ 每题重复次数
→ 每日执行时间
→ 计划周期
→ 运行状态
→ 趋势展示
```

如果 AI 只修改定时器，而没有理解基线和数据集关系，最终生成的趋势数据就不可比较。
因此，我们首先让 AI 把零散需求整理为多份结构化文档：
- GEO 前置监控流程；
- 场景化关键词规划；
- GEO 快速见效方案；
- 产品功能和代码实施规划；
- Lightsail CI/CD 部署实录。

这些文档成为 AI 后续推理的稳定上下文。


----
## 四、第二阶段：用 AI 把业务语言转化为工程模型

GEO Monitor 的很多需求最初来自自然语言反馈。例如：
>数据集分成单次数据集和例行数据集。单次数据集可以转成例行数据集的第一次数据。

AI 首先需要判断这句话在系统中意味着什么。
经过梳理，我们将其拆分为：
### 单次数据集

- 用户手动触发；
- 运行一次后结束；
- 保存问题、模型、重复次数和回答；
- 可被选为后续例行计划的基线。

### 例行计划

- 引用固定的基线问题集；
- 配置每天执行时间；
- 配置执行平台；
- 配置每题重复次数；
- 配置开始日期和持续周期；
- 每次执行产生独立数据集；
- 多个数据集共同形成趋势。

### 数据可比性约束

纵向比较必须保证：
- 问题一致；
- 场景定义一致；
- 模型和平台一致；
- 品牌与竞品识别规则一致；
- 指标算法一致。

这体现了 AI Ops 与普通代码生成的区别。
AI 不只是把需求翻译成表单字段，而是识别需求背后的数据约束、异常状态和长期运维影响。


----
## 五、第三阶段：建立“观察—假设—验证”的诊断方式

项目开发中出现过接口 404、500、JSON 解析失败、模型回答截断、网络超时和页面闪烁等问题。
我们没有让 AI 根据报错文字直接修改代码，而是采用统一诊断流程：
```
复现问题
→ 确认请求入口
→ 检查前端请求参数
→ 检查后端路由
→ 查看服务日志
→ 检查外部模型响应
→ 建立故障假设
→ 用最小测试验证
→ 修复代码
→ 执行回归测试
```
例如，“生成行业画像”返回：
```
'ascii' codec can't encode characters
```

如果只看表面，很容易怀疑 Prompt 中包含中文。
但诊断时需要继续检查：
- 错误发生在请求发送前还是模型响应后；
- HTTP Header 中是否写入了非 ASCII 内容；
- API Key 是否被误填成中文占位符；
- 配置状态接口是否验证了 Key；
- 为什么无效配置没有在更早阶段被拦截。

最终修复目标不应只是捕获异常，而应该把问题前移：

```
读取配置
→ 校验 API Key
→ 无效则返回清晰提示
→ 有效才调用模型
```
这类诊断方式可以复用于任何模型提供方，而不是只解决当前一次错误。


----
## 六、第四阶段：用 AI 建立自动化测试护栏

AI 修改代码后，不能以“代码看起来正确”作为完成标准。
GEO Monitor 的验证分为四层：
### 1. 单元测试

主要覆盖：
- 品牌与竞争对手管理；
- 问题生成；
- 场景分类；
- 模型响应解析；
- 品牌提及和引用判断；
- 单次与例行数据集；
- API Key 校验。

### 2. 后端集成检查

验证：
- FastAPI 路由是否存在；
- 请求和响应结构是否一致；
- SQLite 迁移是否兼容旧数据；
- 错误能否返回可理解的信息。

### 3. 前端检查

执行：
```
npm run lint
npm run build
```
用于发现类型错误、组件引用错误和生产构建问题。
### 4. 生产验证

部署完成后继续检查：
- API 健康状态；
- Web 页面是否可访问；
- Caddy 是否能找到上游；
- HTTPS 是否正常；
- SQLite 是否可读取；
- 原有网站是否受到影响。

只有所有相关层级通过，AI 才能把任务标记为完成。


----
## 七、第五阶段：由 AI 协助设计生产部署

生产服务器已经运行其他项目，Caddy 占用公网 80 和 443 端口。AI 首先进行环境盘点，而不是直接启动应用。
检查内容包括：
- 当前容器；
- 端口占用；
- Docker 网络；
- Caddy 配置；
- Compose 项目身份；
- 数据目录；
- 服务器磁盘空间；
- 已有域名和证书。

最终部署结构为：
![mermaid-diagram.png](https://developer.qcloudimg.com/http-save/yehe-2615134/5919c7a8eac12320ae705103b4fb926c.png)

主要约束如下：
- Next.js 只绑定宿主机 `127.0.0.1:3102`；
- FastAPI 的 `8001` 只在容器网络中开放；
- Caddy 通过共享 Docker 网络访问前端；
- API Key 通过外部环境文件注入；
- SQLite 通过 volume 持久化；
- 生产服务器不保存完整应用源码；
- 镜像、配置、密钥和业务数据彼此分离。

AI 在这里承担的是架构分析和约束检查，而不是简单拼接 Docker 命令。


----
## 八、第六阶段：从 CI 补齐到完整 CD

第一版流水线只完成测试、构建和镜像发布，但这还不能称为完整 CI/CD。
最终自动化链路为：
```
Push main
→ 后端单元测试
→ 前端 lint 和 build
→ 构建 API、Web 镜像
→ 推送到 GHCR
→ SSH 连接 Lightsail
→ 备份 SQLite
→ 拉取新镜像
→ 更新服务
→ 健康检查
→ 成功确认或失败回滚
```生产镜像使用完整 commit SHA：
```
geo-monitor-api:<commit-sha>
geo-monitor-web:<commit-sha>
```这建立了三者之间的确定关系：
```
Git 提交 = Docker 镜像 = 线上运行版本
```相比使用 `latest`，完整 SHA 可以帮助 AI 和运维人员快速回答：
- 线上运行的是哪次提交；
- 哪次提交引入了问题；
- 应回退到哪个镜像；
- 当前部署是否已经包含某项修复。

GitHub Actions 的部署身份独立于个人开发者。团队成员不需要共享服务器私钥，只需要通过仓库流程提交代码。


----
## 九、第七阶段：让 AI Ops 具备失败恢复能力

自动化不等于可靠性。
如果流水线只能自动启动容器，却不能判断服务是否正常，那么它只是自动执行工具。
因此部署脚本增加了：
1. 部署锁，防止多个发布并发执行；
2. 部署前数据库备份；
3. 当前镜像版本记录；
4. 新镜像拉取；
5. 容器健康检查；
6. 失败恢复上一配置和镜像；
7. 非零退出状态返回 GitHub Actions。

完整状态转换如下：
```
准备部署
→ 已备份
→ 正在拉取
→ 正在更新
→ 正在检查
→ 部署成功
```
发生异常时：
```
健康检查失败
→ 恢复旧镜像标签
→ 重新启动旧版本
→ 验证旧版本健康
→ 流水线标记失败
```
这里的关键不是“永远不失败”，而是失败后系统能够回到明确的上一状态。




----
## 十、第八阶段：把运维经验沉淀为 Skill

如果 AI 每次都重新分析同类问题，仍然无法形成稳定的组织能力。
因此，我们把 Lightsail、GHCR、Docker Compose 和 Caddy 的部署经验整理成 AIOps Skill。
Skill 不是单纯的命令集合，而是一个包含输入、判断、动作、护栏和验收的执行规范。
### Skill 输入

```yaml
repository:
  branch: main
  registry: ghcr.io

application:
  frontend: Next.js
  backend: FastAPI
  database: SQLite

deployment:
  runtime: Docker Compose
  host: AWS Lightsail
  reverse_proxy: Caddy
```
### Skill 前置检查

- 读取项目 Dockerfile 和 Compose；
- 检查生产服务器端口；
- 识别已有 Compose 项目；
- 检查 Caddy 网络；
- 检查环境文件；
- 检查 GHCR 登录状态；
- 检查 SQLite 备份；
- 检查 DNS 和 HTTPS 条件。

### Skill 安全护栏

- 不输出或提交 API Key；
- 不覆盖生产数据库；
- 不直接开放新的公网端口；
- 不使用 `latest` 作为唯一生产版本；
- 不在未确认资源归属前删除容器或卷；
- 不在健康检查失败后报告部署成功；
- 涉及生产配置、密钥和删除操作时要求人工确认。

### Skill 验收条件

```
GitHub Actions 全部成功
线上镜像等于本次 commit SHA
Web 与 API 健康
HTTPS 正常
Caddy 上游可达
SQLite 数据可读取
原有业务未受影响
失败时可以回到上一版本
```
将这些规则写入 Skill 后，下一次面对类似项目，AI 可以直接复用经过验证的决策框架。


----
## 十二、这次 AI Ops 实践的核心分工

AI 在项目中承担了以下工作：

|阶段|AI的职责|人的职责|
|:-:|:-:|:-:|
|需求分析|整理需求、识别依赖、形成数据模型|确认业务目标和指标口径|
|代码实现|搜索代码、修改模块、补充测试|审核产品行为|
|故障诊断|读取日志、建立假设、设计验证|提供权限和确认风险|
|部署设计|盘点端口、网络、数据和密钥|决定生产架构|
|CI/CD|编排测试、构建、发布、部署|管理仓库与生产权限|
|生产验收|检查健康状态和版本一致性|确认业务可用|
|知识沉淀|生成文档、脚本和 Skill|审核并推广团队使用|
这种方式没有追求完全无人值守，而是把人放在权限、风险和最终决策的位置，把 AI 放在分析、执行、验证和知识整理的位置。


----
## 十三、实践结果

项目最终形成了两条稳定链路。
### 软件交付链路

```
需求
→ 代码
→ 测试
→ 镜像
→ 部署
→ 健康检查
→ 失败回滚
```
### AI Ops 能力链路

```
对话与日志
→ 上下文理解
→ 诊断和实施
→ 自动验证
→ 文档沉淀
→ Skill 复用
```

具体成果包括：
- 前后端完成容器化；
- 数据、配置、密钥和镜像相互分离；
- 后端测试、前端检查自动执行；
- API 和 Web 镜像自动发布到 GHCR；
- 主分支提交后自动部署到 Lightsail；
- 生产版本可以追溯到具体 Git SHA；
- 部署前自动备份 SQLite；
- 部署后执行健康检查；
- 失败时恢复上一版本；
- 公网入口复用现有 Caddy 和 HTTPS；
- 故障处理过程被整理为文档和 Skill。


----
## 十四、结论

这次实践让我们认识到，AI Ops 不应被理解为“AI 帮我执行几条运维命令”。
一个具备工程价值的 AI Ops 系统应该能够：
1. 理解业务目标和系统上下文；
2. 根据代码、配置和日志建立故障模型；
3. 在变更前识别依赖与风险；
4. 在变更后自动执行验证；
5. 在失败时恢复到明确状态；
6. 把解决过程沉淀为文档、测试、脚本和 Skill。

GEO Monitor 只是一个具体项目。真正可以复用的，是这套由 AI 参与的软件交付方法：

```
理解系统
→ 提出方案
→ 控制风险
→ 实施变更
→ 验证结果
→ 处理失败
→ 沉淀能力
```
当 AI 能够持续参与这一闭环时，它才从一个代码生成工具，转变为研发和运维流程中的工程协作者。

本文以 GEO Monitor 项目为案例，介绍一套从需求分析、代码实现、故障诊断到生产部署的 AI Ops 实践。项目由 Next.js、FastAPI 和 SQLite 构成，部署在 AWS Lightsail，通过 Docker Compose 运行，使用 GitHub Actions 完成测试、镜像构建和自动发布。在整个过程中，AI 不只是生成代码或提供命令，而是持续读取需求、代码、日志和运行状态，参与方案设计、变更实施、故障定位、部署验证和知识沉淀。

从对话式协作到自动化交付：GEO Monitor 的 AI Ops 实践

本文以 GEO Monitor 项目为案例，介绍一套从需求分析、代码实现、故障诊断到生产部署的 AI Ops 实践。
我们的核心结论是：AI Ops 的价值不在于让 AI 无限制操作生产环境，而在于把研发和运维过程转化为可观察、可验证、可恢复、可复用的工程流程。

人工智能

运维

云计算

基于GEOMonitor项目实践，本文介绍AIOps在软件全生命周期中的应用，涵盖需求分析、代码实现、故障诊断到生产部署。通过Next.js、FastAPI和SQLite构建系统，结合Docker Compose、GitHub Actions实现自动化CI/CD。AIOps闭环包含理解目标、执行变更、验证结果、处理异常和沉淀Skill，将研发运维转化为可观察、可验证、可恢复、可复用的工程流程，实现应用闭环与AIOps闭环双驱动。

代码生成工具

代码解释

单元测试

回归测试

服务器

数据库

ChatGPT

Docker

容器

路由

SQLite

GitHub

AIOps

JSON

热销域名限时优惠，新客首年免费！


domain

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

基于GEOMonitor项目实践，本文介绍AIOps在软件全生命周期中的应用，涵盖需求分析、代码实现、故障诊断到生产部署。通过Next.js、FastAPI和SQLite构建系统，结合Docker Compose、GitHub Actions实现自动化CI/CD。AIOps闭环包含理解目标、执行变更、验证结果、处理异常...

从对话式协作到自动化交付：GEO Monitor 的 AI Ops 实践-腾讯云开发者社区-腾讯云

从对话式协作到自动化交付：GEO Monitor 的 AI Ops 实践

从对话式协作到自动化交付：GEO Monitor 的 AI Ops 实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐