vedic-destiny（吠陀命运）

吠陀命盘研判系统

这是一套中文总入口 skill。先判断用户到底要看整张盘、某个专题，还是时间与地点的联合问题，再只读取当前任务真正需要的 reference。

导航方式

按问题最小化加载：

• 用户要完整命盘研判、本命总览、既往事件回看、出生时间稳定度判断，或命主盘 Rashi chart 与九分盘 Navamsha chart 的联合拆盘：

读取 references/总盘.md

• 用户要事业方向、工作模式、变现路径、岗位适配、创业与上升窗口：

读取 references/事业.md

• 用户要婚姻、恋爱模式、关系落地、伴侣结构、桃花窗口、长期关系判断：

读取 references/婚姻.md

• 用户要地点选择、迁移判断、城市比较、事件窗口缩小，或时间与场域联合分析：

读取 references/时空盘.md

• 需要共享术语、读盘抓手和冲突裁定口径：

读取 references/术语框架.md

• 已经有 markdown 报告目录，想包装成单文件 HTML：

使用 scripts/build_report_html.py

不要一次性载入全部 reference。先判断问题重心，再只读最相关的一组。

执行硬约束

这些约束优先级高于各专题 reference。能算的就算，能核的就核，不能核的就降级，不允许用空泛措辞把缺口糊过去。

1. 先判问题类型，再锁最低交付

• 完整命盘研判：必须覆盖基础盘面、一致性检查、既往事件回看、出生时间稳定度、命主盘 Rashi chart、九分盘 Navamsha chart、人生主线和使用提醒
• 事业专题：必须覆盖事业主线、赚钱方式、工作形态、时间窗口、主要风险和使用提醒
• 婚姻专题：必须覆盖关系模式、伴侣结构、时间窗口、主要风险和使用提醒
• 时空盘专题：必须覆盖地点差异、时间窗口、取舍逻辑和使用提醒

不要把完整问题答成几段松散短评，也不要把专题问题答成只有性格描述的泛泛解释。

2. 只要用了数字结论，就必须有校验来源

只要回答里出现下面这类精确结论：

• SAV、BAV、Shadbala 的数值比较
• Nakshatra、pada、Navamsha chart 落座
• Mercury、Venus 与 Sun 的距角
• Rahu、Ketu 对冲
• dasha 起止时间与窗口长度

就必须先调用本地工具或明确引用当前对话里已经算过的结果。对于原始命盘资料，默认优先运行：

python "scripts/chart_sanity_check.py" <chart-input.json-or-jhora.md>

这个脚本现在可以直接读取 JHora 导出的 markdown，不必先手工改写成 JSON。 如果某些图式表格在原始导出里无法稳定摊平，至少先完成主盘、Nakshatra、Navamsha chart、罗计轴、日水金距角和 dasha 的基础校验，再把矩阵类检查标成跳过或待补整理。

如果因为缺数据无法执行完整校验，要明确写出：

• 哪些项目已通过
• 哪些项目跳过
• 这会把哪类结论从高置信度降到中或低置信度

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）

第二阶段（完整拆盘）：

• 验证闸门通过后才执行
• 生成第二阶段 sections/（05 到 13）
• 更新 report.meta.json（status 标记为 complete）
• 生成 report.html

如果验证闸门未通过，报告停留在第一阶段，report.meta.json 的 status 标记为 pending_verification，不生成 report.html。

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 的解释
• 既往事件回看问题设计
• 最终整合与建议
• 时空盘里的地点语境与选择权衡

优先使用的辅助脚本：

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。

默认目录命名建议：

./命盘报告-<client-or-anon>-<yyyymmdd>/

目录契约：

report-folder/
  report.meta.json
  sections/
    01-基础盘面.md
    02-主题拆盘.md

report.meta.json 必填字段：

{
  "lang": "cn 或 en",
  "client_name": "字符串",
  "lagna": "字符串",
  "gender": "字符串",
  "status": "verifying | pending_verification | complete",
  "report_kind": "字符串",
  "source_system": "字符串",
  "notes": ["可选", "字符串数组"]
}

运行：

python "scripts/build_report_html.py" <report-folder>

脚本输出单个自包含 HTML，不负责 PDF。

完整研判分两阶段出，验证闸门见 总盘.md。第一阶段闭合后才允许生成第二阶段和 report.html。

# === 第一阶段：验证闭环 ===
# 生成后先让用户确认既往事件回看和出生时间稳定度。
# 验证闸门未通过时，报告到此为止，不要生成 HTML。

sections/
  01-基础盘面.md         # 上升、九大行星、当前 dasha、九分盘可用度
  02-一致性检查.md       # 已核 / 跳过 / 影响
  03-既往事件回看.md     # 提问模式或直评模式，逐条命中等级
  04-出生时间稳定度.md   # 稳定 / 中等 / 明显不稳

# === 第二阶段：完整拆盘 ===
# 验证闸门通过后才生成。出生时间不稳则本阶段降级。

sections/
  05-行星拆盘A.md        # Sun / Moon / Mars
  06-行星拆盘B.md        # Mercury / Jupiter / Venus
  07-行星拆盘C.md        # Saturn / Rahu / Ketu
  08-九分盘兑现复核.md
  09-宫位主轴.md
  10-人生主线上篇.md
  11-人生主线下篇.md
  12-时空盘专题.md       # 选配
  13-落地提醒.md

如果只是事业或婚姻专题，但内容已经达到完整报告规模，4 节就够：

sections/
  01-主题判断.md
  02-盘面抓手.md
  03-时间与场景.md
  04-使用提醒.md