📌 项目地址：stanford-oval/storm | ⭐ 28,277 颗星 | 🔧 Python | 📜 MIT
一个“第二步被高估”的写作系统
STORM全称是“Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking”。斯坦福Oval实验室出品，GitHub上28,277星，两篇论文分别被NAACL 2024和EMNLP 2024录用。官方演示站（storm.genie.stanford.edu）已有超过7万人试用过。
这套系统的核心设计有个直白的洞察：很多人写长文不是卡在动笔那一刻，而是卡在“不知道要写什么”的阶段——方向不清、结构不明、论据不全。STORM把写作拆成两步：先用搜索和多角度提问生成大纲和参考资料，再基于大纲写正文。第二步比大多数人想象的好解决，真正有价值的是第一步。
安装配置，有三种搜索后端可选
pip install knowledge-storm升级用 pip install knowledge-storm --upgrade。2025年1月的v1.1.0版加入了litellm集成，可以在GPT、Claude、Gemini等模型间切换，不用改代码。2024年9月发布的v1.0.0版则把Co-STORM集成进了核心包。
搜索后端在 knowledge_storm/rm.py 里定义，三种可选：
- YouRM：默认。需要You.com的API Key。如果你在北美或不在意多注册一个服务，这个最省事。
- BingSearch：需要Bing Search API Key。我选了它，因为You.com在国内注册比较麻烦。
- VectorRM：用本地文档向量检索，不连外网。2024年7月加入。如果你有PDF或网页存档，可以先向量化，再让STORM只在你的文档里找引用。适合处理内部知识库、机密资料，或者你不想让生成结果依赖搜索引擎排名。
如果你不确定选哪个，我的建议是：先BingSearch或YouRM跑一次，看看结果质量。如果发现搜索来源不稳定，再切VectorRM用自备资料。
工作流程：先订提纲，再动笔写
STORM分两步：
- Pre-writing阶段：系统搜索互联网，收集参考文献，生成一个详细大纲。
- Writing阶段：按大纲逐节写出带引用的文章。每个段落都有引用来源，可以点击核实。
这个设计有个实际好处：大纲方向不对，改大纲就行，不用重跑全文。我试过几次“写一半发现概念分类错了”，只需要在最开始改几行文字描述，或者加几个关键搜索词，不用从头再来。而传统的一次性生成方式（prompt “写一篇关于X的长文章”）遇到方向问题只能全部重来。
2024年9月发布的Co-STORM增加了人机协作能力：系统针对主题生成一组问题方向（通常5个），代表不同切入角度。你可以选择、修改这些方向，或者自己提新问题。系统根据你的反馈调整搜索策略，把新搜到的资料整合成新大纲和新文章。核心差异是：STORM是系统自动完成全部搜索和写作，Co-STORM是你控制搜索方向，系统帮你做整理。
我做了三组实测
分别测了“Diffusion Models”、“RISC-V Architecture”、“Contrastive Learning”。每次生成2000–4000词，引用10–30条来源。模型用GPT-4o，搜索后端BingSearch。
做得好的地方
大纲结构合理。 测“Diffusion Models”时，系统自动分出“Score-based Generative Models”和“Diffusion-based Generative Models”两条技术路线，还单独列出了“Conditional Generation”。这些子话题我之前没系统想过，查证后确实有对应的经典论文支撑。系统搜索能覆盖到我没触及的论文和综述。
引用来源真实。 我抽查了十几条引用，来自arXiv论文、IEEE标准文档、权威博客。没有发现伪造。STORM不像早期LLM系统那样胡编引用。但如果搜索结果显示的标题缺少字母，系统会照搬那个不完整的标题。引用格式的准确性取决于搜索结果的质量，不是系统的强项。
效率提升明显。 对我陌生的技术领域，从输入主题到拿到带引用的初稿，用了5–10分钟。从零开始写同样内容，我要先看3-5篇综述理清脉络，再逐块写，大概要2-3小时。
做得不好的地方
语言平淡，段落之间缺乏过渡。 读起来像拼凑的摘要。同一个观点可能在不同段落出现两次，只是换了个说法。系统是在每个段落上分别做局部生成，没有强制的首尾衔接逻辑。
事实细节有错。 测“RISC-V Architecture”时，其中一家创始公司的成立年份写错了。系统从多篇文章里整合信息，但无法做事实交叉验证——如果来源本身错了，系统照搬。更糟糕的情况是，如果多篇文章对同一事实有矛盾，系统没有机制去做仲裁。
离出版级差得远。 直接投稿需要大量润色。拿“RISC-V Architecture”那篇来说，结构没问题，事实和语言需要逐句过一遍。但作为初稿框架，已经够用了。
Co-STORM实测
我试了“Contrastive Learning”主题。系统生成了5个子问题，其中一条是关于NLP方向的。我输入“跳过NLP，聚焦视觉领域的应用和对比损失函数设计”。系统调整搜索策略，找到了SimCLR、MoCo、BYOL的论文和解读，然后重写了整个大纲和文章。
对比STORM模式，Co-STORM生成的“Contrastive Learning”文章在视觉部分的分量明显增加，但我失去了一些自己没意识到的相关方向（比如对比学习在NLP的延伸用法）。有控制感，也意味着有盲区。如果你平时习惯开三四个搜索标签页来回切换，Co-STORM模式会让你觉得掌控感更强；如果你想快速得到一个全面概览，STORM模式更省心。
我总结的三个使用建议
用英文输入主题。 中文搜索质量和引用完整性都差很多。即使你要写的是中文文章，也建议先用英文主题跑一次STORM，取它的结构和大纲，然后人工翻译和修改。
等5到10分钟。 拿到大纲和完整文章。如果超过15分钟还没出结果，检查是不是API Key配错了，或者搜索后端返回了空结果。
修剪重复段落，修正事实错误，补充自己熟悉但系统遗漏的细节。 从零写一个陌生主题要2-3小时，用STORM初稿改完大概40分钟。主要的改法是：删掉重复观点，核对每个引用的原文，补充你对这个领域已有的理解。
什么时候用它，什么时候不应该用它
适合：你有一个陌生的英文技术领域需要快速入门，想要带引用的大纲和摘要。你在写技术文章或报告，需要一个基础框架，然后裁剪修改。你正在做文献综述，需要系统帮你收集和组织参考资料。
不适合：预期系统输出可以直接用，不需要修改。写邮件、营销文案、文学作品。需要高度原创性、或者你的主题过于细碎以至于搜索不到足够资料。
STORM的目标非常窄：生成维基百科风格的带引用长文章。拿到初稿后，你必须人工审核事实和结构。它不会自动帮你完成写作，但它能帮你节省从“完全没头绪”到“有了一个基础框架”这个阶段的时间。