prophet

name	prophet
description	Use when the user asks to predict football/soccer match scores, analyze betting lines (让球/盘口), or preview tournament fixtures. Covers World Cup, league matches, and international tournaments.

预言家 — 足球比分预测方法论 v1.0.0

基于 29 场开发集 + 60 场增量更新（含 MD3 12场复盘）+ 64 场 2022 回测校准。方向 ~70%，精确 ~20%。

📁 渐进式披露：本文件为入口（~150 行）。完整规则参数见 rules.md，贝叶斯系统见 bayesian.md，历史账本见 ledger.md。

---

核心工作流

基准数据(必修) + 伤停 + xG + 形势 + 战术体系 + 🌧️天气 → 逐条过规则 → 3D置信度输出

适用范围：世界杯、洲际杯、联赛、杯赛、欧冠——流程相同，数据源不同。 ⑭ "预选赛基准"在联赛语境下等同于"赛季场均 GF/GA"。

不同赛事的数据源

赛事	⑭ 等效数据	正赛数据	需搜索的源
世界杯	预选赛 GF/GA	小组赛已赛场次	FIFA.com, FBref, 懂球帝, 虎扑, 直播吧
洲际杯	预选赛+热身赛 GF/GA	正赛已赛场次	UEFA/CONMEBOL 官网, 懂球帝, 新浪体育
联赛	赛季场均 GF/GA	近 5 轮 + 主客场拆分	WhoScored, Understat, Soccerway, 懂球帝数据
杯赛	国内联赛赛季数据	杯赛已赛轮次	Transfermarkt, FBref, 直播吧, PP体育
欧冠/欧联	小组赛 GF/GA + 国内联赛	淘汰赛已赛回合	UEFA.com, Opta, 新浪体育, 网易体育

🔴 中文源优先原则：对以下数据类型，中文源优于英文源（实时性更强、摘要有更高的结构准确度）：首发阵容、赛果、比分、进球者、红黄牌、历史交锋战绩。 原因：懂球帝/虎扑/直播吧的内容直接从播出信号和官方数据流抓取，不经 AI 摘要改写。

🔴 预选赛数据例外：预选赛 GF/GA/积分榜必须以 ESPN/NBC Sports/Goal.com 英文源为准。中文源（搜狐/腾讯/网易）的预选赛数据存在场次错误、进球数偏差等严重问题（已验证：克罗地亚中文源 9 场 18GF vs ESPN 8 场 26GF——中文源错误）。预选赛数据不得使用中文源。

📡 预选赛数据权威信源

优先级	来源	用途	可靠性
🥇	ESPN / NBC Sports / Goal.com	UEFA/CONMEBOL 预选赛 GF/GA/积分榜	权威，直接采用
🥈	FIFA.com 比赛中心	单场比分、首发	权威但 API 仅限实时
🥉	懂球帝 / 虎扑 / 直播吧	CAF/AFC 预选赛（英文源索引不完整）	可靠，需交叉验证
❌	搜狐 / 腾讯 / 网易 预选赛聚合页	—	不可用（场次和进球数有事实错误）

交叉验证协议：任何预选赛数据在写入 teams.json 之前，必须至少在两个独立英文源之间核对（ESPN vs Goal.com / NBC vs UEFA.com）。中英文源出现矛盾时，英文源为准。

⚠️ 数据审计必修项（所有开发者必读）

不要直接使用原始预选赛 GF/GA。 以下操作是 v1.0.0 开发过程中踩过的坑，每一项都导致了 30-60% 的预测偏差：

1. ⑥ 鱼腩清洗不可跳过——GF 和 GA 都必须洗。 每个洲际都有球队面对极端弱旅刷出虚高数据。清洗方法：列出该队在预选赛中面对的所有对手，识别 ⑥ 清洗清单中标记的鱼腩，扣除对鱼腩的进球和失球后重新计算 GF/g 和 GA/g。GF 和 GA 缺一不可。 强队对鱼腩几乎不丢球（GA=0），不洗 GA 会导致防守数据系统性虚高（如克罗地亚 GA 0.50→0.67，葡萄牙 GA 1.17→1.50）。不得使用原始数据。

洲际	鱼腩示例	未清洗的典型虚高
UEFA	圣马力诺、直布罗陀、列支敦士登、安道尔	奥地利 2.75→1.50、葡萄牙 3.33→1.80
CAF	吉布提、索马里、塞舌尔、南苏丹、乍得	埃及 2.00→1.60、摩洛哥 2.75→2.00
AFC	缅甸、朝鲜、关岛、东帝汶、澳门、蒙古	日本 3.38→2.00、挪威 4.63→3.00
CONCACAF	巴巴多斯、阿鲁巴、圣卢西亚	库拉索 2.80→1.60
OFC	所有大洋洲对手（均为鱼腩级别）	新西兰 5.80→1.20

2. AFC 必须拆分第二轮和第三轮。 AFC 预选赛分为第二轮（含鱼腩）和第三轮（较强对手）。仅使用第三轮数据，或对第二轮场次完整清洗后合并。直接使用两轮合计数据会导致 GF/g 系统性偏高 50-80%。

3. CAF 数据优先搜中文源。 英文搜索引擎对 CAF 预选赛的索引极不完整（多为球员个人页面和新闻通稿）。懂球帝、虎扑等中文平台有完整的非洲区积分榜和场次数据。本次审计中，15 支 CAF/CONCACAF 队伍的 GF/GA 最终全部来自中文源。

4. 东道主的友谊赛数据不可靠。 美国、墨西哥、加拿大未参加预选赛，仅有友谊赛。美国 4 场友谊赛对手为比利时、葡萄牙、塞内加尔、德国（均为 elite 级别），GF/GA 被系统性压低/抬高。标注为 ⚠️ 并在预测时加大置信区间。

5. 预选赛和正赛的 GA 方向可能完全不同。 CAF 预选赛中频繁出现"0 失球"（突尼斯 10 场 0 失球、科特迪瓦 10 场 0 失球），这是因为对手攻击力极弱。正赛中数据已崩溃（突尼斯 2 场失 9 球）。预选赛 GA 必须结合对手质量判断，不能直接作为 ⑭ 输入。

数据审计检查清单

在开始预测前，逐项确认：

□ 所有队伍的 GF/GA 是否已经 ⑥ 清洗？**（GF 和 GA 都必须洗，缺一不可）**
□ AFC 队伍是否仅使用第三轮数据？
□ CAF/CONCACAF 数据源是否为中文平台？
□ 东道主数据是否标注为 ⚠️ 估计值？
□ 预选赛 GA=0 的队伍是否已调整？
□ teams.json 的 _note 字段是否记录了清洗方法？
□ 🔴 每场比赛的 market.signals 是否非空？（有盘口数据就不能留空数组）
□ 🌧️ 是否搜索了场馆天气预报？（雨战触发 ⑳）
□ 🔴 首发更新后是否重新搜索了赔率？（三次遗忘记录：巴西、德国、科特迪瓦）

引擎使用（本地脚本计算）

# Claude 搜索数据后填写 match.json → 跑引擎 → 解释输出
python engine/predictor.py --input match.json

Claude 职责：搜索预选赛/伤停/盘口 → 定性判断 → 🔴 提炼 market signals → 填 JSON → 跑脚本 → 解读双比分输出。

引擎职责：确定性公式计算（⑭ + ② + Σ γδ），两条输出：①纯方法论比分 ②市场修正比分。Claude 不再手动算分。

🔴 首发→赔率联动（不可跳过）

FIFA API 拉完首发 → python3 engine/fetch_odds.py --match PATH → 重跑引擎

顺序不可打乱。 赔率全程走 API，不手动搜索：赛前初盘跑一次 fetch_odds.py，首发公布后再跑一次。三次遗忘记录封存。

🔴 市场信号提炼（必修，不可跳过）

只要有盘口数据，market.signals 就不能为空。 从以下维度逐一检查是否需要提炼信号：

盘口信号	应提炼为	示例
Asian Handicap 偏离方法论 ≥1 球	adjust_home / adjust_away	方法论 1-3，盘口 -2.5 → 市场认为差距更大
Win to Nil 赔率异常低	adjust_home / adjust_away	England Win to Nil -135 → 对手大概率 0 球
Over/Under 与 methodologies 总进球偏离 ≥1 球	adjust_total	方法论总 3 球，U2.5 大热 → -1
BTTS No 概率 >60%	adjust_home 或 adjust_away	一方进球能力被市场否定
Draw 赔率异常低（< +250）	触发 ⑲ 检查	可能的默契球

delta 规则：

• adjust_home/away 的 delta 一般取 ±1。只在极端盘口（如 -2.5 以上）考虑 ±2。
• adjust_total 按需求取 ±1。
• 🔴 ⑲ 触发时禁止叠加 adjust_total：draw_both_advance=true 已触发方法论 ⑲（λ -0.80）+ 市场 auto r19（比分各 -1），此时再加 market signal adjust_total 构成三重计数。实际赛果验证：克罗地亚 vs 加纳 方法论 2-1 正确，三重修正压成 0-0 翻车。

🔴 出线形势判读：禁止机械「必须赢」

积分落后的球队 ≠ 必须赢。 逐队核验：

□ 平局能否晋级？（算积分+GD+最佳第3门槛）
□ 输球能否晋级？（4分大概率够最佳第3）
□ 平局是否对双方都有利？→ ⑲ draw_both_advance = true

典型错误：看到第3名落后第2名就写「必须赢」，不检验平局是否同样晋级。

🔴 首发公布后重新搜索赔率

赛前约 1 小时首发名单公布后，庄家赔率会随之调整。必须重新搜索一遍所有赔率数据，不可沿用赛前的旧赔率。 尤其关注：

• 核心球员首发/缺阵导致的水位变化
• 轮换幅度对 handicap 的修正
• 总进球数盘口的调整

预测公式

进球_A = ⑭基线_GF × ②对手系数 + Σ(触发规则_i × γ_i × δ_i) → 被⑤硬上限截断（如触发）
进球_B = 同上，对称计算
最终比分 = (round(进球_A), round(进球_B))

⑭ 和 ② 不进贝叶斯——直接从数据计算。贝叶斯更新公式见 bayesian.md。

---

数据质量保障 🔴 必修

三条铁律

I. 所有输入数据必须交叉验证。 单一来源的数据一律标注为 ⚠️ 存疑。交叉验证阈值：

数据类型	最低来源数	必须包含	示例
赛果/比分	2（独立域名）	中文源 ≥1	懂球帝+虎扑 = ✅；仅 FIFA.com = ❌
首发名单	2（独立域名）	中文源 ≥1，且发布时间 < 开球前1h	虎扑+直播吧 = ✅；仅 ESPN predicted = ❌
预选赛 GF/GA	1（原始数据）+ ⑥清洗计算	清洗计算必须可复现（记录扣除的对手和进球数）	FootyStats+清洗 = ✅；直接抄用 = ❌
伤停信息	2（独立域名）	发布时间 < 24h	懂球帝+队医官宣 = ✅；一周前的新闻 = ❌
历史交锋	1 + 常识检查	中文源 ≥1	新浪体育 = ✅

II. 未经验证的数据不影响预测。 如果首发名单未通过交叉验证，使用旋转风险假设（见首发验证机制章节），不得假设任何具体球员的出场或缺席。

III. ⚠️ 标记会传播到引擎输出。 teams.json 中标注 ⚠️ 的队伍，引擎自动将其 σ 扩大 30%（数据质量惩罚），并在输出中标注数据不确定性。用户看到 ⚠️ 时应降低对该预测的置信度。

数据质量对 σ 的影响

引擎在计算进球分布时，会根据数据可信度调整 σ：

数据状态	σ 调整	触发条件
✅ 已验证	无调整	teams.json 中无 ⚠️ 标记
⚠️ 估计值	+30%	teams.json 中 _note 含 ⚠️
⚠️ 东道主友谊赛	+50%	is_host=true

实现位置：predictor.py 的 _pooled_sigma() 方法。当 is_host=true 或队伍标记为 ⚠️ 时自动扩大。

赛果全量审计规则

回测或复盘时使用的赛果必须经过审计：

□ 账本 (ledger.md) 中的每场赛果是否来自 ≥2 个独立来源？
□ 来源是否为中文平台（懂球帝/虎扑/直播吧/新浪/网易/PP体育）？
□ 主客场方向是否正确？（搜索摘要常有主客颠倒）
□ 比分是否与 FIFA.com 或其他权威源一致？

---

规则速查

#	规则	一句话	E[γ]	δ	状态
⑤	结构性进攻无能	xG/射门<0.05 或连续零运动战进球 → cap 1 球 (🆕 xG>2.0豁免)	0.89	-1.5	🔵
⑩	开场进球	赛前判断前15分钟进球概率高 → 比分上调	0.64	+1.4	🔵
⑭	预选赛基准	对称应用 GF/GA。1场=85%+15%，2场=70%+30%	0.78	按队计算	🔵
⑫	战术对位	先看人员质量，再看阵型标签。大巴 ≠ 有效大巴	0.79	按对位分档	🔵
⑰	跨洲校准	AFC/CONCACAF+体系成熟 → GF×1.20	0.50	×1.20	🆕
⑮	室内/恒温	恒温无风 → 技术稳定，+0.25球	0.50	+0.25	🆕
⑯	战意衰减	v1.0.0活跃。A:锁头名→-1.5, B:轮换≥5→-1.0	0.55	-1.5/-1.0	🔵
⑱	补水暂停	动量中断(+0.15防方) + 晚期进球(+0.25全局)	0.50	+0.15/+0.25	🆕
⑲	平局博弈	平局=双方晋级 → 总进球-1.0球(全局)	0.80	-1.0(全局)	🔵
⑬	极端天气	暂停>30分钟 → 进球速率减半	0.71	-0.5	🔵
⑳	雨战	赛前/赛中持续降雨 → 双方 λ 各 -0.25	0.60	-0.25	🆕
㉑	板凳深度	5换时代替补席强→r16惩罚全额抵消（bench≥0.7）或25%（≥0.5）	0.60	+100%/+25%×r16	🔵
⑪	GK超神≠防守	区分门将个人表现和防守组织	0.69	—	🔵
⑨	门将不可预测	GK超神/超鬼不在模型范围内	0.75	—	🔵
⑧	精英防线	欧冠淘汰赛级防线+对手低两档 → 可破例零封	0.75	-1.0	🔵
⑦	创造力缺阵	降档幅度=f(缺阵人数, 顶替者级别)	0.69	按缺席计算	🔵
⑥	数据污染	🆕鱼腩清洗清单(AFC/CAF/CONCACAF),全污染→清零,半污染→降权50%	0.77	按污染级别	🔵
④	红牌风险	上一场红牌 → 本场红牌概率上调	0.50	+0.3	⚠️
②	对手质量	对手上一场对手质量 → 系数0.5x~1.5x	0.69	乘数因子	🔵
③	主场 +0.5	东道主+0.4 🆕移民准主场+0.25	0.70	+0.4/+0.25	🔵
①	不预测零封	GF<1.5且②<0.80→触发(+0.5)。被⑧覆盖时例外	0.72	+0.5	🔵

🔵 活跃 16 条 / 🆕 影子准入 4 条（⑮⑰⑱⑳）/ ⚠️ 影子降级 1 条（④）。⑯⑲㉑ v1.0.0 破格激活。㉒ 已删除（2026-07-03）。完整 α/β/σ/n 参数表见 rules.md。

优先级链

⑤ > ⑩ > ⑭ > ⑫ > ⑯ > ㉑ > ⑰ > ⑮ > ⑱ > ⑲ > ⑳ > ⑬ > ⑪ > ⑨ > ⑧ > ⑦ > ⑥ > ④ > ② > ③ > ①

⑮⑰⑱④ 当前为影子模式，不参与活跃预测。⑯⑲ v1.0.0 已激活。交互条款详情见 rules.md。

⑫ 效应量分档

对位	δ	示例
碾压对位	±1.5	五大联赛攻击线 vs 本土联赛大巴
清晰优势	±1.0	技术碾压但对手有组织
显著优势	±0.75	欧洲中游 vs 亚洲中游（波黑 vs 卡塔尔）
轻微优势	±0.5	同级但有对位差
均势	0	各有优劣
被克	-0.5	体系被对手克制

⑦ 缺阵分档

缺阵类型	δ
核心组织者	-0.8
主力射手	-0.5
多人同时缺	-1.2

🔴 ⑦ 只罚「不在大名单」，不罚「替补席」

替补席上的球员不是缺阵。 r07 只对伤停/禁赛/未入名单的球员生效。验证：

□ 该球员在比赛日大名单中吗？
   ├─ 是（首发或替补） → 不加 r07 ❌
   └─ 否（伤停/禁赛/未入名单） → 加 r07 ✅

案例：Bakambu 在替补席误加 r07，刚果 λ 从 1.33→0.99，方法论 2-1→2-0。实际赛果 2-1，错误。

🔴 ⑦ 只罚「新增缺阵」，不罚「早已缺阵」

如果球员在小组赛期间已经缺阵（从未上场），则不在淘汰赛阶段加 r07 惩罚。 原因：⑭ blend 的 30% tournament 权重已经反映了该球员缺席下的球队水平。再罚就是双重计数。

验证方法：

□ 该球员小组赛是否上场过？
   ├─ 是 → 淘汰赛不在大名单 → 加 r07 ✅
   └─ 否 → 早已缺阵 → 不加，baseline 已反映 ❌

案例：日本 Endo+Morita 小组赛前已缺阵，残阵打出 2-2 荷兰。误加 r07 导致 λ 从 1.71 压到 0.88，修正后回升。

---

首发名单验证机制 🔴 必修

核心原则：首发名单赛前约 1 小时公布。在此之前搜到的"confirmed lineup"大概率是预测/推测，不可直接作为⑦伤停依据。

验证流程

搜索首发名单
     │
     ├─ 距离 kickoff < 1 小时？
     │   ├─ YES → 检查来源
     │   │   ├─ FIFA.com / 球队官推 / BBC / ESPN match report → ✅ 可信
     │   │   └─ "predicted" / "probable" / "projected" / "preview" → ❌ 不可信
     │   └─ NO  → 不采信任何具体球员信息
     │
     ├─ 来源含 "injury" + "ruled out" + "confirmed"？
     │   ├─ YES → 队医确认的长期伤病 → ✅ 可信（即使是赛前几天）
     │   └─ NO  → 可能只是预测 → 标注为 ⚠️ 存疑
     │
     └─ 最终判定
         ├─ ✅ 可信 → 填入 input.json 的 key_player_missing / rotation_count
         └─ ❌ 不可信 → 使用旋转风险假设（见下文）

时差速查

比赛时区	vs UTC	vs 北京	首发公布（本地时间）
ET (美东)	UTC-4	北京-12h	赛前 1h ≈ 北京次日凌晨
PT (美西)	UTC-7	北京-15h	赛前 1h ≈ 北京次日中午
CET (欧洲)	UTC+2	北京-6h	赛前 1h ≈ 北京当日傍晚

无首发时的旋转风险假设

当首发不可信时，基于已验证事实做旋转风险判断：

球队状态	rotation_count	逻辑
locked_group_winner=true	5	锁头名后极度可能轮换 → 触发⑯A
already_qualified=true + 非主场	3	已出线但未锁头名，可能轮换但留力有限
already_qualified=true + 主场	0	主场观众压力 → 不轮换（历史：墨西哥MD3主场全主力3-0）
已淘汰	3	无成绩压力，可能给替补机会
必须赢	0	生死战，不可能轮换

⚠️ 当首发公布后（赛前 1 小时内），必须重新运行引擎，用真实数据覆盖假设。

已验证事实 vs 未验证传闻

✅ 可直接使用	❌ 需首发确认
上一场的比分、进球者	本场谁首发/替补
上一场的红黄牌（停赛确认）	赛前"大概率回归"的伤员
已确认的长期伤病（队医官宣）	"预计首发"预测文章
已淘汰/已出线的确定事实	教练赛前发言中的暗示
球员名单（FIFA.com 确认后）	阵型标注（即使是官方源也常错，如 4-3-3 vs 4-1-2-3）

历史教训

• 挪威 vs 法国 (I1)：搜索到"Haaland starts, full strength"。实际 Haaland 未上、挪威大幅轮换。来源是 predicted XI，不是 confirmed。→ 引擎被污染数据误导，方法论 3-3 平局 vs 实际 1-4 法国。

• 乌拉圭 vs 西班牙 (H1)：FIFA.com 页面本身阵容正确（Núñez 首发），但 deepseek web_search 工具在摘要中将其错误提取为"Núñez 板凳、Viñas 首发"。→ 即使 FIFA.com 这个来源是官方的，搜索工具的摘要提取仍可能出错。最终播出画面确认 Núñez 首发。

• 佛得角 vs 沙特 (H2)：英文搜索全返回 "predicted/probable"，反复搜不到确认阵容。切换到 懂球帝+虎扑+直播吧+PP体育+新浪+网易+搜狐 7 个中文源，全部指向同一份首发，交叉验证通过。中文源直接从播出信号扒数据，不经 AI 摘要改写。

• 正确做法：赛前应将 rotation_count 设为 3（双方均已出线），触发 ⑯B 旋转风险，方法论输出降至 2-2。H1 的教训则说明：结构化数据（阵容表）无法通过搜索摘要可靠获取，必须直接抓取原页面或交叉验证。 H2 的教训则说明：中文体育平台（懂球帝/虎扑/直播吧）比英文平台更适合获取首发阵容等结构化实时数据。

搜索摘要的可靠性陷阱 🔴

搜索工具（web_search）返回的是摘要/片段，不是原页面完整内容。对以下类型的数据，摘要提取的准确率显著下降：

数据类型	摘要可靠性	原因	对策
球员首发名单	❌ 低（英文源）/ ✅ 高（中文源）	英文源摘要易错位串行；中文源（懂球帝/虎扑/直播吧）直接从播出信号扒取	优先用中文源，交叉验证阈值：≥2 个独立中文源
具体数字（GF/GA/xG）	⚠️ 中	数字多且接近→摘要可能取到相邻错误的数字	交叉验证，优先用 FBref/WhoScored 原文
比赛结果和比分	✅ 高	格式简单固定	摘要通常可靠
叙事性信息（形势、教练发言）	✅ 高	文本自然语言	摘要通常可靠

交叉验证规则：当两个独立来源（不同域名）对同一事实给出相同结论时，可信度升级为"高"。

• ✅ 通过：来源A说Núñez首发 + 来源B也说Núñez首发 → 可信
• ❌ 不通过：只有一个来源提到具体阵容 → 不可信
• ⚠️ 警告：两个来源似乎互相引用（内容相同/翻译）→ 可能是同一篇文章的不同转载，不算独立验证

---

输出格式

基础要素（必修）

要素	说明
预选赛数据	GF/场、GA/场——必修项，不可跳过
⑥ 数据污染检查	对手前一场 ≥2 污染因素？→ 全污染清零 / 半污染降权50% / 无污染
⑦ 伤停搜索	赛前强制搜索每队伤病+停赛，不可遗漏
首轮/次轮回顾	比分 + xG + 关键信号
伤病	❌缺阵 / ⚠️存疑
出线形势	赢/平/输各意味着什么
战术对位	阵型+打法+人员质量，区分阵型标签 vs 实际执行
规则应用	逐条过，标注触发/不触发 + γ×δ 计算
比分+让球	🔴 必须同时输出方法论比分和市场修正比分，格式：方法论 2-1 / 市场修正 0-0
进球概率分布	每队 P(0球)~P(6+球) + λ/σ，引擎 JSON 自动输出。前端 output/web/index.html 并列显示两个比分

引擎批量输出

# 单场 JSON
python3 engine/predictor.py -i match.json -o output.json

# 批量：目录下所有 .json → web 目录
python3 engine/predictor.py --input output/predictions/ --out-dir output/web/

# 前端预览（← → 翻页 / 拖拽上传）
cd output/web && python3 -m http.server 8080

3D 置信度模块（必修）

维度 A：单规则信度条

触发规则清单：
  ⑭ 预选赛基准    γ=0.79 ████████░░ 高（n=65）
  ⑫ 战术对位      γ=0.76 ███████░░░ 中（n=46）
  ① 不预测零封    γ=0.75 ███████░░░ 中（n=59）

信度条长度 = E[γ] × 10。标注 n 判断稳定性。

维度 B：规则间冲突检测

同向规则数 - 异向规则数 → 冲突等级
  ≥ 2      → 无冲突
  0 或 1   → 轻微冲突
  ≤ -1     → 显著冲突（置信度降一档）

维度 C：预测区间

主队预期进球：2.1 球 → 80% 后验区间：[1.0, 3.2] → 宽度 2.2 → 中等
客队预期进球：0.8 球 → 80% 后验区间：[0.1, 1.5]

区间由各触发规则的 σ 叠加：总方差 = Σ(触发规则_i 的 σ_i²)。

综合信度评级

评级	条件
⭐⭐⭐ 高	同向净计数 ≥ 2 + 核心规则 E[γ] > 0.75 + 区间宽度 < 2.0
⭐⭐ 中	同向净计数 0~1 / 核心规则 E[γ] < 0.75 / 区间宽度 2.0-3.0
⭐ 低	同向净计数 < 0 / 关键规则 E[γ] < 0.60 / 区间宽度 > 3.0

---

方法论边界

• 不能预测的：红牌时间点、VAR、门将超神/超鬼、C罗/Messi 级的 GOAT 回应批评的爆发
• ⑬极端天气（暂停>30min）：赛前不调整，复盘必归因
• ⑳雨战：赛前搜天气预报，持续降雨→ λ -0.25。本届已发生：英格兰 vs 加纳（雨战0-0）、英格兰 vs 巴拿马（雨战2-0）
• 能预测的：方向（~70%）、净胜球范围
• 精确比分：大概率错误（~20%），靠运气
• 贝叶斯更新：信度随样本累积提高，但不改变「精确比分靠运气」的根本约束

---

🔴 赛后复盘与规则进化（每轮必修）

每轮比赛结束后必须执行以下流程，不可跳过。 这是影子规则激活/降级、参数贝叶斯更新的唯一入口。

复盘检查清单

□ 本轮所有赛果是否已录入 ledger.md？
□ 每场预测偏差是否已归因到具体规则？
□ 每条活跃规则的 α/β/n 是否已用本轮结果更新？
□ 🔴 每条影子规则是否已扫描本轮全部场次的触发条件？
□ 影子规则达到激活阈值（n ≥ 3 且 E[γ] > 0.50）→ 晋升活跃
□ 活跃规则 E[γ] < 0.50 持续 3+ 轮 → 降级影子

影子规则扫描方法

对每条影子规则，逐一检查本轮每一场比赛是否满足触发条件：

影子规则	扫描问题	本轮比赛数	应触发数
⑮ 室内/恒温	哪些比赛在室内/恒温场馆进行？	—	—
⑰ 跨洲校准	哪些比赛含 AFC/CONCACAF 体系成熟队？	—	—
⑱ 补水暂停	哪些比赛有强制补水暂停？	—	—
④ 红牌风险	哪些比赛出现红牌？与本轮总数对比	—	—

每条影子规则扫描后必须更新 rules.md 中的贝叶斯参数（α/β/n），无论是否触发。

激活/降级决策表

条件	操作	示例
n ≥ 5 且 E[γ] > 0.70	🔵 立即激活	⑯ MD3 三场翻转即激活
n ≥ 3 且 E[γ] > 0.50	🟡 可破格激活（需人工判断）	⑲ 博弈论基础扎实
n ≥ 3 但 E[γ] ≤ 0.50	❌ 废弃，从规则表删除	—
E[γ] < 0.50 持续 3+ 轮	⚠️ 降级影子（不删除，继续观察）	④ 当前状态
n=0 持续 2+ 轮	⚠️ 标记为「待验证」，提示可能需要重新设计	⑮⑰⑱ 当前状态

当前影子规则积压（2026-06-27 状态）

🔴 66 场比赛已打完，以下影子规则 n 仍为 0，本次复盘必须补扫描：

规则	n	已进行的相关比赛（示例）
⑰ 跨洲校准	0	日本 3场, 韩国 3场, 美国 3场, 澳大利亚 3场, 伊朗 3场, 沙特 3场
⑮ 室内恒温	0	AT&T Stadium (Jordan-Arg, 捷克-墨西哥), 至少 6 场室内/恒温
⑱ 补水暂停	0	Miami, Dallas, Atlanta 等多场下午场

常见错误

错误	正确做法
预选赛数据选择性应用（只看防守不看进攻）	规则⑭：GF 和 GA 必须对称分析
「摆大巴」=「有效大巴」	规则⑫：先看后卫来自哪个联赛，再看阵型
用一场小组赛推翻预选赛全部数据	一场比赛信噪比极低，85% 预选赛权重
对手自爆数据当真实力	规则⑥：检测污染
凉爽天气 = 更高强度 = 更多进球	凉爽增加跑动但降低转化率。温暖天气 + 恒温才利好大球
静态假设首发 = 动态战术现实	规则⑫：验证实际首发。同一球队跨场防守质量可天差地别
世界杯数据照搬到联赛	联赛⑭基准用赛季场均而非预选赛。需拆主客场 GF/GA（⑭ + ③高度相关时分开处理）
杯赛当联赛预测	杯赛有加时+点球——引擎输出的是常规时间比分
赛前搜到"confirmed lineup"就信	🔴 首发赛前1h公布。之前搜到的大概率是 predicted/projected。需验证来源+时间，否则用旋转风险假设
搜索摘要当原页面内容信	🔴 搜索工具对阵容表/数字的摘要提取易出错（H1: FIFA页面正确但摘要说Núñez板凳）。结构化数据必须交叉验证或直接抓取原页面