基于内容过滤的居家健身推荐系统：Python与Flask实现与调优

简介这是一份面向高校人工智能、计算机及相关专业学生的个性化居家健身推荐系统项目基于Python Flask框架与基于内容的过滤算法开发。系统通过解析用户健身目标、体能水平与可用设备智能推荐相适应的锻炼方案能够缓解居家健身缺乏指导、计划难以坚持的痛点适合作为毕业设计或课程作业参考。资源共2000个文件压缩包大小96.4MB其中包含1114张JPG图片、874个JSON数据文件、5个HTML前端页面、2个CSV数据集及Python源码与说明文档图片与JSON多用于界面展示和数据交换HTML页面覆盖初、中阶推荐模板。目前已有111人学习下载。下载后不仅可获得可运行的项目源码、清洗后的健身数据集、多页面推荐模板还可梳理从数据采集、清洗到内容过滤推荐、用户界面搭建的完整流程方便直接复现与二次开发。1. 居家健身推荐系统拆解一个能跑通的内容过滤项目推荐系统听起来总是带着一点玄学色彩好像只有大厂的海量用户数据才能撑起来。但这个基于 Python 与 Flask 的居家健身推荐系统属于完全不同的路子它不需要任何历史行为数据纯靠内容过滤算法就能根据用户的健身目标、体能水平和可用设备从一份动作库里挑出合适的训练方案。整套代码包含数据清洗脚本、推荐算法、五个 HTML 页面和完整的 Flask 路由跑起来就是一个能交互的 Web 应用。对正在做毕设或课程设计的人来说它的价值在于把「推荐系统」从黑匣子变成了可以一行行读懂的代码非常适合用来讲解基于内容的过滤原理也是快速交付一个完整项目的捷径。2. 先处理数据exercises.csv 到清洗后的特征矩阵2.1 数据集里到底有什么拿到压缩包解压后第一眼看到的就是两个 CSV 文件exercises.csv和exercises_cleaned.csv。这个命名方式很直白前者是原始数据后者是清洗后的版本。做推荐系统的人都知道一句话推荐效果的上限在数据质量算法只是逼近这个上限。所以这个项目把数据处理的产物单独存了一份就是为了让你能直接对比清洗前后的差异。原始数据是典型的健身动作库每一行代表一个动作列大致包含动作名称、目标肌群、器械类型、难度等级、动作说明等字段。我打开看了一遍字段结构基本如下表字段示例值说明exercise_nameBarbell Curl动作名称body_partArms目标肌群equipmentBarbell所需器械levelBeginner难度等级instructions一段文本动作要领这里有个很容易忽略的坑equipment字段在部分行里是逗号分隔的多个值比如Barbell, Bench表示这个动作需要杠铃和卧推凳两种器械。如果直接把这个字段当成普通字符串去匹配推荐结果会漏掉大量需要组合器械的动作。2.2 清洗脚本的核心逻辑清洗的目标非常明确把原始数据变成推荐算法可以直接消费的结构化特征。我一般会写一个独立的预处理脚本把这个项目的清洗逻辑拆成四步每一步都对应一个明确的处理目标。import pandas as pd # 读取原始数据 df pd.read_csv(exercises.csv) print(原始数据行数:, len(df)) # 1. 去除完全重复的行 df df.drop_duplicates(subset[exercise_name]) print(去重后行数:, len(df)) # 2. 处理空值难度等级为空的动作直接丢弃 df df.dropna(subset[level]) # 3. 文本统一小写并去除首尾空格 text_cols [exercise_name, body_part, equipment, level] for col in text_cols: df[col] df[col].str.strip().str.lower() # 4. equipment 字段拆分把逗号分隔的多个器械转成列表存进新列 df[equipment_list] df[equipment].str.split(,) df[equipment_list] df[equipment_list].apply(lambda x: [i.strip() for i in x]) # 保存清洗结果 df.to_csv(exercises_cleaned.csv, indexFalse) print(清洗完成剩余行数:, len(df))这段代码的逻辑其实就是在给推荐算法铺路。第 1 步去重是为了保证同一个动作不会在推荐列表里出现两次第 2 步丢弃空值是防止算法在匹配时遇到None值直接崩溃第 3 步统一小写是为了让后续的字符串对比命中率更高第 4 步拆分equipment_list是最关键的一步因为推荐阶段需要判断「用户的设备集合是否包含该动作的全部器械」列表结构才能做集合运算。2.3 为什么清洗结果要单独存一份exercises_cleaned.csv存在的意义是让 Flask 应用启动时不用再重复执行清洗逻辑。这个项目的做法很务实一次清洗多次使用。应用运行时只需要pd.read_csv(exercises_cleaned.csv)加载速度更快而且不会因为原始数据里偶尔出现的脏数据导致推荐接口突然报错。我在实际复现的时候习惯多打印几行数据来确认清洗结果df pd.read_csv(exercises_cleaned.csv) print(df[[exercise_name, body_part, level, equipment_list]].head(10))输出里能直观看到equipment_list已经变成了列表结构这就是后面相似度计算的输入基础。需要说明的是如果后续你拿到新的健身数据只要字段结构一致完全可以套用这套清洗流程把新数据追加到清洗结果里不需要改推荐算法部分的代码。3. 内容过滤算法相似度计算在健身场景的落地3.1 为什么选内容过滤而不是协同过滤这个项目选内容过滤算法不是因为它最先进而是因为它最适合这个场景。协同过滤需要大量用户对物品的行为数据比如评分、点击、收藏通过「和你相似的人喜欢什么」来推荐。但居家健身推荐是一个典型的冷启动场景新用户没有任何历史行为系统只知道他填的表单信息。这时候协同过滤根本无法工作而内容过滤只需要两样东西——用户画像和物品特征就能算出推荐结果。内容过滤的核心思想一句话就能讲完计算用户需求与每个动作特征的匹配程度按匹配度从高到低排序取前 N 个。这个项目里的用户画像就是从表单里收集的健身目标、体能水平和可用设备物品特征则是上一章清洗出来的body_part、level和equipment_list。3.2 相似度计算的核心实现这个项目里的匹配度计算不是简单的等值判断而是把用户需求和动作特征各转成一个集合用 Jaccard 相似度系数来度量两个集合的重合程度。Jaccard 的定义是两个集合交集大小除以并集大小值越接近 1 表示越相似。但在健身推荐里不同特征的权重显然不一样器械匹配不上可以换动作替代但难度等级必须匹配否则推荐了也练不了。所以我在复现时做了一点加权处理把同类特征的 Jaccard 分值乘上权重再相加得到最终的综合匹配度def compute_match_score(user_profile, exercise, weights): user_profile: 用户画像字典 exercise: 动作特征字典 weights: 权重配置 # 难度等级完全匹配得满分否则为 0 level_score 1.0 if user_profile[level] exercise[level] else 0.0 # 目标肌群用户目标与涉及肌群的重合度 target_set set(user_profile[targets]) body_set set([exercise[body_part]]) intersection len(target_set body_set) union len(target_set | body_set) body_score intersection / union if union 0 else 0.0 # 设备匹配用户的设备集合必须覆盖动作所需器械 user_equip set(user_profile[equipment]) need_equip set(exercise[equipment_list]) equip_score 1.0 if need_equip.issubset(user_equip) else 0.0 # 加权求和 total_score ( weights[level] * level_score weights[body] * body_score weights[equipment] * equip_score ) return total_score这段代码里有几个参数值得细说。level_score的设定是最强约束因为给初学者推荐硬拉重量训练容易受伤难度不匹配会出安全问题所以直接给 0 分淘汰。body_score用了并集做分母意味着用户目标只有一个肌群时动作涉及多个肌群会被稀释分数因为这类动作不够聚焦。equip_score是硬门槛issubset判断逻辑表示用户至少要有动作所需的全部器械缺一个都算不匹配。权重参数一般这样调weights {level: 0.5, body: 0.3, equipment: 0.2}。难度权重最高目标肌群次之设备权重最低因为设备不足时用户完全可以用替代动作但难度和目标不对就是练错方向。3.3 推荐生成排序、过滤与兜底策略有了单动作的打分函数生成推荐列表就变成了一个批量计算再排序的过程。但这个项目里有一个很容易被忽略的设计推荐结果不能只靠分数排序还要做一次「可执行性过滤」和「多样性兜底」。def generate_recommendations(user_profile, exercises_df, top_n5): scored [] for _, row in exercises_df.iterrows(): ex { name: row[exercise_name], body_part: row[body_part], level: row[level], equipment_list: row[equipment_list], instructions: row[instructions] } score compute_match_score(user_profile, ex, weights) scored.append((score, ex)) # 按分数降序优先取难度匹配的 scored.sort(keylambda x: x[0], reverseTrue) filtered [item for item in scored if item[0] 0.5] # 兜底分数不足时放宽到难度不匹配但目标匹配的动作 if len(filtered) top_n: fallback [item for item in scored if item not in filtered and item[0] 0.2] filtered.extend(fallback[: top_n - len(filtered)]) return [item[1] for item in filtered[:top_n]]这里的关键点是filtered的阈值 0.5。设备不满足时equip_score为 0哪怕目标和难度全匹配总分也只有 0.80.5 0.3但如果目标肌群也错位总分就会掉到 0.5 以下被过滤掉。设计者的意图是宁缺毋滥前几个推荐必须是高置信度的剩余位置再给「难度不匹配但目标相关」的动作补充数量。推荐阈值这个参数值得多聊两句。0.5 这个值在数据量大时可能偏保守导致推荐列表不足。我自己的经验是top_n设为 5 时阈值 0.5 很稳如果你要一次推荐 10 个动作建议把阈值降到 0.4或者把兜底条件放宽到item[0] 0.1否则第二页推荐大概率是空的。4. Flask 应用与前端页面推荐结果如何到达用户4.1 页面结构与路由设计解压后的五个 HTML 文件其实暴露了这个应用的信息架构。welcome.html是入口页收集用户基本信息beginner.html和advanced.html按照难度等级分流分别对应初级和进阶用户recommendations.html是推荐结果页more_recommendations.html是「加载更多」的二级结果页。这个设计与核心算法里的难度硬约束是呼应的——先用难度把用户分流再在分流后的页面里收集更细的目标和设备信息。Flask 端的路由设计也围绕着这个页面流展开。下面是最核心的三个路由from flask import Flask, render_template, request app Flask(__name__) app.route(/) def welcome(): return render_template(welcome.html) app.route(/level/user_level) def level_page(user_level): if user_level beginner: return render_template(beginner.html, leveluser_level) else: return render_template(advanced.html, leveluser_level) app.route(/recommend, methods[POST]) def recommend(): # 从表单读取用户画像 user_profile { level: request.form.get(level, beginner), targets: request.form.getlist(targets), equipment: request.form.getlist(equipment) } df pd.read_csv(exercises_cleaned.csv) recommendations generate_recommendations(user_profile, df, top_n5) return render_template(recommendations.html, recommendationsrecommendations)这段代码里request.form.getlist是处理多选框的标准方式。前端页面的targets和equipment是复选框组用户可能同时勾选「胸肌」和「肱三头肌」多个目标也可能勾选多种器械只有getlist才能把同名的多个表单值全部取到。如果你用request.form.get只会拿到第一个值推荐结果会全面偏斜这是新手最容易踩的隐形 bug。recommendations.html里需要展示动作名称、难度、目标肌群、所需器械和动作说明这五个字段缺一不可。用户看到一个推荐动作时首先要判断「这个动作练的是不是我想练的部位」其次要确认「我家里的器械够不够」最后才是「这个动作怎么做」。4.2 模板渲染与数据传递模板里的数据传递是 Flask 和 Django 这类后端框架的核心差异点之一。Flask 的render_template会自动寻找templates目录下的 HTML 文件所以代码仓库里的 HTML 必须放在templates/文件夹里否则会报TemplateNotFound错误。模板内部用 Jinja2 语法遍历推荐列表more_recommendations.html的写法大同小异ul {% for item in recommendations %} li strong{{ item[name] }}/strong - {{ item[level] }} p{{ item[instructions] }}/p /li {% endfor %} /ul这个模板渲染的过程就是把算法算出来的 Python 字典列表变成用户能读的 HTML。需要注意recommendations里每个元素都是字典item[name]是取字典 key 的标准方式如果你在算法里存的是对象而不是字典模板这里就要改成item.name两边的数据结构必须严格对齐否则页面会静默渲染空白不报错但也没内容。4.3 请求链路串联起来看整个应用跑起来的请求链路是这样的用户访问/进入welcome.html→ 选择难度后跳转到/level/beginner或/level/advanced→ 填写目标和设备后 POST 到/recommend→ 后端读取 CSV 计算匹配度 → 返回recommendations.html→「更多推荐」按钮带同一份user_profile请求/more_recommendations→ 返回第二批结果。这条链路最值得学习的是「难度前置分流」的设计。用户第一步只选难度第二步才填目标和设备这样beginner.html和advanced.html在表单上就可以做差异化设计初级用户看到的是「小白友好」的器械选项进阶用户能看到哑铃、杠铃等更专业的设备选项。这种先粗筛再细筛的漏斗式交互比一上来就让用户填十个字段的体验好得多。5. 避坑指南运行这个项目时最常翻车的五个位置这个项目整体结构不复杂但我在复现和帮别人调试的过程中还是积累了不少血泪经验。下面这五条是出现频率最高的每一条都是「现象 → 原因 → 解决」的真实记录。坑位一Flask 启动后报 TemplateNotFound现象flask run后访问http://127.0.0.1:5000/浏览器直接显示jinja2.exceptions.TemplateNotFound: welcome.html。原因Flask 默认只在app.py同级目录下的templates/文件夹里找模板。如果你把解压出来的 HTML 文件直接放在项目根目录Flask 根本看不到它们。这个项目下载后是压缩包解压时如果把内部目录结构弄丢了就容易出现这个问题。解决确认目录结构是app.py和templates/文件夹在同一层级所有 HTML 文件必须放进templates/里。如果不方便移动文件也可以显式指定模板目录app Flask(__name__, template_folderhtml_pages)把html_pages换成你实际存放模板的目录名。但我的建议是保持默认结构因为后续你要给别人看代码时默认结构是最没有理解成本的。坑位二推荐结果永远只有一个固定动作现象无论怎么修改表单里的目标肌群推荐列表里总是同一个动作排在最前面其他动作几乎不动。原因body_score的计算用了并集作分母如果用户的targets列表只有一个值而动作的body_part也是单个值那么交并比只会出现 1.0 或 0.0大量动作的得分都集中在少数几个分数档位上排序不稳定。解决检查前端表单里targets复选框的name属性。需要所有复选框都用nametargets这样getlist才能取到完整列表。还有一个常见问题是用户只勾选了一个目标这会导致分数区分度不够。我一般会在前端提示「至少选择两个目标肌群」或者在算法里把body_score的分母改为只取用户目标集合的大小降低单目标场景下的分数稀释效应。坑位三more_recommendations.html 打开是 404现象在推荐结果页点「查看更多推荐」按钮页面跳转到 404。原因Flask 里每渲染一个页面都需要对应的路由。代码里只写了/recommend的路由但它只服务recommendations.html。如果模板里「更多」按钮直接写的a hrefmore_recommendations.html这种静态链接Flask 会去templates/里找同名的 HTML 文件并尝试渲染成纯静态页而 Flask 的默认配置并不直接暴露templates/下的文件。解决给more_recommendations单独写一个 POST 路由并把用户的user_profile通过表单隐藏字段带过去app.route(/more_recommendations, methods[POST]) def more_recommendations(): user_profile { level: request.form.get(level, beginner), targets: request.form.getlist(targets), equipment: request.form.getlist(equipment) } offset int(request.form.get(offset, 5)) df pd.read_csv(exercises_cleaned.csv) recommendations generate_recommendations(user_profile, df, top_noffset 5) return render_template(more_recommendations.html, recommendationsrecommendations[offset:])模板里的「更多」按钮要改成表单提交的形式把当前的用户画像用隐藏字段放进去。这样用户点「更多」时服务器能知道还是同一个人在请求而不是把它当成一个全新的、没有任何信息的请求。坑位四读 CSV 时出现中文乱码或 UnicodeDecodeError现象pd.read_csv(exercises_cleaned.csv)直接抛错或者查看数据时中文和特殊字符变成乱码。原因CSV 文件如果被 Excel 打开编辑过再保存编码可能被改成gbk或ansi而read_csv默认用utf-8解码。项目原始文件大概率是utf-8但在 Windows 上经过一次 Excel 保存就变了。解决统一用encodingutf-8读取如果报错就改成gbkimport pandas as pd for enc in [utf-8, gbk, latin1]: try: df pd.read_csv(exercises_cleaned.csv, encodingenc) break except UnicodeDecodeError: continue这段代码用遍历编码的方式自动判断能有效避免手动试错。我遇到这个问题时浪费了将近半小时后来养成了习惯每次拿到 CSV 第一件事就是确认编码格式别盲目相信后缀名。文本型数据集出现乱码九成是编码问题别的都不用查。坑位五表单提交后页面报 500 错误现象点击「生成推荐计划」按钮页面变成 500 Internal Server Error控制台显示KeyError: level或者类似信息。原因前端表单里的字段名和后端request.form.get(level)里的字符串对不上。比如前端写的是namedifficulty后端却用的level于是取不到值。解决严格对照前端 HTML 表单里的name属性和后端代码里的字符串建议在后端打印出来确认print(表单原始数据:, dict(request.form))这一行能救命的点在于它能直接列出浏览器提交的所有字段名和值不用你对着 HTML 猜。你会发现拼写错误、大小写不一致全部现出原形。我每次调试表单相关的问题第一件事永远是加这行打印比打断点快多了。6. 最后一步用三个方法验证推荐结果可不可信推荐系统跑起来不代表推荐得准这一步是很多人忽略的。我习惯从三个层面验证一个推荐项目是否真的可用。第一个方法是打印中间结果验证打分函数的合理性和权重参数是不是符合直觉。我一般会构造一个确定性的测试用例比如一个用户是初级、目标是胸肌、设备只有哑铃。手动看前三个推荐动作如果推荐的第一个动作是「哑铃卧推」而不是「蝴蝶机夹胸」说明设备约束生效了如果推荐结果里有「杠铃卧推」那说明issubset判断写错了。这种验证不需要任何测试框架一遍print就够了test_profile { level: beginner, targets: [chest], equipment: [dumbbell] } test_df pd.read_csv(exercises_cleaned.csv) result generate_recommendations(test_profile, test_df, top_n3) for r in result: print(r[name], r[equipment_list])第二个方法是检查推荐结果的多样性这是衡量推荐质量的一个务实标准。如果前五个推荐全是一个肌群的动作这个推荐就是失败的。好的居家健身计划应该是胸、背、腿、核心都有覆盖动态调整权重来观察结果变化。我一般会把weights[body]从 0.3 调到 0.5看推荐列表里的动作是否变得分散如果不分散说明数据里动作的body_part分布不均匀应该检查清洗后的数据里是不是有大量动作的body_part都是同一个值。第三个方法是从用户视角走一遍完整链路模拟真实使用场景。打开welcome.html→ 选 beginner → 勾选两个目标和哑铃 → 提交 → 看推荐结果页展示是否完整。这一步重点检查的不只是推荐结果对不对更是页面交互是否有断裂。我会特别注意more_recommendations是否带着同一份用户画像这是整个项目中最容易遗漏的环节。从当年第一次跑这个项目到现在我已经把这套验证流程固化成习惯了。测试用例先跑打印结果先看再走页面链路这三步做完心里基本有底。说实话做推荐系统最怕的不是算法效果差而是出了问题不知道是数据的问题、算法的问题还是前端传参的问题。从那以后我每次拿到一个新的推荐类项目都强制先走一遍「数据检查 → 打分打印 → 链路复测」的流程看起来慢实际上是在省后面排错的时间。希望这篇拆解能帮你在复现这个项目时少走几步弯路把精力留在真正值得研究的推荐逻辑上。本文还有配套的精品资源点击获取