两天的方案，胜过两个月的方案

提词器有一个长期存在的痛点：用户弱网环境下切换词稿，加载卡顿，骨架图转半天。解决它的「完整方案」是做一个全量离线版，开发周期半个月到一个月。我们最后用了 2 天。

先算一笔账

全量离线版能解决所有弱网问题，但当时没有大量用户明确要求，投入产出比极低。政府、军队等场景的完全离线版已有对应解决方案，不是我们的战场。一个要花一个月、又验证不了需求的方案，优先级天然靠后。

2 天做了什么

不做离线编辑，不做断网新建。只做一件事：用户登录后，把他名下最近活跃的词稿预加载缓存到本地；直播时切换词稿不再卡顿。其余保持云端架构不变。

为什么这样取舍

提词器的核心场景是直播提词：用户编辑、新建词稿大多发生在直播前，直播过程中只需要切换。痛点只出现在「切换」这一步，那就只解决这一步。

小步快跑，先跑通最小闭环，再根据反馈扩展。不把资源投在用户需求不明确的功能上。

总结

方案不是越大越好，是越贴近核心场景越好。完成好过完美，速度比质量重要。两天的方案，往往胜过两个月的方案——前提是你知道用户真正疼的那一下在哪。