如果你正在找一个既能练 MySQL又能把 AI 大模型真正用起来的实战项目我强烈建议你试试双色球历史数据分析。数据公开、结构规整、规模不大不小刚好能把数据库建表、SQL 统计、Python 特征工程、大模型报告生成这一条链路完整走一遍。这篇文章不是教你算号中奖而是记录一次我用 MySQL 数据库技术 AI 大模型做双色球数据分析的完整实战过程包括表结构设计、统计口径、代码实现以及我踩过的几个坑。先说明一句双色球开奖是独立随机事件历史数据不能推导出下一期号码。我做的所有统计与分析目的都是练数据技术、研究数据规律而不是寻找中奖密码。看懂这个边界你才能用健康的心态把项目做下去。1. 为什么我会选双色球这类数据当实战对象1.1 一个脏乱差程度刚刚好的数据源很多人在练数据分析时纠结数据从哪来。电商数据要爬虫金融数据要申请权限传感器数据要自己搭环境。双色球数据最大的优势是公开、免费、历史长而且结构出奇地规整。每期开奖就是 6 个红球加 1 个蓝球。红球从 01 到 33 选 6 个蓝球从 01 到 16 选 1 个附带期号、开奖日期、销售额、奖池金额这些属性。这种数据结构特别适合做数据库设计练习因为它的字段类型很典型日期、编号、数值、金额、枚举值恨不得把所有数据类型都用上。数据量也刚好。双色球每周开奖 3 次一年约 156 期。从上市到现在累计也就三千多期算上所有字段撑死几万行。这个规模放在 MySQL 里既不会因为数据量太小而感受不到索引和查询优化的意义也不会因为数据量太大而需要分布式那一套。说白了它是一个你能完全掌控、随意折腾的数据集。更关键的是这个数据的脏乱差程度刚刚好。它不是那种清洗得干干净净的 Demo 数据。你会发现不同来源的数据批次对不上、期号格式不统一、偶尔缺一期、销售额字段有 null这些都是在真实工作中天天遇到的事。用它练手你学到的不是那种书上一切顺利的假经验。1.2 分析目标怎么定先拆掉预测中奖这个伪需求我见过不少人做这类项目一上来就问能不能用 AI 大模型预测下期号码。我直接说不能而且永远不能。因为双色球开奖机制决定了每一次开奖都是独立随机事件上一期的结果对下一期没有任何影响。统计学的常识摆在那里在独立随机事件面前历史数据的价值是描述不是预测。把预测中奖这个伪需求拆掉之后分析目标反而清晰了我做的是这样三件事建一套干净、扩展性好的 MySQL 表结构把历史开奖数据管理起来用 SQL 和 Python 做特征统计算出号码频率、遗漏值、连号、和值这些指标锻炼真正的数据加工能力接一个大模型 API让它根据统计结果生成文字解读体验一条从数据库到报告的自动化链路。这个目标定下来之后整个项目就不会跑偏。你不会纠结这个模型准不准而是会关注数据链路通不通统计口径对不对大模型用得好不好这些才是真正能迁移到工作里的能力。2. 建表之前先想清楚双色球数据在 MySQL 里怎么存才不后悔2.1 一个红球顺序问题直接把表结构分成两种流派我一开始以为建表很简单不就是在 MySQL 里建一张表、塞几个字段嘛。真正动手才发现第一个问题就值得琢磨红球号码要不要按展示顺序存官方公布的双色球结果是红球升序排列的比如03、07、14、18、23、28。但开奖现场摇出来的顺序不一定是升序只是公布时帮你排好了。如果你只存升序后的结果以后想分析开奖顺序就完全没有可能如果你存原始摇奖顺序又跟大部分公开数据源对不上。我的处理方式是宽表里存升序后的红球保证和公开数据一致另外建一张明细表把每个号码拆成一行并且预留一个 position 字段将来如果找到带摇奖顺序的数据源可以直接补上不用动原有表结构。这种宽表 明细表双写的方式在真实的数据仓库项目里很常见宽表给 BI 报表用明细表给深度统计分析用。2.2 字段类型、编码与主键设计宽表结构我最终是这样设计的CREATE TABLE ssq_history ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 自增主键, issue_no CHAR(7) NOT NULL COMMENT 期号例如 2024001, open_date DATE NOT NULL COMMENT 开奖日期, red_1 TINYINT UNSIGNED NOT NULL COMMENT 第1个红球升序, red_2 TINYINT UNSIGNED NOT NULL, red_3 TINYINT UNSIGNED NOT NULL, red_4 TINYINT UNSIGNED NOT NULL, red_5 TINYINT UNSIGNED NOT NULL, red_6 TINYINT UNSIGNED NOT NULL, blue TINYINT UNSIGNED NOT NULL COMMENT 蓝球, total_sales DECIMAL(12,2) DEFAULT NULL COMMENT 本期销售额元, pool_money DECIMAL(12,2) DEFAULT NULL COMMENT 奖池滚存元, first_prize_count INT UNSIGNED DEFAULT NULL COMMENT 一等奖注数, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_issue (issue_no), KEY idx_open_date (open_date), KEY idx_blue (blue) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT双色球历史开奖数据宽表;这里有几个设计决策我想多说两句。期号我用 CHAR(7) 而不是 INT。因为期号是2024001这种格式前面的 2024 是年份后面三位是当年期数。用 INT 存储虽然也能显示但如果你哪天真按字典序排序就会得到2024001, 20240010, 2024002这种诡异结果。更重要的是期号本质上是一个业务编号不是用来做算术运算的数字用 CHAR 更合适。红球和蓝球我用 TINYINT UNSIGNED理由很简单红球范围 1 到 33蓝球范围 1 到 160 到 255 的无符号小整数完全覆盖而且只占 1 个字节。相比 INT一行数据能省好几个字节虽然十几万行也省不了多少但从设计习惯上说字段类型贴合数据范围才是对的。金额字段用 DECIMAL(12,2)坚决不用 FLOAT。任何涉及钱的数据用浮点数都是给自己埋雷会出现 0.30000000000000004 这种精度问题。DECIMAL 是精确小数适合存储销售额和奖池金额。2.3 索引不是炫技小表也有设计价值你可能觉得几千行数据随便全表扫描也就几毫秒加索引有什么意义我的想法不太一样在这个项目里加索引练的是建索引的思维方式。以后跳槽到真正的大厂面对的是几亿行的订单表那时候你不会再有先跑一遍看看的余裕。我建了三个索引uk_issue唯一索引保证同一期号不会重复录入同时提供按期号精确查询的快速路径idx_open_date所有最近 N 期按时间范围统计的查询都会走日期范围没有这个索引日期过滤就是全表扫描idx_blue单独给蓝球加索引是因为蓝球分析是双色球统计里的高频操作而且蓝球字段在 WHERE 里经常单列。实际上我后面写统计 SQL 时uk_issue还真帮我挡住过一次重复导入。当时数据更新脚本因为网络原因重复执行如果没有唯一索引表里就会出现一模一样的期号所有统计结果直接翻倍。明细表的设计也一并给出来CREATE TABLE ssq_ball_detail ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, issue_no CHAR(7) NOT NULL COMMENT 期号, open_date DATE NOT NULL COMMENT 开奖日期, ball_type TINYINT NOT NULL COMMENT 1红球 2蓝球, ball_no TINYINT UNSIGNED NOT NULL COMMENT 号码 1-33 或 1-16, position TINYINT UNSIGNED DEFAULT NULL COMMENT 开奖顺序位置未知则为空, PRIMARY KEY (id), KEY idx_issue (issue_no), KEY idx_ball_type_no (ball_type, ball_no), KEY idx_open_date (open_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT双色球号码明细表;ball_type 我用 TINYINT 而不是 ENUM。ENUM 看着直观但后期想加一种号码类型比如大乐透的前区后区就得改表结构TINYINT 加个枚举映射就行。这算是吃过大乐透扩展的亏之后学到的经验。3. SQL 取数与特征工程从查数据到能建模3.1 号码频率、冷热号用 SQL 还是视图表建好之后第一个要做的统计就是号码频率。比如每个红球在历史上一共出现多少次最近 30 期哪些号码出现次数多在宽表里红球分散在 red_1 到 red_6 六列不能直接 GROUP BY所以我会用明细表来算SELECT ball_no AS number, COUNT(*) AS freq FROM ssq_ball_detail WHERE ball_type 1 GROUP BY ball_no ORDER BY freq DESC;这个查询很基础但信息量不小。它能告诉你哪些号码在历史上出现频率偏高、哪些偏低。注意这里的冷热只描述历史事实不构成对未来的判断。如果要做最近 30 期热号SQL 就要加一个子查询SELECT ball_no, COUNT(*) AS freq_30 FROM ssq_ball_detail WHERE ball_type 1 AND issue_no IN ( SELECT DISTINCT issue_no FROM ssq_history ORDER BY open_date DESC LIMIT 30 ) GROUP BY ball_no ORDER BY freq_30 DESC;这段 SQL 在 MySQL 5.7 上没问题因为用了子查询而不是窗口函数。如果你用的是 MySQL 8.0可以用 ROW_NUMBER() 或 LAG() 写更复杂的分析但在 5.7 上就要绕一下。我在公司里见过不少同事因为这个差异把线上 SQL 写崩所以特意记一笔。这类高频统计我还建议在 MySQL 里建视图固化下来CREATE VIEW v_red_freq AS SELECT ball_no, COUNT(*) AS freq FROM ssq_ball_detail WHERE ball_type 1 GROUP BY ball_no;视图的好处是查询语义清晰你不用每次写一大段 GROUP BY。但它不是万灵药如果底层数据量上来了视图会掩盖性能问题。在这个项目里用没问题别把它当成大规模数据的通用解法。3.2 遗漏值、连号、和值、跨度哪些用 SQL 哪些用 Python号码频率只是开胃菜。真正有挑战的是遗漏值。遗漏值的定义是某个号码距离上一次出现中间隔了多少期。比如蓝球 08 上一次出现在第 2024050 期现在是第 2024058 期那么它的遗漏值就是 8。这个指标用纯 SQL 写非常绕因为你要对每个号码找出最近一次出现和当前期号的差值。MySQL 8.0 可以用窗口函数 LAG() 实现但 5.7 没有而且逻辑稍有不慎就算错。我的实际做法是把宽表读进 Python用 pandas 算指标再把结果写回 MySQL 的中间表。这样既省心又能把复杂的业务逻辑放在容易调试的 Python 侧。连号、和值、跨度这些指标在宽表里算反而更直接。和值就是 red_1 到 red_6 相加跨度就是最大红球减最小红球奇偶比就是统计这组红球里奇数和偶数的个数。这些在 SQL 里用最简单的加减法就能完成SELECT issue_no, open_date, red_1 red_2 red_3 red_4 red_5 red_6 AS red_sum, GREATEST(red_1, red_2, red_3, red_4, red_5, red_6) - LEAST(red_1, red_2, red_3, red_4, red_5, red_6) AS red_span, (red_1 % 2 red_2 % 2 red_3 % 2 red_4 % 2 red_5 % 2 red_6 % 2) AS odd_count FROM ssq_history;连号怎么算连号指同一期出现了相邻号码比如 05、06。这个在宽表里判断也不难只要看 red_2 - red_1 是否等于 1、red_3 - red_2 是否等于 1……依次判断。但如果有 3 连号、4 连号逻辑就开始长了。我建议这类特征统一放 Python 侧算用循环或者 numpy 数组一次搞定。3.3 pandas 特征加工把宽表变成模型能用的结构化特征我用 pandas 做特征加工时的核心逻辑就一段从 MySQL 全量读出数据按开奖日期排序然后逐期构造特征向量。import pymysql import pandas as pd conn pymysql.connect( host127.0.0.1, userroot, passwordyour_password, databaselottery, charsetutf8mb4, ) df pd.read_sql( SELECT issue_no, open_date, red_1, red_2, red_3, red_4, red_5, red_6, blue FROM ssq_history ORDER BY open_date, conn, )读出之后我定义了一个特征构建函数def build_features(row): reds [row[red_1], row[red_2], row[red_3], row[red_4], row[red_5], row[red_6]] return { red_sum: sum(reds), red_span: max(reds) - min(reds), odd_count: sum(1 for r in reds if r % 2 1), even_count: 6 - sum(1 for r in reds if r % 2 1), small_count: sum(1 for r in reds if r 16), big_count: 6 - sum(1 for r in reds if r 16), blue: row[blue], } features [] for _, row in df.iterrows(): features.append(build_features(row)) feat_df pd.DataFrame(features) feat_df[issue_no] df[issue_no].values feat_df[open_date] df[open_date].values这段代码的逻辑简单到有点像玩具但它是后续所有分析的基础。特征都变成了数值型可以算相关系数、做聚类、画分布图也可以喂给机器学习模型做分类练习虽然我不建议真拿它去预测彩票但技术上练手完全没问题。为什么要分 SQL 和 Python 两侧我的判断标准很简单凡是需要按行内多列做组合判断的放 Python凡是需要按列做分组聚合的放 SQL。SQL 的优势在 GROUP BYpandas 的优势在灵活的行级变换各用所长。4. AI 大模型在这个项目里到底能干什么4.1 先把大模型的预测功能这个误区拆掉这个话题我必须多说几句。现在只要搜AI 彩票满屏都是大模型预测下期号码AI 智能选号但懂技术的一看就知道是怎么回事多数是拿随机数生成器包了一层壳有的甚至直接用 LLM 随机输出几个数字然后声称AI 预测。大模型本质上是语言模型它做的事情是根据上下文生成最合理的下一个词。它能预测明天会下雨的概率吗不能它只能根据你给的资料生成一句可能下雨的文字。放到双色球场景里大模型根本不可能知道下一期开什么因为开奖结果是物理世界里的独立随机事件没有任何文本模式可以推断。那大模型在这个项目里是不是就没用了恰恰相反它有三个非常实际的价值。4.2 大模型真正擅长的三件事Text-to-SQL、报告生成、特征解释第一个价值是 Natural Language to SQL。你可以用大白话问它最近 20 期蓝球出现次数最多的三个号码是啥它给你生成一条 SQL。对于不熟悉 SQL 的初级分析员这一步能省不少时间。但注意生成出来的 SQL 一定要拿去 MySQL 里跑一遍验证不能直接信。第二个价值是数据分析报告生成。统计数据算出来后一堆数字摆在那里普通用户看不出门道。你可以把关键统计指标拼成一段 prompt让大模型生成一份像人写的观察报告。比如近 30 期红球 07 出现 11 次、蓝球 05 连续 8 期未出现它会用自然语言组织成热号集中在……蓝球出现遗漏……的表述。这个能力特别适合做自动化周报。第三个价值是特征解释和思路拓展。你算出一个奇怪的统计现象比如红球 13 连续 5 期出现可以把数据发给大模型问这个现象在统计上怎么看。它能帮你梳理冷热号、遗漏、均值回归这些概念相当于一个随叫随到的数据分析顾问。4.3 一次真实的大模型生成 SQL 和报告的示例为了让大家看得明白我这里给一个简化但真实的例子。假设我已经把表结构信息发给大模型用户的问题是查出最近 20 期中蓝球出现次数最多的 3 个号码。发给大模型的 Prompt我的 MySQL 库中有一张双色球历史开奖宽表 ssq_history字段如下 issue_no CHAR(7) 期号 open_date DATE 开奖日期 red_1 ~ red_6 TINYINT UNSIGNED 6个红球升序排列 blue TINYINT UNSIGNED 蓝球 请生成一条 SQL统计最近 20 期中蓝球出现次数最多的 3 个号码。 要求只输出 SQL不要多余解释。大模型的输出大致是这样SELECT blue, COUNT(*) AS cnt FROM ssq_history WHERE issue_no IN ( SELECT issue_no FROM ssq_history ORDER BY open_date DESC LIMIT 20 ) GROUP BY blue ORDER BY cnt DESC LIMIT 3;我直接复制到 MySQL 里跑发现结果是对的。这就是大模型作为SQL 辅助工具的典型用法。它替代的不是数据分析师而是从中文需求到 SQL 语法的转换过程。报告生成的示例我放在下一章完整链路里一起演示因为那一步需要先有统计数据。5. 完整链路搭建MySQL Python 大模型 API 的实战 Pipeline5.1 架构与数据流从库到报告每个环节的职责到了这一步前面的碎片终于能拼成一条流水线了。我只用了一个简单的 Python 脚本定时任务就做到了数据更新→特征计算→统计摘要→大模型生成报告的全自动。数据流是这样的公开数据源 → Python 脚本清洗 → MySQL 宽表 明细表 MySQL → pandas 读取 → 特征计算 特征结果 → 拼接统计摘要 → 调用大模型 API → 生成报告文案 报告 图表 → 输出 Markdown / HTML 周报每个环节的职责非常单一MySQL 负责存pandas 负责算大模型负责写。这种解耦方式最大的好处是任何一个环节出问题都能单独排查不会牵扯其他部分。5.2 数据更新脚本的自动化思路双色球每周二、周四、周日开奖我写了一个 Python 脚本每次运行就从已下载好的开奖公告文件里读取最新一期插入 MySQL。这里我不建议直接去爬非官方站点最稳妥的方式是手动维护一份 CSV或者从官方公布渠道获取开奖公告然后脚本增量导入。增量导入的关键是那行 INSERT 加ON DUPLICATE KEY UPDATEinsert_sql INSERT INTO ssq_history (issue_no, open_date, red_1, red_2, red_3, red_4, red_5, red_6, blue) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE open_date VALUES(open_date), red_1 VALUES(red_1) 这样就算脚本重复执行也不会产生重复数据。唯一索引uk_issue在这里默默起了作用。更新完宽表后还要同步刷明细表。做法是先 DELETE 该期号的旧明细再重新 INSERT 6 行红球和 1 行蓝球。这个先删后插比逐行 UPDATE 简单可靠因为明细行的数量固定删了重建不容易留下脏数据。5.3 特征计算与中间表设计每次更新完数据我会把前面写的特征计算脚本跑一遍把结果写进一张中间表ssq_featuresCREATE TABLE ssq_features ( issue_no CHAR(7) NOT NULL, open_date DATE NOT NULL, red_sum SMALLINT UNSIGNED NOT NULL, red_span TINYINT UNSIGNED NOT NULL, odd_count TINYINT UNSIGNED NOT NULL, even_count TINYINT UNSIGNED NOT NULL, small_count TINYINT UNSIGNED NOT NULL, big_count TINYINT UNSIGNED NOT NULL, PRIMARY KEY (issue_no), KEY idx_open_date (open_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT双色球期次特征表;这张表的意义在于特征计算是一次性的之后所有报表查询都直接查中间表不用每次现算。真实数仓里的特征宽表就是这个思路。5.4 调用大模型 API 的工程细节Prompt、温度、校验特征表算好之后我把最近 N 期的统计指标聚合成一段摘要然后拼进 Prompt 发给大模型。这里有几个工程细节很关键。第一prompt 要分系统角色和用户问题。系统角色负责设定身份用户问题负责给数据和提要求。import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) stats_text 近30期红球出现次数Top507(11次)、18(10次)、23(9次)、14(9次)、31(8次)。近30期蓝球出现次数最多05(5次)。当前蓝球最大遗漏08连续12期未出现。近30期平均和值102.4。近30期奇数红球平均出现3.2个。 prompt f 以下是从 MySQL 中统计得到的双色球近期观察数据 {stats_text} 请生成一份 200 字左右的数据观察周报面向技术学习场景。 要求 1. 不要预测未来开奖号码 2. 客观描述统计现象比如频率变化、冷热分布、遗漏情况 3. 语气平实不要写成营销文案。 resp client.chat.completions.create( modelos.getenv(LLM_MODEL, qwen-plus), messages[ {role: system, content: 你是一名严谨的数据分析师只基于给定数据做客观描述。}, {role: user, content: prompt}, ], temperature0.2, ) report resp.choices[0].message.content print(report)第二temperature 要调低。我习惯设 0.2 到 0.3因为做数据解读时我不希望大模型脑洞大开编造统计结果。温度太高它会一本正经地说出数据里根本没有的结论。第三大模型生成完报告后我加了一道校验把报告里出现的号码和频率跟 stats_text 里的原始数据做一次交叉比对。比如报告说07 出现 11 次我就在 stats_text 里搜07(11次)搜到了才认为这一段可信。5.5 输出形态一份自动化的双色球数据周报链路跑通之后我的输出是一份 Markdown 周报里面包含三块内容基础统计表、特征趋势图、大模型文字解读。基础统计表直接从视图v_red_freq查出来转成 Markdown 表格。特征趋势图用 matplotlib 画和值走势、奇偶比变化。文字解读部分就是大模型生成的报告。这份周报我跑在服务器上设定一个 cron 定时任务每周一早上自动生成上周总结。整套东西跑起来之后我最大的感受是真正复杂的不是 AI 模型本身而是把数据弄干净、把链路串起来的过程。大模型只是最后一个环节的文字包装器前面 MySQL 的设计、SQL 的写法、pandas 的特征加工才是占工作量 80% 的部分。6. 复盘与避坑我在这个项目里踩过的四个坑6.1 数据截止时间没盯住第一个坑是我最容易犯的统计数据以为更新到了最新一期实际还差了三期。有三期缺数据频率统计结果还不至于翻天覆地但遗漏值这种指标是累计的差一期就完全错了。后来我在表结构里加了一个元信息表或者干脆每次生成周报时第一行注明数据截止到 2024xxxx 期。这样不管是谁看报告都能一眼知道数据时点。这个习惯后来被我带到了工作的数据报表里非常实用。6.2 期号用 CHAR 还是 INT前面已经说过期号我选了 CHAR(7)。但有个更隐蔽的坑是如果你从某些 CSV 里读到期号时Python 会默认把它读成 INT比如 2024001 会被转成整数 2024001看起来没问题但存入数据库时如果列是 CHAR(7)你得手动补零。我的解决办法是在 pandas 读取后用.astype(str).str.zfill(7)统一处理保证期号格式永远规范。这个小细节不写出来的话很多人会在数据导入阶段遇到明明看着一样但联查时等于不匹配的诡异问题。6.3 大模型的一本正经胡说八道我遇到过几次大模型把频率数字写错的情况。它明明看到07(11次)却在报告里写07 出现 9 次。原因是大模型生成文本时有概率漂移数字这种精确信息最容易被篡改。这也是我坚持加校验的原因。校验的代码思路很简单import re def validate_report(report: str, stats_text: str): errors [] for num, freq in re.findall(r(\d{1,2})出现(\d{1,2})次, report): if f{num}({freq}次) not in stats_text: errors.append(f报告中的 {num} 出现 {freq} 次与原始数据不一致) return errors把校验函数接在生成步骤之后有错就重新生成或者人工修正。这是所有LLM 生成内容类应用都必须有的安全网。6.4 把统计相关当成了因果预测这是我这个项目里最大的观念坑也值得提醒所有做数据分析的人。比如某段时间红球 07 连出几期按大数定律很多人会觉得该出别的号了。但独立随机事件没有记忆连出 5 期 07 和连出 5 期 05 之后第 6 期 07 出现的概率依然是 6/33不会因为历史数据而有任何变化。历史频率描述的只是过去已经发生的分布不构成未来某个号码更可能的证据。我能做的只是把这些统计现象描述出来比如07 近期出现频率偏高蓝球 08 当前遗漏较大但绝不会把遗漏大翻译成该出了。这个边界一旦守住这个项目的技术价值才真正立得住。6.5 数据来源单一、更新不及时还有一个现实问题手动维护 CSV 更新数据很枯燥容易漏。我后来做了一个半自动化的方案官方公告格式比较规整脚本能解析的自动解析解析不了的则抛个提醒让我手动处理。这样既保证了稳定性又不用完全依赖手工程序。如果你只是自己学习不用追求全自动。哪怕每周手动维护一次 CSV只要你的 MySQL 表结构和 Python 脚本是干净的同样能跑通整个流程。最后再分享一点个人体会。这个项目做完我最受益的不是学会了双色球数据怎么分析而是真正理解了数据从哪来、怎么存、怎么算、怎么用以及大模型在数据分析管线里的真实定位。它不是一个智能预测机而是一个擅长把数据翻译成语言的助手。后续我还想把这个框架迁移到其他公开数据集上比如大乐透、排列三甚至某些体育赛事的历史数据。换数据、换特征、换 prompt技术上完全复用。如果你也打算拿它练手建议你像我一样先把不预测中奖这个原则立住然后尽情折腾数据库和代码那才是这个项目真正的乐趣。