Reading automation

从 Zara 的插件，到我们的 CloudBase 工作流

同样是“把待读内容变成日历时间”，背后其实是两条很不一样的技术路径。

看懂路径，比只会调用工具更重要。
Zara 插件
→
本机 CLI 路线
我们的工作流
→
云端 API 路线
Path 01

Zara 的 reading-block-lark：本地优先

Chrome 插件负责收集和判断；本机 helper 负责调用飞书 CLI。

Chrome 插件点击保存当前网页
本地存储chrome.storage.local 保存标题、URL、状态
批次判断默认凑满 5 条
本机 helper127.0.0.1:8787
lark-cli用本机登录态创建日历
Path 02

我们的 CloudBase 工作流：云端状态中心

入口可以来自手机、快捷指令、浏览器；状态统一存在云端。

微信/浏览器复制、转发或点击保存
快捷入口Shortcuts / 插件 / HTTP
CloudBase云函数接收请求
云数据库保存文章和状态
飞书 API创建日历或发送消息
Architecture

两条路线的关键差异

本地 CLI 路线

Zara 插件

  • 数据主要存在浏览器本地。
  • 依赖当前电脑、Chrome、helper 和 lark-cli。
  • 隐私好，部署轻，但跨设备弱。
  • 适合个人电脑上的轻量自动化。
云端 API 路线

我们的工作流

  • 数据存在 CloudBase 云数据库。
  • 任何设备都能写入同一个状态中心。
  • 更适合长期后台任务和跨设备同步。
  • 代价是要处理鉴权、权限和云端维护。
API vs CLI

API 和 CLI 的本质区别

维度 API CLI
本质 系统之间通信的接口 本机命令行工具
调用方式 HTTP 请求 / SDK 终端命令 / 脚本执行
运行环境 云函数、后端、App、自动化平台 安装过工具并登录过的电脑
鉴权方式 显式 token、app_id、app_secret 复用本机登录态和配置文件
适合场景 长期服务、跨设备、后台自动化 个人工具、本机脚本、agent 操作
Takeaway

一句话收束

CLI 经常是 API 的本地封装；API 才是更适合服务化和跨环境部署的稳定入口。

怎么选？

  • 只在个人电脑上跑，优先考虑 CLI。
  • 要跨设备、长期运行，优先考虑 API。
  • 越想做成系统，越需要理解底层路径。
自动化不是魔法，是一条条清楚的数据流和权限流。
1 / 6