周末安排生成器：从规则过滤到加权评分的推荐系统实战

周末安排生成器这个名字听起来像个玩具但如果你真的经历过周四晚上三个人在群里发了四十条消息从随便聊到都行最后定了个火锅还被吐槽又吃火锅——你就知道这东西解决的不是技术问题是家庭矛盾和社会关系问题。我花了一周时间把这个生成器从想法做成能跑的工具输入预算、人数、偏好它自动输出几个完整的周末活动方案包括时间安排、花费明细、适合人群和备选路线。这篇文章把完整的设计思路、数据结构、评分算法和踩坑记录都摊开讲不管你是想做个自用小工具还是想给自己的小程序加一个类似功能都可以直接抄作业。1. 先说说这个生成器要解决什么问题1.1 选择困难的真实痛点周末安排这件事表面上是去哪里玩实际上是在信息过载和多人决策下做一次低风险选择。打开点评类软件身边三公里内有几百个去处打开短视频平台人人都在必打卡。看起来选择很多但每个选择背后都带着不确定性这家店是不是照骗、这个公园周末会不会人挤人、这个展览小孩能不能进、人均三百的日料吃完会不会被说浪费。我统计过自己过去一年的周末安排真正落地执行的方案里超过六成是之前去过且没踩雷的地方。这其实不是恋旧而是人对未知选择的天然规避。问题不是没有活动而是没有一条足够清晰、可解释的筛选路径。周末安排生成器本质上是在做一件事把海量选项压缩成三个足够靠谱的选项并且告诉你为什么选它、要花多少钱、大概怎么走。1.2 为什么这种场景适合做成生成器生成器这个词最近被玩坏了很多所谓的生成器就是把几个模板拼在一起随机输出。但周末安排这个场景不一样它有明确的结构化输入预算、人数、偏好有半结构化的约束条件距离、时间、容纳人数有清晰的质量评判标准预算不超、偏好匹配、时间可行。当一个问题的输入输出都是结构化、可量化的它就非常适合用程序逻辑来做确定性推荐而不是靠人脑临时拍板。更重要的是这种推荐需要可解释。你说AI帮你推荐了三个地方用户不一定信任但你说按人均预算120元、喜欢户外、5人同行筛掉了86%的选项剩下这三个匹配度最高用户就愿意试一次。规则引擎加加权评分恰好能满足这种诉求——它不黑箱每一步都能讲清楚为什么。1.3 需求边界哪些能做哪些不该做做之前我把功能边界划得很清楚。它做的是方案筛选和组合不做实时信息查询。也就是说不接票务库存、不查实时排队、不验证店铺今天是否营业。这些信息变化太快一个小工具去维护的成本远超它的价值。正确的做法是生成器给一个合理候选用户点击候选去地图、点评或电话确认当前状态两步完成闭环。我见过很多同类工具死掉的共同原因就是什么都想管又想接天气、又想接导航、又想接预订最后变成一个信息中台单人维护根本跑不动。所以这个项目的原则非常明确离线可跑、逻辑自治、推荐结果只是半成品留给用户最后一步自己确认。2. 整体设计从需求到方案的三个关键决策2.1 方案选型为什么不上人工智能最常被问到的一个问题是现在大模型这么能打为什么不用它直接生成周末方案我试过效果确实惊艳但有几个现实问题解决不了。第一是成本每次调用都要花钱还要考虑接口稳定性第二是可控性大模型生成的方案可能极好也可能离谱到把剧本杀安排在周二且默认你不在上班第三是可复现性同一输入反复生成结果不一致用户会觉得这工具不靠谱。所以我最终采用了规则过滤 加权评分 轻量随机扰动的技术路线。所有推荐结果都有明确的计算依据预算超了直接筛掉人数不符合直接筛掉然后按标签匹配度打分排序最后在分数接近的候选中引入一点随机性保证每次推荐不完全一样但也绝不会超出合理范围。这套方案的优势是零依赖、离线可跑、结果可解释、逻辑完全可控配合一个简单的活动库已经能覆盖90%的使用场景。2.2 活动库的数据结构设计整个生成器的心脏不是算法而是活动库。如果活动库本身质量低再聪明的算法也推荐不出好东西。我把每个活动设计成一条结构化记录字段不多但每个都经过仔细推敲字段示例说明activity_id0012唯一标识name城郊湿地公园骑行活动名称categoryoutdoor一级分类indoor/outdoor/food/culture/sport/relaxtags骑行, 自然, 亲子, 低消费偏好匹配用的二级标签min_group1最小成行人数max_group6最大合适人数cost_per_person_min30人均费用下限单位元cost_per_person_max80人均费用上限单位元duration_hours3.5预计耗时小时suitable_timeday适合时段day/night/bothrisk_levellow踩雷风险程度内部评估用remark湿地公园南门有免费停车场补充提示直接展示给用户这里有个容易忽略的细节成本字段我没用固定值而是用了区间。因为实际花费永远是波动的——打车还是地铁、吃农家菜还是自带野餐上下浮动很大。区间的好处是评分时可以计算预算在区间内的位置从而判断这项活动对预算的友好程度而不是一刀切。2.3 单活动推荐还是组合方案推荐一开始我做的版本只推荐单个活动比如推荐你去湿地公园。但实际用起来发现一个问题周末的时间跨度是八到十个小时单活动输出总让人觉得空落落的像只安排了个开场。后来我改成三段式结构上午场、下午场、晚间场生成器可以输出一个完整的一日方案也可以只输出单场推荐由用户选择。组合方案的复杂度比单活动高一个量级因为要考虑活动之间的时间衔接、空间距离、预算累加。我的做法是不做真正的全排列组合优化那在项目初期完全没有必要。而是用贪心策略先按预算和人数筛出所有合格活动再按偏好分数挑出得分最高的两到四个作为种子活动然后围绕种子活动找同区域、时间段兼容、消费水平相近的补充活动拼出组合方案。用贪心的原因是它计算量小、逻辑透明而且实际效果并不比复杂优化差多少。3. 核心逻辑拆解预算、人数、偏好是怎么变成推荐结果的3.1 预算维度人均预算与总预算的换算逻辑预算是所有约束里最硬的一条因为它直接决定活动库的筛选范围。但预算这个词其实有歧义用户说的预算800到底是一共花800还是人均800这个不搞清楚后面的计算全白搭。我的处理方式是在输入阶段强制让用户选择总预算和人均预算二选一同时给出一个默认建议两人及以下按总预算理解三人及以上按人均预算理解。这个默认规则是我翻了大量真实出行账单得出的经验比让用户填两次要顺滑得多。在换算逻辑上总预算除以人数得到人均预算然后留出15%的容差空间。比如四个人总预算800换算人均是200但实际筛选时的人均上限取 200/1.15 ≈ 174 元。这个容差不是拍脑袋定的是因为几乎所有活动都会有隐性消费——停车费、买水、临时加个甜品如果卡在预算上限最终结算大概率超支。去掉这15%推荐结果会更贴近真实花销。活动库筛选时用的是 cost_per_person_max 与修正后人均上限的匹配度而不是简单的区间中值小于等于预算。3.2 人数维度活动容量匹配与人数自动修正人数这个维度看起来简单实际上是最容易出错的。周末活动的容量问题不是能不能装下这么多人而是多少人合适。剧本杀店可能能接待8个人但4个人玩起来体验最好某个网红餐厅有20桌但2个人去只能坐在门口过道。所以活动库里的 min_group 和 max_group 表示的是体验最佳的人数区间而不是物理容量上限。筛选时用人数是否落在最佳区间内做硬过滤落在区间外直接排除。但这里我加了一个自动修正机制如果用户在偏好里明确勾选了某个类别且当前人数与该类别所有活动的容量区间都不匹配就给出一个人数调整建议。比如四个人想去玩密室逃脱但当天可推荐的密室活动库里 max_group 都是2人系统就会明确提示该偏好下四人同行体验较差建议拆成两组或改选其他类别。这个提示比强推一个不合适方案要好得多用户会理解这是负责任的筛选而不是功能缺陷。3.3 偏好维度标签体系与加权评分公式偏好是整个推荐系统里最需要精细设计的一环因为它是唯一一个软约束。预算超了不能妥协但偏好其实是允许被部分满足的。我的标签体系分两层一级是活动类别户外、室内、美食、文化、运动、放松二级是具体标签亲子、拍照、安静、刺激、遛弯、约会、宠物友好等。用户输入偏好时可以自由勾选类别和标签也可以直接用一段自然语言描述由前端的简易分词模块映射到标签上。打分公式我用了线性加权权重根据场景动态调整def score_activity(activity, user_profile, context_weights): budget_score calc_budget_score(activity, user_profile.budget_per_person) group_score calc_group_score(activity, user_profile.group_size) pref_score calc_pref_score(activity.tags, user_profile.preferences) variety_score context_weights.get(variety_bonus, 0) return ( budget_score * 0.35 group_score * 0.25 pref_score * 0.35 variety_score * 0.05 )权重不是固定的。如果用户把预算卡得很紧budget_score 的权重会动态上调到0.45如果用户明确勾选了带孩子pref_score 权重上调。这个动态调整逻辑叫约束感知加权说人话就是越硬的约束权重越大越软的约束越靠后。这样做的好处是推荐的方案在用户的硬性安全区内做偏好优化而不是在偏好里碰运气。3.4 排序与兜底评分公式之外的两个保障光靠评分排序一定会遇到一个问题同类活动霸榜。如果用户偏好里勾了美食评分最高的前五个全是火锅哪怕用户一周前刚吃过火锅。解决办法是引入一个简单的多样性惩罚对每个一级类别设定展示上限默认最多两个类别之间按最高分交错排列。这个限制不改变候选池只影响最终展示顺序实现成本很低但用户体感提升非常明显。兜底机制同样重要。当所有活动经过硬过滤后数量不足三个时系统会进入放宽模式先放宽偏好过滤只保留类别约束去掉二级标签再放宽人数修正用可接受区间替代最佳区间最后才放宽预算容差。这个顺序是固定的预算永远是最后放宽的因为超预算的体验伤害最大。我见过很多推荐算法在冷启动时推荐出一堆不匹配方案就是为了凑数量。宁可给用户两个优质方案加一句本周可选活动较少也不要硬塞五个。4. 实操过程从零搭一个能用的周末安排生成器4.1 第一步定义活动数据样例活动库初期不需要搞大而全我建议先放三十到五十条高质量活动覆盖六个一级类别每条数据都仔细核对过价格区间和适合人数。质量优先的原因很简单生成器的口碑取决于用户对前三次推荐的满意度三十条校准过的数据足够撑起前三次的体验等用户反馈回来了再扩库。给一个我实际使用的活动数据样例{ activity_id: act_023, name: 老城区City Walk 街头咖啡馆歇脚, category: culture, tags: [拍照, 漫步, 文艺, 古城, 低消费], min_group: 1, max_group: 6, cost_per_person_min: 20, cost_per_person_max: 60, duration_hours: 3.0, suitable_time: day, risk_level: low, remark: 建议穿舒服的鞋路线从南门出发逆时针走咖啡馆集中在中间区域 }每条数据的 remark 字段我建议写得越具体越好因为生成器输出的方案里会直接把这条 remark 展示给用户等于帮用户排掉了到了发现鞋穿错了找不到停车位这类高频小坑。4.2 第二步用Python实现过滤与评分核心代码并不复杂总共两百行左右就能跑通完整流程。第一步是硬过滤把不符合预算和人数约束的活动直接丢掉def hard_filter(activities, budget_per_person, group_size): filtered [] for act in activities: if act[cost_per_person_max] budget_per_person * 0.85: continue if not (act[min_group] group_size act[max_group]): continue filtered.append(act) return filtered硬过滤之后是评分排序。这一步我建议把每个维度的得分单独打出来方便调试时一眼看出某个推荐为什么靠前、某个为什么靠后def rank_activities(activities, profile): scored [] for act in activities: s { activity: act, budget_score: round(budget_score(act, profile), 2), group_score: round(group_score(act, profile), 2), pref_score: round(pref_score(act, profile), 2), } s[total] s[budget_score] * 0.35 s[group_score] * 0.25 s[pref_score] * 0.35 scored.append(s) scored.sort(keylambda x: x[total], reverseTrue) return scored[:10]这里有两个细节值得注意一是硬过滤时用的是 cost_per_person_max 而不是 min 或 mid取最大值做判断是为了防超支二是评分时 group_score 的算法不是简单的人数在区间内就是满分而是偏好把人群密度考虑进去——2个人出现在 max_group 为2的活动里比4个人出现在 max_group 为4的活动里得分高因为人少时体验自由度更高这也是我在实际反馈中总结出来的规律。4.3 第三步命令行交互与简易网页界面MVP 阶段我没做花哨的界面一个命令行交互就够了。用户按提示依次输入预算类型、金额、人数、偏好编号程序输出三个推荐方案。这个阶段最重要的是把交互逻辑和算法逻辑分离方便后面套任何前端壳子。请输入预算金额: 800 按总预算(T)还是人均预算(P)? T 出行人数: 4 选择偏好可多选用逗号分隔 1. 户外 2. 室内 3. 美食 4. 文化 5. 运动 6. 放松 请输入编号: 1,4命令行跑通后再花半天时间套一个简单的网页界面一个输入表单加一张结果卡片列表就够。表单字段就是前三步的映射结果卡片把推荐活动的名称、时间段、人均花费、总花费预估、地址提示、remark 全部展示出来。技术上我用的是一个简单的 Python Web 框架加模板渲染不涉及复杂的前端构建链路部署到任何一台小服务器上都能跑。4.4 一次完整的运行演示四口之家、800元预算拿真实数据跑一遍大家感受一下输出效果。输入是总预算800元4人两个大人两个小孩偏好勾了户外和文化。系统内部处理过程是这样的总预算800除以4人均200容差修正后筛选上限为170元。硬过滤活动库四十条里人均上限超170的直接淘汰剩22条。人数过滤4人不在最佳区间内的再淘汰剩13条。偏好评分13条里按标签匹配度排序户外文化得分最高的三条分别是城郊湿地骑行户外标签高、老城区City Walk文化标签高、科技馆半日游文化亲子标签都匹配。多样性约束户外、文化各保留一个主推第三个从得分稍低的候选中选出同时考虑时间衔接。最终输出的方案是上午去湿地公园骑行两小时中午在公园附近的农家菜馆吃饭下午转场去老城区做City Walk傍晚找一家街边咖啡馆收尾。全天下来的预估人均在150元出头总花费620元左右留了一百多的余量完美落在预算内。5. 实测中踩过的坑与排查技巧5.1 预算超支三个容易算错的地方第一版上线后用户反馈里出现最多的就是推荐的时候说人均100实际花了160。排查下来是三个问题叠加一是部分活动数据里 cost_per_person_max 填得太乐观没有包含停车费、门票、园内交通二是容差系数只作用在筛选端没有同步到展示端导致推荐卡上显示的预估费用低于真实筛选阈值三是组合方案里活动A和活动B都卡在各自预算边缘加在一起就爆了。我给的修复方案是三层数据录入时强制要求成本字段至少包含交通、门票、基础消费三类明细不能只填一个名义价格展示端所有费用预估统一用 cost_per_person_max 加上10%浮动显示组合方案在贪心拼接时检查累计总费用一旦超过用户总预算的95%就停止追加晚间场活动。这三个改动上线后超支类投诉降了八成。5.2 偏好冲突多人出行怎么处理五个人一起出来一个想去户外徒步一个想吃日料一个想逛博物馆一个想在酒店躺着还有一个说随便。这种情况下如果系统只按单一偏好推荐注定得罪大多数人。我一开始的做法是取所有偏好的交集结果经常是交集为空一个推荐都出不来。后来改成两步策略先计算每个人勾选的偏好类别的票数权重票数最高的两个类别作为主推荐方向然后在方案组合阶段用一个轮换机制保证不同类别都有露脸机会——比如上午按最高票推户外下午按第二高票推美食晚上再推一个中和型活动。这样五个人都有一部分需求被满足了比只满足大多数人的方案实际接受度更高。5.3 结果重复率过高多样性惩罚机制还有个高频吐槽是每次打开推荐都差不多。原因是活动库只有四十条硬过滤后剩十几条评分排序后头部永远那几个。加上多样性惩罚之后情况好了一点但还是会重复。我后来加了两个补充手段一是分值相近的活动中引入一个5%的随机浮动让排序不完全确定二是按周粒度记录推荐历史同一周内同一个活动最多出现在推荐结果里一次。这里要特别强调一点随机浮动必须控制在5%以内否则会让用户觉得推荐不稳定。当前一周的推荐和上一周完全不一样用户反而会觉得算法变了。历史记录的粒度也需要注意是按周不是按天因为用户不太可能一周内重复查看这个工具按天记录等于没记录。5.4 常见问题速查表把实际运维中遇到的问题整理成一个速查表后续排查时对照着看非常方便问题现象可能原因处理办法推荐结果数量不足3个硬过滤条件过严按优先级放宽偏好、人数、预算容差用户反馈实际花费超预算成本字段口径不统一核查成本明细展示端加10%浮动推荐结果同质化严重多样性惩罚不足增加类别展示上限引入5%随机浮动多人出行偏好多且冲突单一交集导致空结果改为票数权重 轮换机制活动库数据错误被盯上录入时缺乏校验每次发布前跑一遍口径校验脚本同一活动一周内反复出现推荐历史未记录增加周粒度历史去重晚间活动结束后交通不便suitable_time 约束太粗增加 user_rating 扩展运维建议单独把毛坯逻辑先行反馈驱动迭代作为一条经验写下来我认为整个项目保持能用的关键。第一版生成器没有接天气没有接地图没有做用户系统这些问题在实测中不断暴露但每次只改一个点改完立刻验证三十天左右就稳定了。6. 后续可以怎么扩展以及我为什么不扩展6.1 可以考虑接入天气和实时信息最自然的扩展方向有两个一是接一个天级别天气预报雨天自动降低户外活动的得分甚至直接过滤掉二是接入地图或点评类的二手信息辅助判断活动是否正常营业。前者逻辑简单一个接口加一个条件判断就能搞定后者工作量大但能显著降低推荐了结果店关了的尴尬。如果有余力我建议先做天气性价比最高用户也最容易感知到这工具是活的。6.2 建立用户反馈闭环活动库的数据质量不能靠开发者一个人维护需要用户反馈来持续修正。我的设想是每次推荐方案出来后在底部加两个按钮这个方案靠谱和这个方案踩坑了点击后记录到活动库的风险字段里。够一定样本量后评分公式里可以加入一个历史满意度因子让被验证的好活动排名自然上升。这个功能我最终没有在MVP里做因为样本量不够反而会引入噪声但如果你的工具准备长期运营建议从一开始就把反馈入口埋好。6.3 保持克制的理由最后聊聊为什么不继续扩展功能。这个工具的本质是帮助用户从混乱里快速抓到一个合理选项它的价值恰恰来自简单。每多接一个接口、每多增加一个输入项用户的心理负担就重一层就又回到了选择困难的起点。我个人的体会是安排周末这种低频需求用户要的不是永不出错的最优解而是三十秒内给我一个够好且不荒唐的选择。这个工具能做到这一点就已经完成了它最核心的使命。