绩效环评人推荐
单一任务
推荐在指定期间内直接观察过某员工工作的人员，并解释为何每位人员都是合适的360度环评人。使用Lark CLI作为数据访问层。使用当前的Agent宿主（Doubao Enterprise、Codex或Claude Code）作为推理层。
此技能不评估员工绩效、指定评审人、发送邀请、撰写绩效记录或推断个人隐私特征。
默认用户体验
接受如下请求：
给张三推荐本周期10位360环评人，并说明每个人的推荐原因。
解析员工、评审周期、请求数量和角色组合。当提供了明确的评审周期或日期范围时使用它们。如果无法从授权的Lark证据中确定当前周期，对于直接的推荐请求，使用一个公开的六个月观察窗口；仅当周期会实质性地改变候选人池或用户请求正式周期结果时，才询问周期。当未指定数量时，默认为10位候选人。当请求未指定组合时，包含经理、同事和跨职能视角；当员工是经理且评审设计需要下行反馈时，包含直接下属。
当歧义会实质性地改变候选人池时，提出一个简洁的澄清问题。不要因可以报告为假设的偏好而延迟任务。
宿主与访问网关
在任何飞书检索之前，请先阅读 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。
完成边界
正常的终点是向HR或负责经理提供推荐草案。不要分配评审人或写回绩效系统。如果用户随后明确要求写入，则需要干运行预览、确认、幂等性保护和精确回读；将推荐和人为决策作为单独记录保存。
质量检查
使用合成或脱敏的测试用例测试以下情况：缺少Lark CLI、用户身份过期、仅机器人访问、分页不完整、转录不可读、仅出席的候选人、重复身份、冲突标记、角色缺口、矛盾证据、证据稀疏和无效的模型JSON。显式报告 blocked 或 insufficient_evidence，而不是填充配额。