State Machine · Diagram Design

StepCode 反馈处理流转

三个渠道(各带负责人与回收方式)→ 登记分流 → 复现 → 定级 → 开发 → 验收 → 告知用户 → 归档;每个状态标负责人与动作,右侧三条异常分支 + 验收打回 + 每日截止线。

StepCode 反馈状态机(详细版) 反馈从三个渠道进入,经待审核、复现中、已确认、开发中、待验证、待回流到已修复的七态流转;含三个渠道的负责人与回收方式、每个状态的负责人与动作、P0 快速通道、等待用户、不修了三个分支、验收打回,以及每日截止线。 飞书社区群 负责人:孟祥雨 纯手动:扫话题 · 回复 · 填表 GitHub Issues 负责人:罗晓阳 + 孟祥雨 API 拉 issue + 手动分诊回复 微信群 负责人:周旭 微信本地导出(WeChatMsg) ① 待审核 渠道负责人(孟 / 罗 / 周) 补全信息登记进表 · 24h 内分流完 ② 复现中 孟 + 罗分担 · QA 到岗后接 按步骤重试复现,填复现状态 / 复现人 ③ 已确认 PM 周旭 · 16:30 定级完 定 P0–P3 或拒绝 · 指派 Dev · 填 ETA ④ 开发中 Dev(研发同学) 修复并提交 PR,填预计完成时间 ⑤ 待验证 验收实习生 · QA 到岗后主责 修复版本上重放:必现 1 次 · 间歇 ≥3 次 ⑥ 待回流 线 owner(该产品线负责人) 3 天内回原渠道告知 · 填回流状态 ⑦ 已修复 系统 · cron 自动 须已告知用户 · 每小时归档 P0 快速通道(最严重问题) 崩溃 / 数据丢失 / 安全漏洞 大面积不可用 / 迁移被卡住 → 1h 拉群:周 + 实习生 + Dev 当天答复用户 · 先处理后补登记 跳过排队,直接进 ④ 开发中 等用户补充(复现不了时) 按模板向用户追问,最多 3 次 · 等 2 周 补充到位 → 回到 ② 复现中 两周无回应 → 不修了(回话说明) 不修了:非问题 / 重复(终态) PM 判定非问题或与已有反馈重复 回原渠道说明原因后关闭 重复挂父记录 · 可申诉一次 两扫 12:30 / 18:00 当天 15:30 分流完 复现成功(可复现) 定级完成 · 指派 Dev 修复提交(挂 PR) 重放不重现 · 填验收记录 已告知 · 用户确认 判 P0 复现不了 定级拒绝 2 周无回应 仍重现 · 退回重修 附验收记录 · 优先级不降 ◆ 结束:用户拿到答复,问题归档;高频问题沉淀进 FAQ 每日截止线:15:30 分流完 → 16:30 定级完 → 18:00 Dev 接单完;18:00 后新反馈流到明天(P0 除外) LEGEND 正常流转 P0 · 打回 等待 / 终止分支 终态 框内第二行 = 负责人 · 第三行 = 做什么