论坛扩展上线前的复盘模板

扩展类改动最容易出现「功能没问题、体验出问题」的情况，因为它往往牵动既有页面的加载顺序、权限判断与数据读写。复盘的目的不是追责，而是把这次上线中隐性的判断显性化，形成下次可直接套用的检查结构。本模板适用于新增互动模块、调整权限逻辑、接入外部服务、改造消息通知等场景。

一、复盘范围与时间窗
先界定复盘覆盖的时间段：从改动合并到上线后观察期结束。范围要包含受影响的页面与角色，而不只是新功能本身。列出本次改动的三类影响面：直接功能、被复用的公共组件、依赖的配置与数据。注意不要把范围无限扩大，一次复盘聚焦一次上线，跨多次改动混在一起会导致结论无法归因。判断标准：复盘结束时，能否用一句话说清「这次改了什么、影响了谁」。

二、记录结构：事实、判断、结果
分三栏记录。事实栏只写可观察的现象：哪个页面在什么操作下出现什么表现，出现频率与影响角色，不写推测。判断栏写当时的决策依据：为什么选这个方案、放弃了哪些备选、依据是什么信息。结果栏写上线后的实际表现与预期差异。三栏分开的好处是事后能区分「决策错」还是「执行错」。注意事实栏避免使用「感觉慢」「好像有问题」这类描述，换成可复现的步骤与可观察的现象。

三、问题归类的判断框架
把问题按四个维度归类：需求理解偏差、设计遗漏、实现缺陷、环境差异。需求理解偏差表现为做出来的东西与预期用途不符；设计遗漏表现为边界场景未覆盖，如空数据、超长内容、重复提交；实现缺陷是代码层面的错误；环境差异是配置、缓存、版本不一致导致。归类时问三个问题：这个问题在测试环境能否复现？是否只在特定角色或特定数据下出现？是否与加载顺序或缓存有关？归类清晰后，改进项才有针对性，否则容易一律归结为「测试不够」。

四、改进项的可执行化
每条改进写成「动作+负责人角色+完成标志」，避免写成「加强测试」这类无法验收的表述。例如把「加强测试」改写为「为权限判断补充三类角色的用例，覆盖无权限、越权、正常三种路径，用例可重复执行」。改进项数量控制在少数几条，优先处理能防止同类问题复发的项。注意区分「这次必须补」与「长期优化」，前者进入近期清单，后者单独记录，避免清单膨胀后被搁置。

五、沉淀与回看
复盘产出三样东西：一份事实记录、一份归类结论、一份改进清单。把归类结论中反复出现的模式提取成上线前检查项，比如「涉及权限的改动必须覆盖三类角色」「涉及列表的改动必须验证空数据与超长内容」。设定一个回看节点，检查改进项是否落地、同类问题是否再出现。回看时不看决心看证据：用例是否真的存在、检查项是否真的被执行。长期坚持，复盘的产出会从文档变成团队的条件反射。