伏羲引擎技术架构深度拆解

摘要： 传统的在线排盘系统往往只是对农历库的简单封装，而“AI 算命”则常陷入大模型幻觉与套话的泥潭。伏羲引擎 v2.0 重构了底层逻辑：引入天文级精度的“真太阳时”校正算法，构建了基于 context-injection 的 AI 编排层，并解决了一系列 Python Web 开发中的跨域工程挑战。本文将基于核心代码库（bazi_engine.py, ai_service.py, config.py）进行源码级复盘。

1. 核心算力：从“时钟时间”到“真太阳时”

在 app/services/bazi_engine.py 的重构中，最大的技术突破是引入了 真太阳时 (True Solar Time) 系统。传统算法直接使用用户输入的钟表时间（平太阳时），这在命理学上是极其粗糙的。北京时间 12:00 在新疆（东经87度）实际上太阳还在爬坡，而在哈尔滨（东经126度）太阳已经西斜。

1.1 经度校正与均时差

我们引入了 time_utils.py，通过用户输入的地理经度（longitude），结合当日的 均时差 (Equation of Time) 进行二次校正。代码逻辑如下：

def calculate_bazi_data(year, month, day, hour, minute, ... longitude):
    # ... (省略基础校验)
    
    if longitude is not None:
        # 调用天文工具库计算真太阳时
        # 解决了“同一个钟表时间，不同地点八字时柱完全不同”的边缘 Case
        tst = get_true_solar_time(base_year, base_month, base_day, hour, minute, float(longitude))
        year, month, day, hour, minute = tst.year, tst.month, tst.day, tst.hour, tst.minute
        is_true_solar = True
    
    # 继续使用 Lunar 库进行干支转换...

1.2 数字化量化系统

为了让 AI 理解“强弱”概念，我们在 BaziLogic 类中实现了一套加权打分算法。系统遍历四柱干支，计算日主（Me Wuxing）在月令的得令情况以及其他三柱的生助情况，最终输出一个 0-100 的量化分数。这些硬数据（Hard Data）是后续 AI 推理的基石。

2. AI 编排层：Prompt 工程与防幻觉机制

在 app/services/ai_service.py 中，我们没有选择简单的“Chat”模式，而是构建了一个基于 RAG 思想的上下文注入系统。

2.1 解决 LLM 的“时间感知缺失”

通用大模型（如 DeepSeek V3）本身没有“今年是哪一年”的实时感知，直接询问流年运势往往会得到基于其训练截止日期的错误回答（例如它可能认为今年还是 2023 年）。

我们在生成 Prompt 时，强制注入了当前的时间锚点：

def generate_prompt(data, ...):
    # 强制注入服务器当前计算出的年份，防止 AI 幻觉
    current_luck = data.get("current_luck", {})
    numeric_year = current_luck.get("meta", {}).get("year_str", "2026年")
    
    base_info = f"""
    【当前时间基准】
    公历年份: {numeric_year}
    流年干支: {liunian_ganzhi}年 (AI请务必基于此年份进行运势推演，不要使用默认训练数据时间)
    """

2.2 合规与安全层 (Safety Layer)

作为面向公众的 SaaS 服务，合规性至关重要。我们在代码中定义了全局常量 COMPLIANCE_DISCLAIMER，并将其硬编码到每一个 System Prompt 的尾部。这强制要求 AI：

语言风格： 必须使用理性、客观的心理学/统计学术语。
负面清单： 严禁出现“注定”、“血光之灾”、“前世今生”等宿命论词汇。
输出规范： 所有预测必须以“倾向”、“潜质”等非确定性口吻表述。

3. 工程实战：CORS 跨域与 Cookie 的爱恨情仇

在前后端分离（前端 VSCode Live Server :5500，后端 Flask :5000）的开发环境中，跨域资源共享 (CORS) 和 Session 丢失 是最耗时的工程坑。

在 app/__init__.py 和 app/config.py 中，我们留下了一组“战损版”的配置，完美解决了 Nginx 反代环境下的 Cookie 传递问题：

# 1. 必须明确指定 Origins，不能用通配符 '*'
# 否则浏览器会拒绝携带 Credentials (Cookie)
allowed_origins = [
    "http://localhost:5500", 
    "https://www.fuxiengine.xyz"
]

# 2. CORS 初始化
CORS(app, 
     supports_credentials=True, # 关键：允许跨域 Cookie
     resources={r"/*": {"origins": allowed_origins}})

# 3. Cookie 策略 (Config.py)
# Lax 是现代浏览器在安全性与可用性之间的最佳平衡
SESSION_COOKIE_SAMESITE = 'Lax' 
# 在非 HTTPS 的开发/宝塔环境中，强制关闭 Secure 也是为了防止 Session 丢失
SESSION_COOKIE_SECURE = False

4. 商业化闭环：卡密与数据模型

项目的变现逻辑并非简单的接入 Stripe，而是设计了一套解耦的 卡密系统 (CardKey System)。

模型设计： CardKey 表（见 app/models.py）包含 code (唯一索引)、key_type (VIP月卡/点数包) 和状态位。
核销流程： 用户在前端输入卡密 -> 调用 /redeem 接口 -> 后端原子化更新用户 vip_expiry 或 credits -> 标记卡密为 is_used。
优势： 这种设计将“支付”与“履约”完全解耦。无论是通过 Crypto 支付、微信转账还是 LemonSqueezy，只要生成对应的卡密字符串即可完成发货，极大地降低了支付网关的对接复杂度。

5. 总结

伏羲引擎 v2.0 不仅仅是一个算命玩具，它是一次将传统算法（lunar_python）、现代 AI 工程（DeepSeek）与 Python Web 最佳实践（Flask Blueprint/SQLAlchemy）深度融合的尝试。它证明了，即使是再传统的领域，通过严谨的代码重构与架构设计，也能焕发出具有现代感的数字化生命力。