问题是怎么来的
我们团队的发版信息长期散落在多个平台：Confluence、石墨、腾讯文档。
每次有人问“某机型当前版本是什么”“上个版本到底发了哪些功能”，都要跨系统翻很多页面，还要人工比对版本号，沟通成本很高。
我想先解决一个最实际的问题：给团队一个统一、可直接访问的发版入口。
第一版做了什么
第一版是一个周末做出来的轻量看板，目标很明确：先把信息聚合起来。
当时的能力包括：
- 各机型（S6、S2、S1、E1）版本状态一览
- 发版计划与历史记录聚合展示
- 按机型、状态快速筛选
那时它更像一个“信息中台页面”，解决的是“找不到、找不全、找得慢”。
为什么继续迭代
上线后我发现一个更关键的问题：
发版看板只能回答“我们发了什么”，但回答不了“这些发版有没有解决真实用户问题”。
所以后续的迭代重点从“版本信息聚合”转向了“发版价值闭环”。
当前能力（截至 2026-07-01）
现在这个平台已经从单一看板扩展成一个小型的发版运营工具，核心包含 4 块：
- 发版记录
- Confluence + 石墨数据整合
- 按版本、机型、状态查看发版项
- 用户声音
- 工单 / 用户反馈 / 门店反馈统一查看
- 支持筛选、搜索、上传更新
- 用户声音闭环
- 把“可感知发版项”与工单/反馈自动关联
- 支持人工确认、触达标记
- 支持 CSV 和 Markdown 汇报导出
- NPS
- 支持月度数据导入与趋势查看
此外，还做了性能与运维能力：
- 首屏懒加载（先加载发版记录，用户声音按需加载）
- 数据接口 gzip + 缓存
- 本地定时同步（工作日自动更新）
迭代时间线（详细版）
| 时间 | 阶段 | 当时的核心问题 | 我做的动作 | 结果 |
|---|---|---|---|---|
| 2026-05-08 | v0 初始化 | 发版信息散落，查询成本高 | 搭建第一版发版看板 | 有了统一入口，先解决“找信息”问题 |
| 2026-06-12 | 多视角整合 | 只看发版不够，用户侧问题看不到 | 扩展成“发版记录 + 用户声音 + NPS”多 Tab | 团队能在一个页面看“发版 + 反馈” |
| 2026-06-23 | 数据架构重构 | 数据内嵌 HTML，更新和维护成本高 | 改为 data/*.json 独立加载 |
数据更新、脚本处理、部署都更可控 |
| 2026-06-24 | 闭环功能上线 | 无法系统回答“这次发版解决了谁的问题” | 上线“用户声音闭环”能力，支持关联确认与导出 | 发版复盘从口头讨论变成结构化台账 |
| 2026-06-24 | 性能优化一期 | 首屏加载慢（大体量工单/反馈数据） | 懒加载 + gzip + 缓存策略 | 首屏可用性明显改善 |
| 2026-06-26 | 分析体验优化 | 反馈页可读性一般，洞察不直观 | 新增数据洞察卡片、词云筛选/清除、布局优化 | 反馈分析效率更高，支持更快定位问题 |
| 2026-07-01 | 同步稳定性修复 | 工单同步受 cookie 失效影响，定时任务易中断 | 认证改为 ic 动态 cookie 优先，文件 cookie 兜底 |
定时同步稳定性提升，日常维护更省心 |
我做过的两个关键“非功能”改动
1) 把“手动更新流程”变成“定时可运行流程”
除了页面能力，我补了本地同步脚本和定时任务（macOS launchd）：
- 工作日固定时段自动同步发版与工单
- 每小时处理收件箱导入文件
这样日常维护不再依赖“我记不记得手动点一次”。
2) 把“偶发失败”变成“可恢复”
内网认证这类链路非常容易因为 cookie 过期失败。
我后来把工单同步做成了“动态认证优先 + 文件兜底”，并补了可读日志和失败提示。即使认证链路抖动，也不会像之前一样直接卡死在日常流程里。
现在回看这个项目
这个项目最开始只是一个周末小工具，但现在它在团队里的价值已经变成三件事：
- 信息统一：发版信息有单一入口。
- 价值可追踪：发版动作和用户反馈可以串起来。
- 维护可持续：更新流程自动化，日常成本更低。
我很喜欢这类项目：从一个具体痛点出发，先做能用的 MVP，然后围绕真实使用场景不断补齐，最后慢慢长成一个真正能帮团队省时间的内部产品。