平台下一阶段研发任务清单
日期：2026-04-06
1. 文档目的
本文档基于《平台功能清单与优先级规划》进一步拆解下一阶段研发任务，目标是把方向性结论转成可执行的任务包。
本文档回答四个问题：
- 下一阶段到底先做哪些任务
- 每个任务为什么要先做
- 每个任务的交付结果应该是什么
- 这些任务之间的依赖关系是什么
2. 拆解原则
本轮任务拆解遵循以下原则：
- 先解决平台稳定性和主流程问题，不优先追求更多新功能
- 优先处理会放大维护成本和交付风险的模块
- 尽量把任务拆成能独立验收的任务包，而不是泛泛写“持续优化”
- 先做后续所有扩展都绕不过去的底层收口项
3. 总体排期建议
建议把下一阶段拆成三个批次推进。
第一批次：P0 收口批次
目标：
- 让平台更稳
- 让 TR069 更可控
- 让主业务链开始闭环
建议周期：
- 2 到 4 周
第二批次：P1 业务化批次
目标：
- 让平台更像完整业务系统
- 让后台与前台角色入口更清晰
- 让运维进入批量视角
建议周期：
- 3 到 6 周
第三批次：P2 复制化批次
目标：
- 让平台适合跨现场复制
- 让交付、报表、兼容扩展逐步标准化
建议周期：
- 4 到 8 周
4. 第一批次任务清单
T1 统一 TR069 执行链路
任务目标：
- 收口 set/get/download/reboot 等动作的执行入口
- 减少调试态、过渡态、正式态并存的实现
主要工作：
- 梳理当前不同执行路径与使用场景
- 统一动作分发入口和返回结构
- 统一任务执行成功、失败、排队、超时的状态表达
- 清理长期保留的模拟或临时链路
交付结果：
- 一套统一执行入口
- 一份动作类别与执行语义说明
- 旧链路收口清单
验收标准：
- 同一类动作不再走多套长期并存逻辑
- task 列表、详情、设备事件对执行结果的解释一致
依赖关系：
- 无，是当前最高优先级底座任务
T2 强化 TR069 任务状态机与重试恢复机制
任务目标：
- 提升任务可靠性
- 解决异常中断、重复任务、超时任务、重启后恢复问题
主要工作：
- 统一任务状态流转规则
- 建立失败重试与重试上限策略
- 增加进程重启后 running/pending 任务恢复策略
- 补齐长任务、超时任务、重复任务治理规则
交付结果：
- 任务状态机说明
- 重试与恢复规则文档
- 核心任务恢复实现与对应测试
验收标准：
- worker 异常退出后，任务不会长期悬挂在不可解释状态
- 重复入队、重复执行、重复回读有明确防重策略
依赖关系：
- 与 T1 强相关，建议并行设计、顺序落地
T3 收口自动回读、自愈、写后校验链路
任务目标：
- 把当前自动回读与自愈逻辑统一到正式链路
- 避免前端、任务日志、设备详情各自解释一套状态
主要工作：
- 统一 auto verify、auto reconcile、follow-up verify 的触发条件
- 统一执行成功与验证成功的区分语义
- 统一设备页、任务页、日志页的状态口径
- 补齐关键回归测试
交付结果：
- 自动回读与自愈状态口径文档
- 一套共享状态定义
- 关键回归测试补齐
验收标准：
- “执行成功但验证漂移”不会再被误显示成正常绿色成功
- 设备页与任务页对同一任务给出的结论一致
依赖关系：
- 依赖 T1、T2 的统一状态基础
T4 建立业务主流程联动的最小闭环
任务目标：
- 先做成最小闭环版本，而不是一次做成大而全系统
主要工作：
- 新装绑定后自动初始化
- 续费成功后自动恢复
- 欠费后的限制策略标准化
- 账号、订单、设备、微码的关键状态联动
交付结果：
- 一条可走通的新装到使用流程
- 一条可走通的欠费到续费恢复流程
- 状态联动字段与规则说明
验收标准：
- 新装不再依赖人工逐步补操作才能进入正式使用
- 续费成功后可自动恢复到可用状态
依赖关系：
- 依赖 T1 到 T3 提供稳定的设备执行能力
T5 安全与运维治理基础包
任务目标：
- 先补最基础的线上治理能力
主要工作：
- 配置分层与敏感项治理
- 多环境配置与部署边界梳理
- 基础监控与告警项定义
- 备份、回滚、恢复流程整理
交付结果：
- 配置治理清单
- 基础监控指标和告警规则
- 发布、回滚、恢复操作文档
验收标准：
- 敏感配置不再混杂在代码仓或临时脚本中
- 至少具备最小可用的健康检查、错误告警、回滚路径
依赖关系：
- 可与 T1 到 T4 并行推进
5. 第二批次任务清单
T6 批量运营与异常巡检能力
任务目标：
- 从“单设备处理”升级到“区域运营处理”
主要工作：
- 批量任务发起与跟踪
- 离线设备识别与清理策略
- 长期未上报设备标记
- 参数漂移检测汇总
- 异常任务归因视图
交付结果：
- 区域巡检清单页或看板
- 批量任务基础能力
- 异常归因分类口径
验收标准：
- 运维人员可以按区域或批次处理问题，而不是逐台筛查
依赖关系：
- 依赖第一批次完成统一状态和可靠性底座
T7 后台工作台按角色重组
任务目标：
- 把当前按模块分散的后台，整理成按角色工作的入口
主要工作：
- 客服工作台：订单、欠费、恢复、状态查询
- 装维工作台：绑定、纳管、初始化、诊断
- 运营工作台：区域、续费、在线率、异常率
- 收敛重复入口与重复状态表达
交付结果：
- 角色工作台原型或正式页面
- 原模块与新入口的映射关系
验收标准：
- 不同角色可以在更少页面中完成核心操作
- 重复页面和重复入口明显减少
依赖关系：
- 依赖 T4 已建立最小主流程闭环
T8 前台正式入口收敛
任务目标：
- 明确谁是正式业务入口，避免多套前台长期并行
主要工作：
- 确认正式前台项目与演示型页面边界
- 加固扫码、绑定、支付、恢复、状态查询主链路
- 增加到期提醒、欠费提醒、支付结果反馈优化
- 前后台状态口径统一
交付结果：
- 正式前台范围说明
- 主流程页面收敛结果
- 支付与恢复链路异常处理清单
验收标准：
- 用户入口唯一、稳定、可持续迭代
- 同一状态在前台和后台不再出现明显口径漂移
依赖关系：
- 依赖 T4 已形成业务状态联动基础
6. 第三批次任务清单
T9 现场交付标准化
任务目标：
- 固化成功经验，降低对核心个人经验的依赖
主要工作：
- 不同品牌 ONU 接入 SOP
- 现场网络诊断清单
- 交付验收清单
- Connection Request 不可达场景处理手册
- 直改 ACS 与劫持接管切换标准
交付结果：
- 一套可执行的交付文档包
- 一套现场排障清单
验收标准：
- 新人或非核心成员也能按文档完成标准接入与排障
依赖关系：
- 依赖 T1 到 T8 基本稳定后沉淀最佳实践
T10 数据与报表产品化
任务目标：
- 让平台不只可操作，还能反映经营结果和运维结果
主要工作：
- 区域经营数据沉淀
- 续费、留存、到期分布分析
- 在线率、初始化成功率、恢复成功率统计
- 运营趋势和异常趋势可视化
交付结果：
- 一组核心经营与运维指标
- 区域视角的统计报表页面
验收标准：
- 管理侧可以直接看到区域经营效果与设备运营质量
依赖关系：
- 依赖 T4、T6、T7 已建立更稳定的数据链路
T11 多品牌复制扩展机制
任务目标：
- 在不放大复杂度的前提下继续做多品牌扩展
主要工作：
- 继续沿兼容指纹、能力探测、参数映射推进
- 补齐品牌扩展模板和映射生成流程
- 固化校验回读与兼容诊断流程
- 杜绝重新回到型号特判堆积模式
交付结果：
- 新品牌接入模板
- 品牌扩展操作说明
- 兼容诊断闭环说明
验收标准：
- 新品牌接入主要通过框架扩展完成，而不是临时堆特判
依赖关系：
- 强依赖 T1、T2、T3 已经完成工程收口
7. 推荐执行顺序
如果按实际研发推进顺序，建议如下：
- T1 统一 TR069 执行链路
- T2 强化 TR069 任务状态机与重试恢复机制
- T3 收口自动回读、自愈、写后校验链路
- T5 安全与运维治理基础包
- T4 建立业务主流程联动的最小闭环
- T6 批量运营与异常巡检能力
- T7 后台工作台按角色重组
- T8 前台正式入口收敛
- T9 现场交付标准化
- T10 数据与报表产品化
- T11 多品牌复制扩展机制
之所以把 T5 放在 T4 前后并列，是因为安全与运维治理不应等业务全做完再补，而应该从这一阶段开始同步建设。
8. 建议的最小团队分工
如果按最小可执行团队配置，建议按以下分工推进：
- 后端主力 1：负责 T1、T2、T3 的 TR069 收口
- 后端主力 2：负责 T4、T5 的业务联动与运维治理
- 前端主力 1：负责 T7、T8 的工作台与前台收敛
- 联调 / 实施支持：参与 T6、T9、T11 的现场验证与文档沉淀
如果资源不足，优先保证 T1 到 T5，不建议跳过这部分直接做报表或新品牌扩展。
9. 最终结论
下一阶段不建议再以“继续补功能”为主，而应以“收口能力、建立主流程、夯实治理、准备复制”为主。
从任务角度看，最关键的是先做五件事：
- 把 TR069 执行链路统一
- 把任务可靠性和恢复机制补强
- 把自动回读与自愈链路收口
- 把业务主流程做成最小闭环
- 把安全与运维基础治理补起来
只有这五件事做稳了，后续批量运营、角色工作台、前台收敛、交付标准化和多品牌复制才会真正变成“放大能力”，而不是“放大复杂度”。
作者：wuge 创建时间：2026-04-06 17:03
最后编辑：wuge 更新时间：2026-04-06 17:03
最后编辑：wuge 更新时间：2026-04-06 17:03
