最近一年 AI 的发展太快了，但对于终端用户来说始终有两个问题：分别计费和按量计费。
一般来说，终端应用是不按量计费的，比如 notion AI，Cubox，Perplexity。但问题是，你需要为你的每一个场景分别付费，并且价格都不算太低。
另一边就是按量计费，现在开源社区比较活跃，你也可以全部使用开源方案来替代，然后走 OpenAI 的 API 或 Claude 的 API 来在原本的工作流里实现 AI 功能。但这样意味着你需要按量付费，在一些大用量场景（比如管理知识库、筛选信息流）上，个人使用成本太高。
到我这边的一个具体的场景是，我希望打造一个带 AI 的阅读库，但又不想为 Cubox 额外付费，这应该怎么做呢？
我去年曾在《基于 RSS 和 notion AI 打造三级信息阅读 Workflow》里介绍过以 notion 为核心打造阅读库，其中也涉及到了 notion AI 的使用。但其实在这个文章中我没有说的是，我一直在用 Cubox Pro 做 Notion 的前端剪藏器——因为 notion 的剪藏插件太烂了，对大部分国内的网站或文章都只能存一个标题。
最近无意中看到了一个开源的稍后阅读项目 Omnivore，尝试之后发现它对国内网站的支持效果不错，而且它是服务器端解析。也就是说，不受到端侧浏览器的限制。像剪藏微信文章这种，直接把文章链接丢给它，它在服务器端就能完成正文的抓取和简化排版。
但作为开源项目，它自然是没有提供 AI 服务的，不过它提供了 API。
于是，我开启 n8n 大法（一个开源的 IFTTT），缝缝补补完成了一个 Omnivore 到 notion 的集成 Workflow：
示例 n8n workflow（你需要自己改改才能用）：Omnivore_To_Notion.json（阿里云盘）
这里面其中遇到了三个坑：
其一，Omnivore 默认抓来的文章是 Markdown 格式，而 notion API 的默认写入格式是一个 json 包，因此这里使用了一个 n8n 的第三方 node n8n-nodes-notionmd 来做数据转换。
其二，n8n 的官方 notion node 不支持推送 notion json raw，因此需要用 HTTP Request 自己直接写一个。
其三，notion API 的正文推送方法（Append block children）一次最多推送 100 个 Blocks 上去。因此需要对文章做切分处理（也就是 workflow 最后结尾处的循环）。
这个 Workflow 最终实现的，就是每当我在 Omnivore 上收藏了一篇新的文章，它就会把全文推送到 notion 指定的数据库。再根据我之前的设置，notion 会自动用 AI 为该文章生成摘要。实现了在任意端快速剪藏文章全文到 notion 阅读库的方法，比 Save to Notion 和 Notion Web Clipper 都要好用。
但在实现这个 Workflow 的过程中我发现，其实这个 Workflow 可以把 Notion 当作一个简式 AI API 来用，原理是这样的：
- 新建一个 notion 页面，或一个 notion 数据库。
- 在页面属性（property）中建立一个 AI Autofill 字段，并提前设计好 prompt。
- 在需要调用 AI 的场景，利用 API 将上下文推送到该页面。
- 该页面内容更新触发 AI Autofill。
- 延迟一小段时间后用 API 回调该页面的 AI Autofill 字段。
比如说，你可以做一个 Perplexity 的平替 Chrome 插件，每次点击后，自动将 Google 搜索第一页的结果页全文整合进一个 Notion Page。然后用 AI Autofill 字段来综合 Page 内所有内容来生成答案。（我在尝试做了）
在将 notion AI 当作 AI API 的场景下，你甚至不需要往 notion pages 的正文里推送内容（因为这需要切割内容），你可以直接把内容一股脑的写入一个 property 里。因为 AI Autofill 是可以读取同页面的其他 property 的。
这个方法的唯一问题是，AI Autofill 的触发是有延迟的，有时候时间还不短，这在一些需要及时反馈的场景可能并不好用。
但在现阶段，我觉得已经可以干掉很多只在应用层做了创新的 AI App 了。
不建议把 notion AI 当大规模 API 来薅，明显超过个人使用的行为应该会被封号。
精选评论