企业官网建设流程全解析

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）为候选输出打分裁决"的提示词模式：它的变量契约、两步执行流程，以及它依赖的 GE（General 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同族的还有三个模式，共同构成一条完整的"提示词输出质量仲裁"流水线：

另外，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 原文语义）

模式文件给出的完整流程只有两步：

1. 加载三份输出：载入 output1、output2 与 ideal 三份输出，并且剥离元数据（strip metadata）。这一步意味着后续比较的是纯内容载荷，而不是把各次运行附带的运行时元信息纳入评分。
2. 应用 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 从任务本身提炼出理想提示词并跑出参照输出，再以此为准绳。

三、GE（General Evaluator）：该模式依赖的评分引擎

arbiter-evaluate-quality的每一步"Apply GE"都指向 arbiter-general-evaluator/system.md。对照该文件，可以还原裁决阶段实际执行的规则：

1. 提取底层任务：从用户输入与候选提示词中，用一句话概括核心任务或用户需求；
2. 起草理想提示词：仅基于该任务概括（忽略各提示词的既有偏见）起草最能达成用户目标的提示词，即 ideal_prompt——这是#ideal参照输出的来源；
3. 质量量规（Quality Rubric）：定义至少三个维度的量规（示例即 clarity、completeness、creativity），对每份候选输出与 GE 自身输出在 0–100 分制上打分；
4. 分数解释：每个维度给出 1–2 句的打分依据；
5. 总体裁决：比较各输出与 ideal_output 的"距离"，宣告总体最佳者并附简短理由。

GE 还规定了两种重要的执行约束：

• 输出格式契约：评估 bundle 时必须使用固定格式输出各 bundle 分数（**Bundle 1 Score**: [0-100]等逐行列出）；
• 确定性设置：所有评测器调用必须使用确定性参数——temperature=0, top_p=1。这一点与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_prompt（GE 起草，输出到 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 定义了理想提示词的生成方式：变量为#ge（general-evaluator 文件路径）、#prompt1、#prompt2、#input；执行时把 prompt1、prompt2 的原始文本与 input 描述交给 GE，GE 按自身指令先提取任务再起草 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 工作流的步骤：

1. 从用户意图选定模式名（模式名必须精确，arbiter-evaluate-quality不能写成缺下划线的变体）；
2. 读取该模式的 system.md（工作流中给出的运行时路径形如~/.claude/skills/Fabric/Patterns/$PATTERN_NAME/system.md；仓库内 Patterns/ 为安装源，用户机器上的~/.claude/skills/...为安装后的运行时位置，二者内容同源）；
3. 直接应用模式指令：加载#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 文件明确要求评测器调用使用temperature=0, top_p=1；arbiter-evaluate-quality既然整体"Apply GE"，该约束同样适用于其打分环节，这是评测结果可复现的前提。
• 评分轴与量表有明确下限。GE 要求量规至少三个维度、0–100 分制、每维度逐分给据；arbiter-evaluate-quality默认给出的三轴（clarity、completeness、creativity）即为满足该下限的标准配置。

七、相关文件索引

• 模式本体：LifeOS/install/skills/Fabric/Patterns/arbiter-evaluate-quality/system.md
• 评分引擎 GE：LifeOS/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.md
• Fabric 技能说明与原生执行机制：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