背景

README 里给出的评分口径是 综合得分 = 技术平均分 × 0.7 + HR 平均分 × 0.3，技术面试 5 题、HR 面试 3 题。这套口径本身没问题，但目前看起来是写死在「人才测评专员」的 Skill 里的，实际使用时踩到两个点：

问题

1. 权重和题量不可配：校招岗更看重基础与潜力，资深岗更看重技术深度，二者用同一个 0.7/0.3 会把候选人的差异抹平；题量同理，5+3 对实习岗偏多、对专家岗偏少。
2. 中途终止时平均分的分母未定义：候选人只答了 3 道技术题就结束（掉线 / 主动放弃），「技术平均分」是按已出题数还是按计划题数取平均没有说明。两种算法出来的分数不可比，但报告里看不出来。
3. 报告只有 HTML：评估报告是 HTML 模板渲染的，没有机器可读产物，想接 ATS / 自己建个候选人看板只能去解析 HTML。

建议

1. 把权重与题量提到可配置处（例如 Skill 目录下的 config.yaml，或环境变量 TECH_WEIGHT / HR_WEIGHT / TECH_QUESTIONS / HR_QUESTIONS），默认值保持现在的 0.7 / 0.3 / 5 / 3 以兼容现有行为。
2. 生成 HTML 报告的同时输出一份 report.json，字段建议：
   • questions[]：题号、维度（技术/HR）、题干摘要、得分、追问轮次
   • weights：本次实际使用的权重
   • score：技术均分、HR 均分、加权综合分
   • coverage：completed / planned 题数，缺考维度显式标 null 而不是按 0 计
3. 报告开头显式标注本次的评分口径（权重 + 题量 + 是否完整作答），避免拿不同口径的分数横向比较。

验收标准

• 修改 TECH_WEIGHT / HR_WEIGHT 后，综合得分按新权重变化，且 report.json.score 与 HTML 报告里显示的数值一致；
• 候选人提前结束时，coverage 能反映「完成 3 / 计划 5」，综合分不被静默按 0 分补位；
• 默认配置下结果与当前版本完全一致（向后兼容）。

如果维护者认可这个方向，我可以按上面的字段先提一版 report.json 的 schema 和最小样例。