Jyotisha/references/ai-reading-workflow-prompt.md

AI解盘工作流Prompt工程（AI Reading Workflow）

适用场景：AI收到出生信息、PDF星盘或文字星盘后，如何一步步执行完整的解盘+推运分析 版本：v5.2.0 | 更新日期：2026-07-02 来源标签: 【工具/模板】 — AI解盘执行引擎工作流 优先级：⭐⭐⭐⭐⭐（AI解盘质量的决定性文件） 定位：本文件是AI解盘的执行引擎，将Skill中所有参考资料串联成可执行的工作流 v3.0重大变更：三条入口路径明确分流，引擎全自动计算无需用户逐模块触发 v4.0重大变更：Step 0.5 Karaka系统自动识别（解决DK摇摆问题）、预测输出强制[A/B/C]标注、统一精度边界声明、来源标签体系引用 v5.0重大变更：强制外部验证门控（MEVG）——新增核心原则"不凭记忆"、三个门控步骤（Step 3.11/4.10/5.5）嵌入工作流、与"不跳步"同级强制 v5.1重大变更：事件判定骨架接入主工作流——新增 Route -> Evidence Ledger -> Adjudication -> Output Contract 四段式事件裁决层，并引入 marriage 专用 adjudicator。 v5.2重大变更：用户追问校准协议接入主工作流——把用户的质询流程抽象为盲推隔离、具体事件选项、证据先行、相似案例分层对标、可迁移边界与反例处理。

---

⚠️ 核心原则

1. 不跳步：每个阶段必须完成后才能进入下一阶段
2. 不猜测：数据缺失时标注"缺失"，不编造数据
3. 不锚定：先输出星盘推导，再等用户反馈，不先知道用户生活再"找依据"
4. 必标注：每个结论标注来源系统、置信度、精度边界
5. 全自动优先：引擎有能力自动完成的计算，绝不要求用户手动触发
6. 尊重用户数据：用户提供的PDF/文字星盘数据即为事实来源，优先使用而非重新计算
7. 🔴🔴🔴 不凭记忆（v5.0 新增，与"不跳步"同级）：所有解读结论必须经过外部权威来源（web_search）验证，禁止仅凭 AI 训练记忆输出。违反此原则的解读判定为无效。纯数值计算（引擎输出、SAV 点数、Dasha 时间线）可豁免。
   • ❌ 仅凭记忆说"Venus 在 Taurus 10 宫是 Malavya Yoga"
   • ✅ 先 web_search 确认形成条件 + 引用来源
   • → 完整协议：references/mandatory-verification-gate-protocol.md
8. 追问即校准（v5.2 新增）：用户质疑"你用了哪些技法""哪里遗漏""真实案例是否相似""为什么这样判断"时，必须把追问视为工作流校准信号，而不是普通解释请求；需要回到证据层、相似案例层和置信度边界重新裁决。

---

🔴🔴🔴 用户追问校准与相似案例对标协议（v5.2）

目的：把高质量用户追问转化为解盘流程约束，避免泛泛描述、记忆联想、单案例套用或把未闭环内容伪装成完整判断。

0.1 触发条件

只要用户出现以下任一追问，必须启动本协议：

• "不要用我之前说过的反馈"，"重新盲推"，"只用出生参数和当前项目数据"
• "你是不是遗漏了技法"，"这是不是顶级印度占星师逻辑"
• "列具体时间和事件让我选择"，"不要问概念问题"
• "相似真实案例是什么"，"这个案例到底和我哪里像"
• "为什么这样判断"，"哪些地方需要修正"
• "这个机会具体是什么"，"事件节点是什么"

0.2 盲推隔离模式

当用户要求盲推或禁用既往反馈时：

1. 禁止调用用户此前提供的人生事件、校时反馈、对错判断、职业身份、关系状态、偏好描述。
2. 只允许使用出生参数、当前项目现跑出的原始数据、已分级 source pack、MEVG 外部证据和真实案例校准层。
3. 输出必须声明：
   • User Feedback Isolation: used
   • 使用了哪些数据源
   • 明确排除了哪些会话反馈类型
4. 若系统无法保证隔离，必须写 blocked，不得输出伪盲推。

0.3 具体事件选项协议

校时、应期、转型、婚恋、事业机会、财富事件不得只问用户"你感觉像不像"或"有没有变化"。

必须改成可选择的具体事件格式：

| 时间窗口 | 事件选项 | 技术来源 | 用途 |
|---|---|---|---|
| YYYY-MM-DD 到 YYYY-MM-DD | A. 搬家/换住处；B. 工作启动；C. 关系断联 | Dasha + Transit + Varga | 校验/预测/置信度调整 |

要求：

• 每个窗口至少给出 2-4 个可判断事件选项。
• 事件必须落到现实层面：入职、搬家、签约、付款、断联、公开、培训班更换、项目暂停、住处/通勤变化等。
• 不得只给心理状态、抽象主题或"能量变化"。
• 用户选择后，只能用于后续校准；不能倒灌污染"盲推模式"。

0.4 证据先行，结论最后

高严谨解盘必须按以下顺序组织，不得先下结论再找理由：

1. 原始 D1 + 三重参考引擎边界
2. 功能性吉凶星
3. 行星力量：Shadbala / Vimsopaka / Avastha
4. Yoga / Dosha
5. Jaimini：AK / AmK / DK / UL / A10 / Argala
6. 分盘：按问题域调取 D9 / D10 / D2 / D4 / D7 / D12 / D20 / D24 / D30 / D60
7. 多大运：Vimshottari / Narayana / Yogini / Kalachakra / Jaimini
8. Transit + VedAstro range scan
9. Tajika 年运
10. MEVG + 真实案例校准
11. 最后才输出事业、财富、婚恋、健康、迁移等结论

0.5 相似案例分层对标

真实案例不得只因为"同主题"就拿来类比。必须给出相似层级：

层级	含义	置信度作用
L0 同主题	都是婚恋/事业/财富案例，但星盘和运势未证明相似	只能作背景，不得推断
L1 D1 结构相似	Lagna、关键宫主、功能吉凶、行星落宫或尊严有相似点	可作弱参考
L2 分盘相似	D9/D10/D2 等对应分盘支持相同主题	可提高主题置信度
L3 Dasha 功能相似	不是同一颗星也可以，但必须功能等价，如旧系统瓦解、异地网络、长期责任启动	可作阶段类比
L4 事件机制相似	真实案例中发生了可验证的节点，如离开旧组织、获得项目、迁移、收入来源变化	可校准事件形态
L5 物质支撑相似	收入来源、平台、组织资源、合作关系、家庭/伴侣支持等现实条件相似	才能推断"生活会如何变好"

输出案例时必须说明：

• 这个案例和命主在哪些层相似
• 哪些层不相似
• 哪些内容可迁移
• 哪些内容不可迁移
• 因不相似而降低了哪部分置信度

0.6 反例与用户排除案例处理

• 反例不能静默删除；必须标注它为什么是反例、它压低了哪个判断。
• 若用户明确说"不要考虑某个案例"，该案例标记为 user-excluded，不进入主校准，但保留为审计记录。
• 正例不能单独决定结论；必须经过分盘、大运、事件机制和 MEVG 仲裁。
• 单一名人案例只能校准"事件机制"，不得复制成用户个人命运模板。

0.7 转型与机会的现实机制检查

当判断事业转型、婚恋落实、财富改善或人生阶段转折时，必须追问并输出"机会如何落地"，至少拆成：

1. 旧系统断裂：离开组织、旧项目停摆、关系断联、身份失效。
2. 过渡平台：课程、讲座、试稿、短项目、朋友介绍、异地网络、线上发布。
3. 资源入口：谁提供机会，平台是什么，收入从哪里来。
4. 责任测试：合同、制作、交付、管理、公开评价、长期责任。
5. 结果显化：付款、职位、署名、公开关系、稳定合作、可重复收入。

若无法证明"资源入口"或"收入来源"，不得说"情况会变好"，只能说"有转向信号但物质改善待验证"。

0.8 时间节点输出粒度

所有预测窗口必须拆成不同层级：

节点	含义
Contact	初次接触、消息、介绍、线索出现
Activation	开始行动、沟通密集、试稿/面试/约见
Confirmation	确认合作、确认关系、确认资源
Manifestation	公开、到账、签约、入职、搬迁完成
Responsibility Test	压力测试、延期、责任加重、现实磨合

禁止把这些全部混成一句"会有机会"或"会确定关系"。

---

🔴🔴🔴 性别前置检查（必读！每次解盘前必须确认！）

⚠️ 这是从多次用户纠正中提炼的硬性规则，违反会导致全盘分析方向错误！

规则1：性别决定征象星体系

分析配偶/婚姻/感情之前，必须先确认命主性别！

性别	日/夜盘	丈夫征象星	妻子征象星
女性	日盘（白天出生）	木星 Jupiter（入Sect，权重最高）+ 火星 Mars（出Sect，次之）	—
女性	夜盘（夜晚出生）	火星 Mars（入Sect，权重升高）+ 木星 Jupiter（出Sect，权重降低）	—
男性	日盘	—	金星 Venus（出Sect）+ 月亮 Moon
男性	夜盘	—	金星 Venus（入Sect，权重最高）+ 月亮 Moon

规则2：DK系统是性别中立的

• DK（Darakaraka）= 度数最低的行星，不分男女
• 但DK必须与上述性别征象星交叉验证，不能替代
• 禁止："女命只看木星" 或 "男命只看金星" 的单一判据

规则3：具体纠正记录

以下错误曾反复发生，务必避免：

• ❌ 错误：分析女性命盘时用"她"描述配偶（配偶应为"他"）
• ❌ 错误：女性日盘用Venus作为丈夫征象星（应用Jupiter+Mars）
• ❌ 错误：忽略昼夜区分对征象星权重的影响
• ❌ 错误：只看DK不看传统征象星，或只看传统征象星不看DK
• ✅ 正确：多层交叉确认（DK + 7宫主 + 天然征象 + 昼夜区分）

规则4：案例分析示例

隐私保护：本节曾包含真实用户个人星盘或人生事件资料，已移除。请使用公开名人案例、虚构 smoke case，或仅在当前会话中处理用户主动提供的数据；不得写入 skill 文件或公开仓库。

🔴🔴🔴 度数精确判断 & 象不单论（必读！）

⚠️ 用户多次纠正的核心规则——违反会导致结论严重失真！

规则5：庙旺落陷必须看精确度数，禁止仅凭落宫武断判断

隐私保护：本节曾包含真实用户个人星盘或人生事件资料，已移除。请使用公开名人案例、虚构 smoke case，或仅在当前会话中处理用户主动提供的数据；不得写入 skill 文件或公开仓库。

规则6：象不单论——任何单一配置不能单独下结论

❌ 错误做法：

• "DK落12宫 = 地下关系" → 直接判死刑
• "Mars落陷 = 配偶不好" → 单一负面标签
• "7宫主Saturn = 婚姻延迟" → 不看其他条件

✅ 正确做法：每个结论必须至少2个系统交叉验证

单一配置	不能单独说	必须结合
DK落12宫	"关系必然隐藏"	12宫主状态、7宫主、过境触发、Dasha
Mars落陷	"配偶不好/婚姻差"	Neecha Bhanga是否成立、D9状态、Yogakaraka身份、Vargottama
Saturn 7宫主	"婚姻延迟"	Saturn入庙/受克？UL位置？D9 7宫？
任何落陷星	"这颗星是坏的"	深陷点距离、落陷取消、功能角色（Yogakaraka？）

规则7：分析输出格式要求

分析任何行星或配置时，必须包含以下信息才算完整：

## [行星名]@[星座] [度数]° — 综合评定

| 维度 | 结果 |
|------|------|
| 落宫 | X宫 |
| 基础尊严 | 入庙/入旺/本垣/友星/中立/敌星/落陷 |
| 精确度数 | X°XX'（距深陷/入旺点XX°） |
| 渐变评定 | 极深/深/中等/浅 |
| Avastha生命阶段 | 婴儿/青年/成年/老年/衰退 |
| D9 Navamsa状态 | [星座]/[尊严] |
| 功能角色 | 宫主星(X,Y宫) / Yogakaraka / AK/DK等 |
| 特殊条件 | Neecha Bhanga/燃烧/逆行/Vargottama/Pushkara |
| **综合评定** | ⭐ X/5 — [一句话总结] |

---

🔴🔴🔴 Karaka系统自动识别（必读！每次解盘前必须确认！）

⚠️ DK身份反复出错的根因——不同软件/学派使用不同的Karaka系统！

规则8：识别Karaka系统来源

在进入任何分析之前（路径A/B/C完成后、阶段二之前），必须强制执行以下检查：

Step 0.5: Karaka 系统识别与声明

8.1 三大主流Karaka系统对照表

系统	来源	行星数	DK(Darakaraka)定义	特征
K.N. Rao 7星制	K.N. Rao 学派	7颗（排除Rahu）	度数最低的行星	最广泛使用的传统体系
JH 8-Karaka制	JHorosoft / JHoroWatch 软件	8颗（含Rahu，含PiK）	第7低度数行星（含PiK排序）	PDF标记AK/AmK/BK/MK/PiK/PK/GK/DK
Sanjay Rath 8星制	Sanjay Rath 学派	8颗（含Rahu，无PiK）	排除Mars后的最低度数	与7星制的唯一差异：DK可能≠Mars

8.2 自动识别规则

数据来源	识别信号	应使用系统	DK提取方式
PDF含PiK标记	PDF中明确列出 PiK = Putrakaraka	JH 8-Karaka制	按度数排序第7位（从高到低：AK→AmK→BK→MK→PiK→PK→GK→DK）
PDF有8个Karaka但无PiK	列出AK/AmK/BK/MK/PK/GK/DK共7个+Rahu=AK	Sanjay Rath 8星制	排除Rahu和Mars后取最低度数（或按PDF标注）
PDF只有7个Karaka	只列出 AK~DK 共7个	K.N. Rao 7星制	所有7星中度数最低者
引擎计算(full-reading)	Python引擎输出	K.N. Rao 7星制（默认）	引擎内置7星逻辑
用户未提供数据	仅口头描述	询问用户或默认7星	标注"待确认"

8.3 常见陷阱与纠正

隐私保护：本节曾包含真实用户个人星盘或人生事件资料，已移除。请使用公开名人案例、虚构 smoke case，或仅在当前会话中处理用户主动提供的数据；不得写入 skill 文件或公开仓库。

8.4 强制输出格式

每份解盘报告必须在开头声明：

### 📐 分析参数
- **Karaka系统**：[K.N. Rao 7星 / JH 8-Karaka / Sanjay Rath 8星]
- **DK（配偶星）**：[行星名]（[度数]°，排名第[X]低）
- **数据来源**：[full-reading引擎 / JH PDF / PL截图 / 文字描述]
- 若DK在不同系统中可能不同 → 同时注明：
  > ⚠️ 注意：若采用Sanjay Rath 8星制，DK可能为[替代行星]而非[Mars]

---

🔴 阶段零：入口路由（三条路径）

用户消息到达后，AI立即判断走哪条路径：

用户消息到达
  │
  ├─→ 【路径A】用户提供了精准出生信息（日期+时间+地点）
  │     → 直接调用 full-reading 引擎全链路计算
  │     → 跳到阶段二
  │
  ├─→ 【路径B】用户提供了PDF/图片星盘 或 丰富的文字星盘描述
  │     → 提取文档中的所有星象数据（落宫、度数、Dasha等）
  │     → 直接基于提取的数据进行推算分析
  │     → 跳到阶段二
  │
  └─→ 【路径C】用户出生时间不明确 或 仅知道大概时间
        → 启动互动式出生时间矫正
        → 矫正完成后走路径A

---

路径A：精准出生信息 → full-reading 全自动计算

触发条件：用户提供了明确的出生日期+时间+地点（三者齐全）

示例输入：

• "1990年1月1日 12:00（示例） 示例城市"
• "我出生于 1990-08-15 早上6:30 北京"
• "April 17, REDACTED_YEAR, 2:45 PM, San Francisco, China (36.6N, 114.5E)"

执行指令（一条命令搞定所有计算）：

python3 scripts/jyotish_engine.py full-reading \
  --year YYYY --month MM --day DD --hour HH --minute MM \
  --lat XX.XX --lon XX.XX --tz X

此命令自动执行13个计算步骤：

1. chart — 核心星盘（上升、行星位置、宫位）
2. dasha — Vimshottari大运时间线
3. yoga — Yoga格局识别
4. varga_full — BPHS十六分盘（D2-D60）
5. aspects — 度数精确相位系统
6. jaimini — Chara Karaka + Chara Dasha + Karakamsha
7. nakshatra_adv — Tara Bala + Sub-Lord
8. argala — Argala门闩系统
9. tajika — Tajika年运盘
10. shadbala — 六重力量
11. ashtakavarga — 八分法
12. validation — R1-R10数学验证
13. audit — P1-P12行星审计

输出结构：

• chart：完整星盘数据
• modules：12个模块各自的结果
• summary：计算耗时、模块数、错误数
• errors/warnings：异常信息

数据质量门：

字段	检查项	判定
summary.errors	是否为空	空则继续，非空需评估
summary.modules_computed	是否≥10	≥10正常，<10说明多模块失败
chart.ascendant	是否有上升星座	无则计算失败，需排查

完成后：直接跳到阶段二（意图识别）

---

路径B：PDF/文字星盘 → 数据提取 + 直接推算

触发条件：用户上传了PDF星盘、截图，或提供了详细的文字星盘描述

示例输入：

• 上传11页JhoroWatch PDF
• 上传Parashara's Light截图
• 文字描述："我的上升是狮子座，太阳在白羊座9宫，月亮在水瓶座7宫..."

⚠️ 核心原则：用文档的数据，不重新排盘

用户提供的PDF/文字星盘中的数据就是事实来源。AI不需要从出生时间重新计算星盘，而是直接使用文档中已有的：

• 行星落宫落座
• Dasha时间线
• Shadbala分数
• Ashtakavarga点数
• Yoga列表
• 分盘数据

执行步骤：

1. 识别来源（JH / Parashara's Light / 其他软件）
2. 逐页/逐段提取所有星象数据
3. 填充标准JSON Schema（见下方模板）
4. 执行数据完整性门（Quality Gate）
5. 如有出生时间+地点，额外调用 full-reading 补充计算
6. 输出提取报告

数据提取模板：

## 📋 星盘数据提取报告

**来源**：[JH / PL / 文字描述] | **完整度**：[XX%]

### 基本信息
- 出生：[YYYY-MM-DD HH:MM] [地点] [性别]
- Ayanamsa：[Lahiri XX°XX'XX"]

### D1概要
- 上升：[星座] [度数]° ([Nakshatra] P[Pada])
- AL：[星座] | UL：[星座] | HL：[星座] | GL：[星座]

### 行星配置表
| 行星 | 星座 | 宫位 | 度数 | NK | Pada | 状态 | 逆行 | 燃烧 | 战争 |
|------|------|------|------|-----|------|------|------|------|------|
| Sun  |      |      |      |     |      |      |      |      |      |
| Moon |      |      |      |     |      |      |      |      |      |
| ...  |      |      |      |     |      |      |      |      |      |

### Jaimini Karakas
- AK=[行星] AmK=[行星] BK=[行星] MK=[行星] PK=[行星] GK=[行星] DK=[行星]

### 关键分盘
- D9上升：[星座] | D10上升：[星座]

### 当前Dasha
- Maha：[行星] ([起]-[止])
- Antar：[行星] ([起]-[止])
- Pratyantar：[行星] ([起]-[止])

### Shadbala摘要
- 最强：[行星] [分数]R | 最弱：[行星] [分数]R

### Ashtakavarga SAV
- 宫位：1  2  3  4  5  6  7  8  9  10 11 12
- 点数：[XX XX XX XX XX XX XX XX XX XX XX XX]

### Yoga清单
- [Yoga1]：[行星]在[X宫]

数据完整性门：

完整度	判定	允许的分析
≥90%（P0全齐）	✅ Pass	Level 2/3完整分析
70-89%（P0大部分）	⚠️ Limited	Level 2，标注限制
<70%（P0缺关键项）	❌ Fail	Level 1快速概览，要求用户补全

补充计算（条件触发）：

如果PDF中包含了出生日期+时间+地点信息，AI 应当额外调用 full-reading 来补充PDF中可能缺失的计算（如精确相位、Argala、Tajika等v3.7新增模块），将引擎计算结果与PDF提取数据合并，以引擎结果为补充、PDF数据为基准。

完成后：直接跳到阶段二（意图识别）

---

路径C：时间不明确 → 互动式出生时间矫正

触发条件：

• 用户说"不知道出生时间" / "大概下午吧" / "不清楚几点"
• 用户只知道日期不知道时间
• 用户提供的出生证明时间与实际有出入

⚠️ 核心理念：不猜时间，通过互动逐步锁定

AI不应该凭空假设一个时间，而应该通过结构化互动帮助用户锁定精确时间。

矫正流程（→ birth-time-rectification-advanced.md）：

C1. 初始信息收集（第一轮互动）

AI必须收集的基础信息（只问一轮，最多5个问题）：

"为了帮你精准确定出生时间，我需要了解一些信息：

1. 你目前知道的出生时间范围是什么？（比如'下午2点到5点'、'上午'、'完全不知道'）
2. 出生地点是哪里？（城市即可）
3. 你的体型偏瘦/中等/偏壮？脸型偏圆/长/方？
4. 容易出现健康问题的部位是？（比如经常头痛/肠胃不好/腰痛等）
5. 有没有明显的胎记或疤痕？在身体什么位置？"

C2. 外表体质初筛（AI自动分析）

根据用户回答，确定上升星座范围：

• 体型+脸型+健康倾向 → 缩小到2-3个候选上升星座
• 胎记/疤痕位置 → 进一步缩小范围
• 参照 birth-time-rectification-advanced.md 中的外表体质对应表

C3. 生活事件验证（第二轮互动）

AI请求用户提供人生重要事件：

"初步判断你的上升可能在[星座A]或[星座B]。
为了进一步确认，请告诉我你人生中的一些重要转折事件，
大概5-10个就行，包括大概的时间和事件类型。比如：
- 搬家、转学、毕业
- 工作/事业的重要变化
- 开始或结束一段感情
- 亲人离世或重病
- 获奖或重大成就
- 生病或手术"

AI对每个事件做Dasha+Transit验证：

• 用候选时间分别排盘
• 检查事件时间点的Dasha周期是否激活相关宫位
• 检查Transit是否支持该事件
• 计算每个候选时间的吻合率

C4. D9/D10精确校正（第三轮互动，可选）

如果需要更精确（精确到±5分钟以内）：

"时间范围已经缩小到[XX:XX-XX:XX]。
为了进一步精确，请告诉我：
1. 你的感情模式是怎样的？（主动/被动、深刻/轻松、重视精神连接/重视现实基础）
2. 你的工作风格是怎样的？（管理型/创意型/研究型/服务型）"

• 感情模式 → 判定D9上升 → 缩小时间
• 工作风格 → 判定D10上升 → 缩小时间

C5. 矫正结果输出

## 🔧 出生时间矫正报告

### 信息收集
- 已知时间范围：[描述]
- 外表体质：[描述]
- 事件验证：[N]个事件

### 矫正过程
- 上升候选：[星座A] / [星座B] → 判定：[星座X]
- Dasha吻合率：[XX%]
- Transit吻合率：[XX%]
- D9上升判定：[星座]（基于感情特质）
- D10上升判定：[星座]（基于事业特质）

### 矫正结果
- **矫正后出生时间**：[HH:MM]
- **置信度**：[高/中/低]（[XX%]事件吻合）
- **精度范围**：±[X]分钟

### ⚠️ 声明
出生时间矫正是基于事件反向推导的概率性方法。
矫正后的时间不能100%保证精确，但基于[X]个事件的验证，
吻合率达到[XX%]，可作为有效参考。

矫正完成后：使用矫正后的时间走路径A，调用 full-reading 全链路计算。

---

阶段二：用户意图识别与路由

2.0 Strict Workflow Router（v6.0.1-orchestration）

在使用下方意图路由表之前，先读取 strict-workflow-router.md。凡涉及事业、婚恋、财务、事件应期、历史回测、技法可靠性或高级分析，必须选择对应 strict route，并在最终输出附 Technique Audit Table。

在 Technique Audit Table 中，Functional Benefic/Malefic 不得只写“已使用”。必须显式列出：

• functional benefics
• functional malefics
• functional neutrals
• yogakarakas
• 对结论置信度的影响

若缺少其中任一层，不得伪装成高严谨完成态，应降级置信度或标记 blocked。

用户意图	Strict route	必须额外完成
事业机会/职业方向/项目落地	career-timing-strict	D1+D9+D10+Vimshottari+Jaimini+AmK/Karakamsha+AL/A10+Shadbala+AV+Argala
婚恋/婚姻/伴侣/关系结果	relationship-timing-strict	性别/昼夜确认+D1+D9+DK+UL+Double Transit+KP
财运/收入/到账/资产	wealth-timing-strict	2H/11H+D2/D10+Shadbala+AV+Argala+KP
具体事件是否发生/何时发生	event-timing-strict	事件宫位定义+Dasha+Transit+KP+Moon trigger
历史事件验证/技法可靠性	event-verification-strict	同一技法回测+命中/失败评分+个人化规则

2.1 意图路由表

用户意图	目标宫位	核心参考文件	承诺模板
婚姻/恋爱/关系	7宫	strict-workflow-router.md + relationship-astrology-guide.md	§1
事业/职业/工作	10宫	strict-workflow-router.md + house-modern-mapping.md	§2
财富/收入/投资	2宫+11宫	strict-workflow-router.md + house-domain-planet-mapping.md	§3
子女/创作	5宫	modern-life-scenarios-complete.md	§4
健康/体质	1宫+6宫+8宫	—	§5
教育/学业	4宫+9宫	—	§6
出国/迁移	9宫+12宫	—	§7
灵性/修行	9宫+12宫	—	§8
合盘/关系匹配	7宫	strict-workflow-router.md + synastry + relationship-astrology-guide.md	§1
综合解盘（全盘）	全部	strict-workflow-router.md + comprehensive-reading-workflow.md	全部

（承诺模板→ promise-assessment-templates.md）

2.2 用户未明确意图时的默认流程

如果用户没有说具体问什么（比如只给了出生信息或上传了PDF）：

1. 执行综合解盘工作流Level 2（comprehensive-reading-workflow.md）
2. 先输出10宫位快速扫描
3. 识别最强和最弱的领域
4. 重点展开当前Dasha激活的领域
5. 主动提示用户可以深入询问任何领域

2.3 事件判定骨架（v5.1 新增）

凡是以下题型，必须进入事件判定骨架，不得只靠 strict route 后直接写结论：

• marriage / relationship
• career / offer / promotion / project landing
• wealth / payment / gains / asset timing
• generic event verification

固定执行顺序：

1. Route
   • 先冻结 问题域、任务类型、目标粒度
2. Evidence Ledger
   • 把每个模块落成结构化证据块
3. Adjudication
   • 按 Promise -> Activation -> Manifestation -> Timing
4. Output Contract
   • 只输出 verdict + confidence + conflicts + audit + raw evidence

详细协议：

• references/event_judgment_skeleton.md
• references/event_judgment_marriage.md

若问题属于婚恋，必须再额外执行 event_judgment_marriage.md 的专用裁决器。

---

阶段三：静态星盘分析（→ 多个参考文件）

3.1 执行顺序（严格按此顺序）

Step 3.1  宫位-行星基础分析
          → references/planets.md
          → references/signs-and-houses.md

Step 3.2  承诺评估（Promise Assessment）
          → references/promise-assessment-templates.md
          → 输出：承诺等级（完整/部分/缺失）

Step 3.3  Yoga格局识别
          → references/yoga_list.md
          → references/yoga-list-chinese.md
          → references/yoga-strength-scoring-system.md

Step 3.4  Argala检查（目标宫的2/4/5/8/11宫）
          → references/argala-complete-guide.md
          → 输出：目标宫是否被"开门"或"锁门"

Step 3.5  逆行/燃烧/行星战争检查
          → references/retrograde-combustion-war-guide.md
          → 每颗行星检查三重叠加

Step 3.6  Nakshatra深度解读
          → references/nakshatra_deities.md
          → references/nakshatra-chinese-quick-ref.md

Step 3.7  Shadbala评估
          → references/shadbala-complete-methodology.md
          → 输出：行星力量排名

Step 3.8  Ashtakavarga评估
          → references/ashtakavarga-complete-system.md
          → 输出：SAV 12宫排名 + 关键阈值判断

Step 3.9  Ketu双属性检查
          → references/ketu-dual-nature-guide.md
          → 如果命盘有Ketu，必须同时评估"放手"和"突破"

Step 3.10 分盘确认
          → references/varga-system-quick-reference.md
          → D9（关系）+ D10（事业）+ 对应领域分盘

Step 3.11 ⭐ MEVG-静态门控（v5.0 强制）
          → references/mandatory-verification-gate-protocol.md
          → 对所有静态解读声明执行 web_search 外部验证
          → 验证范围：Yoga 识别/行星尊严判断/Shadbala 异常/SAV 关键阈值/Ketu 双属性
          → 最低要求：L2≥4次搜索≥3来源，L3≥8次搜索≥5来源
          → 输出：验证状态表（检索项/查询词/来源数/状态/关键来源）
          → ❌ 未通过 → 降级置信度为[C] + 标注"验证不足"

3.2 静态分析输出模板

## 🔍 静态星盘分析

### 承诺评估（Promise）
| 领域 | 宫位 | 宫主星 | Karaka | 分盘确认 | 承诺等级 |
|------|------|--------|--------|---------|---------|
| [领域] | [强/中/弱] | [状态] | [状态] | [✅/❌] | [完整/部分/缺失] |

### Yoga格局
| Yoga | 构成 | 强度 | 领域影响 |
|------|------|------|---------|
| [名称] | [行星]在[X宫] | [强/中/弱] | [促进/阻碍] |

### Argala分析（目标宫=[X宫]）
| 干预宫 | 行星 | 效应 | Virodha | 最终 |
|--------|------|------|---------|------|
| 2宫 | [行星] | [吉/凶]Argala | 12宫[空/行星] | [开门/锁门/对冲] |
| 4宫 | ... | ... | 10宫 ... | ... |
| 11宫 | ... | ... | 3宫 ... | ... |

### 行星异常状态
| 行星 | 逆行 | 燃烧 | 战争 | 影响 |
|------|------|------|------|------|
| [行星] | ✅/❌ | ✅/❌ | ✅/❌ | [描述] |

### Shadbala排名
1. [行星] — [分数]R（最强）
...
9. [行星] — [分数]R（最弱）

### SAV关键宫位
| 宫位 | SAV | 阈值判断 |
|------|-----|---------|
| [目标宫] | [分数] | [强>30 / 中25-30 / 弱<25] |

### 静态分析结论
- **先天承诺**：[强/中/弱] — [描述]
- **关键优势**：[列出]
- **关键障碍**：[列出]

---

阶段四：动态推运分析（→ 多个参考文件）

4.1 执行顺序

Step 4.1  Dasha激活评估
          → references/vimshottari_dasha_guide.md
          → 当前Maha/Antar/Pratyantar与目标领域的关系

Step 4.2  Dasa Convergence（轻量三系统法）
          → references/dasa-convergence-methodology.md §七
          → Vimsottari + Yogini + Chara 三系统交叉验证
          → 输出：Convergence等级（Level 0-3）

Step 4.3  Transit触发评估（四参考点强制）
          → references/transit-comprehensive-guide.md
          → references/transit-multi-reference-guide.md
          → 必须从Lagna + Chandra Lagna两个参考点分析
          → Level 3加上AL参考点

Step 4.4  Double Transit确认
          → 土星+木星是否同时激活目标宫位

Step 4.5  Jaimini确认
          → references/jaimini-complete-system.md
          → Karaka状态 + Chara Dasha（如有）

Step 4.6  KP确认
          → references/kp-astrology-complete-system.md
          → Cuspal Sub-Lord分析

Step 4.7  Varshaphala年运盘确认（如需要）
          → references/varshaphala-annual-chart-guide.md
          → references/tajika-yoga-complete-guide.md

Step 4.8 Transit Actionable Output 强制输出（⭐ v4.1.0 新增）

隐私保护：本节曾包含真实用户个人星盘或人生事件资料，已移除。请使用公开名人案例、虚构 smoke case，或仅在当前会话中处理用户主动提供的数据；不得写入 skill 文件或公开仓库。

Step 4.9 案例检索与对比（⭐ v4.1.0 强制）

目的：动态预测（被发现/合作/关键事件型）必须以真实案例作为参照，不依赖纯理论推断。

执行条件：当用户问及以下问题时，强制执行：

• "什么时候"、"应期"、"时机"
• "被发现"、"被贵人"、"合作"、"破圈"
• "移民"、"搬迁"、"升职"
• 任何涉及具体事件类型的预测

案例检索命令：

# 引擎内置名人案例库
python3 scripts/jyotish_engine.py celebrity --config "Jupiter+Moon+AmK 7宫"

# WebSearch 真实案例
web_search: "astrologer content creator discovered by mentor collaboration 2024 case study"

输出格式：

## [B] 2026年6月2日—6月18日：Jupiter入Cancer触发事业窗口
**置信度**：⭐ [B]（高概率——基于3个独立维度）

**Actionable Output**：
- 具体时间段：6月2日起，峰值6月18日前后72小时
- 具体行动：已有内容/产品保持展示活跃度，留意主动联系
- 行动类型：⚠️ 被发现型（AmK Moon 7宫机制：被人使用工具后触发）

**案例参照**：Starcross App（0广告月入6万，内容获客+情感变现）；Neda Farr（TikTok 22万粉丝→工具创始人）
**未验证声明**：以上预测基于星盘信号与案例类比推断，未经个人历史事件验证，置信度[B]。

Step 4.10 ⭐ MEVG-动态门控（v5.0 强制）

目的：所有 Transit 效应、Dasha 解读、特殊天文现象（Ashtama Shani/Sade Sati/Jupiter 换座等）必须经过外部来源验证。

触发条件：阶段四 Step 4.1-4.9 完成后，自动执行。

执行步骤：

1. 提取所有动态解读声明（Dasha 效应、Transit 效应、Double Transit 判断等）
2. 为每个声明构建英文检索查询：
   - "[Planet] transit [Sign] [Year] Vedic astrology effects"
   - "[Planet1]/[Planet2] Dasha period effects Vedic"
   - "Ashtama Shani [Moon sign] [Year]" (如适用)
   - "Jupiter transit Cancer [Year] all ascendants" (如适用)
3. 执行 web_search（最低≥4次，Level 3≥8次）
4. 交叉验证：对比来源一致性
5. 输出验证状态表

通过标准：≥80% 动态解读有≥2个独立来源
失败处理：未验证解读全部标注"未经验证" + 置信度降级

输出格式：

### 📋 MEVG 验证状态（动态分析）

| 检索项 | 查询关键词 | 来源数 | 状态 | 关键来源 |
|--------|-----------|--------|------|---------|
| [Dasha/Transit] | [查询词] | [N] | ✅/⚠️/❌ | [来源1, 来源2] |

**总检索次数**：[N] 次 | **验证通过率**：[X]%
**降级声明**：[列出]

→ references/mandatory-verification-gate-protocol.md

4.2 动态分析输出模板

## ⏳ 动态推运分析

### Dasha激活
| 层级 | 行星 | 日期范围 | 与目标关系 | 评估 |
|------|------|---------|-----------|------|
| Maha | [行星] | [日期] | [描述] | [有利/中性/不利] |
| Antar | [行星] | [日期] | [描述] | [有利/中性/不利] |
| Pratyantar | [行星] | [日期] | [描述] | [有利/中性/不利] |

### Dasa Convergence（轻量三系统法）
| 系统 | 当前周期 | 激活？ | 证据 |
|------|---------|--------|------|
| Vimsottari | [Maha]-[Antar] | ✅/❌ | [说明] |
| Yogini | [Yogini名] | ✅/❌ | [说明] |
| Chara | [星座] | ✅/❌ | [说明] |
| **Convergence** | | **Level [X]** | **概率+[XX%]** |

### Transit分析
#### 从Lagna看
| 行星 | 过境[目标宫]时间 | 效应 | SAV |
|------|-----------------|------|-----|
| 土星 | [日期] | [压力/考验] | [分数] |
| 木星 | [日期] | [机遇/祝福] | [分数] |

#### 从Chandra Lagna看 ⚠️强制
| 行星 | 过境[目标宫]时间 | 心理/职业效应 |
|------|-----------------|-------------|
| 土星 | [日期] | [描述] |
| 木星 | [日期] | [描述] |

#### Double Transit
- 土星+木星同时激活目标宫：[是/否]（[时间窗口]）

### 三系统交叉验证
| 系统 | 判断 | 方向 | 置信度 |
|------|------|------|--------|
| Parashara | [描述] | [正面/负面] | [高/中] |
| Jaimini | [描述] | [正面/负面] | [高/中] |
| KP | [描述] | [正面/负面] | [高/中] |
| **一致性** | | [三系统/两系统/矛盾] | |

---

阶段五：应期输出（→ timing-prediction-template.md + prediction-output-protocol.md）

5.0 ⚠️ 置信度分级与验证状态强制标注（必读！）

每条预测结论必须同时标注两个维度：置信度等级 + 验证状态

5.0.1 置信度三级分类（→ precision-reading-methodology.md §五）

级别	标记	定义	触发条件
A-已验证	✅ [A]	经过用户已知事件倒推验证的结论	用户提供了过往事件 + 倒推匹配度≥60%
B-强推断	⭐ [B]	3个以上独立维度指向同一方向，但未经事件验证	PACDARES静态 + L3矛盾检查 + Dasha/Transit多系统一致
C-假设	⚡ [C]	单一维度或理论推导，缺乏多系统支撑	仅凭单一配置（如"DK落12宫"）得出的结论

5.0.2 验证状态强制声明

状态	标记	含义	输出要求
已验证	[已验证·N/N事件吻合]	完成了倒推验证且通过	可给出相对精确的窗口
未经验证	[未经验证]	用户未提供过往事件	必须降低置信度至少一级；不得使用[A]标记
验证失败	[校准异常·需重新评估]	倒推匹配度<60%	停止预测，建议先矫正出生时间

5.0.3 强制标注格式

每条预测结论必须包含以下标注行：

结论：[描述]
置信度：[A/B/C]
验证状态：[已验证·N/N / 未经验证]
依据：[列出1-3个核心依据]
精度边界：[见5.1统一精度表]
矛盾说明：（如有）[描述]

违反示例：

• ❌ "2027年你会结婚" —— 无标记、无置信度、无验证、无依据
• ✅ "2027Q2-Q4期间，婚姻领域处于高度活跃期 ⭐[B][未经验证]，依据：Saturn/Venus大运激活7宫+DK Mars过境恢复，精度±2-3月"

5.0.4 Transit Actionable Output 强制标注（⭐ v4.1.0 新增）

隐私保护：本节曾包含真实用户个人星盘或人生事件资料，已移除。请使用公开名人案例、虚构 smoke case，或仅在当前会话中处理用户主动提供的数据；不得写入 skill 文件或公开仓库。

[B] 时间段：事件描述

置信度：⭐ [B]（高概率——基于N个独立维度：维度1+维度2+维度3） Actionable Output：

• 具体时间段：精确日期范围
• 具体行动：明确做什么
• 行动类型：被发现型/主动出击型/等待窗口型 案例参照：真实案例名称+关键特征 未验证声明：以上预测基于星盘信号与案例类比推断，未经个人历史事件验证，置信度[X]。

**禁用规则**：
- ❌ 纯理论推断行动建议（"保持开放心态"）
- ❌ 无时间段的行动建议（"做好内容准备"）
- ❌ 无置信度的预测（"6月肯定会被发现"）
- ❌ 无未验证声明的 [B]/[C] 预测

→ 详细规范：references/transit-actionable-output-guide.md
→ SKILL.md 主文档：「⚠️ Transit Actionable Output 规范」章节

### 5.1 统一精度边界声明表

> **⚠️ 所有含时间预测的输出必须附此精度表对应等级的声明——不可省略！**

| Dasha层级 | 时间粒度 | 精度范围 | 适用场景 | 强制附注文案 |
|-----------|---------|---------|---------|------------|
| **Maha Dasha (MD)** | 年级 | ±1-3个月 | 人生大趋势、10年主题 | `"本分析为MD级（±1-3月），描述大方向趋势"` |
| **Antar Dasha (AD)** | 月级 | **±2-4周** | 年度主题、年度关键窗口 | `"本分析为AD级（±2-4周），描述年度能量走向"` |
| **Pratyantar (PD)** | 周级 | **±2-3天** | 月度窗口、具体事件时机 | `"本分析为PD级（±2-3天），描述月度活跃区间"` |
| **Sookshma (SD)** | 日级 | **±1-2天** | 周度参考 | `"本分析为SD级（±1-2天），周度参考性质"` |
| **Prana SSD** | 小时级 | **±6-12小时** | 日度精细参考（仅作辅助） | `"⚠️ SSD级精度为±6-12小时误差，非精确时刻，仅供参考"` |

**通用强制声明（附加到所有预测输出末尾）：**

```markdown
---
### ⚠️ 精度与诚实声明
- **本分析精度等级**：[PD/AD/MD]级（[±X天/周/月]）
- **预测本质**：占星描述的是能量场活跃度和时机概率，非绝对保证交付
- ✅ 可以描述：趋势方向、时间窗口概率、风险提示、机会信号
- ⚠️ 谨慎表述：具体月份、事件形态描述（需标注[B]或[C]）
- ❌ 绝对禁止：确定日期、"一定会发生"、指定具体人物/项目
- 若出现SSD级时间 → 必须额外标注："SSD级（±6-12小时），仅供交叉参考"

5.2 输出规范（严格遵守）

每条预测必须包含：

必含项	说明
分析等级	Level 1/2/3/4
置信度	[A]/[B]/[C] + 验证状态
时间窗口	主窗口（月级）+ 次窗口（周级）
承诺评估	本命盘有无此承诺
激活评估	Dasha-Transit是否对齐
精度边界声明	⚠️ 声明预测的边界（按5.1统一精度表）

5.2 禁用措辞（→ prediction-output-protocol.md 第四节）

严格禁止：

• ❌ "完美吻合" / "100%命中" / "一定会"
• ❌ "事业大爆发" / "贵人会联系你"
• ❌ 指定具体行业/项目/人物

必须使用：

• ✅ "X月前后，第Y宫处于高度活跃期"
• ✅ "此窗口的行星能量倾向于[增长/收缩/重组]"
• ✅ "高/中/低概率倾向，±X周/月"

5.4 应期输出模板

## 📅 应期预测

### 📐 分析参数
- **Karaka系统**：[K.N. Rao 7星 / JH 8-Karaka / Sanjay Rath 8星]
- **DK（配偶星）**：[行星名]（[度数]°）
- **验证状态**：[已验证·N/N / 未经验证]

### 事件预测总表
| 项目 | 说明 |
|------|------|
| **事件类型** | [领域] |
| **发生倾向** | [高90%+/中70-89%/低50-69%] |
| **置信度** | [A/B/C]（[依据简述]） |

### 应期时间窗口
| 精度 | 时间窗口 | 判定依据 | 置信度 | 精度声明 |
|------|---------|---------|--------|---------|
| **主窗口(MD/AD级)** | [YYYY-MM 至 YYYY-MM] | Dasha+慢速Transit | [A/B/C] | ±[1-3月/2-4周] |
| **次窗口(PD级)** | [YYYY-MM 至 YYYY-MM] | Pratyantar+Double Transit | [B/C] | ±2-3天 |
| **精细窗口(SD级)** | [YYYY-MM-DD 至 YYYY-MM-DD] | Sookshma+快速Transit | [C] | ±1-2天 |

### 确认/延迟/取消信号
| 类型 | 信号 | 含义 |
|------|------|------|
| 确认 | [描述] | 事件在该窗口内发生的概率提升 |
| 延迟 | [描述] | 事件可能推迟 |
| 取消 | [描述] | 事件可能不发生 |

### ⚠️ 精度与诚实声明
- **本分析精度等级**：[PD/AD/MD]级（±[X]）
- **预测本质**：占星描述的是能量场活跃度和时机概率，非绝对保证交付
- ✅ 可描述：趋势、窗口概率、风险提示
- ⚠️ 谨慎：具体月份、事件形态（需标注[B]/[C]）
- ❌ 禁止：确定日期、"一定会"、指定具体人物/项目

5.5 ⭐ MEVG-预测门控（v5.0 强制）

目的：确保每条预测输出都有来源支撑、置信度标注与验证结果一致、精度声明完整。

触发条件：阶段五 Step 5.0-5.4 完成后，自动执行。

检查项（100% 必须通过）：

#	检查项	通过标准	失败处理
1	每条预测有置信度标注	[A]/[B]/[C] 标记存在	补全
2	置信度与验证结果一致	[B]需≥3独立维度、[A]需历史验证	不一致则降级
3	精度边界声明完整	精度等级+范围+强制附注文案	补全
4	未验证声明存在	[B]/[C] 预测有未验证声明文案	补全
5	MEVG 验证状态表存在	静态+动态验证状态表均已输出	补全

通过标准：5/5 项全部通过 失败处理：缺少任何一项即阻止输出，补全后重新检查

→ references/mandatory-verification-gate-protocol.md

---

阶段六：补救措施（如用户需要）

→ references/remedies-complete-system.md
→ references/personalized-remedies-system.md

仅在以下情况主动提供：

1. 用户明确要求
2. 分析中发现严重受克且用户询问如何缓解
3. Sade Sati / Kantaka Shani / Mangal Dosha等长期压力期

---

阶段七：现代措辞包装

所有输出最终必须经过现代措辞包装：

• → references/modern-language-guide.md
• → references/modern-life-scenarios-complete.md
• → references/common-misconceptions.md

包装规则：

1. 传统术语→现代措辞映射（太阳→个人品牌、月亮→心理健康）
2. 避免"好命/坏命"等绝对化表述
3. 提供"倾向性描述"而非"命运判定"
4. 直接坦率：给核心优势和挑战，不说废话

---

快速参考：完整工作流一页纸

用户消息到达
  │
  ├─ 路径判断
  │   ├─→ 【路径A】精准出生信息 → full-reading 全自动计算
  │   ├─→ 【路径B】PDF/文字星盘 → 提取数据 + 直接推算
  │   └─→ 【路径C】时间不明确 → 互动矫正 → 走路径A
  │
  ├─→ ⚠️ Step 0.5: Karaka系统识别（强制！识别7/8-Karaka制，声明DK）
  │
  ├─→ 阶段二：意图路由
  │     └─→ 用户问什么 → 目标宫位 → 对应承诺模板
  │         （无明确意图 → 综合解盘Level 2）
  │
  ├─→ 阶段三：静态分析（10步 + 1个门控）
  │     ├─→ 宫位-行星基础
  │     ├─→ 承诺评估
  │     ├─→ Yoga识别
  │     ├─→ Argala检查
  │     ├─→ 逆行/燃烧/战争
  │     ├─→ Nakshatra深度
  │     ├─→ Shadbala
  │     ├─→ Ashtakavarga
  │     ├─→ Ketu双属性
  │     ├─→ 分盘确认
  │     └─→ ⭐ Step 3.11: MEVG-静态门控（web_search验证所有静态声明）
  │
  ├─→ 阶段四：动态推运（7步 + 1个门控）
  │     ├─→ Dasha激活
  │     ├─→ Dasa Convergence三系统法
  │     ├─→ Transit四参考点
  │     ├─→ Double Transit
  │     ├─→ Jaimini确认
  │     ├─→ KP确认
  │     ├─→ Varshaphala确认
  │     ├─→ Transit Actionable Output
  │     ├─→ 案例检索与对比
  │     └─→ ⭐ Step 4.10: MEVG-动态门控（web_search验证所有动态声明）
  │
  ├─→ 阶段五：应期输出（+1个门控）
  │     ├─→ 置信度分级与验证状态标注
  │     ├─→ 统一精度边界声明
  │     ├─→ Transit Actionable Output 强制标注
  │     ├─→ 应期输出模板
  │     └─→ ⭐ Step 5.5: MEVG-预测门控（确认100%预测通过验证）
  │
  ├─→ 阶段六：补救措施（可选）
  │
  └─→ 阶段七：现代措辞包装

---

版本：5.0.0 更新日期：2026-04-27 配套文件：pdf-chart-reading-guide.md（PDF提取）、birth-time-rectification-advanced.md（出生时间矫正）、timing-prediction-template.md（应期模板）、prediction-output-protocol.md（输出规范）、comprehensive-reading-workflow.md（综合流程）、promise-assessment-templates.md（承诺模板）、argala-complete-guide.md（Argala检查）、dasa-convergence-methodology.md（Dasa Convergence）、precision-reading-methodology.md（精准解盘方法论+置信度分级+倒推验证协议）、mandatory-verification-gate-protocol.md（⭐ v5.0 强制外部验证门控协议）