智能发布检查：AI 可以提醒，但不能替你上线

智能发布检查：AI 可以提醒，但不能替你上线

一、上线前最怕漏项

独立产品发布频繁，功能小、节奏快，很容易漏掉检查项：环境变量没配、迁移脚本没跑、埋点缺失、文档没更新、回滚方案没准备。AI 可以作为发布助手，帮忙检查变更内容和发布清单。

但 AI 只能提醒，不能替你承担上线责任。

二、发布清单要结构化

flowchart TD
  A[代码变更] --> B[配置]
  A --> C[数据库]
  A --> D[前端资源]
  A --> E[文档]
  A --> F[回滚]

发布检查不能只读 Commit 信息。要结合 PR、配置 diff、数据库迁移、依赖变化和用户影响范围。

release_checklist:
  env_changed: required
  migration_required: required
  rollback_plan: required
  docs_updated: optional
  tracking_updated: optional

结构化清单能让 AI 对照检查，而不是泛泛提醒"小心上线风险"。

清单本身也要分层。代码级别的检查（环境变量、迁移脚本）可以在 CI 里自动跑，产品级别的检查（文档更新、公告通知、客服培训）需要人工确认。把自动化检查前置，人工部分才不会被琐碎的验证步骤淹没。

三、AI 适合找不一致

AI 可以发现变更和清单之间的不一致：代码里新增了环境变量，但发布说明没提；新增了付费入口，但埋点没加；接口返回字段变了，但文档没改。

const releaseFinding = {
  type: "missing_env_doc",
  evidence: "process.env.AI_MODEL_PROVIDER",
  suggestion: "补充生产环境配置说明",
};

这些提醒很适合独立开发者，因为没有完整 QA 团队时，漏项成本会更高。

AI 发现不一致的能力可以细化到具体检查维度。比如扫描代码 diff 时，检测到新增的环境变量引用，就自动对照 .env.example 和部署配置是否同步更新：

async function checkEnvConsistency(prFiles: string[]): Promise<ReleaseFinding[]> {
  const findings: ReleaseFinding[] = []
  const envRefs = await scanEnvReferences(prFiles)
  const documented = await readEnvExample()
  for (const ref of envRefs) {
    if (!documented.includes(ref.name)) {
      findings.push({
        type: "missing_env_doc",
        evidence: ref.name,
        suggestion: `请在 .env.example 和部署配置中补充 ${ref.name} 的说明`,
        file: ref.file,
      })
    }
  }
  return findings
}

这个检查的运行时机最好是 PR 阶段，而不是等到发布前。如果等到发布按钮旁边才提示漏了某个环境变量，意味着配置还没准备好，发布只能延迟。在 PR 阶段就告警，开发者在同一轮修改里就能补上。

四、关键动作仍要人工确认

数据库迁移、计费逻辑、权限策略、删除数据、切换模型供应商，这类高风险动作不能自动放行。AI 可以给风险摘要，最终仍要人工确认。

manual_confirm:
  database_migration: true
  billing_change: true
  permission_change: true
  destructive_action: true

还要定义回滚条件。发布后错误率、转化率、支付失败率、模型调用成本异常时，什么时候回滚，要提前写清楚。

最后，发布检查结果要保存。上线后出现问题，可以回看当时 AI 提醒了什么、人工确认了什么、哪些检查漏掉了。

发布助手还可以读取变更影响面。比如改了登录模块，就自动提示检查注册、密码重置、会话续期和权限跳转；改了计费模块，就提示检查试用、扣费、发票和退款。影响面不是靠模型凭空猜，而是来自代码目录、路由、接口和历史发布记录。

impact_map:
  auth:
    - login
    - session_refresh
    - password_reset
  billing:
    - subscription
    - invoice
    - quota

还要把发布后观察纳入流程。上线前检查只是第一半，发布后 10 分钟、1 小时、24 小时分别看哪些指标，也应该由清单定义。独立产品人少，更需要这种固定节奏。

最后，AI 发现的风险要分级。阻断项必须处理，提醒项可以记录，信息项只供参考。没有分级，发布检查会变成一堆吓人的文字。

还要让发布检查支持 dry-run。真正上线前，先基于当前分支生成一份检查报告，让开发者提前修复环境变量、文档和埋点问题。等到发布按钮旁边才发现漏项，心理压力会大很多。

五、总结

智能发布检查要结构化清单、发现变更不一致、标记高风险动作，并保留人工确认和回滚条件。

AI 可以提醒，但不能替你上线。发布责任必须清楚地留在人这边。

发布检查的本质不是找问题，而是让团队在上线前有最后一道共同确认的决策点。工具可以提醒，但决定"这个风险现在是否值得承担"的只能是人。把这条线画清楚，发布检查才不会变成走形式。