01 / 身体与记录
Fitness OS
训练、饮食和身体状态，
怎么放在一起回看？
- 现场问题
- 记录散在不同地方，回头判断当天状态时还要重新拼起来。
- 我的取舍
- 输入后先确认；缺失就显示缺失；行动之后保留反馈入口。
- 可查看的交付
- 原生 iPhone 版界面、网页版、工作流演示和规则样板。
- 边界
- 原生版接入 Apple Health，网页版范围不同。这里是个人使用，不是外部用户规模。
原生版接入 Apple Health；网页版功能范围不同。产品经理 / 2027 届
把现场的问题，
做成能用的产品。
我是 KOREY WANG TIANRU，产品经理。做过健身教练主管和剧本杀 DM，也为自己的备考和秋招做工具。我的产品实践，从这些具体的使用场景开始。
我负责问题定义、流程设计、实际使用与验收。
AI 协助编码实现。
30+
名会员累计服务教练主管，2024.10—2026.09
53→69
专四两次正式成绩本人，使用自制工作台期间
132页
演员手册被门店转给其他 DM备场长版；另有 34 页上场本
约7000
条校招信息拆解后重做判断我从对外分享链接的表格导出后统计
先看方向、背景和做过的事。
02 / 深入一个项目Fitness OS 案例 ↗看问题、取舍，以及可以体验的产品。
03 / 直接体验打开产品示例 ↗使用虚构数据，浏览网页版的完整界面。
SELECTED WORK / 01—04
从我遇到的问题，
开始设计。
每个项目用同一组问题：
现场问题、我的取舍、现在能看什么、哪句话还不能说。
原生版接入 Apple Health；网页版功能范围不同。
03 / 内容与现场
DM 角色手册
- 现场问题
- 长文档适合备场，上场时只来得及查当前这一幕。
- 我的取舍
- 长手册用来备场，短提示按幕次上场；控制台只用模拟剧本。
- 可查看的交付
- 132 页演员手册和 34 页上场本已在门店流转；公开页只保留演示和边界。
- 边界
- 没有准备时间或现场失误率。212 页是另一版本，还没有店内定版。
- 约77%
- 截止时间写“尽快投递”
- 约14%
- 已过截止日，仍在主表
- 16个
- 视图，其中有重名
04 / 求职与判断
求职控制台
- 现场问题
- 校招信息很多，但一个岗位我能不能投，还得自己读公告判断。
- 我的取舍
- 只问毕业时间、学历和专业，由系统判断能否投并列出依据；截止日不明就写“未知”，不用占位文字。
- 可查看的交付
- 案例页。核心逻辑、测试和 12 页可点击演示已完成，与 AI 工具协作实现；演示的公开地址还未上线。
- 边界
- 可点击演示（虚构数据），尚无真实用户与线上岗位数据。
OPEN SOURCE
做求职工具时，
先把自己的简历管住。
仓库都可以直接看源码。
下面写的是它解决什么问题，不是 Star 数。
HOW I WORK
我在项目里，
承担哪些判断。
工具会变，具体问题和验收标准
需要有人一直负责。
- 01
先还原使用现场
是在训练后记录、备考时复习、上场前查阅，还是投递前判断？先弄清谁在什么时刻需要它。
- 02
把取舍放进流程
哪些信息必须确认、哪些缺口不能猜、哪一步应该先做，都落实到界面与规则。
- 03
让 AI 协助实现
拆清需求与交付范围，借助 Agent 编码，再回到具体流程检查结果。
- 04
用过，再决定怎么改
界面能打开只是开始。记录是否正确、资料能否找到、结果有没有用，需要实际操作。
LET’S TALK
如果你正在找一位
愿意深入现场的产品经理。
可以从一个具体项目聊起：问题怎么发现，为什么这样设计，还有哪些地方需要继续验证。
邮箱 korey2028@gmail.com · GitHub korey2028-prog