一、哪些活可以交给AI
招聘场景里，AI 能做的和不能做的差别极大。分不清就容易出问题。
能做的：简历信息抽取、岗位要求对照、面试题初拟、流程提醒。
不能做的：最终录用决定、候选人评估结论、任何涉及敏感信息的判断。
原因不复杂：这些决定背后有法律责任，也有道德责任。责任不能外包给模型。
二、抽取环节怎么做才准
一、先定字段。
学历、年限、技能、项目类型、城市、期望薪资。字段先写死，再谈抽取。
二、给格式约束。
要求输出 JSON，缺失字段填 null，不要自己编。
三、要求引用原文。
每个字段后面附上简历里的原句。这是最有效的防幻觉手段，也是后面人工复核的入口。
四、先跑小样本。
十份简历人工校一遍，看字段命中率，再批量。
三、匹配环节的正确姿势
不要问"这人合适吗"。这种问题模型只能给你一个到处都对的答案。
要问：岗位要求里的每一条，简历里有没有对应证据？证据是什么？缺哪几条？
把它变成逐条对照表，人来做最后判断。
四、必须避开的三个坑
坑一：让模型排优先级。 排出来的顺序会系统性地偏向某些学校、某些公司。
坑二：用模型筛年龄、性别、婚育。 这些是红线，不要写进提示词。
坑三：把抽取出错当作候选人不符合。 简历格式千奇百怪，错多半在你的提示词。
五、效率提升在哪里
真实收益不在"筛得快"，而在"节省重复看简历的时间"。
十几份简历，人工看要一个下午；结构化之后就变成读表格，二十分钟能看完。省下的时间可以拿去好好聊候选人。
六、技术支持
做招聘工具最麻烦的其实是结构化简历的存储与检索：大量 PDF、各种格式、还要支持关键词与向量两种检索。
这类工程问题在 BackendWiki 里有比较系统的讲解，包括 MySQL 基础与 B+ 树索引、 Redis 缓存与常见坑、以及 RESTful 接口与 Swagger 文档的写法。如果你想自己搭一个系统而不想只是写提示词，这些是必补的。
七、一句提醒
工具能帮你看得更快，但不能帮你看得更公平。
公平这件事，只能靠流程设计。