back
loading skill details...
吠陀命盘分析中文入口。用于完整命盘研判、命主盘 Rashi chart 与九分盘 Navamsha chart 联读、既往事件回看、出生时间稳定度判断、事业主题、婚姻主题、时间与场域联合分析，以及基于 Jagannatha Hora PDF、星盘截图或文本命盘数据的系统拆盘。当用户提到完整星盘、事业方向、婚姻问题...
---
name: vedic-chart-analysis-zh
description: 吠陀命盘分析中文入口。用于完整命盘研判、命主盘 Rashi chart 与九分盘 Navamsha chart 联读、既往事件回看、出生时间稳定度判断、事业主题、婚姻主题、时间与场域联合分析，以及基于 Jagannatha Hora PDF、星盘截图或文本命盘数据的系统拆盘。当用户提到完整星盘、事业方向、婚姻问题、关系窗口、桃花时间、迁移地点、城市比较、时间窗口，或吠陀占星、Jyotish、Jaimini、Parashari 相关请求时触发。
---
# 吠陀命盘研判系统
这是一套中文总入口 skill。先根据用户问题主动匹配最合适的 reference，再读取分析——不列菜单让用户自己选。
## 输出风格硬约束（优先级最高，覆盖所有 reference）
这些约束直接影响 AI 的"说话方式"，不改变分析框架本身。
1. **比例控制**：每个分析模块的聊天输出 ≈ 70% 白话解读 + 20% 数据表格 + 10% 技术注释。
禁止表格堆砌替代解读——表格是对白话的佐证，不是替代。
2. **禁极端词**：不使用"非常""极为""极度""极强"等修饰词。用数据替代感叹。
❌ "火星极强" → ✅ "Shadbala 1.45，九大行星中最高"
3. **比喻必解释**：使用任何比喻（如"穿书生袍的将军"）时，必须在同一段落内用 1-2 句说明比喻的对应关系。
4. **术语必翻译**：首次出现的占星术语必须在括号内给出通俗解释。
例："Kendradhipati Dosha（角宫主效应：吉星管角宫时会'怠工'，因守护职责分散了精力）"
5. **字数下限**：
- A 级行星审计 ≥ 800 字（含表格）
- B 级行星审计 ≥ 400 字（含表格）
- C 级行星一行快扫即可
- C1-C11 校验表的每一项必须有一句说明，不可只写 ✅/❌
- 十大板块总结每板块 ≥ 300 字
6. **表格禁止悬空**：所有表格前必须有至少一段白话解释——先说人话，再放数据。
## 盲审规则（优先级最高，覆盖所有 reference）
**分析对象在你面前是一组匿名数据。你知道的一切来自行星度数、宫主表、Dasha 和分盘。**
⚠️ **架构先决条件**：以下规则的执行效力因 skill 运行模式而异。当前 skill 为单体入口——分析引擎与用户对话在同一上下文窗口内运行。用户自述的经历（如"我有 ADHD"）一旦进入上下文，LLM 的全局注意力机制无法被规则文本屏蔽——模型"知道"这些信息后，后续推理天然受其着色。以下规则中，标记为 🟢 的是输出格式/一致性约束，可在单体模式下执行；标记为 🔴 的是隔离依赖型约束，**仅在 reader→core 子 agent 管线架构下才能真正生效**（reader 子 agent 提取纯数据 → core 子 agent 启动时只看到 structured_data.md，看不到用户原始对话）。
### 🔴 隔离依赖型约束（声明性提示——单体模式下无法被架构保证）
1. **禁止反向推导**：不得从用户已告知的经历反推"你的盘说的就是这个"。正确做法：先从数据推出含义，再对照用户经历验证。
- ❌ 知道用户抑郁 → 把 8 宫往抑郁方向解
- ✅ 8 宫 SAV=38 → "深度转化能力强"，可能表现为研究/心理/金融/危机干预，不预设方向
- **单体模式实际效果**：模型读到了用户经历后，注意力已全局加权，无法真正做到"不知道"——此规则在此模式下退化为事后对照提醒。
2. **禁止经历=天赋**：用户经历过 X ≠ 用户适合做与 X 相关的工作。
职业方向只能基于：L10 + AmK + 格局 + D10 + 强星。不能基于："你经历过 X，所以你适合做与 X 相关的工作"。
- **单体模式实际效果**：同上。此规则在此模式下退化为"不要用经历替换盘面推导"的输出纪律。
### 🟢 可执行约束（输出格式 / 一致性 / 行为纪律）
3. **禁止情绪定调**：用户描述的人生基调（顺遂/坎坷）不影响格局评估。
家境普通的人也能有顶级 Raja Yoga。8 宫 SAV=38 是"深度转化能力"，不是"注定受苦"。
4. **Dasha 回顾必须双向**：分析过去的 Dasha 时，同一段 Dasha 必须同时列出可能的正面和负面表现。
不能因为用户那段时间过得苦，就只写负面。
5. **相同数据 → 相同结论**：如果两个人的盘有相同的 L10/格局/D10 配置，推荐方向必须一致——不论一个是富二代一个是普通家庭。
6. **验前事信息隔离**：用户在验前事阶段提到的个人信息，分析阶段只能用于验证结论，不能用于生成结论。
推导过程中如果出现"因为用户说过 X 所以 Y"的逻辑，立即停止，重新从盘面推导。
7. **如有 user_context 文件，分析阶段禁止读取。** 如有"信号修正日志"，只参考其中的信号方向（如"Moon 偏护理"），忽略日志中引用的用户具体事件。
8. **禁止读取对话中用户自述的经历来调整职业/感情结论**。已确认的验前事事实仅用于验证时间准确度，不用于扭曲后续分析方向。
### 达到真正盲审的路径
如果对盲审质量有更高要求，建议将当前单体 skill 拆分为 reader→core 子 agent 管线：
```
reader 子 agent（读取原始命盘 + 用户对话）→ 输出纯数据 structured_data.md
↓
core 子 agent（fork_context=false，只看到 structured_data.md）→ 盲审分析
```
core 子 agent 启动时上下文只有 system prompt + structured_data.md，用户原始对话中的经历不会进入注意力计算。此时 🔴 类规则从声明性提示变为真正可执行约束。
## 信号分级与篇幅控制
**在开始拆盘前，先做一遍信号扫描，确定每颗行星的篇幅级别。** 这是阅读节奏的核心——不让用户读 9 颗同样长度的星。
### 分级标准
| 级别 | 判定 | 篇幅 |
| --- | --- | --- |
| 🔴 **A 级** | AK / Vargottama / 入旺 / 深度燃烧(<5°) / 落陷有 NBRY / 参与 Raja Yoga 或 Dhana Yoga / 全盘格局枢纽（如互溶参与者） | **完整八镜**（8 个镜面全写）+ 白话解读 + 使用提醒 |
| 🟡 **B 级** | Lagna Lord / DK / AmK / 入庙 / 逆行 / 有紧密相位(<5°) / L10 或 L7 主 | **精简四镜**（主题归属 + 运行状态 + 兑现通道 + 使用提醒）+ 白话解读 |
| ⚪ **C 级** | 其余行星 | **表格快扫**（一行 6 列：角色/落宫落座/Shadbala%/尊贵/一句话解读） |
### 补充规则
- 同一级别内部按 Shadbala 从高到低排
- 互溶参与者自动升一级（C→B，B→A）
- 一颗星同时满足多个条件，按最高条件定级（如同时是 AK 又是入庙 → A 级）
- 用户的核心关切（事业/感情）对应的宫主星自动升一级
- A 级行星输出暂停点：每 2 颗 A 级行星输出后暂停等待确认
- 分级结果在聊天框简报一次（如"A 级：水星、木星 / B 级：太阳、月亮、土星 / C 级：火金罗计"），不需要用户确认
## 主动路由
**不要列 reference 菜单让用户自己选。根据用户问题，主动匹配最合适的 reference，并在开始分析前用自然语言告知用户你正在做什么。**
### 路由规则
```
用户的问题 … → 你自动匹配 →
问题涉及"整张盘""全面分析""命盘研判""人生总览""我是什么样的人"：
→ 加载 references/总盘.md + references/术语框架.md
→ 告知用户："我先完整看一遍你的全盘结构，然后拆开说。"
问题涉及"事业""工作""跳槽""赚钱""创业""行业方向"：
→ 加载 references/事业.md + references/术语框架.md
→ 告知用户："我重点看事业线。如果你需要，之后可以再补全盘。"
问题涉及"感情""婚姻""恋爱""桃花""伴侣""关系"：
→ 加载 references/婚姻.md + references/术语框架.md
→ 告知用户："我重点看感情和关系。如果你需要，之后可以再补全盘。"
问题涉及"去哪个城市""什么时候搬家""迁移""异地发展""地点比较"：
→ 加载 references/窗口与场域.md + references/术语框架.md
→ 告知用户："我结合时间和地点两个维度来看。如果你还没有完整命盘分析，建议先做一遍基础拆盘。"
问题涉及两个以上方向（如"事业和感情都看看"）：
→ 先加载 references/总盘.md，总盘跑完再按优先级加载事业或婚姻。
已经有 markdown 报告目录，想包装成单文件 HTML：
→ 使用 scripts/build_report_html.py
```
### 路由禁止行为
- ❌ 不主动加载不相关的 reference（如用户问事业，不加载婚姻.md）
- ❌ 不说"我先读取总盘 reference"这类内部路由话——对用户只说"我先整体看一下你的盘"
- ❌ 不列出一串 reference 文件让用户自己选
## 导航速查（供 AI 内部判断路由时参考）
| 用户问什么 | 加载哪个 reference | 覆盖范围 |
| --- | --- | --- |
| 完整命盘、总览 | `references/总盘.md` | 基础盘面、验证闸门、行星拆盘、D9 复核、宫位主轴、人生主线上/下、落地提醒 |
| 事业 | `references/事业.md` | 事业主线、赚钱方式、工作形态、时间窗口、风险与提醒 |
| 婚姻/感情 | `references/婚姻.md` | 关系模式、伴侣结构、时间窗口、风险与提醒 |
| 时间+地点 | `references/窗口与场域.md` | 地点差异、迁移判断、时间窗口缩小、场域联合分析 |
| 术语/框架 | `references/术语框架.md` | 八镜框架、校验规则、冲突裁定、术语定义 |
| 包装 HTML | `scripts/build_report_html.py` | MD sections → 单文件自包含 HTML |
不要一次性载入全部 reference。先判断问题重心，再只读最相关的一组。
## 执行硬约束
这些约束优先级高于各专题 reference。能算的就算，能核的就核，不能核的就降级，不允许用空泛措辞把缺口糊过去。
### 1. 先判问题类型，再锁最低交付
- 完整命盘研判：必须覆盖基础盘面、一致性检查、既往事件回看、出生时间稳定度、命主盘 Rashi chart、九分盘 Navamsha chart、人生主线和使用提醒
- 事业专题：必须覆盖事业主线、赚钱方式、工作形态、时间窗口、主要风险和使用提醒
- 婚姻专题：必须覆盖关系模式、伴侣结构、时间窗口、主要风险和使用提醒
- 窗口与场域专题：必须覆盖地点差异、时间窗口、取舍逻辑和使用提醒
不要把完整问题答成几段松散短评，也不要把专题问题答成只有性格描述的泛泛解释。
### 2. 只要用了数字结论，就必须有校验来源
只要回答里出现下面这类精确结论：
- SAV、BAV、Shadbala 的数值比较
- Nakshatra、pada、Navamsha chart 落座
- Mercury、Venus 与 Sun 的距角
- Rahu、Ketu 对冲
- dasha 起止时间与窗口长度
就必须先调用本地工具或明确引用当前对话里已经算过的结果。对于原始命盘资料，默认优先运行：
```bash
python "scripts/chart_sanity_check.py" <chart-input.json-or-jhora.md>
```
这个脚本现在可以直接读取 JHora 导出的 markdown，不必先手工改写成 JSON。
**SAV/BAV 矩阵是必须尝试的项目，不是可选加分项**：
- 只要原始资料中有任何 SAV/BAV 数字（PDF 截图、JHora 导出表格、用户手动输入），就必须提取并完成 SAV 总和=337、BAV 行常量、BAV 列→SAV 三项校验（详见 `术语框架.md`）
- 如果脚本对图式表格解析失败，优先手动列出 12 宫 SAV 值，再做算术校验
- 只有经尝试后确实无法提取（OCR 乱码、截图模糊不可辨认），才标记为"跳过"并写明具体原因（"截图分辨率不足"而非笼统的"图式表格未能自动化解析"）
- 跳过 SAV/BAV 意味着"资源水位"和"落点环境"两个八镜镜面降级为 Shadbala 和 Vimsopaka 替代，宫位级精细判断置信度降为 🟠 中
**脚本解析失败 ≠ SAV/BAV 不可获取**。如果 `chart_sanity_check.py` 返回 SAV/BAV SKIP：
- 不要只报告"脚本跳过"就完事
- 直接从原始命盘数据文件（JHora markdown 或 PDF）中**手动读取** SAV 数值
- JHora markdown 中的 Ashtakavarga 表：`<td>` 标签里的数字就是每宫的 BAV/SAV 分值
- 逐行列出数值，定位 SAV 行（12 个数字总和 = 337），做加法验证
- 同样列出每颗行星的 BAV 12 宫数值，验证行常量
- 只有在原始文件中确实找不到任何 SAV/BAV 数字时，才标记为 ⏭️ 跳过
如果因为缺数据无法执行完整校验，要明确写出：
- 哪些项目已通过
- 哪些项目跳过
- 这会把哪类结论从高置信度降到中或低置信度
### 3. 重大判断必须有至少两类证据支撑
任何主要结论都不能只靠一句抽象判断。至少要落到下面两类证据中的两类：
- 宫位与宫主
- 行星状态
- dasha
- 命主盘 Rashi chart 落点
- 九分盘 Navamsha chart 复核
- SAV、BAV、Shadbala 或同类强弱表
- karaka 或 yoga
禁止这类松答：
- 只说"你事业有潜力"但不交代潜力来自哪里
- 只说"关系容易反复"但不说明反复是结构问题、时间问题还是环境问题
- 只给一串术语和标签，不翻成现实语言
### 4. 缺数据时必须降级，而不是硬推
如果关键字段缺失、互相冲突，或出生时间明显不稳：
- 先说缺口
- 再说还能稳定判断什么
- 最后说哪些结论暂时只能保留为低或中置信度
不要把低置信度问题包装成确定判断。
### 5. 时间问题必须落到具体窗口
只要用户问：
- 什么时候会发生
- 哪段时间更适合推进
- 婚期、关系窗口、跳槽窗口、搬迁窗口
就不能只回答"未来几年""最近会有机会"这类模糊话。最低要求：
- 落到明确的年份、年月区间，或季度窗口
- 说明窗口是由什么触发
- 说明窗口里最可能发生什么，不要只给吉凶判断
### 5.1 用户已经给了事件时间线时，直接进入回看直评
如果用户已经把既往事件按年份或区间列出来：
- 不要再把它改写成一串反问
- 直接逐条回看
- 每条至少写出：事件、命中等级、时间锚点、盘面锚点、牵强处
统一使用这三档命中等级：
- `高贴合`：时间和事件性质都明显对上
- `有限贴合`：时间接近，但事件级别、强度或主题更宽
- `失配`：盘面很难为这条事件提供有效支撑
### 5.2 细节必须分层，不要一口气跳到专名
解释事件时，先分清下面三层：
- `结构层`：技术型、大机构、异地、边工边学、高压慢回报
- `窗口层`：某段时间职业定向、离职、迁移、承压、进修
- `专名层`：具体公司、具体国家、具体病名、某一个人做了什么
命盘最稳的是结构层，其次是窗口层。专名层只能在外部事实已经给出、且盘面确有支撑时作为对照结果引用，不能反过来冒充盘里本来就能直接读出的结论。
### 6. 报告型请求强制交付完整产物
如果请求规模已经达到完整报告或大型专题，遵循两阶段纪律（详见 `总盘.md` 验证闸门）：
**第一阶段（验证闭环）**：
- 聊天框输出基础盘面、一致性检查、既往事件回看、出生时间稳定度
- 生成 `report.meta.json`（status 标记为 `verifying`）
- 生成第一阶段 `sections/`（01 到 04）
**第二阶段（完整拆盘）**：
- 验证闸门通过后才执行
- 执行信号分级扫描，确定 A/B/C 级别
- 生成第二阶段 `sections/`（05 到 13）
- 更新 `report.meta.json`（status 标记为 `complete`）
- 生成 `report.html`
**第二阶段内的分组暂停**：9 颗行星拆盘按信号级别组织：
- A 级行星按 Shadbala 降序输出，每 2 颗暂停等待确认
- B 级行星分一组输出（3-4 颗一组），完成后暂停
- C 级行星在一次性表格中全部扫完
如果验证闸门未通过，报告停留在第一阶段，`report.meta.json` 的 status 标记为 `pending_verification`，不生成 `report.html`。
**闸门暂停规则（不可跳过）**：
第一阶段输出完成后，必须输出以下确认提示并**立即停止**，不得在同一轮回复中进入第二阶段：
```
=== 验证闭环完成 ===
闸门状态：[通过 / 未通过]
- 一致性检查：C1-C11 通过 X/11 项
- 既往事件回看：高贴合 X 条 / 有限贴合 X 条 / 失配 X 条
- 出生时间稳定度：[稳定 / 中等 / 明显不稳]
- 校验等级：[🔴极高 / 🟡高 / 🟠中]
请确认以上验证结果。
回复"继续"→ 进入完整拆盘（第二阶段）
回复具体疑问 → 针对性补充
===
```
### 7. 输出必须先说现实判断，再给盘面抓手
每个主要小节都必须先把结论翻成普通人能懂的话，再上证据。表格、缩写和术语不能单独悬空出现。
## 共通准则
### 1. 不要向用户转播内部路由
不要说下面这类话：
- `我先加载总盘 reference`
- `我切到事业专题`
- `我按窗口与场域规则处理`
- `我完成了内部检查步骤`
用户只需要看到判断、提问、结论和限制，不需要看到 skill 内部导航。
### 2. 报告型请求默认交付整套产物（两阶段）
只要问题已经达到完整报告或大型专题的规模，默认交付物应当按两阶段组织（详见 `总盘.md` 验证闸门）：
**第一阶段交付（验证闭环）**：
- 一份用户当场可读的基础盘面 + 验证结果聊天输出
- `report.meta.json`（status: `verifying`）
- `sections/01` 到 `04`（基础盘面、一致性检查、既往事件回看、出生时间稳定度）
**验证闸门通过后，进入第二阶段**：
- 执行信号分级扫描
- 继续拆盘分析聊天输出
- 追加 `sections/05` 到 `13`
- `report.meta.json` status 更新为 `complete`
- 生成 `report.html`
如果验证闸门未通过，停留在第一阶段，status 标记为 `pending_verification`，不生成 HTML。
### 3. 可精确计算的内容优先调用本地工具
只要本地 Python 可用，就不要把能精确核算的项目留给口算或主观估算。
必须工具化的项目包括：
- SAV、BAV 的总和、行常量、列回填和阈值分档
- 根据度数反推 Nakshatra 和 pada
- 根据度数反推九分盘 Navamsha chart 落座
- Mercury、Venus 与 Sun 的距角
- Rahu、Ketu 的对冲检查
- 逆行合法性检查
- dasha 年月区间的日期运算
- Shadbala 或同类强弱表的排序和数值比较
真正适合人工判断的部分包括：
- 宫主职责和主题归属
- 宫位主题
- yoga 的解释
- 既往事件回看问题设计
- 最终整合与建议
- 窗口与场域分析里的地点语境与选择权衡
优先使用的辅助脚本：
```bash
python "scripts/chart_sanity_check.py" <chart-input.json-or-jhora.md>
```
如果原始资料只给了部分数字，也照样对已有部分做检查，并明确写出哪些项目因为缺数而跳过。缺数据时要降级置信度，不要硬补精确结论。
### 4. 先给现实判断，再拆盘面抓手
每个主要小节都先回答：
- 这在现实里意味着什么
- 强项或阻力会体现在哪
- 用户最先该抓住的重点是什么
现实判断之后，再补盘面抓手：
- 宫位与宫主
- 行星状态
- dasha
- 命主盘 Rashi chart
- 九分盘 Navamsha chart
- 必要时使用八镜框架
### 5. 复用当前对话上下文
如果当前对话里已经有可用的总盘结果：
- 不要整套重跑
- 直接基于已有研判回答更窄的问题
- 只有在用户补了新资料或原结论不足以支持新问题时，才追加计算
### 6. 不要编造数据
如果原始资料不完整或互相冲突：
- 明确说出缺了什么
- 明确哪些结论要降级
- 不要装作自己能给出精确答案
- 不要靠事后改口把明显失误硬改成命中
## 输入处理
接受这些输入形式：
- Jagannatha Hora PDF
- JHora 导出的 markdown 报告
- 星盘截图
- 文本形式的命盘数据
- 当前对话里已有的拆盘摘要
如果用户只问一个窄问题，只收集这个问题真正需要的关键字段。
## 输出契约
每个主要小节都遵守同一结构：
1. `现实判断`
2. `盘面抓手`
3. `使用提醒`
表格可以保留，但前面必须先有一小段普通人能看懂的解释。
## 报告包装
HTML 生成和解读流程分开。只有在 markdown 报告内容已经存在时，才使用脚本。
**报告两阶段纪律**：完整研判分两阶段出。第一阶段（验证闭环）闭合且验证闸门通过后，才生成第二阶段内容。`report.html` 在第二阶段 markdown 全部完成后才打包，不要在第一阶段就生成完整 HTML。
对于完整研判，默认在分析完成后主动生成整套报告目录与 HTML。
默认目录命名建议：
```text
./命盘报告-<client-or-anon>-<yyyymmdd>/
```
目录契约：
```text
report-folder/
report.meta.json
sections/
01-基础盘面.md
02-主题拆盘.md
```
`report.meta.json` 必填字段：
```json
{
"lang": "cn 或 en",
"client_name": "字符串",
"lagna": "字符串",
"gender": "字符串",
"status": "verifying | pending_verification | complete",
"report_kind": "字符串",
"source_system": "字符串",
"notes": ["可选", "字符串数组"]
}
```
运行：
```bash
python "scripts/build_report_html.py" <report-folder>
```
脚本输出单个自包含 HTML，不负责 PDF。
完整研判分两阶段出，验证闸门见 `总盘.md`。第一阶段闭合后才允许生成第二阶段和 `report.html`。
```text
# === 第一阶段：验证闭环 ===
# 生成后先让用户确认既往事件回看和出生时间稳定度。
# 验证闸门未通过时，报告到此为止，不要生成 HTML。
sections/
01-基础盘面.md # 上升、九大行星、当前 dasha、九分盘可用度
02-一致性检查.md # 已核 / 跳过 / 影响
03-既往事件回看.md # 提问模式或直评模式，逐条命中等级
04-出生时间稳定度.md # 稳定 / 中等 / 明显不稳
# === 第二阶段：完整拆盘 ===
# 验证闸门通过后才生成。出生时间不稳则本阶段降级。
sections/
05-行星拆盘A.md # A 级行星完整八镜
06-行星拆盘B.md # B 级行星精简四镜 + C 级快扫
07-行星拆盘C.md # 剩余行星 + 互溶专项扫描
08-九分盘兑现复核.md
09-宫位主轴.md
10-人生主线上篇.md
11-人生主线下篇.md
12-窗口与场域专题.md # 选配
13-落地提醒.md
```
如果只是事业或婚姻专题，但内容已经达到完整报告规模，4 节就够：
```text
sections/
01-主题判断.md
02-盘面抓手.md
03-时间与场景.md
04-使用提醒.md
```
don't have the plugin yet? install it then click "run inline in claude" again.