01项目概览
LifeGame
把生活目标拆成任务，用游戏里的奖励回应每一步行动。
玩《文明 6》时，每一步都有目标和反馈；回到生活，学习、健身和调整作息的回报却很慢。我由此提出 LifeGame：用户说出目标，AI 生成冒险故事和任务清单；用户完成任务后，获得数值奖励、角色庆祝和回顾对话。
在线体验 ↗ 团队仓库 ↗02项目目标
更容易开始
有目标却迟迟不行动，可能是因为不知道从哪里开始，也可能是做了一些却看不到变化。LifeGame 将任务拆解与即时反馈放在一起：先给出具体做法，再让每次完成留下可见的进展。
把目标说具体
用户提供目标和背景，AI 生成有顺序、有做法、有预计耗时的任务。安排不合适时，可以通过对话调整。
让完成有反馈
任务完成后，技能数值更新、角色庆祝；整个目标完成后，AI 再根据这段经历展开回顾对话。
黑客松先完成“目标—任务—奖励—回顾”的主线。桌宠、社交和更完整的人生数值系统留在后续方案中。
03产品功能
使用过程
输入目标
这次示例的目标是“我希望养成早睡早起的生活习惯”。用户还可以补充自己的身份、地点和生活背景，让任务安排更贴近实际处境。
生成任务
AI 将这个目标写成“晨曦勇者”的冒险，并拆成六项行动：记录作息、设置专注模式、安排闹钟、建立晨间仪式、调整睡眠环境和连续记录一周作息。每项任务列出做法、预计耗时和奖励。
例如，“封印深夜魔盒”对应的做法是设置晚间手机专注模式，并把充电器移到离床两米外。游戏化标题下面，仍然是一件能照着做的事。
调整计划
任务生成后，用户可以打开“与 AI 对话”，讨论需要增删或修改的内容，再确认应用更新，返回调整后的清单。
奖励结算
勾选“封印深夜魔盒”后，任务变为已完成，页面显示“意志壁垒 +7”“环境掌控 +5”，右侧数值同步更新，像素角色开始庆祝。
完成状态由用户自行勾选，分数用于游戏反馈，不代表系统测量了现实能力。
回顾对话
全部任务完成后，系统发放一张“话疗券”，打开围绕这个目标的回顾对话。AI 读取已完成任务和累计数值，具体回顾用户做过的事情，再邀请用户分享感受。
这次回复提到了记录作息、设置专注模式和七日打卡，最后问：“完成这个目标后，你心里最真实的感受是什么？”用户可以在下方继续输入。
04实现逻辑
技术实现
AI 负责生成故事、拆解任务和展开对话；程序负责保存数据、判断完成状态和累计奖励。两部分通过固定格式的任务数据连接。
技术分工
| 部分 | 使用的技术 | 在项目中的作用 |
|---|---|---|
| 页面交互 | React 18 · TypeScript Tailwind CSS · Zustand | 展示故事与任务，管理当前目标、角色状态和奖励动画。 |
| 后端接口 | FastAPI | 接收目标与完成请求，调用模型、保存任务并返回奖励。 |
| 模型调用 | LangChain · Pydantic | 组织目标与对话上下文，将模型返回内容解析成故事、任务和奖励等字段。 |
| 数据保存 | SQLAlchemy PostgreSQL 本地配置 | 保存用户、目标、任务、技能数值、话疗券与对话记录。 |
| 开发运行 | Vite · Docker Compose | Vite 启动前端并转发接口请求，Docker Compose 启动本地数据库。 |
代码结构
frontend/src/components/页面组件- 分别展示目标输入、故事、任务、角色、奖励动画和对话面板。
frontend/src/store/页面状态- 用 Zustand 保存当前目标、技能数值和动画状态；App.tsx 接收接口结果后更新页面。
frontend/src/api/接口请求- 统一发送创建目标、完成任务、更新计划和回顾对话等请求。
backend/agent.py模型与规则- 组织提示词、解析任务结构、生成对话；奖励累计采用单独的计算函数。
backend/main.py业务接口- 串起用户、模型和数据库，处理目标创建、完成结算、任务修改与话疗券。
backend/models.py数据关系- 定义用户与目标、目标与任务、话疗券与对话记录之间的关联。
生成与结算
前端把目标和背景发送到 /api/goals。后端将它们放入提示词，要求模型返回故事、任务清单、初始数值和鼓励语。每项任务包含标题、说明、预计耗时和技能奖励；解析通过后，后端写入数据库，页面按这些字段展示。
检查是否已结算 → 累加预设奖励
保存完成状态 → 返回数值与动画状态
创建话疗券 → 读取目标与任务记录
带着上下文调用模型 → 保存回顾对话
奖励在生成计划时确定，勾选完成时由程序累计，不需要再次询问模型。修改计划则重新调用模型：带上当前任务与对话记录生成新清单，后端保留已完成记录，替换未完成部分。
模型通过 OpenAI 兼容接口调用，可接 OpenRouter。AI_MODEL 指定型号，代码默认值为 gpt-4。
保存与恢复
数据库保存目标、任务及其完成状态，技能数值归属于用户，回顾对话通过话疗券关联到具体目标。这样，AI 回顾时能找到对应任务，而不必让用户重新讲一遍经历。
浏览器本地只保存用户编号，下次打开时据此取回用户和技能数值。页面另记住当前正在查看的目标，用来更新任务清单和奖励动画。具体任务记录保存在后端，页面显示的状态与长期保存的数据分开管理。
运行与部署
本地先启动 PostgreSQL，再启动 FastAPI 后端和 Vite 前端。浏览器统一请求 /api，开发时由 Vite 转发到后端。页面、业务接口和数据库各自运行，通过接口连接。
前端用 tsc && vite build 检查类型并生成静态文件；后端通过环境变量配置模型与数据库。作品保留了 Zeabur 体验入口。以上是本地工程的实现，线上实际模型、数据库配置及自动发布机制尚未核实。
05我的工作
产品构想与取舍
产品构想和项目文档由我提出、撰写，网页与代码由团队协作完成。我主要处理的是：一个模糊的成长愿望，怎样变成用户能开始、能完成、完成后还有反馈的使用过程。
- 定义问题从游戏中的即时反馈与生活中的缓慢回报出发，明确任务拆解和完成反馈两项核心需求。
- 梳理场景围绕下班后不想学习、遇到挫折、习惯中断等场景，判断用户需要的是行动建议、任务调整还是情绪支持。
- 连接体验将任务、奖励、结算和回顾连接起来，安排用户输入目标后、完成任务后各自会收到什么回应。
- 控制范围黑客松先完成一条可演示的流程，桌宠、浮窗和社交等想法保留在后续方案中。
最初的构想涵盖更完整的人生数值系统和多种载体。黑客松时间有限，我把演示范围收在“表达目标—拆任务—完成反馈—回顾”上，先呈现一次具体目标如何被承接，再讨论更多功能。
06完成情况
当前原型
已有展示
- 早睡早起案例的输入、任务生成和奖励结算。
- 完成目标后的话疗券回顾对话。
- 产品方案与团队前后端代码。
仍需验证
- 对话修改任务已有代码，尚未补充页面实测。
- 重新打开页面时尚未自动恢复上次任务清单，需要补齐继续任务的体验。
- 长期使用中，任务安排是否合适、用户是否愿意持续行动。
已有结果来自黑客松原型演示，暂未积累连续使用或习惯改善的数据。