1. 从一个自用脚本到独立产品Windie Chai到底解决什么问题先交代一下背景。我自己是个重度天气依赖者每天起床第一件事不是刷社交软件而是看窗外、看气温、看湿度。但光看天气数字没什么用真正影响我决策的是“体感”——同样的25度在南方梅雨天和北方干热天完全是两种体验。后来我又迷上了喝茶发现一个更有趣的规律不同天气条件下人对茶的需求完全不一样。闷热天想来点清爽的生普或茉莉花茶阴冷潮湿天就想泡一壶暖和的老白茶干燥烦躁的时候岩茶的焙火香特别解郁。那时候我就想能不能做一个东西把“天气数据”和“茶饮推荐”结合起来这就是Windie Chai的起点。很多朋友第一反应是这不就是个带茶叶推荐的天气App吗其实不完全是。Windie Chai的核心不是“天气预报”而是把气象数据做一次语义转化——把温度、湿度、气压、风力这些冷冰冰的数字翻译成“此刻适合喝什么茶”的生活化建议。它本质上是一个基于气象特征的推荐引擎只是载体刚好是茶。项目的名字也从这个思路里长出来Wind是风代表天气和环境Chai是茶代表生活方式的落点。两个词拼在一起既点明了数据来源又点明了应用场景。如果你正在做类似“小而美”的工具类产品或者你对个性化推荐感兴趣又或者你只是想做一个能自己天天用的效率工具这篇内容应该能给你一些参考。我下面会把这套系统从数据、算法、工程到内容运营全部拆开讲包括踩过的坑和绕过的弯路。2. 天气数据不是拿过来就能用从气象API到体感特征值的加工链路2.1 为什么直接读温度湿度根本不够用我先说结论气象数据的原始字段绝对不能直接作为推荐逻辑的输入。我最早的原型版本犯过这个错误——直接用温度区间匹配茶类。温度26度以上推荐绿茶10到26度推荐红茶低于10度推荐熟普。逻辑够简单但实测效果非常扯。同样是28度的夏天一个湿度85%的雷雨天和一个湿度35%的干热天身体感受完全不同。前者整个人像泡在蒸汽里根本不想喝热茶后者虽然热但很干爽来一壶热乌龙出出汗反而畅快。后来我又试着把湿度加进去做二维匹配情况好了一些但还是有很严重的缺陷没考虑风力、没考虑体感温度、没考虑昼夜温差、也没考虑天气现象比如降雨、降雪、雾霾。你会发现直接拿原始字段做规则匹配参数一多规则就变得极其混乱几十条if-else堆下来根本维护不了。2.2 体感温度与“茶饮舒适度”建模后来我认真读了一些人体舒适度相关的资料发现气象学里早有现成的思路——体感温度模型。最经典的公式之一是澳大利亚气象学家Steadman提出的体感温度计算法它综合考虑了温度、湿度、风速和太阳辐射。我采用的简化版本思路是这样的首先用当前气温作为基准值根据相对湿度做修正湿度越高夏天感觉越热冬天感觉越冷根据风速做修正风力越大体感温度越低风冷效应根据是否降雨/降雪做场景修正。计算完之后我得到了一个“体感温度”数值。但这还不够因为茶饮推荐不能只看热冷还得看“舒适度”。我又建了一个维度叫“茶饮舒适度”它的取值范围是-2到2体感温度在18到24度之间且湿度适中时舒适度接近2属于“通体舒畅”的状态这时候人最适合品饮层次丰富、香气细腻的茶体感温度超过30度且高湿时舒适度接近-2属于“闷热黏腻”状态这时候身体直觉是想喝能“解腻、降温、发汗”的东西体感温度低于5度且湿度大时舒适度接近-2属于“阴冷潮湿”状态这时候需要的是温暖、厚重、有包裹感的茶。这个模型把复杂的天气形态压缩成一个可计算的连续值后面的推荐算法全部基于它展开。这一步是整个Windie Chai的核心资产也是和市面上“天气App广告位”模式拉开差距的地方。2.3 数据源选型与容错设计再说数据源。我用过好几家天气API国内的、国外的都有简单做一下对比供你参考国内某知名天气服务商的免费版数据更新频率和稳定性都不错缺点是免费额度有限而且部分字段的语义文档写得比较含糊。国际通用的OpenWeatherMap免费额度大、字段全但国内部分城市的小时级数据偶尔会出现延迟。还有一些聚合类气象数据平台数据源覆盖全球但精度参差不齐。最终我的选择是主数据源用国内服务商确保国内城市的数据及时性备用数据源用OpenWeatherMap主源失败时自动切换。两个源之间做字段映射统一成自己的内部数据模型。这里面有一个很容易踩的坑不同API对天气现象的描述代码完全不一样。有的叫“Rain”有的叫“Thunderstorm with light rain”有的直接给你一个天气编号。如果不在接入层做规范化和映射后面所有的规则匹配都会出问题。我在这个环节浪费了大概两天时间后来学聪明了写了一个统一的气象现象枚举表把所有可能的天气码映射到自己的业务语义上比如“晴”、“多云”、“阴”、“小雨”、“暴雨”、“雪”、“雾”、“霾”等十几个大类推荐逻辑只跟这个枚举表打交道彻底隔离了数据源的差异。3. 推荐引擎不是玄学把“天气-茶饮”的映射关系做成可解释的规则系统3.1 茶饮知识库的底层分类逻辑推荐引擎的上游除了天气特征还有一块必须做扎实就是茶的知识库。很多人做推荐系统会把重心全放在算法上但我的经验是领域知识的质量直接决定推荐效果的天花板。我没有按照传统的六大茶类绿、白、黄、青、红、黑做唯一分类维度因为这种分法在专业茶学里成立但在“天气对应关系”上并不直觉。比如乌龙茶里既有清香型的铁观音又有焙火重的岩茶两者在体感上的表现差异极大甚至超过了一些跨茶类的差异。所以我建了两层标签体系第一层是工艺属性茶类、发酵程度、焙火程度 第二层是体感属性茶性寒热、香气类型、口感厚度、适饮温度。举个例子绿茶和新生普在体感属性上就很接近——茶性偏寒凉香气清扬口感鲜爽偏薄适饮温度可以热饮也可以放凉了喝。而传统工艺的足火岩茶和小种红茶体感属性也接近——茶性偏温香气馥郁带焙火味或松烟香口感醇厚适合热饮。有了这套体感属性标签推荐引擎就不需要死记“绿茶对应夏天、红茶对应冬天”这种粗糙规则而是可以根据实时体感特征动态匹配“茶性寒热”、“香气类型”、“口感厚度”这些连续或离散的属性。3.2 规则引擎的具体实现思路推荐引擎我采用了两层结构粗筛层 精排层。粗筛层负责把茶叶池子里明显不符合当前天气的选项淘汰掉。规则很简单当体感温度低于10度时剔除所有茶性偏寒的茶默认只保留茶性偏温或偏热的茶当体感温度高于30度且湿度大于70%剔除所有口感厚重的发酵茶优先保留清新鲜爽、可冷泡的茶当“茶饮舒适度”小于-1.5时无论冷热都会倾向推荐有“发汗”效应的热茶比如老白茶、普洱熟茶。精排层就复杂一些我给每个候选茶打一个“匹配分”分数由四个子项加权求和得出温度匹配分基于体感温度与茶饮适饮温度的重合度计算权重占30%湿度匹配分高湿天气对口感厚重的茶减分对带有清凉感的茶加分权重占25%天气现象匹配分雨雪天倾向温暖型茶饮干热晴日倾向清爽型茶饮雾霾天倾向有“清肺”意象的茶饮权重占25%时段匹配分早晨提神型午后消食型晚间安神型权重占20%。四个子项算完加权求和后排序取Top3作为最终推荐同时附带一段推荐理由。3.3 为什么不用机器学习模型——小数据场景的工程务实主义可能有人会问既然都做了加权评分为什么不上一个机器学习模型来做推荐这个问题我在项目初期也认真纠结过。最后放弃机器学习方案主要有三个原因第一数据量根本不够。机器学习模型要有靠谱的效果至少需要几千上万的标注样本。我自己一人维护这个项目哪来那么多标注数据先不说采集工作量光是“某天气条件下什么茶好喝”这种主观感受本身就很难有标准答案。第二可解释性太差。如果我告诉用户“因为模型算出来匹配分是0.87所以推荐你喝大红袍”用户完全无感。但如果我告诉用户“今天体感偏湿冷推荐你喝一壶足火肉桂焙火香能中和空气中的潮闷感”用户立刻能感知到推荐背后的逻辑。第三规则系统在小规模场景下维护成本更低。规则引擎的每一个判断逻辑都可以写成可读的代码出了偏差一查就知道是哪个规则的问题。而模型一旦出现推荐偏差排查成本就高得多。当然规则引擎也有天花板——规则再多也没法覆盖所有边缘case。我的处理方式是做一层“随机漫步”机制在推荐结果的Top3里每次有较小概率插入一个打破常规的选项目的是让用户偶尔产生意外惊喜。这个机制的效果还挺好不少用户反馈中最惊艳的推荐恰恰来自这些“规则之外”的选项。4. 内容与运营茶饮推荐的另一半功夫在“文案”和“交付体验”4.1 从推荐到交付每个推荐必须讲得出“为什么”前面说的都是算法侧但一个推荐系统的体验好坏文案的作用被严重低估了。我可以直接给你看Windie Chai里一个典型的推荐理由是怎么生成的场景体感温度12度湿度83%小雨东北风3级。系统推荐的茶是老白茶寿眉饼推荐的解释文案是“细雨绵绵的天气里空气湿度超过80%整个人容易透着一股祛不掉的凉意。这时候煮一壶老寿眉枣香、药香在水汽里慢慢化开热汤入喉后背微微发汗整个人就从潮冷的束缚里松出来了。”这段话不是写死的模板而是由三个部分动态拼接出来的第一部分描述当前天气的身体感受基于体感温度和湿度生成 第二部分带入具体的茶品感官描述从茶知识库的感官描述字段取 第三部分给出情绪收尾根据天气场景的情绪语料库生成。为了让这套文案系统能跑起来我花了大量时间整理茶品的感官描述语料。一片茶叶至少要有四个维度的表述香气干茶香、杯盖香、汤香、叶底香、滋味甜度、苦度、涩度、回甘、生津、汤感厚度、顺滑度、收敛性、体感发汗、暖腹、清爽、润喉。每款茶录入知识库时我都要把感官描述写成有画面感的文字而不是只写“香气浓郁、滋味醇厚”这样的空洞套话。4.2 冷启动阶段的内容积累策略内容建设是这类项目里最容易被低估的工作量尤其是你一个人做全栈时。我的做法是不追求茶品数量的大而全而是先把常用茶类的基础款覆盖掉。目前知识库里大约录入了几十款常见的、容易买到的茶品每款都包含茶类、产地、工艺特征、感官描述、适饮场景、储存建议等信息。这些茶品基本覆盖了中国茶消费市场的绝大多数常见品类——绿茶、青茶、红茶、白茶、黑茶、再加工茶都有了。这个策略的好处是推荐系统不需要盲人摸象。每个推荐背后至少有真实的茶品信息做支撑用户看完推荐想尝试时也能在电商平台顺利买到对应产品。在冷启动期我还做了一个很笨但有效的活自己喝、自己记、自己写品鉴笔记。每录入一款茶我至少要喝三次以上分别在晴天、阴天和雨天喝记录下不同天气下同一款茶的表现差异。这些真实笔记成了文案系统里最宝贵的语料来源。4.3 推送时机与用户触达的细节优化茶饮推荐不是用户打开App才生效它还可以主动触达。在这个环节我踩过不少坑。最早的推送策略非常简单粗暴每天早上8点推送一次当日推荐。结果打开率低得可怜用户反馈也很平淡。后来仔细分析了一下问题出在“时机”上——早晨8点推送很多人还在通勤路上根本来不及看推荐内容等有空看的时候已经过了那个情绪点。我把推送时机分成了三个关键时间窗06:30-08:00侧重“唤醒”场景推荐偏轻爽、低咖啡因的茶或者有提神效果但不会过度刺激的茶品13:30-14:30侧重“午后消食”场景推荐能解腻、助消化的茶比如熟普洱、六堡茶、陈年铁观音20:00-22:00侧重“放松安神”场景推荐低咖啡因、有温暖感的茶比如老白茶、熟普、陈皮水。每个时间窗的推送内容、推荐茶品、文案语气都是独立的这样用户就不会觉得每天收到的都是同一个模板的变体。5. 工程落地个人开发者如何用轻量架构撑起一个完整产品5.1 技术选型为什么我选了前后端分离的轻量方案作为一个个人开发者技术选型最重要的原则是能少维护的东西绝不多引入。前端我选了响应式网页方案核心原因是茶饮推荐的使用场景天然分布在多个设备上——用户可能在手机上看推荐在平板上查茶品详情在电脑上浏览知识库。响应式网页一套代码就能覆盖所有端不用维护多套原生应用。后端用的是一个轻量级的Python Web框架主要承担三个职责天气数据的拉取和缓存、推荐引擎的计算、API接口的暴露。数据持久化方面考虑到知识库的数据量不算大我用了SQLite起步后续如果数据量涨上来再迁移到更重的数据库也不迟。整个系统跑在一台低配云服务器上就够了——天气数据是周期性拉取的推荐引擎的计算量也很小这台机器的负载长期在个位数百分比。这也是个人项目最舒服的状态用最少的钱维持一个全年全天候在线的服务。5.2 天气数据的缓存与轮询策略天气API虽然便宜但也不能无脑频繁调用。我设置的轮询策略是每30分钟从主数据源拉取一次当前天气和当日预报覆盖用户量集中区域的默认城市同时支持用户手动刷新时实时拉取。为了防止API调用超限我在中间加了一层缓存用户请求推荐结果时如果缓存中已有30分钟内生成的结果直接返回只有缓存过期或用户主动刷新时才触发新的计算。这样一个普通用户一天打开App几次API调用次数完全可控免费额度绰绰有余。另外气象数据是有时效的特别是降雨类的短时预报30分钟前和现在的天气可能已经完全不一样了。所以我还加了一个优先级机制如果用户主动刷新时发现当前天气与推荐文案里描述的天气状况不符会生成一条简短的修正说明如“10分钟前开始转雨推荐调整为更适合雨天的茶”保证推荐结果的时效性。5.3 前端展示让推荐结果“一眼懂二眼想点”说完了后端再聊前端展示的几个关键设计。首页的核心信息层级按优先级排列一共分四块当前天气状况的视觉化呈现以高辨识度的天气图标和体感温度为核心“今日推荐茶”卡片的强展示位包括茶品名称、品类标签、一句话推荐理由三个备选推荐以轻量列表形式存在“为什么推荐这杯茶”的折叠区域点击展开后能看到完整的气象特征分析、茶品体感属性匹配说明。这里面我认为最重要的设计决策是不把天气数据放在第一位而是把“茶饮推荐”放在第一位。为什么因为用户打开这个产品的动机是“今天喝什么茶”天气只是辅助决策的输入信息。如果用户想查详细天气他自然会去天气App没必要在你这里看。把推荐结果前置让用户一眼就能获得核心价值是留存率的关键。6. 从Windie Chai到任何一个推荐类产品这套方法论的可迁移性6.1 推荐系统的“领域知识优先”原则做完这个项目我最大的感悟是推荐系统的成败主要取决于对领域知识的理解深度算法反而是次要的。我现在把这个方法论总结成一套可迁移的流程如果你也想做类似的推荐类产品可以参考第一步建立一个领域知识库不追求数量但要确保每个实体的描述足够立体比如茶的香气、口感、体感都需要有具体描述而不是笼统的一个标签。第二步找到领域对象的“体感属性”就是那些能影响用户主观感受的属性把它们抽出来作为推荐的特征维度。第三步把环境因素这里指天气映射到这些体感属性上建立起“环境特征-体感属性-领域对象”的关联链条。第四步设计一套可解释的匹配规则让用户能看懂推荐的原因。6.2 三个在任何领域都适用的执行要点在做Windie Chai的过程中有几个执行层面的经验放在任何推荐类项目里都成立第一可解释性永远不是一个可选项它是产品体验的一部分。用户需要理解“为什么推荐这个给我”否则推荐结果很容易被当成垃圾信息。尤其是生活方式类的推荐产品推荐理由直接决定了用户愿不愿意尝试。第二规则引擎在冷启动阶段永远优先于机器学习。不要一上来就追求“智能”先把70%的常规场景用规则覆盖好等积累足够多的用户反馈数据后再考虑用模型替代一部分规则。第三内容建设需要提前规划不能临时抱佛脚。推荐系统的体验上限由知识库的质量决定而知识库的建设是一个漫长的积累过程。我在这个项目里最大的时间投入不是写代码而是喝茶、记笔记、整理感官描述这些看不见的功夫最终都转化成了用户能感知的推荐质感。7. 避坑实录三次典型事故及排查链路这部分我想原原本本还原几个真实踩坑的过程每一个都花了不少时间才定位到根因希望你能绕开。7.1 事故一所有推荐都指向了“暖茶”——体感温度的降权陷阱现象上线后第二天有用户反馈无论天气怎么样推荐结果永远都是红茶、熟普这类“暖茶”绿茶和白茶几乎从未出现在首推位上。我没有直接改代码而是先做了数据排查。查了推荐日志发现每次推荐计算出来的排序结果温度匹配分几乎都压倒了其他子项。进一步追查发现体感温度模型在高温高湿天气的修正幅度太大——比如实际气温28度、湿度80%的天气体感温度被修正到了22度以下系统误判为“偏凉”自然就推荐了暖茶。根因是湿度修正系数设置不合理。我用的体感温度公式里高湿度对温度的综合影响方向在不同季节是不同的——夏天高湿会让人感觉更闷热冬天高湿会让人感觉更阴冷。但我的系数是全年统一取一个值导致高温高湿的夏天被过度修正成“凉”。修复方案是引入季节参数4到10月按夏季修正系数计算11月到次年3月按冬季修正系数计算。修复后再跑同一批历史天气数据推荐分布明显合理了。7.2 事故二冷泡茶推荐导致的“寒性堆积”——推荐只算当下、不算累积现象连续几天高温天气系统每天都推荐冷泡绿茶。有用户反馈说喝了三天冷泡后胃开始不舒服了。这个案例让我意识到推荐系统不能只看当下的天气还要考虑用户的“饮茶历史”。如果用户连续几天都被推荐了茶性偏寒的茶身体可能已经积累了寒性这时候即使天气仍然炎热也应该推荐一款茶性稍微偏温的茶做“中和”。我在推荐引擎里加了一个用户维度的“茶性累积”字段系统会记录用户最近几次推荐的茶性寒热值在精排阶段对候选茶的茶性做一个加权修正。连续推荐寒性茶之后寒性茶会被降权暖性茶会被适当提权。这个改动的影响面很广需要给用户反馈通道才能迭代好。用户被推荐后点“换一杯”或者“不喜欢”都会作为负反馈信号记录到后端后续推荐时自动降低同类茶的优先级。7.3 事故三API数据延迟导致“天气描述与推荐不一致”现象某天有细心用户发现推荐理由里写着“雨天适合煮老白茶”但窗外明明是大晴天。查了日志定位原因主API的天气数据更新延迟了近40分钟系统拿着过期的“小雨”数据生成了推荐而用户刷新时看到的“晴天”已经是新数据。这类问题没法彻底消除因为数据源延迟是外部不可控因素。我的缓解方案是双管齐下一是在推荐文案里增加天气数据的时间戳让用户知道推荐的天气依据是什么时刻的观测值二是增加一个“数据新鲜度”的置信度标签——如果当前天气数据超过20分钟未更新会在推荐结果后附加一行小字提示“天气数据基于XX分钟前观测仅供参考”。这个修复虽然不完美但很好地管理了用户的预期投诉量减少了很多。做任何依赖第三方数据的推荐系统都要提前想清楚数据延迟的应对策略而不是等出了事故再补救。8. 一些我正在做的优化以及我个人的使用体会最后聊几个正在推进的优化方向和一个比较个人的使用体会。短期计划中我在做“用户口味画像”的轻量版目前是让用户给推荐结果点赞或点踩逐步建立一个基于反馈的隐性偏好模型后续可以给用户做更细致的个性化推荐。同时我正在扩充茶知识库目标是加入一些地方小众茶类让推荐的丰富度再上一个台阶。还有一件比较重要的事情冷泡茶的适用场景正在被天气模型单独处理。传统的“冷泡夏天”的简单逻辑太粗糙了我正在尝试建立“冷泡适宜指数”综合考虑气温、湿度、风速、日照等因素判断冷泡茶在什么时候真正比热泡更合适。这个指数完成之后会把冷泡推荐从“夏季专属”升级成“条件触发”。根据我自己前一段时间的实际使用数据——我用Windie Chai完成了超过两个月的每日推荐体验整体满意率大约在75%左右。剩余的25%里一部分是我自己觉得推荐偏保守一部分是文案语气不够贴合当日的心情。这个比例对于一个小体量的规则推荐系统来说还算能接受但也说明个性化方向还有很大的提升空间。Windie Chai这个项目最让我满意的地方不是技术多复杂而是一个很小的切入点被做深了。天气数据和茶文化都是巨大的领域但它们交叉的那个小缝隙刚好够一个独立开发者蹲在里面做出一个有点温度的产品。如果你也在做一个从自身需求出发的小项目我的建议是先找到一个足够具体的场景把一个很小的功能做到极致再考虑扩张。做深一个点永远比做浅十个点更有价值。
1. 从一个自用脚本到独立产品Windie Chai到底解决什么问题先交代一下背景。我自己是个重度天气依赖者每天起床第一件事不是刷社交软件而是看窗外、看气温、看湿度。但光看天气数字没什么用真正影响我决策的是“体感”——同样的25度在南方梅雨天和北方干热天完全是两种体验。后来我又迷上了喝茶发现一个更有趣的规律不同天气条件下人对茶的需求完全不一样。闷热天想来点清爽的生普或茉莉花茶阴冷潮湿天就想泡一壶暖和的老白茶干燥烦躁的时候岩茶的焙火香特别解郁。那时候我就想能不能做一个东西把“天气数据”和“茶饮推荐”结合起来这就是Windie Chai的起点。很多朋友第一反应是这不就是个带茶叶推荐的天气App吗其实不完全是。Windie Chai的核心不是“天气预报”而是把气象数据做一次语义转化——把温度、湿度、气压、风力这些冷冰冰的数字翻译成“此刻适合喝什么茶”的生活化建议。它本质上是一个基于气象特征的推荐引擎只是载体刚好是茶。项目的名字也从这个思路里长出来Wind是风代表天气和环境Chai是茶代表生活方式的落点。两个词拼在一起既点明了数据来源又点明了应用场景。如果你正在做类似“小而美”的工具类产品或者你对个性化推荐感兴趣又或者你只是想做一个能自己天天用的效率工具这篇内容应该能给你一些参考。我下面会把这套系统从数据、算法、工程到内容运营全部拆开讲包括踩过的坑和绕过的弯路。2. 天气数据不是拿过来就能用从气象API到体感特征值的加工链路2.1 为什么直接读温度湿度根本不够用我先说结论气象数据的原始字段绝对不能直接作为推荐逻辑的输入。我最早的原型版本犯过这个错误——直接用温度区间匹配茶类。温度26度以上推荐绿茶10到26度推荐红茶低于10度推荐熟普。逻辑够简单但实测效果非常扯。同样是28度的夏天一个湿度85%的雷雨天和一个湿度35%的干热天身体感受完全不同。前者整个人像泡在蒸汽里根本不想喝热茶后者虽然热但很干爽来一壶热乌龙出出汗反而畅快。后来我又试着把湿度加进去做二维匹配情况好了一些但还是有很严重的缺陷没考虑风力、没考虑体感温度、没考虑昼夜温差、也没考虑天气现象比如降雨、降雪、雾霾。你会发现直接拿原始字段做规则匹配参数一多规则就变得极其混乱几十条if-else堆下来根本维护不了。2.2 体感温度与“茶饮舒适度”建模后来我认真读了一些人体舒适度相关的资料发现气象学里早有现成的思路——体感温度模型。最经典的公式之一是澳大利亚气象学家Steadman提出的体感温度计算法它综合考虑了温度、湿度、风速和太阳辐射。我采用的简化版本思路是这样的首先用当前气温作为基准值根据相对湿度做修正湿度越高夏天感觉越热冬天感觉越冷根据风速做修正风力越大体感温度越低风冷效应根据是否降雨/降雪做场景修正。计算完之后我得到了一个“体感温度”数值。但这还不够因为茶饮推荐不能只看热冷还得看“舒适度”。我又建了一个维度叫“茶饮舒适度”它的取值范围是-2到2体感温度在18到24度之间且湿度适中时舒适度接近2属于“通体舒畅”的状态这时候人最适合品饮层次丰富、香气细腻的茶体感温度超过30度且高湿时舒适度接近-2属于“闷热黏腻”状态这时候身体直觉是想喝能“解腻、降温、发汗”的东西体感温度低于5度且湿度大时舒适度接近-2属于“阴冷潮湿”状态这时候需要的是温暖、厚重、有包裹感的茶。这个模型把复杂的天气形态压缩成一个可计算的连续值后面的推荐算法全部基于它展开。这一步是整个Windie Chai的核心资产也是和市面上“天气App广告位”模式拉开差距的地方。2.3 数据源选型与容错设计再说数据源。我用过好几家天气API国内的、国外的都有简单做一下对比供你参考国内某知名天气服务商的免费版数据更新频率和稳定性都不错缺点是免费额度有限而且部分字段的语义文档写得比较含糊。国际通用的OpenWeatherMap免费额度大、字段全但国内部分城市的小时级数据偶尔会出现延迟。还有一些聚合类气象数据平台数据源覆盖全球但精度参差不齐。最终我的选择是主数据源用国内服务商确保国内城市的数据及时性备用数据源用OpenWeatherMap主源失败时自动切换。两个源之间做字段映射统一成自己的内部数据模型。这里面有一个很容易踩的坑不同API对天气现象的描述代码完全不一样。有的叫“Rain”有的叫“Thunderstorm with light rain”有的直接给你一个天气编号。如果不在接入层做规范化和映射后面所有的规则匹配都会出问题。我在这个环节浪费了大概两天时间后来学聪明了写了一个统一的气象现象枚举表把所有可能的天气码映射到自己的业务语义上比如“晴”、“多云”、“阴”、“小雨”、“暴雨”、“雪”、“雾”、“霾”等十几个大类推荐逻辑只跟这个枚举表打交道彻底隔离了数据源的差异。3. 推荐引擎不是玄学把“天气-茶饮”的映射关系做成可解释的规则系统3.1 茶饮知识库的底层分类逻辑推荐引擎的上游除了天气特征还有一块必须做扎实就是茶的知识库。很多人做推荐系统会把重心全放在算法上但我的经验是领域知识的质量直接决定推荐效果的天花板。我没有按照传统的六大茶类绿、白、黄、青、红、黑做唯一分类维度因为这种分法在专业茶学里成立但在“天气对应关系”上并不直觉。比如乌龙茶里既有清香型的铁观音又有焙火重的岩茶两者在体感上的表现差异极大甚至超过了一些跨茶类的差异。所以我建了两层标签体系第一层是工艺属性茶类、发酵程度、焙火程度 第二层是体感属性茶性寒热、香气类型、口感厚度、适饮温度。举个例子绿茶和新生普在体感属性上就很接近——茶性偏寒凉香气清扬口感鲜爽偏薄适饮温度可以热饮也可以放凉了喝。而传统工艺的足火岩茶和小种红茶体感属性也接近——茶性偏温香气馥郁带焙火味或松烟香口感醇厚适合热饮。有了这套体感属性标签推荐引擎就不需要死记“绿茶对应夏天、红茶对应冬天”这种粗糙规则而是可以根据实时体感特征动态匹配“茶性寒热”、“香气类型”、“口感厚度”这些连续或离散的属性。3.2 规则引擎的具体实现思路推荐引擎我采用了两层结构粗筛层 精排层。粗筛层负责把茶叶池子里明显不符合当前天气的选项淘汰掉。规则很简单当体感温度低于10度时剔除所有茶性偏寒的茶默认只保留茶性偏温或偏热的茶当体感温度高于30度且湿度大于70%剔除所有口感厚重的发酵茶优先保留清新鲜爽、可冷泡的茶当“茶饮舒适度”小于-1.5时无论冷热都会倾向推荐有“发汗”效应的热茶比如老白茶、普洱熟茶。精排层就复杂一些我给每个候选茶打一个“匹配分”分数由四个子项加权求和得出温度匹配分基于体感温度与茶饮适饮温度的重合度计算权重占30%湿度匹配分高湿天气对口感厚重的茶减分对带有清凉感的茶加分权重占25%天气现象匹配分雨雪天倾向温暖型茶饮干热晴日倾向清爽型茶饮雾霾天倾向有“清肺”意象的茶饮权重占25%时段匹配分早晨提神型午后消食型晚间安神型权重占20%。四个子项算完加权求和后排序取Top3作为最终推荐同时附带一段推荐理由。3.3 为什么不用机器学习模型——小数据场景的工程务实主义可能有人会问既然都做了加权评分为什么不上一个机器学习模型来做推荐这个问题我在项目初期也认真纠结过。最后放弃机器学习方案主要有三个原因第一数据量根本不够。机器学习模型要有靠谱的效果至少需要几千上万的标注样本。我自己一人维护这个项目哪来那么多标注数据先不说采集工作量光是“某天气条件下什么茶好喝”这种主观感受本身就很难有标准答案。第二可解释性太差。如果我告诉用户“因为模型算出来匹配分是0.87所以推荐你喝大红袍”用户完全无感。但如果我告诉用户“今天体感偏湿冷推荐你喝一壶足火肉桂焙火香能中和空气中的潮闷感”用户立刻能感知到推荐背后的逻辑。第三规则系统在小规模场景下维护成本更低。规则引擎的每一个判断逻辑都可以写成可读的代码出了偏差一查就知道是哪个规则的问题。而模型一旦出现推荐偏差排查成本就高得多。当然规则引擎也有天花板——规则再多也没法覆盖所有边缘case。我的处理方式是做一层“随机漫步”机制在推荐结果的Top3里每次有较小概率插入一个打破常规的选项目的是让用户偶尔产生意外惊喜。这个机制的效果还挺好不少用户反馈中最惊艳的推荐恰恰来自这些“规则之外”的选项。4. 内容与运营茶饮推荐的另一半功夫在“文案”和“交付体验”4.1 从推荐到交付每个推荐必须讲得出“为什么”前面说的都是算法侧但一个推荐系统的体验好坏文案的作用被严重低估了。我可以直接给你看Windie Chai里一个典型的推荐理由是怎么生成的场景体感温度12度湿度83%小雨东北风3级。系统推荐的茶是老白茶寿眉饼推荐的解释文案是“细雨绵绵的天气里空气湿度超过80%整个人容易透着一股祛不掉的凉意。这时候煮一壶老寿眉枣香、药香在水汽里慢慢化开热汤入喉后背微微发汗整个人就从潮冷的束缚里松出来了。”这段话不是写死的模板而是由三个部分动态拼接出来的第一部分描述当前天气的身体感受基于体感温度和湿度生成 第二部分带入具体的茶品感官描述从茶知识库的感官描述字段取 第三部分给出情绪收尾根据天气场景的情绪语料库生成。为了让这套文案系统能跑起来我花了大量时间整理茶品的感官描述语料。一片茶叶至少要有四个维度的表述香气干茶香、杯盖香、汤香、叶底香、滋味甜度、苦度、涩度、回甘、生津、汤感厚度、顺滑度、收敛性、体感发汗、暖腹、清爽、润喉。每款茶录入知识库时我都要把感官描述写成有画面感的文字而不是只写“香气浓郁、滋味醇厚”这样的空洞套话。4.2 冷启动阶段的内容积累策略内容建设是这类项目里最容易被低估的工作量尤其是你一个人做全栈时。我的做法是不追求茶品数量的大而全而是先把常用茶类的基础款覆盖掉。目前知识库里大约录入了几十款常见的、容易买到的茶品每款都包含茶类、产地、工艺特征、感官描述、适饮场景、储存建议等信息。这些茶品基本覆盖了中国茶消费市场的绝大多数常见品类——绿茶、青茶、红茶、白茶、黑茶、再加工茶都有了。这个策略的好处是推荐系统不需要盲人摸象。每个推荐背后至少有真实的茶品信息做支撑用户看完推荐想尝试时也能在电商平台顺利买到对应产品。在冷启动期我还做了一个很笨但有效的活自己喝、自己记、自己写品鉴笔记。每录入一款茶我至少要喝三次以上分别在晴天、阴天和雨天喝记录下不同天气下同一款茶的表现差异。这些真实笔记成了文案系统里最宝贵的语料来源。4.3 推送时机与用户触达的细节优化茶饮推荐不是用户打开App才生效它还可以主动触达。在这个环节我踩过不少坑。最早的推送策略非常简单粗暴每天早上8点推送一次当日推荐。结果打开率低得可怜用户反馈也很平淡。后来仔细分析了一下问题出在“时机”上——早晨8点推送很多人还在通勤路上根本来不及看推荐内容等有空看的时候已经过了那个情绪点。我把推送时机分成了三个关键时间窗06:30-08:00侧重“唤醒”场景推荐偏轻爽、低咖啡因的茶或者有提神效果但不会过度刺激的茶品13:30-14:30侧重“午后消食”场景推荐能解腻、助消化的茶比如熟普洱、六堡茶、陈年铁观音20:00-22:00侧重“放松安神”场景推荐低咖啡因、有温暖感的茶比如老白茶、熟普、陈皮水。每个时间窗的推送内容、推荐茶品、文案语气都是独立的这样用户就不会觉得每天收到的都是同一个模板的变体。5. 工程落地个人开发者如何用轻量架构撑起一个完整产品5.1 技术选型为什么我选了前后端分离的轻量方案作为一个个人开发者技术选型最重要的原则是能少维护的东西绝不多引入。前端我选了响应式网页方案核心原因是茶饮推荐的使用场景天然分布在多个设备上——用户可能在手机上看推荐在平板上查茶品详情在电脑上浏览知识库。响应式网页一套代码就能覆盖所有端不用维护多套原生应用。后端用的是一个轻量级的Python Web框架主要承担三个职责天气数据的拉取和缓存、推荐引擎的计算、API接口的暴露。数据持久化方面考虑到知识库的数据量不算大我用了SQLite起步后续如果数据量涨上来再迁移到更重的数据库也不迟。整个系统跑在一台低配云服务器上就够了——天气数据是周期性拉取的推荐引擎的计算量也很小这台机器的负载长期在个位数百分比。这也是个人项目最舒服的状态用最少的钱维持一个全年全天候在线的服务。5.2 天气数据的缓存与轮询策略天气API虽然便宜但也不能无脑频繁调用。我设置的轮询策略是每30分钟从主数据源拉取一次当前天气和当日预报覆盖用户量集中区域的默认城市同时支持用户手动刷新时实时拉取。为了防止API调用超限我在中间加了一层缓存用户请求推荐结果时如果缓存中已有30分钟内生成的结果直接返回只有缓存过期或用户主动刷新时才触发新的计算。这样一个普通用户一天打开App几次API调用次数完全可控免费额度绰绰有余。另外气象数据是有时效的特别是降雨类的短时预报30分钟前和现在的天气可能已经完全不一样了。所以我还加了一个优先级机制如果用户主动刷新时发现当前天气与推荐文案里描述的天气状况不符会生成一条简短的修正说明如“10分钟前开始转雨推荐调整为更适合雨天的茶”保证推荐结果的时效性。5.3 前端展示让推荐结果“一眼懂二眼想点”说完了后端再聊前端展示的几个关键设计。首页的核心信息层级按优先级排列一共分四块当前天气状况的视觉化呈现以高辨识度的天气图标和体感温度为核心“今日推荐茶”卡片的强展示位包括茶品名称、品类标签、一句话推荐理由三个备选推荐以轻量列表形式存在“为什么推荐这杯茶”的折叠区域点击展开后能看到完整的气象特征分析、茶品体感属性匹配说明。这里面我认为最重要的设计决策是不把天气数据放在第一位而是把“茶饮推荐”放在第一位。为什么因为用户打开这个产品的动机是“今天喝什么茶”天气只是辅助决策的输入信息。如果用户想查详细天气他自然会去天气App没必要在你这里看。把推荐结果前置让用户一眼就能获得核心价值是留存率的关键。6. 从Windie Chai到任何一个推荐类产品这套方法论的可迁移性6.1 推荐系统的“领域知识优先”原则做完这个项目我最大的感悟是推荐系统的成败主要取决于对领域知识的理解深度算法反而是次要的。我现在把这个方法论总结成一套可迁移的流程如果你也想做类似的推荐类产品可以参考第一步建立一个领域知识库不追求数量但要确保每个实体的描述足够立体比如茶的香气、口感、体感都需要有具体描述而不是笼统的一个标签。第二步找到领域对象的“体感属性”就是那些能影响用户主观感受的属性把它们抽出来作为推荐的特征维度。第三步把环境因素这里指天气映射到这些体感属性上建立起“环境特征-体感属性-领域对象”的关联链条。第四步设计一套可解释的匹配规则让用户能看懂推荐的原因。6.2 三个在任何领域都适用的执行要点在做Windie Chai的过程中有几个执行层面的经验放在任何推荐类项目里都成立第一可解释性永远不是一个可选项它是产品体验的一部分。用户需要理解“为什么推荐这个给我”否则推荐结果很容易被当成垃圾信息。尤其是生活方式类的推荐产品推荐理由直接决定了用户愿不愿意尝试。第二规则引擎在冷启动阶段永远优先于机器学习。不要一上来就追求“智能”先把70%的常规场景用规则覆盖好等积累足够多的用户反馈数据后再考虑用模型替代一部分规则。第三内容建设需要提前规划不能临时抱佛脚。推荐系统的体验上限由知识库的质量决定而知识库的建设是一个漫长的积累过程。我在这个项目里最大的时间投入不是写代码而是喝茶、记笔记、整理感官描述这些看不见的功夫最终都转化成了用户能感知的推荐质感。7. 避坑实录三次典型事故及排查链路这部分我想原原本本还原几个真实踩坑的过程每一个都花了不少时间才定位到根因希望你能绕开。7.1 事故一所有推荐都指向了“暖茶”——体感温度的降权陷阱现象上线后第二天有用户反馈无论天气怎么样推荐结果永远都是红茶、熟普这类“暖茶”绿茶和白茶几乎从未出现在首推位上。我没有直接改代码而是先做了数据排查。查了推荐日志发现每次推荐计算出来的排序结果温度匹配分几乎都压倒了其他子项。进一步追查发现体感温度模型在高温高湿天气的修正幅度太大——比如实际气温28度、湿度80%的天气体感温度被修正到了22度以下系统误判为“偏凉”自然就推荐了暖茶。根因是湿度修正系数设置不合理。我用的体感温度公式里高湿度对温度的综合影响方向在不同季节是不同的——夏天高湿会让人感觉更闷热冬天高湿会让人感觉更阴冷。但我的系数是全年统一取一个值导致高温高湿的夏天被过度修正成“凉”。修复方案是引入季节参数4到10月按夏季修正系数计算11月到次年3月按冬季修正系数计算。修复后再跑同一批历史天气数据推荐分布明显合理了。7.2 事故二冷泡茶推荐导致的“寒性堆积”——推荐只算当下、不算累积现象连续几天高温天气系统每天都推荐冷泡绿茶。有用户反馈说喝了三天冷泡后胃开始不舒服了。这个案例让我意识到推荐系统不能只看当下的天气还要考虑用户的“饮茶历史”。如果用户连续几天都被推荐了茶性偏寒的茶身体可能已经积累了寒性这时候即使天气仍然炎热也应该推荐一款茶性稍微偏温的茶做“中和”。我在推荐引擎里加了一个用户维度的“茶性累积”字段系统会记录用户最近几次推荐的茶性寒热值在精排阶段对候选茶的茶性做一个加权修正。连续推荐寒性茶之后寒性茶会被降权暖性茶会被适当提权。这个改动的影响面很广需要给用户反馈通道才能迭代好。用户被推荐后点“换一杯”或者“不喜欢”都会作为负反馈信号记录到后端后续推荐时自动降低同类茶的优先级。7.3 事故三API数据延迟导致“天气描述与推荐不一致”现象某天有细心用户发现推荐理由里写着“雨天适合煮老白茶”但窗外明明是大晴天。查了日志定位原因主API的天气数据更新延迟了近40分钟系统拿着过期的“小雨”数据生成了推荐而用户刷新时看到的“晴天”已经是新数据。这类问题没法彻底消除因为数据源延迟是外部不可控因素。我的缓解方案是双管齐下一是在推荐文案里增加天气数据的时间戳让用户知道推荐的天气依据是什么时刻的观测值二是增加一个“数据新鲜度”的置信度标签——如果当前天气数据超过20分钟未更新会在推荐结果后附加一行小字提示“天气数据基于XX分钟前观测仅供参考”。这个修复虽然不完美但很好地管理了用户的预期投诉量减少了很多。做任何依赖第三方数据的推荐系统都要提前想清楚数据延迟的应对策略而不是等出了事故再补救。8. 一些我正在做的优化以及我个人的使用体会最后聊几个正在推进的优化方向和一个比较个人的使用体会。短期计划中我在做“用户口味画像”的轻量版目前是让用户给推荐结果点赞或点踩逐步建立一个基于反馈的隐性偏好模型后续可以给用户做更细致的个性化推荐。同时我正在扩充茶知识库目标是加入一些地方小众茶类让推荐的丰富度再上一个台阶。还有一件比较重要的事情冷泡茶的适用场景正在被天气模型单独处理。传统的“冷泡夏天”的简单逻辑太粗糙了我正在尝试建立“冷泡适宜指数”综合考虑气温、湿度、风速、日照等因素判断冷泡茶在什么时候真正比热泡更合适。这个指数完成之后会把冷泡推荐从“夏季专属”升级成“条件触发”。根据我自己前一段时间的实际使用数据——我用Windie Chai完成了超过两个月的每日推荐体验整体满意率大约在75%左右。剩余的25%里一部分是我自己觉得推荐偏保守一部分是文案语气不够贴合当日的心情。这个比例对于一个小体量的规则推荐系统来说还算能接受但也说明个性化方向还有很大的提升空间。Windie Chai这个项目最让我满意的地方不是技术多复杂而是一个很小的切入点被做深了。天气数据和茶文化都是巨大的领域但它们交叉的那个小缝隙刚好够一个独立开发者蹲在里面做出一个有点温度的产品。如果你也在做一个从自身需求出发的小项目我的建议是先找到一个足够具体的场景把一个很小的功能做到极致再考虑扩张。做深一个点永远比做浅十个点更有价值。
