docs/workspace/compare-evaluation-analysis/history/evaluation-prompt-rubric-spec.md
本文档定义下一阶段评估模板应遵循的统一写法与评分规则。 它服务于：
- core 评估模板重写
- UI 评估输入组包
- 后续测试断言与文案对齐
当前问题不是只有接口冗余，还包括：
focus 出现时，系统提示词没有把任务目标真正切换掉因此需要一份单独规范，约束：
focus 应如何改变任务目标三类任务的系统提示词统一采用下面结构，保持和优化模板同类的可读性与约束感：
# Role: <Role_Name>
## Profile
- Author: Prompt Optimizer
- Version: <version>
- Language: zh-CN
- Description: <角色描述>
## Goal
- Outcome: <本次任务的核心输出目标>
- Done Criteria: <完成标准>
- Non-Goals: <明确不做什么>
## Skills
### Skill-1
1. <能力描述>
2. <能力描述>
## Rules
1. <硬规则>
2. <硬规则>
## Workflow
1. <步骤 1>
2. <步骤 2>
3. <步骤 3>
## Output Contract
- score
- improvements
- patchPlan
- summary
## Initialization
As <Role>, you must follow the <Rules>, complete the task according to <Workflow>, and output valid JSON only.
所有评估模板都必须满足：
建议充分使用模板语法，而不是为每种细分情况单独复制一套模板文件。
优先使用这些条件信号：
hasFocushasReferencePrompthasDesignContexthasCrossModelComparisonhasSharedTestCasesfocus 不是补充文案，而是任务模式切换因此：
hasFocus = false 时，模板执行默认分析 / 评估目标hasFocus = true 时，模板中的 Goal / Rules / Workflow / Output Requirements 都应切换到“用户优先问题驱动”hasCrossModelComparison 是 compare 的增强分支它仍属于 compare，但要求系统提示词额外强调：
建议角色名：
Prompt_Design_Analysis_Expert角色目标：
建议角色名：
Prompt_Execution_Evaluation_Expert角色目标：
建议角色名：
Prompt_Compare_Evaluation_Expert角色目标：
分析不依赖输出，建议维度偏设计态：
goalClarity
instructionCompleteness
structuralExecutability
ambiguityControl
robustness
这些都是右侧评估语义，不应混进左侧分析。
单结果评估依赖执行结果，建议维度偏执行态：
goalAchievement
outputQuality
constraintCompliance
promptEffectiveness
对比评估依赖多个执行快照，建议维度偏证据归纳与迁移：
goalAchievementRobustness
outputQualityCeiling
promptPatternQuality
crossSnapshotRobustness
workspaceTransferability
focus 分支规范只要存在 focus，它就是本次任务的最高优先级目标。
这条规则必须同时体现在：
GoalRulesWorkflowOutput Requirements{{#hasFocus}}
## Goal
- Outcome: 优先判断并回应用户指定的聚焦问题
- Done Criteria: summary / improvements / patchPlan 必须直接回应 focus
- Non-Goals: 不要用泛泛而谈的全面总结回避 focus
{{/hasFocus}}
{{^hasFocus}}
## Goal
- Outcome: 按默认 rubric 完成全面分析 / 评估
- Done Criteria: 覆盖标准维度并给出可执行建议
- Non-Goals: 不要脱离当前证据做泛化猜测
{{/hasFocus}}
{{#hasFocus}}
## Rules
1. Focus Brief 是本次任务最高优先级输入。
2. 你必须优先围绕 Focus Brief 组织判断、评分解释、改进建议和 patchPlan。
3. 如果证据不足以支持 Focus Brief 指向的问题，必须明确说明。
4. 默认 rubric 仍需完成，但不得掩盖 Focus Brief。
{{/hasFocus}}
只要 hasFocus = true，就必须满足：
summary 明确回应 focusimprovements 至少 1 条直接回应 focuspatchPlan 若非空，至少 1 条直接回应 focus建议在 compare 模板中使用：
{{#hasCrossModelComparison}}
...
{{/hasCrossModelComparison}}
该条件只应在下面场景触发：
这时 compare 的额外目标应变成：
{{#hasCrossModelComparison}}
## Additional Goal
- 本次快照中存在“相同提示词 + 相同输入 + 不同模型”的对比组。
- 你必须重点分析不同模型为何对同一提示词产生不同理解和不同输出。
- 你的结论应优先帮助当前工作区提示词提升跨模型清晰度与稳健性。
{{/hasCrossModelComparison}}
{{#hasCrossModelComparison}}
## Cross-Model Rules
1. 不要只总结哪个模型更强，要解释提示词为何导致不同模型产生不同理解。
2. 优先识别歧义、弱约束、结构松散、缺少示例、格式要求不刚性等问题。
3. 若差异主要来自模型能力边界而非提示词表达，应明确说明。
4. patchPlan 应优先提升跨模型可理解性，而不是对某个模型做特化。
{{/hasCrossModelComparison}}
{{#hasCrossModelComparison}}
## Workflow Addition
1. 先识别哪些 snapshot 属于同 prompt 同输入跨模型对比。
2. 比较不同模型在哪些要求上分歧最大。
3. 判断分歧更像提示词表达问题，还是模型能力边界问题。
4. 只把可通过提示词改写改善的部分收敛进 patchPlan。
{{/hasCrossModelComparison}}
system prompt 决定任务规则；user message 则负责清晰传入证据。
建议 user message 包含：
建议 user message 包含：
建议 user message 结构为：
重点：
三类任务虽然 rubric 不同，但输出结构尽量保持统一：
{
"score": {
"overall": 0,
"dimensions": [
{ "key": "dimensionKey", "label": "维度名称", "score": 0 }
]
},
"improvements": [],
"patchPlan": [],
"summary": ""
}
score.dimensions 的 key 集合由任务类型决定improvements 应是可复用方向，不是样本复述patchPlan 只允许修改当前工作区提示词summary 应最短表达关键判断建议不要一次性先改所有模板文件，而是先定这一层规范，再按顺序落地：
一句话总结：
分析 / 单结果评估 / 对比评估 拥有不同的任务目标和评分 rubric；同时必须用模板条件语法正式支持 focus 高优先级任务模式，以及 compare 中的“同提示词跨模型差异分析”分支。