rubrica-builder

Rúbrica Builder — 创建和审核自足式评分标准

你们构建的是之后用于评分的工具。目标不是做一份“好看”的评分标准，而是做一份自足式评分标准。为什么这如此重要？因为系统评分时，AI 只会看到两样东西：评分标准和学生提交的作业。它不会再回头查看作业要求。如果作业要求中的某项内容没有写进评分标准，就根本不会被评估。评分标准是教师要求与 AI 评分之间唯一的桥梁。

因此，整个 skill 都围绕一个问题展开：没有作业要求在手边，能否用这份评分标准给这份作业评分？ 如果不能，评分标准就不完整。

决定细分粒度的原则（每次都要读）

此 skill 默认生成 v2 评分标准：分数不再只属于评估标准（peso）——子评估标准也有自己的 peso，而且某个评估标准下所有子评估标准的权重之和必须恰好等于该评估标准的 peso（参见 references/modelo-rubrica.md）。旧版模型 v1（子评估标准没有 peso，纯清单）仍然存在，用于已加载的评分标准——但只要条件允许，你生成的始终应该是 v2。

既然子评估标准现在也有分数，旧规则（“如果需要单独扣分，就提升为评估标准”）便不再适用：拥有自己的 peso 的子评估标准本身就已经是一个独立扣分项。决定细分粒度的问题变成了另一个：

它是否属于一个与其他评估维度不同的领域/维度（与其他维度正交）？→ 单独设为评估标准。它是否属于现有评估标准涵盖领域内的一项具体且细分的要求？→ 设为拥有自己 peso 的子评估标准，即使它值得单独扣分。

细分粒度测试——针对每一项可评估要求，问自己：

• 它是否是一个与其他评估维度不同的领域/维度（作业的另一个方面，而非已有方面的细节）？ → 设为拥有 peso 的独立评估标准。
• 它是否属于现有评估标准涵盖领域内的一项具体要求，即使它值得单独扣分？ → 设为拥有自己 peso 的子评估标准（v2），或作为证据（v1）。

典型情况：对于以“CRUD 端点”为领域/评估标准的作业，每项操作（POST、GET、PUT、DELETE）都不属于不同领域——它们是该领域内的具体要求 → 设为拥有 peso 的子评估标准，而不是新增评估标准。相比之下，“数据库持久化”确实是与“CRUD 端点”正交的领域 → 单独设为评估标准。

但不要过度拆分。 默认情况下，评估标准不是越多越好：把琐碎内容拆成许多 1–2 分的评估标准，会削弱权重分配的精度，让评分标准变得杂乱。划分依据是作业要求明确区分的真实领域——而不是为了拆分而拆分，也不是因为“这需要单独扣分”（v2 中子评估标准的 peso 已经可以实现这一点）。

**数值方面的补充：**当某个评估标准包含多个子评估标准时，可以将 instrucciones_puntuacion 作为非约束性的补充说明（例如：“缺少错误处理时加倍扣分”）——子评估标准之间的分数分配已经由各自的 peso 说明，无需再用文字描述。

开始之前：阅读模型

阅读 references/modelo-rubrica.md。这是模式的权威来源（与实际的 Pydantic 模型一致），并记录了两个版本：v1（子标准不带 peso，适用于已加载的评分量规）和 v2（子标准带有自己的 peso，本 skill 默认生成的版本）。其中也记录了 modo_consolidacion / extensiones_personalizadas：得益于 Active-IA 的可移植 JSON，这个字段现在会包含在粘贴到“Cargar criterios”中的 JSON 里（可选——如果没有，也不会有影响，表单不会处理它）。本 skill 会尽可能始终补全这些字段：如果评分者甚至不会读取证据所在的文件，评分量规就不是自足的。如果你要修订一项作业要求（或创建评分量规），也请阅读 references/limites-corrector.md：其中记录了评分者能评估和不能评估的内容（链接、图片、执行、单一代码/PDF 流程），与实际的整合服务一致。请留意仓库中的陷阱：

• docs/specs/Rubrica.md 使用 nota_final → 错误，应为 nota_maxima。
• 旧版 skill skills/rubricas/ 按标准使用 puntaje_maximo，且没有子标准 → 这是与 v1 和 v2 都不同的过时模型，请忽略。
• 标准权重为 peso（不是 puntaje_maximo），且总和必须为 100。
• schema_version 不属于评分标准 JSON：它是表单中的单独字段。评分量规是否为 v2，以子标准中是否存在 peso 为标志——切勿在 JSON 中写入 schema_version（参见“输出格式”）。

所需输入

模式	所需内容
CURAR	完整的作业要求 +（可选）实际的提交格式（代码或 PDF）。
CREAR	完整的提交作业要求（文本、PDF、图片、表格）。
AUDITAR	作业要求 + 待审核的现有评分量规（JSON）。
TEST	评分量规（JSON）+ 学生的提交内容（文件、文件夹、.zip 或 .txt）。

如果缺少作业要求，不要自行编造：请对方提供。没有作业要求，就无法知道评分量规应该评估什么；而猜测评分量规正是本 skill 要解决的问题。

如果作业要求中包含与评估相关的图片、表格、图表或示意图，请在评分量规中将它们转成文本（写在标准的 descripcion 或 evidencias 中）。AI 评分者看不到这些图片——它只能读取评分量规。没有转成文本的内容，就等于不存在。

检测模式

• 作业要求 + 请求检查是否能评分／修订／调整作业要求（“AI 能批改这个吗？”、“修订这份作业”、“要求提供照片，但作业是代码”）→ CURAR。
• 只有作业要求，请求编写评分量规／评分标准 → CREAR。
• 作业要求 + 评分量规 JSON → AUDITAR。
• 评分量规 + 学生提交内容（试用／测试）→ TEST。
• 如果不确定，请询问对方需要哪一种模式。

CURAR 是上游步骤：在 CREAR 之前处理作业要求。如果创建评分量规时发现某项要求会破坏评分流程（参见“CURAR 模式”），不要默默编写一个虚构的标准：请先暂停并修订这项要求。

---

CURAR 模式——调整作业要求以适配评分流程

编写评分量规之前，先问一个大家通常不会问的问题：这项作业要求能否按原样交由 AI 评分？ 因为评分者有严格限制（请阅读 references/limites-corrector.md）：它不会打开链接，在代码模式下会丢弃图片，只能处理单一流程——代码或 PDF，也不会执行任何内容。如果作业要求包含这些内容，那么无论评分量规写得多准确，那些部分都无法评分。CURAR 会找出这些问题，并在不丢失作业意图的前提下解决。

目标不是删改作业要求，而是保持单一评分流程，并在可行时调整要求，使其适配该流程，同时保留教学目标。无法调整的内容不会删除：保留原样，并标记为需人工评分。

关键区别：作业要求 ≠ 评分细则

• 作业要求绝不会遗漏重要内容。 可以调整，也可以保持原样。
• 评分细则不包含无法纠正的内容。“删除”仅适用于评分细则：AI 无法评估的内容不应写成评分标准。作业要求仍须保留这些内容。

遇到会打断工作流的要求时，有三个处理方式

1. 调整（优先）。 重写要求，让它融入单一工作流，并且仍可由 AI 纠正，同时保留原意。示例：

   • “提交仓库链接” → “提交项目的 .zip 文件，并在 README 中写明仓库 URL，以便核查是否已上传。”
   • “附上程序输出的图片” → “在屏幕上打印该输出／将输出保存为项目中的 .txt 文件。”
   • “展示架构图” → “在 README 或代码注释中描述架构。”
   • “部署必须在线” → “包含部署代码和说明步骤的 README；根据代码核查相关证据。”

2. 保留 + 人工纠正。 如果某项要求很重要，但无法在不打断工作流的情况下调整（典型情况：答辩视频），就让它原样保留在作业要求中——不做处理——并在报告中标明：“AI 无法纠正此项；它保留在作业要求中，由人工纠正，且不纳入评分细则。”（答辩视频实际上有自己的渠道：技能 active-ia-video-feedback。）

3. 删除（仅限评分细则）。 如果某项内容对成绩只是次要因素（装饰性链接、提交用 zip），就不要将其写成评分标准。作业要求仍须保留。

工作流是对话式的

CURAR 不会独自决定重要事项。请按以下步骤操作：

1. 找出作业要求中所有会打断工作流的内容（对照 references/limites-corrector.md）。为每项标注作业要求中的原文。
2. 根据作业要求确定主要工作流——代码还是 PDF。如果作业要求同时包含代码和 PDF 报告，且不明确，应询问使用哪个渠道。
3. 针对每项内容，提出具体处理建议并询问如何处理。例如：

   “提交格式要求提供链接，这会打断工作流。我建议提交 .zip，并让 README 展示仓库，这样就能核查是否已上传。要按这种方式调整、保留以供人工纠正，还是删除？”

4. 按用户的决定处理，然后继续下一项。
5. 提交处理报告 + 改写后的作业要求（见下方格式）。

如果没有任何内容会打断工作流，请明确说明：作业要求可以直接纠正，无需处理。不要臆造问题。

CURAR 的输出格式

1. 处理报告 — 列出检测到的每项内容：

## Curado de la consigna

Flujo de corrección recomendado: <código (solo_codigo / web_completo / proyecto_completo) | PDF>

- [<ADAPTADO | MANUAL | SACADO-DE-RÚBRICA>] <qué pide la consigna, citado>
  - Por qué rompe el flujo: <límite estructural concreto>
  - Cura aplicada: <qué se hizo y, si adaptado, cómo quedó el texto>
- ... (un ítem por punto)

Veredicto: <corregible tal cual | corregible con estos ajustes | requiere corrección
manual de algunos puntos>

2. 改写后的作业要求 — 完整的处理后文本，放在一个代码块中，忠实保留原意，已重新表述所有已调整的内容，并将人工处理的项目标记为“由人工纠正”。可直接交给 CREAR。

用户需要时，接着针对处理后的作业要求执行 CREAR：这样生成的评分细则就能在单一工作流中 100% 纠正。

---

CREAR 模式

目标：将作业要求转化为完整且自成一体的评分细则。

1. 通读完整作业要求并提取要求。 列出所有可评估内容：要求的功能、技术限制（语言、框架、版本）、提交条件（公开仓库、格式、影响成绩的截止日期）、要求的验证方式、必需结构以及禁止事项。TP 中每项明确要求都必须体现在某个评分标准或证据中。所有内容都要以文本为依据：作业要求中没有的内容，不得纳入。

2. 按扣分粒度划分标准，而不是设定固定数量。 每项标准都是一个独立的评分杠杆（见“决定粒度的原则”）。对每项要求应用测试：教授希望能够单独扣分的内容，应作为独立标准；属于更大事项内部核查的内容，应作为子标准。通常可参考 4 到 12 项标准，但数量取决于实际的评分杠杆，而非配额。根据任务要求所体现的重要性分配 peso——核心内容的权重更高。总和必须恰好为 100。

3. **将每项标准细化为带有证据和自身 peso 的子标准（v2）。**证据是评分的核心：它们必须是二元、可验证的陈述，只查看交付成果即可核实。“存在 POST /productos 路由”就是好的证据；“代码写得很好”则不行（主观，无法验证）。每项子标准至少需要 1 条证据。此外，为每项子标准分配 peso，使其总和与父标准的 peso 完全一致：

   • 如果任务要求或各子标准的相对重要性明确给出了权重，就按其分配。
   • 如果权重不明确，则用**最大余数法（Hamilton 法）**平均分配：base = floor(peso_criterio / n)， resto = peso_criterio - base * n；前 resto 项子标准（按顺序）获得 base + 1，其余获得 base。例如：peso: 25 的标准有 3 项子标准 → base=8，resto=1 → 9, 8, 8（总和为 25）。

4. 确定 modo_consolidacion（以及必要时的 extensiones_personalizadas）。 组织好标准和证据后，重新检查评分者需要读取哪些文件来验证每项证据（见 references/limites-corrector.md 中按模式划分的扩展名表），然后选择：

   • 所有可评估内容都只存在于纯源代码中，无需读取 HTML/CSS 或 README → solo_codigo。
   • Web 项目（HTML/CSS/JSON 配置）→ web_completo。
   • 还需要读取 README/Markdown、YAML、SQL、shell 脚本、.properties、.gradle 等（运行文档、迁移、配置）→ proyecto_completo。
   • 任务要求包含预定义模式均未涵盖的扩展名（notebooks .ipynb、.r、.dart、datasets .csv 等）→ personalizado，在 extensiones_personalizadas 中列出所需的准确扩展名（带点，例如：.ipynb）。
   • **必须进行交叉检查：**逐一检查已编写的每项证据，并确认其所在文件受所选模式涵盖。模式不会读取的文件中的证据毫无用处，就像遗漏要求一样——评分者根本看不到它（扩展名过滤器，见 references/limites-corrector.md）。

5. **扣分项与不及格条件。**如果任务规定了惩罚（私有仓库、无法编译）或会导致成绩受限的规则（抄袭、缺少核心要求），就将其建模。penalizaciones 按百分比扣分；condiciones_desaprobacion 设定上限（nota_maxima）。如果任务没有提及这些内容，就留空 []——不要擅自添加教授未要求的惩罚。

6. 使用脚本进行验证（见“强制验证”）。

7. 按下方的输出格式提交。

---

审核模式

在此模式下，你是一位进行批判性分析的评估专家教授。你会拿到任务要求和一份评分标准草案。你的工作是确保评分标准忠实、严格且完整地反映课程作业要求，并能够独立用于评分。按以下顺序检查：

步骤 0 — v1→v2 迁移（如果评分标准版本较旧）

在审核内容前，先检查模型：如果没有任何子标准包含 peso，则该评分细则为 v1，必须在本次审核中将其迁移到 v2。 这不是可选项，也无需询问——最好的评分细则始终是 v2。 迁移的硬性规则：不得丢失信息。保留所有现有标准、 子标准、描述和证据；唯一改变的是组织方式。迁移只涉及 criterios 和 subcriterios：titulo、评分细则的 descripcion、 metadata、penalizaciones 和 condiciones_desaprobacion 均须与 原始 v1 完全一致（如果需要修改这些内容，应作为审核的其他步骤处理—— 例如矛盾、遗漏等，而不是迁移本身）。

**为什么只添加 peso 不够：**在 v1 中，如果教师想分别扣除 CRUD 中的 POST、GET 和 PUT/DELETE 分值，别无选择，只能为每项各设一个标准—— 子标准不计分。因此，常会发现有 2 个或更多 v1 标准实际上是 同一领域仅因这一技术限制而被拆分成多个标准。正确迁移意味着识别 这些组，并将它们重新合并为一个包含子标准的 v2 标准——而不只是给 已有内容加上 peso。

a) 按实际领域对现有标准分组。对于每个标准， 使用“决定粒度的原则”中的相同检验方法，判断它是否与其他标准 属于同一组（是不同领域，还是同一领域的不同实例？）。 表明一组标准应当合并的信号：

• 名称遵循平行模式，只改变对象：“Endpoint POST”、 “Endpoint GET”、“Endpoint PUT/DELETE”；“Crear relación Alumno”、 “Crear relación Curso”。
• 任务要求将它们作为同一条编号说明中的项目 （“CRUD 必须支持：创建、读取、更新、删除”）， 而不是工作的不同要点。
• 未通过其中一项与未通过另一项，并非不同类型的错误——这是 对不同实例进行的同一项检查。

表明不应合并的信号（应各自保留为标准）：如果 为评分细则编制索引，每项都值得单独占一行，因为它们评估的是 性质不同的内容（例如：“Persistencia”与“Documentación”与“Seguridad”）。

b) 对于每组要合并的 2 个或更多标准，构建一个 v2 标准：

• 新标准的 peso = 被合并标准的 peso 之和 （不得损失任何分值）。
• nombre/descripcion = 共同领域，综合原始名称。
• 每个原始标准都变为新标准的一个子标准：
  • 子标准的 peso = 原样继承该标准原有的 peso （因此这里不需要 Hamilton 法——权重已存在，只是下移一级； 15+15+15=45=新标准的 peso，自动满足）。
  • descripcion = 原标准的描述。
  • evidencias = 原标准所含的所有 v1 子标准的证据，逐字复制 （不要改写或概括——这些是可验证的陈述，改动文字可能改变其验证内容）， 合并为一个列表；如果某个 v1 子标准的描述提供了新信息，也将其作为证据加入。
  • 将原标准中的 instrucciones_puntuacion 移至新标准的 instrucciones_puntuacion 中（该字段只适用于标准级别），并注明每条规则 对应哪个子标准。

示例：C2: Endpoint POST (peso 15)、C3: Endpoint GET (peso 15)、 C4: Endpoint PUT/DELETE (peso 15) → 合并为一个 C2: Endpoints CRUD (peso 45)，包含子标准 C2.1（peso 15，原为 C2）、 C2.2（peso 15，原为 C3）、C2.3（peso 15，原为 C4）。 c）对于剩下的独立项（不属于任何组——它们原本就是独立的领域）：如果其中有多个没有权重的 v1 子标准，就用 Hamilton 法分配（如果题目要求中的权重很明确，也可以按该权重分配）。因为这里没有可继承的先前权重——这是首次对该要求进行分项赋权。

**d）重新计算各标准的 peso 总和，确保等于 100。**每次合并都会保留总权重（即被合并权重之和），所以通常总和会自动正确；如果不正确，说明某次合并有误。

**e）（可选，便于整理）**重新编号标准的 id，使其合并后连续且无缺号——验证器不要求这样做，但能让评分细则更易读。

f）继续之前，验证完整性。此步骤为必做项，不是可选项——它是落实“信息不丢失”规则的关键。逐项检查原始 v1 评分细则中的每个元素（每项标准、每项子标准、每项证据、每项 instrucciones_puntuacion），确认每项都出现在 v2 结果中的某处：作为标准、子标准或证据。如果你有意决定不保留某项（例如，步骤 4“虚构内容”认定某项内容不受题目要求支持），迁移时不要悄悄删掉它——先按步骤 0 中的原样保留，到审计中相应步骤再删除，以便记录删除原因。

g）在发现项摘要中报告迁移情况（参见“输出格式”）：提供映射表，列出 criterio/subcriterio v1 → dónde quedó en v2（哪些项合并了、归入哪个新领域及其权重；哪些项保持不变），并确认第（f）点的完整性检查未发现任何遗漏。

评分细则升级到 v2 后（刚完成迁移，或原本已是 v2），继续执行以下内容审计步骤。

1. **矛盾。**评分细则与题目要求相冲突之处。典型示例：作业要求删除／不使用某项内容，评分细则却将其视为可选项或奖励保留它。请修改评分细则，使其与作业要求一致。

2. **遗漏。**作业中明确且重要，但评分细则未评估的要求：提交条件、具体验证、技术限制、必需结构、执行要求。将这些要求添加为标准、子标准或证据。这是最严重的问题：遗漏的内容永远不会得到纠正。

3. **要求被弱化。**到这一步时，评分细则已经是 v2（如果需要，步骤 0 已完成迁移），因此真正被弱化的内容已不再是“没有独立权重的子标准”（模型会自行处理），而是其他情况。请检查：

   • **领域归属不当：**某项要求实际属于独立的评估维度（参见“决定粒度的原则”），却被埋在不相关标准的子标准中 → 将其提升为独立标准并重新调整权重。
   • **子标准权重分配不当：**某项重要子标准在大型标准中的 peso 较小，未体现其在题目要求中的实际权重（例如，题目要求中的权重不同，却进行了平均分配）→ 重新调整各子标准之间的权重（总和必须等于该标准的 peso）。
   • **未细分的剩余项：**某项大型标准只有一个子标准，且该子标准吸收了全部 peso，但实际上它包含多项相互独立的要求，宜拆分为多个各自拥有 peso 的子标准，以便评分者能够更细致地评分。

4. 凭空编造的内容。 评分标准中有、但 TP 中完全没有依据的标准、加分项或规则。删掉它们。评分标准不能比任务要求更宽松或更严格，必须忠实反映任务要求。（注意双重风险：也不要加入评阅者仅凭收到的提交内容无法核实的证据——例如“提交了视频”“仓库是公开的”——这属于臆造。如果无法通过收到的材料核实，就不能作为可评分的证据。）

5. 视觉元素。 如果 TP 中有对评估很重要的图片、表格或示意图，而评分标准没有用文字体现，请将它们纳入。

6. 整合模式。 检查评分标准使用的 modo_consolidacion（如果没有，后端会默认使用 solo_codigo），并确认该模式涵盖证据所需读取的所有文件扩展名（见 references/limites-corrector.md 中的表格）。如果发现某项证据依赖的文件扩展名不受当前模式支持——典型情况是要求检查 README.md，但模式为 solo_codigo，不包含 .md——这就是与缺少评分标准同样严重的结构性遗漏：评阅者永远不会读取该文件，无论证据写得多好。请提高模式（web_completo/proyecto_completo），或改为 personalizado 并指定确切的扩展名，同时在问题发现中报告。

7. 调整权重。 如果你新增、删除或合并了评分标准（包括迁移步骤 0），请重新计算 peso，使总和恰好为 100，且每项评分标准的子标准权重之和等于该评分标准的 peso。遵循任务要求所体现的相对重要性。

8. 使用脚本验证。

9. 按输出格式提交（包括问题发现摘要）。

---

TEST 模式 — 模拟评阅

有效的评分标准不一定能保证评阅效果好。TEST 模式可以弥补这一点：针对一份具体提交进行实际评阅，并展示分数和反馈，让你在上传之前确认评分标准能否区分出应当区分的内容。

该模式会复现系统流程（代码整合 + 评阅提示词），但会通过 Claude CLI 执行评阅，而不是使用 N8N→Gemini。Claude 会替代生产环境中的模型；结果仅供参考（使用的是另一个模型），不会与 Gemini 最终给出的分数完全一致，但有助于发现评分标准的问题。

python scripts/simular_correccion.py \
  --rubrica <rubrica.json> \
  --entrega <archivo|carpeta|.zip|.txt> \
  --materia "Nombre de la materia" \
  --alumno  "Nombre del alumno" \
  --modo solo_codigo            # o web_completo | proyecto_completo | personalizado

• 如果评分标准的 JSON 已包含 modo_consolidacion（现在 CREAR/AUDITAR 生成的内容就包含），则 --modo 可选：脚本会直接从 JSON 中读取。只有在要强制使用不同于评分标准所设模式时，才手动传入。
• --no-run 会准备材料并打印命令，但不执行 claude（便于检查模型将收到的 prompt_correccion.txt）。
• 如果评分标准是没有 tipo 字段的 CriteriosStructure，请使用 --tipo TP。
• --modo personalizado 时使用 --ext ".ipynb,.sql"（如果 JSON 中已有 extensiones_personalizadas，也可以让脚本直接读取）。
• 脚本会保存 prompt_correccion.txt（确切材料）和 correccion.json（结果）。

如何解读结果。 脚本会根据评分标准验证评阅结果，并在出现以下情况时发出提示：某项标准未被评估、某项得分超过其权重、总分不符，或使用了不存在的扣分项/条件。但更重要的是你自己的判断：分数是否反映了提交的实际质量？反馈是否引用了具体证据？是否有评分标准含糊不清，导致模型犹豫？如果结果不理想，通常需要改进评分标准（描述含糊、证据无法核实、权重分配不合理）——返回 CREAR/AUDITAR 并重新测试。

校正器读取的内容（设计评分标准时的重要事项）

校正会使用完整的评分标准：每项标准都包含 id、nombre、 peso、descripcion、instrucciones_puntuacion 和带有相应证据的 子标准，以及 penalizaciones、condiciones_desaprobacion 和 metadata。 因此，证据很重要：它们是模型要核对的清单。

在 v2 中，还会传入每个子标准的 peso，校正结果会按标准给出 subcriterios_evaluados 明细（每个子标准的得分、状态和反馈，其总和必须等于 该标准的 puntaje_obtenido）。在 v1 中，子标准没有 peso，响应中也没有 subcriterios_evaluados——与以往相同。scripts/simular_correccion.py 会像验证器一样 根据子标准中是否存在 peso 推断版本，并相应调整提示词和结果验证。

稳健性建议：每项标准的 descripcion 都应独立完整——概述其证据所核验的内容——这样即使某个集成传入的上下文少于预期，校正也能正常运行。

---

必须进行验证

提交任何评分标准前，先保存 JSON 并运行：

python scripts/validar_rubrica.py <ruta_al_json>

（或者运行 python scripts/validar_rubrica.py -，从标准输入读取）

该脚本复现了真实后端的规则：验证通过，系统就会接受评分标准；验证失败，它会明确告诉你需要修正什么（权重总和、ID、模式、空证据、nota_final 与 nota_maxima 等）。**未经验证器确认有效，不要提交评分标准。**如果验证失败，请修正后重新运行。这样成本很低，还能避免被后端驳回。

验证器支持 v1 和 v2，并根据子标准中是否存在 peso 推断版本（与 Active-IA 前端相同）——无需传入 schema_version。v2 要求每个子标准都包含 peso，且权重总和必须与所属标准的 peso 完全相等；v1 则无此要求。如果需要强制指定版本（例如明确测试 v1 的行为），请使用 --schema-version 1|2。

输出格式

请始终按以下顺序提交：

1.（仅在 AUDITAR 时）发现摘要——放在 JSON 前，简要说明：

## Hallazgos
- Migración v1→v2: <"la rúbrica ya era v2, sin cambios" | mapeo
  "criterio/subcriterio v1 → dónde quedó en v2" con cada fusión y su peso
  heredado | "no aplica">
- Verificación de completitud: <"OK, todo el contenido v1 está presente en
  el v2" | qué faltaba y se agregó>
- Contradicciones: <qué y dónde, o "ninguna">
- Omisiones: <qué requisitos faltaban, o "ninguna">
- Invenciones: <qué se quitó, o "ninguna">
- Modo de consolidación: <"OK, cubre todas las evidencias" | qué extensión faltaba
  cubrir y a qué modo se subió>
- Ajuste de pesos: <cómo quedó el reparto>

2. CriteriosStructure JSON——放在 ```json 代码块中，可直接粘贴到 “Cargar criterios”按钮中（或编辑弹窗中：两者都已支持 Active-IA 的可移植 JSON）。包含：titulo、descripcion、puntaje_maximo、 metadata、criterios、penalizaciones、condiciones_desaprobacion，以及始终包含 modo_consolidacion——如果 modo_consolidacion 为 "personalizado"，还需包含 extensiones_personalizadas（否则省略或设为 null）。这个字段以前会在复制/粘贴 JSON 时丢失：现在它会随评分标准一起传递，表单也会自动填入。不要包含 schema_version：它是评分标准负载之外的独立字段（与 tipo/numero/anio 一样），不属于 CriteriosStructure。评分标准是否为 v2，由每个子标准中的 peso 标记——Active-IA 前端会自动推断。

3. 表单字段——实例身份信息，而非内容；不放入 JSON，需单独填写：

Para completar en el formulario de la rúbrica:
- tipo: <TP | PARCIAL_1 | ... según la consigna>
- numero: <ej: 2 para el TP2>
- anio: <año académico>
(materia_id lo elegís vos según la materia)

4. 验证器确认——粘贴“✅ RÚBRICA VÁLIDA”这一行。

请将 assets/ejemplo-rubrica.json 作为完整且有效的 v2 评分标准范例（每个子标准都带有 peso，并且正确选择了 modo_consolidacion——该示例使用 proyecto_completo，因为其中一项标准会评估 README.md，而 solo_codigo/web_completo 不包含 .md）。为保持向后兼容，examples/rubrica-tp-cli-v1.json 是 v1 范例（子标准不带 peso）。

会毁掉评分标准的错误（避免这些错误）

• 权重总和不等于 100——这是最常见的错误；验证器会发现，但请从分配权重的角度仔细检查。
• 证据主观，或要求提供提交内容之外的信息（“排版很整洁”）。
• 编造题目要求中没有提及的扣分项／条件。
• 让作业要求没有任何标准覆盖。
• 重要要求被弱化：把一个独立的评估领域／维度埋在不相关标准的子标准中，而不是单独设为标准（参见“决定粒度的原则”）。
• （v2）子标准缺少 peso，或其权重总和与父级标准的 peso 不一致——验证器会发现，但请从分配权重的角度仔细检查（如果题目要求中没有明确权重，就使用 Hamilton 法）。
• 过度拆分：把琐碎内容拆成许多 1–2 分的标准，会削弱权重的区分度，让评分标准变得冗杂。应按实际影响力拆分，而不是吹毛求疵。
• 使用 nota_final 而不是 nota_maxima，或为每项标准使用 puntaje_maximo 而不是 peso（这是已经废弃的 V1 模型）。
• 把 materia_id/tipo/numero/anio 放进标准 JSON：这些字段应放在表单中，而不是导入的 JSON 中。
• 选择的 modo_consolidacion 未涵盖证据本身所需的文件扩展名（例如，针对 README.md 的证据却使用 solo_codigo 模式，而该模式不包含 .md 文件）——这会让证据形同虚设：评分者永远不会阅读该文件。务必按照 CREAR 的第 4 步／AUDITAR 的第 6 步进行交叉检查。