吠陀命盘研判系统

这是一套中文总入口 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. 报告型请求强制交付完整产物

如果请求规模已经达到完整报告或大型专题：

• 聊天框里要有可直接阅读的完整结论
• 要生成 report.meta.json
• 要生成 sections/ 分节 markdown
• 要生成 report.html

不要只在聊天里说完就结束，也不要只留 markdown 不打包 HTML。

7. 输出必须先说现实判断，再给盘面抓手

每个主要小节都必须先把结论翻成普通人能懂的话，再上证据。表格、缩写和术语不能单独悬空出现。

共通准则

1. 不要向用户转播内部路由

不要说下面这类话：

• 我先加载总盘 reference
• 我切到事业专题
• 我按时空盘规则处理
• 我完成了内部检查步骤

用户只需要看到判断、提问、结论和限制，不需要看到 skill 内部导航。

2. 报告型请求默认交付整套产物

只要问题已经达到完整报告或大型专题的规模，默认交付物应当包括：

• 一份用户当场可读的聊天输出
• 一个带 report.meta.json 的报告目录
• sections/ 里的 markdown 分节文件
• 生成后的 report.html

不要等用户额外提醒“顺便生成 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 报告内容已经存在时，才使用脚本。

对于完整研判，默认在分析完成后主动生成整套报告目录与 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": "字符串",
  "report_kind": "字符串",
  "source_system": "字符串",
  "notes": ["可选", "字符串数组"]
}

运行：

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

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

完整研判建议使用下面这组分节：

sections/
  01-基础盘面.md
  02-既往事件回看.md
  03-行星拆盘A.md
  04-行星拆盘B.md
  05-行星拆盘C.md
  06-九分盘兑现复核.md
  07-宫位主轴.md
  08-人生主线上篇.md
  09-人生主线下篇.md
  10-时空盘专题.md
  11-落地提醒.md

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

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