在前几篇文章里，我们一步一步，让这个应用变得越来越像一个产品。我们增加了用户档案、训练计划、训练记录趋势分析、风险提醒和分享功能，到这里，你的应用已经具备了一个非常完整的结构。

但如果你认真观察，会发现一个非常明显的问题——所有数据，都是用户自己输入的。也就是说：这个应用虽然功能很多，但它仍然是一个封闭系统。而真正的产品，往往有一个非常重要的特征：它连接现实世界。

所以今天，我们要做两件非常关键的事情：第一，接入真实世界的数据（比赛信息）；第二，让数据可以长期保存（数据库）。

这两个能力，会让你的应用发生一次质变。

一个非常真实的需求——我想知道接下来有哪些比赛

多如果你跑步时间比较久，或者准备参加比赛，很快就会遇到一个问题：下一场比赛是什么时候？

你可能会去这些网站查看：

CODE
中国马拉松官网
ITRA（国际越野跑协会）

但问题是，这些信息是分散的，需要手动查询，也无法和你的训练计划关联。

所以今天，我们要为这个应用增加一个非常真实的功能：比赛日历（Race Calendar）。

因此，我们的目标非常明确，我们要让应用可以：

CODE
自动获取：
      中国马拉松官网的比赛数据
      ITRA 官网的比赛数据
并在应用中展示：
      比赛名称
      比赛日期
      比赛地点
      比赛距离
同时：
      把这些数据保存到数据库中

这一步非常关键，因为从这一刻开始，你的应用，开始拥有“自己的数据”。

为什么必须使用数据库？

在前几篇文章里，我们其实已经在使用数据了。例如：

CODE
用户档案
训练记录
训练计划

但如果你刷新页面或者换一台电脑，很可能会发现，数据消失了。这是因为它们只是暂时存在于内存里。这就像你在纸上写了一些内容，但没有保存。 

而数据库，本质上只是做一件事情：让数据可以一直存在。应用数据必须存储在某个地方，才能保证持续访问。这其实就是 persistent storage（持久化存储）。

所以今天，我们要正式让这个应用进入一个新的阶段：数据库阶段。

我们先设计一个非常简单的 PRD

这是一个非常重要的习惯，不要直接写 Prompt ，先想清楚你需要存什么。

新增模块：比赛日历 

数据来源：中国马拉松官网、ITRA 官网 

数据字段：比赛名称、比赛日期、比赛地点、比赛距离

赛事类型：马拉松、半程马拉松、越野跑 

系统功能：自动获取比赛数据、保存到数据库、在页面中展示比赛日历

用户可以：浏览比赛、搜索比赛

这一步，其实就是数据设计（Data Design）。

现在，写第一个 Prompt

下面这段 Prompt 可以直接使用。

CODE
请为我的应用增加一个比赛日历功能。
需要从以下网站获取比赛数据：
    中国马拉松官网：https://www.runchina.org.cn/#/race/v/list
    ITRA 官网：https://itra.run/Races/RaceCalendar
请实现以下功能：
    1）从这些网站抓取中国国内的比赛信息，包括：
         比赛名称
         比赛日期
         比赛地点
         比赛距离
         赛事类型
   2）将这些数据整理成结构化格式，例如 JSON 数据
   3）在应用中创建一个页面：比赛日历。
展示所有比赛信息

你会看到Agent 会开始读取网页、解析 HTML 、提取数据和生成结构化数据。

这其实就是数据抓取（Data Scraping）。

下一步：把数据保存到数据库

这是今天最关键的一步。因为如果你不保存数据，那么每次重启应用，数据都会消失。我们现在要做的是，把比赛数据，从临时数据变成长期数据。

下面是一个可以直接使用的 Prompt：

CODE
请为我的应用增加数据库支持。
需要实现以下功能：创建一个数据库，用于存储比赛数据。
数据库表需要包含：
    race_id
    race_name
    race_date
    race_location
    race_distance
    race_type
系统需要当应用启动时，自动获取比赛数据，并保存到数据库中。
如果数据已经存在，不要重复保存。

这一步非常重要，因为从这一刻开始，你的应用开始拥有：数据结构。

现在，增加用户注册和登录功能

当应用开始拥有数据时，很快就会遇到一个新的问题：谁在使用这些数据？

这时候，就需要用户系统。我们要增加注册、登录和用户身份功能。这一步，会让你的应用从单人工具变成多用户系统。下面是推荐 Prompt：

CODE
请为我的应用增加用户注册和登录功能。
需要实现：
用户注册——输入：邮箱、密码。
用户登录——输入：邮箱、密码。
系统需要将用户信息保存到数据库中，并在用户登录后显示用户的个人数据。

这一步之后，你的应用就正式进入用户系统阶段。

如果说前几篇文章，我们一直在做的是功能设计，那从这一篇开始，我们进入的是数据设计。这两者的区别非常大，功能可以随时改，数据一旦存在，就会影响系统的未来。

在产品世界里，功能可以不断修改，界面可以随时重做，但数据一旦产生，就会成为这个系统的一部分历史。

而历史一旦存在，就意味着责任——对用户的责任，对数据的责任，对长期稳定运行的责任。

所以一个更重要的认知是，当你的应用开始保存数据的那一刻，它就不再只是你的实验，而是一个需要被认真对待的产品。