ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Grok + Notion API 实现关注列表自动同步与备份全流程

Grok + Notion API 实现关注列表自动同步与备份全流程 这篇不写概念直接给能落地的流程用 Grok Bot 把社交平台的关注列表定时同步进 Notion手机也能配置正常情况下 10 分钟跑通第一版后面挂成定时任务就能自动维护。整个过程涉及 Grok 的 AI 对话/生成能力、Notion 的开放 API、手机端的脚本执行环境以及四个可以直接套用的真实场景。先说结论这不是某个非要下载的 App而是一条“数据获取 Grok 整理 Notion 写入”的自动化链路。你只需要拿到关注列表的 JSON 或导出文件让 Grok 帮忙生成/修正脚本再把结果写进 Notion 数据库。四个典型场景分别是关注列表备份、按主题自动分类、追踪取关和新增变化、生成每周关注清单与运营报告。下面从能力速览开始逐步把步骤、代码、排错全部展开。1. 核心能力速览能力项说明项目类型自动化同步工具链核心由 Grok API Notion API 组成是否需要专用客户端不需要理解为可复制的脚本流程不建议下载来路不明的“Grok Bot 安装包”手机端支持支持可通过 Termux、自动化 App、云函数调用电脑端支持支持Python 3.9 即可核心依赖Grok API 密钥、Notion 集成 Token、关注列表数据源是否支持批量任务支持关注列表可分批次写入可做失败重试是否提供 API写入端走 Notion API整理端走 Grok 对话/补全接口主要功能关注列表备份、自动分类、取关追踪、周报生成上手难度低复制脚本替换 Token 即可适合第一次接触 API 的读者适合场景博主粉丝管理、内容运营、个人知识库维护这里有一个很重要的前提关注列表属于平台数据能不能拿、怎么拿要以对应平台的开放 API 或导出能力为准。本文的方案假设你已经通过合规途径拿到了关注列表数据后面所有脚本只处理这份数据。2. 适用场景与四个真实用法2.1 场景一关注列表定期备份很多人会把关注列表当成“收藏夹”但平台账号一旦变动、误操作或平台规则调整关注数据可能说没就没。用 Notion 做备份本质是给关注列表建一个外部副本。操作逻辑很简单每天或每周固定时间把当前关注列表同步到 Notion 数据库。数据库里每条记录对应一个关注对象字段包括昵称、主页链接、简介、关注时间、备注标签。这个场景的价值在于“可检索、可回溯”。Notion 数据库支持按字段筛选和排序即使平台端没有分组功能你也能在 Notion 里按时间、按标签快速找到某个人。2.2 场景二按主题自动分类关注列表超过 200 人以后人工维护分组的成本非常高。第二类场景是用 Grok 根据每个博主的名称、简介、备注信息自动打标签再写进 Notion 的“分类”字段。典型做法是先把关注列表导出成 JSON提取每个关注对象的简介文本然后把简介批量发送给 Grok让它返回分类结果。你可以指定分类体系比如“AI / 效率 / 设计 / 数码 / 生活”也可以让 Grok 自己聚几类出来。这一步能直接用是因为简介文本通常很短用 AI 做分类非常快且不需要训练模型。分类结果从 Grok 返回后脚本再逐条写入 Notion最终得到一个带标签的关注库。2.3 场景三追踪取关和新增变化关注列表是动态的。今天关注了谁、取关了谁靠人工点开列表去对比很不现实。第三类场景是把每次同步结果和上一次快照做差集自动标出“新增关注”和“移除关注”。实现上在 Notion 数据库里增加两个字段last_seen和status。第一次同步把所有记录标记为active之后每次同步时平台列表里存在、数据库里不存在写入新记录状态为new平台列表里已不存在、数据库里之前是active把状态改为removed两边都存在更新last_seen状态保持active。这样打开 Notion 表格按status筛选就能看到这段时间新增了谁、取关了谁。对做粉丝运营或账号研究的人来说这是四个场景里数据价值最高的一个。2.4 场景四每周生成关注清单与运营报告第四类场景适合内容创作者和运营人员。每周把本周新增关注、取关、分类分布汇总起来让 Grok 生成一段简洁的运营日报写入 Notion 的周报页面。如果数据源能提供“最近更新动态”还可以让 Grok 进一步提炼重点账号的内容方向。如果数据源没有这类信息脚本就退化为统计型报告本周新增多少人、集中在哪些标签、移除了哪些人。报告输出格式可以固定成 Markdown直接在 Notion 页面里展示。长期积累后能形成一份不错的关注趋势记录。3. 环境准备与前置条件在写代码前先把四个前置条件准备好。每一项都缺一不可。前置条件作用怎么获取注意事项Notion 集成 Token调用 Notion API 写数据在 Notion 的集成管理页创建 IntegrationToken 以secret_开头只在服务端保存Notion 数据库 ID指定写入哪个表格打开 Notion 数据库页面从 URL 中复制 32 位字符串注意是数据库页 URL不是普通页面 URLGrok API 密钥调用 Grok 做分类、摘要、代码生成在 Grok 官方开放平台创建 API Key保存好密钥不要提交到公开仓库关注列表数据源程序读取关注对象信息平台开放 API 或导出功能必须走合规渠道不能绕过访问限制3.1 Notion 集成创建步骤登录 Notion打开集成管理页面创建一个新的 Integration给它命名例如Grok-Following-Sync。创建完成后复制内部的 Token这个就是NOTION_TOKEN。回到 Notion 页面新建一个数据库数据库名称可以叫“关注列表”。在数据库页面右上角菜单里把刚才创建的 Integration 连接到这个数据库。从浏览器地址栏复制数据库 URL 中?v前面的那串 32 位 ID这个就是DATABASE_ID。需要注意Notion 的连接权限是按页面和数据库单独授权的。如果 API 返回 404先检查是否在数据库页面里手动关联过 Integration。3.2 Grok API 密钥准备Grok API 密钥通常在你的 Grok 服务开放平台创建。创建后把它写到本地环境变量或配置文件中不要写死在博客示例代码里。这里的“Grok Bot”可以理解为你通过 Grok API 让 AI 帮你生成脚本、解析数据、做文本分类再配合 Notion API 完成写入。也就是说Grok 负责“理解和生成”Notion API 负责“存储和展示”。3.3 关注列表数据源准备这是整个流程里最需要按实际情况调整的部分。不同的平台开放程度不一样有些平台提供官方 API能直接分页拉取关注列表有些平台支持导出 JSON 或 CSV有些情况下你可能需要先手动导出再上传到手机或云端。无论哪种方式最终数据应该是一个数组每个元素至少包含id、name、description、url。下面的脚本都以这个结构作为输入你可以按实际字段改名。4. 10 分钟搭建流程如果材料都准备好了时间分配大致是这样的时间操作2 分钟创建 Notion Integration复制 Token 和数据库 ID2 分钟准备好关注列表 JSON 数据4 分钟复制下面的 Python 脚本替换 Token 和 ID跑通第一次写入2 分钟在手机上配置定时执行或手动触发方式下面是完整步骤。4.1 第 1 步准备关注列表 JSON把关注列表保存为following.json格式类似[ { id: 123456, name: 示例博主, description: 专注 AI 工具和效率方法, url: https://example.com/user/123456 } ]如果平台返回的字段名不一样例如username、bio先在脚本里手动映射一次。4.2 第 2 步创建 Notion 数据库字段在 Notion 数据库里创建以下字段字段名类型说明昵称标题必填作为记录标题主页URL关注对象主页简介富文本平台简介标签多选用于分类状态选择active / new / removed最近同步时间日期每次更新为当前时间4.3 第 3 步写入环境变量在命令终端设置环境变量export NOTION_TOKENsecret_你的Token export NOTION_DATABASE_ID你的数据库ID如果是 Windows PowerShell$env:NOTION_TOKENsecret_你的Token $env:NOTION_DATABASE_ID你的数据库ID4.4 第 4 步跑通一次同步脚本把下面的脚本保存为sync_following.py首次运行只处理前 10 条数据确认没问题再放开全量同步。4.5 第 5 步手机端触发把脚本放到手机 Termux 环境或云函数里设置定时执行。具体方法在第 8 节展开。5. 同步脚本核心代码下面的代码是最小可用版本只处理“写入新记录”不含取关对比。先跑通这个版本再叠加高级功能。import json import os import requests NOTION_TOKEN os.getenv(NOTION_TOKEN, ) DATABASE_ID os.getenv(NOTION_DATABASE_ID, ) NOTION_VERSION 2022-06-28 NOTION_API https://api.notion.com/v1/pages def load_following_data(file_pathfollowing.json): with open(file_path, r, encodingutf-8) as f: return json.load(f) def create_page(item): headers { Authorization: fBearer {NOTION_TOKEN}, Content-Type: application/json, Notion-Version: NOTION_VERSION, } payload { parent: {database_id: DATABASE_ID}, properties: { 昵称: { title: [ { text: {content: item.get(name, )} } ] }, 主页: { url: item.get(url, ) }, 简介: { rich_text: [ { text: {content: item.get(description, )[:2000]} } ] }, 状态: { select: {name: active} }, 最近同步时间: { date: {start: 2024-01-01} } }, } response requests.post(NOTION_API, headersheaders, jsonpayload) return response def main(): items load_following_data()[:10] # 先测试 10 条 for item in items: resp create_page(item) if resp.status_code 200: print(f写入成功: {item.get(name)}) else: print(f写入失败: {item.get(name)} - {resp.text}) if __name__ __main__: main()运行方式python sync_following.py判断是否成功的标准控制台输出“写入成功”Notion 数据库里出现新的记录每条记录的昵称、主页、简介字段正确。如果返回 400多半是字段类型不匹配如果返回 401检查 Token如果返回 404检查数据库 ID 和页面是否授权给这个 Integration。6. 用 Grok 处理关注列表的三种方式同步脚本写好后Grok 的价值更多体现在数据处理环节。这里给三个可以直接用的方式。6.1 方式一让 Grok 生成脚本不确定时间字段怎么填、不会写差集逻辑直接把需求描述给 Grok我有一段关注列表 JSON结构是 id、name、description、url。 请生成一个 Python 函数把这段 JSON 同步到 Notion 数据库。 数据库字段是昵称title、主页url、简介rich_text、标签multi_select、状态select、最近同步时间date。 每周运行一次需要在写入前比较已有页面避免重复创建。把返回的代码另存为sync_with_dedup.py。用 Grok 生成代码时建议只跑小样本验证不要直接全量运行。6.2 方式二让 Grok 直接做文本分类你不需要本地写任何分类算法。把关注列表的name和description截断后发给 Grok让它返回 JSON 格式的分类结果。下面是 50 条博主信息请按AI、效率、设计、数码、生活、其他分类。 输出格式必须是 JSONkey 是原始 idvalue 是分类标签。 只输出 JSON不要解释。Grok 返回后脚本把结果读出来写进 Notion 的“标签”多选字段。如果一次发送 50 条超出上下文限制就拆成每 20 条一批。6.3 方式三让 Grok 排查同步报错Notion API 报错信息通常包含code和message字段。遇到 400 或 429 时直接把响应文本发给 Grok让它判断是哪一类问题。这是 Notion API 返回的错误请帮我分析可能原因和修复方式 {这里粘贴报错内容}这个方式能显著减少搜索文档的时间尤其是第一次接触 Notion API 时。但要注意不要把 Token 或敏感信息发给 Grok。报错信息里如果包含secret_开头的内容先删掉再提问。7. Notion 字段设计与批量写入7.1 推荐的数据库字段设计从四个场景出发数据库字段建议按这个表格设计字段名类型场景昵称title所有场景主页url所有场景简介rich_text分类、周报标签multi_select分类状态select取关追踪第一次关注时间date备份、追踪最近同步时间date所有场景备注rich_text人工补充这样设计的好处是四个场景共用同一个数据库不需要为每个场景单独建表。分类和周报只是用不同视图筛选数据。7.2 批量写入与失败重试关注列表可能有几百上千条一次性全量写入会遇到两个问题Notion API 速率限制、中途失败导致重复写入。更稳妥的做法是分批写入并记录已成功写入的 ID。import requests import time def batch_create_pages(items, batch_size5, delay1.0): success_ids [] failed_ids [] for i in range(0, len(items), batch_size): batch items[i:i batch_size] for item in batch: try: resp create_page(item) if resp.status_code in (200, 201): success_ids.append(item[id]) else: failed_ids.append(item[id]) print(f失败: {item[id]} - {resp.text}) except requests.exceptions.RequestException as exc: failed_ids.append(item[id]) print(f写入异常: {item[id]} - {exc}) # 请求间隔避免触发 429 time.sleep(delay) return success_ids, failed_ids批量写入失败后建议把失败 ID 写入本地日志文件python sync_following.py --batch 5 --delay 1 --retry脚本里加上--retry参数重试读取日志中失败 ID 对应的数据。7.3 幂等处理思路重复同步是常见问题。最简单的幂等方案是每次同步前先从 Notion 数据库查询已有的“主页”或平台 ID 字段构建一个已存在集合。写入前先判断是否已存在如果存在就跳过。def build_existing_set(): # 调用 Notion 查询接口返回已有记录的 url 集合 existing set() # 实现方式分页请求 /v1/databases/{id}/query return existing def is_existing(item, existing_set): return item.get(url) in existing_setexisting build_existing_set() new_items [item for item in items if not is_existing(item, existing)]如果数据源没有稳定的唯一 ID就用“主页 URL”做唯一标识。这样后期跑多次也不会在 Notion 里出现重复记录。8. 手机端定时同步手机端跑脚本有两种思路直接在本机执行或把脚本部署到云端后通过手机触发。前者适合个人使用后者更稳定。8.1 方案一Termux 执行 Python 脚本Termux 是 Android 上的终端模拟器可以安装 Python并配合 cron 实现定时任务。安装流程pkg update pkg install python cronie pip install requests把sync_following.py和following.json放到同一个目录然后设置定时任务crontab -e在 cron 文件里添加0 9 * * 1 cd /sdcard/grok-sync python sync_following.py sync.log 21上面这条表示每周一早上 9 点运行一次。注意不同 Android 版本对后台任务的限制不一样如果 cron 没有按时触发检查 Termux 是否被系统省电策略杀掉。8.2 方案二手机自动化 App 触发如果你不想装 Termux可以用手机自带的自动化 App 定期打开一个网页服务或调用云函数。比如云函数提供一个 HTTP 接口curl -X POST https://your-cloud-function.example/sync手机自动化 App 只需要每周一、每天早上调用这个 URL 即可。判断脚本是否成功的标准是返回200 OK并且 Notion 里出现新记录。8.3 方案三云端函数定时运行最稳定的方式是部署到云函数或定时任务平台设置 cron 表达式不依赖手机后台。手机只负责查看 Notion 结果不需要一直保持脚本运行。部署到云端后注意以下三点环境变量里保存 Token不要写到代码里设置执行超时时间关注列表较大时应分批处理日志输出到标准输出方便在云端控制台排查。如果只是个人用优先推荐方案一数据在本地逻辑透明调试也直观。9. 常见问题与排查方法问题现象可能原因排查方式解决方案写入时返回 401Notion Token 错误或失效检查 Token 是否以secret_开头重新创建 Integration更新环境变量写入时返回 404数据库 ID 错误或 Integration 未关联查看请求中的 database_id 是否正确在 Notion 页面里重新关联 Integration写入时返回 400字段名或字段类型不匹配检查报错中的property信息对照数据库实际字段类型修改 payload分类接口返回内容不是 JSONPrompt 里没限定输出格式查看 Grok 返回的原始内容在 Prompt 中明确“只输出 JSON不要解释”定时任务不执行手机后台策略杀掉 Termux查看 cron 日志或 Termux 通知栏在系统设置里允许 Termux 后台运行同步出现重复记录没有做幂等判断检查 Notion 数据库里是否有重复 URL增加已存在集合判断用 URL 去重API 请求过于频繁触发 Notion 速率限制查看响应是否为 429调大批次间隔减少并发脚本无法联网手机禁止网络权限或代理冲突测试curl或ping是否正常检查网络连接确认 API 域名可达最容易踩的坑主要有三个Notion 数据库 ID 填错。注意数据库 URL 中的 ID 和普通页面 URL 中的 ID 不是一回事确保复制的是数据库页的。字段类型不匹配。Notion API 对 title、rich_text、select、multi_select 的 payload 结构要求很严格报 400 时优先看字段结构。没有授权 Integration。即使 Token 正确如果数据库页面没有手动关联 IntegrationAPI 依然会返回 404。10. 最佳实践与合规建议10.1 数据合规与隐私关注列表属于平台上的半公开数据但依然要注意通过平台官方 API 或官方导出功能获取不要使用绕过访问限制的采集方式只同步自己账号有权查看的数据不采集他人私密列表如果涉及多个用户的关注数据要确保符合平台服务条款和当地隐私法规。10.2 密钥管理Notion Token 和 Grok API Key 都要按密钥对待不要提交到 Git 仓库不要出现在日志里分享报错信息前先删除可能包含密钥的内容建议用.env文件或系统环境变量保存。# 创建 .env 文件并加入 .gitignore echo NOTION_TOKENsecret_xxx .env echo GROK_API_KEYxxx .env10.3 执行频率控制关注列表不是高频数据建议每天或每周同步一次即可。频繁调用容易触发 API 速率限制也容易让对方平台认为请求异常。10.4 日志与失败重试无论跑在手机还是云端都要保留日志。日志至少包含运行时间、写入成功数量、失败 ID、异常堆栈。批量任务加失败重试前先确认失败原因避免把错误数据不断重试。10.5 先小样本验证第一次跑通用 5 到 10 条数据就够。确认字段、授权、幂等逻辑都没问题后再放开全量同步。批量任务建议先跑一次演练再挂到定时任务上。11. 总结与下一步这个方案最值得先做的事是用 10 条关注数据跑通“写入 Notion”这一步。它能把四个场景里最核心的同步链路打通后面的分类、取关追踪、周报都是在这个基础上叠加。四个场景里价值最高的是取关追踪技术难度也在那里。你需要维护一个“已有记录集合”每次同步做差集并把状态字段从active改成removed。先把第 5 节的脚本跑通再逐步加上去重、差集和分类整个工具链就算是完整了。后续可以扩展的方向包括用 Notion 的公式字段统计每个标签的关注数量每周自动发送一封摘要到自己的邮箱或群聊把分类后的关注列表生成公开页面方便团队共享集成更多数据源把多个平台的关注列表统一到一个 Notion 数据库。这篇文章建议收藏备用。第一次搭的时候把重点放在“小样本跑通”上不要一上来就同步全量数据。跑通后再把 Grok 的分类和总结能力加进去整个流程的价值会越来越大。
返回列表