一个没有真实用户数据的个人AI产品MVP，基于倪海厦学习资料构建。本文从产品假设、内容加工到问答路线，详细拆解了从资料结构化到Hybrid RAG的完整决策过程，并坦诚展示了当前测试结果与用户验证之间的差距，为知识类AI产品设计提供了可参考的实现样例。

这是一个没有真实用户数据的个人 AI 产品 MVP。

项目基于倪海厦相关学习资料整理，和官方没有关联，只供学习研究。本文使用了项目过程文件、Git 提交和我以前的记录。AI 协助资料核对、提纲梳理和部分文字整理；产品取舍、事实边界、截图与最终删改由我确认。

我能说明项目做了哪些选择，当前代码通过了哪些检查。真实用户是否觉得入口清楚、回答是否有帮助、使用以后会不会再来，这些问题还没有数据支持。

第一个假设先让资料可以进入

项目开始时，我手里有 231 项资料，大约 1GB。格式包括 PDF、Markdown、Word、JSON 和少量其他文件。原有目录已经做过分类，日常使用仍然会卡在几个很具体的地方。看到一个概念以后，我不知道它和哪些内容相连；想系统地看，又要重新判断先后顺序。

我当时的产品假设很简单。对于这类学习资料，用户需要先知道有哪些内容、从哪里开始，随后才会形成具体问题。

这个假设没有经过用户研究验证。它来自我整理和使用这批资料时遇到的麻烦。为了尽快检查方向，我先做了 12 个样例节点，用它们验证卡片模板和链接格式，随后扩成人纪、天纪学习路径和可交互图谱。

6 月 7 日上线的第一版网站有总览、学习路径、知识图谱、节点卡片、天纪提示词和全局搜索。当时没有 AI 问答。发布记录留下的选择很清楚，第一阶段先验证资料能否变成可以浏览的结构。

这个选择也决定了首页的分工。刚接触内容时可以先看路径；知道一个概念后，可以从图谱找到上下游，节点卡片负责给出较完整的解释。问答后来加入，用来处理已经能够说清楚的问题。

四种入口目前只是产品设计和可操作 Demo，还没有证据说明用户会按这个顺序使用。现阶段可以检查导航、跳转和内容是否成立，入口假设仍需要真实行为数据验证。

同一批资料要支持三种任务

页面结构确定以后，我开始处理背后的内容。

资料清点先暴露了基础问题。旧清单数字和实际目录不完全一致，其中还有一个 0B 文件。部分内容有 OCR 噪声，来源也并非全都明确。中医医案和处方剂量又涉及公开边界。于是我先记录格式、大小和来源，再标记空文件、缺项和风险内容。

随后，这批内容沿着不同用途继续加工。当前站点包含 64 个图谱节点和 5 篇主题文章，共 69 个内容项，节点间有 338 条有向关系。问答侧归并为 11 组语料，生成 4,852 个检索块。

这几个数字的口径不同。231 项是本地资料审计结果，不等于全部进入公开网站。69 个内容项面向阅读和关系浏览，4,852 个检索块面向机器召回，二者也不能互相替代。

实际处理时，我需要同时照顾三种任务。资料来源和版本要能回查，概念之间要能建立关系，用户提问以后还要拿到足够完整的证据。原始文档适合连续阅读，直接按固定长度切开容易混入相邻主题；图谱节点能表达关系，内容长度又未必足够回答问题。

我对这一阶段的判断是，知识结构和检索结构应分别加工，来源信息贯穿其中。这样做增加了维护成本，却能在回答出错时继续追到原始资料，而不必只盯着最后一段生成文字。

问答路线没有一次定型

AI 问答在 7 月 9 日才进入项目。第一版把腾讯元器公开页嵌进网站，同一天又换成站内原生输入框，加入代理和多个后端地址。7 月 10 日接入 CloudBase AI SDK，统一问答路由和最初的 Router 测试也在这时加入，小程序随后上线问答。

7 月 18 日，小程序改为直接调用 CloudBase Agent，之后为了绕开 Agent 计费限制，又迁移到直接调用大模型。第二天，项目接入完整语料、BM25 检索、医疗拦截和限流，形成 Hybrid RAG。

这段 Git 历史对我有两个提醒。技术方案会受费用、部署环境和回答依据影响，能跑通的方案未必适合继续用。产品复盘也不能只画最终架构，方案更换时暴露的约束往往更有价值。

一个 Badcase 让我回到检索结果

问答跑起来后，我用“紫微星、天府星有啥用”做过一次对照。系统返回了天纪相关内容，答案却缺少官带星、三台八座等直接信息。高位结果里出现了学习路径、文件清单、三才框架和排盘表格，真正解释紫微星的块只有 38.72 分，排在第 10 位。

这个现象说明相关性还不够。用户点名了两个实体，系统应该优先拿到对应章节。目录和表格虽然也含关键词，却不该挤掉专项内容。

我先检查分块和排序，没有先改回答语气。固定长度分块把几个星曜混到同一块里，同一来源组最多返回两条，专项章节因此少了一次进入上下文的机会。

后续修改落在检索侧。返回数量从 5 增加到 12，星曜章节重新拆成语义块。标题和用户点名实体提高权重，查询扩展词保留四分之一权重。目录、OCR 表格和文件清单在普通概念问答中被压低，同一来源组的上限从 2 调到 4。

本地重建以后，前三条结果依次覆盖天府星、紫微星、左辅右弼与三台八座。这个回归结果能证明检索条件发生了预期变化。回答在真实用户眼里是否更清楚，仍需要另外验证。

安全规则进入真实问答过程

项目包含中医理论、方剂和医案，学习问题与现实诊疗请求需要分开处理。系统可以解释经典材料，遇到诊断、处方、剂量、服法或个体治疗决策时，不继续给出可执行建议。

这条边界落在输入检查、输出检查、无关问题拒答和请求限额里。回答下方同时显示引用资料，使用者可以继续核对内容来源。

这些规则属于产品安全设计。目前没有外部医疗合规认证，公开说明也要停在这个范围内。

149 项测试能证明到哪里

8 月 14 日，我在干净的 main 分支复跑了当前版本。Router 测试 33 项通过，小程序测试 116 项通过。站点数据校验也通过，69 个内容项、5 篇主题文章、338 条有向关系和 0 条悬空关系都能对应。

这些结果说明测试覆盖的功能、检索和安全行为没有退化。它们没有回答用户价值问题。当前项目缺少真实用户量、留存、学习效率和满意度数据，也没有企业客户采用或商业交付证据。

下一轮验证需要把问题落到实际使用上。我会先观察第一次进入的人从哪个页面开始，记录搜索词和提问，再看哪些回答被继续追问，哪些引用资料解决不了问题。样本足够以前，我只把项目称为可操作的个人 MVP。

企业内部资料也可能遇到来源、关系、检索和权限问题。这个项目可以作为一套缩小后的实现样例，迁移价值仍需放到具体业务资料和用户任务里重新验证。

项目 Demo 在这里

https://www.nihaixia-knowledge.xyz/