从一条想不起来的探店结论说起Savorboard的立项逻辑我决定做Savorboard不是某天灵光一现而是被自己的记忆力当场羞辱了一次。那天晚上我在手机相册里翻到一张咖啡馆照片光影、杯子、角落的绿植都拍得很清楚连那天穿的什么衣服都能从倒影里看出来但我死活想不起来那杯手冲咖啡到底是什么风味走向——是偏柑橘还是偏可可尾韵有没有涩感当时和朋友聊了什么话题让这杯咖啡值得拍下来全部一片空白。那一刻我才意识到一件很讽刺的事我们在消费内容时都在强调“感知当下”但真实的味觉记忆保质期短得惊人大概两周之后就只剩下“好喝”“一般”“难喝”这种情绪标签具体细节全部蒸发。Savorboard这个名字就是这么来的savor是细品、回味board是看板、面板。它要做的事情很简单把每一次真实吃到的、喝到的体验变成一张可以检索、可以翻看、可以分类的卡片然后集中呈现在一块私人看板上。不是社交平台不是大众点评不是美食博主的内容农场就是一个只属于你自己的味觉档案库。这篇文章我会把Savorboard从立项、字段设计、功能落地到踩坑的完整过程拆开讲产品经理、独立开发者、甚至只是平时喜欢探店记录生活的人都能在里面找到可以直接拿来用的思路。1.1 我的原始痛点一个月后完全回忆不起“当时那杯咖啡什么味道”先说那个让我拍桌的瞬间。那天我瘫在沙发上刷相册看到那张咖啡馆照片第一反应是“哦这家我去过”。再往下想就卡壳了它有什么招牌豆子是浅烘还是深烘我最后到底对它是好评还是差评最离谱的是我翻遍了当时的朋友圈文案只有一句“下午咖啡环境很好”连味道都没提。我想去找大众点评上的记录发现我压根没打过卡因为那家店是我朋友带我去的我当时只负责吃不负责写点评。这件事暴露出的问题不是我的记性特别差而是几乎所有人在吃的现场都只完成了“拍一张照”这个动作剩下的细节全靠大脑缓存而大脑缓存是会被覆盖的。第二天上班、加班、开会、地铁上的短视频轰炸味觉细节很快就让位于生活噪音。我后来自己统计过能让我在一周后仍然准确描述出风味细节的餐饮经历大概只有十分之一而这十分之一几乎都是因为当时我发了超过三张图的九宫格强迫自己多写了两句描述。也就是说记录动作越具体记忆留存率越高。这就是Savorboard立项的原始支点我不想再依赖碎片式的相册和朋友圈我需要一个专门的地方把“我尝过什么、在哪尝的、当时感受如何”这件事固定下来。它不用帮我看世界只帮我记住我自己的世界。1.2 为什么大众点评、小红书和相册都解决不了这个问题很多人第一反应是这不就是大众点评吗我认真用了两周大众点评想解决这个需求结论是完全不对路。大众点评本质上是一个公域评价系统它鼓励你写长文、传图、打星目的是给其他用户提供消费决策参考。这意味着两件事第一你的记录带有强烈的“评价感”和社交表演成分写“今天在家做了一碗翻车的番茄鸡蛋面”这种话放在大众点评上毫无意义第二一旦你给商家打了低分你还要面对商家回复、其他用户来杠记录成本无形中变得极高。时间一长写点评变成交作业而不是记录生活。小红书和朋友圈的问题恰好相反它们适合分享但完全不擅长归档。你有几百篇美食笔记想找出“去年秋天喝到的最惊艳的一杯热可可”在现有检索逻辑下基本等于大海捞针你只能凭记忆去翻某个时间点附近的照片翻到一半就被别的帖子带走注意力。相册就不用说了它只有存储能力没有组织能力同一个相册里混着咖啡、火锅、路边的猫和开会用的PPT照片我甚至见过有人拿相册人脸识别功能去搜人也没人能靠相册按“风味类型”或“回购意愿”做检索。垂直领域的App倒是存在比如记录精酿啤酒的Untappd、记录红酒的Vivino体验不错但它们全都锁定单一品类一个既喝咖啡又探店又自己做饭的人手机里至少得装三个App数据还互相割裂。1.3 定下来的产品目标让每一次品尝沉淀成可检索的档案想清楚上面那些工具的局限之后Savorboard的产品目标就变得非常清晰了。它不是一个评价工具不是一个内容社区也不是一个打卡签到应用它更像是一个私人档案馆。准入标准只有一条这件事值得你记住。它可以是米其林三星的晚餐也可以是楼下便利店新出的速溶咖啡因为对个人档案来说好坏并不是重点重点是你曾经认真品尝过它。在立项的第一版文档里我给自己写死了三条边界后来几乎所有的功能取舍都靠这三条来判断第一不做公域社交功能消息流里的内容只属于自己访客模式可有可无但绝不能做成关注体系第二不做商家评分逻辑你不需要帮别人决策你只需要记录自己的倾向第三数据必须能被导出个人档案不是平台资产用户要能随时把全部记录拿走。这三点是Savorboard的边界也是它和所有“想要做你的记录工具但顺便做你的流量工具”的产品之间最本质的分界线。看板模型和字段设计Savorboard最核心的产品决策Savorboard这个项目最让我纠结的不是技术选型而是信息架构。一个记录类工具界面做得多花哨都是次要的真正决定用户体验的是数据组织方式也就是“一条记录长什么样、被放在哪里、后来怎么找到它”。我推翻了三版设计稿最终确定的方向是以看板为核心以卡片为最小单位以双层标签作为组织手段。听起来不太酷但这是我在所有候选方案里验证下来最稳的组合。2.1 “看板”形态为什么比时间线、文件夹更贴近味觉记忆我最开始用的是时间线就是按时间倒序排列所有记录用起来很顺手但三个月后问题出现了我想找“所有让我想回购的甜品店”只能一条条往下翻因为时间线根本没有“状态”这个概念。后来我试过文件夹按品类建了“咖啡”“火锅”“甜品”等文件夹分类倒是清爽了但新的问题来了——一条记录往往横跨多个维度比如“一家同时提供手冲咖啡和芝士蛋糕的独立小店”放咖啡文件夹还是甜品文件夹而且文件夹的语义是静态的你不能体现“这家店我喝过一次还想再去”这种动态倾向。看板恰好解决了这两点。看板的每一列不是一个文件夹而是一种状态卡片可以在列之间移动。我把Savorboard的看板列定义为想尝试、已品尝、值得回购、一般般、不会再碰。注意这里不是按分数分列而是按“下一步动作”分列。这样做有一个非常大的心理学优势用户不需要在“给这顿饭打几星”这种问题上纠结你只需要问自己“还想不想再吃”。大部分情况下答案只有三种想立刻再去、有机会再去、算了不去了。这种状态判断比十分制评分准确得多也轻松得多。组织形态核心语义适合场景主要缺陷时间线按时间排序快速回顾近期记录难以跨时间检索同类内容文件夹静态分类品类固定的档案无法表达状态变化多类别记录会冲突看板状态流转记录之后再决定倾向需要用户理解“列”的概念上手有学习成本看板在这里还有一个隐喻上的优势一张卡片从“想尝试”拖到“已品尝”是一种很物理化的操作就像你真的把那家餐厅从愿望清单移动到了人生经历清单里。这种反馈让记录不再像是填表更像是整理自己的味觉人生。2.2 一张品尝卡片的字段组成以及每个字段存在的理由确定看板之后我设计了Savorboard的最小字段集。每一条记录不是一个简单的相册帖子而是一张结构化卡片。我在数据库里给每条记录定义了这些字段并在后续使用中不断验证它们的必要性。这里用JSON结构展示最核心的部分比较直观{ id: taste_20240718_001, name: 手冲耶加雪菲, type: coffee, source: 公司楼下的独立咖啡馆, status: 值得回购, tasted_at: 2024-07-18T15:30:0008:00, dimensions: { 香气: 4, 口感: 4, 环境: 3 }, notes: 橘子皮香气很明显放凉后酸质变柔和尾韵有一点点涩, tags: [雨天, 下午, 出差间隙], images: [https://cdn.example.com/thumbs/taste_001.jpg], created_at: 2024-07-18T15:40:0008:00 }字段看起来平淡无奇但每一个都是我踩过坑之后留下的。name和type用来完成“快速识别”一个卡片被滑动到眼前时你第一眼要看的就是名字和品类这决定了后续回忆能不能被触发。source记录“在哪里吃到”这是大部分美食帖都会忽略的角色但它对建立场景记忆极其重要同样是白咖啡在伊斯坦布尔街边喝的和你自己办公室楼下的完全是两种记忆。tasted_at是一个精确到分钟的时间戳因为同一个咖啡馆你可能去过很多次靠名称会产生大量重复记录靠时间戳才能区分出“这是三月份的那一次”。dimensions字段是我把单一评分拆掉后的产物不追求一个总分只用香气、口感、环境这种可感知的维度记录倾向。notes是自由文本我把它放在字段的底层而不是顶上原因后面会讲——太多人面对一个空文本框会卡住不知道该写什么这会导致放弃记录。tags是自由标签加上images最多关联九张图。每个字段的存在理由只有一个在不打断记录节奏的前提下尽可能多的触发未来回忆的线索。2.3 双层标签固定品类维度 自由情境标签标签系统是Savorboard里我最想强调的设计。几乎所有记录类工具都有标签但它们几乎都只做单层标签也就是用户可以自定义任意标签然后每个标签地位平等。单层标签的问题在于它过度依赖用户的组织能力。我用过一个笔记软件三个月后标签列表膨胀到上百个“咖啡”“工作日咖啡”“下午咖啡”“2024咖啡”四个标签并存检索效率反而下降。Savorboard把标签拆成两层。第一层是固定品类维度由系统定义包括餐厅、咖啡、酒、茶、自制、零食、路边摊、其他。每个维度内部可以细分但顶层的品类数量是锁死的不允许用户自己创造新品类。这么做的原因很务实如果开放自定义品类最后一定会出现“美食”“好吃的”“好店”“探店记录”这种语义重叠的混乱局面哪怕功能上没问题用户会自己把档案用得很难看。固定品类不是一个限制而是一种保护。第二层是自由情境标签用来补充场景信息陪你吃的人、当时的心情、天气、发生的特殊事件。这层标签完全自由但也设计了防膨胀机制当你输入一个已存在的标签时系统会强制走自动补全不允许在相近标签之外再创建一个新的。比如我已经有了标签“雨天”你再输入“下雨天”时系统会提示你选择已有标签。这个细节看似反人性但它保证了标签的聚合能力也让第二年的“雨天记录回顾”这种筛选项变成可能。双层标签配合起来的效果是既保证了品类维度的整齐又保留了情景记录的灵活。核心功能落地拆解十秒录入、随机回顾和待品尝队列定了看板模型和字段之后接下来的问题是功能优先级。Savorboard的预算和人力都很有限我不可能一开始就做地图、社交、推荐算法这些锦上添花的东西。我给自己定的标准是砍掉一切日常使用率低于百分之十的功能先把三个核心场景打穿——记录一次品尝、回看自己的品尝历史、维护一个待品尝清单。3.1 录入把一次记录拆成“必备信息”和“可选信息”录入是Savorboard的生命线如果录一条要一分钟用户用三天就会流失。我在第一版里走过弯路当时字段全开拍照、填店名、选品类、打分、写描述、加标签一套流程下来平均要一分半钟数据质量倒是很高但留存曲线惨不忍睹。后来我把录入拆成“必备信息”和“可选信息”两档必备信息只有三样照片、名称、状态三样填完就能保存整个过程不超过十秒。其他字段——时间、地点、品类、描述、评分、标签——全部可以事后补充系统会在你滑动到旧卡片时提醒一句“这张卡片还缺一条描述要不要补一下”。这里有一个细节值得单独说source字段也就是“在哪里吃到”对很多人来说是最难填的一个字段。因为探店时你能记住店名但自己做饭或者吃路边摊时真的想不起来这个“来源”该怎么写。Savorboard的解决方案是允许source为空同时提供三个快捷值自制、堂食、外卖外加一个文本输入。这样大部分人只需要点一下就能完成语境标注极大降低了录入阻力。另外我强烈建议任何做记录类工具的人都提供“模板复制”功能。同一个咖啡馆你可能会去很多次Savorboard在卡片页提供了一个“再吃一次”按钮点了之后会自动生成一张新的卡片预填上一次的品类和来源你只需要换一张新照片和新描述。这个功能上线之后第二次及以后的录入时间被压缩到了五秒以内复吃场景的录入率从百分之三十提升到了百分之七十以上。3.2 回顾看板筛选与“再尝一次”的随机召回记录不是为了存而是为了“能想起来”。Savorboard的回顾入口有两个第一个是常规的筛选检索顶部一排品类按钮餐厅、咖啡、酒……搭配状态下拉框、时间范围和自由标签组合起来形成一个多重筛选。这个筛选逻辑用SQL表达起来非常直白效果也很稳SELECT * FROM tastes WHERE type coffee AND 雨天 IN (SELECT tag FROM taste_tags WHERE taste_id tastes.id) AND status IN (值得回购, 已品尝) ORDER BY tasted_at DESC LIMIT 50;第二个回顾入口才是我最想安利的叫“再尝一次”。它不是一个按评分推荐的智能推荐系统而是纯粹的随机召回从所有“已品尝”状态的卡片里随机抽一张展示出来你可以选择“今天想再去”把它拖回“想尝试”状态或者再抽一张。这个功能的设计灵感来自一个很朴素的观察记录的长期价值不在于精确检索而在于“重新遇见”。你费尽心思搜索出来的东西往往是已知的真正能带给你惊喜的是你已经忘了但系统帮你翻出来的那杯三年前的姜撞奶。随机召回的运行成本极低但它带来的情感唤起是任何排行榜都比不了的。我上线这个功能后收到的最多反馈不是“这个功能好用”而是“原来我去年喝过这个竟然完全忘了”。3.3 待品尝清单把“还没吃到的想”变成“已经尝过的忆”Savorboard的“想尝试”列是整个看板流转机制的起点也是冷启动的秘密武器。我在产品上线前以为用户会先快速录入一堆历史记录结果冷启动数据告诉我大部分新用户第一次使用Savorboard动手做的事不是补记而是先把脑子里那串“一直想去还没去的店”往里面塞。这其实揭示了记录类工具的一个隐藏逻辑人偏向先记录未来再记录过去因为未来是确定要发生的过去还要花精力回忆。所以我把“想尝试”列做成了一种独立的卡片类型它不需要照片只需要一个店名或者一个菜名你可以在被朋友安利、刷到探店视频、看到菜单图片的任何时刻用一次点击把它滑进来。等你真正去吃了从“想尝试”拖到“已品尝”系统会自动在后台补录一条“转化为实际品尝”的日志并且帮你带上“从想要到实现”的时间间隔。到年底做个人数据报告时这个间隔数据其实非常动人——你看到“那家云南菜你等了四十三天才吃到”记录的意义瞬间就从功能变成了仪式。开发中的三大坑评分通胀、图片资产和冷启动空板讲完功能说点更实际的。Savorboard开发过程中踩过的坑比预想的多但有三类问题对产品的形态产生了决定性影响。如果你也要做类似的记录工具这几个坑大概率会重复出现提前说清楚能帮你省至少两周时间。4.1 五星评分通胀我开始用“还会再去吗”代替分数初版Savorboard用的是传统的五星评分因为大家都熟不需要教。但测试两周后我拿到了一个很有规律的数据分布四星占一半五星占三成三星占一成五一星二星加起来不到百分之五。这个分布根本不是真实的体验分布而是评分焦虑的产物。给一个并不惊艳的餐厅打三星会让人产生一种“我是不是太刻薄了”的负罪感给街边小吃打二星又觉得“人都挺辛苦别这样”。于是所有人都往中间偏高的分数挤最后四星变成“还行”的代名词评分彻底失去区分度。解决方案就是我前面提到的维度拆减和动作导向。把“给这顿饭一个总分”改成三个低压力问题香气/口感/环境分别是一般还是突出还会不会再去第一个问题分散了评价焦虑第二个问题把抽象分数变成了具体动作。最终Savorboard完全取消了总分概念看板上显示的是一个由动作标签构成的倾向列。这个改动的直接结果是非常明显的记录量没有下降“不会再碰”这个以前几乎没人敢打的标签使用率从不到百分之五上升到了百分之十八数据终于开始反映真实判断。4.2 图片资产的坑文件名时间戳、哈希去重与备份Savorboard是重图片的应用图片管理的坑避不开。我之前踩过的第一个坑是用时间戳作为文件名比如202407181530.jpg听起来很合理但在批量导入旧照片时发现一个问题同一张照片可能以不同时间戳被导入两次因为导入时读取的文件时间和你拍照时的EXIF时间不一致一张图会变成两张图。更可怕的是换手机迁移后文件名冲突导致旧卡片里的图片全部裂开那感觉就像档案馆的档案被烧毁了一角。后来我做了两处修正。第一所有图片文件名改用SHA1哈希值同一张图片内容相同哈希就相同天然去重再也不会出现“同一张照片在两条记录里各放一份”的情况。第二图片一律先压缩到最长边1920像素作为缩略图原图单独备份数据库里只存缩略图路径。这里有个经验值一张原图动辄三四MB压缩后大约200到400KB但在手机上查看的视觉差异非常小。记录类工具的核心是文字和时间戳图片只是锚点你用原图存储只是白白增加服务器成本和加载时间。EXIF信息也别忽略我把拍摄时间作为tasted_at的回退值因为用户导入相册旧照片时绝大多数人不会手动填写品尝时间EXIF自动补全显著提高了导入记录的信息完整度。4.3 冷启动空板没人愿意面对一张白板这是Savorboard上线后最意外的一个坑。我满心以为用户下载后会激动地开始录入结果数据分析显示有超过一半的新用户在首次打开看板后三分钟内就退出了之后再也没回来。原因细想也很合理空荡荡的看板带给人的不是“从零开始的自由”而是“不知道从何下手”的恐惧。写日记的人明白这种感觉本子越空白第一笔越难落下去。针对这个现象我做了三个调整效果拔群。第一是在新手引导里主动展示一张示例看板里面放上了虚构的十条卡片覆盖各种品类和状态让用户知道“填满之后我的看板会长什么样”。第二是提供一个“从相册导入”按钮系统读取用户相册里与食物相关的照片通过相册OCR识别和拍摄时间聚类生成一张临时卡片用户只需要确认“吃了吗”就能一键导入。第三是刻意降低首周目标第一周只需要录入五条而且允许这五条全是“想尝试”状态不需要任何照片和描述。这三招配合下来新用户七日内留存从百分之十提升到了接近百分之三十。核心的心法很简单不要要求用户一次性构建一个完整档案先帮用户搭一块能落地的地基。竞品边界与扩展方向Savorboard到底在和谁抢时间做产品没有边界意识是最危险的。Savorboard上线后经常收到两种反馈“这不就是私密版大众点评吗”和“我用Notion也能做同样的事”。这两句话单独看都对但组合在一起就暴露了一个误解——他们以为Savorboard的功能可以被其他工具替代实际上Savorboard争夺的既不是点评流量也不是笔记软件的用户而是用户“愿意为自己认真做记录”的那一份时间。5.1 和大众点评的区别私域记录不承担社交表演大众点评的核心是公域评价一个评价的价值由点赞数、阅读数、商家回复这些外部反馈决定你的记录从写出来的那一刻起就是公共产品。Savorboard反着来你的记录默认是私有数据不需要点赞不需要互动连评分标准都只对你本人生效。同样是给一家餐厅打标签在大众点评上你需要考虑“我这样说会不会被粉丝骂”在Savorboard里你只需要考虑“我下次还想不想来”。公共评价系统天然偏向极端表达和热度逻辑私人记录系统则允许你温和地、真实地、甚至随性地记录。我自己的使用体验是自从把所有探店记录从点评App搬到Savorboard之后我反而敢写更长的描述了因为没有人在看。5.2 和Notion、Pinterest的区别结构化字段与自由记录的取舍Notion确实可以做一张类似看板的表格Pinterest也可以收藏美食图片但它们都缺一个东西针对味觉场景的结构化字段。在Notion里记录一杯手冲咖啡你得自己建属性列名称、门店、日期、评分、标签建完之后长期维护数据库结构你还得当半个数据库管理员。Savorboard把这一切做成了模板用户不需要设计结构只需要填内容。Pinterest则偏向“收集”而非“记录”一个Pin是一张好看的图但它记录不了“这杯咖啡的尾韵怎么样”这种体验信息。这背后不是功能强弱的问题而是意图的差异通用工具把组织能力交给用户垂直工具把注意力还给用户。5.3 往外走的两个方向年度味觉报告和相似口味检索Savorboard已经积累的数据形态让两个扩展方向变得非常自然。第一个是年度味觉报告年底根据用户的卡片数据生成一份统计——这一年你尝过多少种咖啡、最常去的三家店、最愿意回购的品类、“想尝试转已品尝”清单的首选目标等等。这种报告的价值远远超过单条记录的展示它让用户看到“时间在味觉里留下了什么”。第二个方向是相似口味检索通过双层标签和维度评分来判断“你喝过这款耶加雪菲觉得不错那另一款产区的豆子大概率也合你的口味”。它本质上是一个非常轻量的味觉偏好匹配不需要复杂的推荐算法只需要标签重叠度和几个维度评分就能跑出不错的初步结果门槛不高但收益明显。如果让我把Savorboard重新做一次我会把数据导出功能放到第一个版本就做完并且保证导出的JSON结构清晰、字段完整。说得感性一点一个人在Savorboard里记录下来的每一杯咖啡、每一顿饭都在慢慢拼出一副关于自己生活的肖像这副肖像值得被严肃对待也值得被自由带走。另外我会在第一版就坚持四件套不要贪多卡片、看板、双层标签、待品尝队列这四个功能抓住一条完整的主线剩下的所有花活都可以往后放。这也是我在Savorboard这个项目上最大的体会记录工具最稀缺的资源从来不是功能数量而是用户愿意持续投入的那一点点耐心。你能做的就是把开口放到最小让每一次记录都不显得麻烦其余的事时间会帮你完成。