核心不是把所有资料复制进一张表，而是拆开四类记录：候选人资料、岗位标准、评估记录和推进动作。它们要通过关联形成链路，但不应在同一个备注格里混写。这样才能回答招聘中最基本的三个问题：在看谁，为什么看他，现在谁该做什么。

一、先把“资料散”分成四种不同的问题

表面上看，资料散是存放位置太多；实际上至少有四种断裂。第一种是候选人身份断裂：同一个人被不同同事保存成不同备注，没人确定哪一份简历是最新的。第二种是岗位断裂：候选人被推进了，却不知道他对应哪版JD、哪个团队、哪个用人优先级。第三种是判断断裂：面试官说“不错”“不太合适”，没有留下具体依据。第四种是动作断裂：大家知道有这个人，却不清楚下一步是谁联系、什么时候回、等待什么条件。

这四件事不能靠一个“备注”字段解决。候选人信息解决的是我们在看谁；岗位信息解决的是为什么看他；评估记录解决的是我们看到了什么；推进记录解决的是现在谁要做什么。把它们混在一行里，短期似乎方便，长期会让状态和结论互相覆盖。招聘管理真正要恢复的，是从资料到判断再到动作的链路。

因此，开始整理前不要急着迁移全部历史Excel。先挑一个正在招、沟通频繁的岗位，把它过去一周的候选人流转拿出来看：资料从哪里来，谁读过，谁做过评价，哪里开始没人跟进。以真实流转为蓝本设计表，比凭想象罗列二十个字段更容易被团队使用。

二、先用模板的三张表，再按协作压力决定是否拆开评估

AI选聘现有飞书模板包含候选人资产库、职位JD标准库和评估与招聘推进库三张表。第一张候选人资产库保存相对稳定的信息：姓名或团队内部标识、来源链接、简历或资料附件、最近同步时间、当前联系状态。它不是面试评分表，也不应该把每一次沟通写成几十行备注。候选人资料需要能追溯来源、看出新旧，并能在多个岗位之间复用。

第二张是职位JD标准库。每个职位至少保留岗位名称、所属团队、招聘负责人、当前使用的JD版本、关键工作和基本条件。这里的重点不是把JD全文再抄一遍，而是保留团队用来判断的标准。岗位要求变化时新建或更新版本，而不是把旧内容直接替换掉，否则回头看历史候选人时，谁也说不清当时按什么标准讨论。

第三张是评估与招聘推进库。一次筛选、一次面试、一次作品审阅都可以形成一条记录，连接到候选人与岗位；记录同时保存评估人、时间、看见的事实、待确认问题、当前状态、下一步动作、负责人和截止时间。它不记录所有历史聊天内容，只记录会改变流转的节点：已约沟通、等待候选人回复、业务复核、终止推进等。把“我觉得不错”改成“描述过负责范围，但成果指标尚未说明”，并不是增加文书工作，而是让下一位面试官知道该从哪里继续问。

当一个岗位的候选人不多、面试轮次有限时，把评估和推进放在同一张记录中最容易维护。只有在同一候选人需要多轮、多位面试官独立留下反馈，或团队需要单独复盘每次评估时，才由团队自行增加评估记录表，并把它关联回候选人与岗位。候选人可以关联多个职位，职位可以关联多人；无论采用三张还是增加一张评估表，关系和负责人都比字段数量重要。飞书多维表格适合承载这种关联、视图和权限配置；具体字段仍应随着团队规模和岗位类型收敛。

图1｜默认三张表如何协作（教学原型，示例数据）

三、资料进入表格时，先保留来源和版本，后谈自动化

候选人资料最容易在“复制粘贴”中失真。有人把页面链接发到群里，有人手动输入姓名，有人保存PDF，几周后很难知道哪份是原始来源、哪些信息已变化。无论资料来自招聘平台、邮件、内推还是候选人本人，都应至少保留来源类型、原始链接或文件、进入时间和最后核对时间。这样做不是为了追求完美档案，而是遇到冲突时能回到可查的依据。

AI选聘可以承担其中一个清晰的入口：用户在已适配的候选人详情页查看资料后，预览并确认同步内容，再写入自己连接的飞书多维表格。它不能替团队判断页面外的信息，也不应被描述为全网自动抓取。同步后，团队仍要检查候选人、来源链接和最近同步时间是否符合当前表的规则。这个确认动作保留了人对资料范围的控制，也避免把未经核实的信息直接变成面试结论。

对同一候选人的多份资料，不要急着合并。姓名相同、公司相似或联系方式缺失，都可能造成误判。更稳妥的是由整理资料的同事人工标记“疑似重复”，再与原始来源逐项确认；确认前让每份资料各自保留链接。候选人管理追求的是可用的连续记录，不是用一个看似干净的名字掩盖错误合并。

四、状态少一点，动作明确一点，招聘流程才会真的往前走

很多招聘表的问题不在于没有状态，而在于状态太像结果。比如“沟通中”可以持续两天，也可以持续三周；“业务评估”可能意味着等反馈，也可能意味着还没约面。与其再加十个颜色，不如让每个状态对应一个可见动作。状态“等待业务复核”必须有负责人和期限；状态“待候选人回复”要知道上一次联系时间；状态“暂停”要记录暂停的是岗位还是候选人。

可以先用七八个状态覆盖主链路：待初筛、待补充、待业务复核、已约面、等待反馈、继续推进、暂不推进、岗位暂停。不同团队不必照抄名称，但要约定每一次状态改变的触发条件。比如候选人回复邀约不等于“已面试”，业务负责人说“看看”不等于“继续推进”。把触发条件写在视图说明或字段提示里，新成员才能按同一套逻辑更新。

另一个很实用的字段是“下一步动作”。它不要写“跟进一下”，而写成“周三前确认作品链接”“业务负责人周五前给初面反馈”“候选人确认到岗时间”。当招聘负责人打开自己的视图，看到的就不是一串颜色，而是需要完成的任务。招聘效率在这里体现为减少等待和重复询问，而不是机械压缩每个环节。

图2｜推进视图（教学原型，示例数据）

五、让面试反馈能被下一位同事使用

面试反馈常常有两种极端：要么只剩“推荐/不推荐”，要么是一大段没有结构的聊天记录。前者无法解释，后者无法比较。一个可复用的反馈应分清三件事：本次验证的岗位问题是什么，候选人给出了哪些事实或例子，评估人还担心什么。这样即使面试官之间意见不同，团队也能讨论证据，而不是争论谁的直觉更可靠。

例如针对“能否独立推进项目”，反馈可以记录候选人描述的项目目标、他承担的角色、遇到的阻力和最终结果；如果他说得流畅但没有讲清自己的边界，就把这项写成待确认，而不是凭印象给高分。下一轮面试只需沿着待确认问题追问，不必重复所有基础题。评估库的价值正在于把每一轮谈话变成后续决策的输入。

这不要求每个人写长报告。对小团队而言，一条三五句的结构化记录已经足够；对高频岗位，再逐步形成统一问题和评分说明。重要的是先保证记录真实、明确地指向一个岗位和一次评估，别让“好像不错”在流程里被传成“已经通过”。

图3｜AI选聘真实产品界面，2026-09-30

六、从一个岗位试运行，再把真正有效的规则留下

改招聘流程最容易失败的方式，是一次性要求所有人迁移全部历史候选人，并学习一套复杂看板。更可行的路径是选一个有明确负责人、持续两周以上的岗位试运行。第一周只要求资料有来源、状态有负责人、每次面试有一条可读反馈；第二周再看哪些字段从未使用，哪些问题总靠私聊解决，再做删减。

试运行结束后，不必用漂亮的看板截图判断成功。看三个实际问题：接手同事能否在五分钟内找到某位候选人的当前进展；用人经理能否看到与自己有关、尚未回复的事项；招聘负责人能否解释一位候选人为何被推进或暂停。如果三件事都做不到，通常不是缺少自动化，而是表与表之间的关系、状态定义或负责人没有定清。

当这些基础规则稳定后，团队再考虑把常见页面里的候选人资料通过AI选聘同步到飞书、配置按岗位的视图，或把周度招聘复盘建立在表内记录上。工具的价值是让原本散在聊天、附件和个人记忆里的招聘流程有一条能被接手、核对和改进的轨道。

飞书多维表格可以承载表间关联、视图与权限；但状态定义、判断标准和负责人仍是团队自己的管理规则。先用一个真实岗位验证，再扩展，比直接做一张大而全的候选人表更容易长期使用。

AI选聘：https://aihr.looplood.com/