组合评分 | JevCode

把复杂判断拆成原子分数，用你完全掌控的权重在代码里合并。

这个模式解决什么问题

我们经常需要同时按多个维度对一组项目排序。直接把「综合评分」写成一个问题会很糟：模型给出的分数无法解释，你也不知道它为什么这么排。

组合评分的做法：把判断拆成独立的维度，各自单独打分，然后在代码里用你自己掌控的权重合并。

例子：简历筛选

假设你在处理工程岗位的简历，想按多个标准对候选人排序，最终选出前 X 名进入下一轮。

第一步：独立给每个维度打分

一次调用里问出四个 Score：python_depth、team_leadership、system_design、generalist，每个维度用自己的档位定义。

第二步：用权重合并

py      = response.answers["python_depth"].score / 4
lead    = response.answers["team_leadership"].score / 4
arch    = response.answers["system_design"].score / 4
general = response.answers["generalist"].score / 4

# Senior IC（资深个人贡献者）
ic_score = (0.40 * py) + (0.10 * lead) + (0.40 * arch) + (0.10 * general)

# Engineering Manager（工程经理）
em_score = (0.15 * py) + (0.40 * lead) + (0.20 * arch) + (0.25 * general)

每个维度先归一化到 0–1，再加权。

这个模式真正的价值

加权得到排序结果只是表面收益。真正的价值是可解释性。

注意上面两个不同岗位用了同一组分数、不同的权重。这意味着：

一次调用同时服务两个招聘方向，成本不翻倍；
如果排名结果不符合预期，你可以直接调整权重，而不必重新调提示词；
当有人质疑「为什么这个候选人排第一」时，你能展示出各维度的分值分布和权重。

每个维度的细节都没有丢失。 一个 Python 强但带团队弱的候选人，在 IC 岗位上排前面，在 EM 岗位上排后面——这个差异是权重编码的，不是模型重新判断的。

断点调试

权重还有一个实用好处：你可以按单个维度排序来排查异常。 如果综合排名看起来不对，先把 python_depth 单独排序，看是否与直觉一致。如果不一致，问题出在那一维的档位定义上，而不是权重上。这种可分解性是「一个大问题直接问模型」做不到的。

如果发现某一维的区分度不够（所有人都集中在同一档），说明档位定义需要重写，而不是调权重。

与置信度的配合

每个维度的 Score 都带 confidence。低置信度的维度是个信号：要么档位定义有歧义，要么 state 里缺少判断依据。

一个实用的做法是：如果某个高权重维度的置信度低于阈值，把该候选人标记为「需要人工复核」，而不是让一个不可靠的分数主导排名。

设计要点

维度必须正交。 如果两个维度高度相关（例如「Python 深度」和「编程能力」），加权会重复计算同一件事。设计维度时问自己：这个维度能否独立变化？

权重归一化到和为 1。 便于理解和调整。

先归一化再加权。 不同维度的档位数通常不同，不归一化会让档位多的维度获得不成比例的影响。

权重是业务决策，不是技术决策。 谁来决定 IC 岗和 EM 岗的权重差异？应该是用人方，不是工程师。把权重做成可配置项。