HarperRust 驱动的离线隐私优先语法检查器——一次对 Grammarly 垄断格局的务实反击核心观点Harper 是一个用 Rust 编写、完全本地运行的英语语法检查器由 Elijah Potter 独立开发于2024 年 11 月被 AutomatticWordPress 母公司收购。它的存在逻辑很明确现有主流方案各有致命短板——Grammarly 是隐私黑箱、LanguageTool 是内存怪兽——Harper 选择在这两者的夹缝中切入用极限性能和零联网换取一个刚刚好的可用点。官方宣称的核心指标响应延迟 10msAutomattic 公告称 20ms属同一量级优于 Grammarly 网络往返的 ~100 倍内存占用不到 LanguageTool 的 1/50LanguageTool 完整 n-gram 数据集约 16GB支持 WebAssembly可直接跑在浏览器里Apache-2.0 开源无账号、无遥测、不训练任何模型。关键信息技术定位规则引擎而非 LLMHarper 官网明确自我标榜为the only grammar checker that doesnt use AI。这是一个刻意的取舍规则引擎可以确定性运行在本地不需要 GPU也不会因为模型推理产生不可预测的延迟。相比之下Grammarly 和日益 AI 化的写作助手依赖云端 LLMHarper 走的是完全相反的路——用有限但精确的规则覆盖最高频的语法错误错误大写、拼写、语序、常见搭配错误等而非试图理解全部语义。这与它的核心机制直接相关Rust 的零开销抽象 有限状态机/规则匹配才能在普通 CPU 上打到毫秒级。把 LLM 替换进来10ms 的目标立刻变成空谈。编辑器支持矩阵当前状态集成方式具体产品LSP 语言服务器harper-lsNeovim / Helix / Emacs / Zed编辑器扩展VS Code / Obsidian浏览器扩展Chrome / Firefox桌面端Harper DesktopmacOS系统级覆盖所有文本框CMS 插件WordPressBlock 编辑器SDKharper.jsJS/WASM、harper-coreRust crateAutomattic 收购的战略意图Automattic 明确表示将把 Harper 整合进 WordPress.com、WooCommerce、Jetpack 等产品。这意味着 Harper 的目标用户从开发者自用的 CLI/LSP 工具正在扩展到数百万 WordPress 站长的内容创作流程。这次收购大幅提升了 Harper 的长期可持续性但也意味着它的路线图将受制于 Automattic 的商业利益。局限诚实说清楚Harper 目前只支持英语多方言美/英/加/澳/印度英语。核心团队自称架构可扩展到其他语言但这依赖社区贡献现在下判断还太早。此外规则引擎天然的上限是它无法理解深层语义歧义——比如I saw the man with the telescope这类结构歧义或者风格层面的建议Grammarly 的 AI 反而有优势即便经常答非所问。Harper 适合抓语法硬错误不适合替代文风打磨。横向对比三种路径的真实代差维度HarperLanguageTool自部署Grammarly隐私零上传、零遥测本地可控需自建全量上云训练 LLM性能 10ms秒级Java JVM 启动 规则引擎取决于网络 RTT~100ms内存占用极低 LanguageTool 1/50几百 MB数 GBn-gram 可选云端客户端轻量语言覆盖仅英语30 语言英语为主检查深度规则引擎硬错误为主规则引擎覆盖面更广AI语义/风格均涉及可嵌入性WASM可浏览器内运行不支持不支持开源✅ Apache-2.0✅ LGPL核心库❌费用免费免费自部署/订阅制云端订阅制LanguageTool 的致命伤不是功能不够而是工程成本太重Java JVM 冷启动、GB 级数据集在 LSP 场景编辑器每次保存都触发 lint里用户体验很差。Harper 恰好解决了这个痛点。交叉验证信源 1Automattic 官方博客automattic.com2024-11-21Automattic 收购公告直接证实了 Harper 的性能数据——grammar and language suggestions in under 20ms这不到某知名在线语法检查器所需时间的 1%——即比 Grammarly 快约 100 倍。博客还披露了创始人 Elijah Potter 加入 Automattic 担任Code WranglerHarper 将整合进 WordPress 生态的战略规划。这与 GitHub README 的定位完全吻合不存在矛盾。信源 2Harper 官网writewithharper.com官方文档补充了 README 未提及的细节Harper Desktop 已支持 macOS 系统级覆盖所有文本框且支持英语多方言美/英/加/澳/印度。值得注意的是官网明确强调the only grammar checker that doesnt use AI——这一表述在 README 中并未出现说明官方正在将无 AI作为差异化卖点主动推广而不只是技术实现细节。信源 3第三方横向评测AlternativeTo / Scribbr 对 LanguageTool vs Grammarly 的分析Scribbrscribbr.com的评测独立验证了 LanguageTool 和 Grammarly 各自的局限性与 Harper README 的描述基本一致LanguageTool 自部署确实资源重Grammarly 确实存在数据上云问题。但这些评测尚未将 Harper 纳入比较说明 Harper 在主流技术媒体的曝光度仍然有限其性能声明目前主要来自官方自述缺乏完全独立的第三方基准测试数据——这点需要保持审慎。个人启发对开发者的直接行动价值最高。如果你用 Neovim/Helix/VS Code 写英文文档、注释或 READMEharper-ls 是目前成本最低的无感知质量门禁装上即用不需要账号不会拖慢编辑器也不会把你的代码注释发给任何服务器。相比之下Grammarly 的 IDE 插件会让人时刻想着这段代码注释是不是被抓走了。**对内容团队的判断**现阶段 Harper 适合做硬错误过滤不适合替代人工润色。把它放在写作流水线的第一道——过掉低级语法错误——然后再人工审查风格是合理分工。**关于 Automattic 收购后的隐私承诺**Harper 当前是本地运行代码开源可审计但 Automattic 的整合计划WordPress SaaS 端是否会引入云端处理值得持续关注。开源不等于未来永远不联网使用者应当定期检查版本更新日志。延伸思考规则引擎的天花板在哪里Harper 明确拒绝 AI但语法检查的长尾问题语义歧义、文风建议依赖规则引擎几乎无解。随着用户规模扩大、需求变复杂Harper 是否会被迫引入轻量级本地模型如 Mistral 7B 量化版MiraclePlus 的报道已经提到下一个版本将包括一个或多个小型 ML 模型——这与the only grammar checker that doesnt use AI的官方宣传直接矛盾是一个值得追踪的路线分歧。Automattic 的商业整合会稀释开源精神吗Harper 被收购后整合进 WordPress 云服务完全私有的承诺能否在 SaaS 场景下保持一致开源许可证Apache-2.0只保障代码可见不保障云端服务不采集数据——这是一个架构设计问题而非法律问题。英语独占是战略选择还是能力边界Harper 说架构可扩展但至今没有一个非英语语言实现进入主干。中文、阿拉伯文等形态差异极大的语言规则引擎的维护成本将指数级上升——这意味着 Harper 的多语言愿景更可能是社区长尾贡献而非官方主导的近期目标。 参考来源GitHub - Automattic/harper: Offline, privacy-first grammar checker. Fast, open-source, Rust-powered · GitHub