[讨论] 功能边界与迭代节奏：是否考虑 core/lite 与 full 分线，或按需模块 / 插件化

首先，我很喜欢 FluentRead，也把它推荐给了不少小伙伴，感谢作者愿意在开源社区持续投入维护这样一个项目。

最近的更新里，能明显感到功能扩展得很快，也带来了很多令人兴奋的能力；不过我自己也发现，核心的翻译功能不像之前那么稳定了。于是简单了解了一下当前项目的开发与维护方式，下面是一些观察和想法，仅供参考。

一、现状

• 包体：安装包（CRX / zip）约 24 MB，解包后约 80 MB。其中 fluent-read-ai 下三个 wasm 就占了 52 MB（TTS ORT 22.5 MB、ORT jsep 20.6 MB、wllama 8 MB）；此外还有词典 ecdict-core.json 4.2 MB、OCR 3.9 MB、pdfjs 2.5 MB、多语言包 2.2 MB。这些与"网页翻译"的核心路径无关，但每位用户都会一起下载。
• 功能面：src/features 下 22 个目录，src 约 13 万行；设置界面 27 个 section、配置项约 180 个；翻译服务 48 个。
• 迭代节奏：近 90 天约 feat 166 / fix 280；按提交日期统计，2026-08 约 440 次、2026-09 上半月约 650 次。近期新增了本地模型翻译、单词本 / 学习卡片、视频字幕、图片翻译、文档翻译、写作助手等能力。
• 测试规模也不小（351 个测试文件、约 6900 个用例），从另一个角度说明维护与回归成本已经不低。
• 开发与维护几乎由作者一人承担，近期的新增功能很多是在 agent 协助下完成的。

（以上数据取自我本地构建的 0.0.35，仅供讨论。）

二、我个人的担心

1. 维护与精力：每个新功能都会引入自己的 wasm / worker / offscreen / 配置项和设置界面，验证与回归面随之扩大。近期 fix 明显多于 feat，核心翻译（全文 / 划词 / 悬浮）也偶有回归，感觉修复和新功能在彼此争夺精力。
2. 用户开销：一个"调用在线 API 翻译网页"的插件需要约 24 MB 下载、多组权限和多个后台入口，对只想用核心翻译的用户来说偏重。
3. 耦合：重型能力与核心翻译在同一个包、同一条发布节奏里，任何一处改动都可能牵动整体回归。
4. 会不会走向"全能化"：我有点担心它会像不少大厂产品那样，从小而美变成大而全，从一个翻译工具变成一套语言学习套件。就个人偏好来说，一个边界清晰、行为可预期的 95 分小工具，往往比每个功能都做到 80 分的全能型产品更好用。这只是我的偏好，不代表对错。

三、关于未来迭代方向的一点想法

1. 短期：是否可以先以核心翻译的稳定性优先，比如"核心修复优先合并、重型新功能放 feature 分支慢慢来"，把节奏稍微放慢一些。
2. 长期：是否考虑 core/lite 与 full 两条线（lite 只保留基于机翻 API / LLM 接入点的网页翻译），或者把重型能力做成可插拔模块，让只需要核心翻译的用户有得选？

无论怎样，都要谢谢作者在这段时间里做出这么多可用的功能。也希望这个项目能走得更久、更稳。