AI写的系统上线后，怎样长期稳定运行？记住这份最低运维清单

用AI把系统做出来，再部署到服务器，只是把它从“自己的电脑能运行”变成“别人可以访问”。

真正开始使用后，问题会换一种形式出现：今天突然打不开，应该先看哪里？AI又改了一个功能，能不能直接覆盖服务器上的版本？数据库每天都在增加，备份到底有没有成功？

很多用Vibe Coding做系统的人，暂时并不准备交给开发团队，而是想自己继续维护。这并非一定不可行，但前提不是“我以后遇到问题继续问AI”，而是先建立一套最低限度的维护能力。

上一篇讨论了怎样把Spring Boot + Vue系统部署到服务器，并验证数据库与附件恢复。这篇继续使用同一示例：Ubuntu 24.04、Nginx、Spring Boot、MySQL和独立附件目录，重点讨论系统上线后怎样自己维护。

本文面向能看懂基本配置、愿意学习少量服务器操作的业务负责人和产品经理。它不是完整的专业运维方案，也不适用于没有授权的服务器。涉及生产数据、权限、数据库结构和安全更新时，需要按实际风险决定是否请专业人员参与。

目录

1. [先分清维护不是继续让AI改页面](#一先分清维护不是继续让ai改页面)
2. [画出自己的系统地图](#二画出自己的系统地图)
3. [建立四个最基本的观察入口](#三建立四个最基本的观察入口)
4. [系统出问题按层检查](#四系统出问题按层检查)
5. [每次改功能都走一遍安全更新流程](#五每次改功能都走一遍安全更新流程)
6. [判断哪些修改可以自己做](#六判断哪些修改可以自己做)
7. [给AI资料但不要把秘密一起交出去](#七给ai资料但不要把秘密一起交出去)
8. [把维护变成固定动作](#八把维护变成固定动作)
9. [什么时候不该继续一个人维护](#九什么时候不该继续一个人维护)

一、先分清维护，不是继续让AI改页面

自己维护至少包含四类工作：

工作	要回答的问题	不是只做什么
运行检查	服务是否正常，磁盘和证书是否有风险	偶尔打开首页看看
故障处理	问题发生在哪一层，如何先恢复业务	把最后一行报错发给AI
数据保护	数据库和附件是否都能恢复	看见目录里有备份文件
版本更新	改了什么，怎样验证，失败后退回哪里	把新文件直接覆盖旧文件

因此，“自己维护”不等于看懂每一行代码，也不等于一个人解决所有技术问题。

一个更实际的标准是：出现问题时，你知道从哪里取证；修改系统前，你知道怎样保留退路；超过自己能力边界时，你能把有效资料交给接手的人。

图1：自己维护的目标不是包办所有技术工作，而是让运行、故障、数据和版本保持可控。

二、画出自己的系统地图

很多系统刚做完时，制作者知道每个文件放在哪里。过两个月再看，却只记得“当时好像改过一个配置”。

先为系统留下一张一页纸地图：

用户浏览器
    ↓ HTTPS / 域名 / 证书
Nginx
    ├─ Vue 静态文件：/opt/ai-project/current/web
    └─ /api/ → Spring Boot：127.0.0.1:8080
                         ├─ MySQL：127.0.0.1:3306/ai_project
                         └─ 附件：/srv/ai-project/uploads

运行配置：/etc/ai-project/
服务名称：ai-project.service
发布版本：/opt/ai-project/releases/
备份位置：本机临时落点 + 独立副本

这张图旁边再维护一份资产清单，但不要把秘密直接写进去：

项目	应记录的内容	不要公开记录
代码	仓库位置、分支、当前提交号、构建方式	访问令牌
服务器	用途、系统版本、管理责任人	密码、私钥正文
应用	服务名、安装目录、启动方式、运行账号	环境变量真实值
数据库	版本、库名、迁移方式、备份策略	管理员密码、完整连接串
外部服务	邮件、短信、对象存储等依赖及申请主体	AccessKey、SecretKey
域名证书	域名、证书来源、到期时间、续期方式	私钥文件内容

秘密要存放在受控的凭证管理位置，清单只记录“由谁管理、在哪里按权限取得”。这样既方便自己找，也避免维护文档变成泄密清单。

三、建立四个最基本的观察入口

系统不能等用户反馈“打不开了”，才第一次想起去服务器看看。最低限度应能观察服务、日志、资源和业务。

图2：服务状态、运行日志、资源与端口、业务检查，是自己维护系统时最基本的四个观察入口。

1. 服务状态

如果后端由systemd管理，可以先查看：

sudo systemctl status ai-project --no-pager
sudo systemctl is-active ai-project
sudo systemctl show ai-project -p ActiveEnterTimestamp -p NRestarts

重点不是只看 active，还要留意它什么时候启动、是否反复重启。进程存在，只代表程序还在运行，不代表数据库连接和业务功能一定正常。

2. 应用日志

查看当前启动以来的日志，以及最近一段时间的错误上下文：

sudo journalctl -u ai-project -b --no-pager -n 100
sudo journalctl -u ai-project --since "30 minutes ago" --no-pager

journalctl 可以按服务和时间过滤systemd日志，具体选项以服务器版本为准。参考：Ubuntu 24.04 journalctl手册

不要只截取最后一句异常。一次有效的故障记录至少包含：发生时间、用户做了什么、请求结果、第一段有意义的异常、最近发布版本，以及是否所有人都受影响。

日志本身也可能包含姓名、手机号、业务数据或令牌。复制给AI或外部人员前要先脱敏，不能把整份生产日志直接上传。

3. 服务器资源

页面越来越慢，不一定是代码突然变差，也可能是磁盘、内存或日志已经接近上限：

df -h
free -h
sudo journalctl --disk-usage
sudo ss -lntp

这些命令分别帮助检查文件系统容量、内存、日志占用和监听端口。它们只能提供排查线索，不能仅凭某个数字就直接删除日志、扩容或重启服务器。

4. 业务检查

技术健康检查和业务检查需要分开。

如果项目已经接入Spring Boot Actuator，可以在受限范围内使用健康端点；官方文档也提醒，管理端点可能包含敏感信息，应谨慎决定暴露范围并进行保护。参考：Spring Boot 3.5 Actuator Endpoints

但 /actuator/health 返回正常，仍不能证明“创建项目”“提交审批”或“下载附件”可以使用。因此还要保留一组不会影响真实业务的检查动作：

• 打开一个约定的测试页面。
• 使用测试账号登录。
• 查询一条合成测试记录。
• 在允许的测试范围内完成一次核心流程。
• 核对页面结果和数据库结果是否符合预期。

监控没有覆盖到的地方，最终会变成用户替你监控。

四、系统出问题，按层检查

遇到故障时，先缩小范围，再决定让AI分析什么。以下顺序比“让AI把代码全部检查一遍”更有效：

图3：按访问入口、前端、API、后端、数据和最近变更逐层排查，每一步都保留证据。

现象	第一检查位置	下一步证据
域名完全打不开	域名解析、证书、Nginx和443端口	Nginx状态与错误日志
首页能开，点功能报错	浏览器网络请求和 /api 路径	HTTP状态码、请求时间、后端同一时段日志
只有一个用户失败	账号、角色、数据范围和输入内容	使用脱敏测试账号复现，不借用真实用户密码
查询正常，保存失败	服务端校验、数据库约束、磁盘权限	第一段有效异常及失败请求的脱敏参数
更新后附件打不开	附件路径、运行账号权限、文件是否存在	数据库文件引用和磁盘文件同时核对
系统时好时坏	重启次数、内存、磁盘、连接池和外部依赖	问题时间段的连续日志，而非单张截图

以“点击保存后提示失败”为例，先回答四个问题：

1. 所有人都失败，还是某个账号、某条数据失败？
2. 浏览器请求有没有发出，返回的状态码和响应是什么？
3. 后端同一时间出现的第一段业务异常是什么？
4. 失败发生前，是否刚更新过程序、配置或数据库结构？

这些信息准备好后，再让AI分析，得到的往往不是一句泛泛的“检查网络或数据库”。

五、每次改功能，都走一遍安全更新流程

系统上线后，最危险的习惯不是不会写代码，而是让AI改完以后直接覆盖线上文件。

一次最小更新流程可以是：

图4：安全更新的关键不是增加手续，而是让每次修改都能验证、追溯和回退。

1. 修改前，先让当前状态可追溯

如果项目使用Git，先确认当前文件状态和版本：

git status --short
git log -1 --oneline
git switch -c change/project-priority

修改完成后，检查到底改了哪些文件：

git diff --stat
git diff

Git标签可以标记一个明确的发布点，但标签不能代替数据库和附件备份，也不会自动保存尚未提交或未跟踪的文件。参考：Git Tagging、git status

2. 不要把“增加一个字段”当成只改一个页面

假设要给项目增加“优先级”，至少要检查：

层次	需要明确的问题
页面	是否必填，默认显示什么，编辑和详情是否一致
接口	允许哪些值，空值和非法值怎样返回
数据库	新列是否允许为空，已有数据怎样补齐，索引是否需要调整
查询统计	筛选、排序、导出和报表是否需要包含新字段
权限流程	谁能修改，流程进入下一状态后还能不能改
升级回退	旧程序能否读取新结构，回退时新增数据怎么办

AI很容易完成页面上的下拉框，却不一定主动把历史数据、导出和回退一起处理。让它列出影响范围，再由你结合业务逐项确认，比一句“帮我加一个优先级字段”更可靠。

3. 更新后，检查业务而不只是启动结果

每次发布至少记录：

字段	示例
发布编号	r006
对应代码版本	提交号或标签
变更内容	新增项目优先级；修复保存校验
数据变更	是否执行迁移，影响哪些表
备份证据	数据库和附件备份时间、校验记录
验收结果	新增、编辑、查询、权限及附件检查结果
回退条件	出现哪些情况立即回退
已知限制	哪些场景尚未覆盖

“服务启动成功”只能填在验收记录的一小格里。

六、判断哪些修改可以自己做

不是所有修改都要请人，也不是所有修改都适合继续交给AI试错。可以按影响划分：

级别	常见变更	建议
A：低风险	文案、展示顺序、已外置的非敏感配置	有版本记录和页面检查后，可自行处理
B：有限影响	独立页面、简单查询、非核心导出	在测试环境验证，准备程序回退
C：高业务影响	权限、审批状态、金额计算、唯一性和数据关联	先梳理业务规则、数据影响和失败处理，建议技术复核
D：高技术影响	数据库迁移、认证、安全更新、框架大版本升级、并发任务	不建议在生产环境靠多轮试错完成

这个划分不是看代码行数。

把按钮从蓝色改成绿色，可能改了很多样式文件，但业务风险很低；把“只有负责人可审批”改成“项目成员可审批”，也许只有几行代码，却可能改变整个权限边界。

如果无法回答下面三个问题，就先不要上线：

1. 这次修改会影响哪些已有数据和角色？
2. 怎样证明修改后的结果正确？
3. 失败后，程序和数据分别怎样处理？

七、给AI资料，但不要把秘密一起交出去

AI排查问题需要上下文，但上下文不是越多越好。可以整理成这样的最小问题包：

运行环境：Ubuntu 24.04 / Java版本 / Spring Boot版本 / MySQL版本
发布版本：r006 / 对应提交号
预期结果：项目负责人可以提交审批
实际结果：点击提交后返回HTTP 500
影响范围：两个测试账号均可复现，查询功能正常
最近变更：新增priority字段，执行过迁移脚本V006
日志片段：脱敏后的第一段相关异常及其前后20行
限制：先分析原因和验证步骤，不直接修改生产数据

不要直接提供：

• SSH私钥、服务器密码和数据库密码。
• .env、云平台密钥、短信或邮件服务密钥。
• 未脱敏的数据库备份、生产日志和客户附件。
• 真实身份证号、手机号、合同及其他敏感业务数据。

AI给出命令后，也要先理解目标和作用范围。凡是会删除文件、覆盖数据库、批量改数据、修改防火墙或开放端口的命令，不应因为“看起来像标准答案”就直接在生产服务器执行。

八、把维护变成固定动作

自己维护最容易失败的地方，是所有事情都等“有空再检查”。可以从一个很轻的周期开始：

周期	建议动作	留下什么记录
每天或自动检查	服务可用性、核心页面/API、备份任务结果	失败告警和处理状态
每周	磁盘、异常日志、证书剩余时间、最近变更	简短检查表
每月	抽查备份、账号权限、依赖和服务器更新计划	风险清单与处理安排
每次发布	版本、变更、备份、验收、回退条件	发布记录
定期演练	在隔离环境恢复数据库和附件	恢复时间、核对结果及问题

不要为了“自动化”一次性装很多看不懂的监控工具。先保证真正有人接收告警、知道告警意味着什么，再逐步完善。

备份也不要只看任务显示成功。MySQL官方文档列出了 mysqldump 的适用范围和选项限制；数据库之外的附件、配置和外部依赖仍需单独纳入恢复设计。参考：MySQL 8.4 mysqldump

九、什么时候不该继续一个人维护

自己维护的目标不是证明“我什么都能做”，而是在系统当前风险和自己的能力之间保持匹配。

出现以下情况时，应考虑引入专业人员：

• 系统已经驱动订单、项目、审批、财务或客户服务，停机会直接影响工作。
• 使用人数、部门或外部用户明显增加，需要稳定的权限和审计。
• 数据涉及个人信息、商业秘密或合规要求。
• 多次修改后，已经说不清当前线上版本和数据库结构。
• 备份从未恢复成功，或者不知道故障时最多会丢失多少数据。
• 同一种问题反复出现，只能依靠重启或让AI继续试错。
• 自己无法判断某条命令是否会删除、覆盖或暴露数据。

这不意味着前面的工作白做了。

如果已经保留系统地图、版本记录、部署配置、日志、备份和业务规则，接手人员就能从清晰的现状开始，而不是先花时间猜“线上到底运行的是哪一份代码”。

结语

AI让一个人做出并维护小型系统成为可能，但真正的“自己维护”，不是一个人承担所有技术角色。

它更像是一套可控的工作方式：平时看得见系统状态，出问题时找得到证据，改功能时留得下版本，失败后退得回去；超出边界时，也知道什么时候该停下来。

如果这些基础还没有建立，下一次最值得让AI帮你完成的，也许不是增加新页面，而是把系统地图、检查入口、版本记录和恢复步骤先补齐。

你自己维护AI做的系统时，最容易卡在日志、备份、更新，还是判断一项修改会影响哪些地方？

参考资料

以下资料对应文中具体技术点，实际操作需按项目和安装版本核对：

1. Spring Boot 3.5：Actuator Endpoints
2. Ubuntu 24.04：journalctl
3. Git：Tagging
4. Git：git status
5. MySQL 8.4：mysqldump