What makes vedic-destiny notable?

1.3K downloads. Trust evidence available

How should vedic-destiny be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

vedic-destiny

吠陀命盘分析中文入口。用于完整命盘研判、命主盘 Rashi chart 与九分盘 Navamsha chart 联读、既往事件回看、出生时间稳定度判断、事业主题、婚姻主题、时间与场域联合分析，以及基于 Jagannatha Hora PDF、星盘截图或文本命盘数据的系统拆盘。当用户提到完整星盘、事业方向、婚姻问题... Skill: vedic-destiny Owner: seanding1998 Summary: 吠陀命盘分析中文入口。用于完整命盘研判、命主盘 Rashi chart 与九分盘 Navamsha chart 联读、既往事件回看、出生时间稳定度判断、事业主题、婚姻主题、时间与场域联合分析，以及基于 Jagannatha Hora PDF、星盘截图或文本命盘数据的系统拆盘。当用户提到完整星盘、事业方向、婚姻问题... Tags: latest:1.0.9 Version history: v1.0.9 | 2026-06-03T14:17:05.576Z | user v1.4.2 — JHora Ashtakavarga 精确边框解析 + 导出变体兼容 (2026-06-03) 变更动机新一批 JHora / MinerU 导出样本暴露出两类问题： Ashtakavarga 结构误判：紧凑表并不是普通 12×12 行列表，而

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.3k

Updated

Oct 10, 2026

Version

1.0.9

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.3K downloads reported by the source. Last updated 10/10/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.3K downloadsadoption · observed Oct 10, 2026
Latest release: 1.0.9release · observed Jun 3, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s172regbtzhpdev8rx39mqmjrx85qmrh:vedic-destiny

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-seanding1998-vedic-destiny/snapshot"

Documentation

CLAWHUB

149,789 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---

name: vedic-chart-analysis-zh

description: 吠陀命盘分析中文入口。用于完整命盘研判、命主盘 Rashi chart 与九分盘 Navamsha chart 联读、既往事件回看、出生时间稳定度判断、事业主题、婚姻主题、时间与场域联合分析，以及基于 Jagannatha Hora PDF、星盘截图或文本命盘数据的系统拆盘。当用户提到完整星盘、事业方向、婚姻问题、关系窗口、桃花时间、迁移地点、城市比较、时间窗口，或吠陀占星、Jyotish、Jaimini、Parashari 相关请求时触发。

---

# 吠陀命盘研判系统

这是一套中文总入口 skill。先根据用户问题主动匹配最合适的 reference，再读取分析——不列菜单让用户自己选。

## 执行速览（AI 拿到 skill 后的阅读顺序）

1. **分层推断规则**（下节）→ 绝对优先，覆盖所有 reference
2. **执行硬约束** → 不可降级的底线
3. **主动路由** → 匹配 reference，匹配后**必须读取对应 reference 全文**
4. **信号分级与篇幅控制** → 决定每颗行星写多深
5. **输出风格硬约束** → 影响说话方式但不改变框架

**闸门确认提示是唯一允许向用户暴露内部验证状态的特例**——其余场合遵守"不向用户转播内部路由"。

## 输出风格硬约束（优先级最高，覆盖所有 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）

星盘提供的是**结构信号**——某个时间段内，哪些人生领域被激活、以及激活的强度和方向。同一个结构信号，在不同的人生背景下会兑现为不同具体事件。这不是占星系统的缺陷，而是结构信号本身的特性：它指示的是「领域 + 强度」，而非单一具体事件。

人类占星师从来不会蒙住眼睛看盘——背景信息是将结构信号翻译为具体推断的必要输入，而非污染。真正需要隔离的只有一件事：**用已知结果倒推盘面含义**。

本规则将分析拆为四个独立层。分层的目的不是隔离信息，而是隔离污染——让「用背景细化推断」成为合法的分析动作，同时确保「用结果编造盘面解读」无处藏身。

### 层 0：星盘结构信号（客观不变）

**输入**：仅来自命盘数据——Dasha 周期、宫位激活、行星状态、Yoga、Shadbala/SAV/BAV、分盘复核。

**输出**：
- 信号类型（关系 / 事业 / 财富 / 健康 / 迁移 / 学习 / 家庭 / 其他）
- 信号强度（强 / 中 / 弱，基于至少两类独立证据交叉验证）
- 可能兑现方向（复数——即使某个方向看起来再明显，也必须列出至少 2 个可能方向）

**硬约束**：
- **禁止反向推导**：不得从用户已告知的结果反推信号含义。8 宫 SAV=38 →「深度转化能力强」，可能方向为研究/心理/金融/危机干预——先列出方向，再对照用户经历；不能先知道用户方向再反过来锁定解读。
- **禁止经历=天赋**：职业方向只能基于 L10 + AmK + 格局 + D10 + 强星。用户经历过 X ≠ 适合做与 X 相关的工作。
- **禁止情绪定调**：用户自述的人生基调（顺遂/坎坷）不影响格局评估。家境普通的人也能有顶级 Raja Yoga。

### 层 1：背景事实卡（用户已知，结构化收集）

**收集时机**：在第一阶段开始分析前，按需收集。只收集当前分析方向所需领域的信息——用户问事业不收集感情，问迁移不收集健康。

**收集内容**：

| 领域 | 收集项 | 用途 |
|------|--------|------|
| 通用 | 性别、年龄区间、出生时间精度 | 基础约束 |
| 感情 | 当前状态（已婚/恋爱/单身/离异）、关键关系是否稳定 | 缩小关系信号的兑现形式范围 |
| 事业 | 当前阶段（学生/在职/创业/待业/退休）、行业方向 | 缩小事业信号的兑现形式范围 |
| 迁移 | 当前居住地、异地关系强弱、是否有搬迁动力 | 缩小迁移信号的兑现形式范围 |
| 健康 | 已知重大健康问题 | 缩小健康信号的兑现形式范围 |

**硬约束**：
- **「事实」可以进入层 1**——可被外部验证的客观信息（婚姻状态、职业阶段、居住城市）是合法推断输入
- **「自述」不能进入层 1**——「我性格内向」「我运气不好」「我一直很努力」是主观判断，需要被盘面验证，不能反过来作为推断的前提
- **缺失信息不做假设**——背景事实卡中空白的项目标注为「信息不全」，对应领域的推断精度相应降级
- **层 1 信息只用于缩小可能方向，不用于否定层 0 信号**——即使背景事实看起来与星盘信号方向不一致，也不能因此忽视信号本身

### 层 2：联合推断（信号 × 背景 → 具体结论）

**核心理念**：同样的星盘信号，在不同背景下指向不同具体事件，但核心信号类型不变。层 2 的任务是将层 0 的复数可能方向，通过层 1 的约束缩小为具体的概率排序。

**输出格式**（每个涉及具体人生事件的推断必须覆盖以下结构）：

```text
推断：[具体结论]
├── 星盘信号：[哪段 Dasha / 哪些宫位激活 / 哪些行星参与 / 信号类型与强度]
├── 背景输入：[引用了背景事实卡的哪几条；若某领域信息不全，标注具体缺失项]
├── 推理链：[信号 + 背景 → 结论的完整逻辑步骤]
├── 纯星盘版本：[如果不考虑背景，同样的信号可能对应哪些方向（必须列出至少 2 个）]
├── 边界条件：[什么情况下这个推断不成立或反转]
└── 反事实检查：[如果背景事实卡中某条信息不同，结论会怎样变化]
```

**硬约束**：
- **相同星盘数据 + 相同背景事实 →

_meta.json

{
  "ownerId": "kn767kdw00a1yqfq7r0wfe49tn823tz6",
  "slug": "vedic-destiny",
  "version": "1.0.9",
  "publishedAt": 1780496225576
}

references/事业.md

# 事业主题流程

如果需要共享术语、读盘抓手或冲突裁定口径，读取 `术语框架.md`。

本专题遵循 SKILL.md「分层推断规则」（层 0/1/2/3）。事件回看使用双层口径：旧标签（高贴合/有限贴合/失配）+ 诊断维度（信号命中/推断合理性/信息完备度）。

## 适用场景

当用户明确问的是下面这些问题时，使用这个流程：

- 事业方向
- 工作适配度
- 创业还是任职
- 事业上升路径
- 变现模型
- 职场风险
- 事业时机

不要把它当完整总盘，也不要用它回答婚姻主题。

## 需要的输入

优先接受其中一种：

- 当前对话里已有总盘摘要
- Jagannatha Hora PDF
- JHora 导出的 markdown 报告
- 星盘截图
- 文本命盘数据

事业判断最关键的字段：

- 上升
- 命主盘（Rashi chart）里的 10 宫与 10 宫主
- Amatyakaraka
- 2 宫、6 宫、11 宫因素
- 需要看平台、岗位层级、汇报链或组织摩擦时的 十分盘
- 九分盘（Navamsha chart）里与事业兑现相关的落点
- 当前与未来一段时间的大运

如果当前对话里已经有可用的总盘摘要，直接复用，不要重扫原始资料。

## 计算纪律

如果面对的是原始命盘数字，而不是当前对话里已经检查过的总盘结果，下面这些地方优先调用本地 Python：

- dasha 的日期区间运算
- 和事业、金钱宫位有关的 SAV、BAV 阈值判断
- 关键事业星的 Shadbala 排序
- 需要显性引用时的九分盘（Navamsha chart）度数映射
- 需要展开岗位结构时的 十分盘基础落点整理

## 工作流

### 1. 先判断是复用总盘，还是直接做专题

只分两种：

- 已有总盘支撑：当前对话里已经有完整或足够的总盘结论
- 单独专题：没有总盘，只提取事业专题需要的最小基础

如果是单独专题，要明确告诉用户：这份结果的置信度低于基于总盘的事业分析。

### 2. 先搭事业主线

优先看这些结构：

- 10 宫
- 10 宫主
- 10 宫内行星
- 与 6、7、9、11 宫的强连接
- Amatyakaraka

先把盘面翻译成简单的工作模式，再进细节：

- 权威建设型
- 市场对接型
- 服务与系统型
- 技术手艺型
- 研究、危机或隐藏领域型

### 3. 用八镜框架看它怎么落地

事业主题里最常用的镜面是：

- 主题归属：它在事业系统里到底负责什么
- 运行状态：这股力量是顺、慢、绕，还是有明显损耗
- 资源水位：这条事业线能拿到多少结构性支持
- 落点环境：工作发生在顺风环境还是高摩擦地带
- 兑现通道：结果是直接变现、靠口碑累积，还是先曲折后显形
- 外力牵引：谁在帮助、压制或放大这条事业线
- 熟成节律：它是早显、晚显，还是需要时间堆出层次

### 4. 检查赚钱方式和工作手感

把问题落到现实：

- 这张盘更适合靠权威、手艺、交易、咨询、运营，还是危机处理赚钱
- 更适合体制、自由职业、创业，还是混合路径
- 更强的是曝光、执行、研究、领导，还是后端杠杆

用 2 宫和 11 宫看钱从哪来。用 6 宫和土星看能不能长期扛住日常流程。

### 5. 用九分盘（Navamsha chart）做兑现复核

九分盘（Navamsha chart）的任务，是复核命主盘里的事业承诺成熟后还能不能站住。

用它回答：

- 表面上的事业承诺稳不稳
- 成熟后更像专精、管理、公众可见度，还是专家手艺
- 去掉头衔后，真正有意义的工作风格是什么

### 5.5 需要判断平台、岗位和管理关系时，用 十分盘 做第二层复核

下面这些问题，不要只靠 命主盘 和 九分盘 硬扛：

- 大平台还是小团队更适合
- 岗位是前台、后台、桥接层还是研究层
- 汇报关系、管理压力、组织结构摩擦怎么来
- 为什么会出现边缘化、调岗、上升受阻

十分盘在这里的作用，是补岗位生态和组织结构，不是负责替你命名具体公司。

### 5.6 遇到“人祸”或“病名”时，先收紧结论

事业专题可以判断：

- 组织结构在伤人
- 汇报链或管理层带来高摩擦
- 岗位环境正在消耗身体
- 某段时间工作与健康互相拖累

事业专题不该直接冒进到：

- 某一个人故意害你
- 某一个具体医学诊断就是盘里直接写着的结果

如果用户追问极端事故、病痛或具体病名，要回到总盘流程，由总盘决定是否追加更细的分盘或只保留结构层判断。

### 6. 给时间窗口

优先用 dasha 定时。只有当 transit 真能显著缩小时窗时，再加进来。

对每个窗口都要说清楚：

- 什么机会在打开
- 什么样的努力更有回报
- 风险或隐藏代价是什么

如果用户已经给了完整职业时间线，就把这些窗口逐条对照现实节点，显性标出 `高贴合 / 有限贴合 / 失配`，不要只给抽象走势。

### 7. 需要地点或更细时机时，转入窗口与场域专题

当用户继续问：

- 去哪个城市发展更顺
- 同一个岗位在不同地点差别大不大
- 某个季度里哪一段最值得推进
- 合作、跳槽、搬迁和事业窗口怎么叠加

就转入 `窗口与场域.md`。

## 最低必答清单

事业专题至少要回答完下面这些问题，少一项就容易变松：

- 事业主线是什么：10 宫、10 宫主、10 宫内行星、Amatyakaraka 怎么定调
- 工作形态更像什么：任职、自由职业、创业，还是混合路径
- 钱从哪里来：2 宫、6 宫、11 宫与事业线怎么接通
- 真正的工作手感是什么：更偏领导、执行、交易、研究、服务，还是后端系统
- 九分盘（Navamsha chart）是否支持兑现：成熟后更稳，还是代价更高
- 需要时 十分盘 是否支持岗位生态和平台判断
- 时间窗口在哪：至少给出明确年份或年月区间，并写出触发逻辑
- 主要风险是什么：资源不足、环境磨损、节奏偏晚，还是方向选错

如果用户明确问“创业还是任职”，必须显性比较两条路径，不要只给一个模糊偏好。
如果用户给的是既往职业时间线，至少逐条覆盖所有重大节点，不要只挑好解释的节点。

## 输出契约

每个主要小节都用同一结构：

### 1. 现实判断

先说这张盘真正适合什么工作，用普通人的话讲清楚。

### 2. 盘面抓手

然后再上证据：

- 命主盘（Rashi chart）里的 10 宫与 10 宫主
- Amatyakaraka
- 相关 yogas
- dasha
- 九分盘（Navamsha chart）
- 真正有用的八镜镜面

### 3. 使用提醒

每节结尾落在下面这些里：

- 应该顺着什么去放大
- 哪种幻想该停止浪漫化
- 哪个风险要提前处理
- 哪个结论只是暂定，因为数据还不够

references/婚姻.md

# 婚姻主题流程

如果需要共享术语、读盘抓手或冲突裁定口径，读取 `术语框架.md`。

本专题遵循 SKILL.md「分层推断规则」（层 0/1/2/3）。事件回看使用双层口径：旧标签（高贴合/有限贴合/失配）+ 诊断维度（信号命中/推断合理性/信息完备度）。

## 适用场景

当用户明确问的是下面这些问题时，使用这个流程：

- 婚姻走向
- 恋爱模式
- 关系风险
- 桃花窗口
- 婚期与承诺窗口
- 伴侣画像
- 关系能不能落地

不要把它当完整总盘，也不要用它回答事业规划。

## 需要的输入

优先接受其中一种：

- 当前对话里已有总盘摘要
- Jagannatha Hora PDF
- JHora 导出的 markdown 报告
- 星盘截图
- 文本命盘数据

婚姻判断最关键的字段：

- 上升
- 5 宫与 5 宫主
- 7 宫与 7 宫主
- Venus
- 九分盘（Navamsha chart）落点
- Vimshottari dasha 时间线
- DK、PK、UL、AL

如果当前对话里已经有可用的总盘摘要，直接复用，不要重扫原始资料。

## 计算纪律

如果面对的是原始命盘数字，而不是当前对话里已经检查过的总盘结果，下面这些地方优先调用本地 Python：

- dasha 的日期区间运算
- 和 5 宫、7 宫、11 宫兑现能力有关的 SAV、BAV 阈值判断
- Venus、5 宫主、7 宫主等关键关系星的 Shadbala 排序
- 需要显性引用时的九分盘（Navamsha chart）度数映射

## 工作流

### 1. 先判断是复用总盘，还是直接做专题

只分两种：

- 已有总盘支撑：当前对话里已经有完整或足够的总盘结论
- 单独专题：没有总盘，只提取婚姻专题需要的最小基础

如果是单独专题，要明确告诉用户：这份结果的置信度低于基于总盘的婚姻分析。

### 2. 先用现实体验描述关系模式

从真实体验出发，不要从黑话出发：

- 这个人通常怎么建立连接
- 会被什么吸引
- 哪种伴侣互动会反复出现
- 主要摩擦点在哪

然后再用盘面去支撑：

- 5 宫和 5 宫主看恋爱风格
- 7 宫和 7 宫主看伴侣结构
- Venus 看吸引力、审美和关系润滑度
- 九分盘（Navamsha chart）看深度、耐久度和成熟后的质量

### 3. 用八镜框架判断关系能量怎么落地

婚姻主题里最常用的镜面是：

- 主题归属：这颗星在关系系统里负责什么
- 运行状态：它是稳定、逆行、受损，还是带着明显绕路感
- 资源水位：这段关系有没有足够条件持续下去
- 落点环境：关系能量落在轻松区还是高摩擦区
- 兑现通道：吸引、承诺、稳定与收尾是怎样出现的
- 外力牵引：谁在帮助、压迫、干扰这段关系模式
- 熟成节律：这类关系是早显、晚显，还是随着年龄才变稳

### 4. 把“关系模式”和“时间窗口”分开

不要把下面这些混成一句模糊的话：

- 恋爱风格
- 婚姻稳定性
- 欲望高峰
- 真正的承诺窗口

时间上优先用 dasha。只有 transit 能明显缩小窗口时，再加进来。

### 5. 用九分盘（Navamsha chart）判断质量和持久度

九分盘（Navamsha chart）主要回答：

- 这张盘更容易吸引滋养型还是消耗型关系
- 表面化学反应和内在兼容度是否一致
- 随着成熟，关系风格会变稳还是变复杂

### 6. 传统性别指标要谨慎处理

如果解读依赖传统 spouse-karaka 规则，而用户自己的关系框架不清楚：

- 必要时短问一句
- 或者先说明自己的假设，再继续

拿不准时，宁可回到盘面本身，也不要替用户乱猜。

### 7. 需要地点或更细时机时，转入窗口与场域专题

当用户继续问：

- 异地关系在哪个地方更容易落地
- 哪个时间窗更适合确定关系
- 婚期、搬迁、合作和感情进展如何叠加
- 不同城市是否会放大或缓和关系摩擦

就转入 `窗口与场域.md`。

## 最低必答清单

婚姻或关系专题至少要回答完下面这些问题：

- 关系模式是什么：5 宫、5 宫主、7 宫、7 宫主和 Venus 分别在讲什么
- 伴侣结构是什么：更容易吸引哪类人，关系怎么落地
- 关系质量如何：九分盘（Navamsha chart）是加分、耗损，还是复杂化
- 时间窗口在哪：至少给出明确年份或年月区间，并写出触发逻辑
- 风险点是什么：延迟、消耗、反复、异地、承诺成本，还是边界问题
- 用户怎么用：什么样的关系值得推进，什么样的关系该及时止损

如果用户问婚期、正缘或承诺窗口，不能只说“会有机会”或“偏晚”。必须给出具体时间范围，并说明那段时间更像恋爱、确定关系，还是进入婚姻安排。

## 输出契约

每个主要小节都用同一结构：

### 1. 现实判断

先说这种关系模式在普通生活里到底是什么感觉。

### 2. 盘面抓手

然后再上证据：

- 5 宫
- 7 宫
- Venus
- 九分盘（Navamsha chart）
- dasha
- DK、PK、UL、AL
- 真正有用的八镜镜面

### 3. 使用提醒

每节结尾落在下面这些里：

- 什么样的关系应该追，什么样的关系应该避
- 怎样更理性地使用时间窗口
- 还存在哪些不确定性

references/总盘.md

# 总盘研判流程

如果需要共享术语、读盘抓手或冲突裁定口径，读取 `术语框架.md`。

## 适用场景

当用户要的是整张盘的系统拆盘，而不是单一专题时，使用这个流程。

典型请求：

- 完整命盘研判
- 本命总览
- 命主盘（Rashi chart）与九分盘（Navamsha chart）联读
- 既往事件回看
- 出生时间稳定度判断
- 基于 Jagannatha Hora PDF 或截图做基础命盘拆盘

如果用户只想看事业、婚姻，或地点与时间窗口的专项问题，不要走完整总盘，改读 `事业.md`、`婚姻.md` 或 `窗口与场域.md`。

## 需要的输入

接受以下任一资料：

- Jagannatha Hora 导出的 PDF
- JHora 导出的 markdown 报告
- 星盘截图
- 文本形式的行星位置
- 当前对话里已经存在的总盘摘要

能提取到的话，优先确认这些字段：

- 上升星座与度数
- 九大行星的星座、宫位、度数、逆行状态
- Nakshatra 和 pada
- 九分盘（Navamsha chart）落点与上升
- Vimshottari dasha 时间线
- Shadbala、SAV、BAV
- Chara karaka

不要因为某张可选表缺失就卡死整份解读。只在关键字段缺失时追问。

## 计算纪律

只要原始资料里有数字，就把可确定的检查交给本地 Python。

必须工具化的项目：

- SAV、BAV 算术检查
- 根据度数反推 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，优先直接把原文件送进脚本，不要先手工转述一遍。
如果 SAV 或 BAV 所在的图式表格无法稳定结构化，就先保住基础检查，把矩阵类检查标成跳过或待补整理。

如果只有部分数字，就只检查已有部分，并在结论里明确哪些项目被跳过。

## 工作流

### 1. 先整理基础盘面

在解释前先建立一个干净的底稿：

- 资料来源和完整度
- 上升
- 行星落点
- 当前所处的大运阶段
- 九分盘（Navamsha chart）数据
- 可用的强弱表

如果 OCR 或截图识别有歧义，要明确指出哪一个值不确定。

### 2. 做一致性检查

基础检查始终执行：

- 九大行星是否齐全且不重复
- Rahu 与 Ketu 是否形成对冲轴
- Mercury 与 Venus 是否和 Sun 保持合理距角
- 在数据足够时，Nakshatra 与 pada 是否和度数一致
- 在数据足够时，九分盘（Navamsha chart）映射是否和主盘度数一致
- dasha 序列是否内部自洽

SAV/BAV 检查是**必须尝试、失败才跳过**的项目，不是可选的"加分项"：

- 只要原始资料包含任何 SAV/BAV 数字（PDF 截图、JHora 导出的表格、用户手动输入），就必须提取并完成三项校验
- 如果在 PDF 或 markdown 中能肉眼辨认出数字，优先手动列出 12 宫 SAV 值，再做算术校验
- 只有经过尝试后表格确实无法结构化（如 OCR 输出乱码、截图模糊不可辨认），才标记为"跳过"
- 跳过时必须在回执中说明具体原因（"截图分辨率不足"而非笼统的"图式表格未能自动化解析"）

**强矩阵检查**（SAV/BAV 数据可用时）：

- 12 宫 SAV 总和是否为 337（详见 `术语框架.md` SAV/BAV 量化规范）
- 每颗星的 BAV 行总和是否符合固定常数
- 每个星座的 BAV 列和是否等于对应 SAV
- 行列同时出错时，用交叉定位找可能的 OCR 或录入错误

**降级版**（SAV/BAV 经尝试确实无法提取时）：
- 保留所有基础检查
- 明确写 "SAV/BAV ⏭️ 跳过（原因：...），宫位级量化判断降级为 🟠 中"
- 后续的"资源水位"和"落点环境"镜面使用 Shadbala 和 Vimsopaka 作为替代数据源

每次一致性检查后，**必须输出以下编号校验表**。这是硬性输出格式，缺任何一行都视为校验不完整：

```
=== 一致性检查（必须逐项给出结果，不可省略任何一行）===

C1  行星完整性   : ✅/❌  [说明]
C2  Nakshatra映射: ✅/❌  [说明]
C3  D9映射       : ✅/❌  [说明]
C4  日水距角     : ✅/❌  [度数+判断]
C5  日金距角     : ✅/❌  [度数+判断]
C6  罗计对冲     : ✅/❌  [说明]
C7  逆行合法性   : ✅/❌  [说明]
C8  Dasha序列    : ✅/❌  [说明]
C9  SAV总和=337  : ✅/❌/⏭️  [数值+说明；如跳过必须写明具体原因]
C10 BAV行常量   : ✅/❌/⏭️  [7/7几颗匹配；如跳过必须写明具体原因]
C11 BAV列→SAV   : ✅/❌/⏭️  [12/12几宫匹配；如跳过必须写明具体原因]

校验等级：🔴极高(11/11通过) / 🟡高(C1-C8全过,C9-C11跳过) / 🟠中(有硬冲突)
```

**C9-C11 的硬规则**：
- 只要命盘资料中包含任何 SAV/BAV 数字（无论格式），就必须逐项给出结果
- 脚本解析不了 → 手动从 PDF/截图/HTML 中读取 12 个 SAV 值，做加法验证
- 确实无法提取（OCR 乱码、截图模糊不可辨）→ 标记为 ⏭️ 并写明具体原因
- 禁止出现"SAV/BAV 跳过"而无任何数字输出——要么给出具体数值和校验结果，要么给出具体跳过原因

校验等级影响后续分析的置信度标注：
- 🔴极高：所有宫位级判断正常使用 SAV 阈值
- 🟡高：宫位级判断改用 Bhava Bala + Shadbala 替代，"资源水位"和"落点环境"镜面降级

### C1-C11 计算公式（AI 自算用）

以下公式用于 AI 从原始度数数据自行计算校验值，而非仅检查 JHora 已有标注。**OCR 场景下标注可能读错但度数是准的——AI 必须会自己算。**

**C2 Nakshatra 与 Pada 计算**：
```
绝对经度 = 星座序号 × 30 + 度数    （白羊=0, 金牛=1, ..., 双鱼=11）
Nakshatra编号 = floor(绝对经度 / 13.3333) + 1
Pada编号 = floor((绝对经度 % 13.3333) / 3.3333) + 1
```
计算结果与 JHora 标注对比。不匹配 → ❌，列出不一致的星体。

**C3 D9 映射计算**：

Github ReposUpdated 1d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.