LifeOS Fabric arbiter-evaluate-quality基于理想参照输出的提示词输出质量仲裁模式【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本篇技术指南以 LifeOS 的 Fabric 技能中的arbiter-evaluate-quality模式文件为主体完整解析这一对照理想输出ideal为候选输出打分裁决的提示词模式它的变量契约、两步执行流程以及它依赖的 GEGeneral Evaluator评分引擎如何定义多轴评分与最终裁决规则。读完本文你可以理解 LifeOS 中提示词 A/B 评测这条仲裁流水线arbiter 系列模式的完整数据流并知道如何在 Fabric 的原生模式执行机制下调用该模式对两组候选输出做可复现的质量比较。一、模式定位arbiter 家族中的裁决器arbiter-evaluate-quality是 LifeOS Fabric 技能下 240 提示词模式prompt pattern之一其定义文件位于 system.md。该模式文件开头即给出了一句话定位Pattern: Use GE to score and compare candidate outputs.模式使用 GE 对候选输出进行评分与比较。从源码结构看Fabric 技能在 Patterns/ 目录下按一个模式一个目录、目录内含system.md的结构组织所有模式其中与arbiter-evaluate-quality同族的还有三个模式共同构成一条完整的提示词输出质量仲裁流水线模式文件在流水线中的职责arbiter-run-promptsystem.md用给定提示词对输入跑一次生成落盘原始 JSON 输出arbiter-create-idealsystem.md调用 GE 起草理想提示词 ideal_promptarbiter-general-evaluatorsystem.mdGE 本体评分引擎定义评分轴、量表与裁决规则arbiter-evaluate-qualitysystem.md本篇主角拿到三份 JSON 输出后打分并裁决 overall_winner另外Research 技能的 Fabric 工作流目录中也把arbiter-evaluate-quality登记为 Quality evaluation 类模式见 Fabric.md说明该模式在 LifeOS 中是被跨技能复用的评测件而非孤立脚本。二、模式完整定义变量契约与执行流程下面完整继承模式文件 system.md 的核心内容标题为 EVALUATE OUTPUTS AGAINST IDEAL。2.1 变量契约该模式声明了三个以#前缀命名的输入变量全部是JSON 文件#output1运行 prompt1 得到的 JSON 输出文件#output2运行 prompt2 得到的 JSON 输出文件#ideal运行 ideal_prompt 得到的 JSON 输出文件即理想参照输出。这三个变量名与上游模式严格对应#output1/#output2来自arbiter-run-prompt对两个候选提示词prompt1、prompt2各跑一次的产物#ideal则来自对arbiter-create-ideal产出的 ideal_prompt 再跑一次生成的产物。变量契约本身就规定了该模式的输入边界——它不接收原始任务文本只接收三份已经生成完毕的结构化输出。2.2 执行流程Instructions 原文语义模式文件给出的完整流程只有两步加载三份输出载入 output1、output2 与 ideal 三份输出并且剥离元数据strip metadata。这一步意味着后续比较的是纯内容载荷而不是把各次运行附带的运行时元信息纳入评分。应用 GE 完成三件事计算多轴分数clarity、completeness、creativity即清晰度、完整度、创造性对每一个分数给出依据justify each score将overall_winner 判定为最接近 ideal 的那份输出——注意裁决标准是相对理想参照的距离而不是两份候选之间的绝对高低。这里有两个关键设计点值得注意评分轴是可读的业务轴不是笼统的 0-100 单分。模式明确列出 clarity / completeness / creativity 三轴与 GE 模式中至少三个维度的要求一致见下节贴近理想是相对裁决。overall_winner 的语义是 the output closest to ideal即候选输出与 ideal 输出的接近程度决定胜负。这使评测具备了明确锚点不需要评测者凭空定义什么是好而是先由 GE 从任务本身提炼出理想提示词并跑出参照输出再以此为准绳。三、GEGeneral Evaluator该模式依赖的评分引擎arbiter-evaluate-quality的每一步Apply GE都指向 arbiter-general-evaluator/system.md。对照该文件可以还原裁决阶段实际执行的规则提取底层任务从用户输入与候选提示词中用一句话概括核心任务或用户需求起草理想提示词仅基于该任务概括忽略各提示词的既有偏见起草最能达成用户目标的提示词即 ideal_prompt——这是#ideal参照输出的来源质量量规Quality Rubric定义至少三个维度的量规示例即 clarity、completeness、creativity对每份候选输出与 GE 自身输出在 0–100 分制上打分分数解释每个维度给出 1–2 句的打分依据总体裁决比较各输出与 ideal_output 的距离宣告总体最佳者并附简短理由。GE 还规定了两种重要的执行约束输出格式契约评估 bundle 时必须使用固定格式输出各 bundle 分数**Bundle 1 Score**: [0-100]等逐行列出确定性设置所有评测器调用必须使用确定性参数——temperature0, top_p1。这一点与arbiter-evaluate-quality的裁决场景直接相关同一份输入重复评测应得到可比的结果否则overall_winner就不具备复现意义。因此arbiter-evaluate-quality的第二步多轴打分、逐分依据、以接近度裁决 overall_winner本质上是 GE 指令中第 3–5 步在已有三份输出文件场景下的特化调用GE 无需再现场生成候选输出只需对既定的 output1 / output2 / ideal 执行量规打分与距离比较。四、三份 JSON 输入从哪来完整数据流把四个 arbiter 模式串起来该裁决模式的输入产生链路如下各环节均以其模式文件的 Instructions 为依据prompt1 ──┐ ┌── output1 (#output1) ├─ arbiter-run-prompt ────────────────┤ prompt2 ──┘ └── output2 (#output2) prompt1 prompt2 input │ ├─ arbiter-create-ideal ── ideal_promptGE 起草输出到 stdout │ └─ arbiter-run-prompt(ideal_prompt) ── ideal 输出 (#ideal) #output1 #output2 #ideal │ └─ arbiter-evaluate-quality ── 多轴分数 依据 overall_winner各环节细节arbiter-run-prompt/system.md 定义了单份候选输出的生成方式变量为#prompt提示词 markdown 文件路径与#input输入数据路径流程为把#prompt内容作为 system 提示载入、以 user 角色喂入#input、用默认生成设置调用所选模型最后把原始 JSON 响应保存到指定输出路径。这正是#output1/#output2/#ideal三个JSON 文件约定的来源arbiter-create-ideal/system.md 定义了理想提示词的生成方式变量为#gegeneral-evaluator 文件路径、#prompt1、#prompt2、#input执行时把 prompt1、prompt2 的原始文本与 input 描述交给 GEGE 按自身指令先提取任务再起草 ideal_prompt且只把 ideal_prompt 的 markdown 内容输出到 stdout。从源码结构看这条流水线的分工是清晰的生成由 run-prompt 负责理想化由 create-ideal GE 负责裁决由 evaluate-quality 负责——本篇聚焦的裁决模式只消费前三步的产物本身不触发任何模型生成调用职责单一、输入输出边界明确。五、在 LifeOS 中的执行方式Fabric 原生模式执行Fabric 技能见 SKILL.md的执行模型是原生模式执行LifeOS 直接读取Patterns/{pattern_name}/system.md并将其内容作为提示词指令应用无需外部 CLI 往返fabric命令仅用于 YouTube 转录-y与 URL 兜底抓取-u两类场景。对应到arbiter-evaluate-quality的调用路径可参考 ExecutePattern.md 工作流的步骤从用户意图选定模式名模式名必须精确arbiter-evaluate-quality不能写成缺下划线的变体读取该模式的 system.md工作流中给出的运行时路径形如~/.claude/skills/Fabric/Patterns/$PATTERN_NAME/system.md仓库内 Patterns/ 为安装源用户机器上的~/.claude/skills/...为安装后的运行时位置二者内容同源直接应用模式指令加载#output1、#output2、#ideal三个 JSON 文件、剥离元数据按 GE 量规打分并给出 overall_winner。由于该模式的输入是文件路径变量而非文本内容调用时的实际交互就是提供三个 JSON 文件路径模式自身会完成加载与比较模式不定义额外的落盘动作结果分数、依据、overall_winner直接返回给调用方。六、实践要点与适用边界基于上述模式文件与 GE 定义使用该模式时应注意以下由仓库内容直接支撑的约束输入必须是 JSON 文件。变量契约为三个 JSON 路径如果候选输出尚未落盘需先经arbiter-run-prompt生成否则不满足该模式的前置条件。剥离元数据是显式流程步骤。三份输出中任何运行时元信息都应在比较前剔除保证评分只针对内容载荷这是模式 Instructions 第 1 步的原文要求。裁决是相对裁决。overall_winner 定义为最接近 ideal 的输出当 two 份候选与 ideal 距离接近时模式并未定义平局处理规则可推断需由 GE 的第 5 步距离比较 简短理由给出裁决理由使用时应要求裁决结论附带理由文本。评测需确定性参数。GE 文件明确要求评测器调用使用temperature0, top_p1arbiter-evaluate-quality既然整体Apply GE该约束同样适用于其打分环节这是评测结果可复现的前提。评分轴与量表有明确下限。GE 要求量规至少三个维度、0–100 分制、每维度逐分给据arbiter-evaluate-quality默认给出的三轴clarity、completeness、creativity即为满足该下限的标准配置。七、相关文件索引模式本体LifeOS/install/skills/Fabric/Patterns/arbiter-evaluate-quality/system.md评分引擎 GELifeOS/install/skills/Fabric/Patterns/arbiter-general-evaluator/system.md上游生成LifeOS/install/skills/Fabric/Patterns/arbiter-run-prompt/system.md、LifeOS/install/skills/Fabric/Patterns/arbiter-create-ideal/system.mdFabric 技能说明与原生执行机制LifeOS/install/skills/Fabric/SKILL.md模式执行工作流LifeOS/install/skills/Fabric/Workflows/ExecutePattern.md模式目录总览LifeOS/install/skills/Fabric/Patterns/【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LifeOS Fabric arbiter-evaluate-quality：基于“理想参照输出“的提示词输出质量仲裁模式
LifeOS Fabric arbiter-evaluate-quality基于理想参照输出的提示词输出质量仲裁模式【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本篇技术指南以 LifeOS 的 Fabric 技能中的arbiter-evaluate-quality模式文件为主体完整解析这一对照理想输出ideal为候选输出打分裁决的提示词模式它的变量契约、两步执行流程以及它依赖的 GEGeneral Evaluator评分引擎如何定义多轴评分与最终裁决规则。读完本文你可以理解 LifeOS 中提示词 A/B 评测这条仲裁流水线arbiter 系列模式的完整数据流并知道如何在 Fabric 的原生模式执行机制下调用该模式对两组候选输出做可复现的质量比较。一、模式定位arbiter 家族中的裁决器arbiter-evaluate-quality是 LifeOS Fabric 技能下 240 提示词模式prompt pattern之一其定义文件位于 system.md。该模式文件开头即给出了一句话定位Pattern: Use GE to score and compare candidate outputs.模式使用 GE 对候选输出进行评分与比较。从源码结构看Fabric 技能在 Patterns/ 目录下按一个模式一个目录、目录内含system.md的结构组织所有模式其中与arbiter-evaluate-quality同族的还有三个模式共同构成一条完整的提示词输出质量仲裁流水线模式文件在流水线中的职责arbiter-run-promptsystem.md用给定提示词对输入跑一次生成落盘原始 JSON 输出arbiter-create-idealsystem.md调用 GE 起草理想提示词 ideal_promptarbiter-general-evaluatorsystem.mdGE 本体评分引擎定义评分轴、量表与裁决规则arbiter-evaluate-qualitysystem.md本篇主角拿到三份 JSON 输出后打分并裁决 overall_winner另外Research 技能的 Fabric 工作流目录中也把arbiter-evaluate-quality登记为 Quality evaluation 类模式见 Fabric.md说明该模式在 LifeOS 中是被跨技能复用的评测件而非孤立脚本。二、模式完整定义变量契约与执行流程下面完整继承模式文件 system.md 的核心内容标题为 EVALUATE OUTPUTS AGAINST IDEAL。2.1 变量契约该模式声明了三个以#前缀命名的输入变量全部是JSON 文件#output1运行 prompt1 得到的 JSON 输出文件#output2运行 prompt2 得到的 JSON 输出文件#ideal运行 ideal_prompt 得到的 JSON 输出文件即理想参照输出。这三个变量名与上游模式严格对应#output1/#output2来自arbiter-run-prompt对两个候选提示词prompt1、prompt2各跑一次的产物#ideal则来自对arbiter-create-ideal产出的 ideal_prompt 再跑一次生成的产物。变量契约本身就规定了该模式的输入边界——它不接收原始任务文本只接收三份已经生成完毕的结构化输出。2.2 执行流程Instructions 原文语义模式文件给出的完整流程只有两步加载三份输出载入 output1、output2 与 ideal 三份输出并且剥离元数据strip metadata。这一步意味着后续比较的是纯内容载荷而不是把各次运行附带的运行时元信息纳入评分。应用 GE 完成三件事计算多轴分数clarity、completeness、creativity即清晰度、完整度、创造性对每一个分数给出依据justify each score将overall_winner 判定为最接近 ideal 的那份输出——注意裁决标准是相对理想参照的距离而不是两份候选之间的绝对高低。这里有两个关键设计点值得注意评分轴是可读的业务轴不是笼统的 0-100 单分。模式明确列出 clarity / completeness / creativity 三轴与 GE 模式中至少三个维度的要求一致见下节贴近理想是相对裁决。overall_winner 的语义是 the output closest to ideal即候选输出与 ideal 输出的接近程度决定胜负。这使评测具备了明确锚点不需要评测者凭空定义什么是好而是先由 GE 从任务本身提炼出理想提示词并跑出参照输出再以此为准绳。三、GEGeneral Evaluator该模式依赖的评分引擎arbiter-evaluate-quality的每一步Apply GE都指向 arbiter-general-evaluator/system.md。对照该文件可以还原裁决阶段实际执行的规则提取底层任务从用户输入与候选提示词中用一句话概括核心任务或用户需求起草理想提示词仅基于该任务概括忽略各提示词的既有偏见起草最能达成用户目标的提示词即 ideal_prompt——这是#ideal参照输出的来源质量量规Quality Rubric定义至少三个维度的量规示例即 clarity、completeness、creativity对每份候选输出与 GE 自身输出在 0–100 分制上打分分数解释每个维度给出 1–2 句的打分依据总体裁决比较各输出与 ideal_output 的距离宣告总体最佳者并附简短理由。GE 还规定了两种重要的执行约束输出格式契约评估 bundle 时必须使用固定格式输出各 bundle 分数**Bundle 1 Score**: [0-100]等逐行列出确定性设置所有评测器调用必须使用确定性参数——temperature0, top_p1。这一点与arbiter-evaluate-quality的裁决场景直接相关同一份输入重复评测应得到可比的结果否则overall_winner就不具备复现意义。因此arbiter-evaluate-quality的第二步多轴打分、逐分依据、以接近度裁决 overall_winner本质上是 GE 指令中第 3–5 步在已有三份输出文件场景下的特化调用GE 无需再现场生成候选输出只需对既定的 output1 / output2 / ideal 执行量规打分与距离比较。四、三份 JSON 输入从哪来完整数据流把四个 arbiter 模式串起来该裁决模式的输入产生链路如下各环节均以其模式文件的 Instructions 为依据prompt1 ──┐ ┌── output1 (#output1) ├─ arbiter-run-prompt ────────────────┤ prompt2 ──┘ └── output2 (#output2) prompt1 prompt2 input │ ├─ arbiter-create-ideal ── ideal_promptGE 起草输出到 stdout │ └─ arbiter-run-prompt(ideal_prompt) ── ideal 输出 (#ideal) #output1 #output2 #ideal │ └─ arbiter-evaluate-quality ── 多轴分数 依据 overall_winner各环节细节arbiter-run-prompt/system.md 定义了单份候选输出的生成方式变量为#prompt提示词 markdown 文件路径与#input输入数据路径流程为把#prompt内容作为 system 提示载入、以 user 角色喂入#input、用默认生成设置调用所选模型最后把原始 JSON 响应保存到指定输出路径。这正是#output1/#output2/#ideal三个JSON 文件约定的来源arbiter-create-ideal/system.md 定义了理想提示词的生成方式变量为#gegeneral-evaluator 文件路径、#prompt1、#prompt2、#input执行时把 prompt1、prompt2 的原始文本与 input 描述交给 GEGE 按自身指令先提取任务再起草 ideal_prompt且只把 ideal_prompt 的 markdown 内容输出到 stdout。从源码结构看这条流水线的分工是清晰的生成由 run-prompt 负责理想化由 create-ideal GE 负责裁决由 evaluate-quality 负责——本篇聚焦的裁决模式只消费前三步的产物本身不触发任何模型生成调用职责单一、输入输出边界明确。五、在 LifeOS 中的执行方式Fabric 原生模式执行Fabric 技能见 SKILL.md的执行模型是原生模式执行LifeOS 直接读取Patterns/{pattern_name}/system.md并将其内容作为提示词指令应用无需外部 CLI 往返fabric命令仅用于 YouTube 转录-y与 URL 兜底抓取-u两类场景。对应到arbiter-evaluate-quality的调用路径可参考 ExecutePattern.md 工作流的步骤从用户意图选定模式名模式名必须精确arbiter-evaluate-quality不能写成缺下划线的变体读取该模式的 system.md工作流中给出的运行时路径形如~/.claude/skills/Fabric/Patterns/$PATTERN_NAME/system.md仓库内 Patterns/ 为安装源用户机器上的~/.claude/skills/...为安装后的运行时位置二者内容同源直接应用模式指令加载#output1、#output2、#ideal三个 JSON 文件、剥离元数据按 GE 量规打分并给出 overall_winner。由于该模式的输入是文件路径变量而非文本内容调用时的实际交互就是提供三个 JSON 文件路径模式自身会完成加载与比较模式不定义额外的落盘动作结果分数、依据、overall_winner直接返回给调用方。六、实践要点与适用边界基于上述模式文件与 GE 定义使用该模式时应注意以下由仓库内容直接支撑的约束输入必须是 JSON 文件。变量契约为三个 JSON 路径如果候选输出尚未落盘需先经arbiter-run-prompt生成否则不满足该模式的前置条件。剥离元数据是显式流程步骤。三份输出中任何运行时元信息都应在比较前剔除保证评分只针对内容载荷这是模式 Instructions 第 1 步的原文要求。裁决是相对裁决。overall_winner 定义为最接近 ideal 的输出当 two 份候选与 ideal 距离接近时模式并未定义平局处理规则可推断需由 GE 的第 5 步距离比较 简短理由给出裁决理由使用时应要求裁决结论附带理由文本。评测需确定性参数。GE 文件明确要求评测器调用使用temperature0, top_p1arbiter-evaluate-quality既然整体Apply GE该约束同样适用于其打分环节这是评测结果可复现的前提。评分轴与量表有明确下限。GE 要求量规至少三个维度、0–100 分制、每维度逐分给据arbiter-evaluate-quality默认给出的三轴clarity、completeness、creativity即为满足该下限的标准配置。七、相关文件索引模式本体LifeOS/install/skills/Fabric/Patterns/arbiter-evaluate-quality/system.md评分引擎 GELifeOS/install/skills/Fabric/Patterns/arbiter-general-evaluator/system.md上游生成LifeOS/install/skills/Fabric/Patterns/arbiter-run-prompt/system.md、LifeOS/install/skills/Fabric/Patterns/arbiter-create-ideal/system.mdFabric 技能说明与原生执行机制LifeOS/install/skills/Fabric/SKILL.md模式执行工作流LifeOS/install/skills/Fabric/Workflows/ExecutePattern.md模式目录总览LifeOS/install/skills/Fabric/Patterns/【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
