我是如何用 OpenClaw 连接 Notion，搭建一套学生成绩与日常表现管理系统的

阅读提示：本文约 8000 字，预计阅读时间 15—20 分钟。

如果你想先让 Agent 快速总结全文，可直接输入：

请用尽量简洁的方式总结这篇文章的核心观点、工具链、数据库结构和可迁移场景，并给出一个最小可复现方案。

如果你想让 OpenClaw 参考本文思路，协助你配置并连接同类 Notion 数据库，可直接输入：

请根据这篇文章，为我设计一个最小可用的 Notion 双数据库系统，并一步步指导我完成字段设置、数据库关联、Integration 连接与测试指令配置。

上个学期，我一直用 Excel 来管理学生的数据。

具体来说，我会在不同的 sheet 里记录学生每次考试的成绩；另外还专门留出一个 sheet，用来记录每位学生每周的日常表现，比如作业情况、课堂状态、课后提问等。

这种方式本身并没有什么问题。对于教师来说，Excel 仍然是最常见、也最容易上手的数据管理工具之一。刚开始，我也是顺着这个思路去做的：把各种信息拆分到不同工作表里，按时间、按考试、按类别一点点维护起来。

但很快我就发现，这种方式虽然能用，却始终有一个明显的限制：它更适合”人工操作”，却不太适合”自然语言驱动”。

当时在 WPS 的 Excel 里，其实还没有真正接入 AI。后来虽然有了灵歧助手，但它更像是一种辅助功能，而不是一个真正意义上的 Agent。也就是说，它并不能像我想象中那样，直接根据自然语言去理解任务、定位表格、修改数据、完成记录。也许 WPS 会员体系里有更进一步的能力，但那意味着还要额外付费。

那段时间，我也关注到 Claude 可能会在后续推出和 Excel 相关的能力，但在当时看来，这件事仍然比较遥远。直到后来，Claude Code 以及 Vibe Coding 这些概念逐渐流行起来，我才开始认真思考另一种可能：既然现有工具不能很好地满足需求，那能不能自己搭一套应用，让我直接通过自然语言去修改数据，从而建立一个学生成绩和日常表现管理系统？

后来，前段时间 OpenClaw 出现了。
我注意到它内置的 Skill 里就包括 Notion，于是就尝试了一下：既然 Excel 这条路暂时走不通，那不如换一个更适合数据库化管理、也更便于 API 调用的工具。

这也是我重新开始认真使用 Notion 的起点。

为什么我最后没有继续围绕 Excel 去做

这里并不是说 Excel 不好。
如果只是做单次成绩统计，或者做一些标准化的数据处理，Excel 依然非常强大。

但我当时想解决的问题，并不只是”把成绩记下来”。

因为除了考试成绩之外，我还需要记录许多持续发生的、带有过程性的内容。比如：

• 某位学生最近作业完成得怎样
• 某位学生课堂状态是否稳定
• 某位学生这周是否主动来问过题
• 某次测试之后，哪些学生需要进一步跟进

这些内容和单纯的分数不太一样。
它们不是一次性填完就结束的数据，而是围绕”学生”这个对象不断累积的记录。

如果完全用传统表格思路来处理，当然也可以做，但你会越来越依赖人工维护：
要不停地切换 sheet，不停地找对应行列，不停地考虑这一条信息应该落在哪个位置。

更关键的是，我真正想要的，并不是”更复杂的表格”，而是”可以通过自然语言直接操控的数据系统”。

也就是说，我希望自己说一句话，系统就能够理解我的意图，然后去完成录入、更新、查询这些动作，而不是我始终要亲自进入表格界面，一格一格地修改。

从这个角度看，Excel 更像是一个非常强的表格工具，但并不天然适合作为我这类需求的最终承载者。

为什么后来选择了 Notion

在对比了几种方案之后，我最后选择了 Notion。

一开始的原因其实很直接：OpenClaw 已经内置了 Notion 的 Skill，可以直接接入使用。这意味着我不需要从零去搭建很多底层能力，而是可以先把整条链路跑通，再考虑后续优化。

另一方面，在很长一段时间没用 Notion 之后，我重新用起来时也发现，它现在自己也加入了 AI 功能。只不过实际体验下来，使用额度很快就会达到上限，能做的事情比较有限。至于如果用 CodeX 或者 Claude 去接 Notion MCP，至少在我这边的实践里，能力也相对有限，很多时候只能读取页面，真正涉及写入、删除、更新等操作时，就没有那么顺手了。

而 OpenClaw 接入 Notion 之后，给我的感受完全不一样。
它不仅可以读取页面和数据库，还可以真正去执行写入、删除、更新之类的操作。也就是说，它不只是”看见数据”，而是”能够动数据”。

这点非常关键。

因为对我来说，我并不是缺少一个能帮我总结页面内容的 AI，我真正缺少的是一个能替我完成数据库操作的 Agent。

从工具形态上说，Notion 也比纯表格更适合我当时的思路。
Notion 的数据库并不只是一个二维表格，它更像是一套围绕对象组织信息的系统。你可以把一个学生看作一条独立的记录，而不是仅仅看作某张表里的一行。

围绕这条记录，可以继续关联成绩、备注、表现、事件、评价等各种信息。这样一来，数据的组织方式就不再只是”横向排开的一堆列”，而是围绕同一个对象逐步积累。

我是怎么设计这套数据库结构的

在我的系统里，最核心的是两张数据库。

1. 学生信息库

这一张主要存放相对稳定的静态信息，比如：

• 姓名
• 学号
• 班级
• 分组或培养方向
• 一些固定成绩字段

例如，张三、李四、王五都各自对应一条独立记录。

2. 学生日常记录库

这一张主要存放动态事件，比如：

• 某次考试或小测的成绩录入
• 某天的作业情况
• 某次课堂表现
• 某次课后提问
• 表扬、提醒、观察记录等

这一层设计对我来说很重要。因为我越来越觉得，做这类系统的时候，最关键的不是”表格做得多漂亮”，而是要先把”对象”和”事件”分开。

学生是对象。
围绕学生持续发生的成绩、作业、课堂表现、提问情况，是事件。

如果一开始把所有东西都塞进一张大表里，短期似乎很省事，但时间一长，结构很容易变乱。反过来，如果把学生主信息和事件记录拆开，再通过关联字段连接起来，整个系统就会清楚很多。

这样做之后，我既可以从学生页面出发，查看某个学生的完整信息和全部时间线；也可以从记录库出发，按时间、按类型、按班级统一筛选和查看所有事件。

OpenClaw 接进来之后，交互方式发生了什么变化

如果说 Notion 解决的是”数据结构”问题，那么 OpenClaw 解决的，就是”如何与这套结构交互”的问题。

以前的流程大概是：

打开 Excel，找到对应的 sheet，找到对应学生，输入数据，再检查有没有写错。

现在，一部分场景下我可以直接发送自然语言指令，比如：

“把这次小测成绩录一下：张三 73，李四 68，王五 73。”

或者：

“记一条学生表现：张三今天课后主动来问题，状态不错。”

在这个过程中，OpenClaw 实际上承担了一个中间执行层的角色。
它会先理解我的输入意图，再匹配对应的数据库对象，然后调用 Notion 的 API 去完成写入或更新操作。

换句话说，以前我是亲自操作 GUI；
现在更多时候，是我表达需求，由 Agent 去执行。

这两种工作方式，感受是很不一样的。

而且 Notion 本身又有比较成熟的展示能力。比如我可以：

• 用表格视图看成绩
• 用筛选和排序找特定学生
• 用看板视图做分组管理
• 用时间维度回看表现记录

所以整个系统实际上可以分成两层去看：

一层是 Notion 作为数据库与展示层；
另一层是 OpenClaw 作为自然语言输入和执行层。

把这两层接起来之后，很多原本需要点很多下鼠标才能完成的操作，逐渐可以被一句自然语言替代。

在这个过程中，我越来越认同”胶水编程”的思路

在这套系统的搭建之前，我在学习 Vibe Coding 等相关概念时，也接触到了另一个我觉得很有意思的概念：胶水编程（Glue Coding）。

我现在越来越认同这种思路。

所谓胶水编程，并不是强调我们一定要自己从零开始造出一整套庞大的系统。恰恰相反，它提醒我们：很多时候，市面上已经有很多成熟、稳定、成体系的开源或闭源应用了。我们没有必要为了”看起来更完整”而重复造轮子。

更有效的方式，往往是把这些现有的、优秀的、稳定的”轮子”利用起来，再像胶水一样把它们粘合在一起。

这样做有两个明显的好处：

第一，工作量会小很多。
第二，最终效果往往反而更好，因为你用到的是已经经过大量用户验证的成熟工具。

从这个角度回头看，我最后选择 Notion，其实也是同样的逻辑。

在对比了 Obsidian、飞书多维表格和 Notion 几家之后，我最后还是选择了 Notion。
并不是因为它绝对完美，而是因为它在数据库能力、云端同步、API 可用性以及与现有工具链的衔接上，整体更符合我的习惯。

当然，从另一个角度讲，现在国内也有不少朋友会把 OpenClaw 接到飞书上。飞书本身的办公类应用——包括表格、文档等——数据是互通的，所以理论上也完全可以实现类似的功能。只是我个人对飞书那一套逻辑不太习惯，所以最终还是直接采用了 Notion。

很多时候，我们其实不必被传统 GUI 思维束缚住

在做这件事的过程中，我还有一个越来越明确的感受：
很多时候，我们不需要被传统 GUI 的思维方式束缚住。

过去我们习惯于认为，一个应用就应该长成某种固定样子：
要么是手机 App，要么是电脑客户端，要么是网页界面，而且这些界面最好尽可能适合人类手动操作。

但现在未必一定如此。

以我现在这套流程为例，我完全可以通过手机或电脑上的 IM 应用（比如 TG）接入 OpenClaw，然后在对话里直接发送信息，再由 OpenClaw 去读取和调用 Notion 的 API，对数据库和页面进行读写操作。

从结果上看，这和自己专门打造一个 App 去做了这件事，并没有本质区别。
有时候，体验甚至还更好，因为交互更直接，路径更短，也不需要额外维护一层复杂前端。

而 Notion 本身就是建立在云端之上的，不管是移动端还是电脑端都有相应的 App，自动同步也已经做得比较成熟。所以从使用角度看，它已经天然提供了数据承载和多端同步能力，我只需要把”输入和执行”这一层补齐就够了。

看了很多前辈和开发者的总结之后，我现在也越来越认同一种趋势：
未来很多网站，可能都会越来越偏向 API，或者进一步说，偏向类似 MCP 这样的能力接口。

与此同时，很多应用也未必还需要一个传统意义上完整的 GUI。
有些场景下，它们可能会更多地以 CLI、Agent、API 调用链这样的形式存在。

这套逻辑，其实可以推广到很多行业

虽然我最初是从教育场景出发做了这件事，但后来我越来越觉得，这种逻辑本身其实很通用。

它的本质，说到底就是：用自然语言去打造和操控一个数据库。

学生只是我当前这个场景下的”对象”。
围绕学生不断产生的成绩、作业、课堂、提问记录，是”事件”。

如果你把这个思路稍微抽象一下，就会发现它几乎可以迁移到很多别的领域：

• 客户信息与跟进记录
• 项目主表与任务进展
• 内容选题与写作进度
• 社群成员信息与互动记录
• 个人目标与日常行为数据

只要你的工作里存在一个相对稳定的主体，以及围绕主体不断发生的动态记录，那么这种数据库思路基本都可以成立。

而一旦接入像 OpenClaw 这样的 Agent，交互方式也会进一步变化。
你不再只是”手动维护数据库”，而是在用自然语言驱动数据库。

我觉得这一点本身，比”用的是哪个具体软件”更重要。

最后

回头看，这套系统对我来说最有价值的地方，并不只是把 Excel 换成了 Notion，也不只是接入了一个 AI 工具。

更重要的是，我开始慢慢形成了一种新的工作思路：

不是急着自己从零做一个全新的应用，
而是先看现有世界里，哪些工具已经足够成熟，哪些能力已经足够稳定，再把它们组合起来，让它们服务于自己的实际需求。

从这个角度讲，OpenClaw + Notion 这套方案，对我来说更像是一种方法上的验证。
它验证了两件事：

第一，很多时候我们可以不必拘泥于传统 GUI 软件的形态；
第二，很多行业、很多场景，其实都可以通过自然语言去构建和操控一套数据库系统。

至少在我现在的使用体验里，这种方式已经比过去单纯依赖 Excel 顺手很多，也更接近我理想中的工作流了。

附录：一个非常简易的搭建教程

这一部分不是完整教程，只是把我目前的做法做一个简单说明，方便有兴趣的朋友快速理解整套结构。

一、我目前主要用了哪些数据库字段

我现在主要用了两张数据库：一张是”学生信息库”，一张是”学生日常记录库”。

1. 学生信息库

这一张库我主要放的是相对稳定的信息。常见字段包括：

• 姓名：文本
• 学号：文本或数字，建议作为唯一标识
• 班级：Select
• 分组/方向：Select
• 性别：Select（可选）
• 备注：Text
• 各次考试成绩字段：Number
  例如”小测1””小测2””月考1””期中考试”等
• 学生记录关联：Relation
  关联到”学生日常记录库”
• 最近更新时间：Last edited time

如果不想一开始做得太复杂，可以先只保留最核心的几个字段：姓名、学号、班级、分组、若干成绩列。

2. 学生日常记录库

这一张库主要用来放动态事件。常见字段包括：

• 记录标题：Title
  可以简单写成”张三-课堂表现””李四-作业记录”
• 对应学生：Relation
  关联到”学生信息库”
• 记录日期：Date
• 记录类型：Select
  比如”作业””课堂””提问””考试””表扬””提醒”
• 记录内容：Text
• 涉及成绩：Number（可选）
• 记录人：Text（可选）
• 创建时间：Created time

如果你希望后续做筛选和统计，那么”记录类型”和”记录日期”这两个字段会比较有用。

二、我是怎么和 OpenClaw 对话来使用这个功能的

我现在的使用方式，其实很简单，本质上就是把 OpenClaw 当成一个”能够理解自然语言并执行数据库操作的助手”。

常见对话大概有这几类。

1. 录入成绩

例如：

把这次小测成绩录一下：张三 73，李四 68，王五 73。

或者更具体一点：

请把这次”复数小测”的成绩录入到学生数据库：张三 73，李四 68，王五 73。

如果你的数据库字段名本身就叫”小测3”或者”复数小测”，那 OpenClaw 更容易直接对应到具体字段。

2. 记录日常表现

例如：

记一条学生表现：张三今天课后主动来问复数题，思路比较清楚。

或者：

在学生日常记录库里新增一条记录：李四，本周作业完成不够稳定，需要继续观察。

这类输入更适合写入”学生日常记录库”，而不是直接写在学生主表里。

3. 查询信息

例如：

帮我查一下张三最近有哪些日常记录。
帮我看看李四这几次小测成绩。
列出最近一周有课后提问记录的学生。

这类需求更偏读取和汇总，适合让 OpenClaw 去读 Notion 数据后返回结果。

4. 修改或删除记录

例如：

把刚才张三那条记录里的”状态不错”改成”状态明显好转”。
删除王五昨天那条重复的作业记录。

这也是我觉得 OpenClaw 接入 Notion 比较有意思的一点：它不仅能读，还能真正做写入、修改、删除这类动作。

当然，实际使用时，我比较建议先从”新增”和”查询”两类操作开始，等数据库结构稳定以后，再逐步尝试更复杂的修改操作。

三、怎么在 Notion 里建立数据库页面，并找到 OpenClaw 的集成

这一部分我也只写最简流程。

第一步：先在 Notion 里新建页面

你可以先建一个总页面，例如叫：

• 学生管理系统
• 学生成绩与表现库
• Student Dashboard

都可以，名字不重要，关键是它作为你的总入口页。

第二步：在页面中插入数据库

在这个总页面里，输入 /database，然后选择你需要的数据库形式。

一般我会建议先建两个 Full page database 或者 Inline database：

• 学生信息库
• 学生日常记录库

如果你喜欢都放在同一个总页面下，就用 inline database；
如果你希望每张库单独占一页，就用 full page database。

第三步：设置字段

数据库建好后，把前面提到的字段慢慢补进去就行。
一开始不用追求特别完整，先把最常用的字段搭起来。

建议优先做这几个：

学生信息库：

• 姓名
• 学号
• 班级
• 分组
• 一两个成绩字段

学生日常记录库：

• 标题
• 对应学生
• 日期
• 类型
• 内容

先把最小可用版本跑通，比一开始就设计得很复杂更重要。

第四步：在 Notion 中连接对应的集成（Integration）

这一点很重要。

即使数据库已经建好了，如果没有把数据库连接给对应的 Integration，外部工具也不一定能访问到它。

通常的做法是：

1. 打开你的数据库页面
2. 点击右上角的菜单或分享相关入口
3. 找到 Connect to、Connections 或类似选项
4. 选择你需要授权的 Integration

如果这一步没做好，常见现象就是：数据库明明存在，但 API 调用时会报 404 或权限不足。

第五步：在 OpenClaw 中启用 Notion 相关能力

在 OpenClaw 里，找到 Notion 对应的 Skill 或集成入口，然后按照它的提示完成授权和连接。

一般来说，核心就是两件事：

• 让 OpenClaw 拿到你的 Notion 访问权限
• 确保你要操作的数据库已经共享给这个 Integration

只要这两步都完成了，后面就可以开始用自然语言去测试最基本的读写操作了。

四、一个最小可用的测试顺序

如果你是第一次搭，比较建议按这个顺序测试：

1. 先在 Notion 手动建好两张数据库
2. 先手动录入两三个学生，例如张三、李四、王五
3. 把数据库连接给对应的 Integration
4. 在 OpenClaw 里测试读取
   • 例如：帮我读取学生信息库里的所有学生
5. 再测试新增记录
   • 例如：记一条学生表现：张三今天课后主动来问问题
6. 最后测试成绩写入
   • 例如：把这次小测成绩录一下：张三 73，李四 68

这样做的好处是，出了问题比较容易定位。
如果一上来就做复杂流程，一旦报错，往往很难判断到底是数据库结构、授权、字段命名，还是对话指令本身出了问题。

五、最后补充一句

我自己的这套系统，其实也还在持续调整中，并不是一个已经完全定型的”最终版本”。

但至少到现在为止，我觉得有两点已经比较明确：

第一，先把数据库结构想清楚，比急着做复杂自动化更重要。
第二，只要底层数据库和 API 打通了，用自然语言去管理数据这件事，确实会比传统手动点表格顺手很多。

如果你也有类似需求，不管是教育、项目管理，还是别的记录场景，都可以先从一个最小版本开始尝试。