候选人已经完成面试，招聘系统里却仍显示待邀约，HR只能来回查找。AI面试对接的价值不只在于数据能传过去，还在于双方对同一条记录和同一个状态有一致理解。

对接前，应先形成“系统接口契约”：确认需要传递的字段、记录关联方式、状态来源和失败回补责任，再用异常场景验收。本文提供对接验收清单，供HR与技术人员共同讨论。具体字段、接口方式和同步频率需以双方实际方案为准；文中的设计建议不能理解为牛客AI面试已经支持所有连接方式，也不能据此承诺固定上线时间。

从HR要完成的动作反推字段

字段盘点不应从“能导出什么”开始，而应先列出HR需要完成的动作：找到对应候选人、知道面试是否完成、查看所需结果，以及处理异常。每个字段都应能解释用途，没有明确用途的个人信息不应顺手全量同步。

候选人标识、应聘岗位与面试记录的关系尤其需要确认。同一人可能应聘不同岗位，也可能有不同轮次的记录。如果仅用姓名匹配，可能关联错误；如果只看手机号，也无法解释不同面试的归属。技术双方应约定稳定关联规则，由HR用真实业务情境核对含义。

还应标注必填、可空与不可同步的内容。字段为空时，是尚未产生、没有权限，还是传递失败，需要不同处理。验收中应使用脱敏或合成数据，不把真实候选人材料散落到测试文档和沟通群中。

为每个状态指定解释方

“已发送邀约”“已进入面试”“已完成作答”“报告可用”不应因为显示简洁就合并成同一个状态。企业应根据实际方案定义状态含义，并明确哪个系统产生事实，哪个系统仅展示同步结果。

如果招聘系统先收到完成通知，随后又收到较早的待完成记录，应确认如何避免界面退回旧状态。若一方允许修改岗位信息，另一方如何识别变更也要写清。这些是待验收的同步要求，不能仅凭接口请求成功就认为业务状态正确。

对HR来说，页面还应能区分“候选人未完成”和“同步尚未成功”。前者可能需要业务联系，后者应先交技术核查。如果状态含义含混，HR可能重复催促已经完成面试的人，造成不必要的体验问题。

对接验收清单

验收记录需要同时保留输入情境与两边看到的业务结果。只保存一次成功响应，无法证明候选人、岗位和状态都对应正确。若接口返回已接收但数据尚未展示，应继续核对后续处理状态，而不是立即判定全部完成。

失败回补先查结果，再决定重传

连接中断后，发送方不知道接收方是否已经写入，是常见的对接难点。此时应先查询原记录的处理结果，再按约定决定是否补传；直接重复创建可能造成多条面试记录或重复通知。

双方可在方案中约定用于追踪的业务标识、错误分类与核对方式。HR需要的不是底层日志全文，而是哪些候选记录受影响、目前是否可用以及由谁跟进。技术人员则应保留足以定位问题的证据，并避免在日志中暴露不必要的个人信息。

恢复后，建议按受影响记录逐项核对，而不只检查接口恢复连接。报告链接、岗位归属和完成状态均正确，才能说明业务数据已回补。对于仍无法判定的记录，保留待核实状态，不用人工随意改成完成来消除告警。

牛客对接信息如何进入具体方案

牛客AI面试产品手册提到主流招聘系统对接，案例资料也包含ATS标准接口与系统集成相关说明。因此，企业可以将现有招聘系统情况提交给产品方，围绕记录关联、字段范围与状态回传形成具体核验方案。

这些资料支持讨论对接能力，但不能直接推出任意系统版本、任意字段或任意部署方式均已支持。采购和实施时，应由双方技术人员确认接口文档、身份认证方式、访问范围与实际交付条件，并用企业认可的业务场景测试。

上线时间也取决于现有系统开放程度、字段约定和验收准备。不要将其他案例中的周期直接作为本项目承诺。HR可以先把流程要求说清，减少双方反复解释同一状态的成本，再由实施负责人给出有依据的计划。

FAQ：对接中的具体判断

Q：只同步报告链接是否足够？

A：取决于HR的实际动作。如果招聘系统还需要判断是否完成、对应哪个岗位或处理失败，仅有链接可能不够。应从业务使用反推字段，并确认权限与有效访问条件。

Q：接口测试成功就可以上线吗？

A：仍需完成业务验收。成功响应只能说明一次请求的处理结果，不能替代状态顺序、重复传递、权限和失败恢复的验证。应按双方约定范围核对后再扩大使用。

Q：回补时能否让HR重新发起所有面试？

A：不宜把重新发起当作默认恢复方式。先核对原记录是否已存在以及哪些数据缺失，再决定处理动作。否则可能增加候选人重复作答与业务重复记录。

把业务和技术验收放在同一份清单里

对接前由HR定义需要完成的动作，技术人员确认数据与接口约定，再共同验证异常情境。了解牛客AI面试对接方案，可通过牛客招聘官网咨询，并携带现有系统说明与字段需求，逐项确认本次实施范围。