夜雨聆风很多人对 OpenClaw × Notion 的第一反应，都是：它是不是能像人一样去点 Notion 网页、切视图、改卡片？
其实不是。
先说结论：OpenClaw × Notion 的核心不是网页自动化，而是通过 notion skill 调用 Notion API，把页面、数据库和记录接进自动化流程。
这个区别看起来像技术细节，但它会直接决定你后面的自动化到底能不能设计对。
因为一旦你把它理解成 API 自动化，很多事情就会顺起来：它擅长的是结构化读写、页面管理、记录新增更新、筛选查询、批量处理；它不擅长的，则是很多纯 UI 层的操作，比如前端视图怎么摆、看板列怎么展开、过滤器怎么在界面上保存成展示方案。
所以，这篇文章想讲清的，不是“怎么让 AI 帮你点 Notion”，而是：OpenClaw 如何通过 notion skill 接上 Notion，怎样理解 Notion 的对象关系，以及怎样把这些能力落到一套真实可用的自动化工作流里。
案例我们直接用一个最适合落地的场景：订阅服务管理 / 出云账单。
先把一个误解讲清：它不是在“点 Notion 网页”
在很多人的理解里，Notion 是笔记工具，最多再加一点数据库能力；而 OpenClaw 更像一个会聊天、会调工具的智能助手。
把这两者放在一起，最容易产生的误解就是：它是不是在远程操控 Notion 网页？
不是。
OpenClaw 和 Notion 的这条集成链路，本质上走的是 Notion API。更准确地说，是通过 notion skill 去组织、约束并调用 Notion API 能力，而不是像人一样去点网页、切视图、拖拽卡片。
这个前提非常重要。
因为只要前提错了，后面你对能力边界的判断就会一路错下去。你会以为它什么都能替你点，最后却发现真正要做的，是对象建模、权限配置、结构化字段设计和工作流拆分。
一句话记住：OpenClaw × Notion 的本质，是 API 自动化，不是界面自动化。
接入第一步：integration、NOTION_KEY、share、capability
要让 OpenClaw 能操作 Notion，前提不是“登录你的 Notion 账号”这么简单。
第一步，是在 Notion 里创建 integration，然后把生成的 API key 提供给 OpenClaw。常见写法是环境变量 NOTION_KEY。
没有 integration，就没有后面的授权访问；没有 NOTION_KEY，OpenClaw 就没有合法凭据去调用 Notion API。
但这还不够。
很多人第一次接 Notion API 时，最常见的困惑是：为什么 key 配好了，还是读不到页面、查不到数据库、创建不了记录？
答案通常不是语法错了，而是你忘了 share。
Notion 的 integration 默认并不能看到你整个工作区。它能访问什么，取决于你显式把哪些页面、数据库或相关对象分享给它。
也就是说，OpenClaw 不是拿到一个 key 就自动拥有“全工作区读写权”。你必须把目标页面或目标数据库 share 给这个 integration，它才有资格访问。
然后才是 capability。
可以把它理解成第二层权限：
• share 决定 能不能看到 • capability 决定 看到了以后能做什么
比如：
• 只读导出，需要 read content • 创建记录，需要 insert content • 修改已有内容，需要 update content
很多人以为 integration 只要被分享了，就一定能写，其实不对。没有对应 capability，照样会被拒绝。
权限判断速记
• 看不见对象：大概率没 share • 看得见但写不了：大概率 capability 不够 • relation 读不出来：别忘了关联对象也要 share
一句话记住：能不能访问看 share，能做什么看 capability。
Notion 里这些对象，到底是什么关系？
如果你以前主要把 Notion 当文档用，最容易误判的一点，就是以为页面是页面，数据库记录是数据库记录，两者是完全分开的。
但在 Notion API 语义里，这种理解并不准确。
更接近事实的说法是：Notion 里表格中的一行记录，本质上也是一条 page。
这句话很关键，因为它决定了你后面怎么理解“记录新增”“字段更新”“正文追加”这些动作。
先拆开来看。
Block：内容块
段落、标题、列表、图片、待办项，这些都属于 block。
它是页面正文里的最小内容单元。你在 Notion 页面里看到的一节标题、一段说明、一张图，本质上都是不同类型的 block。
Page：页面
Page 是 Notion 最基础的承载对象。
无论是一篇普通文档，还是数据库中的某一条记录，在 API 看来都落到 page 这个对象上。区别只在于，它挂在什么父级下面，以及它拥有什么样的 properties。
Database 和 Data Source
这是新版 API 里最容易混淆的部分。
更稳妥的理解是：database 更像上层容器，而 data source 才是实际承载一张表结构和记录的那一层。
真正的数据项，也就是你业务上会叫“记录”的东西，是 data source 下面的 pages。
对象关系速记
• record 本质上是一条 page • page 分成 properties 和 blocks 两层 • data source 才是实际承载记录的表结构 • database 更接近上层容器语义
所以可以把关系总结成一句最实用的话：
Notion 里一条 record，本质上是 data source 下的一条 page；这条 page 的结构化字段放在 properties 里，它的正文内容放在 blocks 里。
最关键的区分：properties 和 blocks 不是一回事
理解 OpenClaw × Notion，最关键的一步，不是记接口名字，而是把 properties 和 blocks 的职责分开。
可以把它理解成页面的两层信息。
第一层：properties
也就是结构化字段。
比如标题、状态、金额、日期、负责人、标签、URL、是否自动续费，这些都属于 properties。
它们适合被筛选、排序、聚合、联表、做视图展示。只要是你希望后续拿来查询、过滤、排序、计算的业务信息，优先都应该放在 properties 里。
第二层：blocks
也就是页面正文。
比如你想给这条记录写一段人工备注，记录一次异常说明，贴一个处理过程，追加一份文字清单，或者放上附件说明、操作步骤，这些就更适合放在 blocks 里。
它们是给人读、给人补充上下文的，不是主要拿来做结构化查询的。
建模原则凡是未来要拿来筛选、排序、统计、聚合的信息，优先放 properties；凡是给人补充上下文、说明原因、记录过程的信息，优先放 blocks。
一句话记住：properties 给系统筛，blocks 给人看。
OpenClaw 实际怎么读、怎么写、怎么查、怎么更
把模型放回 OpenClaw 的操作视角里，很多动作就很好拆了。
1）读页面
如果你要读一篇普通页面，OpenClaw 关心的通常是两个层面：先取 page 本身，拿到标题、图标、父级、属性这些元信息；再读 page 的 block children，拿到正文内容。
也就是说，“读页面”往往不是一次性读完一个笼统对象，而是分成“读页面对象”和“读页面内容块”两个动作。
2）新增记录
如果你要在数据库里新增一条记录，本质上是创建一条新的 page，并把它挂到某个 data source 或对应的数据库容器下。
此时最重要的是把 properties 按照目标 schema 写对。
注意这里的关键词是 schema。只要 page 是创建在某个 data source 之下，它的字段就必须符合那张表的字段定义。字段名不匹配、字段类型不匹配、把只读字段硬写进去，这些都会出问题。
如果你在创建记录的同时还想附带一段备注正文，那这部分属于 children，也就是 blocks。你可以在创建时一起带上，也可以后面再 append blocks。
3）查询记录
查询在新版 API 语义下，重点已经转到 data source。也就是说，你不是在一个模糊的“数据库对象”上直接想当然地查所有内容，而是围绕具体的 data source 去做 query。
返回结果本质上还是 pages，也就是一条条记录页。每条记录页里有 properties；必要时你还可以再去读取它的 blocks。
这里有一个做自动化时非常致命、但又特别容易被忽略的点：如果你不显式指定排序，Notion 并不保证你拿到的顺序就是你以为的“最新在前”或“最早到期在前”。
所以，只要你的业务语义里出现“最近”“下一个”“本月最新”“即将到期”这种词，就不要偷懒，一定要显式 sort。
4）更新记录
更新 page 时，最常见的动作有两种：一种是更新 properties，一种是追加 blocks。
前者适合状态流转、金额修订、日期回填、标签变更；后者适合补充处理记录、追加核查说明、写人工备注。
比如你发现某条账单异常，需要把状态改成 Need Review，同时写一句“比上月高出 20%，怀疑实例规格被自动升配”。
正确做法是：
• 先更新状态字段 • 再在 page 下追加一段 block
不要把整段说明硬塞进本来用来筛选的字段里，也不要误以为 patch page 就等于能更新页面正文。
为什么“订阅服务管理 / 出云账单”特别适合做主案例？
因为它天然具备自动化价值，而且结构非常清晰。
你手里可能有很多持续扣费的服务：AI 工具、云服务器、域名、CDN、对象存储、协作 SaaS、邮件服务、代理、设计工具。
它们有金额，有币种，有周期，有下次扣费日，有是否自动续费，有负责人。你会关心：
• 这个月有哪些要扣费？ • 哪些服务明明停用了却还在自动续费？ • 哪一笔账单比平时高很多？ • 某个项目一个月到底花了多少钱？ • 哪些订阅已经进入取消流程但还没彻底停？
这些都非常适合 Notion 来承载，也非常适合 OpenClaw 来做自动化入口。
从单表到双表：怎样把账单系统搭得更稳
如果只讲一个最小可行方案，你完全可以先做一张订阅总表。
每条记录对应一个长期服务，字段大概包括：服务名称、分类、计费周期、金额、币种、下次扣费日期、是否自动续费、状态、账单页链接和备注。
这样做的好处是简单、上手快，对很多个人用户或小团队已经够用了。
但如果你想把系统做得更稳，尤其是想追踪历史账单、金额变化和异常波动，那么最好升级成 双表模型：
• 一张「订阅服务主表」 • 一张「账单记录表」
订阅服务主表关注的是稳定对象，比如 ChatGPT Plus、Claude、Vercel Pro、AWS Lightsail、某个域名套餐。
这里的字段更适合描述长期状态：服务名、供应商、计费周期、标准金额、币种、自动续费、当前状态、下次扣费时间、负责人、所属项目、官网链接、账单链接等。
账单记录表则关注事件流。每一次实际扣费，都是一条新记录。
它应该包含服务关联、扣费日期、实际金额、账单状态、附件链接等信息。你甚至可以给它设计一个稳定的标题规则，比如“服务名 + 年月”或者“服务名 + 账单日期”。
为什么不建议把这两种信息硬塞进一张表？
因为它们的粒度不同。订阅项是相对稳定的实体，账单是持续发生的事件。如果混在一起，后面你会很难同时处理“当前状态”和“历史记录”。
双表模型的价值，就在于把“当前视图”和“历史流”分开。主表负责看全局和当前状态，记录表负责沉淀每次事件。这种结构，不仅适合人在 Notion 里查看，也更适合 OpenClaw 去做自动化。
下一篇我们将来讲解5个最值得先跑通的小工作流，欢迎关注这届科技学会最新技术
