Chrome插件+AI+flomo：论文文献自动整理与GB/T 7714引用生成

1. 论文写作流的核心痛点与方案选型

写论文这件事，最折磨人的往往不是实验做不出来，也不是数据跑不通，而是那些看起来不起眼、却极其消耗精力的“脏活累活”。我读研那几年，光是整理参考文献格式就不知道熬了多少个通宵。GB/T 7714 这个国标格式，看起来简单，真到手动敲的时候，作者名、期刊名、年份、卷期、页码、DOI，少一个标点符号都可能被导师打回来重改。更别提还要在知网、Web of Science、Google Scholar 之间来回切换，复制粘贴摘要，再手动提炼核心观点，最后整理成自己的文献笔记。

这套流程我用了三年，直到有一天我实在受不了了，决定用 Chrome 插件把它彻底打通。核心思路很简单：让浏览器里发生的一切文献相关操作，都能一键流转到 flomo 里，并且自动带上符合 GB/T 7714 标准的引用格式。为什么选 flomo？因为它的输入框足够轻，API 足够简单，标签系统足够灵活，而且它天生就是为“碎片化记录”设计的。你不需要打开一个沉重的笔记软件，不需要等待同步，一条 curl 请求就能把内容塞进去。

整个方案的技术栈其实不复杂：一个 Chrome 插件负责在浏览器端抓取页面信息、调用 AI 接口做摘要提炼、生成标准引用格式，然后通过 flomo 的 API 把整理好的内容推送过去。听起来像是三个独立的功能，但串起来之后，它解决的是一个完整的“输入-处理-输出”闭环。我试过用 Zotero 加各种插件，也试过 Obsidian 的文献管理方案，但那些工具要么太重，要么配置太复杂，要么对中文文献的支持不够友好。Chrome 插件的好处是，它就在你每天查文献的那个浏览器里，不需要切换上下文，不需要额外打开软件，点一下按钮，事情就办完了。

这个方案适合谁？如果你是正在写毕业论文的研究生，或者需要频繁查阅文献的科研工作者，又或者你只是喜欢用 flomo 做知识管理、想把手动整理文献的环节自动化，那这套流程值得你花一个下午的时间搭起来。它不要求你会写复杂的代码，但需要你对 Chrome 扩展的基本结构有一点了解，知道什么是 content script，什么是 background script，什么是 manifest.json。如果你完全没接触过插件开发，也没关系，我会把每一步都拆开讲清楚，你照着抄作业就行。

提示：这套方案的核心价值不在于“自动化”本身，而在于它把文献检索、AI 提炼、标准引用这三个环节无缝衔接在了一起。单独看每个环节都有替代方案，但串起来之后，你节省的是在不同工具之间切换的认知成本。

2. Chrome 插件架构设计与关键决策

2.1 为什么选择 Manifest V3 而不是 V2

Chrome 插件开发现在必须面对一个现实：Manifest V2 已经被逐步淘汰，新提交的插件必须使用 V3。V3 最大的变化是 background script 从持久化的后台页面变成了 Service Worker，这意味着你不能在后台脚本里保存全局变量，也不能依赖它一直活着。这个变化对文献抓取插件来说其实是个好事，因为 Service Worker 按需唤醒的特性正好匹配“用户点击按钮才执行”的场景。你不需要它一直运行，只需要它在用户触发操作时醒来，干完活就休眠。

V3 的另一个关键变化是网络请求权限的收紧。以前 V2 可以在 background 里随意发跨域请求，V3 虽然也支持，但需要更明确的 host_permissions 声明。对于我们要调用的 flomo API 和 AI 接口来说，这意味着你需要在 manifest.json 里把目标域名写清楚。我一开始偷懒用了<all_urls>，结果 Chrome 商店审核直接打回来，说权限范围过大。后来改成具体的域名列表，审核就过了。所以如果你打算把插件发布到商店，这一点要特别注意。

2.2 内容脚本与后台脚本的职责划分

整个插件我分成了三个部分：content script 负责在页面上抓取信息，background script 负责调用外部 API 和处理数据，popup 页面负责展示结果和触发操作。这个划分不是随便定的，而是基于 Chrome 扩展的安全模型。content script 运行在网页的上下文里，能直接读取 DOM，但它不能跨域发请求，也不能访问 Chrome 的扩展 API。background script 正好相反，它能跨域，能访问扩展 API，但碰不到网页的 DOM。所以抓取和请求必须分开。

具体来说，当你在知网或者 Google Scholar 的页面上点击插件图标时，popup 会向 content script 发消息，让它把当前页面的标题、作者、期刊、年份、DOI 等信息提取出来。content script 把这些数据返回给 popup，popup 再转发给 background script，由 background script 去调用 AI 接口做摘要提炼，同时生成 GB/T 7714 格式的引用字符串。最后 background script 把整理好的内容通过 flomo API 推送出去。整个链路看起来有点绕，但每一环都有明确的安全边界，调试起来也更容易定位问题。

2.3 flomo API 的调用方式与限制

flomo 提供了一个非常简洁的 API 接口，你只需要在设置里找到“API 访问”选项，生成一个 webhook 地址，然后往这个地址发 POST 请求就能写入内容。请求体是 JSON 格式，核心字段就一个content，支持 Markdown 语法。我实测下来，这个接口的稳定性很好，几乎没有遇到过失败的情况。但有一个限制需要注意：flomo API 对请求频率没有明确的官方说明，但根据我的经验，短时间内连续发送大量请求可能会被限流。所以我在插件里加了一个简单的队列机制，每次推送间隔 500 毫秒，避免触发风控。

另一个坑是内容长度。flomo 的单条笔记虽然没有硬性字数限制，但如果你把整篇论文的摘要都塞进去，阅读体验会很差。我的做法是在 AI 提炼环节就把内容压缩到 200 字以内，只保留核心观点、研究方法和结论。这样推送到 flomo 之后，每条笔记都是一个独立的、可检索的知识点，而不是一大坨需要二次消化的文本。

注意：flomo API 的 webhook 地址相当于你的账户凭证，千万不要把它硬编码在插件代码里然后发布到公开仓库。我的做法是让用户在插件的设置页面里手动填入自己的 webhook 地址，然后存在chrome.storage.sync里。这样既安全，又方便多设备同步。

3. 文献信息抓取与 AI 提炼的实操细节

3.1 不同文献页面的 DOM 结构适配

知网、万方、维普、Google Scholar、PubMed，每个平台的页面结构都不一样，甚至同一个平台的不同页面类型（检索列表页、详情页、PDF 预览页）的 DOM 结构也有差异。如果你只针对某一个平台写死选择器，换个数据库就失效了。我的做法是写一个通用的抓取函数，按照优先级依次尝试多组选择器，哪组先命中就用哪组。比如抓标题，我会依次尝试h1.title、.article-title、meta[name="citation_title"]、document.title，这样即使页面改版，只要有一组选择器还有效，抓取就不会完全失败。

对于中文文献，知网的详情页有一个比较稳定的结构：标题在.wx-tit h1里，作者在.author的链接文本里，期刊名在.top-tip a里，年份和卷期在.top-tip span里。但这些类名是混淆过的，知网随时可能改。所以我更推荐用 meta 标签来抓取，知网在页面头部埋了citation_title、citation_author、citation_journal_title、citation_publication_date等标准 meta 标签，这些标签的命名遵循 Google Scholar 的规范，相对稳定得多。Google Scholar 本身也是用这套 meta 标签，所以一套抓取逻辑可以同时适配多个平台。

3.2 AI 提炼的提示词设计与参数调优

AI 提炼环节是整个流程里最“玄学”的部分。同样的模型，提示词写得好不好，输出质量天差地别。我试过很多版本，最后稳定下来的提示词是这样的：

你是一名学术文献分析助手。请阅读以下文献信息，完成三件事： 1. 用一句话概括研究目的（不超过30字） 2. 用两句话总结核心方法（不超过60字） 3. 用一句话提炼主要结论（不超过30字） 输出格式： 目的：... 方法：... 结论：...

这个提示词的关键在于限制字数和固定格式。如果不限制字数，模型会写出一大段废话；如果不固定格式，后续解析会很麻烦。我用的模型是 GPT-3.5-turbo，温度设为 0.3，这样输出比较稳定，不会每次都不一样。如果你用的是国产模型，比如通义千问或者文心一言，提示词需要微调，因为它们对“不超过XX字”这种指令的遵循程度不如 GPT 系列。

还有一个细节：输入给 AI 的文本不能太长。知网的摘要一般在 300 字左右，加上标题和作者信息，总共不超过 500 字，这个长度对大多数模型来说都很轻松。但如果你抓的是英文文献，摘要可能有 1000 字以上，这时候需要先截断，只取前 800 个字符。我试过把整篇摘要塞进去，结果模型开始胡言乱语，输出一些和原文无关的内容。后来改成截断之后，稳定性好了很多。

3.3 GB/T 7714 引用格式的自动生成逻辑

GB/T 7714 的格式规则看起来复杂，但拆开之后其实就几个核心要素：作者、题名、文献类型标识、出版地、出版者、出版年、页码。期刊文章的类型标识是[J]，会议论文是[C]，学位论文是[D]，专著是[M]。我写了一个函数，根据文献类型拼接字符串。以期刊文章为例，格式是：

作者. 题名[J]. 刊名, 年, 卷(期): 页码.

作者的处理是最麻烦的。中文文献的作者一般用逗号分隔，英文文献用逗号加空格。如果作者超过三个，GB/T 7714 要求只列前三个，后面加“等”或“et al.”。我一开始没注意这个规则，生成的引用里列了七八个作者，被导师指出格式不对。后来加了一个判断：作者数组长度大于 3 时，取前三个，中文加“等”，英文加“et al.”。

还有一个容易忽略的点是标点符号。GB/T 7714 要求用半角标点，但中文文献的题名和刊名里可能本身就有全角标点。我的做法是先把所有标点统一转成半角，然后再按格式拼接。这个细节看起来很小，但格式审查的时候，一个全角逗号就可能被判定为不合格。

实操心得：GB/T 7714 的格式规则在不同版本之间有细微差异，比如 2015 版和 2005 版对电子资源的处理就不一样。如果你不确定用哪个版本，直接问导师或者查学校图书馆的官方说明。我一开始按 2005 版写的，后来发现学校要求用 2015 版，又改了一遍。

4. 完整实操流程与关键代码解析

4.1 插件目录结构与 manifest 配置

先来看整个插件的目录结构，这样你心里有个全局图：

flomo-paper-helper/ ├── manifest.json ├── popup/ │ ├── popup.html │ ├── popup.css │ └── popup.js ├── content/ │ └── content.js ├── background/ │ └── background.js └── icons/ ├── icon16.png ├── icon48.png └── icon128.png

manifest.json 是插件的入口，V3 版本的配置如下：

{ "manifest_version": 3, "name": "Flomo Paper Helper", "version": "1.0.0", "description": "文献检索、AI提炼、GB/T 7714引用一键推送flomo", "permissions": ["activeTab", "storage", "scripting"], "host_permissions": [ "https://flomoapp.com/*", "https://api.openai.com/*" ], "background": { "service_worker": "background/background.js" }, "action": { "default_popup": "popup/popup.html", "default_icon": { "16": "icons/icon16.png", "48": "icons/icon48.png", "128": "icons/icon128.png" } }, "content_scripts": [ { "matches": ["<all_urls>"], "js": ["content/content.js"], "run_at": "document_idle" } ] }

这里有几个关键点。permissions里的activeTab让你能访问当前标签页，storage让你能保存用户设置，scripting让你能动态注入脚本。host_permissions里必须明确列出 flomo 和 AI 接口的域名，否则请求会被 CORS 拦截。content_scripts的matches我用了<all_urls>，因为用户可能在任意文献页面上使用插件。如果你只想支持特定数据库，可以把这里改成具体的域名列表，减少权限申请范围。

4.2 内容抓取脚本的编写与调试

content.js 的核心是一个抓取函数，它按照优先级尝试不同的选择器：

function extractMetadata() { const getMeta = (name) => { const el = document.querySelector(`meta[name="${name}"]`); return el ? el.content : ''; }; const title = getMeta('citation_title') || document.querySelector('h1')?.innerText || document.title; const authors = []; document.querySelectorAll('meta[name="citation_author"]').forEach(el => { authors.push(el.content); }); const journal = getMeta('citation_journal_title'); const year = getMeta('citation_publication_date')?.slice(0, 4); const volume = getMeta('citation_volume'); const issue = getMeta('citation_issue'); const firstPage = getMeta('citation_firstpage'); const lastPage = getMeta('citation_lastpage'); const doi = getMeta('citation_doi'); const abstract = getMeta('citation_abstract') || document.querySelector('.abstract')?.innerText || ''; return { title, authors, journal, year, volume, issue, firstPage, lastPage, doi, abstract }; }

这段代码的调试过程比较曲折。一开始我只用 meta 标签，结果发现有些中文期刊的页面没有埋 citation 系列的 meta 标签，抓出来全是空的。后来加了 DOM 选择器作为兜底，覆盖率才上来。但 DOM 选择器的问题是，不同平台的类名不一样，你不可能穷举所有情况。我的策略是优先用 meta 标签，因为这是 Google Scholar 的规范，大多数学术平台都会遵循；如果 meta 标签缺失，再用几个通用的选择器兜底，比如h1抓标题、.abstract抓摘要。这样虽然不能保证 100% 覆盖，但能覆盖 80% 以上的常见场景。

4.3 AI 接口调用与结果解析

background.js 里负责调用 AI 接口的部分，我用的是 fetch：

async function summarizeWithAI(metadata, apiKey) { const prompt = `你是一名学术文献分析助手。请阅读以下文献信息，完成三件事： 1. 用一句话概括研究目的（不超过30字） 2. 用两句话总结核心方法（不超过60字） 3. 用一句话提炼主要结论（不超过30字） 输出格式： 目的：... 方法：... 结论：... 文献标题：${metadata.title} 作者：${metadata.authors.join(', ')} 摘要：${metadata.abstract.slice(0, 800)}`; const response = await fetch('https://api.openai.com/v1/chat/completions', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${apiKey}` }, body: JSON.stringify({ model: 'gpt-3.5-turbo', messages: [{ role: 'user', content: prompt }], temperature: 0.3 }) }); const data = await response.json(); return data.choices[0].message.content; }

这里有一个坑：API Key 不能硬编码在代码里，也不能存在 content script 里，因为 content script 运行在网页上下文中，网页本身有可能读取到你的变量。正确的做法是把 API Key 存在chrome.storage.sync里，只在 background script 里读取。background script 运行在扩展的独立上下文中，网页无法访问。我一开始图省事把 Key 写在了 content.js 里，后来意识到这个安全问题，赶紧改掉了。

4.4 引用格式生成与 flomo 推送

引用格式生成函数我单独放在一个模块里，方便复用和测试：

function generateGBRef(metadata) { const typeMap = { journal: '[J]', conference: '[C]', thesis: '[D]', book: '[M]' }; const type = typeMap[metadata.type] || '[J]'; let authorStr = metadata.authors.slice(0, 3).join(', '); if (metadata.authors.length > 3) { authorStr += metadata.authors[0].match(/[\u4e00-\u9fa5]/) ? ', 等' : ', et al.'; } let ref = `${authorStr}. ${metadata.title}${type}. ${metadata.journal}`; if (metadata.year) ref += `, ${metadata.year}`; if (metadata.volume) ref += `, ${metadata.volume}`; if (metadata.issue) ref += `(${metadata.issue})`; if (metadata.firstPage) ref += `: ${metadata.firstPage}`; if (metadata.lastPage) ref += `-${metadata.lastPage}`; ref += '.'; return ref; }

推送 flomo 的函数就更简单了：

async function pushToFlomo(content, webhookUrl) { const response = await fetch(webhookUrl, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ content }) }); return response.ok; }

最终推送到 flomo 的内容格式是这样的：

#论文/文献笔记 目的：探究XX方法在XX场景下的适用性 方法：采用XX实验设计，结合XX分析方法，对XX数据进行了验证 结论：XX方法在XX条件下显著优于基线 引用：张三, 李四, 王五. 论文标题[J]. 期刊名, 2023, 45(3): 12-20. DOI：10.xxxx/xxxxx

这个格式的好处是，flomo 的标签系统会自动把#论文/文献笔记识别为标签，你以后搜索的时候直接点标签就能找到所有文献笔记。引用格式单独一行，方便你直接复制到论文的参考文献列表里。

5. 常见问题排查与避坑经验实录

5.1 抓取失败与选择器失效的排查思路

抓取失败是最常见的问题，表现就是插件弹窗里显示的信息全是空的，或者只有标题没有作者。遇到这种情况，第一步是打开 Chrome DevTools，在 Console 里手动执行document.querySelector('meta[name="citation_title"]')，看看能不能拿到值。如果拿不到，说明这个页面没有埋 meta 标签，你需要检查页面上有没有其他可用的选择器。第二步是检查 content script 有没有正确注入，在 Console 里输入typeof extractMetadata，如果返回undefined，说明脚本没加载，可能是 manifest 里的 matches 配置不对，或者页面在脚本注入之前就跳转了。

还有一个隐蔽的坑：有些学术平台用了 iframe 嵌套，文献详情页在 iframe 里面，content script 默认只注入到顶层页面，拿不到 iframe 里的内容。解决办法是在 manifest 里加"all_frames": true，让脚本注入到所有 frame 里。但这样会带来一个新问题：同一个页面可能有多个 frame，脚本会执行多次，导致重复抓取。我的做法是在脚本开头加一个判断，只在顶层 frame 或者包含文献信息的 frame 里执行抓取逻辑。

5.2 AI 接口超时与限流的应对策略

AI 接口调用失败通常有两种原因：网络超时和频率限流。网络超时的话，fetch 请求会抛出一个 TypeError，你需要在代码里 catch 住，然后给用户一个友好的提示，而不是让插件直接崩溃。我的做法是加一个重试机制，最多重试两次，每次间隔 1 秒。如果两次都失败，就提示用户“AI 服务暂时不可用，请稍后重试”。

频率限流的话，OpenAI 的免费额度有每分钟请求次数限制，如果你短时间内连续抓取多篇文献，很容易触发 429 错误。解决办法是在 background script 里维护一个请求队列，每次请求之间间隔至少 1 秒。我实测下来，1 秒的间隔基本不会触发限流，而且对用户体验的影响也可以接受。如果你用的是国产模型，限流策略可能不一样，需要根据具体平台的文档调整间隔时间。

5.3 flomo 推送失败的内容格式问题

flomo API 对内容格式有一些隐性的要求。我遇到过几次推送失败，排查后发现是内容里包含了特殊字符，比如#号如果出现在行首，会被 flomo 解析为标签，但如果#后面跟的是数字或者特殊符号，可能会导致解析异常。还有一个问题是换行符，如果你在 content 里用了\r\n，flomo 可能会把它当成两个换行，导致格式错乱。我的做法是在推送之前，先把内容里的\r\n统一替换成\n，然后把行首的#号转义成\#，避免被误解析为标签。

另外，flomo 的 webhook 地址如果填错了，请求会返回 404 或者 401。你可以在 background script 里检查 response.status，如果是 401，说明 webhook 地址无效，需要提示用户重新配置。如果是 404，说明 flomo 的 API 地址变了，需要更新插件代码。我建议在插件设置页面加一个“测试连接”按钮，让用户可以在正式使用之前先验证 webhook 是否有效。

5.4 常见问题速查表

避坑技巧：调试插件的时候，不要每次都重新加载整个扩展。Chrome 的扩展管理页面（chrome://extensions/）有一个“重新加载”按钮，点击它就能让修改后的代码生效，不需要重启浏览器。但 content script 的修改需要刷新目标页面才能生效，background script 的修改只需要重新加载扩展。搞清楚这一点，能省下不少调试时间。

6. 从单篇抓取到批量处理的扩展思路

单篇抓取用了一段时间之后，我开始不满足了。写综述的时候，一次要处理几十篇文献，一篇一篇点太慢了。于是我在插件里加了一个“批量模式”：在检索结果列表页，插件会自动识别页面上所有的文献条目，然后依次抓取每一条的元数据，批量调用 AI 接口做摘要，最后一次性推送到 flomo。这个功能的实现难点在于，不同平台的列表页结构差异很大，你需要为每个平台单独写解析逻辑。我的做法是先支持知网和 Google Scholar 两个最常用的平台，其他平台后续再慢慢加。

批量模式还有一个问题是推送频率。如果你一次推送 50 条笔记到 flomo，即使间隔 500 毫秒，也需要 25 秒才能推完。这期间如果用户关闭了浏览器，后面的推送就丢了。我的解决方案是把待推送的内容先存到chrome.storage.local里，然后由 background script 逐个推送，每推送成功一条就删除一条。这样即使浏览器中途关闭，下次打开时插件会自动继续推送剩余的内容。这个机制我称之为“断点续传”，虽然实现起来多了一点代码，但可靠性提升了很多。

另外，我还加了一个“去重”功能。同一篇文献可能在多个平台都出现过，如果重复推送到 flomo，会造成信息冗余。我的做法是在推送之前，先检查 flomo 里是否已经存在相同 DOI 的笔记。但 flomo API 没有提供搜索接口，所以我换了一个思路：在本地维护一个已推送 DOI 的列表，存在chrome.storage.local里，每次推送前先查这个列表。这个方案不是完美的，如果你换了电脑或者清了浏览器数据，列表就丢了，但对于大多数场景来说够用了。

7. 我在这套流程上踩过的坑与最终建议

这套插件我从第一版到现在，断断续续改了半年多。最开始的时候，我贪心想把所有功能都塞进去，结果代码越写越乱，调试越来越难。后来我学乖了，每次只加一个功能，加完测试稳定了再加下一个。这个教训看起来很基础，但真正做的时候很容易上头。尤其是当你看到别人的插件功能很丰富的时候，会忍不住想一次性全实现，结果就是一堆 bug 堆在一起，根本不知道从哪里开始修。

另一个深刻的体会是，不要过度依赖 AI。AI 提炼摘要确实能省时间，但它不是万能的。有些文献的摘要写得很烂，AI 提炼出来的内容还不如你自己看一遍。我的做法是，AI 提炼的结果只作为参考，推送到 flomo 之后，我会在有空的时候快速扫一眼，如果发现提炼得不对，就手动改一下。flomo 的编辑功能很方便，改一条笔记只需要几秒钟。这样既享受了自动化的效率，又保证了笔记的质量。

最后再分享一个小技巧：flomo 的标签系统支持层级结构，比如#论文/文献笔记/方法论和#论文/文献笔记/实验设计。我在推送的时候会根据 AI 提炼的内容自动打上二级标签，这样以后搜索的时候，可以直接按方法论或者实验设计来筛选，比全文搜索精准得多。这个标签策略是我用了半年之后才摸索出来的，一开始只是简单打个#论文，后来发现笔记多了之后根本找不到想要的内容。标签的粒度需要根据你的实际使用习惯来调整，太粗了找不到，太细了记不住，我的经验是两级到三级刚刚好。

这套流程到现在已经跑了大半年，累计推送了 400 多条文献笔记。它没有让我变成什么“效率大师”，但确实把我从重复劳动里解放了出来，让我能把精力放在真正需要思考的事情上。如果你也在写论文，也在用 flomo，不妨花一个下午把这套东西搭起来。一开始可能会遇到一些配置上的问题，但一旦跑通，后面就是纯粹的收益了。