**结论：分析时的代码版本仍有需要修复和验证的问题。最优先处理的是：系统补齐发音时，可能把人工尚未发布的修改一并发布。**

本轮记录17项明确问题（P1一项、P2十六项），另有2项需要明确规则的条件风险。P1表示本轮优先处理；P2表示影响局部功能或需要特定条件触发，仍需安排修复与回归。

本报告依据2026年11月4日的需求与当时固定代码版本。后来已单独交付修复代码和改动矩阵，但没有据此认定测试环境已经部署、业务已经验收，下面描述的是本轮分析发现的问题。

## 先理解本次改动

| 业务操作 | 改动前 | 改动后 | 测试要重点看什么 |
|---|---|---|---|
| 题目同步 | 同步提交后直接处理可查词内容 | 同步先完成，后台稍后处理 | 处理延迟或失败时，正文和可点击词不能配错 |
| 题目首次发布 | 带上已有处理结果 | 先准备后续处理记录，再由后台计算 | 先发布、后算完能否自行恢复，不能要求人工重复发布 |
| 新词发音 | 建词时等待生成 | 先建词，之后统一生成和补齐 | 等待期间的人工编辑、失败次数、超时和后续更新 |
| 词条发布 | 人工发布后学生可见 | 发音补齐后，部分词还会由系统再次发布 | 系统只能补已确认的内容，不能带出人工草稿 |
| 查询短语 | 按一次命中的原形或变形取详情 | 取短语及其全部变形，再选择对应内容 | 对应变形的音标、发音和显示顺序不能错 |
| 短语维护 | 其他服务可能较晚拿到新词库 | 增加了更快通知和检查机制 | 暂时拿不到新词库时，不能把旧规则算出的结果当成新结果保存 |

## 本次验证能证明什么

已重新核对需求正文、评论和代码，并运行了部分独立复现程序。它们能够证明所列处理分支存在问题，但没有执行真实业务数据库、消息处理、发音平台或客户端全流程，因此不写“线上已发生”或“业务验收通过”。

下面每项都按“发生条件—预期—实际—影响—验证方法”说明。研发定位与原始证据在报告末尾，阅读正文不需要先理解代码。