企业官网建设流程全解析

Content Curation Rubric 实战指南：用 LLM-as-a-Judge 为 Agent-Skills-for-Context-Engineering 研究管线把守内容准入

【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering

本篇技术指南讲解 Agent-Skills-for-Context-Engineering 仓库中researcher/rubrics/content-curation.md这份内容策展评分卡：它以 LLM-as-a-Judge 的方式决定一个外部来源是否有资格进入研究管线，并通过四道硬门控（Gatekeeper Triage）、四维加权评分（Dimensional Scoring）、明确的决策阈值与覆盖规则（Overrides），把"这段内容值不值得沉淀成 Agent Skill"这一模糊判断转化为可复现、可审计的确定性流程。读完本文，你将掌握这套评分卡的完整规则、加权计算公式、机器可读输出 JSON 的字段语义，以及它如何与research_loop.py、validate_run.py和 skill-change 评分卡衔接，形成从"来源发现"到"技能落库"的闭环。

这套评分卡要解决的问题

在 researcher/llm-as-a-judge.md 描述的自主研究循环中，Agent 会不断从外部发现文章、代码仓库、论文等候选来源，而真正需要的是可实现（Implementable）的工程原语——那些能直接编码进可复用 Skill 的具体模式，而不是"有趣的泛泛之谈"。如果缺少统一标准，会出现两类失控：一是把空洞的营销文章混入语料库，二是把高价值但证据不足的来源直接丢弃。

Content Curation Rubric 正是为解决这一"门控歧义"而存在。文档开篇即点明其职责：它提取了researcher/llm-as-a-judge.md中的可复用策略，并解决了门控判定歧义——任何一道门失败即拒绝（REJECT）该来源，除非人工显式覆盖（override）。这意味着评分卡不是"打几分取平均"的宽松筛选，而是一条"先过门、再打分、后裁决"的刚性流水线。

Gatekeeper Triage：四道不可妥协的硬门

所有候选来源必须先通过四道二元门控（Pass/Fail），全部通过后才能进入维度打分。任何一门失败，立即记录REJECT并附带失败门编号，终止后续流程——不进入评分阶段。

这套门控对应 researcher/llm-as-a-judge.md 中 EVALUATION_RUBRIC.md 的 PART 1（GATEKEEPER TRIAGE）设计，其中对 G1 给出了更细的示例化判定标准：例如"带压缩比的递归摘要""XML 结构化工具响应""基于检查点的状态持久化""带元数据的分面检索"属于具体机制，而"提升准确性""更好的提示词""AI 最佳实践"这类未说明机理的措辞则判为失败。G4 的"技术可信"参考了顶级 AI 实验室的生产工程博客（如 Anthropic、Google、Vercel 等）、同行评审论文、有公开代码贡献的公认从业者；匿名来源与伪装成技术写作的营销内容直接出局。

值得注意的是门控判定的不确定性处理原则：无法确定某门是否通过时，默认按失败处理（Default to FAIL），这与 researcher/llm-as-a-judge.md 中"UNCERTAINTY HANDLING"章节保持一致——门控是刚性约束，宁严勿松。

Dimensional Scoring：四维加权评分

通过全部门控后，对四个维度分别按 0、1、2 三分制打分。仓库 rubric 给出的是简洁版判定标准，researcher/llm-as-a-judge.md 的 PART 2 则提供了每个维度"2=Excellent / 1=Acceptable / 0=Poor"的完整判据与示例指标，二者必须配合使用。

加权总分计算公式

weighted_total = D1*0.35 + D2*0.30 + D3*0.20 + D4*0.15

满分 2.0。公式与 researcher/llm-as-a-judge.md 中的total_score = (D1 × 0.35) + (D2 × 0.30) + (D3 × 0.20) + (D4 × 0.15)完全一致，且其输出 schema 要求同时给出weighted_total与calculation_shown（如(2×0.35) + (2×0.30) + (1×0.20) + (2×0.15) = 1.85），确保每一分都有据可查。

一个直观的权重意义：D1 权重最高（35%），因为管线的使命是沉淀"可直接实现的工程原语"；若内容再炫酷却无法落地实现，对技能库毫无价值。D4 权重最低（15%），但也保留了"反直觉发现/高价值失败模式"的上浮空间——这与 researcher/llm-as-a-judge.md 中"不要拒绝负面结果，失败的实验同样有价值"的偏见规避原则呼应。

决策阈值与四条覆盖规则

加权总分计算完成后，按以下条件裁决：

此外还有四条覆盖规则（Overrides），用于在特定边界条件下强制改变裁决，即使常规阈值判定与之相反：

• O1：D1 = 0 → 强制REJECT（没有实现路径，直接否决）；
• O2：D2 = 0 → 强制REJECT（与仓库完全无关，直接否决）；
• O3：D3 = 1 且总分 >= 1.4 → 强制HUMAN_REVIEW（内容价值高但证据严谨性存疑，必须人工核验声明是否可复现）；
• O4：D4 = 2 且总分 < 1.4 → 强制HUMAN_REVIEW（可能存在突破性洞见，交由人工把关，避免误杀）。

这一套"阈值 + 覆盖"双轨设计，让高价值但证据不足的来源不会被直接拒绝，也不会让看似高分但零实现路径的来源蒙混过关。

Required Evidence：每个通过来源必须附带的五类证据

无论 APPROVE 还是进入人工复核，评分卡都要求对来源附上完整证据链，防止"凭印象放行"：

1. 检索来源 URL 与检索状态（retrieved / partial / failed）；
2. 针对每一道通过的门控，给出具体的引用或转述证据——即"G1 通过，因为……"这样的逐条对应；
3. 一段话的机制总结（mechanism summary）；
4. 候选技能影响评估：新建技能、更新现有技能、仅作参考、或拒绝；
5. 已知局限、缺失证据或假设。

其中第 4 项直接对应 researcher/llm-as-a-judge.md 中的 SKILL EXTRACTION 环节：对 APPROVE 的来源，还需输出技能名（VerbNoun 命名，如PersistAgentStateWithFiles）、所属上下文工程分类（context_retrieval / context_processing / context_management / rag / memory / tool_integration / multi_agent）、实现类型（prompt_template / code_pattern / architecture / evaluation_method）与预估复杂度（low / medium / high）。

Output Shape：机器可读的 JSON 输出与兜底策略

评分卡要求使用 researcher/templates/source-evaluation.json 模板输出机器可读的结果。该模板定义了严格的字段结构：

• evaluation_id（uuid-v4）与timestamp（ISO-8601）；
• source块：url、title、author_or_org、published_at、source_type（paper / engineering_blog / documentation / benchmark / code / talk / other）、retrieval_status（retrieved / partial / failed）、primary_or_secondary；
• gatekeeper块：G1~G4 各自的pass布尔值与evidence文本，以及总verdict（PASS / REJECT）和rejection_reason；
• scoring块：D1~D4 各自的reasoning与score，以及weighted_total和calculation_shown；
• decision块：verdict、override_triggered（O1~O4 或 null）、confidence、justification；
• extraction块：mechanism、implementable_artifacts、failure_modes、candidate_skill_target（new skill / existing skill / reference only / reject）、candidate_skill_name、taxonomy_category、estimated_complexity；
• human_review_notes。

关键兜底策略：如果模型无法产出合法 JSON，评分卡明确要求——记录原始输出并转人工复核（route to human review），而不是静默修复评估结果。这一"失败不可怕、掩盖失败才可怕"的原则，与 researcher/llm-as-a-judge.md 中"只输出合法 JSON，不得输出额外评论"的输出契约互为表里。

仓库中的真实执行样本：从示例 fixture 看规则如何落地

researcher/fixtures/source-evaluations/ 目录提供了两个可直接对照的评估实例，是理解规则动态行为的最佳教材。

示例一：全门通过但触发 O3 覆盖的 HUMAN_REVIEW

approved-harness-source.json 评估了一个"可执行的自主研究框架"来源（Karpathy autoresearch program 的公开仓库）：

• 门控全部 PASS：G1 证据为"定义了带可编辑/锁定文件的自主实验循环这一具体机制"，G2 证据为"提供了 program.md 指令、命令循环、结果日志与回滚策略"，G3 覆盖"长时自主实验、指标完整性、失败处理"，G4 为"可验证研究者维护的公开仓库"；
• 四维打分：D1=2（可直接用 git、训练命令与结果解析实现）、D2=2（直接指导 harness 工程）、D3=1（有可运行代码与锁定指标，但缺少广泛对比证据）、D4=2（"受限可编辑面"框架是有用的运作模型）；
• 加权计算：(2*0.35) + (2*0.30) + (1*0.20) + (2*0.15) = 1.8；
• 按常规阈值 1.8 >= 1.4 本应 APPROVE，但D3=1 且总分 >= 1.4 触发 O3，强制转为 HUMAN_REVIEW，人工复核备注为"用作通过门控但仍需人工复核（经 O3）来源的 fixture"。

这个例子生动展示了覆盖规则的设计意图：来源极有价值，但证据严谨性只有 1 分，不能仅凭总分高就自动入库。

示例二：四门全败的直接 REJECT

rejected-generic-source.json 评估了一个匿名"Ten AI Tips"来源：

• G1~G4 全部失败：无具体机制、无任何制品、只有基础建议、作者无法验证，rejection_reason为"Failed all content gates"；
• 四维全部 0 分，加权总分 0，裁决 REJECT，且不进入任何技能提取（candidate_skill_target = reject）；
• 与 researcher/llm-as-a-judge.md 中 PART 6 的 Example B（"10 Prompt Engineering Tips" Medium 文章四门全败）形成双重印证——这正是评分卡要拦截的典型低质输入。

在仓库中的工程化落地：锁定面、状态机与发布校验

Content Curation Rubric 不是一份"仅供参考"的文档，而是被仓库的自动化脚本硬编码为不可篡改的约束。

1. 作为锁定面（Locked Surface）受保护。在 researcher/scripts/research_loop.py 的LOCKED_SURFACES列表中，researcher/rubrics/content-curation.md与 skill-change、harness-change 评分卡、机制注册表、校验脚本一同被标记为锁定面——运行状态机（run-state.json）会记录这些锁定面，自治 Agent 只能在其可编辑面（sources/、proposals/、reports/、logs/）内操作，不得改动评分标准本身。每次运行创建的 THREAD.md 也会显式列出该锁定面清单。

2. 生成评估脚手架。同一脚本的create_source_evaluation()会从 researcher/templates/source-evaluation.json 加载模板，生成一份source-evaluation-draft.json：默认retrieval_status为 partial（未提供 URL 则为 failed），裁决预设为HUMAN_REVIEW（confidence: low，justification 注明"Draft scaffold. Complete gates and scoring after retrieval."），四门默认全部 fail、四维默认 0 分——即草稿状态下不默许放行任何来源，必须由后续检索与评分填实。仓库真实运行产物 source-evaluation-draft.json 正是这一脚手架的实际形态。

3. 发布就绪校验强制执行规则。researcher/scripts/validate_run.py 的validate_source_evaluation()是评分卡的执行校验器：它要求已完成的评估文件必须存在（仅有 draft 则报错）、retrieval_status必须为retrieved（发布就绪的运行不允许 partial/failed）、裁决为 REJECT 的来源不允许产出发布就绪的变更。同时validate_state()强制检查锁定面清单中必须包含researcher/rubrics/content-curation.md。也就是说，一份评估只有经过"检索成功 + 未被拒绝"的双重校验，才能继续流向技能提案。

4. 与下游 skill-change 评分卡衔接。内容策展只是第一关。来源通过 curation 后，researcher/rubrics/skill-change.md 会用 S1~S5 五道硬门（独特激活场景、可实现的指导、语料适配、证据可追溯、维护者负担）与另一套加权维度（Actionability 30% / Relevance 25% / Non-Duplication 20% / Evidence 15% / Skill Ergonomics 10%，同样要求加权总分 >= 1.4 且无硬门失败）来决定提取出的机制是否真正落入SKILL.md语料、是新建技能还是更新既有技能。两套评分卡形成"先审来源、再审变更"的两级闸门。

使用这套评分卡的实践要点

• 把门控当开关，不要当打分项：G1~G4 是 Pass/Fail 的硬门，任何一门失败立即 REJECT，绝不进入评分阶段；不确定时默认判失败。
• 给每一道门和每一个维度写证据：输出 schema 中的evidence、reasoning字段就是为此设计，引用具体内容（如"定义了 init.sh 模式、checkpoint 机制、progress.txt schema"）而不是空泛评价。
• 让覆盖规则显式化：每次触发 O1~O4 都要在override_triggered中注明，并附human_review_notes说明人工复核的具体关注点（如验证基准方法学、检查 3 层记忆架构是否可泛化）。
• 严格遵守 JSON 输出契约：机器可读输出失败时记录原始结果并转人工，不要静默修复。
• 用 fixture 校准判断：approved-harness-source.json 与 rejected-generic-source.json 分别对应"高分但需人工复核"与"四门全败"两种典型走向，可作为新评估的对照基准。

总而言之，Content Curation Rubric 把"这篇内容值不值得沉淀成 Agent Skill"这一主观判断，重构成了一条由硬门控、加权评分、阈值裁决、覆盖规则、证据要求与机器可读输出共同组成的确定性流水线。它既能在自主研究循环中拦截低质输入，又能保护高价值但证据不足的来源不被误杀——这正是 researcher/llm-as-a-judge.md 所倡导的"以 LLM 为裁判"思路在工程落地时的完整形态。

【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering