企业官网建设流程全解析

如果你正在找一个既能练 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='双色球历史开奖数据宽表';

这里有几个设计决策我想多说两句。

期号我用 CHAR(7) 而不是 INT。因为期号是"2024001"这种格式，前面的 2024 是年份，后面三位是当年期数。用 INT 存储虽然也能显示，但如果你哪天真按字典序排序，就会得到"2024001, 20240010, 2024002"这种诡异结果。更重要的是，期号本质上是一个业务编号，不是用来做算术运算的数字，用 CHAR 更合适。

红球和蓝球我用 TINYINT UNSIGNED，理由很简单：红球范围 1 到 33，蓝球范围 1 到 16，0 到 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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( host="127.0.0.1", user="root", password="your_password", database="lottery", charset="utf8mb4", ) 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 BY，pandas 的优势在灵活的行级变换，各用所长。

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 的实战 Pipeline

5.1 架构与数据流：从库到报告，每个环节的职责

到了这一步，前面的碎片终于能拼成一条流水线了。我只用了一个简单的 Python 脚本定时任务，就做到了"数据更新→特征计算→统计摘要→大模型生成报告"的全自动。

数据流是这样的：

公开数据源 → Python 脚本清洗 → MySQL 宽表 + 明细表 MySQL → pandas 读取 → 特征计算 特征结果 → 拼接统计摘要 → 调用大模型 API → 生成报告文案 报告 + 图表 → 输出 Markdown / HTML 周报

每个环节的职责非常单一：MySQL 负责存，pandas 负责算，大模型负责写。这种解耦方式最大的好处是，任何一个环节出问题都能单独排查，不会牵扯其他部分。

5.2 数据更新脚本的自动化思路

双色球每周二、周四、周日开奖，我写了一个 Python 脚本，每次运行就从已下载好的开奖公告文件里读取最新一期，插入 MySQL。这里我不建议直接去爬非官方站点，最稳妥的方式是手动维护一份 CSV，或者从官方公布渠道获取开奖公告，然后脚本增量导入。

增量导入的关键是那行 INSERT 加ON DUPLICATE KEY UPDATE：

insert_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_features：

CREATE 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='双色球期次特征表';

这张表的意义在于：特征计算是一次性的，之后所有报表查询都直接查中间表，不用每次现算。真实数仓里的"特征宽表"就是这个思路。

5.4 调用大模型 API 的工程细节：Prompt、温度、校验

特征表算好之后，我把最近 N 期的统计指标聚合成一段摘要，然后拼进 Prompt 发给大模型。这里有几个工程细节很关键。

第一，prompt 要分系统角色和用户问题。系统角色负责设定身份，用户问题负责给数据和提要求。

import os from openai import OpenAI client = OpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL"), ) stats_text = "近30期红球出现次数Top5：07(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( model=os.getenv("LLM_MODEL", "qwen-plus"), messages=[ {"role": "system", "content": "你是一名严谨的数据分析师，只基于给定数据做客观描述。"}, {"role": "user", "content": prompt}, ], temperature=0.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，技术上完全复用。如果你也打算拿它练手，建议你像我一样，先把"不预测中奖"这个原则立住，然后尽情折腾数据库和代码，那才是这个项目真正的乐趣。