两个月前我想看自己的紫微斗数命盘，朋友说"自己学吧"。于是我买了三本书，看了二十几个视频，依然分不清天府和天相到底谁管什么。
我不是学不会，是发现一个问题：紫微斗数的信息密度极高，一张命盘十二个宫位、上百颗星、四化飞星、大限流年层层叠加 —— 但我只是想知道"今年下半年该不该换工作"。
所以我做了 卦相：一个紫微斗数 AI 助手。让 AI 当翻译，把古文术语变成我能听懂的话。
做完才发现，这个"翻译"的动作里，藏着四个我事先不知道的教训。
一、第一版上线，盘是错的
最早我让 Claude 直接根据生辰排命盘 —— 它见过那么多紫微斗数的书，应该行吧？
用自己生日测了三次，紫微星的位置每次都不一样。质问它，它每次都说"抱歉我重新算"，然后吐出一个新的错误答案。
错在哪？农历转换、节气切分、闰月判定、时辰交界 —— 这些是精确规则，不是"大概知道"就够的知识。1991 年农历四月初三对应公历几号，LLM 没法靠"推理"得出正确答案，它只能猜，而且猜得非常自信。
我换了架构：底层用 iztro 这个开源排盘库做精确计算，AI 只负责"解读"那一层。
事实层（排盘计算）→ 规则引擎，零容错
解读层（命盘分析）→ LLM，发挥空间大这条教训听起来像废话，但它是 AI 产品里最常见的死法：因为模型"看起来能做"，你就忘了验证答案对不对。排盘错了用户不一定发现，但一旦发现，所有信任归零。把"不能错的"和"可以有弹性的"分开，是 AI 产品架构的第一刀。
二、那条消息："为什么要等好久好久"
上线第七天，一个朋友测完发了句：
"为什么不用流式输出，现在要等好久好久。"
我心想不可能，我明明做了流式。翻代码，脸热了 —— 我写的"流式"长这样：
// 我以为的"流式输出"
for (const char of response.content) {
await sleep(10);
}先等完整 response 返回，再逐字吐给前端，每个字延迟 10 毫秒。
这不是流式，这是逐字延迟器。用户体感是"前面卡死五六秒，然后一阵狂刷" —— 比纯阻塞还糟，因为白白多了打字机动画的耗时。
改成真正的 SSE 流（从 Anthropic API 边收边推），顺手把 Claude 的 extended thinking 也实时展示 —— 用户能看到模型在"想什么"，等待就从焦虑变成了参与。
这件事的真正教训不是"要做流式"。是这个：用户感知的"AI 好慢"，十次有八次不是模型推理慢，是中间层在假装流式。这种 bug 不会触发任何性能告警 —— 延迟只发生在"收到响应之后"，监控看到的一切指标都正常。只有真用户的一句抱怨能抓到它。
三、多轮 Agent 比完美 Prompt 重要十倍
在做 agent 之前，我花了大量时间调 prompt。改了几十版，每次觉得"这次差不多了"，下一个测试用例又翻车。
核心矛盾是：一个 prompt 装不下"看整盘格局 → 看具体宫位 → 看流年触发 → 综合判断"这个推理链。你写得越长越详细，模型反而越容易在某个环节偷懒。
后来重构成 agent 状态机，最多 10 轮推理：
thinking → planning → tool_calling → reflecting → responding → completed工具只有三个：
generate_astrolabe：排盘get_palace_detail(name)：查某个宫位的星曜和四化get_yearly_fortune(year)：查流年运势
同一个问题 ——"我今年事业怎么样"—— 两种架构的输出差距是这样的：
Prompt 版（一次性生成）：
"事业宫有天机星，主变动，今年可能会有一些调整和变化。建议保持灵活心态，把握机遇……"
听起来面面俱到，换一张命盘几乎能原封不动地套用。
Agent 版（四轮推理）：
第 1 轮：generate_astrolabe → 看整体格局，发现命主是杀破狼格局，天生适合变动
第 2 轮：get_palace_detail("事业宫") → 七杀坐事业宫，化权在迁移宫，外部机会大于内部晋升
第 3 轮：get_yearly_fortune(2026) → 流年化禄飞入事业宫，6-8 月形成双禄交驰
第 4 轮：综合输出 → "今年 6 到 8 月会有一个被动的机会找上门，但它不会自己变成 offer —— 你需要主动开口谈条件。"
差距不在模型本身的能力，在于它有没有"自己去拿信息"的机会。给一个工具箱让模型按需取用，远比雕琢一个完美 prompt 有效。
四、命盘是表，问题才是钥匙
做着做着我意识到一件事：紫微斗数可能是最适合做 AI 对话产品的命理体系。
不是因为它神秘，而是因为它的信息结构天然契合 LLM 的工作方式 ——
传统命理产品是这样的：输入八字 → 输出一份几千字的 PDF 报告。但同一张命盘，问"什么时候结婚"要看夫妻宫和大限福德，问"该不该换工作"要看事业宫和流年命宫 —— 看的是完全不同的切面。
这就是固定报告永远隔靴搔痒的原因：它假设每个用户来的时候，问题都一样。
AI 对话天然是"带着问题来"的交互形态。你此刻的困惑是什么，它就帮你翻开命盘的对应那页。命盘是一本书，问题才是书签。
这个洞察可以泛化：任何"底层数据丰富 + 用户问题多样"的领域 —— 法律、医疗、个人财务 —— 静态报告都是上一代产品形态，动态对话才是下一代。
结尾：产品经理的第一个 vibecoding 项目
这是我作为产品经理做的第一个 vibecoding 项目。
不是 demo，不是 toy project —— 数据库 schema、行级权限策略、SSE 流式响应、agent 推理引擎、多轮工具调用、三语国际化，除了支付，一个线上产品该有的东西它都有了。React + Supabase + Claude + Cursor，全程一个人，从想法到上线。
五年前这张清单摆出来，我会说"得找个全栈工程师"。今天我自己写完了。不是因为我突然会写代码了，是工具链让"一个有产品感的人直接把东西做出来"这件事，第一次真的可行。
技术不再是瓶颈。有想法、且愿意动手，才是。
做完之后最让我上瘾的感觉不是"我居然会写代码了" —— 是画完最后一个功能的那天晚上，看着它跑起来，意识到从今以后，我想到一个东西，就可以直接去做。不用等团队，不用写需求文档说服别人，不用先问"这个技术上能实现吗"。
想到就能做。这个感觉一旦有过一次，就再也回不去了。