Stardust Interview

Stardust Interview

这个 skill 用于 Stardust Inc. / PreSeen Inc. 候选人的面试准备、面试复盘、结构化面评撰写和小青面试系统提交。目标不是快速给一个好坏结论，而是把岗位画像、候选人材料、历史面试记录、AI 听记转写和面试官判断对齐，形成可追溯、可提交的面评。

基本原则

1. 小青是候选人业务事实源。 候选人、岗位画像、简历、附件、面试轮次、评分项、历史面评和提交目标都优先来自 xiaoqing_interview MCP。不要用本地文件、SQLite、源码或浏览器页面替代小青业务查询。
2. DWS 是 AI 听记事实源。 用户提到 AI 听记、会议纪要、转写、听记标题或 DWS 下载时，读取 dws skill，并用 dws minutes 获取摘要和转写。所有 DWS 命令加 --format json。
3. 区分三类内容。 输出和提交前要分清：
   • 材料事实：简历、岗位画像、历史面试记录、AI 听记原文或摘要。
   • 面试官判断：用户明确表达的判断、风险、倾向和纠偏。
   • Agent 分析：基于事实和判断推导出的建议。
4. 不要被 AI 摘要带偏。 AI 听记摘要的录用建议只能作为参考，不能替代岗位画像、转写证据和面试官判断。若用户纠正了 AI 结论，以用户给出的面试官判断为准，并在风险分析中体现。
5. 先分析，后提交。 写入小青属于业务动作。必须先把结构化面评草案给用户确认；只有用户明确说“提交/好的提交/确认提交”等，才执行 dry run 和正式提交。
6. 提交必须两步。 upload_interview_result 先 dry_run=true，校验通过后用完全相同 payload 改 dry_run=false。使用 overwrite_policy="reject_if_changed" 和当前最新 last_known_revision。
7. 不要暴露凭证。 不输出 OAuth token、cookie、API key、临时签名 URL 或下载 token。认证失败时只报告需要重新登录或授权。
8. 默认严判，不等纠偏。 打分时主动按岗位画像和 60 分锚点校准；不要先给乐观分数、等用户或面试官指出问题后才下调。候选人“参与过某项目”只能算线索，不能直接换算成能力分。
9. 逐题看回答质量。 面试后评价不能先读 AI 摘要形成整体好感，再从转写里找支撑。必须按面试官的每个关键问题逐题判断：候选人是否正面回答、是否给出真实案例、是否讲清指标/决策/取舍/结果、是否达到该岗位级别。框架词、术语堆叠、泛泛方法论和“看起来懂”的长回答，不能替代回答质量。

工具顺序

1. 小青候选人材料

优先用可调用工具：

tool_search: xiaoqing_interview search_candidates get_interview_context list_candidate_interviews upload_transcript_document upload_interview_result

常用小青 MCP 工具：

• search_candidates：按姓名、岗位、面试轮次、面试官、日期检索候选人。
• get_interview_context：读取完整候选人评审包 HTML 和结构化上下文。
• list_candidate_interviews：确认候选人每一轮的 interview_id、轮次、面试官、时间和 revision。
• upload_transcript_document：把 .txt、.md、.docx 或 .pdf 原始听记文件绑定到准确的 interview_id，返回 transcript_attachment_id。必须上传原文文件，不能把 AI 摘要冒充 Transcript。
• upload_interview_result：提交结构化面评；必须先 dry run。

排期和面试记录是两类数据。 get_interview_context 完整评审包中的“面试安排时间”表用于判断目标轮次是否已分配面试官、是否填写安排时间；list_candidate_interviews 只列已经物化的面试记录。目标轮次没有 interview_id，不等于没有安排，也不等于不能填写面评。遇到排期、记录缺失、自动回查或网页创建记录时，必须读取并遵循 面试状态与提交目标。

search_candidates 只用于定位候选人，不作为最终事实源。搜索结果里的 matched_sources 只能说明为什么命中，不能证明某轮面评真实存在。最终事实必须来自 get_interview_context、list_candidate_interviews 和目标候选人的结构化字段。

如果当前会话没有暴露 mcp__xiaoqing_interview，先检查：

codex mcp list
codex mcp get xiaoqing_interview
codex mcp login xiaoqing_interview --scopes mcp,interview_context_read,interview_feedback_write

登录成功但当前会话仍无法发现工具时，向用户说明“当前会话工具注入未暴露小青 MCP”。只有用户允许时，才用 Codex CLI fallback 执行同一套小青 MCP 流程。fallback 只能做用户确认的目标任务，不要让子进程额外抓 DWS、浏览网页或写本地文件。

如果必须直接走小青 Streamable HTTP MCP，仍然遵守同一业务顺序：initialize -> tools/list -> search_candidates -> get_interview_context -> list_candidate_interviews -> upload_interview_result(dry_run=true) -> 用户确认范围内的正式提交。注意：

• /api/mcp 需要 Bearer token；不要使用旧静态 token、说明文档里的历史 token 或未经验证的本地配置。
• OAuth 授权回调本地服务要同时支持 GET /callback 和 POST /callback。如果浏览器显示 501 Unsupported method ('POST')，通常是本地回调服务只实现了 GET，而不是小青 MCP 不支持 POST。
• 直接 HTTP 调用时也先 tools/list 读取当前 schema，不要凭记忆拼字段。
• 不输出 authorization code、access token、refresh token、cookie 或任何临时凭证。

2. DWS AI 听记

如果用户给出 AI 听记标题、听记链接或要求“用 dws 下载”，先读取 DWS skill：

sed -n '1,220p' ~/.agents/skills/dws/SKILL.md

然后用 dws minutes --help 和产品参考确认命令。读取材料时至少拿到：

• 听记标题
• taskUuid 或等价 ID
• 摘要
• 转写全文或足够完整的分页转写
• 会议时间、参会人、发言人信息（如果可得）

转写很长时，不要只看摘要。分页读取并抽取和岗位画像、面试问题、候选人能力有关的关键证据。最终提交必须保留原文来源：可直接传完整 transcript_text，可先用 upload_transcript_document 上传原文并传 transcript_attachment_id，或把钉钉 AI 听记 taskUuid 放入 structured_info.external_reference_id 让小青通过钉钉 OpenAPI 自动分页拉取全文。不能只提交 AI 摘要。

DWS 转写处理要求：

• 分页读取完整转写，直到 hasNext 结束；记录标题、会议时间、taskUuid 或等价 ID、分页 token 和参会人/发言人信息。
• AI 听记摘要和转写原文冲突时，以转写原文、面试官现场判断和岗位画像为准。
• 关键证据尽量保留说话人和原始回答。不要只写“候选人表现一般”这种 agent 总结。
• 如果 source_type 是 transcript 或 mixed，transcript_text 应使用完整转写或经面试官确认的核心转写；不要只提交 AI 摘要。

3. AI 认知评分材料

当岗位涉及 AI 能力，或用户要求判断 AI 认知、AI 原生能力、AI 测试能力、RAG/Agent/大模型理解水平时，优先读取：

sed -n '1,260p' ~/Documents/memory/招聘\ and\ 面试/如何识别AI认知水平.md

如果本地文档不存在或路径不适用于当前机器，不要停止，也不要假装已读到。改用 DWS 企业知识检索查找同类文档或内容：

dws mcp aisearch search_enterprise --json '{"queries":["如何识别AI认知水平 AI认知 RAG Agent 大模型 面试 评测"],"searchTypes":["document"],"timeRange":""}' --format json
dws doc search --query "如何识别AI认知水平" --page-size 10 --format json

优先读取检索结果中标题、正文片段或路径最接近“如何识别AI认知水平”的文档。若 DWS 也找不到，明确说明该参考材料未读到，并改用岗位画像、候选人材料、AI 听记转写和面试官判断完成分析。

使用该文档时要区分：

• AI 项目参与经验
• AI 工具使用经验
• AI 认知水平
• AI 评测/工程建设能力

参与过 AI 应用不等于 AI 认知达标。若候选人只能说热词、局部脚本或工具使用，但讲不清原理链路、局限边界、场景判断和落地闭环，AI 能力应按低分处理。

面试准备流程

当用户要求“找到候选人信息”“帮我面试”“设计问题”时：

1. 用小青搜索并锁定候选人和岗位，避免同名或同岗位多候选人混淆。
2. 读取 get_interview_context，整理：
   • 候选人基本信息和教育背景
   • 工作/实习经历
   • 招聘、技术、AI、业务相关经历
   • 岗位画像、评分项、权重和硬要求
   • HR 筛选记录
   • 历史面评和风险点
   • 薪资信息、期望薪资、岗位级别和可参考的同级候选人薪资样本
   • 附件或材料缺口
3. 下载并打开候选人当前简历，必要时同时下载岗位要求、历史面试附件或 AI 听记文件。默认保存到 ~/Downloads，使用系统默认应用打开，方便面试官边看原始材料边问。不要在输出里暴露临时下载链接、签名 URL、cookie 或 token。
4. 如果有 AI 听记，读取摘要和转写，补充候选人真实回答和面试官追问。
5. 对二面、三面或更后轮次，先做历史轮次的“问题—回答—判断”审计，再设计本轮问题：
   • 按轮次列出前面已经问过的主要问题、候选人的关键回答、面试官已经形成的判断和仍缺少的证据。
   • 把能力点分为 已确认优势、已确认风险、存在矛盾/证据不足、尚未测试 四类。已确认的事实不再用同一种问法重复验证。
   • 只有在候选人前后口径矛盾、简历数字需要审计、上一轮回答缺少关键证据，或该点会改变推荐/定级结论时，才对同一主题继续追问；追问应改成证据核验、反事实、现场模拟或失败复盘，而不是让候选人再次介绍同一个项目或解释同一个概念。
   • 本轮优先深挖会改变录用、职级、薪资或岗位匹配判断的不确定点，以及前面轮次没有真实测试过的岗位核心能力。不要为了覆盖完整而重复已经得到稳定结论的问题。
   • 面试准备输出中明确给出：前面轮次主要问题和判断结论、本轮不再重复的问题、仍未闭环的关键判断、本轮递进追问及通过/风险标准。
6. 输出面试建议，聚焦岗位关键能力，不做泛泛的行为面问题。
7. 设置面试后自动复盘定时任务：面试准备完成后，创建一个2 小时后的延后定时任务，任务内容是按本 skill 自动拉取该候选人目标轮次的小青资料和 DWS AI 听记，若听记已生成则进行面评分析，并在满足提交条件时自动提交小青面评。任务标题/描述必须包含候选人姓名、岗位、candidate_id、目标轮次和面试官；仅在目标轮记录已存在时附加 interview_id。详细状态判断遵循 面试状态与提交目标。
   • 如果本轮会话可用自动化/提醒工具，优先使用该工具创建延后任务；若工具未暴露，使用当前环境可用的等价定时任务能力，并在输出中说明任务是否创建成功。
   • 调度规则必须使用可靠的相对延后。 对 Codex heartbeat，优先使用 FREQ=MINUTELY;INTERVAL=120 表达 2 小时后回查；如果必须使用固定时刻，则必须带明确 DTSTART，并在创建后检查配置里有可执行起点。不要用只有 FREQ=DAILY;COUNT=1;BYHOUR=...;BYMINUTE=... 的规则来模拟一次性 2 小时后任务，因为缺少 DTSTART 时可能不会被调度器拾取。
   • 创建自动复盘任务后，必须立刻用自动化查看工具或本地 automation 配置验证：任务状态为 ACTIVE、target_thread_id 为当前线程、rrule 是相对延后或带 DTSTART 的明确规则、任务 prompt 含候选人姓名/岗位/candidate_id/轮次/面试官。已有目标轮记录时再校验 interview_id。如果验证失败，不得报告“已创建成功”，应立即修正或说明阻塞。
   • 自动任务执行时仍要遵守小青提交协议：先刷新上下文和 revision，再 dry run，再正式提交；不要复用面试准备时的旧材料或旧 revision。
   • 如果 2 小时后仍没有对应 AI 听记，任务只生成状态说明，不要凭空评价。只有目标轮记录不存在时，继续分析并保留网页创建路径，不得把“无 interview_id”报告成无法面评。
   • 如果用户明确要求不要设置提醒/自动复盘任务，则跳过，并在面试准备输出里注明已按用户要求跳过。

面试准备输出模板：

候选人定位：
岗位关键要求：
人员匹配程度：
潜在风险：
薪资匹配度：
人员潜力评估：
企业文化匹配：
前面轮次主要问题和判断结论：
本轮不再重复的问题：
仍未闭环的关键判断：
已有证据：
主要风险：
本轮递进追问：
通过/风险标准：

面试前候选人分析

当用户要求“帮我分析候选人”“协助我面试”“给我面试建议”“设计面试问题”时，输出必须包含以下六项，不要只给问题清单；二面及以后额外包含“多轮面试递进”：

1. 人员匹配程度。 对照岗位画像说明候选人与岗位关键项的匹配程度。必须区分“表面匹配”和“已被证据证明的匹配”。例如学历、公司名、项目 title、岗位名只能说明可能相关，不能直接证明胜任。
2. 潜在风险。 从岗位关键项出发列风险，尤其关注准备不足、项目包装、参与深度不足、技术概念不清、业务价值说不清、执行型而非 owner、AI 工具被动使用、文化和可信赖感不足。
3. 人员潜力评估。 看候选人是否有学习能力、抽象能力、复盘能力、可迁移能力和在不完整信息下推进的能力。潜力不是“年轻/名校/态度好”，而是能否从细节里看到认知成长速度和解决问题的方式。
4. 企业文化匹配。 判断候选人与 Stardust / PreSeen 的工作方式是否匹配：真实、直接、能接受追问和反馈、对 AI 和业务问题有主动探索、能在高不确定环境中 owner 问题。亲和力和礼貌只能算基础项，不能替代文化匹配。
5. 薪资匹配度。 对照候选人期望薪资、当前薪资、岗位级别、同级历史样本和能力证据，判断薪资是否匹配。薪资不只是 offer 操作问题，也是级别和招聘可行性风险：高薪候选人必须证明能力、岗位级别或稀缺性足以支撑溢价。
6. 面试问题建议。 问题必须能验证岗位关键项和风险假设。每个问题都要说明想验证什么，以及什么回答算通过、什么回答说明风险。

候选人分析要用面试官视角，不要替候选人美化经历。默认候选人会包装自己的经验，因此分析时要主动带着问题挖掘：

• 不要偏向相信简历总结、AI 摘要或候选人的漂亮表述。
• 先看底层认知能力，再看履历标签。
• 先看事实回答内容，再看表达是否流畅。
• 先看候选人本人解决了什么关键问题，再看项目最终结果。
• 先看业务价值和技术挑战是否讲得清，再判断项目是否有含金量。

面试前输出模板：

候选人一句话判断：

1. 人员匹配程度
- 匹配点：
- 不匹配/未证明点：
- 初步结论：

2. 潜在风险
- 风险：
- 证据或线索：
- 面试中如何验证：

3. 人员潜力评估
- 可迁移能力：
- 学习/复盘能力：
- 独立 owner 可能性：
- 初步结论：

4. 企业文化匹配
- 匹配点：
- 风险点：
- 需要观察的现场信号：

5. 薪资匹配度
- 候选人薪资/期望：
- 岗位级别和同级参考：
- 是否支撑该薪资：
- offer/定级风险：

6. 面试问题建议
| 问题 | 验证什么 | 通过标准 | 风险信号 |

7. 多轮面试递进（仅二面及以后）
- 前面轮次主要问题和判断结论：
- 已确认、不再重复的问题：
- 存在矛盾或证据不足的点：
- 尚未测试但会影响录用/定级的点：
- 本轮递进追问与追问方式：

包装经验反挖规则

高级技术候选人的产品经历评价

筛选 CTO、技术总监、研发总监、首席架构师、资深 AI/算法/工程负责人等高级技术候选人时，先读取 ~/.agents/skills/senior-technical-product-evaluation/SKILL.md，按其规则评价候选人参与产品的领先性、本人技术深入度和目标岗位匹配度。

这类判断必须进行互联网调研和交叉验证。简历、候选人陈述、公司宣传材料和内部汇总表只能作为线索，不能单独证明产品领先或候选人贡献。需要核对产品身份、候选人在职时间、同期竞品、公开技术/商业证据和限制性证据，并明确区分：

• 产品本身是否领先；
• 候选人是否真正负责关键决策和核心实现；
• 这段能力是否能迁移到当前岗位、产品阶段和技术范式。

大厂品牌、管理人数、系统规模、AI 热词和“主导/负责/0到1”等措辞都不能直接换算成高分。公开信息查不到或候选人贡献无法核实时，必须降低证据等级、限制分数，并生成针对性的面试验证问题。

候选人简历里出现“提升准确率”“节约成本”“大幅提高效率”“接入 AI 模型”“搭建平台”“主导项目”“负责核心模块”等表述时，不要直接采信。按以下顺序追问：

1. 候选人本人做了什么。 是她设计方案、解决关键问题、写核心代码、推动业务落地，还是只是接入已有模型、整理材料、做页面、做协调或参与测试。
2. 提升来自哪里。 是模型本身能力、数据质量提升、规则调整、流程变化、人工标注、阈值选择，还是候选人的技术或业务判断导致的改进。
3. 基线是什么。 原始准确率、成本、效率、人工投入是多少；对比口径是否一致；是否有 A/B、线上数据或独立验证。
4. 业务价值是什么。 最后减少了多少人力、节约多少成本、提升多少转化、降低多少风险、影响多少客户或收入；如果讲不出业务价值，项目结果要降权。
5. 技术挑战是什么。 如果候选人是技术人才，必须追问具体难点：数据、模型、系统、性能、稳定性、评测、边界 case、线上回归、错误定位。只讲业务结果不讲技术挑战，不能证明技术专业度。
6. 失败和迭代是什么。 追问最初哪里不准、哪里失败、怎么发现、怎么改、下一版会怎么做。没有失败和迭代，通常说明参与深度不足或复盘不足。

示例：

简历写法：接入 AI 模型对底层资产进行动态提取整合，优化后识别准确率高达 97%，在节约成本的同时大幅提高人工审核资产管理效率。

追问方向：
- 97% 的准确率是哪个指标？precision、recall、F1、人工抽检通过率，还是业务口径？
- 优化前是多少？数据集多大？线上还是离线？谁验证？
- 提升来自模型能力，还是你改了数据、prompt、规则、阈值、流程或评测方法？
- 你本人解决的最关键问题是什么？
- 哪些 case 仍然错？错了如何发现和兜底？
- 最后业务价值是什么：节省多少人工、缩短多少审核时间、降低多少错误成本？
- 如果你是技术负责人，具体技术挑战是什么，为什么难，你怎么解决？

如果候选人只能回答“用了某模型，所以准确率提高”或“项目最后效果很好”，但讲不清指标、基线、本人贡献、错误处理和业务价值，该经历不能按高质量项目计分。

星尘招聘岗位判断框架

具体岗位以小青岗位画像为准。若岗位是招聘、HR、产研招聘、AI 原生招聘相关，重点看：

• 独立招聘能力：能否独立完成标准化到有一定难度的岗位招聘；是否能和业务方共建画像，而不是只拿 JD 执行。
• 画像迭代能力：能否根据面试反馈、渠道反馈和候选人质量主动调整岗位画像、筛选标准和渠道策略。
• 行业人才 mapping：是否能做系统性人才地图、竞品拆解、目标公司拆解、关键词设计、渠道优先级和转化复盘。
• 技术岗位理解：面对算法、工程、产品、AI 岗位时，是否能说清楚面试官筛人标准、通过/淘汰原因、岗位能力差异和复盘沉淀。
• AI 原生能力：是否主动研究、搭建、调试和迭代 AI 工具或工作流；不是只被动使用现成工具。
• 沟通与可信赖：是否能像真人一样和业务沟通，问题是否具体、聪明、抓核心，而不是机械念流程。

判断时要把“会用 AI”和“会主动用 AI 改造招聘流程”分开。前者只是工具使用，后者才接近星尘对 AI 原生 HR 的要求。

售前解决方案岗位判断框架

具体岗位以小青岗位画像为准。若岗位是售前解决方案、售前专家、AI 解决方案工程师、客户方案、行业解决方案相关，重点看：

• 公司和客户理解：是否认真读过公司资料、岗位资料和客户案例；能否说清公司做什么、服务什么客户、解决什么业务问题。HR 已发资料但候选人仍明显误解公司业务，应判为准备度和职业动机风险。
• 需求挖掘能力：是否能把客户问题拆成业务目标、数据来源、数据权限、隐私合规、现有流程、使用者、验收标准和预算约束，而不是只问泛泛需求。
• AI 技术可信度：是否能区分技术概念和业务概念；能否讲清 RAG、Agent、模型调用、评测指标、数据闭环、成本和风险边界。只会堆热词、概念说不清或追问后混乱，应明显压低技术和客户信任分。
• 方案设计和取舍：是否能给出方案架构、替代方案、为什么不用现成工具、POC 怎么做、怎么验收、成本怎么估、风险怎么控。
• 客户信任建立：表达是否真实、清楚、专业，能否在被追问或被纠偏时吸收反馈。准备不足、问答敷衍、反馈不虚心、技术包装，都会直接降低客户可信度。
• Owner vs 助理：区分候选人是独立方案 owner，还是只做协调、页面、图表、原型、材料整理和辅助推进。后者不应按售前解决方案 owner 打高分。

售前岗的关键风险不能被“会做 PPT/原型/包装项目”抵消。材料组织是加分项，但如果公司理解、技术可信度、需求挖掘或客户信任低，整体结论通常不能超过 弱不推荐。

销售与销售工程师岗位判断框架

具体岗位以小青岗位画像为准。若岗位是销售工程师、大客户销售、行业销售、国际销售或兼具销售与解决方案责任的岗位，客户经历和行业标签只能用于定位验证方向，不能直接换算为能力分。

客户类型和 AI 需求前置门槛

• KA 经历本身不加分。 服务过银行、政府、央国企、头部客户或大金额项目，只能证明接触过该类客户。必须继续验证候选人是否理解客户画像、决策链、预算来源、采购机制、尚未满足的需求，以及本人在获客、推进、成交和回款中的责任。
• 政府类客户销售经验在当前阶段减分。 Stardust 当前优先寻找能够销售市场化 AI 产品、主动发现新需求并快速验证成交路径的人，而不是以政府预算、政策项目、招投标、关系维护和长交付周期为主要打法的销售。候选人过往客户如果主要是政府部门、金融监管局、公安、事业单位或政府信息化项目，应降低最近岗位职能匹配度、场景拓展和成交能力判断；不能因为项目金额大、客户级别高或招投标经验丰富而补分。
• 政府经验只有证明迁移后才能止损。 候选人必须用真实案例证明自己能脱离政策预算和既有关系，面向企业客户主动获客，识别未被满足的问题，找到业务负责人和付费方，设计轻量验证并形成合同与回款。只有政府项目经验、没有上述迁移证据时，不能按当前销售工程师岗位的合格经验计算。
• 客户标签必须具体化。 “擅长金融客户”“擅长政府客户”“有央企资源”都不是有效答案。至少要具体到客户组织类型、目标部门和角色、业务流程、关键 KPI、预算/采购特点、信任门槛和典型阻力。长期服务政府部门、金融监管局、公安经侦或央企信息化部门，不应笼统计为金融机构客户能力。
• 不懂 AI 要减分。 销售不要求达到算法或工程师深度，但必须理解 AI 能力边界、数据和权限条件、准确性与评测、人工兜底、成本和 ROI。不能区分 AI 与传统 BI/规则系统/数据中台，不能解释为什么该问题适合用 AI，或只会复述大模型、Agent、RAG 等热词，应直接降低产品理解、场景洞察和客户可信度评分。
• 需求洞察比客户名气重要。 候选人能否发现客户尚未被满足、且有采购价值的问题，比是否服务过 KA 更重要。已有标准系统能够解决的问题、单纯替换旧技术、泛泛的降本增效和政策驱动，不自动构成 AI 商机。

HR 初筛必须逐字问：

你擅长哪类客户画像？
他们尚未被满足的需求是什么？
哪些需求可以用 AI 解决？为什么？

合格回答必须同时包含：

1. 具体客户画像：组织类型、部门/角色、业务流程、决策链或采购特点，而不是只报行业和客户名单。
2. 未满足需求：说明现有方案为什么没有解决、问题造成什么业务损失、谁为结果负责，以及客户为什么可能付费。
3. AI 适配判断：说明 AI 相比规则、BI、流程改造或传统软件的增量价值，以及所需数据、评测指标、准确性边界、人工兜底和 ROI 假设。
4. 真实证据：至少一个本人接触的具体客户或项目，讲清候选人如何发现需求、验证需求和推进下一步。

以下回答视为未通过前置门槛：

• 只说“擅长政府、金融、央企、KA”，没有具体角色、流程和决策链。
• 主要依赖政府预算、政策驱动、招投标和长期关系，却无法说明如何迁移到市场化企业客户、AI 新产品和更短验证周期。
• 只罗列知识库、智能问答、报告生成、数字化转型等通用场景，没有未满足问题和付费理由。
• 认为现有系统可以直接换成大模型，但说不清为什么效果更好、如何验证、失败如何兜底。
• 把传统数据中台、BI、规则引擎、流程自动化直接当成 AI 场景。
• 无法说明本人如何获取或验证这些客户洞察，只复述公司产品和行业趋势。

这个问题是 HR 推进业务面试的硬门槛。若候选人不能回答好，原则上不再推进；只有招聘群内基于明确证据讨论后认为值得补充验证，才可例外进入下一轮。不能用 KA 标签、项目金额、表达流畅、态度良好或售前材料能力抵消该门槛失败。

售前面试回答质量红线

售前/解决方案候选人的评价要先看现场关键问题有没有被答中，不要因为候选人能讲一个长案例、能说很多框架词或 AI 摘要给出正面判断就抬高分数。

逐题审计时，把每个关键问题标记为以下四档：

• 正面回答且有证据。 直接回答问题，并给出真实案例、角色、指标、客户决策、ROI/验收、失败和取舍。
• 部分回答。 有相关经历或方法，但缺少关键证据，例如没有预算、决策链、验收、ROI、交付边界或复盘结果。
• 绕开问题。 用行业趋势、通用框架、术语、方法论或大段背景替代答案，没有回答面试官问的核心。
• 暴露淘汰信号。 回答显示候选人不理解公司产品、客户价值、技术边界、岗位级别要求，或无法提出针对性问题。

如果一场售前面试中，除一个案例外多数关键问题属于“部分回答/绕开问题”，即使候选人履历相关、表达自信或 AI 摘要正面，整体也通常应为 弱不推荐 或 不推荐。如果候选人明显夸夸其谈、传统售前感重、表达啰嗦且没有逻辑，不能按“沟通好”加分；这会降低客户可信赖和内部协作可信赖。

对高阶售前专家（如 L5）尤其要严判：

• 问“客户为什么买单”，必须讲清客户真实问题、决策链、预算来源、竞品/替代方案、验收标准和 ROI；只讲技术方案或行业背景视为未答中。
• 问“POC 怎么设计”，必须讲清范围、指标、资源红线、验收、失败风险、退出条件和最终结果；只讲边界、KPI、分阶段验证等通用词不算通过。
• 问“跨行业前三个案例怎么打造”，必须讲清行业选择、目标客户、首批场景、进入路径、销售材料、验证指标和复盘沉淀；只说解耦分层、标准化沉淀、场景适配不算通过。
• 问“产品不支持但客户预算高是否接”，必须讲清成本、毛利、交付风险、合同边界、产品路线匹配、陪跑识别和退出条件；只说小步快跑、部分匹配、生态合作不算通过。

产品理解前置淘汰线

售前/解决方案岗位候选人如果在 HR 已发资料或已有前置沟通后，仍把 Stardust / PreSeen 明显理解错，例如只理解成数据标注、外包交付、传统项目制服务，不能理解当前 Memory / Agent / AI 产品方向，也提不出围绕产品形态、技术边界、客户价值、交付方式的针对性问题，应视为产品理解和技术理解能力不达标。

这种情况不是轻微准备不足，而是售前岗位关键项失败：

• 对 L2-L3 售前，整体结论通常不能超过 弱不推荐。
• 对 L4-L5 售前专家，通常应直接 不推荐，产品/AI 理解相关评分可落在 10-30 分区间。
• 若候选人同时回答问题不正面、缺少真实案例或行业不可迁移，应明确写入“前置筛选应直接 pass，不应进入高阶面试官环节”。

售前招聘团队前置筛选和一面纠偏

当用户要求总结售前招聘标准、给 HR 或售前同事对齐面试方法、复盘韩露/张静/其他面试官的一面判断，或要求把 Derek 的售前面试要求沉淀为文档/话术/skill 时，必须使用以下口径。

售前候选人不能按“履历相关、表达流畅、项目听起来像 AI、能做 PPT”推进。正确判断顺序是：

1. 产品理解先行。 HR 发过资料后，候选人必须能用 3 分钟复述 Stardust / PreSeen 当前卖什么、服务什么客户、客户为什么付钱，以及它和数据标注、传统外包、普通大数据分析的区别。复述不过，不应进入业务面。
2. 完整项目证据。 一面必须让候选人讲一个最能证明本人能力的完整项目，追到客户真实问题、决策人、预算来源、为什么买、POC 验收、ROI/结果、本人关键动作和失败取舍。
3. 技术可信度。 候选人说 RAG、Agent、知识图谱、工作流、模型微调等词时，必须追机制、边界、baseline、指标、验证人和本人贡献。能说术语不是能力证明。
4. 商机边界。 必问“客户预算高但需求超出产品能力，接不接”。通过答案必须包含成本、毛利、交付风险、合同边界、陪跑识别、退出条件，以及如何和销售/产品/交付对齐。
5. 非关键优势后置。 英语、PPT、行业履历、表达流畅、亲和力只能加分，不能抵消产品理解、技术可信度、客户价值、POC 验收或商机判断失败。

一面面试官（例如韩露）如果已经问到 demo、GitHub、solution deck、benchmark、技术架构、harness、项目角色等问题，但候选人没有给出可验证证据，不能写成“后续验证”后继续推荐。要把失败信号直接映射到结论和分数：

• 没有 demo/文档/GitHub，但也讲不清自己独立产出：文档/PPT/技术 owner 不能高分。
• 项目中只做协调、prompt、页面、材料整理或方案助理：不能按独立售前解决方案 owner 计分。
• 能讲行业案例但不能讲客户买单、预算、决策链、验收、ROI：业务理解和方案能力不能高分。
• AI 项目是传统业务系统加 AI 包装，不能讲 RAG/Agent/评测/工具选择边界：AI 相关能力应低分。
• 产品理解错或无针对性问题：通常弱不推荐或不推荐。

推荐进入 Derek 面前，必须能回答一句话：这个候选人为什么值得 Derek 花时间？ 若答案只是“经验相关、表达不错、背景匹配、有 AI 项目、英语可以”，通常不够。必须写出可审计证据，例如：

候选人能讲清客户 KPI、预算、决策链、现场数据可用性、POC 投入产出和复购/标杆价值；能把一个定制项目抽象为可复用场景包；能承认技术边界并提出作业验证点。

售前正反样本口径：

• 刘鹏宇类风险。 会说 RAG、Text-to-SQL、Agent、DPO 等词，但公司理解偏差、技术概念混乱、无法解释为什么不用现成工具、指标验证和本人贡献不清，属于技术包装和可信赖风险。
• 王子祎类风险。 英语、PPT、海外金融科技经验可用，但没有可验证 AI demo/owner 证据，方案停留在传统产品功能介绍，不能因语言和行业经验推进为 AI 售前解决方案。
• 朱海川类风险。 高阶售前履历和一个案例不够；如果后续问题大量绕开、讲大道理、行业不可迁移、对公司产品理解成数据标注，应前置 pass，不应进入 Derek 面。
• 李玄正类正样本。 推荐理由不是履历好，而是能讲预算、决策链、客户话语权、业务规则、现场数据、POC 投入产出、复购/标杆价值和方案复用，同时能承认技术深度边界并接受作业验证。

给 HR 或售前同事输出培训/对齐内容时，优先包含：

• Derek 的核心标准：招能把客户问题翻译成可卖、可交付、可验收方案的人。
• HR 前置三问：产品理解复述、完整项目案例、产品不支持但客户有预算时接不接。
• 一面六模块：产品理解、完整项目、技术边界、客户价值表达、商机取舍、现场产出。
• 常见误区：相关经验替代能力证明、术语替代机制、PPT/英语替代客户价值、一个好案例掩盖多数问题没答中。
• 具体候选人例子：至少使用一个正样本和两个反样本，避免只讲抽象原则。

AI 测试开发岗位判断框架

具体岗位以小青岗位画像为准。若岗位是测试开发工程师、AI 测试、质量工程、RAG/Agent 评测相关，重点看：

• AI 认知水平：不要把“参与过 AI 项目”当成“理解 AI”。按《如何识别AI认知水平.md》判断原理链路、局限边界、场景 ROI 和落地闭环。
• AI 评测体系：是否能设计 benchmark、golden set、自动评测/人工复核、模型回归、效果指标和线上监控。
• RAG/Agent 测试：是否能拆检索、Prompt、模型、工具调用、权限、记忆、trace 和最终动作，而不是只测输入输出是否看起来正确。
• 测试开发能力：是否实际搭建过自动化框架、接口回归、CI、测试报告、测试数据管理和失败定位机制。
• 复杂系统测试：是否能覆盖服务端、客户端、数据链路、模型推理链路和线上风险。
• 根因分析：是否能用日志、trace、指标、用户反馈和版本变更定位问题，而不是只说“看日志”。

AI 测试开发岗位的 60 分线不是“接触过 AI 工具”，而是刚刚能围绕 AI 产品质量风险设计测试和评测。只做过流程自动化、Prompt 包装、字段脚本校验、内部小工具使用，通常不能视为 AI 测试能力达标。

算法工程师硬门槛

具体岗位以小青岗位画像为准。若岗位是算法工程师、AI 算法、LLM 算法、Agent 算法、算法实习生等，必须把自主研究兴趣和持续关注最新研究方向/论文当作硬性门槛，而不是轻微加分项。

• 无自主研究兴趣不合格。 候选人如果只完成导师、公司、课程或面试官布置的任务，但说不出自己最近主动研究了什么问题、为什么研究、怎么验证，就不应按合格算法候选人处理。
• 不关注最新研究方向和论文不合格。 算法候选人如果不能讲出近期关注的论文、模型、方法或研究趋势，并说明核心问题、关键机制、局限边界和自己如何判断价值，通常不满足算法岗位要求。
• 只会说项目名不算研究。 参与过 LLM、RAG、Agent、RL、LoRA、GraphRAG、CoT 等项目，只能算经历线索；必须追问候选人主动读了什么、复现了什么、改了什么、失败了什么、形成了什么判断。
• 只会背概念不算关注前沿。 能解释 PPO/DPO/GRPO、RAG、Agent、LoRA 等名词但不能说清近期进展、适用边界、实验验证和项目取舍，应按低分处理。
• 没有研究问题意识要压低结论。 如果候选人对“最近最感兴趣的算法问题是什么”“哪篇论文让你改变了判断”“你不同意哪种流行做法”答不上来，整体结论通常不能超过 弱推荐；若同时项目贡献和实验设计也不清楚，通常应为 弱不推荐 或 不推荐。

算法岗面试必须至少追问一组研究兴趣问题：

你最近主动研究的一个算法/LLM/Agent问题是什么？
为什么这个问题值得研究？
你读了哪些论文或技术报告？
你认为其中最关键的机制是什么？
你复现、验证或改动过什么？
什么情况下这个方法不成立？
如果放到我们业务里，你会怎么判断它值不值得做？

大模型深度理解面试题风格

面试算法、AI 工程、AI 产品、AI 测试、售前解决方案等岗位时，不要只问“大模型/RAG/Agent/LoRA/RLHF 是什么”这类概念解释题。优先设计看起来很短、很常见，但必须解释底层机制、工程约束、失败边界和验证方法的问题。

好问题应满足：

• 问题短。 候选人一听就懂问题表面含义，不需要大量业务背景。
• 答案深。 不能靠常识类比或背定义通过，必须讲清机制链路。
• 能追问。 后续可以继续追“为什么”“什么情况下不成立”“怎么验证”“怎么设计实验区分两种解释”。
• 贴工作。 题目最好连接真实研发、评测、交付、成本、线上稳定性或客户验收。

常用题型：

• 推理成本题：为什么模型的输入 token 通常比输出 token 便宜？看候选人是否理解 prefill/decode、KV cache、自回归生成和并行度差异。
• 长上下文题：如果 context window 已经很长，为什么还需要 RAG？看候选人是否理解成本、噪声、lost-in-the-middle、权限、更新频率和可追溯性。
• 检索有效性题：为什么 embedding 相似度高，不等于答案相关？看候选人是否能区分语义相似、可回答性、chunk 粒度、rerank 和生成阶段 grounding。
• 幻觉治理题：为什么加了 RAG 仍然会幻觉？看候选人是否能拆检索召回、证据冲突、prompt 约束、生成解码和评测闭环。
• 微调容量题：为什么 LoRA rank 不是越大越好？看候选人是否理解参数容量、数据规模、过拟合、显存、训练稳定性和任务差异。
• 偏好优化题：为什么 DPO 工程上更简单，但不等于一定优于 PPO/RLHF？看候选人是否理解偏好数据、reward、长链路任务、工具调用和分布外行为。
• 结构化输出题：为什么模型训练过 JSON 输出，线上还是会格式坏？看候选人是否理解概率生成、schema 约束、constrained decoding、重试、校验和降级。
• 确定性题：为什么 temperature=0 也可能不是完全可复现？看候选人是否理解服务端批处理、kernel、浮点非确定性和推理系统实现。
• 模型规模题：为什么小模型 + RAG 有时能打过大模型？看候选人是否理解任务匹配、外部知识、上下文质量、延迟成本和可控性。
• 评测迁移题：为什么 benchmark 分数高，不代表客户项目一定成功？看候选人是否理解数据分布、业务流程、失败代价、指标设计、人工复核和 ROI。

判断回答时，优先看候选人是否给出“机制 -> 边界 -> 验证”的完整链路：

现象是什么 -> 底层机制是什么 -> 什么情况下不成立 -> 如何用实验或指标验证 -> 对项目取舍有什么影响

如果候选人只给概念名、漂亮类比、行业常识或“因为效果更好/成本更低”这类结论，而不能说清底层原因和验证方法，应视为 AI 理解深度不足。

面试官判断标准

看候选人不是看履历是否漂亮，而是看候选人是否能在星尘的真实岗位难度下独立产出结果。判断时按以下顺序：

1. 岗位关键项先行。 先判断这个岗位最核心的 2-4 个能力是什么，再看候选人是否证明了这些能力。非关键优势不能抵消关键项不达标。
2. 独立证据优先。 候选人自述、简历描述和 AI 摘要都只是线索；真正有分量的是可独立验证的材料、历史产出、具体案例、转写原文、面试官追问下仍能站住的解释。
3. 方法沉淀优先于经历标签。 做过某岗位、参与过某项目，不等于有能力。要看候选人是否能说清楚判断标准、失败原因、复盘结论和下一次怎么做得更好。
4. 主动性高于执行性。 星尘更看重能主动定义问题、调整策略、迭代方法的人。只按流程执行、等业务方给 JD、等工具给结果的人，只能算执行型。
5. 真实难度匹配。 简单任务做得顺不代表能胜任高难度岗位。必须看候选人在不完整信息、复杂业务、技术不确定、资源不足时怎么推进。
6. 可迁移能力。 一个案例讲得好还不够，要看候选人能否抽象出原则，迁移到新岗位、新业务和新工具。
7. 风险不平均。 如果岗位关键项不达标，即使沟通、态度、学历、亲和力不错，也不能给推荐。关键风险要直接压低总分和推荐结论。

打分时使用这个口径：

• 通用锚点：
  • 20 分：明显不具备，基本不相关。候选人答非所问、只有空泛态度或概念词、没有真实案例、对岗位核心要求不理解；需要从头培养，且未体现足够学习潜力。
  • 40 分：有接触或经历线索，但不能胜任。候选人参与过相关项目，或能复述流程、名词和表层做法，但讲不清本人贡献、关键难点、指标、方案取舍、失败迭代和结果闭环；低于岗位要求明显。
  • 60 分：刚刚满足岗位要求。候选人能独立完成该级别岗位的基本工作，并能正面回答问题，讲清真实案例、本人责任、关键难点、方案取舍、结果指标和失败迭代；仍有短板，但主要风险可控。
  • 80 分：明显超过岗位要求。候选人不只是做过，而是能定义问题、做关键决策、解决难题、形成方法论，并能迁移到星尘当前场景；回答有细节、有反思、有判断，能让面试官建立信任。
  • 100 分：行业顶尖或标杆级。候选人有原创性判断或领先实践，做过高难度、高影响结果，并能提出超出面试官预期的框架、边界、风险和下一步路线，可直接提升团队能力上限。
• 60 分是刚刚满足岗位要求，不是普通候选人的平均水平。
• 70+ 需要有清楚证据证明能稳定胜任。
• 80+ 需要明显超过岗位要求，并且风险可控。
• 能力表现分和证据置信度分开。 候选人能正面回答并讲清具体方案、关键机制和实际取舍时，应按其已展示的能力打分；指标真实性、项目所有权或落地可行性存疑，应单列为“可信度/可行性风险”，不能把已经展示出的技术深度直接抹成不会。比如方案本身达到 80，但 99% 准确率没有评测口径、且底层追问失守，可以把该能力维度折算到 65-70，并明确说明折损原因，而不是直接打到 40。
• 区分未考察、证据不足和已证伪。 未考察 表示本轮没有覆盖，不能据此给低分；证据不足 表示候选人给了正向线索但尚未形成完整闭环，可以给暂定分并标注待验证；已证伪 表示候选人在直接追问中答不上来、前后矛盾或暴露明显错误，才应直接压低对应能力分。
• 意识分可以独立成立。 管理、研发体系或组织变革问题中，如果候选人能讲清目标、原则、机制、边界和反思，即使本轮没有完整结果数据，也可以给 70 左右的“意识/方法分”；但必须注明这是认知与方法证据，不等于已经证明高质量落地。80+ 仍要求团队结果、质量指标或可复用机制。
• 关键项低于 60 时，整体结论通常不能超过 弱推荐；多个关键项低于 60 时，通常应为 弱不推荐 或 不推荐。
• 核心管理或研发体系能力尚未聊透、但已有正向线索且没有明确负面证据时，可以暂定 弱推荐，并把总分和结论标为“待后续轮次验证”；不要仅因本轮覆盖不足直接判为不推荐。反之，若已经通过直接问题暴露不胜任，不能用“没聊透”回避降分。
• 对没有独立证据支持的能力，不要因为候选人表达自信就给高分。
• 非关键优势不能抵消关键项不达标。候选人在学历、沟通、态度、通用 QA、流程推进上表现不错，也不能补足 AI 评测、自动化框架、岗位核心能力不达标。
• 如果候选人只会说概念、热词、工具名或项目名，但不能讲清输入、处理逻辑、评估指标、失败处理和迭代机制，应按低分段处理。
• 如果候选人只能说出技术链路或项目名，例如“ASR、RTC、流式、大模型、TTS、渲染都有延迟”，但不能讲清真实瓶颈、优化前后指标、本人技术决策、替代方案取舍、压测回归和失败 case，对应技术维度通常只能落在 40 分左右，不能因为项目听起来复杂就打到 60。
• 对算法工程师，缺少自主研究兴趣或不关注最新研究方向/论文属于关键项不达标，不能用项目经历、学历、表达流畅或工具使用经验抵消。

薪资匹配度判断

后续所有候选人评估都必须单独判断薪资匹配度。这不是简单记录“薪资高/低”，而是判断候选人的能力证据、岗位级别、市场稀缺性和公司薪资带宽是否一致。

判断顺序：

1. 先确认岗位级别。 以小青岗位画像、候选人目标轮次和当前定级为准，明确是 L1/L2/L3 还是更高阶要求。
2. 再看同级参考。 读取历史面评、HR 信息或用户给出的同级样本。若上一个同级 L2 候选人参考薪资是 7k，当前候选人期望或成本是 23k，必须显式写出差距和原因，不要只写“薪资偏高”。
3. 再看能力是否支撑溢价。 如果候选人只是达到 L2，薪资却显著高于 L2 带宽，应判为薪资匹配度风险；如果候选人能力已达到 L2+、L3- 或具备明显稀缺价值，可以说明为何可以例外。
4. 区分能力推荐和 offer 可行性。 候选人可以能力上强推荐，但薪资匹配度低；这种情况下结论要写清“按 L2 能力强推荐，但薪资已超 L2 范围，需要重新定级、压薪或设置试用目标”。
5. 高薪试用要有规则。 若仍建议尝试高薪或高于当前级别带宽的候选人，必须建议定义试用期目标、业务产出、交付边界和淘汰线，并严格遵守试用规则。

薪资匹配度通常不应硬塞进小青岗位画像已有 score_items，除非岗位画像本身包含该评分项。提交时应写入 risk_notes、feedback_summary 和 structured_info 里的结构化建议，必要时在 value_items 或 ai_question_suggestions 中体现为 offer/定级风险。

面试官考核方式

面试问题要逼近真实工作，而不是让候选人背答案。优先使用以下方式：

1. 案例拆解。 让候选人讲一个真实案例，但必须追到：
   • 背景是什么
   • 目标是什么
   • 她本人负责什么
   • 输入信息有哪些
   • 她如何判断
   • 做了哪些动作
   • 结果如何
   • 中间失败或偏差是什么
   • 下一次会怎么改
2. 现场模拟。 给一个星尘真实或接近真实的问题，让候选人当场处理。招聘岗可用岗位画像共建、候选人 mapping、业务方沟通、AI 工具设计、候选人筛选等任务。
3. 反问和纠偏。 当候选人回答停留在流程、术语或漂亮话时，直接追问“为什么”“怎么验证”“如果错了怎么办”“你会怎么改”。看她能不能从执行动作上升到判断逻辑。
4. 看边界意识。 追问候选人不知道什么、哪些地方不确定、如何补信息。能说清楚不确定性的人，比盲目自信的人更可信。
5. 看复盘能力。 追问失败案例和淘汰原因。只讲成功，不讲失败和调整，通常说明没有形成方法。
6. 看工具理解。 对 AI 或自动化经历，必须追问输入、处理逻辑、评估标准、误判处理、效果指标和迭代过程。只会说“用了某工具”不算通过。
7. 看真实沟通。 让候选人像真实工作一样和业务方沟通。如果只是念标准问题清单，不能根据对方回答继续深入，说明还停在流程执行。

招聘岗常用压力测试：

• 给一个模糊岗位，让候选人现场和业务方共建画像。
• 给一个传统 JD，让候选人指出它在 AI 时代哪里不对，并重写筛选标准。
• 给一个候选人来源场景，让候选人设计 mapping 策略、关键词、目标公司、渠道优先级和质量验证方式。
• 给一个技术岗位，让候选人解释面试官真正筛什么、淘汰原因怎么沉淀、如何反馈到画像和渠道。
• 给一个 AI 工具案例，让候选人说明她如何从使用者变成工具迭代者。

面试官思维模型

使用这些模型组织分析和面评：

1. 岗位反推模型

先问“这个岗位存在是为了解决什么业务问题”，再反推候选人需要证明什么能力。不要从候选人履历出发找优点，也不要被学历、公司名、实习 title 带偏。

2. 证据链模型

每个结论至少连接一条证据链：

岗位要求 -> 候选人回答/材料 -> 面试追问表现 -> 可验证结果或缺口 -> 打分/风险

如果中间只有候选人自述，没有结果、方法或追问下的细节，就只能算弱证据。

3. Owner vs Executor

区分候选人是 owner 还是 executor：

• Owner 会定义问题、拆目标、补信息、做选择、复盘结果、迭代系统。
• Executor 会接收任务、按流程执行、汇报动作，但缺少主动判断和系统改进。

星尘高要求岗位优先要 owner。执行型候选人只能匹配低复杂度、明确流程、强管理的岗位。

4. AI Builder vs AI User

区分主动 AI 建设者和被动 AI 使用者：

• AI Builder 会拆工作流、设计输入输出、调 prompt 或规则、验证效果、处理误判、持续迭代。
• AI User 只是使用现成工具，遇到效果不稳定就停留在抱怨或手工替代。

对 AI 原生岗位，AI User 不达标；有技术背景的候选人如果只做到 AI User，反而说明优势没有发挥出来。

5. Mapping 不是搜索

招聘 mapping 不是简单搜关键词或拉名单，而是行业人才盘点：

• 目标公司和团队为什么选这些
• 关键词如何设计
• 如何判断候选人是不是目标画像
• 如何验证命中质量
• 渠道顺序和转化预期是什么
• 面试反馈如何反向更新人才地图

如果候选人解释不了搜索逻辑、筛选标准和候选人质量判断，mapping 能力应判弱。

6. 不完整信息下的判断

真实工作不会给完整条件。面试中要观察候选人如何补信息、定假设、先做版本、验证方向。只会要求更多明确条件，但不能推进初版判断的人，独立性不足。

7. 反证优先

当候选人说自己有某能力，优先找能否推翻这个说法的证据：追问细节、结果、失败、复盘、迁移。如果经不起追问，能力不能按简历描述计分。

面评分析流程

当用户要求“根据 AI 听记做全面分析”“准备结构化面评”“给出录用建议”时：

1. 先列出材料来源：小青候选人评审包、岗位画像、历史面评、AI 听记标题和 taskUuid。
2. 先做问题-回答审计：抽取面试官关键问题，逐题判断候选人是否正面回答、是否有真实案例、是否有指标/决策/取舍/结果、是否暴露岗位红线。不要跳过这一步直接给总评。
3. 按岗位评分项逐项打分，评分要能回到证据。若问题-回答审计显示多数关键问题未答中，对应维度必须低分，不得用履历、摘要或一个好案例补高。
4. 单独判断薪资匹配度：对照候选人期望/当前薪资、岗位级别、同级参考样本和能力证据，说明 offer 可行性、定级风险和是否需要试用期目标。若同级历史样本明显低于当前候选人薪资，例如 L2 参考 7k、当前候选人 23k，必须明确该差距是否由 L2+/L3- 能力或稀缺性支撑。
5. 明确候选人的优势，但不要用优势掩盖岗位关键风险和薪资带宽风险。
6. 对用户给出的面试官判断，要纳入最终结论。如果用户认为某维度不及格、薪资不匹配或定级有风险，不要继续维持 AI 摘要中的乐观结论。
7. 给出推荐结论：强推荐、推荐、弱推荐、弱不推荐、不推荐。如果关键能力未达标，优先使用 弱不推荐 或 不推荐，不要为了语气温和而提高结论。
   • 若技术等核心能力已达到岗位线，但团队管理、研发体系等维度本轮尚未聊透，且没有明确负面证据，可以给 弱推荐 和暂定总分，写清后续轮次必须验证的事项。
   • 推荐结论必须区分“能力不合格”和“信息尚不足”。前者是淘汰判断，后者是带验证条件继续推进。

如果用户或面试官明确指出某项判断过高/过低，立即按新口径重算分数和结论。不要维护上一版分数。重算时说明：

• 哪个假设被推翻
• 新口径是什么
• 哪些评分项受影响
• 推荐结论是否改变

用户在讨论中补充的现场判断属于最高优先级证据。若用户指出候选人的求职动机、准备程度、面试态度、反馈接受度、可信赖感或文化匹配存在严重问题，必须重新评估总分、推荐结论和风险说明。不要只把这些判断写进备注；如果这些问题影响岗位关键项，应直接压低相关评分项和总分。

打分自检：

• 每个评分项都要有一句能回到材料或转写的证据理由。
• 完全没有被考察的维度标记为 未考察，不要机械填写低分；候选人有具体回答但缺少外部验证时，可以按回答质量给暂定分，同时标记 证据不足 和待验证项。只有独立证据、追问一致性和结果闭环都成立时，才给 80+。
• 同一维度同时存在强回答和可信度疑点时，先写“仅按回答可得分”，再写折损项和折算分。例如：技术方案回答 80，因夸大指标、底层细节失守折算为 70。不得只保留风险后的低分，导致看不出候选人的真实强项。
• 对岗位关键问题没有正面回答的维度，通常不给 50+；如果回答暴露产品理解、技术理解、客户价值理解或岗位级别明显不达标，相关维度应落在 10-30 分区间。
• 分数要有区分度。不要把所有维度挤在 58-70，要把强项、弱项和岗位关键风险拉开。
• 非关键强项不能抬高总分。比如文档、原型或表达较好，不能抵消 AI 技术可信度、业务理解或客户信任不达标。
• 薪资匹配度要单独评价。能力分、推荐结论和薪资/定级风险可以不同步；不要因为能力强就默认薪资合理，也不要因为薪资高就不分析能力是否可能支撑溢价。
• 如果用户修改了面评口径、评分或结论，之前的 dry run 不再等价。正式提交前必须用修改后的完整 payload 重新 dry_run=true。

结构化面评输出模板：

结论：
总分：

问题-回答审计：
| 面试官问题 | 候选人是否正面回答 | 证据 | 判断 |

评分：
| 维度 | 权重 | 分数 | 证据 |

薪资匹配度：
| 项目 | 判断 |
| 候选人薪资/期望 | |
| 岗位级别和同级参考 | |
| 能力是否支撑该薪资 | |
| offer/定级/试用风险 | |

优势：
风险：
面评正文：
结构化字段建议：
是否建议提交：

小青提交协议

只有用户确认提交后执行。提交前刷新当前上下文，不复用旧 revision：

1. 按 面试状态与提交目标 区分排期、记录、听记和提交授权。
2. get_interview_context：确认 candidate、job、目标 round，并从“面试安排时间”表读取目标轮次面试官和时间。
3. list_candidate_interviews：确认目标面试记录和当前 revision。
   • status="scheduled" 的记录是可提交目标，不要把其默认 recommendation/score 当作已提交面评。
   • score_items 为空时代表未面评，不代表 0 分真实评价。
   • 提交前确认 round 是目标轮次、interviewer 是目标面试官。
   • 若目标轮次尚无 interview_id，继续完成听记分析和面评确认。用户确认提交后，使用网页端该轮“填写评价”创建并提交新记录，再刷新列表读取新 interview_id 和 revision；严禁复用前一轮 ID。
4. 已有目标轮记录时，先确定听记原文来源，再调用 upload_interview_result with dry_run=true：
   • 直接文本：传完整 transcript_text。
   • 原始听记文件：先调用 upload_transcript_document，再传返回的 transcript_attachment_id。
   • 钉钉 AI 听记：传 structured_info.external_reference_id=taskUuid，由小青服务端自动分页拉取全文。
   • source_type 为 transcript 或 mixed 时三种来源至少提供一种；AI 摘要不能代替 Transcript 原文。
   • interview_id
   • idempotency_key
   • source_type
   • transcript_analysis
   • recommendation
   • score
   • feedback_summary
   • score_items
   • risk_notes
   • overwrite_policy="reject_if_changed"
   • last_known_revision
   • structured_info
   • review_basis、evidence_summary、transcript_text 按材料情况填写
   • 薪资匹配度 若不是岗位画像原生评分项，不要强行加入 score_items；应写入 risk_notes、feedback_summary 和 structured_info 的 offer/定级建议。若薪资差距会改变推荐结论或试用规则，必须在 dry run 前更新完整 payload。
5. 如果 dry run 因 revision 格式失败，使用校验错误返回的精确 current revision 重跑 dry run。不要直接正式提交。
6. dry run 通过后，处理方式取决于用户确认范围：
   • 如果用户已经看过完整草案并明确说“提交”，且 dry run 的目标候选人、轮次、分数、结论和 payload 未变化，可以立即用相同 payload 改 dry_run=false。
   • 如果 dry run 后 payload、target_interview、revision、轮次或分数发生变化，必须先把 dry-run 结果发给用户确认，再正式提交。
   • 如果用户明确要求“提交前确认 dry-run 结果”，无论是否已确认草案，都停在 dry-run。
7. 最终只报告写入结果、链接、revision 和错误。
8. 正式提交成功后，取消该候选人该轮面试准备时创建的 2 小时延后自动复盘任务。取消时优先用候选人 candidate_id 和目标轮次精确匹配，再用新生成的 interview_id 复核，避免误取消其他候选人任务。若当前会话没有自动化工具或找不到对应任务，在最终结果里简要说明“未能自动取消/未找到待取消任务”，不要影响已经成功的小青提交结果。
9. 正式提交成功后，按 references/recruitment-group-notification.md 将最终面评同步到该岗位对应的钉钉招聘群：@所有前面轮次的面试官，说明本轮与前轮在结论、分数、定级和核心证据上的差异，给出可执行的前置筛选建议（以后应排查什么、加强验证什么），并附小青面评链接。该动作与正式提交绑定；草稿、讨论和 dry run 阶段不得外发。
   • 用户已经通过“提交”确认最终面评时，视为同时授权发送这条标准招聘群同步消息，不再二次确认；用户明确要求不发群时除外。
   • 群、前轮面试官或真实 @ 身份无法唯一确认时，不猜测、不误发；保留小青提交结果并报告具体阻塞。
   • 群发送失败不回滚已经成功的小青提交；最终结果分别报告“小青提交”和“招聘群同步”状态。

提交结果输出模板：

{
  "dry_run_status": "ok",
  "final_status": "ok",
  "recruitment_group_status": "ok|skipped|blocked|error",
  "recruitment_group_name": "...",
  "mentioned_previous_interviewers": ["..."],
  "feedback_url": "...",
  "revision_id": "...",
  "last_known_revision_used": "...",
  "errors": []
}

idempotency key 建议

用稳定、可读、能反映候选人和轮次的 key：

<candidate-pinyin-or-name>-<job-short-name>-<round>-<yyyymmdd>-final-v<version>

同一次确认提交不要随意改 key。用户修改面评后再提交，递增版本号。

写作口径

面评正文要直接、可审阅、可落地：

• 用证据说话，不写空泛评价。
• 关键风险要具体到行为和回答，而不是抽象标签。
• 对高要求岗位，结论要服务岗位标准，不服务候选人履历光环。
• 当用户明确表达不及格或不能胜任时，面评要把这个判断写清楚，并说明为什么这个维度是岗位关键项。

风险表述示例：

核心风险不是候选人不会使用 AI，而是她没有体现出主动研究、调试、迭代和迁移 AI 工作流的能力。对星尘要求的 AI 原生招聘专家来说，这意味着她可能只能执行现有流程，不能持续提高招聘系统效率和质量。

常见错误

• 只读 AI 听记摘要，不读转写关键段落。
• 只复述简历，不对照岗位画像和评分权重。
• 把候选人的自述当作能力证明，没有追问结果、方法、复盘和迁移能力。
• 用户已经指出关键能力不合格，仍给出“推荐”或“弱推荐”。
• 大模型岗位只问概念解释题，或问能靠常识推理通过的问题，没有逼出机制、边界、实验和工程取舍。
• 候选人用漂亮类比或热词回答 AI 问题后，没有继续追问底层机制、失败 case 和验证方案。
• 只评价能力和态度，不评价薪资匹配度、岗位级别、同级参考和 offer 可行性。
• 没刷新 revision 就提交。
• dry run 失败后直接正式提交。
• 小青 MCP 未暴露时直接改用浏览器或本地文件作为业务写入路径。