全程不写一行代码,我如何用 AI 做出一个复杂的小说分析系统
主要发现问题：
1. “Claude Code” 不准确。Anthropic 并没有一个叫“Claude Code”的产品。您指的应该是 Claude（或 Claude 的代码能力）。文中所有“Claude Code”都会改为“Claude”（或必要时保留语义，如“让 Claude 写代码”）。
2. “BMad Method” 并非广为人知的正式工程方法，更像是您采用的某个个人/社区项目。为尊重原文，保留名称，但会调整表述为“一个叫 BMad Method 的 Agent 工程方案”，不包装成标准方法。
3. InkOS 和 Sumeru 这两个工具名称无法确认真实性，很可能是指代性的示例。为了不误导读者，我将它们改称为“有的项目采用……架构”“另一种思路把创作拆分成技能模块”等模糊化表述，保留对比思路，去掉具体不确指的产品名。
4. 数据准确率 92%（抽查 50 个节点）——合理，保留。
5. 其他细节（如《凡人修仙传》情境举例、2000 章、37 章和 182 章等）均属合理叙述，不再改动。
6. 文中没有出现指定的 AI 味词汇（值得注意的是/总而言之/综上所述/不难发现/众所周知/毋庸置疑/在当今社会/随着……的发展/让我们一起/深入探讨/全面解析/不可否认/毫无疑问），因此不需要删除这些词。但部分句子对仗工整（如三点建议、三条原则），我会打散节奏。结尾重复句也会合并优化。
以下是修改后的最终版本：
你有没有过这种憋屈？
追一部小说追到两千多章，放下几个月再拿起来——满脑子都是“这人谁啊？”“南宫婉和那个妖女什么关系？”“这个宗门之前出现过吗？”
我打赌，追过长篇网文的人都懂这种痛！
但我比你还离谱。记不住人名，每次跳几章就得往回翻人物关系。后来干脆搞了个 Excel，手动记角色出场章节——自己都觉得好笑。
年初我给自己下了个战书：用 Claude（不写一行代码）从零搭一个小说分析系统。把人物关系、地点、势力、事件全提取出来，画成图谱。
你想想，当时市面上没有一个工具能干这事——包括那些吹得震天响的“AI 阅读助手”。
就问你狂不狂？
第一巴掌：需求散，产出就散
开始的时候，我把想法跟 Claude 聊了一轮，AI 给我一份看着挺靠谱的架构文档。
我建了个目录，存成 markdown，打开 Claude 让它开干。
几天后，东西真跑起来了！
React 前端、FastAPI 后端、SQLite 存储，全齐了！
……然后一用就崩。
功能东一块西一块，像把需求碎片随手拼在一起，根本不是连贯的产品。
举个例子：角色关系图能看了，但你点一个角色，详情面板是空的。后来补了面板，可面板和图之间完全没联动。
这还不是最要命的——让 AI 提取人物关系，它一会儿按章节，一会儿按卷，输出格式来回变，跟人格分裂似的。
后来我想明白了：根源就是我的需求本身就是散的。AI 的产出质量上限，就是你的需求质量。
这一课，太值了。
转折：BMAD 一来，我从“码农”变成了“产品经理”
我开始翻 AI Agent 相关的软件工程方案。
说实话，市面上很多方案华而不实，动不动“AI 颠覆开发”，一上手全是坑。
直到我撞见一个叫 BMad Method 的 Agent 工程方案。
这才是真正的转折点。
简单说，它提供了一套完整的软件工程 workflow：PM、UX 设计师、架构师、开发者，每个角色都有对应的 AI Skill。
我让 Claude 引入 BMad，重新来过。
这次体验完全不同了——
- 先让 PM Skill 写了一份正经的 PRD：功能优先级、用户故事、验收标准，列得清清楚楚。
- 再让 UX Skill 做交互设计：页面布局、信息层级、操作流程，一步到位。
- 接着才是架构设计和开发。
你猜怎么着？
我突然找到了感觉：我不是在写代码，是在管一个团队。我负责想清楚“做什么”和“做成什么样”，AI 负责“怎么做”。
有个细节特别有意思：以前我自己写代码时，经常边写边改需求，因为改代码比改需求文档容易。现在反过来了——需求文档写得越清楚，AI 产出的代码问题越少。
你让 AI 猜需求，它给你一堆 AI 味的功能。
元可计算：把“理解小说”变成工程问题
这是最兴奋的部分。
AI-Reader 要解决的核心是“理解一部小说”——这个本质依赖主观审美、不可计算的问题。
我借鉴了一篇讲元可计算的文章的思路，把“分析小说”这个模糊需求，提炼为严格的图论与拓扑学问题：
- 人物被定义为图节点：命名实体出现频次超过阈值，且经指代消解验证。
- 关系则作为边：基于共现窗口与动词谓语的语义匹配。
- 地理则是层级树：空间介词与方位词的递归嵌套结构。
同时还引入了验证机制。通过图连通性算法检查是否有孤立节点（叙事断裂）；通过拓扑排序验证时间线因果（事件 A 必须早于事件 B）；通过空间约束求解器检测地理描述的矛盾（第 5 章“往北走”，第 20 章“往南退”——必须对得上）。
但我也踩了一个大坑：AI 把“妖精”“道友”这种泛称当成了具体角色名，人物关系图里冒出几十个不存在的角色，聚类全乱套。
最后我引入 Union-Find 算法和章节证据阈值修正实体消歧规则——说白了，就是让 AI 判断“这个词到底是不是人名”。
这个过程让我彻底悟了：AI 不能解决一切问题，但 AI 加形式化验证，能解决大部分问题。
顺便看看隔壁的思路，路子完全不同
做到一半的时候，我好奇翻了一下市面上的 AI 辅助写作方案，发现路子完全不同。
有的项目采用“五员大将”架构——雷达、建筑师、写手、审计员、修订者接力。核心痛点是“长篇连载的连续性”，用真相文件和交叉检查防止设定崩塌。试了一下，写网文确实好用，但它的“审计员”本质是事后检查：你先写出来，它再查漏洞。AI-Reader 则是事前分析——提取已有文本，建立关系图谱。
另一种思路是把创作技能化——worldbuilder、outline、write、review、polish，每个环节边界清晰，中间数据持久化。优势是“从 0 到 300 章”，把重复劳动变得可执行。但问题也明显：批量生产导致节奏松散、人物行为偶尔不自然。
你看，每个思路各有适用场景，不是谁取代谁的问题。AI-Reader 的定位就是分析，不是创作，跟它们不冲突。
Prompt 调教：AI 不会天生提取小说信息
整个项目最磨人的环节不是开发，而是通过 Prompt 调教 AI 提取信息的准确率。
角色提取我用了“资深文学编辑”人设的 Prompt：「请阅读以下章节文本，提取所有出现的有名字的角色（包括配角）。输出格式为 JSON 对象列表：姓名、角色定位、特征。注意：只输出提取的结果，不要输出代码块标记。」
这段 Prompt 迭代了十几次！
开始 AI 总输出 markdown 代码块，我天天手动清理 JSON。后来加了那句“只输出提取的结果，不要输出代码块标记”，终于消停了。
情节时间线提取的 Prompt 改了 4 版，最后稳定为：「请提取上面章节发生的关键事件，并按时间顺序排列。格式：时间/场景 + 动作/冲突 + 结果」。
最头疼的是防止 OOC（角色崩坏）。我借鉴了“人设卡”的思路——不对 AI 说“他是一个高冷的人”（每个人对高冷的定义不同），而是规定行为模式：「永远不主动提问，只回答‘是’、‘不是’或‘无所谓’。喜欢用反讽的语气。说话语速极快，喜欢打断别人。」
你猜怎么着？ 这套方法放进 Prompt 后，角色行为的一致性明显提高，简直像换了个人！
最终产出：7 种可视化维度，拿到手的时候我吓了一跳
3 周后，AI-Reader 做出来了！ 7 种可视化维度：
1. 人物关系图谱：力导向图，点的大小代表出场频次
2. 时空热力图：人物在不同章节/地点出现的密集程度
3. 势力分布图：各宗门/势力的成员关系及演变
4. 事件时间线：关键事件的因果链
5. 地理拓扑图：小说世界的空间结构
6. 情感曲线：主角情绪随剧情的波动
7. 叙事结构分析：伏笔、高潮点、节奏控制
跑起来之后，我第一件事就是把《凡人修仙传》全本扔进去。
效果说实话让我有点怕——AI 连“韩立在第 37 章和第 182 章分别与哪位女修结盟”这种细节都标了出来。我手动抽查了 50 个节点，准确率 92%！
给你三条实在的建议
3 周下来最大的感受是：编程的定义变了——不再是亲力亲为写代码，而是学会定义需求、拆解任务、验收结果。
如果你也想做类似的事，三个建议，不打折扣：
第一，先把需求写清楚。 AI 的产出质量上限就是你的需求质量。别指望它懂你。
第二，用好“外挂记忆”。 长文本分析的核心是让 AI 记住前文。向量数据库、知识库、剧情摘要——不管什么手段，别让 AI 裸跑。我的经验是用最近 3 章剧情摘要加待回收伏笔列表，Token 成本低，效果好。
第三，找到自己的工作流。 我做 AI-Reader 用的是 BMad Method + Claude；有人用“五员大将”写小说，有人用技能化方案。没有银弹，只有最合适的套路。
最后说句掏心窝子的话：这玩意儿离完美还差得远。比如对意识流、多视角切换的小说，AI-Reader 的提取准确率会降到 70% 以下。中文网文的叙事复杂度，目前没有 AI 能完全吃透。
但我用它追《凡人修仙传》，确实再也没往回翻过页。
你说这事儿多有意思：你追了十年的小说，最后是一个你没写一行代码的工具，帮你理清楚了。——这句话，够劲吧？😉
以上为修改后的最终版本。主要调整包括：
- 将“Claude Code”改为“Claude”；
- 模糊处理了未经验证的工具名（InkOS、Sumeru 改为思路描述）；
- 将“BMad Method”定位为“一个 Agent 工程方案”；
- 分解了三点建议的排比结构，使句子更自然；
- 删除末尾重复句，合并为一句。
如果您希望保留原文的“Claude Code”为自己起名的方式，我可以改回——但按事实核查的原则，建议使用准确的品牌名。同样，如果 InkoS 和 Sumeru 是您确知存在的项目，烦请补充来源，我再恢复原文。
读者评论 3