飞书 OpenAPI 技术支持终面复盘：那 30 分钟我到底在讲什么

背景

这篇接上一篇：《飞书开放平台 API 实战：技术支持岗笔试全记录》。

上一篇更像操作记录。我按题目给出的 app_id 和 app_secret 换 tenant_access_token，再把多维表格、群组、日历、素材上传和机器人信息串起来。如果只想看具体 API 怎么调，可以先看那篇。

终面不是这样。

终面大约 30 分钟，由技术团队面试。它没有让我现场再写一遍 curl，也没有逐个追问某个接口的参数。面试官更关心的是：我做完那组 API 之后，脑子里有没有形成一套可迁移的判断方式。

所以这篇不会重复上一篇的命令和响应体。它更像一次事后拆解：我在终面里讲了什么，哪些技术事实真的支撑了表达，哪些地方其实还不够扎实。

我现在回头看，这场面试最关键的不是某个问题答得多漂亮，而是我有没有把上一篇笔试从“完成任务”讲成“排查问题的样本”。这也是我后来觉得值得单独写一篇复盘的原因。

那条链路比题库有用

初面结束后，我把笔试重新复盘了一遍。这个动作对终面帮助很大。

不是因为我把所有接口都背下来了，而是因为我手里多了一条完整链路：

应用凭证
  -> tenant_access_token
  -> 新增多维表格记录，得到 record_id
  -> 创建群组，得到 chat_id
  -> 回写群组字段
  -> 获取主日历并创建日程
  -> 上传截图，得到 file_token
  -> 回写附件字段
  -> 获取机器人信息，再写回表格

这条链路让我在面试里不至于只说抽象概念。聊到鉴权，我能回到 tenant_access_token；聊到权限，我能回到读写接口和 scope；聊到字段格式，我能回到多维表格的群组字段和附件字段。

我发现这种表达比“我会看文档、我会排查问题”更有说服力。前者是一句态度，后者是一个可以被追问的现场。面试官继续往下问时，我也不用临时找例子。

面试不是问答游戏

我原本准备了不少可能被问到的问题，比如 HTTP 200 是否等于成功、tenant_access_token 和 user_access_token 的区别、机器人为什么收不到消息、回调 URL 验证失败怎么排查。

这些准备当然有用，但如果直接把它们一条条倒出来，文章和面试都会变成题库。终面真正考验的是能不能把这些知识点放回一个具体场景里。

终面里更自然的状态是，面试官抛出一个场景，我先判断它落在哪条链路上。比如接口报错，不急着猜权限；先要知道接口路径、请求方法、完整响应体、code/msg/log_id、Header、token 类型、发生时间和是否必现。

这不是为了显得流程完整，而是因为用户的一句话经常不够可靠。技术支持如果顺着一句模糊描述往下猜，很容易把时间花在错误方向上。

“接口返回成功”可能只是 HTTP 200，业务码并不是 0。“我已经配了权限”可能只配了应用 scope，没有资源授权。“我已经填了 app_id 和 app_secret”也不代表他真的拿到了 access token，并且放进了正确的 Header。

技术支持的难点不在于猜得快，而在于不要被一句模糊描述带偏。

权限这块我讲得还不够扎实

复盘时我最想单独记下来的，是权限。

飞书 OpenAPI 的权限不是一个开关。tenant_access_token 表示应用在租户下的身份，user_access_token 表示具体用户授权后的身份。接口支持哪种 token、应用有没有对应 scope、管理员有没有审批、应用版本有没有发布、目标资源有没有授权，这些都可能成为断点。

我当时能讲出这个层次，但讲得还不够系统。

笔试里有一个细节让我印象很深：读写接口可能依赖不同的权限。某个读接口权限不足，不等于同一资源上的所有操作都失败。反过来，一个写接口成功，也不能推出读接口一定可用。

这个点其实很适合技术支持岗位。因为真实工单里，用户往往只说“权限有问题”，但支持同学必须把“权限”拆成身份、scope、审批、发布、资源授权和接口动作。

我如果再面一次，会把这部分讲得更慢一点，不急着给结论。权限问题看起来像一个错误码，实际上背后经常是几层配置和几种身份叠在一起。

字段类型是最真实的坑

这次笔试里，我最想保留的技术细节不是 token，而是多维表格字段类型。

这一节不展开完整请求，具体请求上一篇已经写过。这里单独拿出来，是因为它最能说明“会调通接口”和“理解接口背后的业务字段”不是一回事。

多维表格不是所有字段都传字符串。文本字段是字符串，数字字段是数字，日期字段是 13 位毫秒级时间戳。群组字段不是群名文本，而是 [{id: chat_id}]。附件字段也不能直接塞图片 URL，要先上传素材拿到 file_token，再写 [{file_token}]。

这些细节听起来琐碎，但它们很像真实工单。

很多问题不是“接口完全失败”，而是“返回成功了，但页面显示不对”。这时候只看 HTTP 状态码没有意义，要回到字段 schema，看传进去的值是不是业务组件能识别的格式。

时间戳也是同类问题。多维表格日期字段用毫秒级时间戳，日历 API 的 start_time/end_time 用秒级时间戳，而且 timestamp 字段是字符串。字段名都叫时间，但格式并不一样。

这类坑让我意识到，API 支持不是只会说“检查参数”。真正的检查参数，是能说清楚哪个参数、哪种类型、进入哪个业务字段后会怎样解释。

机器人、回调和限流都要拆链路

机器人问题也很容易被讲成背过的检查项。

我当时提醒自己不要只说“检查权限”。机器人能发消息，不代表能收到消息；发送消息成功，也不代表发到了正确的人或群。主动调用和事件接收是两条链路。

比如发消息，要看 receive_id_type 和实际 ID 是否匹配。chat_id、open_id、user_id 混用时，接口层可能能告诉你错误，也可能只是让结果偏离预期。

回调则更像网络和业务处理的交界处。URL 是否公网可访问、HTTPS 证书是否正常、DNS 是否解析、防火墙是否拦截，是网络层；challenge 是否正确返回、服务端日志有没有请求，是应用层。

我在面试里能把这两层分开讲，这一点应该是加分的。它至少说明我不是把“回调失败”当成一个黑盒错误。

限流也是同一类问题。它不是“平台偶尔抽风”，而是调用方式已经碰到了平台保护机制。支持时要看 QPS、并发、重试策略、是否在循环里重复拿 token，以及能不能缓存用户、群组或日历这类相对稳定的信息。

还有一种很具体的错误是 IP 白名单。比如请求从云服务器、代理或 NAT 出去时，用户以为自己填的是机器 IP，实际平台看到的是公网出口 IP。这个时候继续查 token 没意义，方向已经错了。

这一组问题放在一起看，其实都不是单个 API 参数问题，而是“请求从哪里来、以什么身份来、平台如何处理、结果又回到哪里去”的链路问题。

AI 话题差点变空

初面后有人提醒我，终面可以多聊 AI。我也准备了 RAG 工单助手的说法，所以这部分是我提前想过的。

但复盘下来，这一块最危险。因为只要稍微失控，就会变成“AI 可以自动分类、自动检索、自动回答、自动转人工”这种空话。

我比较认可的说法是：AI 可以帮技术支持做信息抽取和知识检索，但不能替代证据链。没有 log_id、错误码、接口路径和上下文，AI 说得再顺也只是猜。

一个 API 工单助手可以抽取接口路径、错误码、log_id、token 类型、应用类型和请求参数；也可以基于官方文档、错误码、SDK 示例、历史工单和 SOP 做 RAG 检索。

但它不应该在没有证据时编造字段，也不应该处理敏感密钥。遇到低置信度、生产故障、疑似平台 bug、权限审批或客户业务影响时，还是要转人工。

这部分我面试时讲得比较克制。现在看，这是对的。我不想把这篇复盘写成一个没有实现过的 AI 工单系统设计。技术支持岗位里的 AI 不是主角，排障链路才是。

安全意识不能只放在嘴上

还有一个我觉得必须写进复盘的点：敏感信息。

用户把 app_secret 或 access token 发进工单时，不能为了排查方便继续复制、转发、贴进 AI 工具。它应该被当作已经泄露处理。

后续排查真正需要的是脱敏请求体、错误码、log_id、接口路径、调用时间和必要的应用配置状态。密钥本身不应该成为流转材料。

这个点不复杂，但很能区分“会调接口”和“能做技术支持”。技术支持不是只对接口负责，也对用户交给你的信息负责。

我现在怎么看这场终面

这场终面让我确认了一件事：上一篇笔试文章的价值，不是它记录了多少 API 调用，而是它给我提供了一个可以反复拆解的技术场景。

我做得比较好的地方，是没有把面试完全变成被动问答。我能把问题拉回一条自己做过的链路，说明每一步的输入、输出和可能断点。至少在这 30 分钟里，我不是只拿概念应付概念。

做得不够好的地方也很清楚。权限体系还需要继续补，尤其是 OAuth、事件订阅、回调验签、长连接、scope 和资源授权之间的关系。错误码也还没有整理成自己的体系。

如果只是为了面试，讲到这里也许够了。但如果真要做 API 技术支持，这些还不够。

我需要继续把“我知道要查什么”变成“我能更快判断该查哪里”。这两者之间，还有不少真实工单和真实错误要补。

这篇复盘先写到这里。它对我更像一个快照：记录一次面试后，我当时对 API 技术支持这件事的理解到了哪里。