用公众号测试号、云函数和 DeepSeek API，二十分钟完成对话接入，免服务器与备案，适合教学答疑。 不少老师想把 DeepSeek 放进做答疑、备课和作业反馈，却误以为必须买服务器、备案域名或开发完整 App。实际最轻量的做法，是用公众平台测试号获取消息入口，再用腾讯云函数或云开发承接 Webhook，把用户发来的文本转成 DeepSeek 的聊天请求，最后按 XML 格式返回答案。整个流程不碰个人外挂，也不依赖复杂前端，配置顺利时半小时内可跑通。
1. 接入路径选择与账号准备
把 DeepSeek 接入，第一决策是走官方接口还是非官方自动化。个人机器人、Xposed 插件、iPad 协议这类方案看似省事，却违反个人账号使用规范，轻则限制登录，重则永久封号，教学场景一旦涉及学生群体会带来不可控风险。稳妥路径有三条：公众号测试号、已认证服务号或订阅号、企业自建应用。测试号最适合验证，它不需要认证和备案，登录公众平台测试号页面就能拿到 appID、appsecret 和接口配置权限，支持接收文本消息并被动回复。认证服务号适合正式对外，企业适合校内组织，但起步阶段不必增加审核成本。 账号准备同时进行。到 DeepSeek 开放平台注册并创建 API Key，密钥只在创建时显示一次，需要立即复制到密码管理器或云函数环境变量；账户要有余额，否则调用会返回 402。模型选择上，问答优先用 deepseek-chat，它响应快、上下文 64K，适合短对话；deepseek-reasoner 适合数学推理，但思考过程长，容易触碰 5 秒被动回复限制。服务器侧可以选择腾讯云 SCF、云开发云函数或 Cloudflare Workers，核心要求只有一个：提供公网 HTTPS 地址，能被服务器访问。云函数 Node.js 18 运行环境即可，内存 256MB、超时 20 秒，足够单次问答。 配置前还要确定消息加密。测试号和多数轻量接入都选明文模式，省去 AES 解密；Token 自己设定一串 32 位随机字符，不要用 123456。若使用云开发，需要先开通环境并部署云函数，再在云开发控制台找到 HTTP 访问服务或云接入，把函数映射成 URL。此时手里应有三样东西：公众号侧的 Token 与 appID，DeepSeek 侧的 API Key，以及一个可被公网访问的 Webhook 地址。它们分别解决身份校验、模型调用和消息投递，缺一不可。
2. 公众平台服务器配置与消息验证
进入测试号或服务号的开发配置页，找到服务器配置。URL 填云函数映射出的 HTTPS 地址，Token 填刚才设定的随机串，EncodingAESKey 可随机生成，消息加解密先选明文模式。点击提交时，并不会立刻发用户消息，而是先发一个 GET 请求，参数包括 signature、timestamp、nonce 和 echostr。服务器端要做的是把 Token、timestamp、nonce 三个字符串按字典序排序，拼接成一个字符串，再做 SHA1 计算，结果与 signature 比较。一致就原样返回 echostr，不一致返回空或错误。很多“Token 验证失败”并非密钥错，而是云函数没有读取 query 参数，或把 echostr 包进了 JSON。 验证通过后，用户在里发送的每条文本都会以 POST XML 到达同一个 URL。典型 XML 包含 ToUserName、FromUserName、CreateTime、MsgType、Content 和 MsgId。服务器需要解析 Content，把它作为用户提问；FromUserName 是用户 openid，可用于限流和识别会话；MsgId 用于去重，因为在 5 秒内没收到响应会重试。被动回复必须是一个 XML 字符串，根节点为 xml，内部包含 ToUserName 和 FromUserName 对调、CreateTime、MsgType 为 text、Content 为模型答案。响应头应设为 Content-Type: application/xml; charset=utf-8，避免把中文识别成乱码。 这里有一个关键限制：公众号被动回复要求在 5 秒左右完成，而 DeepSeek 生成 500 字答案可能需要 3 到 10 秒。超简单做法是压缩 max_tokens 到 500 以内，并在提示词中要求“直接回答、少铺垫”，让响应落在安全窗口。若仍超时，可以先用被动回复返回“正在整理答案，请稍候”，同时把用户 openid 和问题写入数据库，再由另一个云函数用客服消息接口异步推送。客服消息需要 access_token，并且用户 48 小时内有过交互，适合认证服务号；测试号调试阶段则优先保证被动回复链路跑通。
3. 云函数对接 DeepSeek API 的关键实现
云函数入口先判断请求方法：GET 走签名校验，POST 走消息处理。解析 XML 可用 fast-xml-parser 或 xml2js，取出 event.body 中的 Content 字段。接着构造 DeepSeek 请求体，地址是 ，请求头包含 Authorization: Bearer 你的 API Key 和 Content-Type: application/json。请求体里 model 写 deepseek-chat，messages 数组至少包含 system 与 user 两条。system 提示词直接决定教学质感，例如“你是耐心 AI 指导老师，面向中小学生，用中文回答；先给结论，再给两步到三步做法；不直接代写作业，优先提示思路”。user 内容就是传来的 Content，可附带“请控制在 400 字内”。 调用成功后，从返回 JSON 的 choices[0].message.content 取答案。若使用 deepseek-reasoner，答案可能在 message.content，推理内容在 reasoning_content，但场景不建议展示推理链。拿到文本后要做 XML 安全处理：如果答案里出现 ]]>，需要拆成 ]]> 与 > 的组合，或者统一做实体转义；否则回复 XML 会被拒绝。然后拼出被动回复 XML，把 ToUserName 设为用户 openid，FromUserName 设为公众号原始 ID，CreateTime 用当前秒级时间戳，MsgType 为 text，Content 放模型答案并包在 CDATA 中。云函数返回这个字符串时不要额外包 JSON，否则会显示“该公众号暂时无法提供服务”。 工程上还要加三道保险。第一，把 API Key 放进云函数环境变量，不要硬编码在代码仓库；第二，用云数据库记录 MsgId，处理前先查重，避免重试导致同一条问题调用两次模型；第三，按 openid 做简单限流，例如每人每分钟最多 5 次、每天最多 200 次，防止公开测试号被刷。成本方面，deepseek-chat 按输入输出 token 计费，教学答疑通常单次几百 token，一个班级日常使用成本可控。错误处理要覆盖 401 密钥错误、402 余额不足、429 触发限流和请求超时；遇到超时先返回简短提示，并把问题写入待处理队列，比直接报错更利于课堂体验。
4. 教学场景调优与常见故障排查
跑通链路后，真正决定可用性的是教学调优。是短阅读场景，答案超过 600 字会明显增加阅读负担，因此提示词里应要求分点但少用表格、代码块和复杂公式，数学题用文字步骤表达，英语作文批改按内容、结构、语法、词汇四个维度给分。可以为不同关键词设计路由：用户发“备课”时，让 DeepSeek 输出教学目标、重难点、课堂活动和作业建议；发“出题”时，要求生成 5 道选择加 2 道简答并附答案；发“答疑”时，要求先判断学生卡在哪一步，再给提示而不是直接给最终答案。测试号没有自定义菜单，可直接用关键词触发；认证服务号可在自定义菜单里配置对应指令，降低学生输入成本。 常见故障集中在四处。服务器配置提交失败，先确认 URL 是 HTTPS、公网可访问、返回 echostr 为纯文本，Token 与公众号后台完全一致。用户发消息无回复，检查云函数日志里是否收到 POST XML、Content 是否被正确解析、返回内容是否以 xml 开头，以及是否在 5 秒内返回；若日志显示重复调用，按 MsgId 去重。回复中文乱码，通常是响应头缺少 charset=utf-8 或 CDATA 未闭合。API 报错则看状态码：401 多为 Key 错误或 Bearer 后多了空格，402 需要充值，429 要降低并发，超时则缩短 max_tokens 或改用 deepseek-chat。把每次请求的 openid、MsgId、耗时和 token 用量写入日志，排查效率会高很多。 教学场景还要守住隐私边界。提示词和界面应明确告知学生，问题会发送到 DeepSeek API 处理，不要输入身份证号、家庭住址、成绩表等敏感信息；日志中只保留 openid 的哈希值和问题摘要，答案正文不必长期存储。对未成年学生，建议由教师统一管理测试号或服务号，限制公开传播二维码，并设置每日调用上限。若学校有本地化要求，可以把 DeepSeek 模型换成私有部署版本，只保留当前 Webhook 与 XML 转换逻辑。这样既能保留的触达优势，也能把数据风险控制在可接受范围内。
