企业官网建设流程全解析

一次内容更新可能同时改变图鉴正文、神兽关系、讲解提示词和客户端展示。若这些变化只靠“打一个新包、发布一批内容”分别推进，出现异常时很难判断该停掉应用版本、撤回内容，还是切回讲解策略。更稳妥的做法，是把它们收束为一份可追溯的发布候选，并让灰度、回滚和观察期都围绕这份候选运行。

本文给出山海万灵的发布候选与灰度门禁方案。重点不是增加页面入口，而是让探索、展厅、图鉴、馆长讲解和护照这些既有旅程，在版本切换期间始终能知道自己使用了哪一组内容与策略。

从一次“内容变更”变成可识别的候选

候选不应只记录应用版本。对于文化知识类产品，内容批次、图谱版本和讲解 Prompt 同样会改变用户看到的结果；数据库迁移、资源清单与回归报告则决定候选能否被复现。发布系统把这些对象固定到同一个candidateId，每次扩量、暂停和回退都写入同一条时间线。

候选建立后不可原地修改。内容或 Prompt 有任何补丁，都生成新的候选版本；这样既能保留问题发生时的实际组合，也不会把后来的修复误记成旧版本行为。

type CandidateState = 'DRAFT' | 'READY' | 'CANARY' | 'PAUSED' | 'ROLLED_BACK' | 'PROMOTED' interface ReleaseCandidate { candidateId: string appVersion: string contentBatchId: string graphVersion: string promptVersion: string migrationId: string regressionReportId: string createdAt: string createdBy: string state: CandidateState } function freezeCandidate(input: Omit<ReleaseCandidate, 'candidateId' | 'state'>): ReleaseCandidate { assertNonEmpty(input.appVersion, 'appVersion') assertNonEmpty(input.contentBatchId, 'contentBatchId') assertNonEmpty(input.graphVersion, 'graphVersion') assertNonEmpty(input.promptVersion, 'promptVersion') assertNonEmpty(input.regressionReportId, 'regressionReportId') return { ...input, candidateId: createStableId(input.appVersion, input.contentBatchId, input.promptVersion), state: 'READY', } }

门禁按“能否恢复用户旅程”组织

构建成功只是候选入场券，不是发布结论。山海万灵的核心旅程至少包括：打开首页后进入图鉴或展厅、查看一只神兽的出处与关联、发起馆长讲解、完成一次探索并回看护照进度。门禁应围绕这些连续动作采样，而不是只统计接口成功数。

每一项门禁都应给出可读的失败原因。例如内容批次缺少来源字段时，阻止内容切换；图谱关系计算异常时，保持已发布的图谱版本；讲解服务超时则走明确的本地讲解降级。用户看到的是稳定的可用路径，发布后台保存的是可复盘的技术原因。

interface GateResult { name: string passed: boolean reason: string } function evaluateGates(candidate: ReleaseCandidate, report: RegressionReport): GateResult[] { return [ { name: 'candidate-components', passed: hasAllVersions(candidate), reason: '候选清单完整' }, { name: 'core-journeys', passed: report.coreJourneyPassed, reason: report.coreJourneySummary }, { name: 'content-provenance', passed: report.contentAccepted, reason: report.contentSummary }, { name: 'migration', passed: report.migrationVerified, reason: report.migrationSummary }, ] } function canEnterCanary(candidate: ReleaseCandidate, report: RegressionReport): boolean { return candidate.state === 'READY' && evaluateGates(candidate, report).every((gate) => gate.passed) && report.blockingDefects === 0 }

灰度不只是百分比，更是一条可停止的决策链

灰度的目标是把影响范围控制在可观察、可回退的窗口内。第一批用户应通过稳定哈希或白名单确定，避免同一用户在反复启动时来回切换候选。每次扩量都记录样本规模、开始时间、指标快照和决策人；如果任一停止条件触发，系统立即冻结扩量并把候选标记为暂停。

对山海万灵而言，除了崩溃率，还要观察“核心探索成功率”和“馆长降级比例”。前者反映用户能否完成查看、探索和进度回读，后者反映讲解策略是否让服务频繁退回本地内容。单次网络波动不应直接回滚，但连续窗口恶化必须阻断下一次扩量。

interface CanaryMetrics { crashFreeRate: number coreJourneySuccess: number curatorFallbackRate: number sampleSize: number observedMinutes: number } function decidePromotion(metrics: CanaryMetrics): 'EXPAND' | 'HOLD' | 'ROLLBACK' { if (metrics.sampleSize < 200 || metrics.observedMinutes < 30) return 'HOLD' if (metrics.crashFreeRate < 0.995) return 'ROLLBACK' if (metrics.coreJourneySuccess < 0.98) return 'ROLLBACK' if (metrics.curatorFallbackRate > 0.15) return 'HOLD' return 'EXPAND' } function nextTraffic(currentPercent: number): number { const ladder = [1, 5, 20, 50, 100] return ladder.find((value) => value > currentPercent) ?? 100 }

回滚先选最小影响面

不同组件的回退成本不同。内容批次、图谱版本和 Prompt 可以优先切回上一个已验证版本；应用包回退需要考虑商店审核与用户安装状态；数据迁移若包含不可逆变更，则必须用兼容读写和补偿迁移避免破坏用户进度。因此回滚命令不能只写“恢复旧版本”，而要带上目标组件、目标版本、原因、操作者和验证结果。

interface RollbackCommand { candidateId: string component: 'CONTENT' | 'GRAPH' | 'PROMPT' | 'APP' targetVersion: string reason: string requestedBy: string } function executeRollback(command: RollbackCommand): RollbackResult { assertNonEmpty(command.reason, 'reason') const target = findVerifiedVersion(command.component, command.targetVersion) if (!target) return { ok: false, code: 'TARGET_NOT_VERIFIED' } const result = switchTraffic(command.component, target) writeReleaseEvent(command, result) return result }

观察期结束前不把“已发布”当作结论

候选完成全量扩量后，仍需要一个固定观察期。观察期间汇总崩溃、核心旅程、内容异常、讲解降级和人工反馈，并用候选 ID 把日志、指标和问题单关联起来。没有触发停止条件时，候选才进入正式稳定状态；出现趋势性异常则回到暂停或回滚状态，而不是靠一次人工刷新掩盖问题。

观察指标还要区分“可接受的降级”和“需要处理的故障”。例如馆长讲解在网络不可用时返回经过来源约束的本地文本，用户仍能完成阅读和探索，这类降级应被记录并计入比例，却不能被当作成功的远端讲解。反过来，图鉴详情无法显示出处、探索完成后护照没有回读到新进度，虽然页面没有崩溃，也应记为核心旅程失败。这样的口径能避免指标只描述服务是否存活，却遗漏用户是否真的走完关键动作。

观察期内的事件最好携带候选 ID、组件版本、用户分桶和旅程节点，但不收集神兽阅读内容、讲解全文或可识别身份。排障人员可以据此比较不同候选的失败分布：问题集中在某个内容批次时先回退内容，集中在某个 Prompt 版本时先切换策略，集中在客户端构建号时停止扩量。日志既支持定位，又不会把文化阅读行为变成不必要的追踪数据。

回滚完成也不能直接关闭问题。系统应重新执行受影响的核心旅程，并确认旧候选的内容、图谱与讲解策略已经同时生效；若客户端已缓存新资源，则通过版本清单触发安全失效或保留兼容读路径。复盘记录至少包含触发信号、决策时间、实际影响范围、回滚耗时和再次发布前需要补齐的门禁。下一份候选只能引用已关闭的复盘项，不能沿用模糊的“上次应该没有问题”。

实施可以分四步推进：先落地候选清单与冻结规则，再接入核心回归报告；随后加入稳定分桶与指标阈值；最后串起组件级回滚、观察期报表和复盘记录。每一步都保留可独立验收的输入、输出和失败分支，避免把发布治理做成只在上线当天才使用的表格。

验收时应核对同一个候选是否能完整回答四个问题：它包含哪些版本；为什么允许扩量；发生异常时先回退什么；观察期结束后依据什么结论归档。把这些问题变成系统记录，发布就从一次临时操作变成可重复执行的工程流程。

参考资料：HarmonyOS 应用发布文档。