在“快缩短网址”（suo.run）的远程岁月里，我曾在方寸屏幕间，独自与代码、算法、需求鏖战。那段疫情封锁的日子，没有通勤的喧嚣，却多了深夜的键盘声。我把这段经历写成一封长信，寄给所有正徘徊在后台产品迷雾中的同路人。

一、缘起：当旧楼要换新梁
APP 架构大调，「图书馆」与「发现」被重新赋予灵魂：一个负责沉淀，一个负责相遇。过去靠人工搬运的短链榜单，要让位于算法与规则的静默编排。老后台的断壁残垣必须迁往新后台，且不能惊扰仍在旧版本里冲浪的千万用户。于是，我——一个尚未谋面的远程实习生——成了这场迁徙的临时建筑师。

二、目标 · 行动 · 结果
目标
1. 设计图书馆首页的后台配置与内容管理模块。
2. 将老后台的断点续传、短链黑名单、域名白名单等能力，平滑嵌入新后台。



行动
• 拆解老后台：像考古学家一样，把七年前的字段、五年前的按钮、三年前的补丁逐层标注。
• 翻译需求：把「想让用户更快找到想分享的短链」翻译成「推荐策略权重 = 0.7×点击率 + 0.3×停留时长」。
• 原型即剧本：用 Axure 把每个按钮的呼吸、每条数据的增删查改写成一幕幕交互剧。
• 算法握手：与推荐工程师一起，把「不可手动干预」的算法结果，留出 5% 的人工置顶灰度实验位。
• 双线并行：让新旧后台像两座并列的桥，旧桥通车，新桥试跑，直至 90% 流量迁移完成。

结果
新版本在凌晨 3:27 灰度上线，比预期晚了 18 个小时。需求在最后一晚仍在生长，像春夜里的藤蔓。我留下 7 个待优化的小遗憾，把更大的舞台留给了第二阶段。



三、重难点：在规则的缝隙里跳舞
1. 推荐与规则的楚河汉界
推荐靠数据起舞，规则靠人定边界。后台必须同时供奉两位神明：
• 算法神殿：实时预览、策略调参、A/B 祭坛。
• 规则祭台：白名单、黑名单、时段权重、地域屏蔽。
我用一张泳道图，让二者在数据库里相安无事。



2. 旧版本兼容的七道封印
• 新字段是否会击穿旧接口？——让技术全链路 Diff。
• 弃用的字段是否真的一无是处？——拉齐客户端、服务端、数据端三堂会审。
• 数据迁移是机器跑还是人工搬？——用 Excel 公式先跑一遍沙箱，再决定要不要熬夜。
• 双 App 并存期如何优雅地提示升级？——在用户第 5 次打开旧版时，弹窗不再温柔：「世界已更新，你何时启程？」

四、个人图谱：在后台的暗房里冲洗底片
1. 交互文档写给「明天的自己」
• 用结构化语言，拒绝散文式描述。
• 每次更新原型，标注时间戳，像 Git 的 commit message。
• 菜单层级画成树状图，让测试一眼看见叶子节点。
• 按钮状态用色盲友好的对比色，减少误操作。

2. 后台设计的四行诗
增删查改是韵脚，
业务痛点是诗眼，
技术成本是平仄，
异常分支是留白。

3. 项目跟进的三字诀
听：—听懂技术的弦外之音；
断{—在需求膨胀时手起刀落；
传{—任何变更 10 分钟内同步全员。

五、下一步：把问题问得比答案更长
我将把「快缩短网址」的后台当成持续演进的生态，而非一次竣工的楼宇。
• 定义问题的时间 ≥ 解决问题的时间。
• 每周拆解一款 B 端产品，写 500 字外科式笔记。
• 继续与 super 黄色拆解小组过招，让不同视角的刀锋，磨亮自己的钝处。

愿这封长信，像 suo.run 生成的短链，把冗长的迷茫折叠成轻盈的入口，带你直达产品世界的下一座灯塔。