绩效评估最怕一年做一次表、平时毫无积累；真正能跑起来的体系，必须把发起、目标跟踪和下一周期安排串成一条长期链。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/hr_appraisal/models/hr_appraisal.pyenterprise/hr_appraisal/models/hr_employee.pyenterprise/hr_appraisal/tests/test_hr_appraisal.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
hr_appraisal 管的不只是一次打分，而是员工、经理、目标与下次评估周期之间的长期关系：谁能发起请求、目标完成率如何汇总、下一次 appraisal date 如何随人事事件滚动。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 hr_appraisal 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. request flow 决定评估怎么启动
employee.action_send_appraisal_request()、request_appraisal 向导与相关测试说明，评估不是后台管理员偷偷建记录，而是有明确发起人与收件人链路。
2. 目标完成率是动态汇总的
hr_appraisal_goal.compute_number_of_completed_sibling_goals()、_compute_sibling_goals_ratio() 说明目标不是附件列表，而是会反向影响评估视图。
3. next appraisal date 会随人事事件重算
员工侧 _compute_next_appraisal_date() 与多组测试覆盖入职、首次评估、招聘后首次评估等场景，说明周期不是固定日历，而是和员工生命周期绑定。
三、最容易被误解的边界
- 把 appraisal 当成一次性问卷，不设计 request flow。
- 目标只记录名称，不利用 ratio / progression 追踪完成度。
- next appraisal date 固定写死，不随入职、离职或已完成评估重算。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查 appraisal request 是谁发起、模板发给了谁。
- 再核对 goal progression 与 sibling ratio 是否正确。
- 最后验证 next appraisal date 在关键员工事件后是否更新。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
绩效评估真正难的不是“写评价”，而是让目标、人和周期持续对齐；这才是 hr_appraisal 真正管理的对象。
DISCUSSION
评论区