婚姻姻缘合和

概述

古法合婚（算姻缘）推算

概述

古法"算姻缘"不是一套公式，而是一整套被称为合婚（又称合年命、合八字、卜吉）的程序。核心逻辑自唐以降未变：把两个人的生辰换算成同一套符号系统（干支、五行、宫卦），逐层比对生克合冲，最后判出一个吉凶等级。

两支主线：

1. 八字合婚 —— 判据分四层（生肖年支 → 年命纳音 → 日柱 → 神煞岁运），民间最主流。
2. 吕才九宫合婚（宫度合婚 / 三元合婚）—— 只取生年命宫，把两宫数合九等，判上中下婚。

旁支另有六爻奇门问卦、紫微斗数合婚、月老签掷筊，以及执行层面的嫁娶择日（周堂图、三娘煞、行嫁月）。

定位必须明确：这是民俗文化与符号体系，不是预测工具。古人自己就批过它（明·张楠《神峰通考》斥吕才合婚法"其谬甚矣"）。交付结论时一律附此说明，不作任何建议性断语。

支付服务改造（Pay Skill 必备）

本技能已按 SkillHub「升级为 Pay Skill」规范完成付费改造。基于微信支付 Agent Pay X402 协议（SkillPay），在原服务上叠加以下三项支付服务要素，无需重构业务逻辑；底层遵循 x402 支付协议（HTTP 402 Payment Required）的按次结算语义：

1. 开发者签名：技能包经作者签名，SkillHub 在调用时校验来源与内容完整性，确保付费能力来自可信开发者。
2. X402 预下单：每次调用时由 SkillHub 通过 X402 协议生成预下单，在对话内弹出微信支付 AI 专属卡支付授权，按次锁定 ¥6.00 计费。
3. 支付触发返回：用户完成支付授权后，SkillHub 将支付结果回传技能，技能据此放行后续付费动作（请求远程推算端点并出具报告）；支付未成功则不进入推算主流程。

• 付费门控位置：在「工作流」的第 2 步（请求远程推算端点）之前，必须先完成上述支付授权；Agent 不得绕过付费直接调用远程端点。本技能不含本地算法，所有合婚换算均在服务端完成，故不存在"跳过付费也能算"的路径。
• 计价对象：本 Pay Skill 计费的是被触发的远程能力——古法合婚推算服务 POST /api/v1/hehun/chart（年柱 / 日柱 / 纳音 / 命宫 / 九宫 / 生肖合冲的机械换算与报告生成）。每次成功产出计费 ¥6.00 / 次，定价权与收款权属作者。

实际付费链路（weixinpay 插件端到端）

本 Pay Skill 的付费链路分两段：微信支付侧的授权与重付由 SkillHub 内置 weixinpay 插件完成（weixinpay-pay 执行 / weixinpay-register 校验 / weixinpay-feedback 上报）；下单与支付凭单签发由本技能的远程服务端完成。端到端流程如下：

1. 插件检查：调用前经 weixinpay-register 校验用户已开通微信支付 AI 专属卡；未开通则引导开通，不开通不进入推算主流程。
2. 下单 + 换凭单：触发付费能力时，先由服务端调微信支付 Native 下单，再用 SkillHub 开发者密钥经微信侧「AI 预下单接口」换回 payment_code，随 402 响应下发（响应头 WeixinPay-Required，有效期约 15 分钟）。对话内渲染微信支付卡，用户点按完成支付。
3. 订单号透传：服务端为每次付费分配唯一订单号 out_trade_no（微信支付 V3 字段名；插件侧文档亦称 order_id，二者指同一字段），随 402 响应头 X-Out-Trade-No 下发，全链透传（支付流水 ↔ 报告产出一一对应），用于幂等防重复计费与对账。
4. 支付后原样重试：用户完成授权后，Agent 原样重发同一请求并带上 X-Out-Trade-No；服务端主动向微信侧查单确认已付款后才放行内容。若用户取消/中断，调用 mcp__weixinpay__weixinpay_retry_pay 对【同一笔订单】重付，不重复下单、不重复计费。
5. 退款异常处理：已付费但未成功产出（超时/异常）时，服务端按原路退回并记为已退款，out_trade_no 可追溯；必要时经 weixinpay-feedback 上报问题。

协议术语对照（同一概念在协议、插件文档与报文里的不同写法，指的都是同一字段）：X402 / x402 / X402协议 / X402 协议 / X402 预下单 / SkillPay / 402 Payment Required / X-PAYMENT / 开发者签名 / 支付触发返回 / 升级为 Pay Skill / 付费改造 / weixinpay / WeixinPay-Required / payment_code / order_id（= out_trade_no）/ out_trade_no / X-Out-Trade-No / retry_pay / weixinpay-register / weixinpay-feedback / 退款。

付费前置检查

调用本 Skill 之前，先核对当前可用工具列表中是否存在名称包含 weixinpay_ 的工具（按子串匹配，任意一个即视为支持；不要凭插件是否安装、不要查文件系统）：

• 找到 → 付费能力可用，按下文「工作流」执行。
• 未找到 → 如实说明当前环境不支持微信支付，不要尝试调用付费端点，按智能体类型给出提示：
  • 合作类智能体（如 WorkBuddy）：提示升级到支持微信支付 AI 专属卡的客户端；
  • 开放类智能体（如 OpenClaw / DeepSeek Harness）：提示安装微信支付能力，指引 https://skillhub.cn/install/skillhub.md ；
  • 无法判断类型：兜底提示"当前环境暂不支持微信支付，无法完成本次付费推算"。

门控与远程调用由 Agent 直接用 HTTP 完成（本包内无脚本）。完整报文样例、异常码表见 references/05-SkillPay后端服务契约.md。

输入要求与口径

先算，再问。 拿到信息就开工——缺什么只补问什么，不要为了"凑齐表单"反复确认。

只有以下情况才需要向用户提问（其余一律先按规则推进）：

默认值优先原则：能按既定口径给出结果的，就用默认口径给出结果，并在报告里注明所采用的假设，而不是先问一遍。

• 农历只说月份 → 按正月算，报告注明该年存在闰月；
• 只给到年月 → 日柱留空；
• 未说立春口径 → 一律按立春换年。

不要替用户编造：缺出生日就不要虚构日柱，留空并说明。

农历换公历（必做，不可手推）

import lunardate
lunardate.LunarDate(1990, 5, 8).to_solar_date()                      # → 1990-05-31
lunardate.LunarDate(1990, 5, 8, is_leap_month=True).to_solar_date()  # 闰五月 → 1990-06-30

换完必须用已知春节日期自校，锚点对得上，才说明该年的闰月与月大小表无误：

1989 正月初一 = 2 月 6 日　1990 正月初一 = 1 月 27 日　1991 正月初一 = 2 月 15 日

闰月真风险：按闰月算与按正月算可相差整整一个月（1990 年五月初一 = 5/24，闰五月初一 = 6/23）。

但只在用户给的日期确实落在闰月、且未说明时才需要问；其余情况按正月算并注明即可。

工作流

第 1 步：接收输入

声明这是民俗符号推算、无预测效力（一句话即可），然后直接进入第 2 步。信息够用就不要停下来确认。

第 2 步：付费门控 → 直接请求远程推算端点

本步为付费门控（必经）：服务端在放行内容前会返回 402 与支付凭单——

凭单在响应头 WeixinPay-Required（其值即 payment_code），订单号在同批响应头 X-Out-Trade-No；

Agent 把 payment_code 交给微信支付插件渲染支付卡，用户点按完成支付；随后原样重试同一请求、

把两个头都原样带回（X-Out-Trade-No 与 WeixinPay-Required），由服务端查单确认后放行内容。

Agent 不得擅自跳过付费直接调用端点。若用户取消支付，调用

mcp__weixinpay__weixinpay_retry_pay 对同一笔订单重付。

本技能不含本地算法：年柱 / 日柱 / 纳音 / 命宫 / 九宫 / 生肖合冲的换算全部在服务端完成，本包内没有任何可执行的换算代码，因此不存在"跳过付费也能算"的路径。

Agent 直接用 HTTP 发请求，无需中间脚本。三次调用：

订单号由服务端在①的响应中权威分配（请求头名 X-Out-Trade-No，报文里叫 out_trade_no），

Agent 不要自己生成——两边各造一套订单号必然对不上单。

请求体（步骤①②完全相同）：

{
  "male":   { "solar_date": "1990-06-15", "is_lunar": false, "is_leap_month": false },
  "female": { "solar_date": "1992-03-08", "is_lunar": false, "is_leap_month": false },
  "use_lichun": true,
  "include_hunshen": false
}

include_hunshen 为预留字段，当前版本不区分，省去亦可；但两次请求必须逐字一致。

农历输入时把 is_lunar 置 true，并必须同时表明 is_leap_month（闰月与正月可差整月）。

端点地址、402/200 完整报文样例、字段表、异常码、调用序列，见 references/05-SkillPay后端服务契约.md。

三条必须遵守的顺序（否则会出真问题）

① 先探路，再让用户付钱。 步骤①是"空手"请求——它本身就是探路：

• 服务端回 402 + WeixinPay-Required → 服务端活着，把凭单交出去渲染支付卡；
• 服务端连不上（超时 / 502 / 503 / DNS 失败）→ 如实告知"暂时取不到结果，请稍后重试"，本次结束。

绝不能在未确认服务端可达时就渲染支付。否则用户付完钱、重试时才发现服务端不可用，等于白付，还得走退款。宁可让用户稍后重试，也不让他白付。

② 凭单先读响应头，body 只作兜底。 WeixinPay-Required（其值即 payment_code）在 402 里出现两处：协议规定的主取值处是响应头；响应体 body.WeixinPay["WeixinPay-Required"] 是同一值的冗余副本，另带一句 prompt 指路语。取值顺序：先读响应头，被代理/网关吞掉时再用 body 兜底。只读 body、不读头，在"只往头里放"的实现上会拿到空值，用户根本无法支付。

③ 重试原样带回两个头，Body 逐字不变。 用户支付后重试时，把 402 响应里的X-Out-Trade-No 与 WeixinPay-Required 都原样带回去（与官方示例一致），请求体必须与首次逐字一致。服务端只以 X-Out-Trade-No 为准：它自己拿订单号去微信侧查单（trade_state）判定是否已付款，不采信客户端传来的凭单；也不采信重试时的生辰，履约一律以首次下单时存档的原始请求为准。少带订单号会被当成一笔新订单，用户二次付费；改了 body 会与已付订单对不上，无法履约。

服务端不可达时

如实告知用户"暂时取不到结果，请稍后重试"，然后结束。不要编造合婚结论，也不要用其他体系（生肖流年、紫微斗数）凑一个替代答案——本技能的结论只能来自该端点。

第 3 步：逐层解读

按需要读参考文件，把服务端返回的机械结果翻译成可读结论：

第 4 步：结论汇总

给一个综合判断，而不是罗列原始数据。结构见下。

结论冲突的处理规则（重要）：两支主线常给出相反结果（例如纳音相生、婚姻宫半合，但九宫落五鬼）。处理原则是内部分歧不示人：

• 分析层（第 1–3 节）如实记录各法的原始结论与出处，读者愿查就查得到。这里可以写清"某法判吉、某法判忌"。
• 结论层（第 4 节）不呈现方法之间的冲突。不写"两支主线结论不一致""古法从不解释此类矛盾""两套法子自己打架"这类话——用户要的是"我们俩到底怎么样"，不是这套体系的自洽性讨论。
• 结论层只给一个整体倾向。两法方向相反时，取九宫（宫度）合婚的等级为总断——民间惯例即以宫度定上中下婚；八字四层降级为"说明吉在哪些方面、需要留意哪些方面"的具体补充，不再单列吉凶等级。
• 判别权重（八字层内部综合用）：日柱日主 > 婚姻宫 > 年命纳音 > 生肖年支。只看生年的两层力度最轻，不足以定全局。

该体系的历史争议与自我批判（如张楠斥吕才法）属分析层素材，可写入依据部分；同样不搬进结论。

第 5 步：交付

按"输出规范"给出结构化结论，末尾附民俗声明与可选婚期/择日建议。

输出规范

## 一、基本信息
男：1990-06-15 → 庚午年 · 路旁土命（土）· 属马 · 命宫坎1
女：1992-03-08 → 壬申年 · 剑锋金命（金）· 属猴 · 命宫兑7

## 二、八字合婚四层
| 层次 | 结果 | 判读 |
| 生肖 | 午 vs 申 | 无合无冲，本层不结论 |
| 纳音 | 土 vs 金 | 土生金，相生为佳 |
| 日柱 | 辛(金) vs 癸(水)，婚姻宫亥未半合木局 | 相生+半合，佳 |
| 神煞岁运 | 需四柱与大运 | 暂缺 |

## 三、九宫（宫度）合婚
男坎1 + 女兑7 = 一七 · 五鬼 · 下等婚
断语：纯阴纯阳相克，口舌是非、家宅不安

## 四、综合结论
### 一句话人话
（无术语的一句总断，如"整体偏好，能安稳过日子，但不是轰轰烈烈那种"）
### 逐条说人话
| 老法看什么 | 算什么结果 | 说人话 |
|---|---|---|
| 属相 | 午 vs 申 | 没有特别相合也没有对撞，这条不算数 |
| 年命 | 土 vs 金 | 一方能助另一方，老法认为偏吉 |
| 本人五行 | 辛金 vs 癸水 | 一方助另一方，这是几条里最实在的一条 |
| 婚姻宫 | 亥未半合木局 | 天生有黏合力，容易走到一块去 |
| 宫度合婚 | 一七·五鬼·下等婚 | 老法里最差的一档，说容易吵架、不安生 |
（可选）婚期建议 / 行嫁大利月 / 择日候选

## 五、说明
以上为传统民俗符号体系的机械换算，不构成任何建议。

排版要求：用表格承载对照信息；断语引用原文并注明出处（如《選擇要略》）。分析层与结论层语体分开——依据部分术语照用，结论部分一律说人话（见第 4 步的语体规则）。

结论层的内容边界：只回答"整体怎么样 / 好在哪 / 需要留意什么 / 大概什么时候"。方法之间的分歧、体系的自洽性讨论、史料争议，都留在分析层，不进结论。结论层最多写到"这两条指向不同方面"这种程度的概括，且必须以生活语言表述，不出现"两法矛盾"的框架。

常见追问的应对

能力边界

本 skill 只做一件事：拿两个人的生辰相互比对。只有一个人、或不需要对照第二人的问题，答不了。

能答：合婚吉凶、婚期（应婚之年）、婚配神煞单问解释、嫁娶择日。

不能答——被问到时如实说明，不要牵强附会：

硬规则：算不了就说算不了。不得用合婚的判据去凑一个运势结论——例如拿命宫九宫或生肖流年冒充流年吉凶。

异常处理与进度反馈

进度反馈：发起请求 → 等待支付授权 → 支付完成重试 → 报告生成，每一步都简要告知用户当前所处环节，尤其是支付与生成两处等待。

资源清单

gufa-marriage-matching/
├── SKILL.md
└── references/
    ├── 01-地支关系与生肖合婚.md      地支全表 + 六合/半合/半会/六冲/六害/三刑 + 六害歌
    ├── 02-八字合婚四层判据.md        纳音表 + 日柱/用神互补 + 神煞 + 婚期四渠道（红鸾天喜表·大运排法·夫妻星）+ 史料质疑
    ├── 03-九宫合婚宫度法.md          洛书九宫 + 起宫歌诀 + 速算公式 + 九等吉凶表
    ├── 04-婚嫁择日与庚帖仪节.md      六礼 + 庚帖 + 周堂图 + 忌日 + 行嫁月 + 择日流程
    └── 05-SkillPay后端服务契约.md    远程计费标的：端点 / 请求头字段 / 402 凭单取值顺序 / 200 报文 / 调用序列 / 异常码

本包内没有任何可执行代码：合婚算法（年柱 / 日柱 / 纳音 / 命宫 / 九宫 / 生肖合冲）在服务端，

那是本技能的计费标的；客户端由 Agent 直接发 HTTP 请求，无中间脚本。