让产品每次升级，
都有一套持续保障。

第一阶段由 Nada先把“新闻内容质检＋新闻提问后的 AI 回答”做成样板。第二阶段由 Nada统筹测试环境，把 Bear 后台和 Ice App 接入同一验收流程。第三阶段的完整自动化运维暂缓。

常规路径：开发留痕 → 自动检查 → 独立验收 → 模块负责人发布 → 发布后验证。

持续质检：生产留痕 → 定期检查 → Buglist → 修复 → 独立复验。

紧急路径：事故确认 → 有权负责人授权 → 最小修复先发布 → 验证恢复 → 补独立验收。Agent 离线、失败或没有结论不能锁死紧急发布。

授权按阶段和范围打包。Bear、Ice 保留原有开发方式，提供候选产物、确认影响并修复本模块问题；交付记录由 Agent 起草，不重复填报。

Agent 不代理业务授权。验收身份不得持有生产发布权限。

按 A1 至 A6 执行；前一包形成的标准和证据作为后一包输入。

第一阶段不依赖 Bear、Ice 新建环境。跨模块证据缺失时登记缺口，不宣称已做完整 App 验收。数据关联复用内部基线；历史快照不等于当前线上认证。

出口闸与质检分工

翻译、热点卡、chat、Bear 质检分别核对实际调用路径和运行版本。已有闸优先复用，验证是否有效；语义质检补查闸外问题。没有闸的出口明确标示只能事后发现。

明确可检测的严重错误应在出口拦截。样板内发现缺口纳入修复；样板外列入后续范围，不能用“定时质检”代替出口保护，也不能因此无限扩大本期。

质检步骤与结论

取得新增记录 → 组装原文、上下文、来源及版本 → 判断证据完整性 → 确定性检查 → AI 语义检查 → 保存证据与结论 → 归并问题。

代码检查字段、枚举、数量换算和可确定的金额单位关系；AI 检查相关性、原文歪曲、遗漏有用补充、无依据结论。特别覆盖“已提供证据，却回答没有查到”的情况。

主观怀疑不自动无限阻断发布。产品预期争议由 Gary 决定。校准使用正常、错误、证据不足三类样本，另保留未参与调试的验收集；固定验收集中约定严重错误全部检出且依据正确，正常样本不得误认定为已确认严重缺陷。结论只适用于该验收范围。

样本、调度与成本

先统计最近一个完整工作周的实际产量，区分原始内容、语言版本、生成次数。历史数字只作复核线索。

初期每天运行一次。按输入、输出、检查器版本去重，重检记录理由；有限重试、保存进度、记录超时和费用。失败、漏跑、额度不足均是未完成。异常优先样本与普通抽样分别报告，不混算总体错误率。

上游字段结构变化、认证失败、数据断供单独分类，关联最后成功记录和影响范围；不得自动改上游 schema 或轮换凭据。

模拟费用保留为 200 条/天 × $0.005–0.03/条 = $1–6/天，尚未实测，不代表当前业务量。执行机、生成、搜索、复核、重试另计。小批实测后按对象池计算成本，Gary 在获批范围内确认单批、日、月限额；未配置额度不启用付费调度。

独立小型 Linux 执行机承载队列、调度、报告和隔离任务。理由是避免争抢生产资源、避免与被检服务同时失效、隔离测试代码和生产凭据。现有 Vultr 规格与负载需实测，历史 CPU 瓶颈不能作为当前值直接引用。

调度常驻、Agent 按任务启动退出；独立工作目录，限制时间、资源和费用；队列持久化，重启识别未完成任务。生产证据限定范围只读导出。开发与验收分离上下文，验收可写测试数据和报告，不能写生产。Mac 仅用于开发调试。

每次任务绑定任务 ID、候选版本、环境版本清单、测试集版本、检查规则版本、结论、证据位置和实际费用。提示词或关键配置变化也需重新执行受影响检查。

检查系统自身监控

Nada维护，执行机之外的探针检查心跳及应完成任务。默认每 5 分钟心跳，连续 15 分钟缺失通知负责人；批次完成窗口在小批试跑后固定并写入任务配置。日报只汇总，不能代替告警。

阶段启用前确定实际通知渠道并验证送达。测试停止执行机、停止调度、任务卡死三种情况；每种必须被检测并留下通知证据。不能依赖已经停止的执行机自己告警。

首次与持续交接

Bear 首次提供部署材料、依赖、数据库初始化、测试权限、接口及外部副作用清单；后续提供候选版本、迁移或配置变化及影响范围。

Ice 首次提供可连接测试环境的包、安装构建说明和身份要求；后续提供候选包、版本标识和影响范围。Android 为首期默认，iOS 不在本期。

Nada提供 AI 部署、数据、调度、规则和报告入口。Gary 明确产品预期，协调权限和资源。Agent 整理记录，各方确认准确性。

环境和用例

服务、数据库、涉及的 Worker/D1/KV 与生产隔离；身份、密钥、回调独立。推送、支付、邮件关闭或指向测试接收端。误指生产配置拒绝运行。有初始化、重置、清理和保留失败现场的入口。

初期一套共享测试环境，排队锁版本，不在测试中替换部署。App、后台、AI 及关键配置均展示实际版本。

首批用例：新闻标题正文和语言；从新闻提问的关联；回答完整和证据一致；切后台恢复；断网重连和重复点击；新旧接口及在途任务；服务或上游失败反馈。每条提前确定输入、步骤和预期，歧义由 Gary 决定。

固定操作自动执行，Agent 分析截图和日志。切后台、断网恢复包含真机测试，模拟器不能替代。自动化暂不稳定时由 Ice 或指定人员按同一脚本执行，明确标记人工证据。

常规验收

按行为影响选检查，不按行数或文件类型。局部展示做页面和冒烟；模型、提示词、生成逻辑做语义与历史回归；API、数据、回调、共享配置做兼容及联调；App 网络与展示做设备场景；跨模块做完整版本组合、部署顺序及失败处置验证。

PASS 表示约定检查完成、无范围内阻断缺陷、版本一致；FAIL 表示已确认阻断缺陷；BLOCKED 表示条件不足或执行未完成。核心路径不可用、重要事实错误、数据损坏、契约或安全边界失效、版本不一致、必测未完成，阻断常规发布。无关普通问题留 Buglist。

模块负责人在范围内决定常规发布。发布后核对实际版本、检查原路径及新增异常，按授权执行后续处置。

紧急发布通道

生产事故、严重错误或必须立即处置的问题可启用，普通赶进度不适用。单模块由模块负责人授权；跨模块由 Gary授权。Agent 不能自行宣布紧急并绕过生产授权。

1. 发布人先记录问题、候选修复版本、影响范围、授权人、失败处置方式；可简短记录，随后补全。

2. 尽可能做针对性最小检查；未执行项明确保留，不等待完整 Agent 结果。

3. 使用独立于验收平台的既有发布入口。Agent 不可用、报告服务故障或未完成不得技术性锁死紧急上线。

4. 发布人立即核对版本、故障是否缓解、新增异常；不能等补验收才检查恢复情况。

5. 恢复后 24 小时内由 Nada组织独立验收，模块负责人配合。事故尚未恢复则持续处置并报告，不得搁置。

6. 补验收失败或逾期，通知负责人并登记原因、下一步和期限；不自动转 PASS，不自动回滚，不自动关闭。

不方便回撤时允许向前修复、暂停写入或任务、关闭入口、切兼容路径、限制影响并保留现场。发布前明确谁负责及失败后的下一动作，不强制可回滚作为前提。未授权的数据删除、契约变化等不能由 Agent 自行扩大执行。

发布状态、验收状态、事故状态分别保存。允许显示“已紧急发布／待补验收／已缓解”；上线成功与恢复正常均不等于验收通过。

第一阶段：A1–A6 通过；固定验收集严重错误检出有依据，正常样本不被误确认为严重缺陷，缺证据正确标示；闭环至少一例；重复、超时、额度不足和失联不产生假通过；连续一周有完整批次账；交付实测成本、人工复核负担和盲区。

第二阶段：B1–B5 通过；生产隔离实测；候选可部署、锁定、重测；首批链路和真机用例通过；已知缺陷候选不被误判通过；漏跑、版本替换和环境故障不能产生 PASS；常规及紧急通道演练通过；再完成一次经授权的真实候选发布和发布后验证。

第一阶段 3–5 周量级，前提为稳定人员投入、执行资源和试测额度；第二阶段材料资源齐备后 4–8 周量级。是规划估算，不是承诺。A1 后细化排期，外部等待单列。

启动前确认阶段范围、资源预算、权限、通知渠道；第二阶段另确认 Bear/Ice 交接时间和真机。未落实项记为待办，不据此声称已经上线。

• 阶段与样板范围：
• Nada、Bear、Ice、Gary 联系入口：
• 资源目标及生产隔离证明：
• 单批／日／月费用上限及授权依据：
• 调度时区、执行时间、批次完成窗口：
• 外部探针位置、通知渠道、送达验证：
• 允许的操作、禁止的操作、生产授权边界：
• 未落实条件、负责人及下一步：

未填写预算不启用付费任务；未确定环境隔离不执行远程测试写入。

• 变更 ID、目标、预期行为：
• 候选代码／产物／提示词／配置版本：
• 影响范围及负责人确认：
• 测试环境实际版本清单：
• 测试集与检查规则版本：
• 自测结果及证据：
• 独立验收任务 ID：
• 必测项、实际执行、预期与实际结果：
• PASS／FAIL／BLOCKED，依据及覆盖限制：
• 遗留问题及对应 Buglist ID：
• 发布人、授权依据、部署顺序、失败后处置：
• 发布后实际版本与冒烟证据：

• 批次 ID、检查窗口、检查器版本：
• 对象池、总记录数、符合范围数量：
• 优先样本与普通样本分别计数：
• 已检查、去重跳过、失败、未覆盖数量及原因：
• 结论、问题 ID、证据位置：
• 模型费用、生成／搜索／重试等分项费用：
• 开始／结束时间、心跳、重试、最终状态：

去重与抽样规则必须能解释计数；异常样本比例不作为总体错误率。

• 问题 ID、模块、负责人、影响：
• 首次与最近发生、实例 ID 列表：
• 版本、证据、复现或无法复现原因：
• 待确认／已确认依据：
• 当前状态、下一步、期限：
• 修复版本、独立复验任务及结论：
• 发布状态、生产验证、关闭依据：
• 误报／重复／暂缓原因（适用时）：

• 事故 ID、触发原因、单模块或跨模块：
• 授权人及依据、执行人：
• 修复版本、影响范围：
• 已做最小检查及未完成项目：
• 回退或向前修复／暂停／关闭功能方案与负责人：
• 发布时间、实际版本、恢复检查证据：
• 事故状态及恢复时间：
• 独立验收负责人、恢复后 24 小时截止时间：
• 补验收任务、结果；逾期或失败后的决定与新期限：

分别记录发布、验收、事故状态，禁止用“已发布”填充验收 PASS。

服务器稳定性、网络稳定性、数据接口稳定性、bug 监控、防攻击、防数据抓取、系统漏洞均保留在整体范围。前两阶段已有执行系统监控及上游异常检测；完整自动化运维暂缓。

备份与恢复

先核实各数据源备份和恢复能力，后续在隔离目标演练；生产恢复、删除和凭据轮换另列授权。

容量与费用

根据真实负载、配额、积压和人工维护成本决定扩展，不沿用历史规格作为当前事实。

扩展条件

前两阶段稳定维护后，由 Gary 根据用户增长、风险与成本提出范围和预算，审批后再开展多服务自动化、受控恢复及容器或 K8s 评估。