Chen's Blog
0%

先让产品产生价值：如何把 AI 辅助内容系统以受控 MVP 方式上线

发表于
本文字数： 4.8k 阅读时长 ≈ 4 分钟

1. 引言与适用范围

本文是一份面向独立开发者和小型技术团队的上线方法指南，不是可以原样复制到任意环境的生产脚本。文中的命令、服务名、目录、镜像和网络策略都应结合实际项目核对后再执行。

适用场景是：已有一个能够在本地运行的 AI 辅助内容系统，希望以较低风险完成第一次真实生产闭环。目标不是一次性建成完整平台，而是尽快验证“生成内容是否有价值、人工审核是否可控、发布链路是否稳定”。

本文不适用于高并发、多租户、多区域部署、强合规行业或复杂多平台同步发布场景。这些场景需要更完整的权限、审计、容量、灾备和发布治理设计。

核心原则只有一句话：

先让产品在受控条件下产生真实价值，再用真实数据决定下一步投入。

2. 为什么受控 MVP 应优先于复杂发布治理

没有真实运行数据时，团队很难判断真正的瓶颈在哪里。提前投入多环境流水线、灰度发布、复杂编排和多平台分发，可能会让工程看起来更完整，却不能证明用户是否愿意使用生成结果。

MVP 阶段应优先建立四条边界：

  1. 生产可用优先于功能齐全：至少有一个稳定入口可以完成一次真实任务。
  2. 人工审核优先于自动发布：未经明确批准的 AI 内容不得进入发布队列。
  3. 单平台优先于多平台：先把一个发布目标做稳定，再扩展格式适配和认证集成。
  4. 可恢复优先于高自动化：数据库、内容仓库和备份必须有明确恢复路径。

这并不意味着忽略工程质量，而是把工程投入集中到最影响业务闭环的风险上：数据安全、生成质量、人工门禁、发布幂等性和失败可见性。

3. 执行前提与环境假设

一台 2 核 4 GB 云服务器可以作为单用户、低并发、AI 请求串行执行场景的起始规格，但它不是容量承诺。实际资源需求应根据 JVM 内存、数据库规模、AI 响应时间、并发任务数和内容构建过程测量。

生产环境至少需要：

  • 已安装并验证可用的 Docker Engine 与 Docker Compose v2；
  • 已固定并经过测试的 MySQL、Redis、JDK、Spring Boot 和 Caddy 版本；
  • 一个可以构建或拉取的应用镜像；
  • 可持久化的 MySQL、Redis 和应用数据卷；
  • 一个可写且可推送的 Hexo Git 仓库；
  • 一个用于公网健康检查或站点访问的域名；
  • 一个不直接暴露到公网的管理入口，例如 SSH 隧道、TAT 或私有网络。

不要只依据“版本足够新”判断兼容性。更可靠的方式是固定精确镜像版本或 digest，并用同一组版本完成部署、备份恢复和回滚演练。

4. 用 Docker Compose 建立最小可靠生产闭环

最小生产拓扑可以包含四类服务：

  • Spring Boot 应用；
  • MySQL；
  • Redis；
  • Caddy 或其他 HTTPS 入口。

应用、数据库和缓存可以位于同一个 Compose 项目网络中，但 MySQL 与 Redis 不应直接映射到公网。管理接口也不应因“方便调试”而公开暴露；可以只将应用端口绑定到 127.0.0.1，再通过 SSH 隧道访问后台。

敏感信息应与普通配置分离。数据库密码、Redis 密码和 AI API Key 不应写进镜像、代码仓库或可被普通用户读取的配置文件。优先使用 Compose secrets 或只读 secret 文件，让容器通过 /run/secrets/... 读取。宿主机上的源文件应限制权限，并明确哪些服务可以挂载对应 secret。

MySQL 客户端密码不要直接出现在命令行参数中。自动化脚本可使用受保护的 option file、login path 或挂载的 secret 文件，并确保日志不会输出凭证。不要把宿主机路径直接假设为容器内路径，必须显式挂载或通过 Compose secret 注入。

上线前至少验证：

  • 四个服务处于 running，有健康检查的服务处于 healthy；
  • 应用只能通过预期入口访问；
  • MySQL、Redis 没有公网端口；
  • 管理页面只能经受控通道访问；
  • 应用数据卷、数据库卷和 Hexo 工作区均可读写；
  • 自动生成和自动发布默认关闭。

5. 只升级应用容器的发布策略

生产升级应使用已经构建并验证的不可变镜像，推荐固定到镜像 digest。不要在正式服务器上临时修改代码后直接构建一个无法追踪的镜像。

一次应用升级的基本顺序可以是：

  1. 记录当前应用镜像、容器 ID、数据库版本和关键数据校验值；
  2. 验证 Compose 配置；
  3. 拉取目标不可变镜像；
  4. 只重新创建应用服务；
  5. 验证应用健康、迁移版本和核心数据；
  6. 保留原镜像与回滚证据。

只更新应用服务时，可使用类似下面的命令，但服务名和环境文件必须以项目实际配置为准：

1
2
docker compose pull app
docker compose up -d --no-deps app

--no-deps 的作用是避免因应用更新而启动或重新创建依赖服务。不要无条件执行 docker compose down，更不能使用 down -v 或删除现有数据库卷。

数据库备份与迁移

涉及数据库变更前，应生成最终备份并验证其可恢复性。对以 InnoDB 为主的数据库，mysqldump --single-transaction --quick 可以在不长时间阻塞业务写入的情况下取得事务一致性快照；但执行期间的 DDL，以及 MyISAM、MEMORY 等非事务表，不具备同等一致性保证。

备份文件存在不等于备份有效。至少应在隔离环境中完成一次恢复演练：

  1. 创建新的空数据卷；
  2. 使用兼容的 MySQL 镜像启动临时实例；
  3. 有限时等待数据库就绪；
  4. 导入备份；
  5. 核对迁移版本、关键表行数和核心业务记录；
  6. 只清理本次演练创建的临时资源。

数据库迁移应由 Flyway 或 Liquibase 等工具管理。破坏性迁移必须单独评估，必要时安排停写窗口。不要假设切回旧应用镜像会自动还原数据库，也不要假设迁移工具一定具备可靠的反向迁移能力。

6. AI 生成、人工审核、单平台发布与验收

一个安全的真实闭环不应只写成抽象的 draft → approved → published，而应与系统实际状态和门禁一致。

以当前系统的实现为例，流程如下。

第一步：创建并执行生成任务

人工提交一个生成任务。任务状态从 PENDING 进入 RUNNING，最终可能是：

  • SUCCESS；
  • FAILED；
  • SKIPPED；
  • CANCELLED。

生成过程中应记录实际 Provider、模型、阶段、尝试次数、Token 使用量和失败代码，但不得记录 API Key 或完整敏感 Prompt。

第二步：生成待审核草稿

任务成功后创建草稿。此时草稿生命周期为 AI_GENERATED，独立审核字段 reviewStatus 为 PENDING。

这个阶段只说明正文已经生成并落盘，不代表已经具备发布条件，也不应自动产生发布任务。

第三步：生成平台变体

当前实现要求审核批准前存在完整的平台变体。因此即使首轮只计划发布 Hexo，也需要先生成系统要求的 CSDN、WECHAT 和 HEXO 三个平台版本。

这一步的目的不是同时发布三个平台，而是形成可供人工逐项检查的确定版本。平台正文发生修改时，应更新内容摘要并使旧审核结果失效，避免发布未经查看的新版本。

第四步：人工审阅

审核人员至少检查：

  • 事实和技术命令是否准确；
  • 是否包含内部路径、账号、密钥或真实服务器信息；
  • 标题、摘要和正文是否一致；
  • Markdown 与目标平台格式是否兼容；
  • AI 质量审查是否存在 blocking finding；
  • 各平台版本号是否与当前页面快照一致。

发现问题时，应先修改规范化正文，再重新生成平台变体并重新审阅。

第五步：明确批准

批准成功后，reviewStatus 变为 APPROVED，草稿生命周期进入 REVIEWED。

当前版本能够记录审核状态和内容版本一致性，但不能据此声称已经持久化“审批人身份”和“审批时间”。如果业务需要责任追踪，应把审批主体、时间、来源 IP 或会话信息作为后续审计能力单独实现。

第六步：只创建 Hexo 发布任务

批准后只为 Hexo 创建发布任务，不调用会为全部平台建单的批量接口。

发布任务状态可能包括：

  • PENDING；
  • RUNNING；
  • SUCCESS；
  • RETRYABLE_FAILED；
  • NEED_MANUAL；
  • FAILED；
  • CANCELLED。

任务领取必须具备幂等性，已经运行或成功的任务不能因重复请求再次发布。

第七步：执行 Hexo Git 发布

当前 Hexo 发布并不是调用内容平台 API。发布器会把 Hexo 版本写入仓库的文章目录，校验工作区和分支，创建 Git commit，并在启用推送时推送到指定远端分支。

因此验收证据应包括：

  • 新文章文件存在；
  • Git 工作区干净；
  • 本地与远端分支指向预期提交；
  • 发布任务为 SUCCESS；
  • 记录了外部访问 URL 或可验证的文章路径。

第八步：公网验收

最后从公网访问实际文章，确认：

  • 页面返回成功；
  • 标题与正文正确；
  • 中文和代码块没有乱码；
  • 没有泄露管理入口或内部信息；
  • 失败重试和发布日志保持可查询。

在这一流程中，任何发布任务都必须出现在人工批准之后。

7. 风险与回滚方案

应用升级后无法启动

先判断问题是否只涉及应用镜像。如果数据库结构仍与旧版本兼容，可以恢复上一不可变镜像并只重新创建应用容器。

如果无法确认旧应用是否兼容升级后的数据库，不要直接让旧镜像连接当前数据卷。应保留现有卷不删除，用新的空卷和已验证备份恢复旧版本环境，再执行数据核对。

数据库迁移失败

停止继续写入，保留现场证据。根据已验证的恢复方案，从迁移前备份恢复数据库，并回退应用镜像。不要把“切回旧镜像”描述为数据库回滚。

Caddy 配置错误

先使用配置校验命令确认语法。回滚时恢复上一版配置并执行受控 reload；只有 reload 不可用或进程异常时才考虑重启入口服务。不要用入口配置问题作为重建整个 Compose 项目的理由。

Hexo 发布失败

不要盲目重复推送。先检查：

  • 工作区是否干净；
  • 当前分支是否正确；
  • 远端是否可访问；
  • 同一 slug 是否已经存在不同内容；
  • 本地提交是否已产生但远端推送失败。

根据失败类型选择自动重试、人工处理或终止，不得覆盖远端已有的不同文章。

服务器或凭证故障

数据库备份应保存到独立存储位置，并设置恢复演练和保留策略。凭证泄露时应立即轮换，而不是只删除泄露文件。管理后台应保持非公网暴露。

8. 上线后用真实数据决定迭代方向

上线后应持续记录最少的一组指标：

  • AI 生成成功率；
  • 各生成阶段耗时和 Token 消耗；
  • 人工审核通过率；
  • 从生成到批准的耗时；
  • 发布成功率；
  • 重试与人工处理比例；
  • 从批准到公网可见的耗时。

这些指标可以帮助团队区分不同问题：

  • 生成失败率高：先检查 Provider 稳定性、超时和重试；
  • blocking finding 多：先优化 Prompt、模型参数和质量规则；
  • 审核修改量大：先改善内容结构和平台变体；
  • 发布失败率高：先修复 Git 工作区、凭证、远端和幂等逻辑；
  • 人工审核耗时长：再考虑更好的差异对比、批量操作和审批体验。

只有当人工闭环稳定后，才适合逐步启用定时生成、更多平台和更高自动化。

9. 上线检查清单与常见误区

上线检查清单

  • 应用、MySQL、Redis 和入口服务健康；
  • 应用使用固定镜像版本或 digest；
  • MySQL、Redis 和管理后台未直接暴露公网；
  • 公网只开放业务真正需要的入口，管理通过 TAT、SSH 隧道或私有网络完成；
  • 自动生成保持关闭，直到人工闭环稳定；
  • 数据库备份已完成恢复演练；
  • 应用升级不会重建 MySQL、Redis 或删除卷；
  • Hexo 仓库分支正确、工作区干净、远端可推送；
  • 至少完成一次“生成—审核—批准—Hexo 发布—公网验收”；
  • 失败状态、日志和重试入口可查询。

常见误区

  1. 过早引入 Kubernetes，而单机 Compose 尚未形成稳定业务闭环；
  2. 把 AI 生成成功误认为内容已经可以发布；
  3. 未生成并审阅平台变体就直接批准；
  4. 调用批量发布接口，意外为多个平台创建任务；
  5. 应用升级时顺带重建数据库和缓存；
  6. 备份从未做过恢复演练；
  7. 在命令行、日志、镜像或仓库中泄露凭证；
  8. 把管理后台直接暴露到公网；
  9. 为了自动化而启用定时生成，却没有先证明人工流程稳定。

受控 MVP 的成功标准不是“架构看起来足够复杂”，而是系统能够在明确边界内稳定完成一次真实业务闭环，并且失败时知道如何停止、定位和恢复。

感谢您的支持，您的打赏是我持续创作的动力！