说实话一开始我把 Notion 当成一个高级表格来用建了张数据库、拖了张看板视图每天把任务卡片从一个栏挪到另一个栏然后……就没有然后了。到周五复盘的时候我还是得靠脑子回忆上周是不是漏了什么。后来我把 DeepSeek 接进了这套 Notion 工作流让它每天早上帮我看一遍任务清单输出今天值得做的三件事建议延期哪些任务哪个项目其实已经过载了——看板才真正从一面墙变成一个有判断力的助理。这篇文章不是讲神奇的 AI 魔法而是我实际搭这套个人工作看板的全过程数据库字段怎么设计、DeepSeek 怎么接入、任务管理规则怎么一步步从手动拖卡片变成自动出建议。适合两种人一种是已经在用 Notion 但觉得看板只是换了个样子的 Excel另一种是刚接触 DeepSeek API想找一个能落地、不烧钱的个人项目练手。看完以后你完全可以照着搭一套属于自己的。1. 为什么把Notion和DeepSeek绑在一起我不再只是往看板里粘卡片1.1 普通看板只解决了存放问题没解决选择问题Kanban 视图的价值我一直是认的状态一目了然拖拽操作符合直觉。但用久了你会发现看板本质上只是把任务存在了一个结构化的地方。它记录的是一项任务现在在哪个阶段却没有回答我今天到底该打开哪个任务开始干活。当任务只有七八条的时候没问题靠脑子就能排。但当一个月的任务堆到三四十条分布在好几个项目里再赶上几个截止日期都挤在同一周看板就开始失控了。我每周五都要对着屏幕愣半天一项项过这个是不是该做了那个是不是已经废了其实多数任务只需要三秒判断——没到截止日期放着今天到期必须做延期了得加班处理——但这些判断每次都要人工重复一遍纯属浪费时间。1.2 DeepSeek 加入之后任务决策链发生了变化我搭这套系统的核心思路是把决策从人脑搬到规则和 AI 上。现在每天早晨 8 点半服务器上有一个 Python 脚本自动运行通过 Notion API 把所有未完成任务连同状态、优先级、截止日期、所属项目拉出来整理成一段结构化的文本扔给 DeepSeekDeepSeek 根据我预先写好的判断规则输出一份今日工作简报脚本把这份简报写回 Notion 的一个字段里。我起床打开手机不用再自己翻看板先看这份简报就够了。以前我是在管理一个看板现在更像带了一个实习助理它帮我做粗筛和初判我只负责做最终决定。想改判断规则也不用改脑子里的习惯改一段提示词或者一条公式就行。1.3 为什么选 Notion 和 DeepSeek 这两样选 Notion是因为它的数据结构对自动化非常友好。Select、Multi-select、Date、Relation、Rollup 这些字段类型不是摆设它们天然就是机器可以读的状态变量。而且 Notion 官方 API 很成熟查询数据库、更新属性都是标准 REST 接口个人免费额度完全够用。再加上视图切换方便同一份数据既能看板也能日历、表格一套数据可以换五种展示方式。选 DeepSeek直接原因是成本。个人项目不像公司没有预算买贵的 API。DeepSeek 的 API 价格低而且接口是 OpenAI 兼容的我用的 SDK 都不用换改个 base_url 就能跑。再加上它对中文任务描述的理解确实在线让它读任务清单输出建议比我之前试过的几个模型都更靠谱。如果你对数据敏感度有要求DeepSeek 还支持本地部署后面我会单独说这条路线的适用场景。1.4 整体数据流长什么样这套系统的逻辑可以用四层来理解存储层Notion 数据库任务、项目、周报都在这。它是唯一的事实来源所有判断都基于这层数据。调度层一个定时任务cron或者 n8n 工作流负责按时触发自动化流程。智能层DeepSeek API接收任务清单按照我写的规则产出判断建议。展示层Notion 视图、看板卡片、每日简报字段把结果展示给我。关键点是第一层一定要干净可靠字段乱、数据脏后面所有规则都是空谈。这也是为什么我先把大量时间花在看板数据模型上而不是急着写代码。2. 看板字段设计自动化规则的地基2.1 设计字段之前先问一个问题所有自动化规则本质上都是在读字段、判断字段、更新字段。所以每个字段在创建时都要回答一个问题自动化脚本或者公式能不能用这个值做判断如果一个字段只是给人看的描述性文字那它对规则没有意义。举个例子很多人喜欢把截止日期写在任务标题里比如写周报 周五前交。这样人眼能看懂但脚本拿到标题只能做文本匹配没法计算还有几天到期。正确的做法是建一个 Date 类型的截止日期字段AI 和公式才能用 dateBetween 函数算出剩余时间。这是我从头搭这套系统最重要的一条经验字段设计不是给眼睛看的是给机器看的。2.2 我的任务数据库字段清单下面是我实际在用的任务数据库字段设计你可以直接抄作业字段名类型用途与自动化价值任务名称Title任务主体状态Select待办/进行中/已完成/已取消脚本按它过滤优先级Select高/中/低排序和 AI 判断的输入标签Multi-select工作/生活/学习/维护用于分组统计截止日期Date与 now() 配合计算紧急度预估工时Number做日排期的总量控制所属项目Relation关联项目库Rollup 聚合项目任务量完成日期Date周复盘统计本周完成量是否阻塞Checkbox标记异常AI 风险识别会读它AI 建议Rich text脚本写回 DeepSeek 的每日产出前五个字段是核心没有它们自动化跑不起来后几个字段是锦上添花根据你的场景挑着加就行。我最开始只有六个字段后来发现要做周复盘的时候才补了完成日期要做项目聚合的时候才补了所属项目。2.3 Relation 和 Rollup把零散任务串成项目个人看板用久了会发现一个问题任务都是散的但它们的归属是某个项目。比如我手里的整理博客草稿更新部署文档修复搜索页 bug三个任务其实都属于博客重构这个项目。如果不在数据层把它们关联起来每次复盘都要靠人脑归类。我的做法是建一个项目数据库里面只有项目名、项目状态进行中/已归档、项目负责人三个字段。任务表通过 Relation 关联到项目表的某一条记录。然后在项目表里加几个 Rollup 字段就能自动聚合出项目总工时 所有关联任务的预估工时之和已完成任务数 统计关联任务中状态为已完成的数量项目总任务数 统计关联任务总数。这样我在项目表就能看到每个项目的负载和进度不用再跑到任务表里数卡片。这个自动聚合能力在周复盘的时候尤其香后面我讲周复盘脚本时你会看到它多省事。2.4 字段命名稳定比字段丰富更重要这个坑我踩得很痛。早期我把状态选项设计成待办进行中已完成已取消后来觉得已完成不好看改成了Done因为我参考的某个模板用的是英文。结果第二天脚本跑出来一片空白排查了半天才发现是状态名匹配不上脚本里写的是select 已完成而 Notion 里实际的值是Done。这提醒我Select 字段的选项名会被脚本硬编码当成字符串匹配命名一旦定了就别频繁改。即便要改也要先检查脚本和公式里所有引用位置。类似的坑还有把某个字段从 Select 类型改成 Multi-select公式里的prop(优先级) 高会直接失效因为前者是字符串比较后者是数组包含判断。所以在字段图上我建议把机器可读的稳定字段和给人看的灵活字段分开前者如状态、优先级、截止日期后者如备注、标签、AI 建议可以随便折腾。3. 接入DeepSeek的三条路线Python、n8n和本地部署3.1 准备工作创建 Notion 集成并拿到数据库 ID不管选哪条路线第一步都是创建 Notion Integration。去www.notion.so/my-integrations页面新建一个 Internal Integration拿到一串以secret_开头的 token。然后在你要开放的数据库页面右上角点 Share把刚创建的 integration 邀请进去这样它才有权限读写。数据库 ID 怎么找打开数据库页面URL 长这样https://www.notion.so/1234567890abcdef...其中1234567890abcdef这 32 位字符就是 database ID。如果你用的是 Notion 新版 URL 格式可能会在?v参数后面找到那串 32 位的 hex 字符串就行。提示Integration Token 就是你的 API 密钥千万别提交到公开的 GitHub 仓库里。个人项目我习惯用环境变量或者.env文件存再在.gitignore里把它忽略掉。3.2 路线 APython 脚本主力方案我主力用的是 Python 脚本原因很直接灵活。规则想怎么改就怎么改有问题能加日志排查还能方便地处理重试、限速这些边界情况。核心就两个调用一个是 Notion API 查询任务一个是调 DeepSeek API 做分析。先看 Notion 查询部分。下面这段代码把所有未完成任务拉出来import os import requests NOTION_TOKEN os.getenv(NOTION_TOKEN) DATABASE_ID os.getenv(NOTION_DATABASE_ID) headers { Authorization: fBearer {NOTION_TOKEN}, Notion-Version: 2022-06-28, Content-Type: application/json, } payload { filter: { and: [ {property: 状态, select: {does_not_equal: 已完成}}, {property: 状态, select: {does_not_equal: 已取消}}, ] } } resp requests.post( fhttps://api.notion.com/v1/databases/{DATABASE_ID}/query, headersheaders, jsonpayload, timeout15, ) tasks resp.json().get(results, []) # 这里可以打印 tasks 看看结构提取字段拼成文本然后是 DeepSeek 调用。DeepSeek 的接口是 OpenAI 兼容的所以我直接用openai库只改base_urlfrom openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com, ) resp client.chat.completions.create( modeldeepseek-chat, messages[ { role: system, content: ( 你是一名严谨的个人项目助理。你收到一份任务清单 格式为任务名|状态|优先级|截止日期|预估工时|所属项目。 请输出三部分1) 今天必须完成的3个任务及每个理由 2) 建议延期的任务3) 风险提醒长期未更新、项目过载等。 语气客观简洁不要用markdown格式。 ), }, {role: user, content: task_text}, ], temperature0.7, ) result resp.choices[0].message.content这里task_text就是上一步从 Notion 拉出来的任务列表整理成几行文本。整个链路跑通之后把结果用 Notion API 的更新页面属性接口写回AI 建议字段第二天打开看板就能看到。3.3 路线 Bn8n 可视化编排适合不想写代码的人如果你看到代码就头大n8n 是很好的替代。它在服务器上以一个网页工具的形式跑你可以用可视化的方式拖出整个流程Schedule Trigger定时触发→ Notion Node查询任务→ HTTP Request Node调用 DeepSeek API→ Notion Node更新页面字段。n8n 的优点是改流程直观节点配置都是图形界面。缺点是复杂判断逻辑绕来绕去不如代码直观另外 DeepSeek 不是 n8n 官方内置节点需要用 HTTP Request 节点手动构造请求第一次配置要对着 API 文档稍微研究一下。如果你任务是搭一次就不动n8n 完全够用。3.4 路线 C本地部署 DeepSeek适合数据敏感场景对个人任务管理来说把数据发给外部 API 通常没什么问题。但如果你工作内容比较敏感或者你就是不想让任何数据出内网可以考虑本地部署。用 vLLM 这类推理框架可以在你自己的服务器跑开源的 DeepSeek 模型它也提供 OpenAI 兼容的接口代码几乎可以无缝切换。代价也很明显需要一块像样的显卡或者能接受量化的低端模型效果打折。而且本地部署的维护成本不低模型更新、推理框架升级、显存管理都是事。个人用除非有明确的隐私合规要求否则我不太推荐为了一个小看板上这么重的方案。3.5 三条路线怎么选方案灵活度上手难度成本隐私维护Python 脚本高中低中低n8n 可视化中低中中中本地部署高高高高高如果你只是看了这篇文章想试试先从 Python 路线开始。就算后面要切 n8n 或者本地部署核心思路是一样的查数据、拼提示词、调 API、写回结果。逻辑通了工具只是外壳。4. 任务规则分三层视图过滤、公式计算和AI判断4.1 规则的本质是把平时怎么想的写下来很多人在搭自动化任务管理时会陷入一个误区先学工具再想规则。我建议反过来——先坐下来把过去一周做任务取舍时脑子里的判断写下来。我当时写的是这几条今天到期的任务优先干高优先级的任务可以插队被阻塞的任务不能算我拖延一个任务超过 7 天没动静要提醒自己是不是该砍掉同一项目未完成任务超过 5 个说明项目过载不能再接新需求。这些规则朴素到不好意思拿出来但它们就是自动化的种子。后面所有工作都是把它们翻译成计算机能执行的东西。我按实现方式把它们分成三层视图过滤、公式计算、AI 判断。越靠前越硬、越确定越靠后越软、越智能。4.2 第一层视图过滤零成本的硬规则最简单的一层甚至不用写代码只需要建视图的时候加 filter。我在看板里固定了一个今日视图过滤器条件状态 ≠ 已完成状态 ≠ 已取消截止日期 ≤ 今天优先级 高。打开这个视图眼前只有必须处理的任务其他都眼不见为净。再建一个本周视图条件只是截止日期在本周内用于周末排计划。这层规则的价值在于看板不再展示全部任务而是默认展示当前该看的部分。任务多了以后这个默认过滤能省掉非常多心智负担。4.3 第二层公式计算把紧急度变成可排序的数字视图过滤能筛掉不看什么但同一屏里任务还是平铺的谁先谁后依然靠人工判断。这时候用 Notion 的 Formula 字段算紧急度。我建了一个紧急度公式字段逻辑是if(empty(prop(截止日期)), 无截止, if(dateBetween(now(), prop(截止日期), hours) 0, 已逾期, if(dateBetween(now(), prop(截止日期), hours) 24, 今日紧急, 可安排)))解释一下dateBetween(now(), prop(截止日期), hours)它计算现在和截止日期相差多少小时。如果结果是负数说明已经逾期小于 24 小时说明今天必须处理其他就是可安排。然后我看板排序规则设成先按紧急度分组再按优先级排打开就能看到最要命的事。这里注意一个容易踩的细节如果截止日期为空公式会报错或者显示奇怪的结果所以最外层一定要包一层empty()判断。我一开始没加结果新建任务没有截止日期时紧急度显示已逾期吓得我以为一天漏了八个任务。4.4 第三层AI 判断让 DeepSeek 做软性决策公式只能处理明确的数值条件但项目过载长期未更新任务描述含糊这类判断靠公式写会非常痛苦也写不全。这时候就把规则交给 DeepSeek。AI 判断的核心不是模型有多聪明而是你喂给它的规则说明有多清楚。我在 system prompt 里明确写了几条软规则让它按规则推理只推荐 3 个任务作为今日必做且每个理由必须引用具体字段截止日期或优先级如果某个任务超过 7 天没有状态更新标记为长期未动建议确认是否取消如果同一个项目下未完成任务超过 5 个提示项目过载如果任务名称写得太短、看不出下一步动作标记为描述不清晰。DeepSeek 并不是在思考任务它是在按你提供的规则对结构化数据做推断。这比公式灵活、比人脑稳定。当然它偶尔也会给出不合理的建议所以 AI 建议写回 Notion 的时候我只放在AI 建议字段里作为参考不会直接改任务的截止日期或状态。4.5 一张规则表总结三个层次规则判定输入判定输出实现方式今日必做截止日期 ≤ 今天 且 优先级 高任务进入今日视图视图过滤紧急度分级截止日期距今天的小时数已逾期 / 今日紧急 / 可安排FormulaAI 推荐三件事全部未完成任务及其字段今日建议文本DeepSeek长期未动提醒状态更新时间超过 7 天风险标记脚本 DeepSeek项目过载预警同一项目未完成任务数 5提示信息脚本 DeepSeek这张表的作用是让我每次想加新规则时先想清楚它是硬判断还是软判断该用公式还是 AI想清楚再动手代码只写一遍。5. 时区、字段类型、限速自动化链路里的三处翻车点5.1 时区是第一个坑自动化脚本跑了一周之后我发现一个问题每天早上 8 点半的简报经常把今天到期的和明天到期的混在一起。排查了半天根子在时区。Notion API 返回的日期是 ISO 8601 格式带有时区偏移。而我服务器上的 cron 默认用的是 UTC 时间。我人在东八区脚本里判断今天用的却是 UTC 的今天等于比真实时间慢了 8 小时。8 点半跑的简报按 UTC 看还是凌晨 0 点半日期自然错了一天。解决的方案两个在脚本里把时间统一转成本地时区用 Python 的zoneinfo库在 cron 里直接指定时区在 crontab 第一行写上TZAsia/Shanghai。我的 cron 配置现在是这样的TZAsia/Shanghai 0 8 * * * cd /path/to/project python daily_brief.py logs/daily_brief.log 21加了TZ之后现象立刻消失。提醒一下如果你以后换服务器或者把脚本交给别人部署这类时区写死的问题会非常隐蔽。5.2 Formula 报错字段类型是一切之根Notion 的 Formula 对类型极其严格。prop(截止日期)拿到的是 Date 对象你不能直接拿它跟字符串比prop(预估工时)是 Number 类型你不能直接拼进字符串里当文本显示。我实际遇到过最抓狂的一次把某个 Select 字段换成了 Multi-select。因为 Multi-select 返回的是一个数组prop(标签) 工作这种写法直接失效但从界面看完全正常只有公式一片红。后来我把公式改成contains(prop(标签), 工作)才修复。经验总结Select 字段适合单选状态用判断Multi-select 字段是数组必须用contains判断Date 字段必须经过dateBetween()或formatDate()才能参与比较空值判断统一用empty()别依赖空字符串这类写法。每次改字段类型之前先在 Notion 里打开公式编辑器看右侧的属性类型提示等类型确认了再写表达式能少踩很多雷。5.3 API 429 限速和超时重试机制必须加个人项目最容易忽视的就是限速。Notion API 对单个 integration 的请求频率有限制大约是每秒 3 次。如果你写了一个循环批量更新 20 个任务的状态不加速率控制请求发出去一半就会被 429 打回来。DeepSeek API 也有类似的速率限制。我的处理方式很简单所有请求都走同一个函数加上重试和退避。import time import requests def call_with_retry(func, retries3, base_delay1): for i in range(retries): try: return func() except requests.exceptions.RequestException: time.sleep(base_delay * (2 ** i)) return None同时每次请求之间至少time.sleep(0.4)给 API 一点喘息的空间。批量写任务的时候我甚至会把 sleep 加到 1 秒反正个人脚本又不追求吞吐量稳比快重要。5.4 网络不稳时的降级方案如果你访问 Notion API 的网络路径不稳定脚本偶尔会报 ConnectionError 或者读超时。这种问题没法根治只能从工程上兜底所有请求都设timeout默认 10 到 15 秒别让脚本卡死请求失败按上面的重试函数重试几次重试仍然失败时发一条告警消息到自己的微信或邮箱然后退出。最重要的降级方案是AI 挂了看板仍然得能用。所以我从来没有把任务管理的基本功能构建在 AI 返回上面。紧急度公式、视图过滤、手动拖拽这些都不依赖网络和 API。AI 只是额外层它挂了最多没有每日简报不影响我正常使用看板。这个设计思路让我在遇到 API 波动的时候从来不慌。6. 规则跑起来之后日报、周复盘和一点扩展6.1 每日简报长什么样脚本跑通之后的第三天早晨我打开 Notion看到AI 建议字段里写着一份这样的内容今日重点完成 Notion API 集成文档——今日 14:00 截止高优先级修复博客搜索页 bug——已逾期 1 天且阻塞部署上线整理本周周报素材——预计 2 小时建议上午完成。风险提醒设计分享 PPT已连续 6 天未更新请确认是否取消 建议将数据库归档延期至下周一当前预估工时 1 小时不紧急 提示客户反馈表名称过短无法判断下一步动作建议补充具体交付物。说实话第一次看到这份简报的时候我有点被震到。不是因为它多聪明而是因为它把我本来要花 20 分钟想的事情压缩成了 30 秒能看完的建议。而且它给出的延期理由、风险标记都很合理大部分情况我直接采纳。6.2 周复盘把数据分析交给脚本和 AI周复盘我做了第二套脚本逻辑和每日简报类似但数据口径不同。它在每周日傍晚运行查询条件变成完成日期在本周之内然后把这一周完成的任务列表拉出来。先做基础统计——完成数量、按项目聚合的工时、按标签聚合的分类——再把清单交给 DeepSeek 生成一段周总结。配合项目表的 Rollup 字段我甚至不用额外写聚合逻辑数据库里直接能查到每个项目的本周完成量和总工时。DeepSeek 拿到这些数据生成的内容基本就是一篇能直接贴到周报里的草稿。以前我写周报要对着看板翻半小时现在脚本 2 分钟跑完我再花 5 分钟改改措辞就发出去了。6.3 扩展玩法收集箱入口与团队看板这套系统稳定跑了一个月之后我开始琢磨入口侧的优化。现在收任务主要有几个渠道微信上别人发来的消息、自己临时想到的点子、邮件里需要跟进的事项。于是我把 Notion 弄成了一个收集箱微信消息可以通过转发工具或机器人直接存进 Notion 数据库存的时候打上待整理标签手动快速添加任务时只填任务名称和截止日期其他字段后续再补每天简报运行时AI 会专门检查收集箱里待整理的任务建议哪些该转成正式任务、哪些该删掉。核心思路是入口一定要低门槛出口一定要自动分析。不能因为字段复杂就拒绝记录也不能让记录进来的东西永远是一堆垃圾。中间那层清洗、归类、判断的工作正好是脚本和 AI 的活。如果你想把这套方案用于小团队改动也不大任务表加一个负责人字段每日简报脚本按负责人分组分别生成每个人的今日重点。Notion 本身也支持多人在线协作数据的编辑和同步都不是问题。6.4 最后说点个人体会这套系统用到现在我最大的感受是它没有让我变得更自动化崇拜反而让我更清楚哪些判断必须亲手来做。AI 给的只是基于字段状态的参考它不懂我当时为什么接下这个需求也不懂某个客户随口一提背后有多重要。所以我把 AI 定位成提醒者而不是决策者真正的决策权始终在我手里。另外别过度自动化。我现在仍然保留手动拖拽任务状态的操作——不是说不能自动而是这个动作本身就带着一种仪式感当你把一张卡片从进行中拖到已完成你会下意识复盘一次这项任务的来龙去脉。这种复盘算法替代不了。如果你也想搭一套不要一上来就追求什么复杂的自动化流程。先把看板用起来梳理出自己真实的决策规则再一点点加脚本、接 API。规则清楚的人用什么工具都能跑得很好规则不清楚再大模型也帮不了你。