起因：一个阅读痛点
追《凡人修仙传》，2000 多章。放下几个月再拿起来，满脑子都是"这人谁来着""南宫婉和那个妖女是什么关系""这个宗门之前出现过吗"。
我相信每个追长篇网文的读者都被这个问题折磨过。
后来越想越觉得，这件事 AI 应该能干——逐章读完一本小说，把人物关系、地点、势力、事件都提取出来，画成图谱。于是年初我给自己定了一个挑战：用 Claude Code，不写一行代码，看看能不能从零做出来。
第一轮尝试：需求散乱，产出也跟着松散
过程比想象的顺利。我把想法跟 Claude 聊了一轮，它给了一份看起来挺靠谱的架构文档。我建了个目录，把聊天记录存成 markdown，然后打开 Claude Code，跟它说：按这个文档开始写。
几天之后，东西真的跑起来了。React 前端、FastAPI 后端、SQLite 存储，都有了。
但用起来就知道问题了——功能东一块西一块，像是把需求碎片拼在一起，不是一个连贯的产品。原因很简单：我的需求本身就是散的，AI 做出来的东西自然也散。
最早的版本甚至没有 UI，我通过聊天窗口获取 AI 理解的小说内容（比如小说的世界地图的层级树）。
这是我在整个过程中学到的第一课：AI 的产出质量，上限就是你需求的质量。
转折：找到 BMad Method，重塑工程化思维
我开始研究 AI Agent 相关的软件工程方案，最终找到了 BMad Method 这个敏捷开发 Agent 仓库。这是整个项目的真正转折点。
它提供了一套完整的软件工程 workflow——PM、UX 设计师、架构师、开发者，每个角色都有对应的 AI Skill。我让 Claude Code 引入 BMAD，然后重新来过。
这一次体验完全不同：先让 PM Skill 写了一份正经的 PRD，功能优先级、用户故事、验收标准都列清楚。然后让 UX Skill 做交互设计——页面布局、信息层级、操作流程。接着才是架构设计和开发。
突然之间我找到感觉了：我不是在写代码，我是在管一个团队。
BMad 的 UX 技能，甚至直接帮我给出了专业的 excalidraw UI 交互设计稿
我突然意识到，在 AI 时代，编程的定义已经发生了根本性的变化。不再是亲力亲为地写每一行代码，而是学会如何定义需求、如何拆解任务、如何验收结果。代码能力依然有价值，但如何高效地「使用 AI 来编程」，可能变成了更重要的能力。
春节假期期间高频迭代，1 周多完成了 30+ 个版本。这个过程太爽了——想到问题，写出需求，马上就实现。最终有了 AI-Reader-V2：
- 官网：ai-reader.cc
- GitHub：mouseart2025/AI-Reader-V2
做出来了什么
先说最直观的——你扔一本 TXT 小说进去，AI-Reader 会尝试分析章节，幸运的话，你会看到自动划分好的章节（小说格式比较规范）。如果格式不规范，可能需要使用正则模板做一些手动尝试。
导入封神演义的 txt文件，在导入面板会进行章节划分。
然后给你生成这些东西：
1. 人物关系图谱
这是最有视觉冲击的功能。AI 能自动识别 70 多种关系类型，用 6 种颜色分类标注。最让我满意的是别名合并——西游记里孙悟空、行者、齐天大圣、美猴王、孙大圣、老孙、猴王……十几个称呼，系统能自动识别成同一个角色。（这个功能调了很久，最近刚修好一个关键 bug。）
人物关系图谱给出了一种更直观了解小说人物关系的视角。不同线的颜色代表不同的关系类型，不同点的颜色代表角色所在的组织。用户也可以通过左上角的滑块，显示指定章节范围内的角色关系。
点击人物节点会打开人物卡片，展示别名、外貌、关系、能力、物品、足迹、经历、参与场景等信息——全部来自 AI 逐章阅读的提取结果。
我甚至分析了整部《凡人修仙传》，2000+ 章，700 万字，提炼出 2480 个人物、4484 条关系。大量红色线条（敌对关系）真实反映了这个小说弱肉强食的主基调。
2. 多层级世界地图
从文本提取地点和空间关系，自动生成手绘风格地图（河流网络、生物群落着色、地形纹理、轨迹动画）。现实背景小说自动匹配真实地理坐标。这个功能是项目中花费时间最多的——让 AI 理解并描绘小说的空间世界是件极其复杂的事情，目前效果离游戏地图还有差距。这似乎也是一个学术难题，如果大家有好的思路，欢迎一起探讨。
AI 想象中的《西游记》的幻想版世界地图
对于像《神秘岛》包含大量现实世界的地名，我的这个工具会调用现实世界地图来展示小说中提到的地点。
对于像《平凡的世界》这种在现实基础上虚构的地名，AI-Reader 也能画出感觉像那么回事的地图。
3. 时间线 — 6 源事件聚合，情绪标注，智能降噪，可按人物筛选泳道。
时间线可以选择不同事件类型进行筛选，也可以通过右侧的泳道，选择指定人物的事件。
4. 百科全书 — 5 类实体卡片，场景索引，世界观概览。
凡人修仙传提炼了 20644 个实体，每个都有独立资料卡。
5. 智能问答 — 基于 RAG 的原文溯源对话，依据结构化数据回答，给出章节出处。
问答功能，用户设置的 AI（本地或云端大模型）会依据习得的结构化数据进行分析，给出答案。
6. 智能阅读 — 实体高亮（5 种颜色区分人物/地点/物品/组织/概念）、剧本模式（快速跳转到指定场景段落）、书签。
AI 分析过的小说，在左侧章节列表会添加绿点标记，对已经分析过的小说，可以开启“剧本”模式，读者可以在右侧剧本场景快速跳转到指定场景段落。
AI 自主决策技术架构
技术上多说几句。说实话这些技术选型我自己也不算真正「懂」——都是 Claude Code 建议的，但我至少知道它们各自在干什么，这里用人话解释一下：
前端是一整套现代 Web 技术栈。 React 19 + TypeScript 负责页面逻辑，Tailwind CSS + shadcn/ui 管样式和组件（就是你看到的那些按钮、卡片、弹窗），Zustand 做状态管理（让不同页面之间共享数据）。可视化是这个项目最重的部分——人物关系图谱用的 react-force-graph-2d（力导向图，节点之间会像弹簧一样自动排布），世界地图用了 D3.js + SVG 做手绘风格渲染，现实地理坐标匹配则用 react-leaflet（就是你看地图 App 时那种可缩放拖拽的地图）。整个前端用 Vite 7 打包构建，开发时热更新秒级生效。
后端是 Python + FastAPI。 全异步架构，数据库用 SQLite（单文件，不用装数据库服务），每章的分析结果（ChapterFact）存成 JSON——人物、关系、地点、事件都在里面，实体档案在需要时才聚合，不单独建表。向量检索用 ChromaDB + BGE 中文 embedding 模型，让智能问答能做语义搜索（不只是关键词匹配，而是理解意思去找相关段落）。中文分词用了 jieba，主要用在分析前的实体预扫描——先统计高频词，再让 LLM 分类，这样正式分析时实体识别的准确率会高很多。
桌面端用 Tauri 2 打包。 Tauri 是用 Rust 写的桌面应用框架，比 Electron 轻很多。Python 后端被 PyInstaller 打成一个独立的二进制文件（叫 sidecar），Tauri 启动时自动拉起，用户完全无感——双击安装包就能用，不需要装 Python 也不需要配环境。macOS DMG 约 100MB，Windows EXE 约 130MB。
LLM 灵活度拉满。 本地跑 Ollama 的话默认用 qwen3:8b，8G 显存就能跑，但我这个 M1 的 macbook pro ，Ollama本地模型分析西游记一个章节差不多要半小时；想要更好的效果可以接云端 API，DeepSeek、MiniMax、通义千问、Moonshot、智谱、SiliconFlow、零一万物、OpenAI、Gemini、Anthropic，10 家供应商都支持，在设置里填个 API Key 就能切换。分析质量主要看模型能力——本地小模型够用但粗糙，云端大模型明显更准。系统还会根据模型的上下文窗口大小（8K 到 128K 不等）自动调整截断长度、摘要限制、超时时间这些参数，不用手动改配置。我目前主力分析模型MiniMax 2.5，主要是速度够快且便宜，分析西游记一个章节 2-3 分钟即可。
设置 AI 引擎可以选择本地 Ollama 还是云端 API，并提供了性能测试功能，MiniMax-M2.5 除了速度够快，也很经济。
诚实地说，AI 不行的地方
别名合并是个大坑。 "妖精""那怪""泼猴"这些泛称会桥接不相关角色。修仙小说里"前辈""道友""师兄"满天飞。最终方案是 Union-Find + 多层安全过滤 + 章节证据阈值合并，前后花了很多轮才调好。
地图质量很难自动保证。 空间关系在小说里经常模糊甚至矛盾（作者自己都忘了），需要大量后处理——冲突检测、层级修正、约束求解。
需求不清晰 = 废代码。 第一版就是教训。说"帮我做个小说分析工具"，AI 做出来的东西真的很泛。必须把需求拆细，说清楚交互逻辑和验收标准。
写在最后
AI 时代，把想法变成产品的门槛大幅降低了。 但门槛降低不等于消失——你仍然需要想清楚做什么、为谁做、做成什么样。
核心是找到一种方法把你的需求结构化地表达出来，然后交给 AI 执行。
项目开源（AGPL-3.0）：github.com/mouseart202…
官网 Demo：ai-reader.cc
Tags: AI, Claude Code, Tauri, FastAPI, LLM应用, 开源项目, 独立开发