GxP招聘证据核验与结构化面试

它解决什么问题

GxP 相关岗位（临床、实验室、质量体系等）的招聘场景中，候选人材料真实性核验与面试流程规范化是刚性需求。这类能力涉及受保护的业务逻辑，不能靠一段提示词在本地凭空展开。本技能把真正的业务流程放在云端，本地层只负责环境检测与鉴权门禁——先确认运行环境可用，再确认调用方已授权，两个条件都满足后才拉取并执行云端指令。

它是如何工作的

运行时可以拆成三个阶段：

• Python 环境检测（最先执行）：跑任何脚本前先静默探测 PYTHON_CMD，有值且版本可用就直接执行，失败才上报。Windows 下 python 命令可能打开 Microsoft Store 而非执行解释器，文档建议改用 py -3 启动器。若用户主动提供全路径，则直接采用。
• 鉴权门禁：全部授权逻辑收敛在 scripts/auth.py 里，覆盖本地凭证缓存、WorkBuddy 用户绑定、平台授权校验。stdout 只有五种信号：AUTH_OK、AUTH_REQUIRED+CREDENTIALS_MISSING、AUTH_INVALID+CREDENTIALS_INVALID、AUTH_BIND_OK，以及 --bind-jwt 失败时的 AUTH_INVALID，业务细节走 stderr。
• 关键决策：可修复 vs 真失败：AUTH_REQUIRED / CREDENTIALS_MISSING 不是故障，而是首次绑定的正常流程。Agent 必须主动调用 connect_cloud_service 拿到 JWT 并执行 --bind-jwt，用新凭证覆盖缓存，而不是停下向用户报告。只有绑定后再次 --ensure 仍失败，才属于真正的鉴权失败。

拿到 AUTH_OK 后，通过 scripts/protected.py 拉取云端受保护指令，并严格按返回内容执行。鉴权未通过时禁止产出任何业务结果，二者互斥。

适用边界与注意点

• 重试上限为 1 次：触发条件包括 CREDENTIALS_MISSING、CREDENTIALS_INVALID、HTTP 401/403、authorization failed、签名类错误关键字，以及 protected.py 退出码非 0 且 stderr 提示鉴权问题。两次失败即判定为数据服务暂不可用，停止重试。
• 鉴权失败必须原样转述 stdout 信号与 stderr 关键行，禁止用「稍后再试」糊弄；密钥字段必须打码（如 app_key=abc****）。
• AppKey / AppSecret 不得明文出现在业务命令、环境变量或回复中，也不在 SKILL.md 里手动解析 JWT 或拼接密钥。
• 云端拉取失败（未拿到 protected instructions）时必须停止，不得凭本地提示或历史上下文继续生成。
• 技能名中的「证据核验」与「结构化面试」指向具体业务能力，其执行细则存放在云端 protected instructions 中，本地文档不含这些内容，也未在此层声明具体的核验规则或评分标准。