达灵感
办公数据4 阅读

如何用 Codex 建立人才库标签体系

很多公司的人才库看起来有很多简历，但真正要用人的时候，还是靠 HR 或负责人翻聊天记录、翻邮箱、翻表格。候选人的信息散落在简历、面试反馈、招聘平台、飞书文档、Excel、Notion、ATS 系统里，最后只能凭印象判断“这个人好像适合”。

发布时间 2026/07/04

如何用 Codex 建立人才库标签体系

为什么人才库需要标签体系，而不只是简历文件夹？

很多公司的人才库看起来有很多简历，但真正要用人的时候，还是靠 HR 或负责人翻聊天记录、翻邮箱、翻表格。候选人的信息散落在简历、面试反馈、招聘平台、飞书文档、Excel、Notion、ATS 系统里，最后只能凭印象判断“这个人好像适合”。

这不是人才库，而是资料堆。资料越多，检索成本越高；候选人越多，越容易出现重复沟通、标签混乱、岗位匹配不准、好候选人被遗忘的问题。

人才库标签体系的价值，不是把每个人贴满标签，而是让团队能在需要某类人才时，快速回答几个问题：这个人适合什么岗位？核心能力是什么？是否有相关项目经验？当前沟通状态如何？哪些信息还需要核验？

Codex 可以参与这件事，但定位要准确：它不应该替你做最终招聘决策，也不应该根据敏感信息给人下判断。更合理的用法，是让 Codex 把散乱资料整理成结构化字段、标签字典、打标规则、数据校验脚本和可检索的人才库视图。

Codex 在人才库标签体系里能做什么？

Codex 本质上更适合处理“文件化、结构化、可执行”的任务。只要你把简历、候选人反馈、JD、岗位画像、历史面试结论整理成 Markdown、CSV、JSON、YAML 或项目文档，Codex 就能围绕这些资料建立一套可维护的人才标签系统。

  • 盘点现有候选人资料：找出字段缺失、格式不一致、重复候选人、无法检索的信息。

  • 建立标签分层：把岗位方向、技能能力、经验场景、状态阶段、优先级、待核验信息分开管理。

  • 生成标签字典：为每个标签写清楚定义、适用条件、反例、证据来源和维护规则。

  • 批量标注候选人：根据简历和面试反馈提取岗位相关标签，并标注证据片段。

  • 建立职位匹配视图：把岗位 JD 拆成标签需求，再从人才库中筛出可优先联系的人选。

  • 输出数据文件：生成 candidates.csv、tags.yaml、tag-rules.md、candidate-match-report.md 等可继续维护的文件。

  • 检查风险：识别敏感标签、主观标签、无法解释的标签和可能造成偏见的筛选条件。

先明确：人才库标签不是“AI 自动筛人”

人才库标签体系很容易走偏。最常见的问题，是把标签变成“录用概率”“稳定性”“性格好坏”“聪不聪明”这类主观判断。这样的标签看起来节省时间，实际会把招聘经验、个人偏见和不完整信息固化到系统里。

更稳妥的原则是：标签只描述与岗位相关、可解释、可核验的信息。例如“有 B 端 SaaS 后台项目经验”“熟悉 Figma 组件库”“参与过 Next.js 项目”“待核验英文沟通能力”。不要使用年龄、性别、婚育、民族、宗教、健康、政治观点、籍贯、外貌、家庭情况等与岗位无关或容易造成歧视的标签。

Codex 的输出也应该被当作辅助整理结果，而不是最终判断。对于招聘、晋升、淘汰、薪资等高影响决策，必须保留人工复核、证据来源和申诉/纠错机制。

人才库标签体系推荐分层

一套可用的人才库标签体系，至少应该把“候选人是谁”“适合什么岗位”“能力证据是什么”“目前处于什么状态”分开。不要把所有信息都塞进一个标签字段里，否则后期检索会越来越乱。

标签层级用途示例标签
基础信息标签帮助识别候选人来源和资料完整度，不参与能力判断。来源：内推、官网投递、招聘平台；资料状态：简历完整、作品集缺失、联系方式待核验
岗位方向标签判断候选人可被纳入哪个岗位池。UI 设计师、产品设计师、前端工程师、增长运营、内容运营、HRBP
能力标签描述候选人的可验证技能。Figma 组件库、设计系统、React、Next.js、数据分析、SEO 内容、B 端后台设计
经验场景标签描述候选人在哪些业务场景中做过事。SaaS Dashboard、企业官网、海外信贷、AI 工具、招聘系统、小程序、会员系统
证据标签标记该能力来自哪里，降低误判。来自简历、来自作品集、来自面试反馈、来自笔试、待二面核验
状态标签管理候选人当前沟通阶段。新入库、已初筛、已约面、已面试、已发 Offer、暂缓、不可联系
优先级标签辅助排序，但不能替代人工判断。A 级优先联系、B 级可观察、C 级备用、需补充资料
风险/待核验标签提示信息不完整或需要进一步确认。项目真实性待核验、薪资预期待确认、到岗时间待确认、能力证据不足

执行前需要准备哪些资料？

Codex 不能凭空建立稳定的人才库标签体系。你需要先把资料集中到一个项目目录里，哪怕只是几个 CSV 和 Markdown 文件。推荐目录如下。

talent-pool/

README.md

AGENTS.md

data/

candidates.csv

interviews.csv

resumes/

candidate-001.md

candidate-002.md

jobs/

ui-designer.md

frontend-engineer.md

content-operator.md

taxonomy/

tags.yaml

tag-rules.md

reports/

candidate-audit.md

match-report.md

最小可用版本只需要三类文件：候选人基础表、候选人简历或作品摘要、岗位 JD。后续再逐步补充面试反馈、作品集链接、沟通记录和招聘结果。

第一步：让 Codex 盘点现有人才库资料

不要一上来就让 Codex 生成标签。正确顺序是先让它审查现有资料质量，找出数据里到底有什么、缺什么、乱在哪里。

可复制的 Codex 一键执行指令：

你是一个招聘运营与数据整理助手。请先不要修改任何候选人数据。

目标：

对当前项目中的 talent-pool/ 目录做一次资料盘点，判断现有人才库是否适合建立标签体系。

请完成：

1. 阅读 data/candidates.csv、data/interviews.csv、data/resumes/ 和 jobs/ 目录。

2. 统计候选人数量、岗位方向数量、重复候选人疑似数量、缺失字段数量。

3. 找出字段命名不一致、标签混用、状态不清、简历信息无法检索的问题。

4. 不要根据年龄、性别、婚育、民族、宗教、健康、政治观点等信息生成任何判断。

5. 输出 reports/candidate-audit.md。

输出格式：

- 当前资料结构概览

- 主要问题清单

- 建议保留字段

- 建议新增字段

- 不应进入标签体系的信息

- 下一步标签体系设计建议

完成标准：

只生成审查报告，不修改原始数据文件。

第二步：让 Codex 生成标签字典，而不是随手打标签

标签体系最重要的文件不是候选人表，而是标签字典。没有标签字典，今天的“高级设计师”和明天的“资深 UI”可能指同一类人，也可能完全不同。

标签字典至少要包含：标签 ID、标签名称、所属层级、定义、使用条件、反例、证据来源、是否可用于检索、是否可用于排序、维护责任人。

可复制的 Codex 一键执行指令：

请基于 reports/candidate-audit.md 和 jobs/ 目录，为人才库建立第一版标签字典。

目标：

生成一个可维护、可解释、可检索的人才库标签体系。

约束：

1. 只创建与岗位匹配、能力判断、经验场景、候选人状态相关的标签。

2. 禁止创建敏感属性标签或容易导致歧视的标签。

3. 禁止创建“聪明”“靠谱”“稳定”“年轻”“形象好”这类主观标签。

4. 每个能力标签都必须写明证据来源，例如简历、作品集、面试反馈、笔试结果。

5. 标签数量先控制在 50 个以内，避免第一版过重。

请输出：

- taxonomy/tags.yaml

- taxonomy/tag-rules.md

完成标准：

每个标签都具备 id、name、group、definition、apply_when、do_not_apply_when、evidence_required、review_rule 字段。

第三步：用结构化规则描述每个标签

好的标签不能只写一个名字。比如“设计系统”这个标签，如果没有规则，有人可能看到候选人写过组件就打上，有人可能只有做过完整规范才打上。后期检索一定会失真。

推荐让 Codex 生成类似下面的标签结构。

- id: design_system

name: 设计系统

group: ability

definition: 候选人有设计系统、组件库、设计规范或跨页面 UI 一致性建设经验。

apply_when:

- 简历或作品集中明确出现设计系统、组件库、Design System、Variants、Tokens、规范落地等证据。

- 面试反馈中能说明其参与过组件抽象、规范制定或前端落地协作。

do_not_apply_when:

- 只是使用过 Figma，但没有组件体系建设经验。

- 只做过单页视觉设计，未参与复用规范。

evidence_required:

- resume

- portfolio

- interview_feedback

review_rule: 若证据只来自候选人口述，标记为 pending_verify。

这类结构化标签有三个好处：第一，后续可直接被系统读取；第二，方便团队统一理解；第三，候选人被打上某个标签时，能回到证据来源，而不是只看 AI 的一句判断。

第四步：让 Codex 批量给候选人补标签

当标签字典稳定后，才适合批量标注候选人。这里的关键不是“标得多”，而是每个标签都要有证据。没有证据的能力，只能进入“待核验”，不能直接进入核心标签。

可复制的 Codex 一键执行指令：

请根据 taxonomy/tags.yaml 和 taxonomy/tag-rules.md，对 data/candidates.csv 和 data/resumes/ 中的候选人进行第一轮标签补全。

目标：

为每个候选人生成岗位相关、可解释、带证据的人才库标签。

执行规则：

1. 每个候选人最多添加 8 个核心标签，避免标签泛滥。

2. 每个标签必须引用证据来源：resume、portfolio、interview_feedback、assessment 或 manual_note。

3. 如果证据不足，只能加入 pending_tags，不得加入 confirmed_tags。

4. 禁止根据敏感属性、非岗位信息或主观印象打标签。

5. 不要覆盖人工已有标签，新增标签请写入 suggested_tags 字段。

6. 对疑似重复候选人，只输出 merge_suggestions，不自动合并。

请输出：

- data/candidates_tagged.csv

- reports/tagging-summary.md

完成标准：

报告中说明新增标签数量、待核验标签数量、无法标注原因、需要人工复核的候选人列表。

第五步：建立职位与标签的匹配关系

人才库标签最终要服务招聘，不只是让表格变得好看。下一步要把岗位 JD 拆成标签需求，让招聘负责人能快速找到“这个岗位应该优先看哪些人”。

建议把每个职位拆成三类标签：必须具备、加分项、待面试核验。必须具备用于初步检索，加分项用于排序，待核验用于面试问题设计。

请阅读 jobs/ 目录下的岗位 JD，并基于 taxonomy/tags.yaml 生成岗位与标签的匹配规则。

目标：

为每个岗位建立 must_have、nice_to_have、verify_in_interview 三组标签。

要求：

1. must_have 只能包含岗位真正必要的能力或经验，不要把所有要求都放进去。

2. nice_to_have 用于候选人排序，但不能作为自动淘汰条件。

3. verify_in_interview 用于生成面试追问，不直接作为结论。

4. 每个岗位输出一段“筛选解释”，说明为什么选择这些标签。

请输出：

- taxonomy/job-tag-map.yaml

- reports/job-tag-map.md

完成标准：

每个岗位都能用标签解释检索逻辑，并能追溯到原始 JD。

第六步：生成可检索的人才库运营视图

标签体系建立后，应该马上生成几个真实可用的运营视图。否则标签只是文件，不会进入招聘流程。

  • 岗位候选池视图：每个岗位下有哪些候选人、核心匹配标签是什么、缺什么证据。

  • 优先联系视图：近期可联系、资料完整、匹配度高、未进入流程的人。

  • 待核验视图：某些关键能力证据不足，需要二次沟通或面试确认。

  • 沉睡人才视图：历史不错但长期未联系的人，适合定期激活。

  • 标签质量视图：哪些标签使用过多、哪些标签定义模糊、哪些标签长期无人使用。

  • 岗位供给缺口视图：某类岗位候选人不足，反向指导招聘渠道和 JD 优化。

可复制的 Codex 一键执行指令：

请基于 data/candidates_tagged.csv、taxonomy/tags.yaml 和 taxonomy/job-tag-map.yaml，生成一份人才库运营视图报告。

请输出 reports/talent-pool-views.md，包含：

1. 各岗位候选池列表

2. 每个岗位的优先联系候选人

3. 关键能力待核验候选人

4. 疑似重复候选人

5. 标签使用频率统计

6. 标签定义需要调整的地方

7. 下次维护建议

约束：

不要输出敏感属性，不要生成自动淘汰结论，不要使用“录用概率”这类不可解释评分。

AGENTS.md：把人才库标签规则写成项目约束

如果后续会反复让 Codex 维护人才库，就应该把规则写进 AGENTS.md。这样每次执行批量标注、职位匹配、报告生成时，Codex 都能先读取同一套边界。

# AGENTS.md

## 项目目标

本项目用于维护人才库标签体系，帮助团队整理候选人资料、生成标签字典、建立岗位匹配视图和招聘运营报告。

## 目录说明

- data/：候选人基础数据和面试反馈

- data/resumes/：候选人简历或作品摘要

- jobs/：岗位 JD 和岗位画像

- taxonomy/：标签字典、标签规则、岗位标签映射

- reports/：审查报告、标注报告、岗位匹配报告

## 工作规则

- 不要直接修改原始简历文件。

- 不要删除人工已有标签，新增建议写入 suggested_tags。

- 所有标签必须来自 taxonomy/tags.yaml。

- 每个候选人标签必须带证据来源。

- 证据不足时使用 pending_tags，不要写入 confirmed_tags。

- 疑似重复候选人只输出建议，不自动合并。

## 风险边界

- 禁止创建或使用年龄、性别、婚育、民族、宗教、健康、政治观点、外貌、家庭情况等敏感或非岗位相关标签。

- 禁止输出录用、淘汰、薪资、晋升等最终决策。

- 禁止用主观人格标签替代岗位证据。

- 所有候选人结论必须保留人工复核。

## 完成标准

- 修改后必须生成摘要报告。

- 新增标签必须说明定义、适用条件、反例和证据来源。

- 批量处理后必须列出需要人工复核的候选人。

人才库标签体系的验收标准

判断这套系统是否可用，不是看标签数量，而是看它能否支持真实招聘动作。可以按下面标准验收。

  • 每个标签都有清晰定义，不依赖个人理解。

  • 每个能力标签都有证据来源，不能只靠 AI 推断。

  • 岗位 JD 能映射到 must_have、nice_to_have、verify_in_interview 三类标签。

  • 候选人表中没有敏感属性标签和明显主观标签。

  • 候选人可以按岗位方向、能力、经验场景、状态快速检索。

  • 疑似重复候选人、信息缺失候选人、待核验候选人能单独列出。

  • 标签字典能被团队持续维护，而不是只生成一次就废弃。

  • Codex 每次批量处理都会输出变更报告，方便人工复核。

常见错误：这些做法会让标签体系越来越乱

  • 标签太多：第一版就建几百个标签，最后没人知道怎么用。

  • 标签太主观：例如“稳定”“聪明”“高级感强”“沟通好”，没有证据标准。

  • 岗位和能力混在一起：把“UI 设计师”和“Figma 组件库”放在同一层，后期无法筛选。

  • 没有证据来源：只保留标签，不保留来自简历、作品集还是面试反馈。

  • 让 AI 自动淘汰候选人：这是高风险用法，尤其不适合缺乏审计机制的小团队。

  • 忽略资料状态：候选人能力看起来匹配，但联系方式、到岗时间、薪资预期都没核验。

  • 长期不维护：业务变了、岗位变了、标签还停留在旧版本。

FAQ

1. Codex 能直接读取招聘平台里的候选人吗？

通常不能直接读取封闭招聘平台。更稳妥的做法，是把候选人数据导出成 CSV、Excel、Markdown、JSON 或 ATS 支持的结构化文件，再让 Codex 在项目目录里处理。

2. 人才库标签要不要做评分？

可以做“证据完整度”“岗位标签匹配度”“待核验项数量”这类可解释指标，但不建议做“录用概率”“人才价值分”这类黑箱评分。招聘决策属于高影响场景，评分必须可解释、可复核。

3. 候选人标签越多越好吗？

不是。一个候选人 5 到 8 个核心标签通常比 30 个泛标签更有用。标签过多会降低检索准确度，也会增加维护成本。

4. 如何处理简历里不确定的信息？

不要直接写入 confirmed_tags。可以写入 pending_tags，并标注“来自简历表述，待面试核验”或“来自作品集，待确认实际负责范围”。

5. 适合小团队吗？

适合，但小团队不要一开始做复杂 ATS。先用 candidates.csv、tags.yaml、job-tag-map.yaml 和几个 结构化报告跑通流程，再决定是否接入系统。

6. 达灵感这类文章为什么要写 Codex 指令？

因为用户搜索这类问题时，真正需要的不是概念解释，而是能复制到 Codex 里执行的任务说明。指令越清楚，Codex 越容易输出可检查、可维护的结果。

总结

用 Codex 建立人才库标签体系，不是让 AI 替 HR 判断谁好谁坏，而是把散乱的人才资料整理成一套可检索、可复核、可持续维护的数据结构。

正确流程应该是：先盘点资料，再建立标签分层，然后生成标签字典和规则，接着批量补标签，最后把岗位需求映射成可检索的人才库视图。

如果这套规则能写进 AGENTS.md，并配合 candidates.csv、tags.yaml、job-tag-map.yaml、reports/ 等文件长期维护，Codex 就不只是临时帮你整理简历，而是变成一个可重复执行的招聘运营助手。

参考资料

CodexHR办公数据人才管理人才库