从 PRD 到上线放量：全栈需求交付检查表

需求交付不是把 PRD 拆成前后端任务就结束。真正的闭环是目标有证据、接口有契约、失败可恢复、上线可观测、问题可回退。

一、把需求变成可验收问题

写明目标用户、触发场景、当前痛点和预期变化；区分目标、非目标、假设与依赖。
用主流程和异常流程描述真实操作：空数据、重复点击、弱网、权限不足、超时、取消、历史数据和移动端窄屏都不能留成“后续再看”。
为每个结果定义可验收行为和数据口径，确认埋点究竟统计曝光、点击、成功还是最终业务结果。
标识敏感数据、授权、留存、审核、投诉和删除要求，避免上线后才补合规边界。

二、方案与接口契约

前端列页面状态机、路由、状态来源、缓存失效和可访问性；后端列接口字段、状态码、权限、限流、幂等与分页；数据层列 schema、唯一约束、索引、迁移、回填和兼容窗口。对跨服务字段提供 JSON 示例，说明空值、枚举、时区、金额单位和版本兼容规则。

不要用“成功/失败”两个布尔值表达所有状态。上传、审核、异步任务、消息和支付等流程需要明确状态转换、重复请求行为、取消机制、超时策略和人工处理入口。日志与埋点只保留分析所需字段，不复制正文、凭证或个人敏感信息。

三、拆解与测试

任务要能独立验收，明确 owner、依赖、开关、回滚和阻塞。测试覆盖单元、API 契约、权限矩阵、数据库迁移、端到端主路径、浏览器兼容、移动端触控、性能预算和可访问性。针对关键失败点设计故障演练：队列重复投递、缓存不可用、第三方超时、客户端断开和转换失败。

每条验收标准都可映射到测试或观测指标。只验证代码覆盖率无法证明业务口径正确；埋点需要用真实请求核对字段、重复上报、登录切换和隐私脱敏。

四、发布前闸门

变更清单、代码评审、依赖风险和数据库迁移通过。
灰度目标人群、观察窗口、错误/性能阈值、暂停人和回滚步骤明确。
配置与代码发布顺序可兼容；旧客户端、旧数据和旧服务不会立即被破坏。
面板、告警、客服/运营答复和用户提示已就绪。
备份真实可恢复，回滚不依赖唯一操作者临场记忆。

五、上线与复盘

按小流量或内部用户启动，按版本/人群观察成功率、P95、崩溃、队列积压、关键漏斗和投诉，而不是只看首页 200。超阈值即暂停放量；先区分代码、配置、数据和下游故障，再选择功能关闭、代码回退或数据修复。上线后记录影响、发现时间、恢复时间、有效动作和可验证的后续改进，不把复盘写成责任归因。

需求变更与范围控制

评审后建立基线：目标指标、非目标、验收条件、责任人、接口版本、上线窗口和待决问题。新增需求要说明它替代哪项优先级、影响哪些端/API/数据/测试、是否改变风险和发布时间；产品确认后同步相关文档与任务。紧急变更可以走轻量流程，但要记录决策人、原因、验证范围和补充评审时间，不能把“先做了再说”变成默认路径。

将需求拆为可交付切片，每片都能独立演示并验证，不把前端、后端和测试拆成互相等待的大阶段。对未知项先做短期验证任务，明确验证结果如何改变方案；估算同时列出依赖、联调、数据迁移和发布观察时间。延期时优先减少低价值范围或分阶段发布，不通过跳过权限测试、数据核对和回滚准备来伪造进度。

交付模板可以缩短沟通，但不要让检查表变成机械签字。真正有价值的是把高风险、不确定和跨团队依赖提前暴露。

会议与交接输出

评审结束后把未决问题转成有 owner 和截止时间的事项，而不是留在聊天记录里。方案变化要同步 PRD、接口文档、验收标准、埋点字典和测试数据；变更原因也要记录，避免产品、研发和测试各拿一份旧口径。临上线交接说明开关默认值、观察面板、告警联系人、支持话术和回滚入口。指标口径未统一时要显式标为风险，不能用上线后的报表倒推成功标准。

上线后回看目标是否有证据、异常流程是否出现、反馈是否改变优先级，以及临时埋点/开关是否按期清理。只把证据支持的结论沉淀为通用实践；工作中的内部标识、域名、包名、用户数据和未公开指标不能直接搬进公开文章。

参考：Google SRE Workbook：Canarying Releases 与 OWASP Application Security Verification Standard。