如何建立自己的 UI Reference Library，而不是继续收藏后遗忘

把收藏入口改成任务维度：登录、搜索、空态、权限、定价、Agent 工作台。每条参考都写一句“值得借什么”，而不是只存链接。

视觉风格可以作为第二标签，但不能代替任务标签。你在做支付流程时，需要看到的是完成路径，而不是一百张渐变卡片。

Dribbble、Behance、Pinterest 适合找视觉方向；Mobbin、Page Flows、UI Sources 更适合验证真实流程。两类来源混在一起，会让你把概念图误当作已验证产品。

给每条来源标记可信层级、平台、访问成本和最适合的任务，选择成本会下降很多。

每个项目开始时选 3 到 5 个参考，拆出结构、状态、文案和材质四项判断；结束后把真正采用的结论回写到库中。

长期看，最有价值的不是收集量，而是你形成的“看到某个任务就知道往哪里找”的路径。

一张截图只有在被解释后才会成为参考。保存时至少记录任务、用户角色、所处流程、值得借鉴的结构、不能照搬的条件和原始来源。没有这些字段，几个月后只会剩下“当时觉得挺好看”。

把描述写成决策语言，例如“审批卡把影响范围放在按钮之前”，而不是“卡片很高级”。前者可以进入需求和 Review，后者只能再次激发模糊审美。

同一参考可以支持多个任务，但每个任务需要独立注释。搜索页的筛选结构与它的视觉风格属于两种知识，不要只用一个大而模糊的标签概括。

参考库不是只进不出的收藏夹。新来源先进入 Inbox，确认链接稳定、产品真实上线、流程可访问后再进入 Verified；失效、重复或只剩营销截图的条目进入 Archive。

每季度按任务检查覆盖率：是否有完整的登录、搜索、空态、权限、错误和恢复流程；是否过度集中在同一类 SaaS；是否缺少移动端、无障碍和本地化案例。

来源质量应高于数量。十个带完整 flow、状态与注释的案例，比一千张无法确认上下文的图片更能支持设计判断。

真正有用的 Reference Library 不依赖设计师临时想起某个收藏。需求进入审批、搜索、Onboarding 等任务时，系统或模板应自动提示对应参考集与检查点。

可以在 PRD、Figma 页、组件 Story 和代码 Review 模板中链接同一任务集合。设计师看流程，工程师看状态覆盖，产品经理看决策依据，参考由此进入协作链路。

项目完成后把最终方案和结果回写到参考库：借了什么、改了什么、上线后是否有效。内部案例往往比外部名站更贴近自己的业务约束。