八字排盘与分析

概览

1. 1. chart 模式：把公历日期时间转换成可复现的八字排盘结果。
2. INLINECODE1 模式：基于已有盘面 JSON、用户问题和本地知识文件生成适配用户语言的分析。

不要把两种模式混用。排盘负责事实，分析负责表达与建议。

何时使用

使用 chart 模式

• - 用户提供出生日期、时间、时区、地点，要求排盘、算四柱、看大运、看流年。
• 任务需要结构化 JSON 结果，供后续程序或分析环节消费。
• 需要稳定、可重复的计算结果，而不是自由发挥的解释。

使用 analysis 模式

• - 已经有 chart 盘面 JSON，用户要求分析事业、婚恋、健康、整体趋势或指定年份。
• 任务需要生成面向用户的中文报告，而不是重新计算排盘。
• 需要引用 knowledge.md 的解释素材，并遵循 prompt.md 的输出结构。

使用顺序

• - 如果用户同时要“排盘 + 分析”，先执行 chart，再把结果传给 analysis。
• 如果用户只给了 chart，不要重复排盘。
• 如果用户只给了生日信息但要分析，先排盘，再分析。

共享约束

• - 排盘事实以 main.py 为准。
• 分析不得篡改盘面字段，不得臆造盘面中不存在的干支、岁运或结论。
• 不使用农历换算。
• 不输出宿命化、绝对化、恐吓式表达。
• 信息不足时，明确说明缺口和影响，不强行补全。
• 分析语言默认跟随用户；若未指定也无法判断，则默认使用简体中文。

模式一：chart

目标

输入合同

CODEBLOCK0

必填字段

• - datetime：本地日期时间字符串，不带 offset。
• INLINECODE14：IANA 时区，例如 Asia/Shanghai。

条件必填字段

• - location：当 time_correction 为 mean_solar_time 或 true_solar_time 时必填。
• INLINECODE20：当需要计算大运且 require_dayun=true 时必填。
• INLINECODE22：只有请求流年/流月/流日时才需要。

可选字段与默认值

• - rules.year_boundary 默认 INLINECODE24
• INLINECODE25 默认 INLINECODE26
• INLINECODE27 默认 INLINECODE28
• INLINECODE29 默认 INLINECODE30
• INLINECODE31 默认 INLINECODE32
• INLINECODE33 默认 INLINECODE34
• INLINECODE35 默认 INLINECODE36
• INLINECODE37 默认 INLINECODE38
• INLINECODE39 默认 INLINECODE40
• INLINECODE41 默认 INLINECODE42

地点解析规则

• - 优先使用 longitude 和 latitude。
• 只有 name 时，按 lookup_mode 解析：

• - amap 和 tencent 需要 lookup_key，也可走环境变量 BAZI_GEOCODE_KEY。
• 可通过环境变量覆盖默认路径和服务：

固定计算规则

• - 年界：INLINECODE59
• 月界：按节气切月
• 日界：默认 INLINECODE60
• 时差修正：

• - require_dayun：默认 INLINECODE64
• 日柱基准：1984-02-02 为 INLINECODE66
• INLINECODE67 模式下，缺少关键时间信息应直接报错

处理顺序

1. 1. 解析 datetime 与 INLINECODE69
2. 根据 rules 决定是否做平太阳时或真太阳时修正
3. 计算年柱、月柱、日柱、时柱
4. 如请求大运，则根据性别与年干阴阳顺逆推算
5. 如请求流转信息，则计算 INLINECODE71
6. 返回节气信息、元信息与置信度

成功输出

失败输出

错误处理约定

• - MISSING_DATE：缺少 INLINECODE73
• INLINECODE74：日期时间格式不合法
• INLINECODE75：缺少 INLINECODE76
• INLINECODE77：时区无效
• INLINECODE78：需要地点但无法解析
• INLINECODE79：请求大运时缺少性别

最低测试覆盖

• - 立春前后跨年边界
• 节气切月边界
• INLINECODE80 日界
• 同一 UTC 在不同时区对应不同本地日
• 缺地点时的报错路径
• 请求大运但缺性别时的报错路径

调用入口

CODEBLOCK3

模式二：analysis

目标

必需输入

• - user_query：用户当前问题，可为简体中文或其他语言。
• INLINECODE85：由 main.py 产生的排盘 JSON。
• INLINECODE87：解释和建议素材，来源于 knowledge.md。

语言适配规则

1. 1. 用户明确指定的输出语言
2. INLINECODE89 的主要语言
3. 简体中文（默认）

补充约束：

• - 若用户使用非中文提问，可按该语言输出，但核心术语如“十神”“天干”“地支”“大运”“流年”可保留中文并加简短解释。
• 若用户要求双语输出，可先给主语言版本，再附简短中文术语对照。
• 若用户未要求翻译，不要为了“国际化”主动输出双语。

事实来源优先级

1. 1. INLINECODE90
2. INLINECODE91
3. 用户问题中的补充条件

当知识库与盘面事实冲突时，以 chart 为准，并明确说明不确定性。

分析前检查

• - 先识别用户问的是整体、事业、婚恋、健康、还是指定年份。
• 确认 chart 是否包含 dayun、flows、meta.confidence 等关键字段。
• 若缺少时辰、地点、性别或用户关注年份，要说明影响范围。

输出结构

1. 1. INLINECODE97
2. INLINECODE98
3. INLINECODE99（仅在用户询问年份或趋势时使用）
4. INLINECODE100
5. INLINECODE101
6. INLINECODE102

每部分要求

1. 盘面摘要

• - 四柱按年、月、日、时顺序展示。
• 大运写当前正在走的运；无法确定时写“当前大运不确定”。
• 流年仅在 chart.flows.year.gz 可用时展示，否则写“流年未指定”。

2. 本次问题结论

• - 输出 3 到 6 条核心判断。
• 每条都尽量包含：现象、影响、建议。
• 结论必须围绕 user_query，不要泛泛而谈。

3. 时间轴

• - 用户问未来趋势、具体年份、近三年变化时再输出。
• 可按今年、明年、后年逐年列重点。
• 若无对应流年数据，提示用户补年份。

4. 建议

• - 输出 3 到 7 条动作化建议。
• 尽量区分“适合做什么”和“避免做什么”。
• 建议要现实、可执行，避免空泛玄学口号。

5. 依据与补充

• - 只引用与当前盘面相关的知识点。
• 引用来源应对应 knowledge.md 的条目或章节。
• 引用尽量短，不超过 25 个字，可适度改写。
• 这里只提供解释依据，不新增结论。

6. 可信度与缺失信息

• - 可信度优先使用 chart.meta.confidence。
• 明确指出缺失信息会影响哪些判断。
• 如需追问，只提最关键的一项或两项。

写作原则

• - 输出语言与用户请求保持一致；无法判断时默认简体中文。
• 多用“倾向于”“可能”“建议”等词，避免绝对断言。
• 不做医学诊断、法律建议或恐吓式表达。
• 不堆砌术语，首次出现可顺手白话解释。

禁止事项

• - 不凭空创造新的八字理论。
• 不脱离 chart 事实做判断。
• 不把知识库内容整段照搬。
• 不因为用户追问就伪造缺失的大运、流年或时柱。

参考文件

• - 输出格式与分析任务要求：INLINECODE108
• 解释依据与建议素材：INLINECODE109

模式切换与交接

• - 排盘结果是分析输入，不是分析结论。
• 当同一请求同时包含出生信息和分析诉求时，先产出 chart，再基于 chart 输出分析。
• 分析阶段如果发现 chart 关键字段缺失，只说明限制，不在分析阶段偷偷补算。

快速判定

• - 问“帮我排盘 / 算四柱 / 算大运” -> INLINECODE113
• 问“帮我看看事业 / 婚恋 / 健康 / 今年运势”且已有盘面 -> INLINECODE114
• 问“这是我的生日，顺便分析一下” -> chart 然后 INLINECODE116