通过DeepSeek API与Notion API，在自动化平台中搭建问答工作流，让数据库问题自动获取回答并回写页面，零代码也能快速复现。
很多使用者希望把 DeepSeek 的推理能力嵌入 Notion 页面，让数据库里的问题自动获得回答，再把答案归档到知识库。真正要打通的是三个环节：Notion 集成授权、DeepSeek 接口调用、自动触发与回写。下面用极简路径拆解可复现方案，重点放在权限、字段、工作流与调试，避免在配置细节上反复试错。
1. 接入前的账号与权限准备
DeepSeek 开放平台需要注册并创建 API Key。登录 platform.deepseek.com，进入 API Keys 生成密钥，密钥只在创建时显示一次，复制后妥善保存。DeepSeek API 兼容 OpenAI 的 chat completions 协议，基础地址可写 或 ，模型名常用 deepseek-chat 与 deepseek-reasoner。若仅做知识库问答，deepseek-chat 响应快、成本低，适合大多数场景；涉及复杂推理时再切到 deepseek-reasoner。新账号可能有赠送额度，正式使用前在充值页面确认余额与限流策略。
Notion 侧需要创建内部集成。打开 notion.so/my-integrations，新建一个内部集成，命名如 DeepSeek 问答助手，选择目标工作区。创建完成后复制 Internal Integration Token，通常以 ntn_ 或 secret_ 开头。在 Capabilities 中至少勾选 Read content、Update content、Insert content，若需要读取数据库结构，还要确认数据库读取权限。不要把 token 写进 Notion 页面、公开仓库或前端代码，后续在自动化平台中以环境变量或凭据形式保存。
目标数据库必须显式授权给该集成。进入 Notion 数据库页面，点右上角菜单，找到 Connections 或连接，选择刚创建的集成。很多人调用查询接口时收到 object_not_found，并不是数据库 ID 错误，而是集成没有被分享到该数据库。数据库 ID 可从页面链接中截取，通常是 32 位字符，带连字符也可。完成这些准备后，Notion 与 DeepSeek 之间才具备最小可用的通信权限。
2. 构建可触发的Notion数据库
数据库字段决定工作流能否稳定运行。建议至少设置名称 title、问题 rich_text、回答 rich_text、状态 select、模型 select、错误信息 rich_text、耗时 number、完成时间 date。名称用于人工识别，问题保存用户输入，回答接收 DeepSeek 输出，状态控制触发与去重。状态选项设为待处理、处理中、已完成、失败。模型选项设为 deepseek-chat、deepseek-reasoner。错误信息用于记录接口返回的异常，耗时用于观察性能。
触发器依赖状态字段而非页面按钮。Notion 按钮目前难以直接向外部 API 发起任意网络请求，因此更稳妥的是让自动化平台轮询数据库，筛选状态为待处理的记录。以 n8n 或 Make 为例，Notion Trigger 可监听数据库新增项，再通过过滤器只放行待处理状态。为了避免重复处理，工作流开始后先把状态改为处理中，调用完成后再写回答并改为已完成。若失败，则写入错误信息并改为失败，便于人工重试。
建议为数据库建立多个视图。待处理视图只显示状态为待处理，方便检查积压；已完成视图按完成时间倒序，方便复习；失败视图集中展示错误信息。实际使用时，在 Notion 中新建一条记录，填写问题并选择模型，状态设为待处理，自动化平台就会在下一个轮询周期取走任务。轮询间隔不宜过短，免费或低配方案可设 1 到 5 分钟，既能控制 API 调用频率，也能降低触发平台的任务消耗。
3. 用自动化平台串联DeepSeek与Notion
以 n8n 为例，工作流从 Notion Trigger 开始，选择目标数据库，事件设为 Page Added 或 Database Item Created，随后接一个 If 节点判断状态是否为待处理。若使用 Make，则用 Watch Database Items 作为触发器，再添加过滤器。触发器拿到 page_id 和问题文本后，先用 Notion 节点把状态更新为处理中，这一步很关键，可以避免同一记录在轮询中被多次读取。若平台支持并发控制，应把工作流并发数限制为 1 到 3，防止短时间内触发大量 DeepSeek 请求。
调用 DeepSeek 推荐用 HTTP Request 节点，而不是依赖只兼容 OpenAI 默认地址的原生节点。请求地址填 ，方法 POST，认证选 Header Auth 或 Bearer Token，Header 中 Authorization 值为 Bearer 加 API Key，Content-Type 为 application/json。请求体用 JSON，包含 model、messages、temperature、max_tokens、stream 四个关键字段。messages 里放一条 system 消息，例如“你是 AI 指导老师，回答要准确、分点清晰、给出可执行步骤”，再放一条 user 消息，内容引用 Notion 的问题属性。max_tokens 可先设 1500 到 2500，避免超长回答挤占数据库字段。
解析响应时取 choices[0].message.content，写入 Notion 的回答属性，同时把状态改为已完成，写入完成时间和耗时。Notion 更新接口为 PATCH /v1/pages/{page_id}，请求头需带 Authorization 和 Notion-Version，版本可用 2022-06-28。属性结构必须与数据库字段类型一致，rich_text 用 text.content，select 用 name，number 用数值，date 用 ISO 时间。若 DeepSeek 返回 4xx 或 5xx，把错误信息截断后写入错误信息属性，状态改为失败。这样一套工作流即可完成从问题到回答的闭环。
4. 调试、成本与安全边界
调试时先看认证与权限。DeepSeek 返回 401 通常是 API Key 错误或余额不足，404 多为模型名写错或接口路径缺少 chat/completions，400 常见于 max_tokens 超限或 JSON 格式不合法。Notion 返回 401 说明 token 失效，404 往往是集成没有连接数据库或 database_id 错误，400 则要检查属性名称、属性类型和 Notion-Version。建议先用 curl 或 Postman 单独调通 DeepSeek，再用 Notion API 查询一条记录，确认两端都能独立工作后，再回到自动化平台排查映射关系。
成本控制依赖模型选择和字段长度。DeepSeek 按输入与输出 token 计费，deepseek-chat 适合日常问答，deepseek-reasoner 适合数学、推理和复杂规划。可以在 Notion 里限制问题长度，在自动化平台里设置 max_tokens 上限，并在 system 提示中要求“回答不超过 800 字”。若数据库记录很多，不要把整库内容都塞进提示词，只传当前问题与必要上下文。轮询间隔过短、重试次数过多、失败记录反复触发，都会造成不必要的 token 消耗。
安全边界同样重要。API Key 和 Notion Token 只能保存在自动化平台的凭据或环境变量中，不能写入数据库属性，也不能放在公开页面。Notion 集成遵循最小权限原则，只授予目标数据库所需能力。对外分享数据库时，要确认视图不会暴露密钥或内部提示词。若工作流涉及客户数据，应在写入前脱敏，并给失败记录设置人工复核环节。定期轮换密钥、查看 DeepSeek 用量和 Notion 连接记录，能及时发现异常调用。
