绩效评审人推荐
单一任务
推荐在指定期间内直接观察过员工工作的人员，并说明为何每个人都是合适的360度评审人。使用 Lark CLI 作为数据访问层。使用当前的 Agent 主机——Doubao Enterprise、Codex 或 Claude Code——作为推理层。
本技能不对员工的绩效进行评分、指派评审人、发送邀请、撰写绩效记录，也不推断私人特质。
默认用户体验
接受如下请求：
给张三推荐本周期 10 位 360 环评人，并说明每个人的推荐原因。
解析员工、评审周期、请求数量和角色组合。使用明确的评审周期或日期范围（如果提供）。如果无法从授权的 Lark 证据确定当前周期，则使用公开的六个月观察窗口进行直接推荐请求；仅当周期会实质性改变候选人池，或者用户请求正式周期结果时，才询问周期。数量缺失时默认推荐十位候选人。当请求未指定组合时，包含经理、同级和跨职能视角；如果员工是管理者且评审设计需要下行反馈，则包含直接下属。
当歧义会实质性改变候选人池时，提出一个简洁的澄清问题。不要因可报告为假设的偏好而延迟任务。
主机与访问门控
在进行任何飞书检索之前，请先阅读 host-bootstrap.md。
- Doubao Enterprise：使用其内置的 Lark 工具或经批准的 Lark CLI 桥接。如果两者都不可用，则停止并报
blocked。 - Codex / Claude Code：需要本地安装
lark-cli。如果缺失，告知用户安装或启用，然后停止。 - 优先使用
lark-cli auth status --json --verify验证预期的租户、配置文件和用户身份。当当前 CLI 版本未暴露auth子命令时，回退到contact +get-user --as user，并在必要时使用task +get-my-tasks --as user作为只读兼容性探测。将contact视为已解析的当前用户，将task视为仅用户上下文，并且不要将兼容模式转化为可写或绑定主体的声明。 - 切勿静默使用机器人身份、不同的飞书配置文件、浏览器搜索或手动猜测的记录作为替代。
记录主机、Lark 配置文件、身份类型、令牌状态、作用域和检查时间，但不记录凭证。
检索顺序
使用 data-source-map.md 作为来源路径。优先选择回答请求的最窄只读查询，然后完整分页。
- 解析目标：识别员工并确认组织上下文。
- 解析周期：使用明确的周期或观察日期；如果使用了默认值，则保留假设。
- 查找共享工作：在授权范围内搜索目标在会议、转录文本、消息和线程、任务、文档、OKR、项目、审批、日历和邮件中的实质性协作。
- 构建候选人边缘：将员工与共同交付工作、做出决策、拥有后续行动、审核工件或参与可归属业务讨论的人员联系起来。
- 保留边界：记录来源、日期、访问状态、分页、截断、已删除材料和不可读工件。仅凭会议标题、与会者名单、消息提及或文档查看不足以证明观察。
优先选择以下顺序的一手证据：
- 共享交付物、任务所有权、决策、行动项、里程碑、实质性编辑/评论、OKR、审批和正式反馈；
- 有上下文的可归属消息或转录文本内容；
- 经一手材料佐证的 AI 生成会议摘要；
- 共同出席、群组成员、提及、查看和管理性抄送仅作为支持性上下文。
候选人规则
排除或标记员工本人、重复身份、非活跃或已离职用户、被允许群体之外的人员、策略定义的冲突以及任何在期间内没有实质性证据的人员。
将跨租户协作人员视为有资格标记的候选人，即使他们的直接证据很强。在将其放入可提交的候选名单之前，确认目标评审系统接受他们。
不要将消息量、会议次数、出席情况、反应、休假、薪酬、健康、年龄、性别、民族、残疾、私人关系或推断的性格作为正面证据。
如果可能，需要两个独立的证据项目，其中至少有一个实质性的一手项目。将置信度与排名分开：证据不完整的高排名候选人仍为低置信度。
选择视角覆盖，而非受欢迎程度。避免在一个团队或一种关系类型中过度集中。当证据不支持某个角色时，将其留空。
证据表示
将每个可用的观察结果规范化为 evidence.schema.json 中的合约。将原始快照和候选人名称映射保留在本地。为主机模型提供不透明的候选人别名以及最小化的事实和来源引用。
每个证据边缘必须回答：
- 谁观察了谁？
- 观察到了什么工作事实？
- 它支持哪个维度？
- 何时发生？
- 评审人可以检查哪个来源？
- 该事实是主要的、派生的、管理性的、受限的还是未知的？
推荐逻辑
当未提供组织策略时，使用透明的临时评分规则：
工作相关性 30
观察深度 25
时效性 15
证据广度 10
角色互补性 10
评审可靠性 10
在审计记录中存储评分规则版本。根据证据边缘计算组件，而非原始事件计数。对证据稀疏、冲突、视角重复和历史集中性应用明确的标记。不要让模型覆盖访问阻塞或证据不足的状态。
默认输出
以简洁易读的候选名单开头：
| 候选人 | 角色 | 推荐原因 | 证据范围 | 置信度 |
|---|---|---|---|---|
| 某人 | 跨团队协作 | 基于共同交付、关键决策和后续验收，对目标员工的交付与协作有直接观察 | 会议、任务、文档 | 中 |
每个原因必须说明观察到的工作关系、支持的维度和实质性限制。不要复制私人消息或将模型生成的声明呈现为源事实。
当需要机器可读输出时，返回与 output.schema.json 匹配的 JSON，并使用以下命令进行验证：
python3 scripts/validate_output.py path/to/result.json
始终包含来源覆盖范围、证据引用、已排除的候选人、数据缺口、置信度、主机审计元数据和 human_review_required: true。
完成边界
正常终点是面向人力资源或负责经理的推荐草案。不要指派评审人或写回绩效系统。如果用户后来明确要求写入，需要干运行预览、确认、幂等性保护和精确回读；将推荐和人工决策作为单独记录保存。
质量检查
使用合成或脱敏的测试夹具来测试缺失 Lark CLI、过期的用户身份、仅机器人访问、不完整的分页、不可读的转录文本、仅出席的候选人、重复身份、冲突标记、角色缺口、矛盾证据、稀疏证据和无效的模型 JSON。明确报告 blocked 或 insufficient_evidence，而不是填充配额。