# 生时校正分盘调用决策树

> 目标：把生时校正从“所有分盘一起上”改成“按证据价值和过拟合风险分层调用”。
> 结论先行：**不是所有分盘一股脑上。**

## 1. 总原则

生时校正时，优先级应当是：

1. `Dasha + dated events`
2. `D9`
3. `D10`
4. `D7 / D12 / D24 / D4 / D2` 按主题选
5. `Nakshatra / Pada / house shifts`
6. `D30`
7. `D60`

一句话版本：

**Dasha 定框，D9/D10 定核心，D12/D7/D24 等按题补刀，D30/D60 最后谨慎使用。**

这和当前仓库里已有的校时权重一致：

- `Dasha` 40%
- `分盘一致性` 35%
- `宫位变化` 15%
- `Nakshatra Pada` 10%

对应实现见：

- [jyotish-app/rectification-engine.js](<repo>/jyotish-app/rectification-engine.js)
- [references/varga-system-quick-reference.md](<repo>/references/varga-system-quick-reference.md)

## 1.1 产品化问询原则

生时校正不应默认要求用户先列出 8-15 个事件。普通用户路径优先采用主动问询：

```text
候选时间扫描
→ 分盘 / Arudha / KP cusp / Dasha 敏感差异提取
→ 生成高信息量选择题
→ 用户回答 A/B/C/D
→ 动态缩小候选时间簇
→ 进入下一轮追问
```

用户只需回答：

```text
A. 明确有，且时间大致吻合
B. 有类似，但时间略偏或不够重大
C. 没有明显发生
D. 不确定 / 不记得
```

机器可审计入口：

```bash
python3 scripts/active_rectification_questions.py --birth-time "1955-02-24 19:15" --uncertainty-minutes 30 --pretty
```

## 2. 第一层：主引擎

### Dasha + dated events

这是第一裁判，不是某一张分盘。

先用真实事件把时间框住：

- 结婚 / 分手 / 离婚
- 入职 / 升职 / 创业 / 换工作
- 搬迁 / 出国 / 移民
- 生育 / 流产 / 子女关键年份
- 健康危机 / 手术 / 事故
- 重大财富变化 / 破财

如果没有 dated events，只靠分盘做校时，风险会显著上升。

## 3. 第二层：核心分盘

### D9

最适合验证：

- 婚姻 / 关系质量
- 亲密关系成熟度
- 配偶画像
- 内在命运路线是否与 D1 同向

### D10

最适合验证：

- 事业显化
- 职业兑现
- 升职 / 名声 / 社会角色
- 事业方向切换是否成立

如果用户提供的事件主要是婚恋和事业，**D9 + D10 是最值钱的双核**。

## 4. 第三层：主题分盘补刀

当 Dasha 已经定出大框，但两个候选时间都还能解释时，再按主题调专项分盘：

| 事件主题 | 优先分盘 | 用法 |
|---|---|---|
| 婚姻/关系 | `D9` | 核心，不是补充 |
| 事业/升职/换工作 | `D10` | 核心，不是补充 |
| 子女/生育 | `D7` | 用于拉开生育相关年份与子女主题差异 |
| 父母/家族 | `D12` | 辅助裁判，不是第一裁判 |
| 教育/考试 | `D24` | 学业、考试、研究路线 |
| 房产/搬迁 | `D4` | 房产、居所、迁移、家庭落点 |
| 财富/收入变化 | `D2` | 收入、资产、财务结构变化 |
| 健康/事故/创伤 | `D30` | 只在有明确健康事件时用 |

其中 `D12` 的角色要说清楚：

- 它很有价值
- 但通常在 `D9/D10` 不能彻底拉开差距时再上
- 所以它是**辅助裁判**，不是**第一裁判**

## 5. 第四层：细分钟收口层

这一层适合最后 2-10 分钟的缩窄，不适合一开始就拍板：

- `Nakshatra / Pada`
- 特殊 Lagna
- 敏感点
- 分盘上升切换点
- 宫位变动

它们的作用是：

- 在大框已经基本收敛后
- 继续缩小到更细的分钟段

不应让这一层反过来主导整体结论。

## 6. 第五层：超高敏层，慎用

### D30

可用，但前提是用户有明确的：

- 健康危机
- 手术
- 创伤
- 事故
- 极端压力事件

### D60

只适合在已经高度收敛后，作为最后参考。

不要让 `D60` 反过来主导校时结论。原因很简单：

- 对出生时间太敏感
- 在事件样本不足时特别容易过拟合
- 很容易出现“解释很漂亮，但时间其实没校准好”

## 7. 实战决策树

### Step 1

先问：有没有 5 个以上带年份或日期的真实事件？

- 没有：先补事件，不急着堆分盘
- 有：进入 Dasha 定框

### Step 2

事件主要落在哪个主题？

- 婚姻/关系 -> `D9`
- 事业/升职/换工作 -> `D10`
- 子女/生育 -> `D7`
- 父母/家族 -> `D12`
- 教育/考试 -> `D24`
- 房产/搬迁 -> `D4`
- 财富/收入 -> `D2`
- 健康/事故/创伤 -> `D30`

### Step 3

如果两个候选时间在核心分盘上仍都说得通：

- 再看 `Nakshatra / Pada / house shifts`
- 再看更窄的分盘上升切换

### Step 4

只有当 Dasha + 核心分盘 + 主题分盘都已经明显收敛后，才允许上 `D60` 做最后参考。

## 8. 时间敏感度提醒

仓库当前已有的分盘时间精度要求：

- `D9 / D10`: `±2分钟`
- `D2/D3/D4/D7/D12`: `±5分钟`
- `D30`: `±1分钟`
- `D60`: `±30秒`

因此：

- `D9/D10` 足够敏感，适合作为校时主力
- `D30/D60` 过于敏感，适合作为后段验证

## 9. 禁止做法

以下做法不推荐：

- 一开始就把所有分盘全开
- 用 `D60` 反向主导时间结论
- 没有 dated events 时过度依赖高敏分盘
- 用单一分盘推翻 `D1 + Dasha + 核心分盘` 的同向证据

## 10. 落地口径

校时时，默认解释顺序应是：

1. `Dasha + dated events`
2. `D9`
3. `D10`
4. 主题专项分盘
5. `Nakshatra / Pada / house shifts`
6. `D30`
7. `D60`

如果需要一句给用户看的简明口径，就用这句：

**校时主力不是“所有分盘”，而是“Dasha 定框，D9/D10 定核心，D12/D7/D24 等按题补刀，D30/D60 最后谨慎使用”。**