flowers
AI驱动的智能浏览器扩展，集成翻译、润色、笔记与RAG问答，本地优先保护隐私
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
AI驱动的智能浏览器扩展，集成翻译、润色、笔记与RAG问答，本地优先保护隐私
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象这样一个场景： 你正在阅读一篇日语技术博客，发现某个关键段落理解困难；以往你需要复制文字、切换到翻译工具、粘贴、再切回来——整个过程打断阅读节奏，割裂信息流。或者你在研究一份英文 PDF 论文，术语密集、段落冗长，逐字查词效率极低。再比如你在逛 GitHub 时看到一段精彩的笔记分享，想要保存到自己的知识库，却只能手动复制粘贴。
Flowers 正是为解决这些痛点而生。它将 AI 能力直接注入浏览器——无需离开当前页面，选中文本即可获得翻译、润色、笔记生成、问答等全套 AI 服务。
这是一个诞生于 2025 年底的独立开发者项目（snailfrying），目前已在 GitHub 获得 179 Stars，专注于打造"无感接入"的 AI 辅助阅读与笔记工作流。项目的核心理念是：AI 工具应该适配人类的工作流，而不是让人类去适应 AI 工具的操作逻辑。
Flowers 采用典型的前后端分离架构，前端为 Chrome/Edge 浏览器扩展，后端为 Node.js 服务，中间通过 REST API 通信。
前端层（frontend/） 基于 React 18 + TypeScript + Vite 构建，这是目前浏览器扩展开发的主流技术栈。TypeScript 保障了代码的可维护性，Vite 提供了极快的热重载开发体验。核心模块包括：
video/ 子目录处理视频字幕翻译，监听 TextTrack 和 DOM 变化；fullpage/ 子目录处理全文翻译，通过 DOM 操作实现非侵入式内容注入，同时智能保护代码块和公式不被翻译引擎处理。后端层（backend/src/） 采用 TypeScript 模块化架构，分为四个核心模块：
值得注意的是，后端引入了 hnswlib-wasm（分层可导航小世界图算法的 WebAssembly 实现），这是本地向量相似度搜索的核心组件。结合 Dexie 的索引能力，Flowers 能够在浏览器环境中实现 RAG（检索增强生成）问答，而无需连接外部数据库——真正做到了"本地优先"。
AI 服务商适配策略：项目没有绑定单一 AI 服务商，而是通过统一的接口层抽象 LLM 调用，允许用户按需选择。这种设计的好处是明显的：用户可以根据成本、性能、隐私需求灵活切换模型，也可以同时使用多个模型处理不同任务（如翻译用 DeepSeek，润色用 Claude）。
Flowers 提供了 9 大核心功能，覆盖阅读、翻译、笔记、问答的完整链路：
1. 智能翻译 是整个扩展的基石。选中文本后弹出工具栏，可选"翻译"功能。不同于传统机翻，Flowers 的翻译基于上下文语境，能识别术语并在专业译法与通顺表达之间取得平衡。用户还可以在设置中管理自定义术语表，确保关键名词翻译一致。
2. AI 润色 提供多种语气风格（正式、简洁、专业、友好等），适合将口语化表达转化为书面语，或将草稿润色为专业文档。
3. 笔记生成 能从选中内容自动提取要点，生成结构化笔记，并自动存储到本地知识库。这解决了"收藏了文章却再也没看过"的普遍痛点——笔记不是简单的复制粘贴，而是经过 AI 理解和结构化处理的知识结晶。
4. RAG 问答 是笔记功能的延伸。用户可以向自己的知识库提问，Flowers 通过向量检索找到最相关的笔记片段，再由 LLM 生成回答。这相当于为个人建立了一个可对话的"第二大脑"。
5. 图片 OCR 识别（需配置 Vision 模型如 GPT-4o、Claude 3.5 Sonnet、Gemini 3 Flash）。右键任意图片，选择"Extract Text"，Flowers 会调用视觉语言模型提取图片中的文字，并将结果直接送入翻译/润色/笔记工作流。
6. PDF 翻译与阅读：内置 Flowers PDF 阅读器，完整支持上述所有 AI 功能。GitHub/GitLab 上的 PDF 文件会自动重定向到该阅读器。专业工具栏提供下载、打印、搜索、全屏、缩放、深色模式、页码跳转等功能。
7. 视频字幕翻译：支持 YouTube（DOM 和 TextTrack 两种模式）和通用视频（TextTrack），实时将外语字幕翻译为中文或其他语言，配合智能批处理减少 API 调用次数。
8. 全文翻译：将整个网页翻译为双语对照模式。特色在于"技术内容保护"机制——代码块、LaTeX 公式、图表描述等非自然语言内容会被自动识别并保留原文，避免 AI 错误翻译导致代码不可用。
9. 自定义提示词：每个工作流（翻译、润色、笔记生成、聊天、图片 OCR）都有独立的系统提示词模板，用户可以在设置中完全自定义 AI 的行为逻辑，甚至可以设置"语言自适应切换"——让 AI 根据界面语言自动选择输出语言。
Flowers 在隐私保护上的设计值得单独一提。项目明确承诺：所有笔记和设置均存储在浏览器本地（IndexedDB），不收集数据，不追踪行为。AI API 调用确实需要将文本发送给外部服务（如 OpenAI），但这是翻译/润色的必要代价，用户可以配置 Ollama 等本地模型来完全避免数据外流。
这一点对在意隐私的用户（如研究人员、医疗从业者、法律工作者）非常重要——他们可能需要翻译涉及敏感内容的文档，但又不愿意让这些内容经过第三方服务器。
图1：Flowers 全屏翻译双语对照模式，自动保护代码块和公式不被翻译
图2：Flowers 侧边栏 RAG 问答界面，可基于本地知识库进行智能对话
安装流程：
git clone 克隆仓库backend/ 和 frontend/ 目录执行 npm installbackend/env.yaml.example 为 backend/env.yaml，填入 AI 服务商的 API Keynpm run build（前后端各一次）chrome://extensions/，开启开发者模式，加载 frontend/dist/ 目录难度评估：安装过程需要一定的命令行操作经验，但没有 Docker 依赖，Node.js 环境足够即可。扩展加载后，扩展图标本身即入口——无需启动额外服务（后端可选，如需 RAG 问答则必须启动）。
无 GPU 要求：扩展运行在浏览器沙箱中，不需要独立显卡。所有计算通过 AI API 远程完成。
不支持一键部署：没有提供 Dockerfile、docker-compose 或打包安装包，不支持 Kubernetes。适合个人用户本地使用。
Flowers 并非完美无缺，以下几点值得潜在用户知悉：
1. 非商业许可证：项目采用"个人使用非商业许可证"（Personal Use Non-Commercial License），这意味着不能用于商业场景。对于企业用户或希望在团队中推广的用户，这是一个实质性的限制。如果需要商业使用，需要联系作者获取授权。
2. 视频字幕翻译的限制：YouTube 字幕翻译依赖页面 DOM 结构或 TextTrack API，部分视频可能因字幕格式不支持而无法工作。此外，字幕翻译涉及频繁 API 调用，大批量使用成本不可忽视。
3. 本地 LLM 支持尚不完善：虽然架构上支持 Ollama 和 OpenAI 兼容 API，但 README 中的路线图显示"本地 LLM 集成"仍在规划中。Ollama 等本地模型的配置需要用户有一定经验，官方文档不够详细。
4. Firefox 支持缺失：当前仅支持 Chrome 和 Edge。Firefox 用户无法使用，虽然有路线图规划，但尚未实现。
在 2025-2026 年，AI 浏览器扩展赛道已经相当拥挤——从 Readify、Monica 到immersive-translate，每家都在解决"如何让用户更便捷地使用 AI"这一核心问题。Flowers 的差异化在于功能完整性和本地优先理念的结合：大多数竞品是 SaaS 平台，数据必须上传服务器；Flowers 则将知识管理建立在本地存储上，只有 AI API 调用需要外发请求。
从增长曲线看，项目在 2026 年 6 月仍有活跃更新（updated_at: 2026-06-21），维护频率较高，技术文档详尽（4 篇技术设计文档超过 50KB），说明作者在认真投入。
路线图上的几个方向值得关注：提示词版本控制（可回溯历史版本）、高级 RAG 功能（更复杂的知识图谱组织）、移动端配套应用（扩展使用场景）。如果这些功能落地，Flowers 有潜力从"浏览器扩展"进化为"个人 AI 工作台"。
对于日常需要大量阅读外文资料的从业者——无论你是研究人员、开发者、还是跨境电商运营——Flowers 提供了一套足够完整、足够本地化、足够可定制的 AI 辅助阅读方案，值得一试。