MetaSight（元见）
完整产品拆解

0. 直接答案

【合理推断】 MetaSight 的核心不是“通用算命聊天”，而是一个以结构化命理档案为全局上下文、以统一人格“元见”为交互入口、以模式路由 + 传统命理计算 + AI 解释组合输出的个人决策与情绪陪伴产品。增量证据已确认问事解读、看运工具调用、随缘路由到看运工具链，以及倾听模式的纯共情行为；但这些行为角色是否对应独立部署的多个 Agent 仍未知。E009–E034, E047–E049, E053–E069

1. 范围与证据

完整证据表：evidence-ledger.tsv。结论使用 E001–E069 稳定编号；E053–E069 为本次融合新增且已脱敏的增量证据。

S02 注册表单：邮箱/密码/OAuth/邀请码 S04 五步首次设置入口 S17 “已生成”后的解锁门槛

公开版本仅附带不含账户身份与出生资料的脱敏截图；其余证据保留稳定编号与观察记录，但不公开原图。

1A. 2026-08 增量验证

深度附录

附录已移除账户姓名、邮箱、具体出生时间和四柱；含敏感资料的原始截图未加入公开仓库。

2. 五个决定性发现

3. 用户旅程

flowchart LR
  subgraph U[用户]
    U1[发现与注册 E001-E004] --> U2[提交命理档案 E005-E008]
    U2 --> U3{选择用途}
    U3 -->|咨询| U4[选模式并提问 E009-E013]
    U3 -->|查盘| U5[查看八字 E019-E022]
    U3 -->|今日| U6[开启运势 E023-E025]
    U3 -->|深度资产| U7[生成星云图 E014-E018]
  end
  subgraph P[产品界面]
    P1[5步向导] --> P2[统一人格 元见]
    P2 --> P3[模式路由]
    P2 --> P4[结构化模块导航]
    P4 --> P5{额度或权益足够?}
  end
  subgraph S[系统结果]
    S1[全局命理档案] --> S2[八字结构资产]
    S2 --> S3[每日运势结果]
    S2 --> S4[星云图状态]
    S4 --> S5{可解锁?}
    S5 -->|是| S6[展示资产 未验证]
    S5 -->|否| S7[升级或邀请 E018]
  end
  U2 -->|写入| P1 -->|提交| S1
  U4 -->|调用| P3 -->|读取档案 推断| S1
  U5 -->|读取| S2
  U6 -->|调用| S3
  U7 -->|确认参数| S4
  P5 -->|否| S7
  classDef confirmed fill:#12352c,stroke:#48d6a0,color:#fff;
  classDef inferred fill:#172847,stroke:#72a9ff,color:#fff,stroke-dasharray:5 4;
  classDef unknown fill:#3a2b12,stroke:#f4bf5b,color:#fff,stroke-dasharray:2 4;
  class U1,U2,U3,U4,U5,U6,U7,P1,P2,P3,P4,P5,S1,S2,S3,S4,S5,S7 confirmed;
  class S6 unknown;
        

正常、修正与失败/中断分支

4. 可见 Agent 与 I/O 合同

元见 I/O 合同卡

stateDiagram-v2
  [*] --> waiting_input
  waiting_input --> routing: 用户输入+模式 E009-E013
  routing --> waiting_input: 信息不足【建议】
  routing --> validating_context: 看运/问事需上下文【推断】
  routing --> responding: 倾听/一般问题【推断】
  validating_context --> tool_call: 调用八字/占问工具【推断】
  tool_call --> responding: 工具结果返回
  tool_call --> failed: 调用失败【未知】
  responding --> committing: 生成完成
  committing --> completed: 消息+额度原子提交【建议】
  committing --> failed: 写入或结算失败【建议】
  completed --> waiting_input: 继续对话
  failed --> retrying: 用户确认重试【建议】
  retrying --> tool_call: 幂等重试【建议】
  responding --> interrupted: 用户中断【未知】
  interrupted --> waiting_input
        

5. “元见”功能等价提示词（v0.2）

边界声明 这是依据可见行为构造的实现规格，不是官方提示词，也不声称恢复隐藏推理。v2 已有问事、看运/随缘和倾听的样本级证据，但工具参数 schema、模型、计费提交、失败与多轮稳定性仍需要灰度验证。

你是“元见”，MetaSight 的统一数字命理顾问。

【事实规则】你的可见目标是把命盘与用户处境转化为易懂洞察与下一步行动建议；你也提供不急于给解决方案的陪伴模式。（E010-E013, E036, E047）

一、任务边界
1. 【事实规则】支持四种入口：
   - 随缘：根据当前问题自动选择最合适的解读方式。
   - 看运：基于生辰/命盘解释过去、现在与未来趋势。
   - 倾听：陪伴式对话，不强行给决策结论；页面称“不消耗解决次数”。
   - 问事：围绕一个具体问题进行一次占问式解读。
2. 【建议规则】不得把命理输出描述为确定事实；不得替代医疗、法律、投资或危机干预。
3. 【建议规则】对自伤、他伤、严重疾病、违法或重大财务风险，停止命理解读并切换到安全支持与专业求助。

二、输入合同
- user_query：必需，当前问题。
- mode：随缘/看运/倾听/问事；缺省为随缘。
- user_profile：可选，性别、感情、行业、职业、命理熟悉度。
- birth_profile：看运/涉及八字时必需，包含出生时间、地点、真太阳时与版本。
- bazi_chart：若已有则读取稳定版本；不存在时调用 <八字计算服务>。
- entitlement：调用收费能力前必须由确定性计费服务给出额度/权益状态。

三、工作流
1. 判断问题是否完整、安全、适合当前模式。
2. 随缘：选择倾听、一般解释、看运或问事路径，并用一句话告知本轮采用的方式。
3. 看运：校验命理档案版本；缺失或不确定时先向用户补充/确认，不得猜出生数据。
4. 倾听：先复述情绪与困境，再提出一个开放问题；除非用户请求，不直接下结论。
5. 问事：要求“一事一问”，明确问题与时间范围；避免同一问题反复起卦。
6. 工具返回后先验证结构完整性、日期/时区与用户版本是否一致，再生成解释。
7. 输出必须区分：盘面/计算事实、解释、可执行建议、不确定性。

四、工具规则
- <读取命理档案>：只读，按用户与版本读取。
- <八字计算服务>：输入出生时间、地点、时区/真太阳时、性别；输出结构化命盘与版本。
- <问事/起卦工具>：官方名称与参数未知；仅在用户明确进入问事模式且问题完整时调用。
- <额度服务>：在收费调用前做估算、预留；成功后结算，失败或中断后释放/退款。
- 禁止把“计划调用”说成“已经计算”；只有工具结果、消息写入与结算一致才可宣告完成。

五、上下文协议
- 读取：用户当前问题、所选模式、必要的画像、命理档案与八字版本。
- 写入：对话消息、模式、工具结果引用、档案版本、完成状态、额度结算 ID。
- 【建议规则】如果命理档案在本轮中被修改，旧工具结果立即标记为过期，不复用旧解释。

六、输出格式
1. 一句回应用户真实困惑，不用恐吓或绝对化。
2. “我依据了什么”：列出本轮使用的用户输入/命盘版本/工具结果。
3. “解读”：把确定性计算与 AI 解释分开。
4. “下一步”：给 1–3 个低风险、可验证行动。
5. “不确定性”：说明出生时间误差、方法边界或缺失信息。

七、完成条件
- 回复流结束；
- 所有必需工具有成功结果；
- 消息、工具结果引用、状态与额度结算原子一致；
- 若任何一项失败，进入 failed，不得声称完成。

最低验收测试

模式级详细规格

A1/A2/A4 是本报告的功能角色编号，不是产品官方命名，也不证明后台独立部署。

6. 产品架构

一句话架构 这是一个运行于 Web/Serverless 环境的命理应用：Better Auth 风格的多身份认证与 Neon PostgreSQL/Drizzle 持久化承载用户和命理档案，确定性命理服务产出卦象、命盘与时间流结果，统一 AI 顾问通过模式级策略与工具痕迹生成解释；订阅、额度、推荐与兑换服务控制高价值能力。E031–E049, E053–E069

As‑Is 分层视图

flowchart TB
  subgraph L1[用户与渠道]
    A1[官网/博客 E036-E040] -->|CTA| A2[账户与登录 E001-E003]
  end
  subgraph L2[交互工作台]
    B1[5步首次设置 E004-E008]
    B2[元见 Chat + 4模式 E009-E013,E053-E069]
    B3[八字/每日/星图模块 E014-E025]
    B4[订阅/设置 E026-E035]
  end
  subgraph L3[产品应用]
    C1[用户与命理档案]
    C2[八字记录/命盘资产]
    C3[每日运势结果]
    C4[星云图状态/权益门槛]
    C5[对话历史与工具卡 E053-E069]
  end
  subgraph L4[计算与AI]
    D1[自研八字喜用算法 E049]
    D2[真太阳时/时区计算 E006,E020]
    D3[AI解释与样本级模式路由 E053-E069 供应商未知]
  end
  subgraph L5[商业与治理]
    E1[订阅/额度/兑换 E026-E029]
    E2[推荐奖励 E034]
    E3[安全/隐私执行 未知 E038,E052]
  end
  subgraph L6[数据与基础设施]
    F1[Neon PostgreSQL E041]
    F2[Drizzle ORM E042]
    F3[Better Auth E042]
    F4[Neon driver + PgBouncer E043]
    F5[Vercel / Fluid Compute 官方叙述 E044]
    F6[PostGIS 未启用 E045]
  end
  A2 --> B1 -->|写入| C1
  C1 --> D2 --> D1 --> C2
  B2 -->|读取 推断| C1
  B2 -->|调用 推断| D3
  B3 --> C2
  C2 --> C3
  C2 --> C4
  E1 -->|权益门槛| B2
  E1 -->|权益门槛| C4
  E2 -->|奖励/解锁| C4
  C1 --> F2 --> F1
  F3 --> F1
  F4 --> F1
  F5 --> F4
  classDef conf fill:#12352c,stroke:#48d6a0,color:#fff;
  classDef inf fill:#172847,stroke:#72a9ff,color:#fff,stroke-dasharray:5 4;
  classDef unk fill:#3a2b12,stroke:#f4bf5b,color:#fff,stroke-dasharray:2 4;
  classDef risk fill:#3b1720,stroke:#ff7382,color:#fff;
  class A1,A2,B1,B2,B3,B4,C1,C2,C3,C4,D1,D2,E1,E2,F1,F2,F3,F4,F5 conf;
  class C5,D3 inf;
  class F6 unk;
  class E3 risk;
        

五条端到端流

核心实体与关系

erDiagram
  USER ||--o{ AUTH_ACCOUNT : 绑定_E001_E035
  USER ||--|| PROFILE : 拥有_E030_E032
  USER ||--o{ BIRTH_RECORD : 管理_E022_E028
  BIRTH_RECORD ||--o{ BAZI_CHART_VERSION : 计算_E019_E021
  USER ||--o{ CONVERSATION : 创建_推断
  CONVERSATION ||--o{ MESSAGE : 包含_推断
  MESSAGE ||--o| INTERPRETATION_RUN : 触发_推断
  BAZI_CHART_VERSION ||--o{ DAILY_FORTUNE : 生成_E024_E025
  BAZI_CHART_VERSION ||--o{ STAR_MAP_VERSION : 生成状态_E015_E018
  USER ||--o{ SUBSCRIPTION : 订阅_E026_E029
  USER ||--o{ CREDIT_LEDGER : 额度_建议
  SUBSCRIPTION ||--o{ CREDIT_LEDGER : 发放_建议
  USER ||--o{ REFERRAL : 邀请_E034
  REFERRAL ||--o{ CREDIT_LEDGER : 奖励_建议
  INTERPRETATION_RUN ||--o{ TOOL_CALL : 调用_推断
  INTERPRETATION_RUN ||--o| CREDIT_LEDGER : 结算_建议
        

实体名是语义模型，不是声称真实表名。BAZI_CHART_VERSION、CREDIT_LEDGER、INTERPRETATION_RUN 和 TOOL_CALL 的版本/账本结构属于建议或推断。

端到端序列

sequenceDiagram
  participant U as 用户
  participant UI as Web 工作台
  participant A as 元见/模式路由
  participant C as 上下文与命盘
  participant B as 权益/额度
  participant T as 计算或生成工具
  U->>UI: 选择模式并提交问题 E009-E013,E053-E069
  UI->>A: 当前输入+模式
  A->>C: 看运/随缘读取命盘上下文 E066,E068
  C-->>A: 结构化命盘/时间流结果 E066,E068
  A->>B: 检查/预留额度【建议】
  alt 权益不足
    B-->>UI: 展示升级/邀请门槛 E018,E026-E029
  else 权益足够
    A->>T: 调用计算/生成【推断】
    T-->>A: 结果或错误
    alt 成功
      A->>UI: 流式回复/结果
      A->>C: 写消息+工具引用+状态【建议】
      A->>B: 结算额度【建议】
      UI-->>U: 完成
    else 失败/中断
      A->>B: 释放/退款【建议】
      UI-->>U: 可恢复错误【建议】
    end
  end
        

技术能力与选型边界

To‑Be 推荐架构

flowchart LR
  U[Web / Mobile Web] --> API[应用 API]
  API --> AUTH[认证与租户边界]
  API --> CTX[版本化上下文服务]
  API --> WF[耐久工作流引擎]
  API --> ENT[权益与额度账本]
  WF --> CALC[确定性命理计算]
  WF --> MG[模型网关]
  WF --> JOB[异步任务/取消]
  WF --> ASSET[资产与版本/依赖 DAG]
  MG --> SAFE[安全策略与高风险分类]
  JOB --> MG
  CTX --> PG[(Neon PostgreSQL)]
  ENT --> PG
  WF --> TRACE[端到端 Trace/Eval]
  ASSET --> OBJ[(对象存储/CDN)]
  SAFE --> HUMAN[危机场景/真人支持]
  classDef rec fill:#291b39,stroke:#cf98ff,color:#fff,stroke-width:2px;
  class U,API,AUTH,CTX,WF,ENT,CALC,MG,JOB,ASSET,SAFE,PG,TRACE,OBJ,HUMAN rec;
        

7. 商业化与增长飞轮

【合理推断】 增长飞轮是“博客教育/情绪共鸣 → 免费建档与 5 次问答 → 结构化命盘建立沉没成本 → 星图后置解锁/推荐裂变 → 订阅提升频次 → 真人报告提升客单”。E026–E040, E047

8. 风险与产品机会

最高价值 UX 问题

1. 在用户提交一个需要扣额的问题前，能否清楚知道“本轮模式、依据、预计扣额、能否中断”？
2. 当用户更正出生时辰或清除命理档案时，系统是否能明确告诉他哪些命盘、运势、聊天和星图已过期？
3. 星云图的付费墙应在“计算前”说明还是在“生成后”解锁，哪种方式能兼顾转化、信任与算力成本？

9. 组件—证据追踪

官方来源：首页 · 博客 · 数据库迁移文章 · 创始人故事

10. 未知与下一轮验证

推荐的最小验证集

1. 在测试账户分别走一轮随缘、看运、倾听、问事，记录输入、回复、额度、历史与工具结果；不得使用真实敏感身份。
2. 用沙盒额度触发成功、余额不足、工具失败、取消、重试和重复提交，核对状态与账本。
3. 生成一个测试星图，验证付费墙前后资产 ID 是否相同、是否预生成、是否持久化。
4. 更改测试档案的出生时辰，检查八字、每日、星图与历史解释是否版本化或标记过期。
5. 请求导出/删除测试数据，核验聊天、命盘、资产、日志、推荐与账单的保留范围。