learn-harness-engineering 的 Evaluator Rubric 模板：六维评分卡与 Agent 会话验收实践

learn-harness-engineering 的 Evaluator Rubric 模板六维评分卡与 Agent 会话验收实践【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址: https://gitcode.com/gh_mirrors/le/learn-harness-engineering导读本指南围绕 learn-harness-engineering 仓库中模板体系的核心文件之一——评估评分卡模板Evaluator-Rubrik展开讲解如何在一次或一组 Agent 会话结束后、正式验收之前用正确性、验证、范围纪律、可靠性、可维护性、交接准备度六个维度对 Agent 产出做结构化打分并给出接受、修订、阻塞三种结论。读完本文你将掌握这张评分卡的使用时机、每个维度的判定要点、评估器校准Kalibrierung的迭代流程以及它在仓库实战项目与自动化验证脚本中的两种落地形态。Evaluator Rubric 在 harness 工程中的定位在 learn-harness-engineering 的模板体系中evaluator-rubric.md是评审评分表它在实现完成后、最终验收前使用回答一个与日常进度跟踪完全不同的问题——这次会话里Agent 的工作是否真的达到了要求它与仓库中其他模板的分工十分明确见模板指南claude-progress.md进度日志记录项目当前处于什么状态feature_list.json功能清单跟踪哪些功能已完成、证据是什么session-handoff.md交接笔记告诉下一场会话从哪继续clean-state-checklist.md清洁状态检查表确保仓库可以被干净地接手evaluator-rubric.md评分卡判断Agent 这次的产出质量是否达标。尤其要注意它与quality-document.md质量快照的区别评分卡评估的是单次 Agent 产出这轮干得好不好而质量快照评估的是代码库本身随时间的健康度项目在变强还是变弱。两者回答不同的问题使用时不要混为一谈。六维评分表0–2 分级验收原模板的核心是一张 0–2 分的六维评分表使用时机为实现之后、最终验收之前。完整表格如下维度问题评分0–2备注正确性Korrektheit实现出来的行为是否符合目标功能验证Verifikation要求的检查是否真的跑过并留下证据范围纪律Scope-Disziplin这一轮是否基本保持在选定功能范围内可靠性Zuverlässigkeit结果是否能在重启或重跑后继续工作可维护性Wartbarkeit代码和文档是否清楚到足以交给下一轮会话交接准备度Handoff-Bereitschaft新会话是否能只靠仓库内工件继续推进每个维度按 0–2 打分。关于分值含义仓库模板没有逐分定义但可以结合模板指南对六维度的完整说明合理推断其判定方向正确性实现的真实行为是否与目标功能一致而不是看起来像实现了。判定时应以 feature_list.json 中声明的user_visible_behavior用户可见行为为对照基准。验证关键检查编译、类型检查、测试、构建是否真的执行过且留有证据。这一维度直指 Agent 最常见的失范行为——口头宣称完成而测试从未跑过。注意 feature_list.json 模板要求每个功能记录verification步骤和evidence证据评分时应据此核对。范围纪律会话是否始终聚焦于选定的一个功能而没有顺手改无关代码。仓库模板明确要求同一时刻只能有一个in_progress功能见 feature_list.json 状态规则这一维度就是对该规则的验收。可靠性结果能否经受重启或重跑而无需人工修复。对长期多会话项目而言这意味着依赖不被破坏、状态可恢复。可维护性代码与文档是否清晰到下一场会话能直接接手的程度而不是只有原作者能理解。交接准备度一场全新会话能否仅凭仓库内工件AGENTS.md、进度日志、交接笔记、功能清单继续推进无需口头补充。三种结论与后续动作评分完成后评估者需要给出明确的总体结论模板提供了三档德语原模板Akzeptieren接受Accept——达到要求可以验收Überarbeiten修订Revise——需要修正后才能验收Blockieren阻塞Block——存在必须先解决的根本性问题。在结论之后模板强制要求填写后续动作Erforderliches Follow-Up三行缺失的证据Fehlende Nachweise哪些验证没有留下可查证的证据需要补录必须补的修复Erforderliche Korrekturen验收前必须完成的修正项下次复审触发条件Nächster Review-Trigger什么条件满足时再次评审。这三行是评分卡闭环的关键它把一次评审的结论转化为下一次会话的可执行输入避免评完就完、问题悬空。关键陷阱评估器必须校准3–5 轮迭代模板指南用一段加粗警告点明了使用评分卡时最容易被忽视的问题评估器需要校准。开箱即用的 Agent 是糟糕的自我评估者——它们能识别出问题然后又说服自己批准通过。这意味着如果让 Agent 用这张评分卡给自己打分它倾向于自我放行。解决办法是持续迭代校准指南给出了明确的五步流程把评分卡应用到一个已完成的迭代上将它的评分与你自己的判断进行对比在两者出现分歧的地方把评分卡改得更具体——用明确的通过/失败标准替代模糊描述重新运行并检查一致性重复以上步骤直到评分卡结果与人工评审稳定一致。模板指南还给出了两个落地建议预留 3–5 轮校准每轮都记录评分卡的每次变更以便追溯到底是什么改动提升了与人工评审的一致性。校准本身不是一次性的——随着模型能力变化、项目特征变化评分标准也需要随之更新。从模板到实战仓库中的两种落地形态原模板是 0–2 分、六维度的轻量评分表而仓库的实战项目中展示了两套更细化的落地变体可作为扩展参考。形态一Capstone 全量评分表1–5 分制。project-06 的评估评分表针对运行时可观测性与调试毕业项目把评分表扩展为 15 项标准构建与编译、窗口启动、文档导入、文本索引、接地问答、对话历史、反馈收集、结构化日志、清洁状态重置、持久化、状态栏、基准脚本、清理扫描器、harness 完整性等采用 1–5 分制并在表后附上harness 文件清单评估9 个顶层文件逐一核验、文档评估和IPC 通道覆盖清单14 个通道逐一列出。它展示了评分卡可以从一张表生长为评审报告集。形态二生成器 评估器双角色模式。project-05 的 gen-eval 评估评分表演示了另一种用法实现 AgentGenerator与评审 AgentEvaluator分离评审 Agent 在生成之后对组件进行 8 项细化评分功能完整度、视觉设计、时间戳、引用展示、交互性、边界情况、可访问性、代码质量并记录修订证据链——初始 2.8/5 → 修订一 3.1/5 → 修订二 3.3/5同时列出遗留问题与下一步建议。这正对应模板指南中先识别问题、再逼近通过的评审精神评分不是终点驱动修订才是。与自动化验证脚本的互补关系除了人工填写的评分卡仓库还提供了可自动执行的 harness 校验脚本 validate-harness.mjs。该脚本从instructions指令、state状态、verification验证、scope范围、lifecycle生命周期五个子系统对仓库进行静态评分每子系统 1–5 分总分换算为百分制默认 70 分为及格线见 harness-utils.mjs 的评分实现并可输出 JSON 或 HTML 报告--json/--html。从源码结构看两者存在明确互补validate-harness.mjs检查的是harness 工件本身是否齐全、结构是否达标如是否包含 AGENTS.md、feature_list.json 是否合法、init.sh 是否set -e快速失败等而evaluator-rubric.md评估的是Agent 会话产出的行为质量行为是否符合需求、验证是否有证据、能否交接。前者可随时批量执行、作为客观基线后者需要人工或双角色评估者结合证据做判断。这一点与 harness-creator 的 eval 3 Harness Assessment 的要求一致——按五子系统评分并识别瓶颈子系统同时强调分数必须给出依据。实践中可先用脚本自动打分定位薄弱子系统再用评分卡对薄弱环节做人工复核形成自动化扫描 人工验收的双层闸门。可复制的完整模板德语原文与中文对照最后附上原模板的完整结构可直接复制到项目根目录后使用德语为原版措辞中文为对照翻译# Evaluator-Rubrik / 评审评分表 Verwenden Sie diese Rubrik nach der Implementierung und vor der finalen Abnahme. 在实现完成后、正式验收前用这张表做一次评审。 | 维度 | 问题 | 评分0-2 | 备注 | | --- | --- | --- | --- | | Korrektheit / 正确性 | Entspricht das implementierte Verhalten dem angeforderten Feature? / 实现的行为是否符合目标功能 | | | | Verifikation / 验证 | Wurden die erforderlichen Checks tatsächlich mit Nachweis ausgeführt? / 要求的检查是否真的跑过并留下证据 | | | | Scope-Disziplin / 范围纪律 | Blieb die Session im gewählten Feature-Scope? / 会话是否保持在选定功能范围内 | | | | Zuverlässigkeit / 可靠性 | Übersteht das Ergebnis einen Neustart ohne Reparatur? / 结果能否在重启后无需修复继续工作 | | | | Wartbarkeit / 可维护性 | Sind Code und Dokumentation klar genug für die nächste Session? / 代码和文档是否清楚到足以交给下一轮会话 | | | | Handoff-Bereitschaft / 交接准备度 | Kann eine frische Session nur aus Repo-Artefakten weiterarbeiten? / 新会话能否只靠仓库工件继续推进 | | | ## Urteil / 结论 - Akzeptieren / 接受 - Überarbeiten / 修订 - Blockieren / 阻塞 ## Erforderliches Follow-Up / 后续动作 - Fehlende Nachweise / 缺失的证据 - Erforderliche Korrekturen / 必须补的修复 - Nächster Review-Trigger / 下次复审触发条件配套使用建议模板目录 docs/de/resources/templates 中还有其他 9 个模板AGENTS.md、init.sh、claude-progress.md、feature_list.json、session-handoff.md、clean-state-checklist.md、quality-document.md 等模板指南建议先复制 AGENTS.md、init.sh、claude-progress.md、feature_list.json 四件套再随项目成长补充其余文件评分卡即属于项目长大后加入的验收层中文版对照见 中文评审评分表每个项目可根据自身需求调整分值制如 project-06 用 1–5 分、模板默认 0–2 分与维度数量但务必保留证据驱动评分 明确结论 可追溯的后续动作三要素。小结Evaluator Rubric 是 harness 工程中验收闸门的最小可执行单元六个维度分别锁定正确性、验证证据、范围纪律、可靠性、可维护性与交接准备度三种结论与后续动作模板保证评审可闭环而评估器需要校准这一告诫提醒我们——任何评分卡的有效性都取决于持续与人工判断对齐。在实际项目中它既可以作为单会话后的快速自评表也可以扩展为 project-06 式的完整评审报告并与validate-harness.mjs的自动化五子系统评分互为补充构成一套从工件结构到会话行为的完整质量保障链路。【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址: https://gitcode.com/gh_mirrors/le/learn-harness-engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考