想开发健身 App?1,324 个动作、6 种语言的开源数据集已就绪

健身数据集 · 运动分类 · 多语言说明 · LLM 后端生成

hasaneyldrm/exercises-dataset 收录了 1,324 个健身动作， 每条记录包含分类、目标肌群、所需装备、六国语言的分步说明， 以及可追溯的媒体引用 ID。项目同时附带一套纯前端的开发者向导工具， 从建表 SQL、API 代码到 LLM Prompt， 几分钟内就能为健身 App 准备好后端骨架。

开发健身 App，数据从哪里来？

任何需要记录训练动作的 App 都绕不开一个问题： 动作数据谁提供？

自己标注一千多个动作的名称、分类、肌群、装备、步骤说明， 工作量巨大。从网络上爬取又涉及版权与数据质量问题—— 动作命名不统一、缺少标准字段、说明文本质量参差不齐。 更麻烦的是多语言支持：如果你的 App 面向国际市场， 每个动作的说明都需要逐语言翻译，这是一笔不小的成本。

另一个常被忽略的坑是后端接口。 有了数据还要写 CRUD API、设计数据库表结构、 考虑多语言字段该怎么存。不少团队在原型阶段花了大把时间搭后端， 最后发现数据本身才是价值核心，CRUD 只是标配。

exercises-dataset 试图一次性解决这些问题： 把结构化数据、多语言翻译、建表脚本、API 示例代码、 甚至 LLM 后端生成 Prompt 全部打包。 开发者只需关注业务逻辑，不用在数据基础设施上重复造轮子。

三分钟上手：从加载到后端启动

这个项目的使用路径非常直白，按需走三个阶段即可。

阶段一：获取与探索数据

data/exercises.json 是一个标准的 JSON 数组， 任意编程语言都能直接加载。以 Python 为例：

import json
with open("data/exercises.json", "r", encoding="utf-8") as f:
    exercises = json.load(f)

chest = [ex for ex in exercises if ex["category"] == "chest"]
print(f"胸部动作: {len(chest)}")  # -> 163

# 按装备过滤 - 无器械动作
bodyweight = [ex for ex in exercises if ex["equipment"] == "body weight"]
print(f"自重动作: {len(bodyweight)}")  # -> 325

数据按「部位」分 10 大类： 上臂 292 个、大腿 227 个、背部 203 个居前三； 最小的是颈部，仅 2 个动作。 按装备看，自重（325）、哑铃（294）、龙门架（157）、 杠铃（154）排在前四——覆盖了绝大多数健身房场景。

如果你不想写代码，直接打开项目中的 index.html。 这是一个纯浏览器端的交互式运动浏览器，支持全文搜索， 可按类别、装备、目标肌群过滤。 点击任意卡片即可查看 6 种语言的完整说明。

阶段二：生成数据库 Schema

打开 setup.html，第一个功能是数据库建表工具。 支持 4 种引擎：PostgreSQL、MySQL、SQL Server、SQLite。

界面提供 Tab 切换，选择目标数据库后自动生成对应的 CREATE TABLE 语句。多语言的 instructions 字段按语言拆分为独立列 （instructions_en、instructions_zh 等）， secondary_muscles 以 JSON 字符串存储。 确认后可直接下载 .sql 文件导入数据库。

阶段三：获取 API 代码 + 让 LLM 代写后端

setup.html 的第二个功能是 API 集成代码生成。 填入 API 基础 URL，页面自动生成 7 种语言的客户端调用示例： JavaScript (Fetch)、Python (requests)、C# (HttpClient)、 Java (OkHttp)、PHP (cURL)、Go (net/http)、cURL。

第三个功能是最亮眼的部分——LLM Prompt 生成器。 选择框架（Express.js / FastAPI / ASP.NET Core / Spring Boot / Laravel / Gin）和数据库， 页面会自动组装一段完整的 Prompt，包含：

这段 Prompt 可以直接粘贴进 ChatGPT、Claude 或 Gemini， 得到一个可以跑起来的后端项目。 从数据集到可运行的 API，整个过程不需要写一行后端代码 ——连 Prompt 都是自动生成的。

结构化数据 + 向导，创新在哪

这个项目不是第一个健身数据集，但它在「数据交付」这件事上 做了几个值得关注的设计选择。

数据可组合，字段拆得细

每条记录包含 id、name、category、body_part、 equipment、target、muscle_group、secondary_muscles （数组）等字段。细粒度拆分的直接好处是： 你可以围绕任意字段做过滤与推荐逻辑。 想找「用哑铃练肱二头肌」的动作？ 三重条件过滤即可，不需要自然语言解析。

多语言说明的工程价值

6 种语言（英、西、意、土、俄、中）的说明文本全部内嵌在 同一条 JSON 中，嵌套在 instructions 对象下。 前端接数据时无需关联翻译表，一次加载就能展示全部语言。 代价是每条记录体积略大，但对 1,324 条数据来说完全可以接受。

Setup Wizard 的 LLM Prompt 生成是最大创新

与大多数数据集不同，这个项目没有止步于「数据给你了， 剩下的自己来」。它提供了一个结构化的生成式编程入口： 将数据 Schema、业务逻辑需求、框架选型组合成一段 上下文完整的 Prompt，让 LLM 生成可直接部署的代码。

这种做法的好处：

这个模式的代价也很清楚：生成的代码质量取决于底层 LLM 的能力， 且没有自动化测试覆盖。但对于原型阶段或内部工具来说， 这已经足够用了。

可以直接落地的两个场景

场景一：个人训练记录 App

如果你想做一个类似 Strong 或 Hevy 的健身记录工具， 可以直接将整个 JSON 导入本地数据库。 1,324 个动作覆盖了绝大多数健身房练习。 按类别做动作选择器、按装备做过滤、展示多语言说明 ——这三个功能再加上运动组数和重量的记录逻辑， 一个 MVP 的核心模块就成型了。 对于个人开发者或小团队，这意味着几天内就能跑通原型。

场景二：AI 运动推荐引擎

利用数据集中清晰的分类体系 （category × equipment × target × muscle_group）， 你可以构建推荐逻辑。 例如用户说「今天练胸，有杠铃」， 系统推荐对应的胸部杠铃动作，并按目标肌群的协同关系排序。 更进一步，结合用户的训练历史做个性化推荐 ——这本质上是推荐系统在健身领域的典型应用， 而这个数据集恰好提供了足够多的标签维度来支撑这件事。

展望：数据集即 API

更长远来看，这个项目代表了一种有意思的交付趋势： 数据集 + 代码生成器的组合。 未来类似的项目可能直接内置 LLM 调用来生成不仅包含 CRUD 代码、还包括业务逻辑 （如训练计划编排、渐进超负荷计算）的完整后端应用。 数据集不再只是文件，而是一个可交互的开发者入口： 开发者进来后，挑引擎、选框架、一键生成—— 然后就可以开始写真正的业务了。