说实话，一开始我把 Notion 当成一个高级表格来用，建了张数据库、拖了张看板视图，每天把任务卡片从一个栏挪到另一个栏，然后……就没有然后了。到周五复盘的时候，我还是得靠脑子回忆"上周是不是漏了什么"。后来我把 DeepSeek 接进了这套 Notion 工作流，让它每天早上帮我看一遍任务清单，输出"今天值得做的三件事""建议延期哪些任务""哪个项目其实已经过载了"——看板才真正从一面墙变成一个有判断力的助理。
这篇文章不是讲神奇的 AI 魔法，而是我实际搭这套个人工作看板的全过程：数据库字段怎么设计、DeepSeek 怎么接入、任务管理规则怎么一步步从"手动拖卡片"变成"自动出建议"。适合两种人：一种是已经在用 Notion 但觉得看板只是换了个样子的 Excel；另一种是刚接触 DeepSeek API，想找一个能落地、不烧钱的个人项目练手。看完以后，你完全可以照着搭一套属于自己的。
1. 为什么把Notion和DeepSeek绑在一起：我不再只是往看板里粘卡片
1.1 普通看板只解决了"存放"问题，没解决"选择"问题
Kanban 视图的价值我一直是认的：状态一目了然，拖拽操作符合直觉。但用久了你会发现，看板本质上只是把任务存在了一个结构化的地方。它记录的是"一项任务现在在哪个阶段"，却没有回答"我今天到底该打开哪个任务开始干活"。
当任务只有七八条的时候没问题，靠脑子就能排。但当一个月的任务堆到三四十条，分布在好几个项目里，再赶上几个截止日期都挤在同一周，看板就开始失控了。我每周五都要对着屏幕愣半天，一项项过："这个是不是该做了？那个是不是已经废了？"其实多数任务只需要三秒判断——"没到截止日期，放着""今天到期，必须做""延期了，得加班处理"——但这些判断每次都要人工重复一遍，纯属浪费时间。
1.2 DeepSeek 加入之后，任务决策链发生了变化
我搭这套系统的核心思路，是把"决策"从人脑搬到规则和 AI 上。现在每天早晨 8 点半，服务器上有一个 Python 脚本自动运行：
- 通过 Notion API 把所有"未完成任务"连同状态、优先级、截止日期、所属项目拉出来；
- 整理成一段结构化的文本，扔给 DeepSeek；
- DeepSeek 根据我预先写好的判断规则，输出一份"今日工作简报"；
- 脚本把这份简报写回 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 路线 A：Python 脚本，主力方案
我主力用的是 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": f"Bearer {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( f"https://api.notion.com/v1/databases/{DATABASE_ID}/query", headers=headers, json=payload, timeout=15, ) tasks = resp.json().get("results", []) # 这里可以打印 tasks 看看结构，提取字段拼成文本然后是 DeepSeek 调用。DeepSeek 的接口是 OpenAI 兼容的，所以我直接用openai库，只改base_url：
from openai import OpenAI client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com", ) resp = client.chat.completions.create( model="deepseek-chat", messages=[ { "role": "system", "content": ( "你是一名严谨的个人项目助理。你收到一份任务清单，" "格式为：任务名|状态|优先级|截止日期|预估工时|所属项目。" "请输出三部分：1) 今天必须完成的3个任务及每个理由；" "2) 建议延期的任务；3) 风险提醒（长期未更新、项目过载等）。" "语气客观简洁，不要用markdown格式。" ), }, {"role": "user", "content": task_text}, ], temperature=0.7, ) result = resp.choices[0].message.content这里task_text就是上一步从 Notion 拉出来的任务列表，整理成几行文本。整个链路跑通之后，把结果用 Notion API 的"更新页面属性"接口写回"AI 建议"字段，第二天打开看板就能看到。
3.3 路线 B：n8n 可视化编排，适合不想写代码的人
如果你看到代码就头大，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 一张规则表总结三个层次
| 规则 | 判定输入 | 判定输出 | 实现方式 |
|---|---|---|---|
| 今日必做 | 截止日期 ≤ 今天 且 优先级 = 高 | 任务进入"今日"视图 | 视图过滤 |
| 紧急度分级 | 截止日期距今天的小时数 | 已逾期 / 今日紧急 / 可安排 | Formula |
| AI 推荐三件事 | 全部未完成任务及其字段 | 今日建议文本 | 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 第一行写上
TZ=Asia/Shanghai。
我的 cron 配置现在是这样的：
TZ=Asia/Shanghai 0 8 * * * cd /path/to/project && python daily_brief.py >> logs/daily_brief.log 2>&1加了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, retries=3, base_delay=1): 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。规则清楚的人，用什么工具都能跑得很好；规则不清楚，再大模型也帮不了你。
