如何让 Codex 生成面试官评价模板

为什么需要让 Codex 生成面试官评价模板？

很多团队的面试问题并不在于没有面试，而在于面试结束后没有留下可用的评价资料。一个候选人表现好不好，最后往往变成几句模糊印象：感觉不错、沟通一般、经验还行、可能不太匹配。这样的评价短期看能推进招聘，长期看几乎没有复盘价值。

真正有用的面试官评价模板，应该把面试过程里的观察、证据、评分、风险和结论拆开。它不能只让面试官写感受，而要逼着面试官回答：这个判断来自候选人的哪段回答？和岗位要求有什么关系？是硬性不匹配，还是可以入职后培养？

这类工作很适合交给 Codex 做第一版结构整理。Codex 的价值不是替面试官决定候选人是否录用，而是根据岗位要求和面试流程，生成一套更规范、更可复用、更方便协作的评价模板。OpenAI 官方对 Codex 的定位是面向真实工程任务的 coding agent，可用于完成端到端任务、理解代码库、生成文档和处理结构化工作流。对于招聘团队来说，面试评价模板本质上也是一种结构化协作文档。

面试官评价模板最常见的问题

如果没有统一模板，面试反馈通常会出现四类问题。第一，评价维度不稳定。A 面试官重点看专业能力，B 面试官重点看沟通表达，C 面试官只凭整体感觉给结论，最后不同候选人之间没有可比性。

第二，评价缺少证据。很多面试记录只写“项目经验不错”，但没有写候选人具体做过什么、负责到什么程度、有没有遇到复杂问题、如何解决问题。这样的评价无法支持后续录用讨论。

第三，评分标准不清晰。比如同样是 4 分，有人认为是“超过岗位要求”，有人认为是“基本合格”。评分没有描述，就会变成装饰。

第四，风险点没有沉淀。候选人是否夸大经历、是否对关键职责理解不足、是否有明显协作风险，如果不记录清楚，后面复盘时很难判断当初的问题是面试没发现，还是发现了但没有处理。

什么样的面试评价模板才算可用？

可用的模板不是字段越多越好。字段太多，面试官不会认真填；字段太少，又无法留下有效判断。比较合理的做法是围绕岗位匹配度、关键能力、证据记录、风险判断和最终建议来组织。

让 Codex 生成模板前，需要准备哪些材料？

不要只对 Codex 说“帮我生成一个面试评价模板”。这种指令太空，最后只能得到一套通用表格，和你真实岗位没有多少关系。更好的做法是先准备四类输入：岗位要求、面试轮次、重点考察能力、输出格式。

• 岗位要求：包括 JD、岗位职责、必备能力、加分项、当前团队真正缺的人。

• 面试轮次：比如 HR 初筛、专业一面、负责人二面、文化匹配面。不同轮次不应该用同一套模板。

• 评价维度：比如专业能力、项目经验、问题拆解、沟通表达、协作方式、学习能力、稳定性。

• 输出格式：需要 Word 文档、Notion 表格、飞书多维表、Excel 字段，还是 ATS 系统字段。

准备的信息越具体，Codex 生成的评价模板越接近真实招聘场景。尤其是设计师、前端开发、产品经理、运营这类岗位，不能只用统一模板，因为每类岗位的证据标准完全不同。

可直接复制的 Codex 一键执行指令

下面这段指令可以直接复制给 Codex 使用。使用前，把方括号里的内容替换成你的岗位信息。

你现在是一名资深招聘流程顾问、面试官培训顾问和结构化文档设计师。请基于我提供的岗位信息，生成一套可直接使用的面试官评价模板。 【岗位信息】 岗位名称：[填写岗位名称，例如 UI/UX 设计师、前端开发、产品经理、运营经理] 岗位级别：[实习 / 初级 / 中级 / 高级 / 负责人] 团队阶段：[初创团队 / 成长期团队 / 成熟团队 / 外包项目团队] 主要职责：[粘贴岗位职责] 必备能力：[粘贴必备能力] 加分项：[粘贴加分项] 面试轮次：[HR 初筛 / 专业一面 / 负责人二面 / 终面，可自行修改] 面试方式：[线上 / 线下 / 电话 / 作品集评审 / 代码评审 / 案例分析] 【任务目标】 请生成一套面试官评价模板，帮助面试官在面试结束后快速、客观、可复盘地记录候选人表现。模板必须适合真实招聘流程，而不是只生成一张空表。 【输出内容】 1. 面试官评价表字段，包含字段名称、字段说明、填写要求和示例。 2. 候选人评分维度，至少包含岗位匹配度、专业能力、项目经验、问题拆解能力、沟通表达、协作意识、学习能力、风险点。 3. 每个评分维度提供 1 到 5 分的评分标准，说明什么情况是 1 分、3 分、5 分。 4. 生成一组面试官可直接使用的评价话术，分为“通过建议”“待定建议”“拒绝建议”“需要复试验证”。 5. 生成一份“证据记录要求”，要求面试官每个判断都要对应候选人的具体回答、项目案例或行为表现。 6. 生成一份“禁止写法清单”，避免出现“感觉不错”“不太合适”“沟通一般”等无法复盘的模糊评价。 7. 生成一份“面试后复盘清单”，方便招聘负责人比较不同候选人。 【重要约束】 1. 不要根据年龄、性别、婚育、地域、外貌、学历标签等与岗位无关的信息做评价。 2. 所有评价必须围绕岗位要求、工作能力、项目证据、沟通表现和协作表现。 3. 不要替公司直接做录用决定，只输出结构化评价和建议等级。 4. 模板要适合复制到 Word、飞书文档、Notion 或 Excel 中使用。 5. 输出要清晰、可执行，不要写成泛泛的 HR 理论。

这条指令为什么有效？

这条指令不是让 Codex 随便生成一张表，而是把“岗位信息、面试轮次、输出要求、评分标准、使用约束”全部交代清楚。这样 Codex 生成的结果才会接近真实业务，而不是通用模板。

• 先定义角色：让 Codex 以招聘流程顾问和文档设计师的视角工作，避免只生成普通表格。

• 再输入岗位信息：让模板围绕真实岗位，而不是套用所有岗位都一样的评价字段。

• 明确输出内容：要求 Codex 一次性给出字段、评分标准、评价话术、证据要求和复盘清单。

• 加入限制条件：避免模板引导面试官写与岗位无关的信息，也避免输出不可复盘的主观评价。

• 限定使用场景：让结果能被复制到 Word、飞书、Notion 或 Excel，而不是只停留在聊天窗口。

面试官评价模板建议包含哪些字段？

如果你想让 Codex 输出更稳定，可以提前告诉它你希望模板至少包含以下字段。这样生成的结果更容易接入招聘流程。

评分标准不要只写数字

很多团队的面试评分表看起来很专业，但问题在于只有数字，没有解释。1 分、3 分、5 分到底代表什么，如果不提前定义，分数就没有意义。让 Codex 生成模板时，一定要要求它给每个维度写清评分锚点。

这张表只是基础版本。更好的做法是让 Codex 针对不同岗位重新生成评分锚点。比如 UI/UX 设计师的 5 分，应该体现用户体验判断、视觉系统能力、项目推进能力和设计落地能力；前端开发的 5 分，则应该体现工程质量、性能意识、组件抽象、协作和测试能力。

不同岗位可以追加不同指令

面试官评价模板不能所有岗位都长一样。你可以在主指令后面追加岗位专项要求，让 Codex 生成更贴合实际的版本。

设计师岗位追加指令

请把这套面试官评价模板改成适合 UI/UX 设计师岗位的版本。重点增加作品集质量、需求理解、信息架构、交互逻辑、视觉完成度、设计系统意识、与产品和开发协作、设计落地能力、审美稳定性、业务理解能力等维度。每个维度都要提供 1 到 5 分的评分标准和可观察证据。

前端开发岗位追加指令

请把这套面试官评价模板改成适合前端开发岗位的版本。重点增加代码质量、组件抽象、状态管理、性能优化、工程化、测试意识、浏览器兼容性、接口协作、问题排查能力和长期维护意识等维度。每个维度都要提供具体证据标准。

产品经理岗位追加指令

请把这套面试官评价模板改成适合产品经理岗位的版本。重点增加用户洞察、需求拆解、业务理解、数据意识、优先级判断、跨团队沟通、项目推进、竞品分析、文档表达和结果复盘能力等维度。不要只评价表达能力，要强调可验证的项目证据。

如何让 Codex 生成“可复盘”的面试评价话术？

面试评价里最应该避免的是空泛话术。比如“候选人沟通一般”，这句话没有任何复盘价值。更好的写法应该是：候选人在讲解项目 A 时能说明目标和结果，但对自己负责的具体环节描述较模糊，需要二面重点验证其真实参与深度。

你可以让 Codex 专门生成一组评价话术，把模糊评价改成带证据的表达。

请基于上面的面试官评价模板，生成一份“面试评价话术库”。要求： 1. 把常见模糊评价改写成可复盘评价。 2. 每句话都必须包含观察点、证据来源和后续建议。 3. 分为通过、待定、需要复试验证、拒绝四类。 4. 不要出现“感觉”“还行”“一般”“不错”这类没有证据的词。 5. 评价要专业、克制、适合写入招聘系统。

如何让 Codex 检查现有面试评价是否太主观？

如果团队已经有大量面试反馈，可以让 Codex 反向审查这些反馈。它可以帮助你发现哪些评价没有证据、哪些评价不对应岗位要求、哪些评价只是个人偏好。

请审查下面这些面试官评价，判断它们是否存在主观、模糊、缺少证据、与岗位无关、无法复盘的问题。 【输入内容】 [粘贴面试官评价文本] 【请输出】 1. 每条评价的问题类型。 2. 为什么这条评价不够可复盘。 3. 应该补充哪些证据。 4. 改写成更专业、更客观的版本。 5. 标记是否存在与岗位无关的信息或潜在偏见风险。 注意：不要替面试官做录用判断，只做评价质量审查和改写。

如何把模板变成 Excel 或飞书多维表字段？

很多团队不是在 Word 里管理招聘，而是在飞书、Notion、Excel 或 ATS 系统里管理候选人。这个时候，不要只让 Codex 生成文章式模板，而要让它输出字段结构。

请把上面的面试官评价模板转换成适合 Excel / 飞书多维表 / Notion 数据库的字段结构。 请输出以下内容： 1. 字段名称。 2. 字段类型，例如文本、单选、多选、评分、日期、人员、长文本。 3. 是否必填。 4. 填写说明。 5. 示例内容。 6. 是否适合用于候选人横向对比。 请优先保证字段可落地，不要生成过多字段。

让 Codex 生成面试官评价模板时，常见错误写法

很多人用 Codex 生成模板时效果不好，不是因为 Codex 不会写表格，而是指令没有告诉它真实使用场景。以下几种写法都容易得到低质量结果。

• 错误写法一：帮我生成一个面试评价表。问题是没有岗位、轮次、评价维度和输出格式。

• 错误写法二：帮我判断这个候选人能不能录用。问题是把招聘决策直接交给 AI，不适合团队流程。

• 错误写法三：生成一个通用 HR 面试模板。问题是通用模板无法判断专业岗位能力。

• 错误写法四：帮我给候选人打分。问题是没有评分锚点，也没有证据要求。

• 错误写法五：帮我写得正式一点。问题是只优化表达，没有改善评价结构。

正确做法是把 Codex 当成结构化模板生成工具，让它围绕岗位、证据、评分标准和复盘目标工作。

面试官评价模板的最低可用版本

如果你只想先做一个最轻量的版本，可以让 Codex 生成以下结构。这个版本适合初创团队、小团队、临时招聘或第一次建立面试流程。

最低可用版本的重点不是完整，而是能够让面试官从“凭感觉评价”变成“基于证据评价”。只要做到这一点，模板就已经有价值。

适合放进达灵感的模板化价值

这篇文章的核心，不是教用户写一张普通面试表，而是让用户理解：好的 Codex 指令应该把任务目标、输入材料、输出格式、判断标准和限制条件一次性说明。对于达灵感来说，这类文章可以沉淀成一套可复制的招聘场景任务模板。

用户真正需要的不是“AI 帮我写个表”，而是“我把岗位信息放进去，Codex 能生成一套可落地的面试评价流程”。这正是达灵感适合承接的长尾需求：把模糊任务变成可执行指令，把一次性经验变成可复用模板。

FAQ

1. Codex 可以直接判断候选人是否录用吗？

不建议。Codex 可以帮助整理评价模板、评分维度、证据要求和复盘清单，但最终录用决策应该由招聘团队基于岗位需求、面试证据和公司流程完成。

2. 没有岗位 JD，能不能让 Codex 生成模板？

可以，但效果会比较通用。最好至少提供岗位名称、主要职责、必备能力和面试轮次，否则生成的模板很难贴合真实招聘场景。

3. 面试评价模板应该越详细越好吗？

不是。太复杂的模板会降低填写率。建议先保留基础信息、岗位匹配度、核心能力评分、关键证据、主要风险和综合建议，再根据岗位逐步增加字段。

4. 如何避免面试官评价太主观？

要求每个判断都对应候选人的具体回答、项目案例或行为表现。可以让 Codex 增加“证据摘录”字段，并生成禁止写法清单。

5. 这套方法适合设计师面试吗？

适合。设计师岗位可以重点增加作品集质量、信息架构、交互逻辑、视觉完成度、设计系统意识、业务理解和设计落地能力等维度。

6. 能不能让 Codex 生成多轮面试的不同模板？

可以。HR 初筛、专业面试、负责人面试和终面关注点不同，应该分别生成模板，而不是所有轮次共用一张表。

7. 面试评价模板能不能转成 Excel 或 Notion？

可以。只要在指令里要求 Codex 输出字段名称、字段类型、是否必填、填写说明和示例内容，就可以很方便地迁移到 Excel、飞书多维表或 Notion 数据库。

8. 小团队有必要做面试官评价模板吗？

有必要。小团队每次招错人的成本更高，更需要把面试判断写清楚。模板不需要复杂，但至少要让评价有证据、有标准、能复盘。

总结

让 Codex 生成面试官评价模板，真正解决的不是“写表格”问题，而是招聘协作中的标准化问题。一个好的模板，可以让不同面试官围绕同一套标准记录候选人表现，让候选人之间更容易比较，也让后续复盘更有依据。

对达灵感来说，这类场景非常适合做成可复制任务模板。用户只需要替换岗位信息，就能让 Codex 生成适合自己团队的面试评价表、评分标准、评价话术和复盘清单。相比临时写提示词，模板化指令更稳定，也更容易长期复用。

参考来源

• OpenAI Codex 官方页面：Codex is built to drive real engineering work and complete tasks end to end. https://openai.com/codex/

• OpenAI Developers Codex Use Cases：Codex use cases include turning feedback into reviewable artifacts and understanding large codebases. https://developers.openai.com/codex/use-cases