我们的自动化验证与自动值守体系
「代码写完了」和「代码真的能上线」之间，隔着一段大多数外包交付里靠运气填补的距离。 我们选择用机器把这段距离铺满：每次 push 先过 83 项自动验收，全绿才允许部署； 上线之后，编排与执行双模型轮流值守。这篇文章把体系拆开讲一遍。
一次 push 背后发生了什么
以 dcc.vedio 企业视频培训平台为例，开发者执行 git push 之后，流水线自动跑完以下环节：
| 环节 | 内容 | 典型耗时 |
|---|---|---|
| 门 1 · 验收门禁 | verify.js all：83 项检查逐项断言，任何一项失败 = 不放行 | 约 2 分钟 |
| 前端构建 | web + admin 双端 Vite 构建，构建失败同样不放行 | 约 3 分钟 |
| 镜像构建推送 | 服务端打镜像、推私有镜像仓（git-sha 双 tag 可追溯） | 约 1 分钟 |
| 自动部署 | Node B 容器以 sha 精确 tag 起新版本 | 约 1 分钟 |
| 探活 + 前端同步 | /api/health 探活通过后，dist 原子切换至边缘节点 | 约 1 分钟 |
全程 6–10 分钟，线上生效。回滚同样简单：换一个 tag，或者边缘节点的 .old 目录秒切。
83 项检查都查什么
验收门禁不是「跑通就算过」，而是把产品的验收标准固化成断言。当前 30 个检查模块覆盖：
- 业务契约：登录鉴权、课程/分集/考试/证书/订单等核心流程的接口行为
- 数据完整性：数据库迁移一致性、备份快照可恢复、上传文件落盘校验
- 运行时约束：进程启动、健康探针、端口与内存预算
- 构建产物：前端双端可构建、产物引用路径正确
设计原则：只增不减。每个新功能必须同步追加它的验收检查，禁止为了「绿灯」弱化任何一条。
检查的历史修订全部留在 git 记录里，可追溯。
双模型编排：Pro 决策，Flash 执行
验证体系之外，值守体系解决「上线之后谁来盯」的问题：
- DeepSeek-Pro 编排：周期性读取 CI 运行记录与三节点健康状态，判断「一切正常」还是「需要处理」。 正常 → 归档快照；异常 → 生成一张 Flash 任务卡。
- DeepSeek-Flash 执行：任务卡里是固化的诊断脚本（复现命令 + 预期输出 + 验收命令）， 只读诊断为主，非生产修复可执行，生产变更永远留给人按按钮。
红线很明确：AI 可以发现问题、给出方案、固化脚本，但生产的写操作永远由人审批。 这条红线不是对 AI 的不信任，而是把「责任归属」焊死在流程里——出了任何事，都有一个人、一条审计记录。
这套体系的真实记录
$ node scripts/verify.js all
[PASS] CH01:2 [PASS] CH02:2 [PASS] CH03:5 [PASS] CH04:4
[PASS] CH05:7 [PASS] CH06:4 [PASS] CH07:4 [PASS] CH08:3
…（30 个模块 / 83 项全部通过）
汇总：83 通过，0 失败以及一次故意的故障演练：手动停掉 dcc-server 容器，自动值守在分钟内产出诊断记录与恢复建议， 恢复动作由人执行——线上从不可见到恢复，全程有记录可查。
对客户意味着什么
- 交付质量是机器证明的，不是口头保证的——每个版本都有 83 项断言背书。
- 需求变更的代价可控：改一行代码，机器用 6–10 分钟告诉你有没有改坏。
- 线上出问题有人先发现：自动值守先于用户报障产出诊断与建议。
- 人不被琐事绑架：重复劳动交给 Flash，人只做决策与审批。