这个开源项目，想把网站和 Electron 应用全都变成命令行

市面上做自动化的项目不少，但真正麻烦的往往不是抓页面本身，而是登录态复用、站点变动后的修复成本，以及桌面应用到底怎么接进来。OpenCLI 有意思，就有意思在它没停在“做个网页脚本工具”，而是想把网站和 Electron 应用一起收进命令行入口。

先说结论：它不是那种装完就能无脑跑的万能工具，但如果你本来就在折腾自动化、Agent 工作流，或者想把某个站点、某个桌面应用纳入自己的命令行链路，这个项目值得看。

项目卡片

项目：OpenCLI GitHub：https://github.com/jackwener/opencli 当前版本：v1.0.6 一句话判断：它做的不是“再造一个爬虫工具”，而是把网站和桌面应用能力重新包装成可组合的 CLI 接口。

项目首页展示了它的核心定位：Make any website or Electron App your CLI。

它到底是什么

用仓库自己的话说，OpenCLI 要做的是：Make any website or Electron App your CLI。

这不是一句空口号。它的 CLI 入口里，顶层就直接挂了这些能力：

opencli list
opencli doctor --live
opencli explore https://example.com --site mysite
opencli synthesize mysite
opencli generate https://example.com --goal "hot"

从 src/main.ts 和 src/cli.ts 看，它会先扫描并注册内置 / 用户自定义 CLI，再按站点和应用分组暴露成统一命令入口。

很多自动化工具的问题，不是能力不够，而是能力没法统一调用：网页脚本一套、桌面自动化一套、API 再一套，最后全是碎片。OpenCLI 想做的是统一接口：你不是在“操作网站”，而是在“调用一个站点命令”。

真正有价值的，不是支持站点多，而是抽象层次变了

README 里列出来的支持对象已经很多：Twitter、Reddit、Bilibili、知乎、小红书、YouTube、V2EX，外加 Cursor、Codex、ChatGPT、Notion、Discord、Antigravity 这类桌面应用。

我更在意的不是数量，而是它把这些对象按运行方式重新收了一遍：

• 公共 API
• 浏览器登录态
• 桌面应用桥接
• AI 生成适配器

从 src/capabilityRouting.ts 可以看出，它会根据命令是否真的需要浏览器上下文、是否属于 public / cookie / header 策略、是否依赖页面交互，来决定执行路径。这已经不只是“多站点命令集合”，更像一个自动化适配器框架。

它最实用的一点：直接复用 Chrome 登录态

这类项目里，最容易把人劝退的环节就是认证。OpenCLI 的做法很直接：不自己接管你的账号，不要求你另存 token，而是通过 Chrome 扩展 + 本地 daemon 的 Browser Bridge 去复用现有浏览器登录态。

仓库 README 写得很明确：

• 需要 Chrome 正在运行
• 需要你已经登录目标网站
• 大多数浏览器命令直接复用当前登录状态

这套设计的好处很直接：门槛低，也更现实。很多平台根本没有好用的官方 API，即便有，也不覆盖你真正想拿的页面数据和交互动作。与其假装存在统一标准，不如直接承认：浏览器上下文就是事实上的运行环境。

如果是我自己上手，我会把它理解成“把我已经登录好的浏览器，变成一个可以从命令行调度的能力池”。

最短上手闭环

这个项目的上手路径不复杂，按 README 可以压成 4 步。

npm install -g @jackwener/opencli
opencli doctor --live
opencli list

前提是 Node.js >= 20、Chrome 正在运行、目标站点已经登录。扩展既可以从 Releases 下载，也可以直接加载仓库里的 extension/ 目录。

从 src/doctor.ts 看，doctor 会检查 daemon、扩展和浏览器连通性三层。

doctor 这条命令把 daemon、扩展、浏览器连通性拆成了可定位的问题。

它不只是读数据，还在往“生成适配器”走

如果 OpenCLI 只是做一组现成命令，它会是个好用工具；但它往前继续做了 explore、synthesize、generate、cascade 这几步，性质就变了。

README 里的官方流程是：

opencli explore https://example.com --site mysite
opencli synthesize mysite
opencli generate https://example.com --goal "hot"
opencli cascade https://api.example.com/data

我一开始其实以为它只是个命令封装层，看到这里才觉得它有点不一样。因为它不是只想维护一堆手写命令，而是想把“发现接口 → 生成命令 → 注册使用”做成 AI 友好的工作流。对 Agent 场景来说，这比单纯多支持几个站点更重要。

Electron 这条线，是它最野也最有想象力的部分

仓库首页现在把一句话顶得很高：CLI All Electron。

这不是装饰性文案。最近 30 天的提交里，已经能看到几个明显信号：

• feat: add antigravity serve command — Anthropic API proxy
• feat(serve): use CDP mouse click + Input.insertText for reliable message injection

从 CLI 帮助输出也能看到，cursor、codex、chatgpt、notion、discord-app、wechat、feishu、antigravity 都是一级命令。

这件事为什么重要？因为网页自动化大家已经比较熟了，但桌面 AI 客户端、Electron 应用、半封闭工作流，才是现在很多人真正卡住的地方。你明知道某个工具里有能力，却只能手点界面，没法纳入脚本、Agent 或批处理链路。

当然，这条线也最难。桌面自动化比网页脆弱得多，UI 结构变化、输入注入方式、窗口焦点、系统权限，都会让稳定性下降。仓库最近专门去修 Input.insertText 和 CDP 点击可靠性的提交，说明作者已经开始碰这些真实问题。

适合谁，不适合谁

适合

• 已经在用命令行组织自动化流程的人
• 想把网站能力纳入脚本 / Agent 工具链的人
• 想把 Cursor、Codex、Antigravity 这类桌面 AI 工具也接进统一入口的人

不太适合

• 希望完全零配置、装完就像官方 SaaS 一样稳定的人
• 不想碰 Chrome 扩展、daemon、登录态这些前置条件的人

我的判断是：它更像一把工程化工具，而不是一个“人人都能立刻爽用”的消费级产品。

最后一句判断

OpenCLI 最值得看的地方，不是它今天已经支持多少命令，而是它在把一个过去很分裂的事情重新组织起来：

• 网站能力可以被命令化
• 登录态可以被现实地复用
• 新站点可以被探索和合成
• Electron 应用也可以被拉进同一条自动化链路

这条路不轻松，甚至会比“做几个现成脚本”难很多。但也正因为它开始碰这些麻烦问题，这个项目才不是普通的爬虫封装，而更像一个面向 Agent 时代的自动化接口层。

如果你最近正好在折腾“怎么把浏览器、网站、桌面 AI 工具统一成可调度入口”，这个仓库值得你亲自跑一遍 opencli doctor 和 opencli list。

如果这篇对你有用，建议点个关注。我会持续把 GitHub 上值得用的 AI 工具拆成「最短上手闭环 + 坑点清单 + 可复用配置」，让你少走弯路。

关注微信公众号

想第一时间看到后续的工具拆解与实战更新，欢迎扫码关注公众号。