mirror of
https://github.com/linshenkx/prompt-optimizer.git
synced 2026-05-06 21:50:27 +08:00
docs(workspace): consolidate compare evaluation specs and acceptance evidence
- fold earlier planning notes into a single current-spec and archived history structure - keep manual acceptance steps and real API samples aligned with the refactored analysis/result/compare model - retain supporting workspace notes needed to review version-selection and evaluation behavior changes
This commit is contained in:
linshen
72
docs/workspace/compare-evaluation-analysis/README.md
Normal file
72
docs/workspace/compare-evaluation-analysis/README.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# compare-evaluation-analysis
|
||||
|
||||
> 这个目录已经收敛成“当前规范 + 手工验收 + 真实样例 + 历史资料”四层结构。
|
||||
|
||||
## 先看什么
|
||||
|
||||
如果你只想快速理解现在的实现，不要再从旧进度稿开始读。按这个顺序看：
|
||||
|
||||
1. [current-spec.md](./current-spec.md)
|
||||
2. [manual-acceptance.md](./manual-acceptance.md)
|
||||
3. [real-api-samples/review-summary.md](./real-api-samples/review-summary.md)
|
||||
4. `real-api-samples/*/rendered-messages.md`
|
||||
|
||||
## 当前目录结构
|
||||
|
||||
- `current-spec.md`
|
||||
当前唯一推荐的总览文档。
|
||||
说明分析 / 评估 / 对比评估的语义、输入边界、4 个文本模式差异、当前已完成项和剩余问题。
|
||||
- `manual-acceptance.md`
|
||||
当前手工测试入口。
|
||||
如果你要自己在浏览器里点一遍，就看这份。
|
||||
- `real-api-samples/`
|
||||
真实模型请求样例。
|
||||
这是判断“现在到底发了什么给模型”的最高优先级证据。
|
||||
- `history/`
|
||||
历史设计稿、阶段进度、旧推导文档。
|
||||
保留是为了追溯，不再作为当前实现的直接依据。
|
||||
|
||||
## 当前结论
|
||||
|
||||
- 左侧没有输出的是“分析”。
|
||||
- 右侧单个输出的是“评估”。
|
||||
- 右侧多个输出一起比的是“对比评估”。
|
||||
- 左侧只看设计态输入，右侧只看执行态证据。
|
||||
- 文本模式当前主线已经基本完成。
|
||||
- image 右侧评估链路仍未纳入本轮范围。
|
||||
|
||||
## 当前真实样例覆盖
|
||||
|
||||
### 左侧分析
|
||||
|
||||
| 能力 | basic-user | basic-system | pro-variable | pro-multi |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `prompt-only` | 有 | 有 | 有 | 有 |
|
||||
| `prompt-iterate + focus` | 有 | 暂无 | 暂无 | 暂无 |
|
||||
|
||||
### 右侧评估
|
||||
|
||||
| 能力 | basic-user | basic-system | pro-variable | pro-multi |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `result` | 有 | 有 | 有 | 有 |
|
||||
| `result + focus` | 有 | 暂无 | 暂无 | 暂无 |
|
||||
| `compare` | 有 | 有 | 有 | 有 |
|
||||
| `compare + focus` | 有 | 有 | 有 | 暂无 |
|
||||
|
||||
## 一个重要提醒
|
||||
|
||||
如果你在 `history/` 里的旧文档中看到这些说法，不要直接当成当前事实：
|
||||
|
||||
- `original / optimized`
|
||||
- `A/B only`
|
||||
- `workspacePrompt + variants[]`
|
||||
- `resolvedPrompt` 仍直接进入右侧评估请求
|
||||
- compare 默认继续带 `## 当前工作区提示词`
|
||||
|
||||
这些都属于阶段性推导或旧实现记录。当前实现请以：
|
||||
|
||||
- [current-spec.md](./current-spec.md)
|
||||
- [manual-acceptance.md](./manual-acceptance.md)
|
||||
- [real-api-samples/](./real-api-samples/)
|
||||
|
||||
为准。
|
||||
198
docs/workspace/compare-evaluation-analysis/current-spec.md
Normal file
198
docs/workspace/compare-evaluation-analysis/current-spec.md
Normal file
@@ -0,0 +1,198 @@
|
||||
# 当前规范：分析 / 评估 / 对比评估
|
||||
|
||||
> 这是当前目录唯一推荐的总览文档。
|
||||
> 如果它与 `history/` 里的旧文档冲突，应优先以本文和 `real-api-samples/` 为准。
|
||||
|
||||
## 1. 一句话先讲清
|
||||
|
||||
- 左侧没有输出的是分析。
|
||||
- 右侧单个输出的是评估。
|
||||
- 右侧多个输出一起比的是对比评估。
|
||||
- 左侧只看设计态，右侧只看执行态。
|
||||
|
||||
## 2. 当前任务边界
|
||||
|
||||
本轮真正完成的是文本工作区下的语义重构，不是所有模式的终局重写。
|
||||
|
||||
当前范围：
|
||||
|
||||
- `basic-user`
|
||||
- `basic-system`
|
||||
- `pro-variable`
|
||||
- `pro-multi`
|
||||
|
||||
当前不在主线范围内：
|
||||
|
||||
- image 右侧 `result / compare`
|
||||
|
||||
## 3. 三类能力的当前语义
|
||||
|
||||
### 3.1 分析
|
||||
|
||||
分析作用在左侧工作区，是“提示词设计质量分析”。
|
||||
|
||||
它的特点：
|
||||
|
||||
- 没有执行结果输入。
|
||||
- 不讨论输出质量。
|
||||
- 允许产出 `patchPlan`，因为编辑目标就是左侧当前工作区。
|
||||
|
||||
### 3.2 单结果评估
|
||||
|
||||
评估作用在右侧某一列，是“基于一次执行快照的结果评估”。
|
||||
|
||||
它的特点：
|
||||
|
||||
- 只看这一次测试输入、这一次执行提示词、这一次输出。
|
||||
- 不再额外注入当前工作区全文作为独立证据。
|
||||
- 当前只保留方向性 `improvements`，不要求 `patchPlan`。
|
||||
|
||||
### 3.3 对比评估
|
||||
|
||||
对比评估作用在右侧顶部，是“基于多个执行快照的对比评估”。
|
||||
|
||||
它的特点：
|
||||
|
||||
- 只看公共测试输入和多个执行快照。
|
||||
- 不再默认把问题理解成“原始 vs 优化后”。
|
||||
- 不再默认额外注入当前工作区全文。
|
||||
- 普通 compare 和跨模型 compare 都要求先解释“已观察到的关键差异”，不能先发散到泛建议。
|
||||
|
||||
## 4. 当前输入边界
|
||||
|
||||
### 4.1 左侧分析
|
||||
|
||||
统一原则：
|
||||
|
||||
- 只看当前工作区目标。
|
||||
- 不引用右侧测试文本。
|
||||
- 不引用右侧测试输出。
|
||||
- 不默认引用右侧变量实例值。
|
||||
|
||||
模式差异：
|
||||
|
||||
- `basic-user`
|
||||
只看当前工作区用户提示词。
|
||||
- `basic-system`
|
||||
只看当前工作区系统提示词。
|
||||
- `pro-variable`
|
||||
只保留变量结构，不带变量值。
|
||||
- `pro-multi`
|
||||
只保留最小会话位置上下文，不带完整 transcript。
|
||||
|
||||
### 4.2 右侧单结果评估
|
||||
|
||||
统一结构：
|
||||
|
||||
- 公共测试输入
|
||||
- 当前快照的执行提示词
|
||||
- 当前快照的输出
|
||||
- 必要的模型 / 版本元信息
|
||||
- 编辑目标语义只认当前工作区，不回退到原始提示词
|
||||
|
||||
模式差异：
|
||||
|
||||
- `basic-user`
|
||||
可能没有额外测试文本，此时公共输入会明确写“无额外测试输入”。
|
||||
- `basic-system`
|
||||
公共输入通常是右侧测试文本。
|
||||
- `pro-variable`
|
||||
公共输入里带一次变量值；快照里只保留当前列执行提示词和输出。
|
||||
- `pro-multi`
|
||||
公共输入里带一次 `Conversation Snapshot`；快照里只保留当前列执行提示词和输出。
|
||||
|
||||
### 4.3 右侧对比评估
|
||||
|
||||
统一结构：
|
||||
|
||||
- 公共测试输入只出现一次
|
||||
- 每个快照只保留：
|
||||
- 执行提示词
|
||||
- 输出
|
||||
- 推理（如果有）
|
||||
- 模型 / 版本信息
|
||||
- 仅当当前工作区存在时才允许发起新的 compare 评估
|
||||
|
||||
当前不应再默认出现：
|
||||
|
||||
- `## 当前工作区提示词`
|
||||
- 每个 variant 重复的渲染输入快照
|
||||
- `resolvedPrompt`
|
||||
- `targetMessage + conversationMessages` 原始 JSON
|
||||
|
||||
## 5. 4 个文本模式的差异
|
||||
|
||||
### 5.1 basic-user
|
||||
|
||||
- 左侧分析：只分析当前用户提示词。
|
||||
- 右侧评估：无额外测试输入时，也按真实执行快照评估。
|
||||
- 对比评估：更关注任务类型、格式约束、禁止项是否真的影响输出。
|
||||
|
||||
### 5.2 basic-system
|
||||
|
||||
- 左侧分析：只分析当前 system prompt。
|
||||
- 右侧评估：公共输入通常来自右侧测试文本。
|
||||
- 对比评估：更关注角色、任务步骤、输出格式、语气要求是否真的造成差异。
|
||||
- 如果旧评估已经存在但右侧测试文本被清空，结果应保留可查看，但不允许重新评估。
|
||||
|
||||
### 5.3 pro-variable
|
||||
|
||||
- 左侧分析：只看变量结构，不看变量值。
|
||||
- 右侧评估：变量值属于执行态公共输入，只出现一次。
|
||||
- 对比评估：重点不是“变量渲染内容重复展示”，而是不同执行提示词 / 输出差异。
|
||||
|
||||
### 5.4 pro-multi
|
||||
|
||||
- 左侧分析：看最小会话位置上下文。
|
||||
- 右侧评估：公共输入是一次性的会话快照。
|
||||
- 对比评估：多个快照共享一次会话输入，每个快照只保留自己的执行证据。
|
||||
|
||||
## 6. 当前模板规则
|
||||
|
||||
### 6.1 分析模板
|
||||
|
||||
- 评分维度是设计导向，不评价输出质量。
|
||||
- `focus` 出现时，summary / improvements / patchPlan 必须直接回应 focus。
|
||||
|
||||
### 6.2 单结果评估模板
|
||||
|
||||
- 评分维度是执行导向。
|
||||
- 如果已经出现明确违例或输出边界滑移，summary 必须点名，第一条 improvement 必须先处理它。
|
||||
- 不允许“内容质量不错”掩盖明显违例。
|
||||
|
||||
### 6.3 对比评估模板
|
||||
|
||||
- 普通 compare：
|
||||
- 必须先点名已观察到的关键差异。
|
||||
- 第一条 improvement 必须先处理这条差异。
|
||||
- 跨模型 compare：
|
||||
- 必须先解释同提示词跨模型差异暴露的误解点。
|
||||
- 第一条 improvement 必须先处理这条误解点。
|
||||
|
||||
## 7. 当前已完成项
|
||||
|
||||
- 文本模式的左侧分析 / 右侧 `result` / 右侧 `compare` 主线已打通。
|
||||
- 测试区版本来源已统一到 `workspace / v0 / vN`。
|
||||
- `latest` 只作为旧 session 迁移值，不再是面向用户的主语义。
|
||||
- 真实样例已经收敛成最新标准集合，不再保留大量过渡态样例。
|
||||
- 普通 compare 与跨模型 compare 的模板都已经收紧。
|
||||
- 右侧评估入口已改为 strict workspace-only，不再回退到原始提示词。
|
||||
- 已有评估结果在输入失效后保留为可查看态，但重跑入口会被禁用。
|
||||
|
||||
## 8. 当前剩余问题
|
||||
|
||||
### 8.1 image 右侧评估链路未纳入本轮
|
||||
|
||||
当前没有把 image 的 `result / compare` 纳入主线。
|
||||
|
||||
### 8.2 历史文档仍保留旧阶段推导
|
||||
|
||||
这不是代码问题，而是资料管理问题。当前已经通过 `history/` 隔离，但历史文档本身内容没有全部重写。
|
||||
|
||||
## 9. 当前推荐阅读顺序
|
||||
|
||||
1. 本文
|
||||
2. [manual-acceptance.md](./manual-acceptance.md)
|
||||
3. [real-api-samples/review-summary.md](./real-api-samples/review-summary.md)
|
||||
4. `real-api-samples/*/rendered-messages.md`
|
||||
5. `history/` 里的旧文档，仅在需要追溯时阅读
|
||||
45
docs/workspace/compare-evaluation-analysis/history/README.md
Normal file
45
docs/workspace/compare-evaluation-analysis/history/README.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# history
|
||||
|
||||
> 这里存放的是本任务在推进过程中的阶段性资料。
|
||||
> 它们保留是为了追溯，不再作为当前实现的直接依据。
|
||||
|
||||
## 当前用途
|
||||
|
||||
- 回看为什么当时会这样设计
|
||||
- 追溯某个阶段的判断、分歧和修正过程
|
||||
- 查找早期推导过但后来被收敛掉的方案
|
||||
|
||||
## 不适合直接拿来判断当前事实的内容
|
||||
|
||||
这些文档里可能仍出现：
|
||||
|
||||
- `original / optimized`
|
||||
- `A/B only`
|
||||
- `workspacePrompt + variants[]`
|
||||
- `resolvedPrompt`
|
||||
- compare 默认继续带 `## 当前工作区提示词`
|
||||
|
||||
如果你要判断“现在代码到底怎么发请求”，请回到：
|
||||
|
||||
- [../current-spec.md](../current-spec.md)
|
||||
- [../manual-acceptance.md](../manual-acceptance.md)
|
||||
- [../real-api-samples/](../real-api-samples/)
|
||||
|
||||
## 文件说明
|
||||
|
||||
- `task_plan.md`
|
||||
任务定义原稿。
|
||||
- `findings.md`
|
||||
中期结论与偏差分析。
|
||||
- `progress.md`
|
||||
详细过程记录与阶段验证。
|
||||
- `current-analysis-feature-map.md`
|
||||
入口与模式地图，仍有参考价值，但 payload 细节不再是最新权威。
|
||||
- `evaluation-redesign-overview.md`
|
||||
中期重构总览设计稿。
|
||||
- `evaluation-prompt-rubric-spec.md`
|
||||
模板与评分规范设计稿。
|
||||
- `input-minimization-spec.md`
|
||||
输入最小化设计稿。
|
||||
- `overall-reframing.md`
|
||||
早期整体重构梳理。
|
||||
@@ -0,0 +1,433 @@
|
||||
# 当前“分析 / 评估 / 对比评估”功能现状地图
|
||||
|
||||
> 本文档只描述 **当前代码实现事实**。
|
||||
> 已按 2026-03-16 的工作区代码重新核对。
|
||||
> 如果后续代码与本文冲突，应以代码为准，并同步更新本文。
|
||||
> 2026-03-17 补充说明：本文中的“功能入口 / 语义分层 / 模式差异”仍可视为当前事实；但涉及 compare payload、`workspacePrompt + variants[]`、`resolvedPrompt`、或旧阶段字段名的细节段落，可能保留了阶段性推导痕迹。若与 `real-api-samples/*/rendered-messages.json` 冲突，应优先以真实样例和 [builders.ts](/C:/Users/15588/.codex/worktrees/a89a/prompt-optimizer/packages/core/src/services/template/default-templates/evaluation/builders.ts) 为准。
|
||||
|
||||
## 1. 先记住这 4 句话
|
||||
|
||||
1. 左侧没有输出的是 **分析**。
|
||||
2. 右侧单个输出的是 **评估**。
|
||||
3. 右侧多个输出一起比的是 **对比评估**。
|
||||
4. image 模式目前只有左侧分析，右侧结果评估 / 对比评估还没有完整主链路。
|
||||
|
||||
## 2. 当前 core 真正支持的评估类型
|
||||
|
||||
当前 `packages/core/src/services/evaluation/types.ts` 里的 `EvaluationType` 已经是：
|
||||
|
||||
| 类型 | 当前语义 | 是否依赖输出 |
|
||||
| --- | --- | --- |
|
||||
| `prompt-only` | 左侧提示词分析 | 否 |
|
||||
| `prompt-iterate` | 左侧带迭代要求的提示词分析 | 否 |
|
||||
| `result` | 右侧单结果评估 | 是 |
|
||||
| `compare` | 右侧多结果对比评估 | 是 |
|
||||
|
||||
这意味着：
|
||||
|
||||
- 已经没有 `original` / `optimized` 这两个评估类型。
|
||||
- 右侧单列评估统一走 `result`。
|
||||
- compare 已经不是旧的 `originalPrompt + optimizedPrompt + originalTestResult + optimizedTestResult` 协议。
|
||||
|
||||
## 3. 当前 core 请求结构
|
||||
|
||||
### 3.1 左侧分析
|
||||
|
||||
```ts
|
||||
type PromptAnalysisRequest =
|
||||
| {
|
||||
type: 'prompt-only'
|
||||
originalPrompt?: string
|
||||
optimizedPrompt: string
|
||||
proContext?: ProEvaluationContext
|
||||
}
|
||||
| {
|
||||
type: 'prompt-iterate'
|
||||
originalPrompt?: string
|
||||
optimizedPrompt: string
|
||||
iterateRequirement: string
|
||||
proContext?: ProEvaluationContext
|
||||
}
|
||||
```
|
||||
|
||||
关键点：
|
||||
|
||||
- 不带测试输出。
|
||||
- `originalPrompt` 只是可选参考；如果和当前提示词相同，UI 会主动压掉。
|
||||
|
||||
### 3.2 右侧单结果评估
|
||||
|
||||
```ts
|
||||
interface ResultEvaluationRequest {
|
||||
type: 'result'
|
||||
prompt: string
|
||||
testResult: string
|
||||
testContent?: string
|
||||
resultLabel?: string
|
||||
proContext?: ProEvaluationContext
|
||||
}
|
||||
```
|
||||
|
||||
关键点：
|
||||
|
||||
- 当前单结果评估已经是 **按 `variantId` 分桶** 的。
|
||||
- 它关心的是“这一个测试结果”，而不是“这是 original 还是 optimized”。
|
||||
|
||||
### 3.3 右侧对比评估
|
||||
|
||||
```ts
|
||||
interface CompareEvaluationRequest {
|
||||
type: 'compare'
|
||||
workspacePrompt?: string
|
||||
variants: CompareEvaluationVariant[]
|
||||
proContext?: ProEvaluationContext
|
||||
}
|
||||
|
||||
interface CompareEvaluationVariant {
|
||||
id: string
|
||||
label: string
|
||||
prompt: string
|
||||
output: string
|
||||
reasoning?: string
|
||||
modelKey?: string
|
||||
versionLabel?: string
|
||||
input?: {
|
||||
label: string
|
||||
content: string
|
||||
summary?: string
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
关键点：
|
||||
|
||||
- compare 已经支持 `variants[]`。
|
||||
- 但当前还是一个 **简化版 compare 协议**。
|
||||
- 更彻底的 `inputs[] + variants[]` 去重模型，目前还没有落地。
|
||||
|
||||
## 4. 4 个文本 workspace 的入口总表
|
||||
|
||||
| 工作区 | 左侧输入区分析按钮 | 左侧 PromptPanel 分析按钮 | 右侧单结果评估 | 顶部对比评估 | 当前输入边界结论 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| `basic-user` | 有 | 有 | 有，覆盖所有 active variants | 有，`>= 2` 个 ready variants 即可 | 左侧不吃右侧测试文本；右侧评估/对比评估吃测试文本 |
|
||||
| `basic-system` | 有 | 有 | 有，覆盖所有 active variants | 有，`>= 2` 个 ready variants 即可 | 同上 |
|
||||
| `context-user` | 有 | 有 | 有，覆盖所有 active variants | 有，`>= 2` 个 ready variants 即可 | 左侧只看变量结构；右侧单结果评估已按 variant 单独构造变量上下文；右侧 compare 已带每列渲染后输入快照 |
|
||||
| `context-system` | 无单独输入区分析按钮 | 有 | 有，覆盖所有 active variants | 有，`>= 2` 个 ready variants 即可 | 左侧分析会带会话上下文；右侧单结果评估已按 variant 单独构造会话上下文；compare 已带 `Conversation Snapshot` |
|
||||
|
||||
## 5. 以 `basic-user` 为例，按钮分别在哪，输入分别是什么
|
||||
|
||||
这是最容易把“分析”和“评估”混在一起的模式，所以单独拆开。
|
||||
|
||||
### 5.1 左上输入卡片里的“分析”
|
||||
|
||||
位置：
|
||||
|
||||
- `BasicUserWorkspace.vue` 顶部 `InputPanelUI`
|
||||
|
||||
行为：
|
||||
|
||||
- 读取左上输入框当前内容。
|
||||
- 先把当前输入同步到左侧工作区。
|
||||
- 收起输入区后触发 `prompt-only`。
|
||||
|
||||
输入：
|
||||
|
||||
- `analysisOptimizedPrompt = 当前左侧工作区提示词`
|
||||
- `analysisOriginalPrompt = 当前原始输入`
|
||||
- 不带 `testContent`
|
||||
- 不带输出
|
||||
|
||||
语义：
|
||||
|
||||
- 这是“分析当前提示词本身”。
|
||||
- 不是“分析测试结果”。
|
||||
|
||||
### 5.2 左侧 PromptPanel 顶部的“分析”
|
||||
|
||||
位置：
|
||||
|
||||
- `PromptPanel.vue`
|
||||
|
||||
行为：
|
||||
|
||||
- 直接调用注入的 `evaluation.evaluatePromptOnly()` / `evaluation.evaluatePromptIterate()`。
|
||||
- 如果当前版本带 `iterationNote`，走 `prompt-iterate`；否则走 `prompt-only`。
|
||||
|
||||
输入：
|
||||
|
||||
- `originalPrompt = PromptPanel 当前展示的原始参考`
|
||||
- `optimizedPrompt = PromptPanel 当前展示的工作区版本`
|
||||
- `iterateRequirement` 仅在 `prompt-iterate` 时存在
|
||||
- 不带 `testContent`
|
||||
- 不带输出
|
||||
|
||||
语义：
|
||||
|
||||
- 这是“分析当前工作区版本”。
|
||||
- 它和左上输入卡片分析不是同一个入口。
|
||||
|
||||
### 5.3 右侧单列“评估该结果”
|
||||
|
||||
位置：
|
||||
|
||||
- 每一个 active result column 的 `EvaluationScoreBadge` / `FocusAnalyzeButton`
|
||||
|
||||
行为：
|
||||
|
||||
- 当前列只要有输出，就可以触发 `result`。
|
||||
- 不再只限 A/B。
|
||||
|
||||
输入：
|
||||
|
||||
- `prompt = 该列当前实际选中的版本文本（workspace / v0 / vN）`
|
||||
- `testContent = 右侧测试文本`
|
||||
- `testResult = 该列输出`
|
||||
- `resultLabel = A/B/C/D`
|
||||
|
||||
语义：
|
||||
|
||||
- 这是“结合输入和输出评估当前这次结果”。
|
||||
- 它不再携带 original/optimized 的领域语义。
|
||||
|
||||
### 5.4 右侧顶部“对比评估”
|
||||
|
||||
位置：
|
||||
|
||||
- 右侧测试区顶部工具栏
|
||||
|
||||
显示条件：
|
||||
|
||||
- 当前 active variants 中
|
||||
- 至少 2 个 variant 已有结果
|
||||
- 且这些结果不是 stale
|
||||
|
||||
输入：
|
||||
|
||||
- `workspacePrompt = 左侧当前工作区提示词`
|
||||
- `variants[]`
|
||||
- 每个 variant 带：
|
||||
- 当前列实际选中的 prompt
|
||||
- 当前列输出
|
||||
- 当前列模型
|
||||
- 当前列版本标签
|
||||
- `input = 右侧测试文本`
|
||||
|
||||
语义：
|
||||
|
||||
- 这是“基于多个测试快照，对左侧当前工作区提示词做对比评估”。
|
||||
- patchPlan 统一尝试作用到左侧工作区，而不是作用到某个测试列版本。
|
||||
- 如果某列选的是 `workspace` 但当前工作区为空，UI 会直接阻止测试并报错。
|
||||
|
||||
## 6. 每个文本 workspace 现在分别带什么输入
|
||||
|
||||
### 6.1 `basic-user`
|
||||
|
||||
左侧分析：
|
||||
|
||||
- 只看左侧 prompt。
|
||||
- 不吃右侧测试文本。
|
||||
|
||||
右侧结果评估：
|
||||
|
||||
- `prompt + testContent + output`
|
||||
|
||||
右侧对比评估：
|
||||
|
||||
- `workspacePrompt + variants[]`
|
||||
- 每个 variant 额外带统一的 `testContent` 作为 `input`
|
||||
|
||||
### 6.2 `basic-system`
|
||||
|
||||
与 `basic-user` 结构相同，只是 prompt 语义变成 system prompt。
|
||||
|
||||
左侧分析：
|
||||
|
||||
- 只看左侧 system prompt。
|
||||
- 不吃右侧测试文本。
|
||||
|
||||
右侧结果评估：
|
||||
|
||||
- `system prompt + testContent + output`
|
||||
|
||||
右侧对比评估：
|
||||
|
||||
- `workspacePrompt + variants[]`
|
||||
- 每个 variant 可带 `testContent` 作为 `input`
|
||||
|
||||
### 6.3 `context-user`
|
||||
|
||||
这是这次改造里最关键、也最需要谨慎理解的一个模式。
|
||||
|
||||
左侧分析：
|
||||
|
||||
- Workspace 会单独构造 `analysisContext`
|
||||
- 当前是：
|
||||
|
||||
```ts
|
||||
{
|
||||
variables: buildUsedVariables(usedVarNames, { includeValues: false }),
|
||||
rawPrompt: currentWorkspacePrompt,
|
||||
}
|
||||
```
|
||||
|
||||
也就是：
|
||||
|
||||
- 只带变量结构
|
||||
- 不带变量实例值
|
||||
- 不带右侧测试变量内容
|
||||
|
||||
这条边界已经按目标纠正了。
|
||||
|
||||
右侧结果评估：
|
||||
|
||||
- 当前 `resultTargets` 会按 `variantId` 提供：
|
||||
- `prompt`
|
||||
- `output`
|
||||
- `label`
|
||||
- `proContext`
|
||||
|
||||
当前单结果评估用的 `proContext` 已经改成按当前列动态构造：
|
||||
|
||||
```ts
|
||||
{
|
||||
variables: buildUsedVariables(usedVarNames, {
|
||||
includeValues: true,
|
||||
predefinedOverrides: {
|
||||
currentPrompt: rawPrompt,
|
||||
userQuestion: rawPrompt
|
||||
}
|
||||
}),
|
||||
rawPrompt,
|
||||
resolvedPrompt: buildPromptExecutionContext(rawPrompt, executionVariables).renderedContent
|
||||
}
|
||||
```
|
||||
|
||||
这里要特别注意：
|
||||
|
||||
- 右侧评估确实会吃变量值，这在语义上是对的。
|
||||
- 现在右侧单结果评估已经不再复用 A/B 的共享变量上下文。
|
||||
- 它看到的是“当前列 prompt + 当前列输出 + 当前列变量渲染结果”。
|
||||
|
||||
右侧对比评估：
|
||||
|
||||
- compare 已经按 active variants 收集 `variants[]`
|
||||
- 当前 `context-user` 的 compare payload 已经会给每个 variant 带：
|
||||
- `input.label = Rendered Content`
|
||||
- `input.content = 当前列真正发送给模型的渲染后输入`
|
||||
- `input.summary = 当前列变量值摘要`
|
||||
|
||||
所以当前状态应理解为：
|
||||
|
||||
- “分析不再吃变量值”已经完成
|
||||
- “变量模式右侧评估已脱离 original/optimized”已经完成
|
||||
- “变量模式右侧单结果评估按 variant 取上下文”已经完成
|
||||
- “变量模式右侧 compare 已显式带执行态输入快照”也已经完成
|
||||
- 剩余主要是 compare 结构仍然是 `workspacePrompt + variants[]`，还没继续演进到 `inputs[] + variants[]`
|
||||
|
||||
### 6.4 `context-system`
|
||||
|
||||
左侧分析：
|
||||
|
||||
- 没有单独输入区分析按钮
|
||||
- 只有 `PromptPanel` 顶部分析
|
||||
- 分析会带会话上下文 `proContext`
|
||||
|
||||
当前 `proContext` 会包含：
|
||||
|
||||
- `targetMessage`
|
||||
- `conversationMessages`
|
||||
|
||||
这类上下文本身属于设计态输入的一部分，所以左侧分析带它是合理的。
|
||||
|
||||
右侧结果评估：
|
||||
|
||||
- `resultTargets` 当前会按 `variantId` 提供：
|
||||
- 当前 variant 的目标消息 prompt
|
||||
- 当前 variant 输出
|
||||
- 当前 variant 的 `proContext`
|
||||
|
||||
同样要注意：
|
||||
|
||||
- 单结果评估的 `proContext` 现在会按当前列：
|
||||
- 单独取该列目标消息内容
|
||||
- 单独重建 `conversationMessages`
|
||||
- 因此右侧单结果评估已经不再复用 A/B 的共享会话上下文
|
||||
|
||||
右侧对比评估：
|
||||
|
||||
- compare payload 已经比 `context-user` 更完整
|
||||
- 每个 variant 会带：
|
||||
- prompt
|
||||
- output
|
||||
- modelKey
|
||||
- versionLabel
|
||||
- `input = Conversation Snapshot`
|
||||
- 如果有工具，还会把 tools 一起拼进 input content
|
||||
|
||||
因此当前 `context-system` 的 compare 比 result 更接近目标结构。
|
||||
|
||||
## 7. 右侧测试文本 / 变量输入，当前到底只在哪些地方有效
|
||||
|
||||
### 7.1 `basic-user` / `basic-system` 的测试文本
|
||||
|
||||
当前结论很明确：
|
||||
|
||||
- 左侧分析不使用右侧测试文本。
|
||||
- 右侧结果评估和对比评估会使用右侧测试文本。
|
||||
|
||||
所以：
|
||||
|
||||
- 它只在“测试”和“评估”语义下有意义。
|
||||
- 对左侧分析不应产生影响。
|
||||
|
||||
### 7.2 `context-user` 的测试变量值
|
||||
|
||||
当前结论也明确：
|
||||
|
||||
- 左侧分析不再使用右侧测试变量值。
|
||||
- 右侧执行、结果评估、对比评估才需要它们。
|
||||
|
||||
但实现上要分两层理解：
|
||||
|
||||
- 语义边界已经纠正了
|
||||
- 单结果评估上下文也已经按 variant 纠正了
|
||||
- compare 现在也已经显式携带每列执行态 `input`
|
||||
- 剩余主要是 compare 结构还没有继续演进到 `inputs[] + variants[]`
|
||||
|
||||
### 7.3 `context-system` 的右侧变量/会话输入
|
||||
|
||||
这里要区分两类东西：
|
||||
|
||||
- 会话结构本身：属于设计态上下文，左侧分析带它合理
|
||||
- 右侧测试区临时变量值：属于执行态输入，更适合右侧评估
|
||||
|
||||
当前实现基本符合这条边界；单结果评估的 per-variant 会话上下文也已经独立，后续如果还要继续收紧，重点会落在 compare 协议是否继续去 shared-context 化。
|
||||
|
||||
## 8. 当前已经完成的事
|
||||
|
||||
1. 评估类型已经改成 `result / compare / prompt-only / prompt-iterate`。
|
||||
2. 文本 workspace 的右侧单结果评估已经覆盖所有 active variants。
|
||||
3. compare 已经支持任意 `>= 2` 个 ready variants，不再只限 A/B 或 2 列模式。
|
||||
4. basic 两个 workspace 的 compare 已经显式把测试文本作为 variant input 带入。
|
||||
5. `context-user` 左侧分析已经纠正为“只看变量结构，不看变量值”。
|
||||
6. `context-user` / `context-system` 的右侧单结果评估都已经按 variant 单独构造 `proContext`。
|
||||
7. compare 模板已经从“原始 vs 优化后”语言切到“多快照证据”的语言。
|
||||
|
||||
## 9. 当前仍然存在的偏差 / 未完成项
|
||||
|
||||
1. compare 结构目前仍然是 `workspacePrompt + variants[]`；这属于可选的后续规范化项，不再作为当前主链路 blocker。
|
||||
2. image 模式目前只有左侧 `prompt-only` 分析模板，没有右侧 `result` / `compare` 模板与接线。
|
||||
3. 一些共享测试面板内部仍保留 `COMPARE_BASELINE_VARIANT_ID` / `COMPARE_CANDIDATE_VARIANT_ID` 这样的旧常量做 tool-call 分桶，这属于后续可清理的内部残留，不影响当前对外语义。
|
||||
|
||||
## 10. 一句话版本
|
||||
|
||||
当前文本 workspace 的主语义已经基本收拢成：
|
||||
|
||||
- 左侧分析只看工作区设计态对象
|
||||
- 右侧单结果评估看某个 variant 的实际输出
|
||||
- 右侧对比评估看多个 ready variants 的快照
|
||||
|
||||
当前真正还没完全收干净的，主要是：
|
||||
|
||||
- compare 协议还没有继续演进到 `inputs[] + variants[]`，但这已降级为可选后续优化
|
||||
- image 右侧评估链路还没补齐
|
||||
@@ -0,0 +1,404 @@
|
||||
# 分析 / 评估 / 对比评估模板与评分规范
|
||||
|
||||
> 本文档定义下一阶段评估模板应遵循的统一写法与评分规则。
|
||||
> 它服务于：
|
||||
> - core 评估模板重写
|
||||
> - UI 评估输入组包
|
||||
> - 后续测试断言与文案对齐
|
||||
|
||||
## 1. 为什么需要单独这份规范
|
||||
|
||||
当前问题不是只有接口冗余，还包括：
|
||||
|
||||
- 三类任务的系统提示词结构不统一
|
||||
- 三类任务的评分维度边界不清楚
|
||||
- `focus` 出现时，系统提示词没有把任务目标真正切换掉
|
||||
- compare 中“跨模型同提示词对比”缺少显式分析规则
|
||||
|
||||
因此需要一份单独规范，约束：
|
||||
|
||||
1. 模板框架长什么样
|
||||
2. 三类任务分别用什么 rubric
|
||||
3. `focus` 应如何改变任务目标
|
||||
4. compare 的跨模型分支应如何切换
|
||||
|
||||
## 2. 统一模板框架
|
||||
|
||||
三类任务的系统提示词统一采用下面结构，保持和优化模板同类的可读性与约束感：
|
||||
|
||||
```md
|
||||
# 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.
|
||||
```
|
||||
|
||||
### 2.1 统一要求
|
||||
|
||||
所有评估模板都必须满足：
|
||||
|
||||
1. 角色必须明确是“评估者”，不是任务执行者。
|
||||
2. 目标必须明确 patchPlan 只允许修改当前工作区提示词。
|
||||
3. 规则必须明确：证据不足时返回空 patchPlan，不得臆造不存在的 prompt 片段。
|
||||
4. 工作流必须先分析，再评分，再建议，再映射 patchPlan。
|
||||
5. 输出契约统一为 JSON，不输出额外解释。
|
||||
|
||||
## 3. 模板条件块使用规范
|
||||
|
||||
建议充分使用模板语法，而不是为每种细分情况单独复制一套模板文件。
|
||||
|
||||
优先使用这些条件信号：
|
||||
|
||||
- `hasFocus`
|
||||
- `hasReferencePrompt`
|
||||
- `hasDesignContext`
|
||||
- `hasCrossModelComparison`
|
||||
- `hasSharedTestCases`
|
||||
|
||||
### 3.1 `focus` 不是补充文案，而是任务模式切换
|
||||
|
||||
因此：
|
||||
|
||||
- `hasFocus = false` 时，模板执行默认分析 / 评估目标
|
||||
- `hasFocus = true` 时，模板中的 `Goal / Rules / Workflow / Output Requirements` 都应切换到“用户优先问题驱动”
|
||||
|
||||
### 3.2 `hasCrossModelComparison` 是 compare 的增强分支
|
||||
|
||||
它仍属于 compare，但要求系统提示词额外强调：
|
||||
|
||||
- 同 prompt 同输入跨模型差异
|
||||
- 不要只总结模型强弱
|
||||
- 要找出 prompt 对弱模型不够清晰的地方
|
||||
|
||||
## 4. 三类任务的 Role 建议
|
||||
|
||||
### 4.1 分析 Analysis
|
||||
|
||||
建议角色名：
|
||||
|
||||
- `Prompt_Design_Analysis_Expert`
|
||||
|
||||
角色目标：
|
||||
|
||||
- 专注提示词设计质量
|
||||
- 不看执行输出
|
||||
- 识别结构问题、歧义、约束缺失、稳健性问题
|
||||
|
||||
### 4.2 单结果评估 Single Result Evaluation
|
||||
|
||||
建议角色名：
|
||||
|
||||
- `Prompt_Execution_Evaluation_Expert`
|
||||
|
||||
角色目标：
|
||||
|
||||
- 基于一次执行快照评估提示词表现
|
||||
- 看 prompt、输入、输出之间的匹配关系
|
||||
- 分析结果质量与提示词设计之间的因果
|
||||
|
||||
### 4.3 对比评估 Compare Evaluation
|
||||
|
||||
建议角色名：
|
||||
|
||||
- `Prompt_Compare_Evaluation_Expert`
|
||||
|
||||
角色目标：
|
||||
|
||||
- 基于多个执行快照提炼规律
|
||||
- 判断哪些模式值得吸收到当前工作区提示词
|
||||
- 不能把 compare 误解为简单 A/B 输赢总结
|
||||
|
||||
## 5. 三类任务的评分维度应彻底拆开
|
||||
|
||||
## 5.1 分析 Analysis Rubric
|
||||
|
||||
分析不依赖输出，建议维度偏设计态：
|
||||
|
||||
1. `goalClarity`
|
||||
- 目标清晰度
|
||||
- 任务目标是否明确、边界是否清楚
|
||||
2. `instructionCompleteness`
|
||||
- 指令完备度
|
||||
- 是否覆盖必要要求、约束、输入边界
|
||||
3. `structuralExecutability`
|
||||
- 结构可执行性
|
||||
- 模型是否容易按结构理解并执行
|
||||
4. `ambiguityControl`
|
||||
- 歧义控制
|
||||
- 是否存在容易产生不同理解的表达
|
||||
5. `robustness`
|
||||
- 稳健性
|
||||
- 是否更可能在不同输入下稳定工作
|
||||
|
||||
### 不适合放进分析的维度
|
||||
|
||||
- 输出质量
|
||||
- 单次结果达成度
|
||||
- 跨快照稳定性
|
||||
|
||||
这些都是右侧评估语义，不应混进左侧分析。
|
||||
|
||||
## 5.2 单结果评估 Single Result Rubric
|
||||
|
||||
单结果评估依赖执行结果，建议维度偏执行态：
|
||||
|
||||
1. `goalAchievement`
|
||||
- 目标达成度
|
||||
- 这次输出是否完成任务
|
||||
2. `outputQuality`
|
||||
- 输出质量
|
||||
- 内容质量、准确性、表达质量
|
||||
3. `constraintCompliance`
|
||||
- 约束符合度
|
||||
- 输出是否遵守格式、限制、风格等要求
|
||||
4. `promptEffectiveness`
|
||||
- 提示词引导有效性
|
||||
- 该提示词是否足以稳定地引导出当前结果
|
||||
|
||||
### 不适合放进单结果评估的维度
|
||||
|
||||
- 跨快照鲁棒性
|
||||
- 多方案规律收敛能力
|
||||
|
||||
## 5.3 对比评估 Compare Rubric
|
||||
|
||||
对比评估依赖多个执行快照，建议维度偏证据归纳与迁移：
|
||||
|
||||
1. `goalAchievementRobustness`
|
||||
- 目标达成稳定性
|
||||
- 多快照下是否都能较稳定地达到目标
|
||||
2. `outputQualityCeiling`
|
||||
- 输出质量上限
|
||||
- 更优快照体现出的质量上限是否足够高
|
||||
3. `promptPatternQuality`
|
||||
- 提示词模式质量
|
||||
- 哪些 prompt 写法明显更好、更差
|
||||
4. `crossSnapshotRobustness`
|
||||
- 跨快照鲁棒性
|
||||
- 同类条件下结果是否稳定
|
||||
5. `workspaceTransferability`
|
||||
- 对工作区的可迁移性
|
||||
- 这些证据是否能可靠收敛成对当前工作区的修改建议
|
||||
|
||||
### 不适合放进 compare 的维度
|
||||
|
||||
- 单次输出细节得分导向过强的维度
|
||||
- 纯设计态、不看结果的维度
|
||||
|
||||
## 6. `focus` 分支规范
|
||||
|
||||
## 6.1 核心原则
|
||||
|
||||
只要存在 `focus`，它就是本次任务的最高优先级目标。
|
||||
|
||||
这条规则必须同时体现在：
|
||||
|
||||
- `Goal`
|
||||
- `Rules`
|
||||
- `Workflow`
|
||||
- `Output Requirements`
|
||||
|
||||
### 6.2 系统提示词中的条件块建议
|
||||
|
||||
```md
|
||||
{{#hasFocus}}
|
||||
## Goal
|
||||
- Outcome: 优先判断并回应用户指定的聚焦问题
|
||||
- Done Criteria: summary / improvements / patchPlan 必须直接回应 focus
|
||||
- Non-Goals: 不要用泛泛而谈的全面总结回避 focus
|
||||
{{/hasFocus}}
|
||||
|
||||
{{^hasFocus}}
|
||||
## Goal
|
||||
- Outcome: 按默认 rubric 完成全面分析 / 评估
|
||||
- Done Criteria: 覆盖标准维度并给出可执行建议
|
||||
- Non-Goals: 不要脱离当前证据做泛化猜测
|
||||
{{/hasFocus}}
|
||||
```
|
||||
|
||||
```md
|
||||
{{#hasFocus}}
|
||||
## Rules
|
||||
1. Focus Brief 是本次任务最高优先级输入。
|
||||
2. 你必须优先围绕 Focus Brief 组织判断、评分解释、改进建议和 patchPlan。
|
||||
3. 如果证据不足以支持 Focus Brief 指向的问题，必须明确说明。
|
||||
4. 默认 rubric 仍需完成，但不得掩盖 Focus Brief。
|
||||
{{/hasFocus}}
|
||||
```
|
||||
|
||||
### 6.3 输出约束
|
||||
|
||||
只要 `hasFocus = true`，就必须满足：
|
||||
|
||||
1. `summary` 明确回应 focus
|
||||
2. `improvements` 至少 1 条直接回应 focus
|
||||
3. `patchPlan` 若非空，至少 1 条直接回应 focus
|
||||
|
||||
## 7. compare 的跨模型分支规范
|
||||
|
||||
## 7.1 使用条件
|
||||
|
||||
建议在 compare 模板中使用：
|
||||
|
||||
```md
|
||||
{{#hasCrossModelComparison}}
|
||||
...
|
||||
{{/hasCrossModelComparison}}
|
||||
```
|
||||
|
||||
该条件只应在下面场景触发：
|
||||
|
||||
- 同一测试用例
|
||||
- 相同或等价 prompt
|
||||
- 模型不同
|
||||
- 输出有明显差异
|
||||
|
||||
### 7.2 目标切换
|
||||
|
||||
这时 compare 的额外目标应变成：
|
||||
|
||||
- 识别提示词对不同模型的理解门槛
|
||||
- 发现哪些表达对强模型足够、对弱模型不够清晰
|
||||
- 优先改进跨模型可理解性与一致性
|
||||
|
||||
### 7.3 推荐条件块
|
||||
|
||||
```md
|
||||
{{#hasCrossModelComparison}}
|
||||
## Additional Goal
|
||||
- 本次快照中存在“相同提示词 + 相同输入 + 不同模型”的对比组。
|
||||
- 你必须重点分析不同模型为何对同一提示词产生不同理解和不同输出。
|
||||
- 你的结论应优先帮助当前工作区提示词提升跨模型清晰度与稳健性。
|
||||
{{/hasCrossModelComparison}}
|
||||
```
|
||||
|
||||
```md
|
||||
{{#hasCrossModelComparison}}
|
||||
## Cross-Model Rules
|
||||
1. 不要只总结哪个模型更强，要解释提示词为何导致不同模型产生不同理解。
|
||||
2. 优先识别歧义、弱约束、结构松散、缺少示例、格式要求不刚性等问题。
|
||||
3. 若差异主要来自模型能力边界而非提示词表达，应明确说明。
|
||||
4. patchPlan 应优先提升跨模型可理解性，而不是对某个模型做特化。
|
||||
{{/hasCrossModelComparison}}
|
||||
```
|
||||
|
||||
### 7.4 工作流增强
|
||||
|
||||
```md
|
||||
{{#hasCrossModelComparison}}
|
||||
## Workflow Addition
|
||||
1. 先识别哪些 snapshot 属于同 prompt 同输入跨模型对比。
|
||||
2. 比较不同模型在哪些要求上分歧最大。
|
||||
3. 判断分歧更像提示词表达问题，还是模型能力边界问题。
|
||||
4. 只把可通过提示词改写改善的部分收敛进 patchPlan。
|
||||
{{/hasCrossModelComparison}}
|
||||
```
|
||||
|
||||
## 8. 用户提示词（user message）规范
|
||||
|
||||
system prompt 决定任务规则；user message 则负责清晰传入证据。
|
||||
|
||||
### 8.1 分析
|
||||
|
||||
建议 user message 包含：
|
||||
|
||||
- 当前工作区提示词
|
||||
- 可选参考 prompt
|
||||
- 设计态上下文
|
||||
- 可选 focus
|
||||
|
||||
### 8.2 单结果评估
|
||||
|
||||
建议 user message 包含：
|
||||
|
||||
- 当前工作区提示词
|
||||
- 当前执行 prompt
|
||||
- 当前测试输入
|
||||
- 当前输出
|
||||
- 可选 focus
|
||||
|
||||
### 8.3 对比评估
|
||||
|
||||
建议 user message 结构为：
|
||||
|
||||
1. 当前工作区提示词
|
||||
2. 公共测试用例
|
||||
3. 快照列表
|
||||
4. 可选 compare hints
|
||||
5. 可选 focus
|
||||
|
||||
重点：
|
||||
|
||||
- 公共测试输入尽量放公共区域，不重复塞入每个 snapshot
|
||||
- snapshot 只写其独有信息
|
||||
|
||||
## 9. 输出 contract 保持统一
|
||||
|
||||
三类任务虽然 rubric 不同，但输出结构尽量保持统一：
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 0,
|
||||
"dimensions": [
|
||||
{ "key": "dimensionKey", "label": "维度名称", "score": 0 }
|
||||
]
|
||||
},
|
||||
"improvements": [],
|
||||
"patchPlan": [],
|
||||
"summary": ""
|
||||
}
|
||||
```
|
||||
|
||||
### 统一约束
|
||||
|
||||
1. `score.dimensions` 的 key 集合由任务类型决定
|
||||
2. `improvements` 应是可复用方向，不是样本复述
|
||||
3. `patchPlan` 只允许修改当前工作区提示词
|
||||
4. `summary` 应最短表达关键判断
|
||||
|
||||
## 10. 实施建议
|
||||
|
||||
建议不要一次性先改所有模板文件，而是先定这一层规范，再按顺序落地：
|
||||
|
||||
1. 先改 core 类型与模板渲染上下文
|
||||
2. 再改三类模板主骨架
|
||||
3. 再给不同模式接入各自上下文
|
||||
4. 最后补测试和 i18n 文案
|
||||
|
||||
## 11. 本文档的最终结论
|
||||
|
||||
一句话总结：
|
||||
|
||||
- 下一阶段模板重写不应只是“改措辞”，而应建立统一的结构化系统提示词框架，并让 `分析 / 单结果评估 / 对比评估` 拥有不同的任务目标和评分 rubric；同时必须用模板条件语法正式支持 `focus` 高优先级任务模式，以及 compare 中的“同提示词跨模型差异分析”分支。
|
||||
@@ -0,0 +1,404 @@
|
||||
# 分析 / 评估 / 对比评估重构设计总览
|
||||
|
||||
> 本文档描述 **下一阶段重构设计目标**，不是当前代码事实记录。
|
||||
> 当前代码现状请优先参考：
|
||||
> - `current-analysis-feature-map.md`
|
||||
> - `findings.md`
|
||||
> - `progress.md`
|
||||
|
||||
## 1. 本轮设计的核心目标
|
||||
|
||||
这一阶段不再只是修正旧 `compare` 的语义，而是要建立一套更稳定的评估体系：
|
||||
|
||||
1. 明确区分：
|
||||
- 左侧 `分析`
|
||||
- 右侧单结果 `评估`
|
||||
- 右侧多结果 `对比评估`
|
||||
2. 统一“当前工作区提示词才是可修改目标”的原则。
|
||||
3. 重构输入协议，去掉公共输入重复，支持未来多测试能力。
|
||||
4. 彻底重写评估类模板，统一采用结构化系统提示词框架。
|
||||
5. 为三类任务分别定义不同的评分维度，不再共用一套 rubric。
|
||||
6. 把 `聚焦内容（focus）` 升级为所有分析 / 评估任务的最高优先级输入。
|
||||
|
||||
## 2. 先明确三类任务的语义
|
||||
|
||||
### 2.1 分析 Analysis
|
||||
|
||||
分析作用在左侧工作区，评估对象是“提示词设计本身”。
|
||||
|
||||
特点：
|
||||
|
||||
- 不依赖右侧测试输出。
|
||||
- 只看工作区当前可编辑对象及其设计态上下文。
|
||||
- 目标是判断提示词是否清晰、完整、可执行、稳健。
|
||||
- patchPlan 只允许修改当前工作区提示词。
|
||||
|
||||
### 2.2 单结果评估 Single Result Evaluation
|
||||
|
||||
单结果评估作用在右侧单个测试结果上，评估对象是“一次执行快照”。
|
||||
|
||||
特点：
|
||||
|
||||
- 依赖输入、提示词和输出。
|
||||
- 不关心该结果来自 original / optimized 还是某个版本身份。
|
||||
- 关注的是“这个提示词在这次执行中表现如何”。
|
||||
- patchPlan 仍然只尝试修改当前工作区提示词，而不是某个历史版本。
|
||||
|
||||
### 2.3 对比评估 Compare Evaluation
|
||||
|
||||
对比评估作用在右侧多个测试快照上，评估对象是“一组执行证据”。
|
||||
|
||||
特点：
|
||||
|
||||
- 至少需要 2 个快照。
|
||||
- 核心不是“哪一列赢了”，而是“哪些规律值得吸收到当前工作区提示词中”。
|
||||
- patchPlan 的唯一目标仍然是当前工作区提示词。
|
||||
- 如果多组证据无法可靠映射到当前工作区提示词，必须返回空 patchPlan。
|
||||
|
||||
## 3. 设计原则
|
||||
|
||||
### 3.1 当前工作区才是唯一 patch target
|
||||
|
||||
这条规则对三类任务全部成立：
|
||||
|
||||
- 可以引用原始提示词、历史版本、测试快照作为证据。
|
||||
- 但 patchPlan 只能针对当前工作区提示词生成。
|
||||
- 如果当前工作区为空，应该直接阻止相关操作，而不是回退到其他 prompt。
|
||||
|
||||
### 3.2 左侧只看设计态，右侧只看执行态
|
||||
|
||||
左侧分析：
|
||||
|
||||
- 只看工作区 prompt 和设计态上下文。
|
||||
- 不读取右侧测试文本、变量值、测试输出。
|
||||
|
||||
右侧评估：
|
||||
|
||||
- 只看测试输入、执行 prompt、执行输出及相关执行上下文。
|
||||
- 不应误把右侧执行态输入当成左侧设计态上下文。
|
||||
|
||||
### 3.3 评估不是版本关系推断
|
||||
|
||||
评估功能不应假设：
|
||||
|
||||
- 某列一定代表“原始”
|
||||
- 某列一定代表“优化后”
|
||||
- 当前工作区一定对应被测试的某个版本
|
||||
|
||||
正确理解是：
|
||||
|
||||
- 测试快照只是证据。
|
||||
- 当前工作区只是可修改目标。
|
||||
- 两者不要求一一对应。
|
||||
|
||||
## 4. 新的输入模型：从“字段堆叠”改为“三层结构”
|
||||
|
||||
当前最值得统一的，不是再调 `result / compare` 的字段名，而是把输入拆成三个层次：
|
||||
|
||||
1. `target`：当前工作区中可被修改的对象
|
||||
2. `testCases`：公共测试用例
|
||||
3. `snapshots`：每一次真实执行快照
|
||||
|
||||
### 4.1 目标对象 Target
|
||||
|
||||
```ts
|
||||
export interface EvaluationTarget {
|
||||
mode: {
|
||||
functionMode: 'basic' | 'pro' | 'image'
|
||||
subMode: string
|
||||
}
|
||||
workspacePrompt: string
|
||||
referencePrompt?: string
|
||||
designContext?: DesignContext
|
||||
}
|
||||
```
|
||||
|
||||
含义：
|
||||
|
||||
- `workspacePrompt`：唯一可修改对象
|
||||
- `referencePrompt`：可选参考，如 v0 或工作区进入分析前的原始内容
|
||||
- `designContext`：只用于左侧分析的设计态上下文
|
||||
|
||||
### 4.2 公共测试用例 TestCases
|
||||
|
||||
```ts
|
||||
export interface TestCase {
|
||||
id: string
|
||||
label?: string
|
||||
input: TestCaseInput
|
||||
sharedSettings?: SharedExecutionSettings
|
||||
}
|
||||
```
|
||||
|
||||
含义：
|
||||
|
||||
- 表达“这次我们到底在测什么”
|
||||
- 适合承载公共测试文本、变量输入、会话输入、图像输入
|
||||
- 多个 snapshot 可以共用同一个 testCase
|
||||
|
||||
### 4.3 执行快照 Snapshots
|
||||
|
||||
```ts
|
||||
export interface ExecutionSnapshot {
|
||||
id: string
|
||||
label: string
|
||||
testCaseId: string
|
||||
promptRef: PromptRef
|
||||
promptText: string
|
||||
output: string
|
||||
reasoning?: string
|
||||
modelKey?: string
|
||||
settingsOverride?: Partial<SharedExecutionSettings>
|
||||
executionInput?: {
|
||||
label: string
|
||||
content: string
|
||||
summary?: string
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
含义：
|
||||
|
||||
- 表达“这一次真实执行时，模型看到了什么、输出了什么”
|
||||
- `promptText` 是实际执行 prompt
|
||||
- `executionInput` 只放“与 testCase 公共输入不同、或需要额外表达的执行态证据”
|
||||
|
||||
### 4.4 统一后的请求形态
|
||||
|
||||
分析：
|
||||
|
||||
```ts
|
||||
export interface AnalysisRequest {
|
||||
type: 'analysis'
|
||||
target: EvaluationTarget
|
||||
iterateRequirement?: string
|
||||
focus?: FocusBrief
|
||||
}
|
||||
```
|
||||
|
||||
右侧评估：
|
||||
|
||||
```ts
|
||||
export interface ExecutionEvaluationRequest {
|
||||
type: 'execution-evaluation'
|
||||
view: 'single' | 'compare'
|
||||
target: EvaluationTarget
|
||||
testCases: TestCase[]
|
||||
snapshots: ExecutionSnapshot[]
|
||||
focus?: FocusBrief
|
||||
compareHints?: CompareAnalysisHints
|
||||
}
|
||||
```
|
||||
|
||||
## 5. 为什么这种结构更适合未来多测试
|
||||
|
||||
多测试能力的关键不是“支持更多 variant”，而是支持：
|
||||
|
||||
- 多个测试用例
|
||||
- 每个测试用例下可有多个快照
|
||||
- 多个快照之间可能只是模型不同，也可能只是 prompt 版本不同
|
||||
|
||||
这套结构下：
|
||||
|
||||
- 共同的测试内容只在 `testCases` 里出现一次
|
||||
- 每个 snapshot 只表达自己独有的信息
|
||||
- 单结果评估和对比评估共用同一套协议，只是 `snapshots.length` 不同
|
||||
|
||||
## 6. `focus` 的设计地位：最高优先级输入
|
||||
|
||||
## 6.1 `focus` 不是备注，是任务切换器
|
||||
|
||||
当用户填写聚焦内容时，它不只是“补充说明”，而是改变本次任务的主目标。
|
||||
|
||||
因此：
|
||||
|
||||
- 无 `focus`：执行默认分析 / 评估任务
|
||||
- 有 `focus`：执行“用户优先问题驱动”的定向分析 / 评估任务
|
||||
|
||||
### 6.2 统一建模建议
|
||||
|
||||
```ts
|
||||
export interface FocusBrief {
|
||||
content: string
|
||||
source: 'user' | 'system'
|
||||
priority: 'highest'
|
||||
}
|
||||
```
|
||||
|
||||
### 6.3 统一规则
|
||||
|
||||
只要存在 `focus`，就必须满足：
|
||||
|
||||
1. `summary` 必须先回应 `focus`
|
||||
2. `improvements` 至少 1 条直接回应 `focus`
|
||||
3. `patchPlan` 若非空，至少 1 条直接回应 `focus`
|
||||
4. 默认 rubric 仍需完成，但不能盖过 `focus`
|
||||
5. 若当前证据不足以支持 `focus` 指向的问题，必须明确说明
|
||||
|
||||
## 7. compare 的一个重要子场景：同提示词跨模型对比
|
||||
|
||||
## 7.1 场景定义
|
||||
|
||||
当满足以下条件时：
|
||||
|
||||
- 测试输入相同
|
||||
- 执行 prompt 相同或语义等价
|
||||
- 模型不同
|
||||
- 输出不同
|
||||
|
||||
应视为：
|
||||
|
||||
- “同一提示词在不同模型下的理解差异对比”
|
||||
|
||||
### 7.2 这个场景的核心目标
|
||||
|
||||
重点不应只放在“哪个模型更强”，而应分析：
|
||||
|
||||
- 为什么同一个 prompt 会被不同模型理解成不同结果
|
||||
- 哪些表达对强模型足够，但对弱模型不够清晰
|
||||
- 是否存在这些问题：
|
||||
- 目标表达不够显式
|
||||
- 约束不够前置
|
||||
- 歧义词太多
|
||||
- 结构层级不清楚
|
||||
- 输出格式要求不够刚性
|
||||
- 缺少示例
|
||||
|
||||
### 7.3 这不是新的任务类型
|
||||
|
||||
它仍属于 compare evaluation，但需要额外的分析提示。
|
||||
|
||||
建议通过 `compareHints` 显式建模：
|
||||
|
||||
```ts
|
||||
export interface CompareAnalysisHints {
|
||||
sameTestCaseAcrossSnapshots: boolean
|
||||
samePromptAcrossSnapshots: boolean
|
||||
crossModelComparison: boolean
|
||||
}
|
||||
```
|
||||
|
||||
必要时可以再加：
|
||||
|
||||
```ts
|
||||
export interface SnapshotComparisonGroup {
|
||||
groupId: string
|
||||
basis: 'same-prompt-same-input-cross-model' | 'same-input-cross-prompt'
|
||||
snapshotIds: string[]
|
||||
}
|
||||
```
|
||||
|
||||
## 8. 4 个模式在新模型下的映射方式
|
||||
|
||||
### 8.1 basic-user / basic-system
|
||||
|
||||
左侧分析：
|
||||
|
||||
- `target.workspacePrompt`
|
||||
- 无执行态测试输入
|
||||
|
||||
右侧评估：
|
||||
|
||||
- `TestCase.input = { kind: 'text', text }`
|
||||
- snapshot 持有：
|
||||
- `promptText`
|
||||
- `output`
|
||||
- `modelKey`
|
||||
|
||||
### 8.2 context-user
|
||||
|
||||
左侧分析：
|
||||
|
||||
- `target.designContext = variable-design`
|
||||
- 只带变量结构，不带变量值
|
||||
|
||||
右侧评估：
|
||||
|
||||
- `TestCase.input = { kind: 'variables', values }`
|
||||
- snapshot 可额外带：
|
||||
- `executionInput.content = 渲染后的实际输入`
|
||||
- `executionInput.summary = 变量值摘要`
|
||||
|
||||
### 8.3 context-system
|
||||
|
||||
左侧分析：
|
||||
|
||||
- `target.designContext = conversation-design`
|
||||
- 带目标消息与对话结构
|
||||
|
||||
右侧评估：
|
||||
|
||||
- `TestCase.input = { kind: 'conversation', messages, tools? }`
|
||||
- snapshot 可带：
|
||||
- `executionInput.content = 当前列真正发送给模型的对话快照`
|
||||
|
||||
### 8.4 image
|
||||
|
||||
左侧分析：
|
||||
|
||||
- `target.workspacePrompt`
|
||||
- 必要时加 image 设计态上下文
|
||||
|
||||
右侧评估（未来）：
|
||||
|
||||
- `TestCase.input = { kind: 'image', text?, imageIds? }`
|
||||
- snapshot 持有生成结果摘要
|
||||
|
||||
## 9. 实现分层建议
|
||||
|
||||
### 9.1 core
|
||||
|
||||
目标：
|
||||
|
||||
- 把当前分裂的 `prompt-only / prompt-iterate / result / compare` 输入协议，重构成更稳定的任务模型
|
||||
- 保留 UI 语义，但让底层协议更统一
|
||||
|
||||
建议：
|
||||
|
||||
- 新增 `AnalysisRequest`
|
||||
- 新增 `ExecutionEvaluationRequest`
|
||||
- 保留 `view = single | compare`
|
||||
- 新增 `FocusBrief`
|
||||
- 新增 `CompareAnalysisHints`
|
||||
|
||||
### 9.2 UI 组包层
|
||||
|
||||
目标：
|
||||
|
||||
- 不再让各 workspace 维护一套 `resultTargets + comparePayload` 的拼装习惯
|
||||
|
||||
建议：
|
||||
|
||||
- 每个 workspace 只负责实现：
|
||||
- `buildAnalysisTarget()`
|
||||
- `buildExecutionEvaluationRequest(view)`
|
||||
|
||||
### 9.3 模板层
|
||||
|
||||
目标：
|
||||
|
||||
- 不再把模板写成“散的说明文”
|
||||
- 统一改为结构化 system prompt
|
||||
|
||||
建议：
|
||||
|
||||
- `analysis` 1 套主模板
|
||||
- `execution-single` 1 套主模板
|
||||
- `execution-compare` 1 套主模板
|
||||
- 各模式差异通过 context 注入
|
||||
- `focus` 和跨模型 compare 通过模板条件块切换
|
||||
|
||||
### 9.4 UI 文案层
|
||||
|
||||
建议统一：
|
||||
|
||||
- 左侧：`分析`
|
||||
- 右侧单列：`结果评估`
|
||||
- 右侧多列：`对比评估`
|
||||
- `focus` 输入框文案应更明确表达“优先问题”，而不是弱语义备注
|
||||
|
||||
## 10. 本轮设计最重要的收敛结论
|
||||
|
||||
一句话总结：
|
||||
|
||||
- 下一阶段重构的关键，不是继续修补旧 compare，而是把分析 / 单结果评估 / 对比评估正式建成三类不同任务：共享“当前工作区才是 patch target”的原则，但拥有不同的输入边界、不同的评分 rubric，以及统一但可条件分支的结构化评估模板。
|
||||
385
docs/workspace/compare-evaluation-analysis/history/findings.md
Normal file
385
docs/workspace/compare-evaluation-analysis/history/findings.md
Normal file
@@ -0,0 +1,385 @@
|
||||
# 发现与结论：compare-evaluation-analysis
|
||||
|
||||
> 本文档已经按 2026-03-14 当前代码重写。
|
||||
> 2026-03-16 补充：测试区版本来源已统一为 `workspace / v0 / vN`，`latest` 仅保留为旧 session 迁移输入。
|
||||
> 它不再把“旧实现问题”和“未来方案”混在一起，而是拆成：
|
||||
> 1. 当前已经落地的结构
|
||||
> 2. 仍然存在的真实偏差
|
||||
> 3. 后续如果继续推进，最值得做的下一层改造
|
||||
|
||||
## 1. 当前结论
|
||||
|
||||
这轮重构的大方向已经基本成立：
|
||||
|
||||
- 左侧是 **分析**
|
||||
- 右侧单列是 **评估**
|
||||
- 右侧多列是 **对比评估**
|
||||
|
||||
对应到代码层面：
|
||||
|
||||
- `EvaluationType` 已经收成 `result / compare / prompt-only / prompt-iterate`
|
||||
- 文本 workspace 的单结果评估已经按 `variantId` 工作
|
||||
- compare 已经改成 `workspacePrompt? + variants[]`
|
||||
- compare 模板也已经不再把 A/B 强行解释成 original/optimized
|
||||
|
||||
所以，最核心的语义纠偏已经完成了。
|
||||
|
||||
## 1.1 不要把当前问题继续复杂化
|
||||
|
||||
这里需要刻意做一个收口判断：
|
||||
|
||||
- 当前暴露出来的问题已经分成两层
|
||||
- 第一层是主语义是否正确
|
||||
- 第二层是实现是否已经在所有模式、所有变体上做到完全精确
|
||||
|
||||
当前代码状态更适合这样理解：
|
||||
|
||||
- **第一层已经基本完成**
|
||||
- 左侧分析 vs 右侧评估 vs 右侧对比评估 的语义已经拆开
|
||||
- 文本 workspace 的主结构已经按 `result / compare / prompt-*` 跑起来
|
||||
- **第二层还没有完全完成**
|
||||
- compare 还没有继续演进到 `inputs[] + variants[]` 去重模型
|
||||
- image 右侧评估链路还没补齐
|
||||
|
||||
所以现在不应该把问题表述成：
|
||||
|
||||
- “这轮任务越来越复杂，还没理顺”
|
||||
|
||||
而应表述成：
|
||||
|
||||
- “这轮主任务已经理顺，当前剩下的是后续精度修正项和扩展项”
|
||||
|
||||
这条判断很重要，因为它直接决定后面的工作策略：
|
||||
|
||||
- 不再把所有残留都并入这轮主任务
|
||||
- 先承认文本 workspace 主语义已经基本落地
|
||||
- 再决定要不要继续做 compare 输入建模收口与 image 扩展
|
||||
- 其中 compare 去重建模当前已明确降级为“可选后续优化”
|
||||
|
||||
## 2. 已经落地的结构
|
||||
|
||||
### 2.1 core 侧真实接口
|
||||
|
||||
当前 core 里的核心请求结构已经是：
|
||||
|
||||
```ts
|
||||
export type EvaluationType =
|
||||
| 'result'
|
||||
| 'compare'
|
||||
| 'prompt-only'
|
||||
| 'prompt-iterate'
|
||||
|
||||
export interface ResultEvaluationRequest extends EvaluationRequestBase {
|
||||
type: 'result'
|
||||
prompt: string
|
||||
testResult: string
|
||||
testContent?: string
|
||||
resultLabel?: string
|
||||
}
|
||||
|
||||
export interface CompareEvaluationRequest extends EvaluationRequestBase {
|
||||
type: 'compare'
|
||||
workspacePrompt?: string
|
||||
variants: CompareEvaluationVariant[]
|
||||
}
|
||||
|
||||
export interface CompareEvaluationVariant {
|
||||
id: string
|
||||
label: string
|
||||
prompt: string
|
||||
output: string
|
||||
reasoning?: string
|
||||
modelKey?: string
|
||||
versionLabel?: string
|
||||
input?: {
|
||||
label: string
|
||||
content: string
|
||||
summary?: string
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
这说明：
|
||||
|
||||
- 单结果评估已经是“一个结果快照”的建模。
|
||||
- compare 已经不是旧二元协议。
|
||||
- 但 compare 目前还是一个“简化的多 variant 协议”；是否继续演进到 `inputs[] + variants[]` 去重模型，已不再视为当前 blocker。
|
||||
|
||||
### 2.2 UI 侧真实分层
|
||||
|
||||
当前 `useEvaluationHandler` 已经把三类输入拆开了：
|
||||
|
||||
```ts
|
||||
interface UseEvaluationHandlerOptions {
|
||||
analysisOriginalPrompt?: Ref<string> | ComputedRef<string>
|
||||
analysisOptimizedPrompt: Ref<string> | ComputedRef<string>
|
||||
analysisContext?: Ref<ProEvaluationContext | undefined> | ComputedRef<...>
|
||||
|
||||
resultTargets?: Ref<Record<string, ResultEvaluationTarget>> | ComputedRef<...>
|
||||
comparePayload?: Ref<CompareEvaluationPayload | null> | ComputedRef<...>
|
||||
|
||||
proContext?: Ref<ProEvaluationContext | undefined> | ComputedRef<...>
|
||||
}
|
||||
```
|
||||
|
||||
这层拆分的意义是：
|
||||
|
||||
- 左侧分析已经可以单独收口输入边界
|
||||
- 右侧结果评估已经按 `variantId` 获取目标
|
||||
- 右侧 compare 已经走统一的 `comparePayload`
|
||||
|
||||
### 2.3 文本 workspace 的完成度
|
||||
|
||||
当前 4 个文本 workspace 的主链路都已经切到了新语义：
|
||||
|
||||
- `basic-user`
|
||||
- `basic-system`
|
||||
- `context-user`
|
||||
- `context-system`
|
||||
|
||||
共同点：
|
||||
|
||||
- 右侧单结果评估都已覆盖所有 active variants
|
||||
- compare 都已支持当前 active variants 中任意 `>= 2` 个 ready variants
|
||||
- compare 按钮不再只在 2 列 A/B 模式下出现
|
||||
|
||||
## 3. 这轮已经真正解决了什么
|
||||
|
||||
### 3.1 旧的 `original / optimized` 评估语义已经被拿掉
|
||||
|
||||
这件事不是文案层面的改名，而是实际接线已经改了：
|
||||
|
||||
- core 类型变了
|
||||
- result 模板变了
|
||||
- compare 模板变了
|
||||
- workspace 接线变了
|
||||
|
||||
### 3.2 左侧分析和右侧评估的边界已经被拉开
|
||||
|
||||
尤其是 `context-user`：
|
||||
|
||||
- 左侧分析现在单独走 `analysisContext`
|
||||
- 只带变量结构
|
||||
- 不再默认带变量实例值
|
||||
|
||||
这是本轮最重要的输入边界修正之一。
|
||||
|
||||
### 3.3 compare 已经真正开始围绕“测试快照”而不是“版本身份”
|
||||
|
||||
当前 compare payload 里，每个 variant 已经会带：
|
||||
|
||||
- `id`
|
||||
- `label`
|
||||
- `prompt`
|
||||
- `output`
|
||||
- `reasoning?`
|
||||
- `modelKey?`
|
||||
- `versionLabel?`
|
||||
- `input?`
|
||||
|
||||
这已经足够让 compare 模板不再把问题理解成“优化前后对比”。
|
||||
|
||||
## 4. 当前仍然存在的真实偏差
|
||||
|
||||
这部分是目前最值得在文档里明确写出来的，不然很容易误以为这轮已经完全收口。
|
||||
|
||||
### 4.1 `context-user` 的 compare 已补上 per-variant input snapshot
|
||||
|
||||
当前 `ContextUserWorkspace.vue` 中：
|
||||
|
||||
- 左侧分析用的是 `analysisProContext`
|
||||
- 这部分已经正确，只带变量结构
|
||||
|
||||
右侧单结果评估现在已经会按当前列构造 `proContext`：
|
||||
|
||||
```ts
|
||||
{
|
||||
rawPrompt,
|
||||
resolvedPrompt,
|
||||
variables: buildUsedVariables(..., {
|
||||
includeValues: true,
|
||||
predefinedOverrides: { currentPrompt: rawPrompt, userQuestion: rawPrompt }
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
右侧 compare 现在也会给每个 variant 明确带：
|
||||
|
||||
当前 `context-user` compare payload 会带：
|
||||
|
||||
- prompt
|
||||
- output
|
||||
- reasoning
|
||||
- modelKey
|
||||
- versionLabel
|
||||
- input
|
||||
- `label = Rendered Content`
|
||||
- `content = 当前列渲染后输入`
|
||||
- `summary = 当前列变量值摘要`
|
||||
|
||||
这说明当前 `context-user` compare 的真实状态已经变成：
|
||||
|
||||
- 已经摆脱了 old compare 协议
|
||||
- 单结果评估也已经按 variant 取上下文
|
||||
- 现在也已经像 `basic-*` / `context-system` 那样，把执行态输入快照明确表达出来
|
||||
- 剩余主要是 compare 结构本身还不是更彻底的 `inputs[] + variants[]`
|
||||
|
||||
### 4.2 `context-system` 的单结果评估上下文已经补齐，compare 相对更完整
|
||||
|
||||
`context-system` 现在的状态更接近目标结构：
|
||||
|
||||
- 单结果评估会按当前列单独构造：
|
||||
- `targetMessage`
|
||||
- `conversationMessages`
|
||||
- compare payload 也会给每个 variant 带 `Conversation Snapshot`
|
||||
|
||||
所以它当前更像是：
|
||||
|
||||
- 单结果评估链路已经到位
|
||||
- compare 也已经具备较完整的执行态输入表达
|
||||
|
||||
### 4.3 image 模式仍然只停留在左侧分析
|
||||
|
||||
当前 image 模式：
|
||||
|
||||
- 有左侧分析入口
|
||||
- `useEvaluationHandler` 只被用来处理 `prompt-only`
|
||||
- core 模板目录下也只有 image 的 `evaluation-prompt-only`
|
||||
|
||||
所以现在不应该把 image 写成“只是还差一点 compare”。
|
||||
|
||||
更准确的说法是：
|
||||
|
||||
- image 右侧结果评估 / 对比评估主链路都还没有完成
|
||||
|
||||
### 4.4 还有一些内部残留还没清干净
|
||||
|
||||
例如：
|
||||
|
||||
- `ConversationTestPanel.vue`
|
||||
- `ContextUserTestPanel.vue`
|
||||
- `TestAreaPanel.vue`
|
||||
|
||||
内部 tool-call 分桶仍在使用：
|
||||
|
||||
- `COMPARE_BASELINE_VARIANT_ID`
|
||||
- `COMPARE_CANDIDATE_VARIANT_ID`
|
||||
|
||||
这不影响当前主语义，但说明“内部彻底去旧 compare 化”还没完全做完。
|
||||
|
||||
另外：
|
||||
|
||||
- `usePromptTester.ts`
|
||||
- `useConversationTester.ts`
|
||||
- `useContextUserTester.ts`
|
||||
|
||||
这些旧测试 helper 仍然在仓库里，虽然当前文本 workspace 主链路已经不再依赖它们。
|
||||
|
||||
## 5. 当前文档最应该怎么理解
|
||||
|
||||
如果后续模型或开发者要快速判断“现在代码到了哪一步”，建议按下面这套口径理解：
|
||||
|
||||
### 已完成
|
||||
|
||||
- 语义分层已经完成第一阶段
|
||||
- core 请求已经不再围绕 original/optimized
|
||||
- 文本 workspace 已经具备 variant 化的 result / compare 能力
|
||||
- 左侧分析输入边界已经开始收口
|
||||
|
||||
### 未完成
|
||||
|
||||
- compare 还没有演进到 `inputs[] + variants[]` 去重模型
|
||||
- image 右侧评估链路还没补齐
|
||||
- 一些旧 compare internal naming 仍残留在共享组件和旧 helper 中
|
||||
|
||||
## 6. 如果继续推进，最值得做的下一层改造
|
||||
|
||||
这里不再写大而全的终局方案，而只写当前代码基础上最自然的下一步。
|
||||
|
||||
在进入这些下一步之前，建议先明确一个判断标准：
|
||||
|
||||
- **文本 workspace 主语义重构** 可以视为当前阶段已基本完成
|
||||
- 下面这些工作不应再被包装成“否则本轮不成立”
|
||||
- 它们更适合被视为“下一阶段增强”
|
||||
|
||||
### 第 1 优先级：补齐 image 右侧评估链路或明确继续排除
|
||||
|
||||
目标：
|
||||
|
||||
- image 有多列测试 UI
|
||||
- 但没有完整的右侧评估链路
|
||||
|
||||
后续最好二选一：
|
||||
|
||||
1. 正式补 image 的 `result` / `compare` 模板和接线
|
||||
2. 或者在产品和文档里明确写成“image 当前只支持左侧分析”
|
||||
|
||||
### 第 2 优先级：清理内部旧 compare 残留
|
||||
|
||||
这包括：
|
||||
|
||||
- shared panel 内部的 compare baseline/candidate 常量
|
||||
- 旧 tester helper
|
||||
- 一些只剩兼容意义的旧命名
|
||||
|
||||
这一步不是当前功能正确性的 blocker，但能减少后续维护成本。
|
||||
|
||||
## 7. 下一步工作的收敛建议
|
||||
|
||||
如果按“不继续复杂化当前任务”的原则，下一步工作建议按下面顺序推进：
|
||||
|
||||
### 7.1 先停在文档与任务边界收口
|
||||
|
||||
目标：
|
||||
|
||||
- 明确告诉后续开发者：文本 workspace 的主语义重构已经基本完成
|
||||
- `pro` 精度问题与 image 扩展不是这轮 blocker
|
||||
|
||||
这是为了避免后续工作继续失焦。
|
||||
|
||||
### 7.2 如果要继续做代码，优先决定 compare 是否继续走去重模型
|
||||
|
||||
原因：
|
||||
|
||||
- 这是当前文本主链路里最真实、最具体的剩余结构问题
|
||||
- 它比清理命名残留更影响 compare 评估质量
|
||||
- 它比 image 扩展更贴近当前主任务脉络
|
||||
|
||||
建议拆成两个小步：
|
||||
|
||||
1. 先确认是否真的需要去重共享输入
|
||||
2. 再决定 compare 是否进一步演进成 `inputs[] + variants[]`
|
||||
|
||||
### 7.3 image 暂时单独立项，不混入当前文本主线
|
||||
|
||||
原因：
|
||||
|
||||
- image 不是“差最后一点”
|
||||
- 它实际上缺的是一整段右侧评估能力
|
||||
- 和文本主链路的剩余工作不是同一种量级
|
||||
|
||||
### 7.4 内部旧 compare 残留最后清
|
||||
|
||||
像这些内容：
|
||||
|
||||
- `COMPARE_BASELINE_VARIANT_ID`
|
||||
- `COMPARE_CANDIDATE_VARIANT_ID`
|
||||
- 旧 tester helper
|
||||
|
||||
更适合作为“收尾清理”，而不是下一步第一优先级。
|
||||
|
||||
### 第 3 优先级：如果确实有收益，再决定 compare 是否继续去重建模
|
||||
|
||||
目标：
|
||||
|
||||
- 去重共享输入
|
||||
- 明确输入引用关系
|
||||
- 降低 token 重复
|
||||
|
||||
但当前这一步已经明确不是主线 blocker，更适合作为后续精修项。
|
||||
|
||||
## 8. 当前最简洁的任务判断
|
||||
|
||||
如果要把现在的状态收成一句话，可以直接写：
|
||||
|
||||
- 文本 workspace 的“分析 / 评估 / 对比评估”主语义已经基本重构完成，测试区版本来源也已统一到 `workspace / v0 / vN`；当前主线剩余问题主要是 image 模式右侧评估链路缺失，compare 去重建模属于可选后续优化。
|
||||
@@ -0,0 +1,492 @@
|
||||
# 分析 / 评估输入最小化与去重规范
|
||||
|
||||
> 本文档用于收敛一个核心约束：
|
||||
> 在一次 LLM 请求中，同一份长内容应尽量只出现一次。
|
||||
>
|
||||
> 这里的“长内容”包括但不限于：
|
||||
> - 原始提示词
|
||||
> - 当前工作区提示词
|
||||
> - 历史版本提示词
|
||||
> - 变量值
|
||||
> - 测试文本
|
||||
> - 会话上下文
|
||||
> - 大段 JSON / 结构化上下文
|
||||
|
||||
## 1. 为什么需要这份规范
|
||||
|
||||
当前分析 / 评估链路已经完成语义重构，但还存在一个独立问题：
|
||||
|
||||
- 某些请求仍可能携带多份相近或重复的大块文本
|
||||
- 即使语义上没有错误，也会带来 token 浪费与注意力分散
|
||||
- 对于左侧分析尤其明显：一旦同时出现“原始提示词 + 当前工作区提示词”，模型很容易把任务理解成“对比阅读”，而不是“分析当前工作区”
|
||||
|
||||
因此需要补上一条更强的设计原则：
|
||||
|
||||
## 2. 总原则
|
||||
|
||||
### 2.1 单次请求中的硬约束
|
||||
|
||||
1. 同一份长内容，在一次请求里最多出现一次。
|
||||
2. 如果某类信息不是当前任务的直接证据，就不要发送。
|
||||
3. 如果某类信息只是辅助理解，应优先传“短摘要”，而不是原文全文。
|
||||
4. 左侧分析只看设计态信息，右侧评估只看执行态证据。
|
||||
|
||||
### 2.2 任务优先级规则
|
||||
|
||||
#### 分析 `prompt-only / prompt-iterate`
|
||||
|
||||
- 核心目标：分析当前工作区提示词设计质量
|
||||
- 唯一主对象：当前工作区提示词
|
||||
- 不应被原始提示词、右侧测试输入、右侧输出分散注意力
|
||||
|
||||
#### 单结果评估 `result`
|
||||
|
||||
- 核心目标：评估一次执行快照本身
|
||||
- 唯一证据：测试输入、执行提示词、执行输出
|
||||
- 不应再额外注入当前工作区提示词全文
|
||||
|
||||
#### 对比评估 `compare`
|
||||
|
||||
- 核心目标：比较多个执行快照，提炼可迁移规律
|
||||
- 唯一证据：公共测试输入、各快照自己的执行提示词与输出
|
||||
- 公共输入只能出现一次，不应在每个快照里重复展开
|
||||
|
||||
## 3. 左侧分析的最小输入规则
|
||||
|
||||
### 3.1 `basic/user` 与 `basic/system`
|
||||
|
||||
默认只发送：
|
||||
|
||||
1. `workspacePrompt`
|
||||
2. `focus`，如果有
|
||||
|
||||
默认不发送：
|
||||
|
||||
1. `referencePrompt`
|
||||
2. “工作区来源说明”“是否已保存版本”等 UI 状态信息
|
||||
3. 右侧测试文本
|
||||
4. 右侧变量值
|
||||
5. 右侧测试输出
|
||||
|
||||
原因：
|
||||
|
||||
- 左侧分析的任务是“分析当前工作区提示词”，不是“比较当前与原始提示词”
|
||||
- 当原始提示词和工作区提示词都很长时，同时出现会严重分散注意力
|
||||
- UI 来源说明通常不构成提示词设计语义的一部分
|
||||
|
||||
### 3.2 `pro/variable`
|
||||
|
||||
默认只发送：
|
||||
|
||||
1. `workspacePrompt`
|
||||
2. `focus`，如果有
|
||||
|
||||
按需可发送的最小设计态上下文：
|
||||
|
||||
1. 变量名列表
|
||||
2. 变量语义说明
|
||||
3. 变量之间的关系说明
|
||||
|
||||
默认不发送：
|
||||
|
||||
1. 变量实际测试值
|
||||
2. 渲染后的 resolved prompt
|
||||
3. 某次右侧测试时填写的变量输入
|
||||
|
||||
建议格式：
|
||||
|
||||
```md
|
||||
## 当前工作区变量提示词
|
||||
...
|
||||
|
||||
## 变量结构说明
|
||||
- 风格: 诗歌风格
|
||||
- 主题: 诗歌主题
|
||||
```
|
||||
|
||||
不建议格式：
|
||||
|
||||
```md
|
||||
## 变量上下文
|
||||
风格=中文古典
|
||||
主题=一大段很长的业务输入
|
||||
```
|
||||
|
||||
原因：
|
||||
|
||||
- 左侧分析分析的是模板设计，不是某次实例化执行
|
||||
- 长变量值会把设计分析污染成样例分析
|
||||
|
||||
当前已落地验证：
|
||||
|
||||
- `basic-user` / `basic-system` 已完成最小输入收敛
|
||||
- `pro/variable prompt-only` 已完成最小结构上下文收敛
|
||||
- 对应真实请求样例可见：
|
||||
- `real-api-samples/pro-variable-prompt-only`
|
||||
- `real-api-samples/pro-variable-prompt-only-current`
|
||||
- `real-api-samples/pro-variable-prompt-only-minimal`
|
||||
|
||||
### 3.3 `pro/multi`
|
||||
|
||||
默认只发送：
|
||||
|
||||
1. 当前工作区目标消息 / 当前工作区提示词
|
||||
2. `focus`，如果有
|
||||
|
||||
按需可发送的最小设计态上下文：
|
||||
|
||||
1. 被分析消息的角色
|
||||
2. 与该消息直接相邻、直接相关的极短会话上下文
|
||||
3. 使用显式位置标记，指出当前工作区提示词在会话中的位置
|
||||
|
||||
默认不发送：
|
||||
|
||||
1. 完整长会话全文
|
||||
2. 右侧测试时的整段对话输入
|
||||
3. 某次测试输出
|
||||
|
||||
原因：
|
||||
|
||||
- 多消息模式左侧分析仍然是设计分析，不是执行复盘
|
||||
- 完整会话很容易成为请求中最大的 token 消耗源
|
||||
|
||||
推荐格式：
|
||||
|
||||
当选中 `system` 消息时：
|
||||
|
||||
```md
|
||||
## 当前工作区上下文消息提示词
|
||||
你是一个诗人
|
||||
|
||||
## 会话上下文
|
||||
目标消息角色: system
|
||||
- system: 【当前工作区要优化的提示词】
|
||||
- user: 请你写一首关于{{主题}}的诗。
|
||||
```
|
||||
|
||||
当选中 `user` 消息时：
|
||||
|
||||
```md
|
||||
## 当前工作区上下文消息提示词
|
||||
请你写一首关于{{主题}}的诗。
|
||||
|
||||
## 会话上下文
|
||||
目标消息角色: user
|
||||
- system: 你是一个诗人
|
||||
- user: 【当前工作区要优化的提示词】
|
||||
```
|
||||
|
||||
不推荐格式：
|
||||
|
||||
```md
|
||||
## 会话摘要
|
||||
这是一个诗歌创作场景，system 负责定义角色，user 负责提出写诗需求...
|
||||
```
|
||||
|
||||
也不推荐：
|
||||
|
||||
```md
|
||||
## 完整会话 JSON
|
||||
{
|
||||
"targetMessage": ...,
|
||||
"conversationMessages": [...]
|
||||
}
|
||||
```
|
||||
|
||||
原因：
|
||||
|
||||
- `pro/multi` 左侧分析仍然是设计分析，不是执行复盘
|
||||
- 模型真正需要的是“当前工作区提示词在会话里的位置关系”，而不是泛化摘要
|
||||
- 显式位置标记比“相关会话摘要”更稳定，也更便于长提示词场景下控制 token
|
||||
- 完整 transcript 或 JSON 很容易成为请求中最大的 token 消耗源
|
||||
|
||||
真实对照补充：
|
||||
|
||||
- `real-api-samples/pro-multi-prompt-only-current`
|
||||
- 当前实现会重复带入 `workspacePrompt / referencePrompt / targetMessage.content / conversationMessages`
|
||||
- `real-api-samples/pro-multi-prompt-only-minimal`
|
||||
- 对照旧最小化尝试，主要用于证明减少重复输入不会明显损伤分析能力
|
||||
- `real-api-samples/pro-multi-prompt-only-system-selected`
|
||||
- 使用最简单的双消息示例，并显式标记当前工作区提示词在 `system` 位置
|
||||
- `real-api-samples/pro-multi-prompt-only-user-selected`
|
||||
- 使用最简单的双消息示例，并显式标记当前工作区提示词在 `user` 位置
|
||||
|
||||
目前真实返回对照显示：
|
||||
|
||||
- 两者 `overall` 都是 `70`
|
||||
- 但最小化版本耗时明显更短，请求更聚焦
|
||||
|
||||
因此，`pro/multi prompt-only` 的推荐最终形态不是“泛摘要”，而是“最少量、带位置引用的会话上下文”。
|
||||
|
||||
当前已落地：
|
||||
|
||||
- `pro/multi prompt-only` 左侧分析现在默认不再发送 `referencePrompt`
|
||||
- 当前 `designContext` 已收敛为：
|
||||
- 目标消息角色
|
||||
- 会话中的明确位置引用
|
||||
- 与目标消息直接相关的最少量上下文消息
|
||||
- 最终态真实样例可见：
|
||||
- `real-api-samples/pro-multi-prompt-only`
|
||||
- `real-api-samples/pro-multi-prompt-only-system-selected`
|
||||
- `real-api-samples/pro-multi-prompt-only-user-selected`
|
||||
|
||||
### 3.4 `image/*`
|
||||
|
||||
当前仍按左侧分析处理，建议遵守同样规则：
|
||||
|
||||
- 只发送当前工作区图像提示词
|
||||
- 设计意图只发简短摘要
|
||||
- 不重复发送参考提示词全文
|
||||
|
||||
## 4. 右侧单结果评估的最小输入规则
|
||||
|
||||
### 4.1 统一原则
|
||||
|
||||
右侧单结果评估只发送这一次执行所必需的证据：
|
||||
|
||||
1. `testCase.input`
|
||||
2. `snapshot.promptText`
|
||||
3. `snapshot.output`
|
||||
4. `snapshot.executionInput`，仅当其不同于公共测试输入且确有必要
|
||||
5. `focus`，如果有
|
||||
|
||||
默认不发送：
|
||||
|
||||
1. `target.workspacePrompt` 全文
|
||||
2. `target.referencePrompt` 全文
|
||||
3. 其他版本提示词全文
|
||||
4. 与本次执行无关的变量值或上下文
|
||||
|
||||
### 4.2 `basic/user` / `basic/system`
|
||||
|
||||
推荐结构：
|
||||
|
||||
```md
|
||||
## 测试用例输入
|
||||
...
|
||||
|
||||
## 执行快照 A
|
||||
### 执行提示词
|
||||
...
|
||||
|
||||
### 输出
|
||||
...
|
||||
```
|
||||
|
||||
不应额外再出现：
|
||||
|
||||
```md
|
||||
## 当前工作区提示词
|
||||
...
|
||||
|
||||
## 参考提示词
|
||||
...
|
||||
```
|
||||
|
||||
原因：
|
||||
|
||||
- 这会把“结果评估”重新污染成“对工作区的先验判断”
|
||||
- 尤其当当前工作区并不是本次执行提示词时，模型会被误导
|
||||
|
||||
### 4.3 `pro/variable`
|
||||
|
||||
右侧 `result` 时，变量值是执行证据的一部分，因此可以发送，但应只出现一次。
|
||||
|
||||
推荐：
|
||||
|
||||
- 放在 `testCase.input`
|
||||
- 或放在 `snapshot.executionInput`
|
||||
- 但二者只能选一个，不要重复
|
||||
|
||||
不推荐：
|
||||
|
||||
- 既在公共测试输入里写变量值
|
||||
- 又在执行快照里再写一遍渲染后输入
|
||||
- 又在系统 / 用户提示词其他位置再写一次当前工作区提示词
|
||||
|
||||
### 4.4 `pro/multi`
|
||||
|
||||
右侧 `result` 时，会话片段也是执行证据的一部分，因此可以发送，但必须控制长度。
|
||||
|
||||
推荐：
|
||||
|
||||
- 公共用户输入进 `testCase.input`
|
||||
- 确有必要的附加会话状态进 `snapshot.executionInput`
|
||||
|
||||
不推荐：
|
||||
|
||||
- 把完整长会话同时塞进 `testCase.input` 和 `executionInput`
|
||||
|
||||
## 5. 右侧对比评估的最小输入规则
|
||||
|
||||
### 5.1 公共输入上提
|
||||
|
||||
凡是多个快照共享的信息，应上提到 `testCases[]`，只出现一次。
|
||||
|
||||
包括：
|
||||
|
||||
1. 测试文本
|
||||
2. 变量输入
|
||||
3. 共享设置摘要
|
||||
4. 共享会话输入
|
||||
|
||||
### 5.2 快照只保留独有证据
|
||||
|
||||
每个 `snapshot` 只保留自己的：
|
||||
|
||||
1. `promptText`
|
||||
2. `output`
|
||||
3. `reasoning`，如果有
|
||||
4. `modelKey`
|
||||
5. `versionLabel`
|
||||
6. `executionInput`，仅当该输入是该快照独有信息
|
||||
|
||||
### 5.3 默认不发送的内容
|
||||
|
||||
1. `workspacePrompt` 全文
|
||||
2. `referencePrompt` 全文
|
||||
3. 每个快照重复展开的公共测试输入
|
||||
4. 每个快照重复展开的长变量值
|
||||
5. 每个快照重复展开的渲染后完整输入
|
||||
|
||||
### 5.4 `basic/user` / `basic/system`
|
||||
|
||||
推荐结构：
|
||||
|
||||
```md
|
||||
## 公共测试用例（1）
|
||||
### 测试用例 测试内容
|
||||
#### 输入
|
||||
...
|
||||
|
||||
## 执行快照（2）
|
||||
### 快照 A
|
||||
#### 执行提示词
|
||||
...
|
||||
#### 输出
|
||||
...
|
||||
|
||||
### 快照 B
|
||||
#### 执行提示词
|
||||
...
|
||||
#### 输出
|
||||
...
|
||||
```
|
||||
|
||||
不应再出现：
|
||||
|
||||
```md
|
||||
## 当前工作区提示词
|
||||
...
|
||||
```
|
||||
|
||||
因为 compare 的评分证据应是多快照本身，而不是工作区全文。
|
||||
|
||||
### 5.5 `pro/variable`
|
||||
|
||||
推荐：
|
||||
|
||||
- 变量值只在公共测试输入块出现一次
|
||||
- 每个快照只放模板提示词 / 执行提示词与输出
|
||||
|
||||
不推荐：
|
||||
|
||||
- 在快照里再重复写“变量: 风格=..., 主题=...”
|
||||
- 再重复写一遍“渲染后的完整输入”
|
||||
|
||||
因为变量和提示词都可能很长，重复一次成本就会快速放大。
|
||||
|
||||
### 5.6 `pro/multi`
|
||||
|
||||
推荐：
|
||||
|
||||
- 共享用户问题、共享前置消息摘要放在公共测试输入
|
||||
- 某个快照独有的附加上下文再放在 `executionInput`
|
||||
|
||||
不推荐：
|
||||
|
||||
- 每个快照都重复带整段会话 transcript
|
||||
|
||||
## 6. 关于 `referencePrompt` 的最终策略
|
||||
|
||||
为避免行为复杂化，建议先采用简单稳定规则：
|
||||
|
||||
1. 左侧分析默认不发送 `referencePrompt`
|
||||
2. 右侧单结果评估默认不发送 `referencePrompt`
|
||||
3. 右侧对比评估默认不发送 `referencePrompt`
|
||||
|
||||
如果未来确实需要保留“原始意图”的辅助价值，建议不要做“长度阈值判断”这种隐式策略，而是显式设计成另一种任务模式，例如：
|
||||
|
||||
- 普通分析：只看当前工作区
|
||||
- 对照分析：工作区 + 原始意图摘要
|
||||
|
||||
在当前阶段，不建议：
|
||||
|
||||
- “短 prompt 时带 reference，长 prompt 时不带”
|
||||
|
||||
原因：
|
||||
|
||||
- 行为不稳定
|
||||
- 用户难以预期
|
||||
- 后续维护成本高
|
||||
|
||||
## 7. 关于 `designContext` 的最终策略
|
||||
|
||||
`designContext` 只应保留真正服务于“设计语义理解”的内容。
|
||||
|
||||
允许：
|
||||
|
||||
1. 变量结构说明
|
||||
2. 会话角色说明
|
||||
3. 图像风格目标摘要
|
||||
4. 非执行态的简短背景约束
|
||||
|
||||
不允许：
|
||||
|
||||
1. 工作区来源说明
|
||||
2. “来自原始区域复制”
|
||||
3. “尚未保存版本”
|
||||
4. 右侧测试文本
|
||||
5. 右侧变量实际值
|
||||
6. 右侧输出摘要
|
||||
|
||||
## 8. 推荐的最终默认策略
|
||||
|
||||
### 8.1 左侧分析
|
||||
|
||||
- 只发 `workspacePrompt`
|
||||
- 有 `focus` 就加 `focus`
|
||||
- 默认不发 `referencePrompt`
|
||||
- 默认不发 `designContext`
|
||||
- 如必须发 `designContext`，只允许极短摘要，且不得包含执行态证据
|
||||
|
||||
### 8.2 单结果评估
|
||||
|
||||
- 只发 `testCase.input`
|
||||
- 只发当前 `snapshot.promptText`
|
||||
- 只发当前 `snapshot.output`
|
||||
- 可选发当前 `snapshot.executionInput`
|
||||
- 有 `focus` 就加 `focus`
|
||||
- 不额外发 `workspacePrompt`
|
||||
|
||||
### 8.3 对比评估
|
||||
|
||||
- 公共输入只发一次
|
||||
- 每个快照只发自己的 prompt / output / reasoning
|
||||
- 有 `focus` 就加 `focus`
|
||||
- 不额外发 `workspacePrompt`
|
||||
- 不重复发变量值、渲染后输入、公共会话文本
|
||||
|
||||
## 9. 这份规范对当前代码收敛的直接含义
|
||||
|
||||
如果按这份规范继续收敛，当前最优先的方向应是：
|
||||
|
||||
1. `basic/user prompt-only`
|
||||
- 去掉默认 `referencePrompt`
|
||||
- 去掉默认 `designContext`
|
||||
2. 其余 `prompt-only`
|
||||
- 仅保留最小设计态上下文
|
||||
3. `result / compare`
|
||||
- 持续检查是否仍有重复注入长内容
|
||||
4. 所有模式
|
||||
- 把“同一长内容只出现一次”当作协议层约束，而不是模板层偶然结果
|
||||
@@ -0,0 +1,458 @@
|
||||
# 整体重构梳理：分析、评估与多测试对比评估
|
||||
|
||||
> 这份文档不是在补充某个局部细节，而是把这次讨论整体收成一个新框架。
|
||||
> 核心目的只有一个：以后不要再把左侧“分析”和右侧“评估”当成同一种结构的不同变体。
|
||||
>
|
||||
> 状态说明（2026-03-14）：
|
||||
> 这份文档的核心边界定义仍然有效，但其中部分“接下来要做”的内容，当前代码已经落地了一部分。
|
||||
> 最新实现状态请优先参考：
|
||||
> - `current-analysis-feature-map.md`
|
||||
> - `progress.md`
|
||||
>
|
||||
> 进一步说明：
|
||||
> - 文本 workspace 的 `result / compare / prompt-*` 主语义已经基本落地。
|
||||
> - 文中凡是把“当前实现”写成 A/B only、`original / optimized`、或“单结果评估只覆盖 A/B”的段落，应理解为前期问题背景，而不是当前代码事实。
|
||||
> - 当前真正还没完全收口的，主要是 compare 结构还没有继续演进到 `inputs[] + variants[]`，以及 image 模式右侧评估链路。
|
||||
|
||||
## 1. 最终结论
|
||||
|
||||
当前功能在产品表面上都叫“分析 / 评估”，但从结构上看，后续应该明确拆成 3 类并列能力：
|
||||
|
||||
1. **分析（analysis）**
|
||||
2. **单结果评估（single evaluation）**
|
||||
3. **对比评估（compare evaluation）**
|
||||
|
||||
它们不是一个大接口的 3 个小分支，而是：
|
||||
|
||||
- 分析：看“设计对象本身”
|
||||
- 单结果评估：看“一次执行结果”
|
||||
- 对比评估：看“多次执行结果之间的关系”
|
||||
|
||||
这点在“评估要升级成支持多个测试变体”之后会更加明显。
|
||||
|
||||
## 1.1 当前主任务（收敛版）
|
||||
|
||||
基于最新讨论，这轮主任务可以收成下面 3 条：
|
||||
|
||||
1. 明确区分“分析”和“评估”的语义、结构与 UI 文案。
|
||||
2. 矫正分析功能，默认不准引用右侧测试内容和变量实例值。
|
||||
3. 重构评估功能，使其基于测试快照支持单结果评估与多测试对比评估，不再依赖左侧“优化前/优化后”的版本语义。
|
||||
|
||||
再补一个实现原则：
|
||||
|
||||
- **评估基于测试快照，修改统一面向左侧当前工作区；无法应用就跳过，不建立版本绑定关系。**
|
||||
|
||||
## 2. 为什么现在必须拆开
|
||||
|
||||
在旧模型里，大家容易把它们混在一起，是因为：
|
||||
|
||||
- compare 当时还只有 A/B 两列
|
||||
- 右侧评估的输入结构还比较扁平
|
||||
- 左侧分析和右侧评估都复用了同一套 `EvaluationType` 话语体系
|
||||
|
||||
但如果评估真的要支持：
|
||||
|
||||
- 2/3/4 个测试列
|
||||
- 每列不同模型
|
||||
- 每列不同版本
|
||||
- 输入去重
|
||||
- 多输出统一对比
|
||||
|
||||
那右侧评估天然就会长成“测试变体集合”的结构。
|
||||
|
||||
而左侧分析不会。
|
||||
|
||||
左侧分析更像：
|
||||
|
||||
- 当前 prompt 是什么
|
||||
- 原始参考内容是什么
|
||||
- 当前上下文是什么
|
||||
- 当前变量设计是什么
|
||||
- 当前迭代要求是什么
|
||||
|
||||
右侧评估更像：
|
||||
|
||||
- 这次实际用了哪段 prompt 快照
|
||||
- 这次实际跑了什么输入
|
||||
- 用了什么模型
|
||||
- 产出了什么输出
|
||||
|
||||
右侧对比评估更像：
|
||||
|
||||
- 这些测试变体之间，谁共享输入
|
||||
- 谁模型不同
|
||||
- 谁版本不同
|
||||
- 哪些输出更好
|
||||
|
||||
所以从这一步开始，再把“分析”和“评估”强行塞回同一请求结构里，成本会越来越高。
|
||||
|
||||
## 3. 新的总体边界
|
||||
|
||||
后续建议用下面这套边界统一全局。
|
||||
|
||||
### 3.1 分析
|
||||
|
||||
分析回答的是：
|
||||
|
||||
- 这个 prompt / context 本身设计得好不好？
|
||||
- 变量设计是否清晰？
|
||||
- 结构是否合理？
|
||||
- 当前修改方向是否符合迭代目标？
|
||||
|
||||
分析默认应具有这些特点：
|
||||
|
||||
- **不依赖测试输出**
|
||||
- **不默认依赖右侧测试样本值**
|
||||
- 更接近“设计态检查”
|
||||
|
||||
分析应该主要消费：
|
||||
|
||||
- 当前 prompt / message / context 文本
|
||||
- 原始参考文本
|
||||
- 变量 schema
|
||||
- 会话结构
|
||||
- 迭代要求
|
||||
|
||||
### 3.2 单结果评估
|
||||
|
||||
单结果评估回答的是：
|
||||
|
||||
- 这一次测试跑出来的结果好不好？
|
||||
- 这次输入和输出是否匹配？
|
||||
|
||||
单结果评估默认应具有这些特点：
|
||||
|
||||
- **依赖一个真实测试输出**
|
||||
- 关注“输入 + 输出”的效果
|
||||
- 更接近“执行态评估”
|
||||
|
||||
单结果评估应该主要消费：
|
||||
|
||||
- 一次测试时实际使用的 prompt 快照
|
||||
- 一次实际测试输入
|
||||
- 一个模型
|
||||
- 一个输出结果
|
||||
|
||||
### 3.3 对比评估
|
||||
|
||||
对比评估回答的是：
|
||||
|
||||
- 多个测试变体之间谁更好？
|
||||
- 差异来自提示词、模型，还是执行输入？
|
||||
- 哪些变体共享输入，哪些不是？
|
||||
|
||||
对比评估默认应具有这些特点：
|
||||
|
||||
- **依赖多个真实测试输出**
|
||||
- 关注“变体之间的关系”
|
||||
- 更接近“实验对比”
|
||||
|
||||
对比评估应该主要消费：
|
||||
|
||||
- 去重后的输入列表
|
||||
- 多个测试变体
|
||||
- 每个变体的模型、输入引用、输出
|
||||
|
||||
## 4. 一个更清楚的三层输入模型
|
||||
|
||||
为了避免后面再把“测试文本”“变量值”“prompt 结构”“输出结果”混在一起，建议先把输入分成 3 层。
|
||||
|
||||
### 4.1 设计态输入
|
||||
|
||||
这层输入是给分析用的，典型包括：
|
||||
|
||||
- prompt / message / context 正文
|
||||
- 原始版本
|
||||
- 变量名、变量来源、是否缺失
|
||||
- 会话结构
|
||||
- 迭代要求
|
||||
|
||||
它回答的是：
|
||||
|
||||
- 你设计了什么
|
||||
|
||||
### 4.2 执行态输入
|
||||
|
||||
这层输入是给评估用的，典型包括：
|
||||
|
||||
- 测试文本
|
||||
- 当前变量实例值
|
||||
- 当前模型
|
||||
- 当前工具配置
|
||||
- 渲染后的最终输入
|
||||
|
||||
它回答的是：
|
||||
|
||||
- 你实际拿什么去跑了
|
||||
|
||||
### 4.3 执行态输出
|
||||
|
||||
这层输入是评估和对比评估都要看的，典型包括：
|
||||
|
||||
- 文本输出
|
||||
- reasoning
|
||||
- 图像结果摘要
|
||||
|
||||
它回答的是：
|
||||
|
||||
- 跑出来了什么
|
||||
|
||||
映射起来就是：
|
||||
|
||||
- 分析：主要看设计态输入
|
||||
- 单结果评估：看执行态输入 + 执行态输出
|
||||
- 对比评估：看多个执行态输入来源 + 多个执行态输出
|
||||
|
||||
## 5. 为什么“变量值默认进入分析”应该被纠正
|
||||
|
||||
这是这次梳理里一个很重要的新结论。
|
||||
|
||||
当前 `context-user` 左侧分析会带：
|
||||
|
||||
- `variables`
|
||||
- `rawPrompt`
|
||||
- `resolvedPrompt`
|
||||
|
||||
这说明当前实现确实会把变量实例值喂给左侧分析。
|
||||
|
||||
但这更像历史实现结果，不适合直接固化成目标设计。
|
||||
|
||||
原因是：
|
||||
|
||||
1. 左侧分析应该优先看模板设计，而不是某次样本值
|
||||
2. 样本值属于测试执行上下文，更适合进入右侧评估
|
||||
3. 如果默认把样本值塞给分析，分析结论会过度依赖当前测试态
|
||||
|
||||
更合理的边界是：
|
||||
|
||||
- **默认分析**：看变量 schema，不看变量实例值
|
||||
- **诊断分析**：必要时显式带变量实例值
|
||||
- **评估 / 对比评估**：正常带变量实例值
|
||||
|
||||
也就是说：
|
||||
|
||||
- “变量语义”属于分析
|
||||
- “变量样本值”默认属于评估
|
||||
|
||||
## 6. 结构上应该怎么拆
|
||||
|
||||
从接口角度，建议后续至少拆成 3 类请求。
|
||||
|
||||
### 6.1 PromptAnalysisRequest
|
||||
|
||||
它代表左侧分析。
|
||||
|
||||
```ts
|
||||
export interface PromptAnalysisRequest {
|
||||
type: 'prompt-only' | 'prompt-iterate'
|
||||
target: {
|
||||
mode: 'basic-user' | 'basic-system' | 'context-user' | 'context-system' | 'image'
|
||||
original?: string
|
||||
current: string
|
||||
}
|
||||
context?: {
|
||||
conversation?: unknown
|
||||
variableSchema?: Array<{
|
||||
name: string
|
||||
source: 'predefined' | 'global' | 'temporary'
|
||||
required?: boolean
|
||||
}>
|
||||
}
|
||||
iterateRequirement?: string
|
||||
}
|
||||
```
|
||||
|
||||
关键点：
|
||||
|
||||
- 不带测试输出
|
||||
- 不默认带变量实例值
|
||||
|
||||
### 6.2 SingleTestEvaluationRequest
|
||||
|
||||
它代表右侧单列评估。
|
||||
|
||||
```ts
|
||||
export interface SingleTestEvaluationRequest {
|
||||
type: 'single'
|
||||
snapshot: {
|
||||
id: 'a' | 'b' | 'c' | 'd'
|
||||
label: string
|
||||
model: {
|
||||
key: string
|
||||
providerId?: string
|
||||
modelId?: string
|
||||
}
|
||||
prompt: {
|
||||
mode: string
|
||||
content: string
|
||||
}
|
||||
executionInput: {
|
||||
mode: string
|
||||
summary: string
|
||||
body: string
|
||||
}
|
||||
output: {
|
||||
kind: 'text' | 'image'
|
||||
content: string
|
||||
reasoning?: string
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
关键点：
|
||||
|
||||
- 一个请求只评估一个真实测试快照
|
||||
- 不需要知道它是“优化前”还是“优化后”
|
||||
- 结构中心是 `snapshot`
|
||||
|
||||
### 6.3 MultiVariantCompareEvaluationRequest
|
||||
|
||||
它代表右侧多测试对比评估。
|
||||
|
||||
```ts
|
||||
export interface MultiVariantCompareEvaluationRequest {
|
||||
type: 'compare'
|
||||
inputs: Array<{
|
||||
id: string
|
||||
fingerprint: string
|
||||
mode: string
|
||||
title: string
|
||||
summary: string
|
||||
body: string
|
||||
}>
|
||||
variants: Array<{
|
||||
id: 'a' | 'b' | 'c' | 'd'
|
||||
label: string
|
||||
model: {
|
||||
key: string
|
||||
providerId?: string
|
||||
modelId?: string
|
||||
}
|
||||
inputId: string
|
||||
output: {
|
||||
kind: 'text' | 'image'
|
||||
content: string
|
||||
reasoning?: string
|
||||
}
|
||||
}>
|
||||
}
|
||||
```
|
||||
|
||||
关键点：
|
||||
|
||||
- 结构中心不再是 `original/optimized`
|
||||
- 而是 `inputs[] + variants[]`
|
||||
|
||||
## 7. 这三类能力为什么不该强行共用一套 builder
|
||||
|
||||
可以共用一些底层能力，但不应共用同一层业务 builder。
|
||||
|
||||
### 可以共用的
|
||||
|
||||
- 模板路由
|
||||
- LLM 调用
|
||||
- JSON 解析
|
||||
- 评分结果结构
|
||||
|
||||
### 不该强行共用的
|
||||
|
||||
- 输入归一化
|
||||
- summarizer
|
||||
- 领域对象
|
||||
|
||||
原因是：
|
||||
|
||||
- 分析看的是设计态对象
|
||||
- 单结果评估看的是单次执行
|
||||
- 对比评估看的是多次执行关系
|
||||
|
||||
所以更合理的方向是：
|
||||
|
||||
- `analysis/*`
|
||||
- `evaluation/*`
|
||||
- `compare/*`
|
||||
|
||||
而不是继续把三者都塞进一个“泛 evaluation builder”。
|
||||
|
||||
## 8. 对当前代码意味着什么
|
||||
|
||||
这套新框架落到当前项目，意味着几件事。
|
||||
|
||||
### 8.1 左侧分析链路要收紧
|
||||
|
||||
- 继续保留 `prompt-only` / `prompt-iterate`
|
||||
- 但默认只吃设计态输入
|
||||
- 不默认吃右侧测试样本值
|
||||
|
||||
### 8.2 右侧单列评估链路要从 A/B 特权里走出来
|
||||
|
||||
这个小节描述的是重构前的问题背景：当时 `original` / `optimized` 只挂在 A/B 上。
|
||||
|
||||
后续如果真的支持多测试，应该理解成：
|
||||
|
||||
- 每个测试快照都可以被单独评估
|
||||
|
||||
也就是说，今天的：
|
||||
|
||||
- `original`
|
||||
- `optimized`
|
||||
|
||||
更像是“历史 UI 触发语义”，不是未来最稳定的领域模型。
|
||||
|
||||
### 8.3 compare 链路要从二元语义改成多变体语义
|
||||
|
||||
这是这次改造最核心的一块：
|
||||
|
||||
- 从 `original/optimized`
|
||||
- 走向 `variants + deduped inputs`
|
||||
|
||||
### 8.4 `useEvaluationHandler` 后续更像协调层，不应继续承担全部抽象
|
||||
|
||||
后面它更适合做：
|
||||
|
||||
- 路由
|
||||
- 状态衔接
|
||||
- 结果持久化
|
||||
|
||||
而不是自己既处理分析、又处理单结果评估、又处理多结果对比评估的全部输入建模。
|
||||
|
||||
### 8.5 评估结果不做版本绑定，只统一回写左侧当前工作区
|
||||
|
||||
这里建议刻意保持简单：
|
||||
|
||||
- 评估时记录的是测试快照，不是版本分支身份
|
||||
- 应用建议时，统一尝试作用到左侧当前工作区
|
||||
- 如果因为左侧内容已经变化而无法自动应用，就直接跳过
|
||||
|
||||
这样做的目的是：
|
||||
|
||||
- 保持评估语义正确
|
||||
- 同时避免把系统推向复杂的版本绑定 / 版本回放设计
|
||||
|
||||
## 9. 推荐的实现顺序
|
||||
|
||||
如果按“风险最小”的方式推进，建议顺序是：
|
||||
|
||||
1. 先统一领域语言，明确分析 / 单结果评估 / 对比评估三层
|
||||
2. 再把 compare request 改成多变体结构
|
||||
3. 再把单结果评估从 A/B 特殊逻辑中抽出来
|
||||
4. 最后收紧分析输入，只保留设计态默认输入
|
||||
|
||||
这个顺序的好处是：
|
||||
|
||||
- 最先解决最影响认知的问题
|
||||
- compare 抽象先对齐多测试目标
|
||||
- analysis 与 evaluation 的边界最后再收口，不会一开始改得太散
|
||||
|
||||
## 10. 一句话版本
|
||||
|
||||
如果要把这次整体梳理收成一句话，可以直接用这句：
|
||||
|
||||
- **分析看设计，评估看一次执行，对比评估看多次执行之间的关系。**
|
||||
|
||||
再补一句更具体的：
|
||||
|
||||
- **多测试一旦成立，评估就天然是“变体集合”结构，而分析仍然是“对象快照”结构。**
|
||||
|
||||
这就是为什么后续这两者应该越拆越清楚，而不是继续揉在一起。
|
||||
727
docs/workspace/compare-evaluation-analysis/history/progress.md
Normal file
727
docs/workspace/compare-evaluation-analysis/history/progress.md
Normal file
@@ -0,0 +1,727 @@
|
||||
# 整理记录
|
||||
|
||||
## 当前文档对齐结论（2026-03-17，第二轮收口）
|
||||
|
||||
### 当前应优先相信哪些文档
|
||||
|
||||
- 请求结构与模板最终形态：
|
||||
- `real-api-samples/`
|
||||
- `real-api-samples/review-summary.md`
|
||||
- `manual-acceptance.md`
|
||||
- 本文件下方按日期展开的长记录，仍保留“问题如何一步步收敛”的价值，但其中部分请求字段、样例命名、旧 compare 结构描述已经变成历史阶段信息。
|
||||
|
||||
### 当前已明确的实现事实
|
||||
|
||||
- 左侧分析：
|
||||
- 只围绕当前工作区目标本身展开。
|
||||
- `basic` 默认不再注入 `referencePrompt`。
|
||||
- `pro-variable` 只保留变量结构，不带变量值。
|
||||
- `pro-multi` 只保留最小会话位置上下文，不再发送完整 transcript。
|
||||
- 右侧单结果评估：
|
||||
- 只使用“测试输入 + 当前快照执行提示词 + 当前输出”作为证据。
|
||||
- 不再额外注入 `## 当前工作区提示词`。
|
||||
- 当前保留的是方向性 `improvements`，不再要求 `patchPlan`。
|
||||
- 右侧对比评估：
|
||||
- 只使用“公共测试输入 + 多个执行快照”作为证据。
|
||||
- 不再默认注入 `## 当前工作区提示词`。
|
||||
- 普通 compare 与跨模型 compare 都已经收紧为“必须先解释已观察到的关键差异”，不能先发散到泛建议。
|
||||
- `pro-variable` / `pro-multi` 的右侧评估链路都已按“公共输入一次 + 快照差异单独展开”的最小化结构收口。
|
||||
|
||||
### 阅读旧记录时要特别注意
|
||||
|
||||
- 如果下文出现这些说法，应优先理解为历史阶段记录，而不是当前事实：
|
||||
- `workspacePrompt + variants[]`
|
||||
- `resolvedPrompt` 仍直接进入右侧评估请求
|
||||
- compare 里继续保留 `## 当前工作区提示词`
|
||||
- 每个 compare variant 继续带“输入快照（渲染内容）”
|
||||
- `pro/multi` 右侧评估继续带 `targetMessage + conversationMessages` 原始 JSON
|
||||
|
||||
### 当前建议
|
||||
|
||||
- 后续如果再需要核对“代码现在到底发了什么给模型”，不要从本文件中段的旧日志反推，直接看：
|
||||
- `docs/workspace/compare-evaluation-analysis/real-api-samples/*/rendered-messages.json`
|
||||
- `packages/core/src/services/template/default-templates/evaluation/builders.ts`
|
||||
- `packages/core/tests/unit/evaluation/result-compare-evidence-behavior.test.ts`
|
||||
|
||||
## 补充状态（2026-03-17，左侧真实样例已清理为最终版本）
|
||||
|
||||
### 本次人工审查结论
|
||||
|
||||
- 左侧 `prompt-only` 的正式标准参考样例，应统一收敛到“最小输入”版本。
|
||||
- 旧的 `current / 冗余对照` 样例已经从 `real-api-samples/` 中删除，不再继续保留。
|
||||
|
||||
### 原因
|
||||
|
||||
- 历史样例中曾存在：
|
||||
- `当前工作区提示词`
|
||||
- `参考提示词`
|
||||
- `designContext.rawPrompt`
|
||||
在同一次左侧分析请求里重复出现的问题。
|
||||
- 这会导致同一份长提示词在一次左侧分析请求中重复出现。
|
||||
- 与当前已经确认的输入最小化原则不一致：
|
||||
- 当前工作区提示词尽量只出现一次
|
||||
- 左侧分析不应默认携带旧参考提示词
|
||||
- 变量模式只保留变量结构，不保留测试值，也不重复保留原 prompt
|
||||
|
||||
### 当前收口后的标准参考口径
|
||||
|
||||
- `basic-user`
|
||||
- 标准参考：`basic-user-prompt-only`
|
||||
- `basic-system`
|
||||
- 标准参考：`basic-system-prompt-only-minimal`
|
||||
- `pro-variable`
|
||||
- 标准参考：`pro-variable-prompt-only-minimal`
|
||||
- `pro-multi`
|
||||
- 标准参考：`pro-multi-prompt-only-system-selected`
|
||||
- 标准参考：`pro-multi-prompt-only-user-selected`
|
||||
|
||||
### 文档更新
|
||||
|
||||
- `real-api-samples/`
|
||||
- 已只保留最终标准样例目录
|
||||
- 旧的 `basic-system-prompt-only`
|
||||
- 旧的 `pro-variable-prompt-only`
|
||||
- 旧的 `pro-variable-prompt-only-current`
|
||||
- 旧的 `pro-multi-prompt-only`
|
||||
- 旧的 `pro-multi-prompt-only-current`
|
||||
- 旧的 `pro-multi-prompt-only-minimal`
|
||||
均已删除
|
||||
- `README.md`
|
||||
- 已改为“真实样例目录里只保留最终版本”的阅读指引
|
||||
|
||||
## 补充状态（2026-03-17，真实样例覆盖矩阵补齐 + Focus 有效性校验）
|
||||
|
||||
### 本次新增的真实样例
|
||||
|
||||
- 左侧：
|
||||
- `basic-user-prompt-iterate-focus`
|
||||
- 右侧单结果评估：
|
||||
- `basic-user-result-focus`
|
||||
- 右侧对比评估：
|
||||
- `basic-system-compare-focus`
|
||||
- `pro-variable-compare-focus`
|
||||
|
||||
### 当前 `real-api-samples` 的真实覆盖状态
|
||||
|
||||
- 左侧分析
|
||||
- `prompt-only`
|
||||
- `basic-user / basic-system / pro-variable / pro-multi` 均已有真实样例
|
||||
- `prompt-only + focus`
|
||||
- `basic-user / basic-system / pro-variable / pro-multi` 均已有真实样例
|
||||
- `prompt-iterate + focus`
|
||||
- 当前已有 `basic-user` 真实样例
|
||||
- 右侧单结果评估
|
||||
- `result`
|
||||
- `basic-user / basic-system / pro-variable / pro-multi` 均已有真实样例
|
||||
- `result + focus`
|
||||
- 当前已有 `basic-user / pro-variable / pro-multi` 真实样例
|
||||
- 右侧对比评估
|
||||
- `compare`
|
||||
- `basic-user / basic-system / pro-variable / pro-multi` 均已有真实样例
|
||||
- `compare + focus`
|
||||
- 当前已有 `basic-user / basic-system / pro-variable / pro-multi` 真实样例
|
||||
|
||||
### 本次新增的“Focus 是否真的生效”校验
|
||||
|
||||
- `scripts/generate-real-api-samples.mjs`
|
||||
- 现在支持为指定 case 配置 `focusKeywords`
|
||||
- 生成真实样例后，会检查响应中的：
|
||||
- `summary`
|
||||
- `improvements`
|
||||
- `patchPlan`（如果有）
|
||||
- 是否至少有一处命中 Focus 关键词
|
||||
- 如果 Focus 没有真正反映到结果里，脚本会直接 fail
|
||||
|
||||
### 当前结论
|
||||
|
||||
- `real-api-samples/` 现在不只是覆盖了“请求结构”。
|
||||
- 对于重点的 focus case，还额外覆盖了“结果是否真的围绕 focus 展开”这一层语义验证。
|
||||
|
||||
## 补充状态（2026-03-17，右侧 `result / compare` 输入继续瘦身）
|
||||
|
||||
### 本次收口的实现点
|
||||
|
||||
- `pro/variable` 右侧单结果评估
|
||||
- 保留：
|
||||
- 公共测试输入中的变量值
|
||||
- 快照中的执行提示词与输出
|
||||
- 移除：
|
||||
- `executionInput` 中整段渲染后输入
|
||||
- 变量值在快照里的二次重复
|
||||
- `pro/multi` 右侧单结果评估
|
||||
- 公共测试输入中的会话上下文，当前已改为：
|
||||
- 目标消息位置用 `【当前执行提示词见下方快照】` 标记
|
||||
- 实际目标消息内容只保留在下方 `promptText`
|
||||
- `pro/multi` 右侧对比评估
|
||||
- 公共会话上下文现在只出现一次
|
||||
- 每个快照不再重复携带 `executionInput`
|
||||
- 对比时的差异集中体现在：
|
||||
- `promptText`
|
||||
- `output`
|
||||
- `reasoning`
|
||||
- `modelKey / versionLabel`
|
||||
|
||||
### 这次调整解决的重复问题
|
||||
|
||||
- 同一份变量值不再同时出现在：
|
||||
- 测试输入
|
||||
- 渲染后输入摘要
|
||||
- 渲染后整段 prompt
|
||||
- 同一条被测上下文消息不再同时出现在：
|
||||
- 公共会话上下文
|
||||
- 每个 compare variant 的 `executionInput`
|
||||
- 每个快照的 `promptText`
|
||||
|
||||
### 本次验证
|
||||
|
||||
- `pnpm -F @prompt-optimizer/core test -- tests/unit/evaluation/result-compare-evidence-behavior.test.ts`
|
||||
- `pnpm -F @prompt-optimizer/core test -- tests/unit/evaluation/rendered-samples.test.ts`
|
||||
- `pnpm -F @prompt-optimizer/ui test -- tests/integration/context-user-tester.spec.ts tests/integration/conversation-tester.spec.ts`
|
||||
- `pnpm -F @prompt-optimizer/ui exec tsc --noEmit -p tsconfig.json`
|
||||
- `pnpm -F @prompt-optimizer/core exec tsc --noEmit -p tsconfig.json`
|
||||
|
||||
## 补充状态（2026-03-17，`pro/multi prompt-only` 示例进一步收口）
|
||||
|
||||
### 本次文档与样例收口
|
||||
|
||||
- `pro/multi` 左侧分析样例不再使用“情感陪伴”之类复杂示例
|
||||
- 当前统一改为最简单的双消息场景：
|
||||
- `system: 你是一个诗人`
|
||||
- `user: 请你写一首关于{{主题}}的诗。`
|
||||
- 并且不再写“相关会话摘要”，而是明确写成：
|
||||
- `会话上下文`
|
||||
- 当前工作区消息位置用 `【当前工作区要优化的提示词】` 标记
|
||||
|
||||
### 新增的最终参考样例
|
||||
|
||||
- `real-api-samples/pro-multi-prompt-only-system-selected`
|
||||
- 选中 `system` 消息时：
|
||||
- `system: 【当前工作区要优化的提示词】`
|
||||
- `user: 请你写一首关于{{主题}}的诗。`
|
||||
- `real-api-samples/pro-multi-prompt-only-user-selected`
|
||||
- 选中 `user` 消息时：
|
||||
- `system: 你是一个诗人`
|
||||
- `user: 【当前工作区要优化的提示词】`
|
||||
|
||||
### 当前结论
|
||||
|
||||
- `pro/multi prompt-only` 的最小输入规则已经进一步明确：
|
||||
- 不是“抽象摘要越短越好”
|
||||
- 而是“只保留对当前位置判断真正必要的最小会话上下文”
|
||||
- 这比“相关会话摘要”更不容易失真，也更适合长提示词场景
|
||||
|
||||
## 补充状态（2026-03-17，`pro/variable prompt-only` 最小化已落地）
|
||||
|
||||
### 已完成的实现收敛
|
||||
|
||||
- `packages/ui/src/composables/prompt/useEvaluationHandler.ts`
|
||||
- `pro/variable` 左侧分析不再默认透传 `referencePrompt`
|
||||
- `pro/variable` 左侧分析的 `designContext` 不再使用整段 JSON stringify
|
||||
- 当前改为最小变量结构说明：
|
||||
- `summary = 这里只说明模板变量结构，不包含任何测试值。`
|
||||
- `content = 变量: 风格, 主题`
|
||||
- `packages/core/tests/unit/evaluation/rendered-samples.test.ts`
|
||||
- `05-pro-variable-prompt-only-base` 已改为最小输入样例
|
||||
- `packages/ui/tests/unit/composables/useEvaluationHandler.spec.ts`
|
||||
- 已补 `pro/variable` 最小结构上下文断言
|
||||
- 已补 `pro/multi` 最小摘要上下文断言，避免退回完整 transcript
|
||||
|
||||
### 真实请求验证
|
||||
|
||||
- 已新增真实请求样例：
|
||||
- `real-api-samples/pro-variable-prompt-only`
|
||||
- `real-api-samples/pro-variable-prompt-only-current`
|
||||
- `real-api-samples/pro-variable-prompt-only-minimal`
|
||||
- 真实请求结论：
|
||||
- 旧风格输入会重复出现 `referencePrompt + rawPrompt`
|
||||
- 最小化后仍然能稳定产出非空 `patchPlan`
|
||||
- 最小化版本的真实返回更干净，也更符合“长内容只出现一次”的约束
|
||||
|
||||
### 本次回归验证
|
||||
|
||||
- `pnpm -F @prompt-optimizer/ui test -- tests/unit/composables/useEvaluationHandler.spec.ts`
|
||||
- `pnpm -F @prompt-optimizer/core test -- tests/unit/evaluation/rendered-samples.test.ts`
|
||||
- `pnpm -F @prompt-optimizer/ui exec tsc --noEmit -p tsconfig.json`
|
||||
- `pnpm -F @prompt-optimizer/core exec tsc --noEmit -p tsconfig.json`
|
||||
|
||||
## 补充状态（2026-03-17，`pro/multi prompt-only` 真实对照已完成）
|
||||
|
||||
### 当前实现的主要冗余
|
||||
|
||||
当前 `pro/multi` 左侧分析请求里，工作区提示词会在同一次请求中重复出现多次：
|
||||
|
||||
- `workspacePrompt`
|
||||
- `referencePrompt`
|
||||
- `designContext.targetMessage.content`
|
||||
- `designContext.conversationMessages[].content` 中的目标消息内容
|
||||
|
||||
这意味着同一份长 system 消息可能在一次分析请求里出现 3-4 次。
|
||||
|
||||
### 真实请求对照结果
|
||||
|
||||
已新增真实请求样例：
|
||||
|
||||
- `real-api-samples/pro-multi-prompt-only-current`
|
||||
- `real-api-samples/pro-multi-prompt-only-minimal`
|
||||
|
||||
对照结论：
|
||||
|
||||
- `current`
|
||||
- 带 `referencePrompt`
|
||||
- 带完整 `targetMessage + conversationMessages` JSON
|
||||
- 真实返回：`overall = 70`
|
||||
- 请求耗时：约 `21492ms`
|
||||
- `minimal`
|
||||
- 不带 `referencePrompt`
|
||||
- 只带“目标消息角色 + 位置引用 + 最小相关消息”的短上下文
|
||||
- 真实返回：`overall = 70`
|
||||
- 请求耗时：约 `11635ms`
|
||||
|
||||
目前看，最小化版本没有明显损失分析能力，但请求更短、更聚焦，也更符合“同一长内容只出现一次”的约束。
|
||||
|
||||
### 当前建议
|
||||
|
||||
下一步优先建议把 `pro/multi prompt-only` 收敛到：
|
||||
|
||||
- `workspacePrompt`
|
||||
- `focus`
|
||||
- 极短 `designContext`
|
||||
- 目标消息角色
|
||||
- 当前工作区提示词在会话中的明确位置引用
|
||||
- 与目标消息直接相关的最少量上下文消息
|
||||
|
||||
默认不再发送：
|
||||
|
||||
- `referencePrompt`
|
||||
- 完整 `targetMessage.content`
|
||||
- 完整 `conversationMessages` transcript
|
||||
- 任何与左侧设计分析无关的执行态快照
|
||||
|
||||
## 补充状态（2026-03-17，`pro/multi prompt-only` 最小化已落地）
|
||||
|
||||
### 已完成的实现收敛
|
||||
|
||||
- `packages/ui/src/composables/prompt/useEvaluationHandler.ts`
|
||||
- `pro/multi` 左侧分析不再默认透传 `referencePrompt`
|
||||
- `pro/multi` 左侧分析的 `designContext` 不再使用完整 `targetMessage + conversationMessages` JSON
|
||||
- 当前改为最小会话位置上下文：
|
||||
- `summary = 当前分析目标是某一条上下文消息，不是整个会话结果。`
|
||||
- `content` 仅包含：
|
||||
- 目标消息角色
|
||||
- 当前工作区提示词所在位置的显式标记
|
||||
- 与目标消息直接相关的最少量会话消息
|
||||
- `packages/ui/tests/unit/composables/useEvaluationHandler.spec.ts`
|
||||
- 已补 `pro/multi` 最小摘要上下文断言
|
||||
- `packages/core/tests/unit/evaluation/rendered-samples.test.ts`
|
||||
- `06-pro-multi-prompt-only-base` 已改为最小输入样例
|
||||
|
||||
### 真实请求验证
|
||||
|
||||
- 已新增最终态真实样例：
|
||||
- `real-api-samples/pro-multi-prompt-only`
|
||||
- 当前最终态真实返回：
|
||||
- `overall = 60`
|
||||
- `patchPlan` 非空
|
||||
- 当前最终态请求已符合：
|
||||
- 不重复发送 `referencePrompt`
|
||||
- 不重复发送目标消息全文
|
||||
- 不发送完整 transcript
|
||||
|
||||
### 本次回归验证
|
||||
|
||||
- `pnpm -F @prompt-optimizer/ui test -- tests/unit/composables/useEvaluationHandler.spec.ts`
|
||||
- `pnpm -F @prompt-optimizer/core test -- tests/unit/evaluation/rendered-samples.test.ts`
|
||||
- `pnpm -F @prompt-optimizer/ui exec tsc --noEmit -p tsconfig.json`
|
||||
- `pnpm -F @prompt-optimizer/core exec tsc --noEmit -p tsconfig.json`
|
||||
- `pnpm -F @prompt-optimizer/core build`
|
||||
|
||||
## 补充状态（2026-03-17，输入最小化规范补充）
|
||||
|
||||
### 已新增“输入最小化与去重规范”
|
||||
|
||||
- 新增：
|
||||
- `input-minimization-spec.md`
|
||||
|
||||
本次补充的核心结论是：
|
||||
|
||||
- 同一份长内容，在一次 LLM 请求里应尽量只出现一次
|
||||
- 左侧分析应进一步收口为“只看当前工作区”
|
||||
- `referencePrompt` 不应作为默认输入继续保留
|
||||
- `designContext` 只允许承载真正有设计语义的短摘要，不应继续承载 UI 来源说明
|
||||
- 右侧 `result / compare` 应继续坚持“只看执行证据，不额外注入工作区全文”
|
||||
|
||||
### 对当前各任务的直接约束
|
||||
|
||||
- `basic/user prompt-only`
|
||||
- 默认只发 `workspacePrompt`
|
||||
- 有 `focus` 时再加 `focus`
|
||||
- 默认不发 `referencePrompt`
|
||||
- 默认不发 `designContext`
|
||||
- `pro/variable prompt-only`
|
||||
- 默认不发变量值
|
||||
- 只允许发送变量结构或变量语义摘要
|
||||
- `result`
|
||||
- 只发测试输入、执行提示词、输出
|
||||
- `compare`
|
||||
- 公共输入只出现一次
|
||||
- 每个快照只保留独有 prompt / output / reasoning
|
||||
|
||||
## 补充状态（2026-03-16，workspace 语义收口）
|
||||
|
||||
### 测试区版本来源已统一为 `workspace / v0 / vN`
|
||||
|
||||
- `basic-user`
|
||||
- `basic-system`
|
||||
- `pro-variable`
|
||||
- `pro-multi`
|
||||
- `image-text2image`
|
||||
- `image-image2image`
|
||||
|
||||
以上模式的右侧测试列当前都已把旧 `'latest'` 语义替换为 `'workspace'`：
|
||||
|
||||
- `workspace` = 下方工作区当前内容
|
||||
- `v0` = 原始输入
|
||||
- `v1..vn` = 已持久化历史版本
|
||||
|
||||
并且：
|
||||
|
||||
- 旧 session 持久化值 `'latest'` 会在读取时迁移为 `'workspace'`
|
||||
- 如果测试列选择 `workspace`，但当前工作区为空，则直接报错
|
||||
- 不再 silently fallback 到 `logic.prompt` / 原始输入
|
||||
|
||||
### basic 左侧“分析”后的链路重置问题已补回归
|
||||
|
||||
- `basic-user` / `basic-system` 左上输入区点击 `分析` 时：
|
||||
- 会重建左侧工作区
|
||||
- 会清理旧优化链显示
|
||||
- 会生成新的工作区 `V0`
|
||||
- 已补：
|
||||
- UI 集成回归
|
||||
- store 持久化回归
|
||||
- Playwright e2e 回归
|
||||
|
||||
### 当前主线剩余问题重新收口
|
||||
|
||||
- 文本 workspace 主语义：可视为已基本完成
|
||||
- image 右侧评估链路：仍未完成
|
||||
- compare 去重建模（`inputs[] + variants[]`）：当前已明确降级为可选后续优化，不再作为本轮 blocker
|
||||
|
||||
## 补充状态（2026-03-15，MCP 复核 + 修复回写）
|
||||
|
||||
### `context-user` 的 `分析 -> 继续优化` 真实路径已修复
|
||||
|
||||
- 根因已确认：
|
||||
- 左侧 `分析` 会创建虚拟 `V0`
|
||||
- 同时清空 `currentChainId`
|
||||
- 旧的继续优化路径仍尝试 `addIteration(emptyChainId)`，最终在 history manager 里抛出 `RecordNotFoundError`
|
||||
- 当前修复方式：
|
||||
- 当 `currentChainId` 为空时，不再错误地追加到旧链
|
||||
- 改为走 `createNewChain()` 创建新迭代链
|
||||
- 2026-03-15 MCP 实测结果：
|
||||
- 在 `/#/pro/variable` 中执行 `分析 -> 关闭对话框 -> 继续优化 -> 确认优化`
|
||||
- 工作区成功从 `V0` 进入 `V1`
|
||||
- 控制台为 `0 errors / 0 warnings`
|
||||
- 未再出现 `RecordNotFoundError`
|
||||
|
||||
### 相关 i18n 问题也已一起修正
|
||||
|
||||
- 原来错误引用了不存在的 key：`toast.warning.historyFailed`
|
||||
- 当前已改为：`toast.warning.saveHistoryFailed`
|
||||
- 2026-03-15 MCP 实测中未再出现历史保存失败相关的未翻译 key 泄漏
|
||||
|
||||
### `pro-variable` 在修复后的评估链路已做同会话复核
|
||||
|
||||
- 左侧分析：
|
||||
- 仍然只带变量结构，不带变量值
|
||||
- 右侧单结果评估：
|
||||
- 已实测带上当前工作区 `V1` 提示词
|
||||
- 已实测带上 `variables[].value`
|
||||
- 已实测带上 `resolvedPrompt`
|
||||
- 已实测带上当前列输出
|
||||
- 右侧对比评估：
|
||||
- 已实测带上 `## 当前工作区提示词`
|
||||
- 已实测带上 `### 方案 A / B`
|
||||
- 已实测带上每个 variant 自己的 `#### 输入快照（渲染内容）`
|
||||
- 已实测带上每个 variant 自己的输出
|
||||
|
||||
### 文档补充
|
||||
|
||||
- 新增并持续回写：
|
||||
- `manual-acceptance.md`
|
||||
- 当前该文档已经包含：
|
||||
- 4 个文本 workspace 的手工验收步骤
|
||||
- `pro-variable` 的 post-fix 复核步骤
|
||||
- 浏览器真实请求应如何检查
|
||||
|
||||
## 最新状态（2026-03-14，已按当前代码复核）
|
||||
|
||||
## 1. 已确认落地到代码的部分
|
||||
|
||||
### 评估类型与 core 协议
|
||||
|
||||
- `EvaluationType` 已收敛为：
|
||||
- `result`
|
||||
- `compare`
|
||||
- `prompt-only`
|
||||
- `prompt-iterate`
|
||||
- 单结果评估模板已经改成 `evaluation-*-result`
|
||||
- compare request 已改成：
|
||||
- `workspacePrompt?`
|
||||
- `variants[]`
|
||||
- compare template 已切到“多快照证据”语义，不再默认把 A/B 解释成 original/optimized
|
||||
|
||||
### 文本 workspace 的 UI / 业务行为
|
||||
|
||||
- 4 个文本 workspace 的右侧单结果评估都已经是 **variant 化** 的
|
||||
- 当前 active variants 中，只要该列有输出，就能触发 `result`
|
||||
- compare 已经从“只在 2 列 A/B 出现”放宽为：
|
||||
- 当前 active variants 中
|
||||
- 至少 2 个有结果
|
||||
- 且不是 stale
|
||||
- 就可以触发 `compare`
|
||||
|
||||
### 分析输入边界
|
||||
|
||||
- `context-user` 左侧分析已经改为只走 `analysisContext`
|
||||
- 该上下文只带变量结构，不带变量实例值
|
||||
- basic 两个 workspace 左侧分析也不再吃右侧测试文本
|
||||
|
||||
### 状态与持久化
|
||||
|
||||
- `PersistedEvaluationResults` 已切为：
|
||||
- `result: Record<string, EvaluationResponse | null>`
|
||||
- `compare`
|
||||
- `prompt-only`
|
||||
- `prompt-iterate`
|
||||
- 文本 workspace 的评估结果已按 `variantId` 分桶持久化
|
||||
|
||||
## 2. 本轮新增完成的修正
|
||||
|
||||
### `context-user` / `context-system` 的右侧单结果评估上下文已按 variant 独立
|
||||
|
||||
- `useEvaluationHandler` 现在允许 `resultTargets[variantId]` 自带 `proContext`
|
||||
- `context-user` 的单结果评估会按当前列单独构造：
|
||||
- `rawPrompt`
|
||||
- `resolvedPrompt`
|
||||
- 当前列变量值
|
||||
- `context-system` 的单结果评估会按当前列单独构造：
|
||||
- `targetMessage`
|
||||
- `conversationMessages`
|
||||
|
||||
### `context-user` compare payload 已带 per-variant input snapshot
|
||||
|
||||
- 当前会带每个 variant 的：
|
||||
- `prompt`
|
||||
- `output`
|
||||
- `reasoning`
|
||||
- `modelKey`
|
||||
- `versionLabel`
|
||||
- `input`
|
||||
- `label = Rendered Content`
|
||||
- `content = 当前列渲染后输入`
|
||||
- `summary = 当前列变量值摘要`
|
||||
|
||||
### compare 结构仍是 `workspacePrompt + variants[]`
|
||||
|
||||
- 当前 compare 已经足够表达多测试快照
|
||||
- 但还没有继续演进到更彻底的：
|
||||
- `inputs[]`
|
||||
- `variants[]`
|
||||
- 输入引用关系
|
||||
- 这条目前已降级为后续可选优化，不再作为主链路 blocker
|
||||
|
||||
### `context-system` compare payload 目前已经相对完整
|
||||
|
||||
- 每个 variant 已显式带 `Conversation Snapshot`
|
||||
- 如果有 tools，也会一起拼入 input content
|
||||
|
||||
### image 模式右侧评估链路仍未完成
|
||||
|
||||
- 当前 image 只有左侧 `prompt-only` 分析模板
|
||||
- 没有 image 的 `result` / `compare` 模板
|
||||
- workspace 右侧也没有完成对应评估接线
|
||||
|
||||
### 还有一些内部旧 compare 残留
|
||||
|
||||
- 共享测试面板内部 tool-call 分桶仍使用：
|
||||
- `COMPARE_BASELINE_VARIANT_ID`
|
||||
- `COMPARE_CANDIDATE_VARIANT_ID`
|
||||
- 旧 tester helper 文件仍在仓库里，但当前文本 workspace 主链路已不再依赖它们
|
||||
|
||||
## 3. 本次文档更新结果
|
||||
|
||||
### 已更新
|
||||
|
||||
- `current-analysis-feature-map.md`
|
||||
- 改成只讲当前实现事实
|
||||
- 移除了正文里大量“旧实现现状”的混淆
|
||||
- `findings.md`
|
||||
- 改成“当前已落地 / 当前偏差 / 下一步建议”的结构
|
||||
- 不再把旧 A/B 问题当成当前事实
|
||||
- `README.md`
|
||||
- 目录说明改成“分析 / 评估 / 对比评估”口径
|
||||
- 避免继续把 compare evaluation 误写成“对比分析”
|
||||
- `manual-acceptance.md`
|
||||
- 补齐了手工点击步骤、抓包关注点、以及 `pro-variable` 修复项的 post-fix 复核结论
|
||||
|
||||
### 保持为设计框架 / 目标文档
|
||||
|
||||
- `task_plan.md`
|
||||
- 仍然是本轮目标定义
|
||||
- 仅补充了状态说明，标明 `pro` 两个 workspace 的 per-variant 右侧上下文精度这轮已经补齐
|
||||
- `overall-reframing.md`
|
||||
- 仍然保留为设计框架文档
|
||||
- 顶部状态说明已同步到当前代码事实
|
||||
- 需要结合本文件和 `current-analysis-feature-map.md` 一起读
|
||||
|
||||
## 4. 当前最准确的状态判断
|
||||
|
||||
如果只用一句话概括当前进度：
|
||||
|
||||
- 文本 workspace 的语义重构已经基本完成，4 个文本 workspace 的左侧分析与右侧 `result / compare` 都已有真实回归覆盖；测试区版本来源也已统一到 `workspace / v0 / vN`，当前主线剩余问题主要是 image 模式右侧评估链路还没做完。
|
||||
|
||||
## 5. 关于“是不是问题复杂化了”的结论
|
||||
|
||||
当前更准确的结论不是“任务本身复杂化了”，而是：
|
||||
|
||||
- 主任务已经基本收口
|
||||
- 剩下暴露出来的是第二层实现精度问题
|
||||
|
||||
建议这样理解：
|
||||
|
||||
- 文本 workspace 的主语义重构：已经基本完成
|
||||
- compare 去重建模：后续收紧项
|
||||
- image 右侧评估链路：后续扩展项
|
||||
|
||||
这样做的目的，是避免把当前所有残留问题继续抬升为本轮主任务的 blocker。
|
||||
|
||||
## 6. 本轮补充的回归验证（2026-03-14）
|
||||
|
||||
### 已通过
|
||||
|
||||
- `pnpm -F @prompt-optimizer/ui typecheck`
|
||||
- `pnpm -F @prompt-optimizer/core test -- tests/unit/evaluation/service.test.ts`
|
||||
- `pnpm -F @prompt-optimizer/ui test -- tests/unit/composables/compareEvaluation.spec.ts tests/unit/composables/useEvaluationHandler.spec.ts tests/unit/components/EvaluationScoreBadge.spec.ts tests/unit/components/EvaluationHoverCard.spec.ts tests/unit/composables/useAppPromptGardenImport.spec.ts`
|
||||
- `pnpm -F @prompt-optimizer/ui test -- tests/unit/stores/session/basic-session-persistence.spec.ts tests/unit/stores/session/pro-session-persistence.spec.ts`
|
||||
- `pnpm -F @prompt-optimizer/ui test -- tests/integration/basic-workspace-logic.spec.ts tests/integration/context-user-tester.spec.ts tests/integration/conversation-tester.spec.ts`
|
||||
- `pnpm exec playwright test tests/e2e/analysis/basic-user.spec.ts --grep "分析提示词并显示评估结果"`
|
||||
- `pnpm exec playwright test tests/e2e/analysis/basic-system.spec.ts --grep "分析提示词并显示评估结果"`
|
||||
- `pnpm exec playwright test tests/e2e/analysis/pro-variable.spec.ts --grep "分析带变量的提示词并显示评估结果"`
|
||||
- `E2E_VCR_MODE=replay pnpm exec playwright test tests/e2e/analysis/pro-multi.spec.ts`
|
||||
- `pnpm exec playwright test tests/e2e/test/basic-system-compare-test.spec.ts --grep "测试后可触发单结果评估与对比评估"`
|
||||
- `pnpm exec playwright test tests/e2e/test/basic-user-test.spec.ts`
|
||||
- `pnpm exec playwright test tests/e2e/test/basic-user-test.spec.ts --grep "三列测试后可触发多变体对比评估"`
|
||||
- `pnpm exec playwright test tests/e2e/test/pro-variable-test.spec.ts`
|
||||
- `E2E_VCR_MODE=replay pnpm exec playwright test tests/e2e/test/pro-multi-test.spec.ts`
|
||||
- `E2E_VCR_MODE=replay pnpm exec playwright test tests/e2e/analysis/basic-system.spec.ts tests/e2e/analysis/basic-user.spec.ts tests/e2e/analysis/pro-variable.spec.ts tests/e2e/analysis/pro-multi.spec.ts tests/e2e/test/basic-system-compare-test.spec.ts tests/e2e/test/basic-user-test.spec.ts tests/e2e/test/pro-variable-test.spec.ts tests/e2e/test/pro-multi-test.spec.ts`
|
||||
|
||||
### 本轮新增 / 修正的测试
|
||||
|
||||
- 新增 `packages/ui/tests/unit/composables/compareEvaluation.spec.ts`
|
||||
- 锁定 compare payload 的规范化、过滤与输入快照清洗逻辑
|
||||
- 新增 `packages/ui/tests/unit/composables/useEvaluationHandler.spec.ts`
|
||||
- 锁定 `result / compare / prompt-only` 路由行为
|
||||
- 锁定 `PersistedEvaluationResults` 的 variant 分桶恢复与回写
|
||||
- 修正旧集成测试断言
|
||||
- `context-user-tester.spec.ts`
|
||||
- `conversation-tester.spec.ts`
|
||||
- 两者都已切到新 `variantStates` 结构，不再依赖旧 `testResults.originalResult / optimizedResult`
|
||||
- 新增 `basic-user` 右侧 3 列 compare e2e
|
||||
- 覆盖 `A/B/C` 三列 run-all 后触发 `compare` 评估
|
||||
- 配套新增真实录制 fixture：
|
||||
- `tests/e2e/fixtures/vcr/test-basic-user-test-spec-ts/三列测试后可触发多变体对比评估.json`
|
||||
- 新增 `pro-variable` 右侧评估 e2e
|
||||
- 覆盖填写变量后：
|
||||
- 两列 run-all
|
||||
- 单结果 `result` 评估
|
||||
- 顶部 `compare` 评估
|
||||
- 配套新增真实录制 fixture：
|
||||
- `tests/e2e/fixtures/vcr/test-pro-variable-test-spec-ts/填写变量后可触发单结果评估与对比评估.json`
|
||||
- 新增 `pro-multi` 右侧评估 e2e
|
||||
- 覆盖多消息 workspace 中：
|
||||
- 左侧选中消息优化
|
||||
- 右侧 A/B 顺序测试
|
||||
- 单结果 `result` 评估
|
||||
- 顶部 `compare` 评估
|
||||
- 配套新增真实录制 fixture：
|
||||
- `tests/e2e/fixtures/vcr/test-pro-multi-test-spec-ts/多消息工作区测试后可触发单结果评估与对比评估.json`
|
||||
- 新增 `pro-multi` 左侧分析 e2e
|
||||
- 覆盖多消息 workspace 中：
|
||||
- 左侧选中消息优化
|
||||
- 等待优化流式完成
|
||||
- 左侧 `prompt-only` 分析
|
||||
- 分数徽章显示
|
||||
- 配套新增真实录制 fixture：
|
||||
- `tests/e2e/fixtures/vcr/analysis-pro-multi-spec-ts/分析对话优化结果并显示评估分数.json`
|
||||
- 新增 `basic-system` 右侧评估 e2e
|
||||
- 覆盖填写测试输入后：
|
||||
- 两列 run-all
|
||||
- 单结果 `result` 评估
|
||||
- 顶部 `compare` 评估
|
||||
- 配套新增真实录制 fixture：
|
||||
- `tests/e2e/fixtures/vcr/test-basic-system-compare-test-spec-ts/测试后可触发单结果评估与对比评估.json`
|
||||
|
||||
### 当前尚未补齐的 e2e 边界
|
||||
|
||||
- image 模式本轮明确先不补右侧评估
|
||||
- 原因不是语义未定，而是输出是图片，需要视觉分析能力，当前文字型 VCR 回归价值有限
|
||||
|
||||
### 本轮 e2e 修正结果
|
||||
|
||||
- 原先卡住的 2 条分析 e2e 已确认不是产品功能回归，而是 VCR fixture 与当前 analysis request body / requestHash 漂移
|
||||
- 已将以下 fixture 刷新为当前 `interactions[]` 格式，并对齐到现有 core 模板渲染出的 request body
|
||||
- `tests/e2e/fixtures/vcr/analysis-basic-system-spec-ts/分析提示词并显示评估结果.json`
|
||||
- `tests/e2e/fixtures/vcr/analysis-basic-user-spec-ts/分析提示词并显示评估结果.json`
|
||||
- `tests/e2e/fixtures/vcr/analysis-pro-variable-spec-ts/分析带变量的提示词并显示评估结果.json`
|
||||
- `tests/e2e/fixtures/vcr/analysis-pro-multi-spec-ts/分析对话优化结果并显示评估分数.json`
|
||||
- 修正后，已有 analysis e2e 已恢复为绿色
|
||||
- 另外补了一处测试基建问题：
|
||||
- `expectOptimizedResultNotEmpty()` 现在会继续等待优化按钮重新可用
|
||||
- 避免在流式优化尚未结束时过早点击左侧分析，导致 `pro-multi` 按钮仍处于重建阶段
|
||||
- `basic-system` 现已同时具备：
|
||||
- 左侧 `prompt-only` 分析的真实 fixture
|
||||
- 右侧测试输出回归 fixture
|
||||
- 右侧单结果 `result` 评估真实 fixture
|
||||
- 右侧 `compare` 评估真实 fixture
|
||||
- `basic-user` 现已同时具备：
|
||||
- 左侧 `prompt-only` 分析的真实 fixture
|
||||
- 右侧单结果 `result` 评估的真实 fixture
|
||||
- 右侧 2 列 / 3 列 `compare` 评估的真实 fixture
|
||||
- `pro-variable` 现已同时具备：
|
||||
- 左侧 `prompt-only` 分析的真实 fixture
|
||||
- 右侧填写变量后的单结果 `result` 评估真实 fixture
|
||||
- 右侧填写变量后的 `compare` 评估真实 fixture
|
||||
- `pro-multi` 现已具备：
|
||||
- 左侧 `prompt-only` 分析真实 fixture
|
||||
- 右侧单结果 `result` 评估真实 fixture
|
||||
- 右侧 `compare` 评估真实 fixture
|
||||
- 对应多消息输入场景的真实录制回放
|
||||
|
||||
## 7. 本轮提交拆分结果（2026-03-14）
|
||||
|
||||
当前分支 `codex/compare-evaluation-analysis-refactor` 上，与这轮收口直接相关的提交已经拆成：
|
||||
|
||||
- `34960c1` `refactor(core): reshape evaluation protocol around results`
|
||||
- `af06ff5` `refactor(ui): variantize analysis and evaluation flows`
|
||||
- `99779c5` `docs(workspace): capture analysis and evaluation refactor status`
|
||||
- `cd835ac` `test(e2e): refresh analysis vcr fixtures`
|
||||
- `3034d46` `chore(git): ignore local codex folders`
|
||||
|
||||
这样拆分后：
|
||||
|
||||
- core 协议与模板语义变更
|
||||
- UI variant 化与状态重构
|
||||
- 文档对齐
|
||||
- e2e fixture 收口
|
||||
- 本地开发环境忽略项
|
||||
|
||||
已经是相对清晰的边界。
|
||||
|
||||
## 8. 更适合的下一步
|
||||
|
||||
- 先按逻辑边界拆分提交：
|
||||
- 当前这一步已经完成，可直接进入 review / PR 整理
|
||||
- 如果继续补质量保障，可以补更多文本边界用例，例如：
|
||||
- 左侧分析弹窗 / badge 的更多异常态
|
||||
- compare 多列切换版本后的 stale / re-run 组合
|
||||
- 如果继续补架构收口，优先再决定 compare 是否还要演进到 `inputs[] + variants[]`
|
||||
@@ -0,0 +1,78 @@
|
||||
# 当前任务定义
|
||||
|
||||
> 状态说明（2026-03-14）：
|
||||
> 本文档仍然作为“目标定义”有效。
|
||||
> 当前代码已经完成其中一大部分文本 workspace 重构进度；
|
||||
> 最新实现状态与剩余偏差请优先参考 `progress.md` 与 `current-analysis-feature-map.md`。
|
||||
|
||||
## 核心任务
|
||||
|
||||
### 1. 明确区分“分析”和“评估”的语义、结构与 UI 文案
|
||||
|
||||
- 左侧能力统一定义为“分析”
|
||||
- 右侧单结果能力统一定义为“评估”
|
||||
- 右侧多结果能力统一定义为“对比评估”
|
||||
- 相关按钮文本、面板标题、空态文案、结果文案都应跟着统一
|
||||
|
||||
### 2. 矫正分析功能的输入边界
|
||||
|
||||
- 分析默认只允许使用左侧工作区的设计态信息
|
||||
- 分析不准引用右侧测试文本
|
||||
- 分析不准默认引用右侧测试变量实例值
|
||||
- 如果未来确实需要“结合当前变量值排障”，应定义成显式诊断模式，而不是默认分析
|
||||
|
||||
### 3. 重构评估功能，支持多测试的结果导向评估
|
||||
|
||||
- 单结果评估应基于一次真实测试快照
|
||||
- 对比评估应支持多个真实测试快照
|
||||
- 评估对象应是测试快照，而不是左侧“优化前/优化后”的编辑器语义
|
||||
- 对比评估应支持多测试输入 + 多测试输出，而不再只限 A/B 二元 compare
|
||||
|
||||
## 一个关键实现原则
|
||||
|
||||
- **评估基于测试快照，修改统一面向左侧当前工作区。**
|
||||
|
||||
这句话展开后，含义是：
|
||||
|
||||
- 评估时要知道“这次实际怎么测的、测出了什么”
|
||||
- 但不建立“这个结果属于 v1 / v2 / 某个版本分支”的强绑定关系
|
||||
- 所有“应用建议 / 应用 patch”都统一尝试作用到左侧当前工作区
|
||||
- 如果当前工作区内容已变化、导致无法应用，就直接失败或跳过
|
||||
|
||||
## 当前收口判断
|
||||
|
||||
这轮任务不应继续被“实现精度残留”拉成一个无限扩大的重构。
|
||||
|
||||
当前更合理的判断是：
|
||||
|
||||
- 文本 workspace 的主语义重构是本轮主任务
|
||||
- `pro` 两个 workspace 的 per-variant 右侧上下文精度，这轮已经补齐，不再是当前剩余主问题
|
||||
- image 模式右侧评估链路，是单独的后续扩展问题
|
||||
|
||||
也就是说：
|
||||
|
||||
- 不能因为 `context-user` / `context-system` 还有 shared `proContext` 残留，就否定本轮“分析 / 评估 / 对比评估”主结构已经成立
|
||||
- 这些问题应记录为 **后续精度修正项**，而不是继续抬升为本轮必须全部做完的 blocker
|
||||
|
||||
## 边界
|
||||
|
||||
- 本工作区覆盖分析 / 评估 / 对比评估的语义划分、输入边界、接口设计与分层改造方向。
|
||||
- 可以给出按层次组织的实施顺序，但不展开到逐文件编码 checklist。
|
||||
- 重点聚焦当前项目已有的 LLM 主观分析 / 评估体系，不讨论通用 promptfoo / 客观断言路线。
|
||||
|
||||
## 关注点
|
||||
|
||||
- 分析与评估的边界到底如何稳定下来
|
||||
- 单结果评估的最小必需输入是什么
|
||||
- 多测试对比评估如何摆脱 `original/optimized` 二元语义
|
||||
- 不同模式下哪些属于设计态输入，哪些属于执行态输入
|
||||
- 如何在不引入版本绑定复杂度的前提下，让评估结果仍然可用于左侧工作区修改
|
||||
|
||||
## 非目标
|
||||
|
||||
- 不建立评估结果到历史版本分支的绑定关系
|
||||
- 不实现版本回放或历史快照重放系统
|
||||
- 不提供本次改造的具体实施任务列表
|
||||
- 不提供 UI 视觉方案
|
||||
- 不在本轮文档中直接产出代码提交
|
||||
- 不把 `pro` 模式 per-variant 上下文精度问题与 image 右侧评估链路，一起并入本轮“主语义重构完成度”的判断标准
|
||||
334
docs/workspace/compare-evaluation-analysis/manual-acceptance.md
Normal file
334
docs/workspace/compare-evaluation-analysis/manual-acceptance.md
Normal file
@@ -0,0 +1,334 @@
|
||||
# 分析 / 评估 / 对比评估手工验收
|
||||
|
||||
> 这是当前最短手测版。
|
||||
> 目标不是记录所有历史现象，而是帮助你快速确认“当前实现是否符合设计”。
|
||||
|
||||
## 1. 本轮范围
|
||||
|
||||
只测 4 个文本工作区：
|
||||
|
||||
- `basic-user`
|
||||
- `basic-system`
|
||||
- `pro-variable`
|
||||
- `pro-multi`
|
||||
|
||||
本轮不测：
|
||||
|
||||
- image 右侧 `result / compare`
|
||||
|
||||
## 2. 启动方式
|
||||
|
||||
```powershell
|
||||
pnpm -F @prompt-optimizer/core build
|
||||
pnpm -F @prompt-optimizer/ui build
|
||||
pnpm -F @prompt-optimizer/web dev --port 18181
|
||||
```
|
||||
|
||||
打开：
|
||||
|
||||
```text
|
||||
http://localhost:18181
|
||||
```
|
||||
|
||||
建议：
|
||||
|
||||
- 用无痕窗口或新 profile
|
||||
- 打开 DevTools，看网络请求里的 `messages`
|
||||
|
||||
## 3. 这次到底要验证什么
|
||||
|
||||
只验证 4 条：
|
||||
|
||||
1. 左侧“分析”只看左侧工作区，不引用右侧测试内容。
|
||||
2. 右侧单结果“评估”只看当前列的执行快照。
|
||||
3. 右侧顶部“对比评估”看的是多个执行快照，不再是旧 A/B 语义。
|
||||
4. 请求体尽量最小化，不再重复塞工作区全文、重复渲染输入、`resolvedPrompt` 等旧冗余字段。
|
||||
|
||||
再补 2 条这轮新增回归检查：
|
||||
|
||||
5. 右侧 `result / compare` 只认当前工作区，不允许回退到左侧原始提示词。
|
||||
6. 当已有评估结果但当前输入条件已失效时，评估入口应保留可查看，但禁止重跑。
|
||||
|
||||
## 4. 抓包时只看这些点
|
||||
|
||||
优先看模型请求里的 `messages[0].content` 和 `messages[1].content`。
|
||||
|
||||
### 左侧分析应满足
|
||||
|
||||
- 只有当前工作区目标
|
||||
- 必要时带最小设计态上下文
|
||||
- 不应出现右侧测试文本
|
||||
- 不应出现右侧测试输出
|
||||
- `pro-variable` 不应出现变量值
|
||||
|
||||
### 右侧单结果评估应满足
|
||||
|
||||
- 有且只有一次公共测试输入
|
||||
- 有当前列的 `执行提示词`
|
||||
- 有当前列的 `输出`
|
||||
- 不应再额外出现 `## 当前工作区提示词`
|
||||
- 不应混入别的列输出
|
||||
|
||||
### 右侧对比评估应满足
|
||||
|
||||
- 公共测试输入只出现一次
|
||||
- 至少两个快照
|
||||
- 每个快照只带自己的：
|
||||
- `执行提示词`
|
||||
- `输出`
|
||||
- `推理`（如果有）
|
||||
- 模型 / 版本信息
|
||||
- 不应退回旧 `original / optimized`
|
||||
- 不应再默认出现：
|
||||
- `## 当前工作区提示词`
|
||||
- 每个 variant 一整段重复输入快照
|
||||
- `resolvedPrompt`
|
||||
|
||||
## 5. 路由
|
||||
|
||||
| 工作区 | 路由 |
|
||||
| --- | --- |
|
||||
| `basic-user` | `/#/basic/user` |
|
||||
| `basic-system` | `/#/basic/system` |
|
||||
| `pro-variable` | `/#/pro/variable` |
|
||||
| `pro-multi` | `/#/pro/multi` |
|
||||
|
||||
## 6. 最小测试步骤
|
||||
|
||||
---
|
||||
|
||||
## 6.1 `basic-user`
|
||||
|
||||
### A. 左侧分析
|
||||
|
||||
1. 输入一段用户提示词。
|
||||
2. 不填写右侧测试区。
|
||||
3. 点击左侧 `分析`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 可以返回分析结果。
|
||||
- 请求里只出现当前工作区用户提示词。
|
||||
- 不出现右侧测试文本、输出。
|
||||
|
||||
### B. 右侧单结果评估
|
||||
|
||||
1. 先完成一次优化或测试，让右侧至少有一列结果。
|
||||
2. 在某个结果卡片点击 `评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 请求里有当前列 `执行提示词` 和 `输出`。
|
||||
- 没有别的列输出。
|
||||
- 没有额外的 `## 当前工作区用户提示词`。
|
||||
|
||||
### C. 右侧对比评估
|
||||
|
||||
1. 让至少两列有结果。
|
||||
2. 点击顶部 `对比评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 请求里出现多个快照。
|
||||
- 不是旧 A/B 固定语义。
|
||||
- summary 和建议应围绕快照差异，而不是空泛地说“都可以继续优化”。
|
||||
|
||||
### D. 工作区为空时不应回退到原始提示词
|
||||
|
||||
1. 先完成一次优化和一次测试，确认右侧已经有结果。
|
||||
2. 手动清空下方工作区内容。
|
||||
3. 尝试点击某列 `评估` 或顶部 `对比评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 不应继续发起新的评估请求。
|
||||
- 应提示当前没有可评估的工作区内容。
|
||||
- 旧分数徽章如果之前已存在，可以继续查看，但不能偷偷拿左侧原始提示词继续评估。
|
||||
|
||||
---
|
||||
|
||||
## 6.2 `basic-system`
|
||||
|
||||
### A. 左侧分析
|
||||
|
||||
1. 左侧输入 system prompt。
|
||||
2. 右侧故意填一段明显可识别的测试文本。
|
||||
3. 不跑测试，直接点左侧 `分析`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 分析请求不应带右侧测试文本。
|
||||
|
||||
### B. 右侧单结果评估
|
||||
|
||||
1. 跑出至少一列结果。
|
||||
2. 点击该列 `评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 请求里有：
|
||||
- 公共测试文本
|
||||
- 当前列执行提示词
|
||||
- 当前列输出
|
||||
- 没有别的列输出。
|
||||
|
||||
### C. 右侧对比评估
|
||||
|
||||
1. 跑出两列结果。
|
||||
2. 点击顶部 `对比评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 请求里有公共测试文本一次。
|
||||
- 每个快照只保留自己的执行提示词和输出。
|
||||
- 不再默认注入当前工作区全文。
|
||||
|
||||
### D. 清空测试文本后的旧评估处理
|
||||
|
||||
1. 先跑出两列结果，并完成一次单结果评估或对比评估。
|
||||
2. 保留右侧已有输出不动。
|
||||
3. 清空右侧测试文本。
|
||||
4. 再观察已有评估徽章，并尝试从徽章或详情面板里重跑评估。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 已有评估结果仍可查看。
|
||||
- 徽章应保留，不应直接消失。
|
||||
- 重新评估入口应被禁用，不能再继续发请求。
|
||||
- 不应出现“按钮点了没反应”或直接报 core 校验错误。
|
||||
|
||||
---
|
||||
|
||||
## 6.3 `pro-variable`
|
||||
|
||||
建议提示词：
|
||||
|
||||
```text
|
||||
请根据{{任务描述}}，为{{目标用户}}编写一份{{文档类型}}，要求{{质量要求}}
|
||||
```
|
||||
|
||||
### A. 左侧分析
|
||||
|
||||
1. 填好 prompt。
|
||||
2. 把变量值也填好。
|
||||
3. 不跑右侧测试，直接点左侧 `分析`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 请求里可以看到变量结构。
|
||||
- 不应看到变量具体值。
|
||||
- 不应出现执行态渲染后的额外 prompt。
|
||||
|
||||
### B. 分析后继续优化
|
||||
|
||||
1. 分析完成后关闭面板。
|
||||
2. 点击 `继续优化`。
|
||||
3. 输入一个简单优化方向并确认。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 能正常进入下一版工作区。
|
||||
- 不应出现 `RecordNotFoundError`。
|
||||
|
||||
### C. 右侧单结果评估
|
||||
|
||||
1. 跑出至少一列结果。
|
||||
2. 点击该列 `评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 请求里有一次性的变量值输入。
|
||||
- 有当前列 `执行提示词`。
|
||||
- 有当前列 `输出`。
|
||||
- 不应再额外出现 `resolvedPrompt`。
|
||||
|
||||
### D. 右侧对比评估
|
||||
|
||||
1. 跑出两列结果。
|
||||
2. 点击顶部 `对比评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 公共变量输入只出现一次。
|
||||
- 每个快照只保留自己的执行提示词和输出。
|
||||
- 不应再出现每个 variant 都重复一整段渲染后输入。
|
||||
|
||||
---
|
||||
|
||||
## 6.4 `pro-multi`
|
||||
|
||||
建议最简单示例：
|
||||
|
||||
- `system: 你是一个诗人`
|
||||
- `user: 请你写一首关于{{主题}}的诗。`
|
||||
|
||||
### A. 左侧分析
|
||||
|
||||
1. 选中一条消息作为优化目标。
|
||||
2. 让左侧工作区出现内容。
|
||||
3. 点击左侧 `分析`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 请求里有最小会话位置上下文。
|
||||
- 能看到 `【当前工作区要优化的提示词】` 之类的位置标记。
|
||||
- 不应出现右侧测试输出。
|
||||
- 不应出现完整 transcript JSON。
|
||||
|
||||
### B. 右侧单结果评估
|
||||
|
||||
1. 跑出至少一列结果。
|
||||
2. 点击该列 `评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 公共输入区只带一次会话快照。
|
||||
- 当前列只带自己的执行提示词和输出。
|
||||
- 不应再出现旧的 `targetMessage + conversationMessages` 原始 JSON。
|
||||
|
||||
### C. 右侧对比评估
|
||||
|
||||
1. 跑出两列结果。
|
||||
2. 点击顶部 `对比评估`。
|
||||
|
||||
通过标准：
|
||||
|
||||
- 共享会话输入只出现一次。
|
||||
- 每个快照只保留自己的执行提示词和输出。
|
||||
- 不应为每个快照重复整段会话输入。
|
||||
|
||||
## 7. 最终通过标准
|
||||
|
||||
如果下面 6 条都成立，就可以认为文本主线验收通过：
|
||||
|
||||
1. 左侧分析不吃右侧测试输入。
|
||||
2. `pro-variable` 左侧分析不吃变量值。
|
||||
3. 单结果评估只看当前列。
|
||||
4. 对比评估按多个快照工作，而不是旧 A/B 语义。
|
||||
5. 请求体已经瘦身，不再重复注入工作区全文或重复输入快照。
|
||||
6. `分析 -> 继续优化` 这条真实路径没有历史记录错误。
|
||||
|
||||
建议再补看 2 条：
|
||||
|
||||
7. 工作区为空时，右侧评估不会回退到原始提示词。
|
||||
8. `basic-system` 在清空测试文本后，旧评估可看但不可重跑。
|
||||
|
||||
## 8. 如果发现偏差，优先怎么记
|
||||
|
||||
建议只记录这 3 类信息：
|
||||
|
||||
1. 哪个工作区
|
||||
2. 哪个能力
|
||||
- `prompt-only`
|
||||
- `prompt-iterate`
|
||||
- `result`
|
||||
- `compare`
|
||||
3. 实际多带了什么，或少带了什么
|
||||
|
||||
例如：
|
||||
|
||||
```text
|
||||
pro-variable / result
|
||||
问题：请求里仍带了 resolvedPrompt
|
||||
预期：只保留公共变量输入一次 + 当前列执行提示词 + 当前列输出
|
||||
```
|
||||
@@ -0,0 +1,80 @@
|
||||
# Real API Samples
|
||||
|
||||
> 这里保存真实模型调用的 request / rendered messages / response。
|
||||
> `request.md` / `rendered-messages.md` / `response.md` 都是从对应 JSON 自动渲染出的可读版本，方便人工检查。
|
||||
|
||||
## Cases
|
||||
|
||||
- `basic-system-compare`
|
||||
request: [request.md](./basic-system-compare/request.md)
|
||||
rendered: [rendered-messages.md](./basic-system-compare/rendered-messages.md)
|
||||
response: [response.md](./basic-system-compare/response.md)
|
||||
- `basic-system-compare-focus`
|
||||
request: [request.md](./basic-system-compare-focus/request.md)
|
||||
rendered: [rendered-messages.md](./basic-system-compare-focus/rendered-messages.md)
|
||||
response: [response.md](./basic-system-compare-focus/response.md)
|
||||
- `basic-system-prompt-only-minimal`
|
||||
request: [request.md](./basic-system-prompt-only-minimal/request.md)
|
||||
rendered: [rendered-messages.md](./basic-system-prompt-only-minimal/rendered-messages.md)
|
||||
response: [response.md](./basic-system-prompt-only-minimal/response.md)
|
||||
- `basic-system-result`
|
||||
request: [request.md](./basic-system-result/request.md)
|
||||
rendered: [rendered-messages.md](./basic-system-result/rendered-messages.md)
|
||||
response: [response.md](./basic-system-result/response.md)
|
||||
- `basic-user-compare`
|
||||
request: [request.md](./basic-user-compare/request.md)
|
||||
rendered: [rendered-messages.md](./basic-user-compare/rendered-messages.md)
|
||||
response: [response.md](./basic-user-compare/response.md)
|
||||
- `basic-user-compare-focus`
|
||||
request: [request.md](./basic-user-compare-focus/request.md)
|
||||
rendered: [rendered-messages.md](./basic-user-compare-focus/rendered-messages.md)
|
||||
response: [response.md](./basic-user-compare-focus/response.md)
|
||||
- `basic-user-prompt-iterate-focus`
|
||||
request: [request.md](./basic-user-prompt-iterate-focus/request.md)
|
||||
rendered: [rendered-messages.md](./basic-user-prompt-iterate-focus/rendered-messages.md)
|
||||
response: [response.md](./basic-user-prompt-iterate-focus/response.md)
|
||||
- `basic-user-prompt-only`
|
||||
request: [request.md](./basic-user-prompt-only/request.md)
|
||||
rendered: [rendered-messages.md](./basic-user-prompt-only/rendered-messages.md)
|
||||
response: [response.md](./basic-user-prompt-only/response.md)
|
||||
- `basic-user-result`
|
||||
request: [request.md](./basic-user-result/request.md)
|
||||
rendered: [rendered-messages.md](./basic-user-result/rendered-messages.md)
|
||||
response: [response.md](./basic-user-result/response.md)
|
||||
- `basic-user-result-focus`
|
||||
request: [request.md](./basic-user-result-focus/request.md)
|
||||
rendered: [rendered-messages.md](./basic-user-result-focus/rendered-messages.md)
|
||||
response: [response.md](./basic-user-result-focus/response.md)
|
||||
- `pro-multi-compare`
|
||||
request: [request.md](./pro-multi-compare/request.md)
|
||||
rendered: [rendered-messages.md](./pro-multi-compare/rendered-messages.md)
|
||||
response: [response.md](./pro-multi-compare/response.md)
|
||||
- `pro-multi-prompt-only-system-selected`
|
||||
request: [request.md](./pro-multi-prompt-only-system-selected/request.md)
|
||||
rendered: [rendered-messages.md](./pro-multi-prompt-only-system-selected/rendered-messages.md)
|
||||
response: [response.md](./pro-multi-prompt-only-system-selected/response.md)
|
||||
- `pro-multi-prompt-only-user-selected`
|
||||
request: [request.md](./pro-multi-prompt-only-user-selected/request.md)
|
||||
rendered: [rendered-messages.md](./pro-multi-prompt-only-user-selected/rendered-messages.md)
|
||||
response: [response.md](./pro-multi-prompt-only-user-selected/response.md)
|
||||
- `pro-multi-result`
|
||||
request: [request.md](./pro-multi-result/request.md)
|
||||
rendered: [rendered-messages.md](./pro-multi-result/rendered-messages.md)
|
||||
response: [response.md](./pro-multi-result/response.md)
|
||||
- `pro-variable-compare`
|
||||
request: [request.md](./pro-variable-compare/request.md)
|
||||
rendered: [rendered-messages.md](./pro-variable-compare/rendered-messages.md)
|
||||
response: [response.md](./pro-variable-compare/response.md)
|
||||
- `pro-variable-compare-focus`
|
||||
request: [request.md](./pro-variable-compare-focus/request.md)
|
||||
rendered: [rendered-messages.md](./pro-variable-compare-focus/rendered-messages.md)
|
||||
response: [response.md](./pro-variable-compare-focus/response.md)
|
||||
- `pro-variable-prompt-only-minimal`
|
||||
request: [request.md](./pro-variable-prompt-only-minimal/request.md)
|
||||
rendered: [rendered-messages.md](./pro-variable-prompt-only-minimal/rendered-messages.md)
|
||||
response: [response.md](./pro-variable-prompt-only-minimal/response.md)
|
||||
- `pro-variable-result`
|
||||
request: [request.md](./pro-variable-result/request.md)
|
||||
rendered: [rendered-messages.md](./pro-variable-result/rendered-messages.md)
|
||||
response: [response.md](./pro-variable-result/response.md)
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区系统提示词应如何改进。\n- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. Focus Brief 是本次任务的最高优先级输入。\n5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n6. improvements 仍必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。\n7. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。\n8. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。\n4. 再把每条改进建议映射回这条已观察到的差异。\n5. 判断哪些规律可以安全提炼为可复用结论。\n6. 按对比导向维度打分。\n7. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。\n- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为系统提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（1）\n### 测试用例 测试内容\n#### 输入（测试内容)\n用户说：订单超过一周还没发货，我很着急。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n你是一个助手。\n\n#### 输出\n请耐心等待。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。\n\n#### 输出\n问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等了，我们理解您现在很着急，会立刻帮您核查物流进度并优先跟进。\n\n## Focus Brief\n优先比较哪种系统提示词更能稳定安抚用户情绪并输出风险等级\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,141 @@
|
||||
# basic-system-compare-focus
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 多快照对比评估专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区系统提示词应如何改进。
|
||||
- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。
|
||||
2. 判断哪些证据是可复用规律，哪些只是单次快照现象。
|
||||
|
||||
### Skill-2
|
||||
1. 识别“同提示词跨模型”差异场景。
|
||||
2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。
|
||||
3. 把快照差异收敛成可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Rules
|
||||
1. 各快照与公共测试输入是本次评分的唯一证据。
|
||||
2. 不得使用快照之外的提示词文本来影响评分判断。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. Focus Brief 是本次任务的最高优先级输入。
|
||||
5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
6. improvements 仍必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。
|
||||
7. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。
|
||||
8. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。
|
||||
|
||||
## Workflow
|
||||
1. 读取公共测试用例和全部执行快照。
|
||||
2. 识别多快照中的强模式、弱模式与重复失败模式。
|
||||
3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。
|
||||
4. 再把每条改进建议映射回这条已观察到的差异。
|
||||
5. 判断哪些规律可以安全提炼为可复用结论。
|
||||
6. 按对比导向维度打分。
|
||||
7. 输出可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalAchievementRobustness
|
||||
- outputQualityCeiling
|
||||
- promptPatternQuality
|
||||
- crossSnapshotRobustness
|
||||
- workspaceTransferability
|
||||
- improvements：0-3 条，可复用洞察。
|
||||
- summary：一句短结论。
|
||||
- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。
|
||||
- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": <0-100> },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": <0-100> },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": <0-100> },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": <0-100> },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为系统提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 公共测试用例（1）
|
||||
### 测试用例 测试内容
|
||||
#### 输入（测试内容)
|
||||
用户说：订单超过一周还没发货，我很着急。
|
||||
|
||||
## 执行快照（2）
|
||||
### 快照 A
|
||||
- 提示词来源：原始
|
||||
- 模型：siliconflow
|
||||
- 版本：原始
|
||||
#### 执行提示词
|
||||
你是一个助手。
|
||||
|
||||
#### 输出
|
||||
请耐心等待。
|
||||
|
||||
### 快照 B
|
||||
- 提示词来源：工作区
|
||||
- 模型：dashscope
|
||||
- 版本：工作区
|
||||
#### 执行提示词
|
||||
你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
|
||||
#### 输出
|
||||
问题类型：物流延迟
|
||||
风险等级：中
|
||||
建议回复：非常抱歉让您久等了，我们理解您现在很着急，会立刻帮您核查物流进度并优先跟进。
|
||||
|
||||
## Focus Brief
|
||||
优先比较哪种系统提示词更能稳定安抚用户情绪并输出风险等级
|
||||
|
||||
---
|
||||
|
||||
请基于这些快照做对比评估，并且只返回合法 JSON。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区系统提示词应如何改进。\n- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. Focus Brief 是本次任务的最高优先级输入。\n5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n6. improvements 仍必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。\n7. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。\n8. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。\n4. 再把每条改进建议映射回这条已观察到的差异。\n5. 判断哪些规律可以安全提炼为可复用结论。\n6. 按对比导向维度打分。\n7. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。\n- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为系统提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（1）\n### 测试用例 测试内容\n#### 输入（测试内容)\n用户说：订单超过一周还没发货，我很着急。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n你是一个助手。\n\n#### 输出\n请耐心等待。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。\n\n#### 输出\n问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等了，我们理解您现在很着急，会立刻帮您核查物流进度并优先跟进。\n\n## Focus Brief\n优先比较哪种系统提示词更能稳定安抚用户情绪并输出风险等级\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "system"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先比较哪种系统提示词更能稳定安抚用户情绪并输出风险等级",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"referencePrompt": "你是一个助手。"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-system-focus-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "用户说：订单超过一周还没发货，我很着急。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-system-focus-test-case",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "你是一个助手。",
|
||||
"output": "请耐心等待。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-system-focus-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"output": "问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等了，我们理解您现在很着急，会立刻帮您核查物流进度并优先跟进。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,141 @@
|
||||
# basic-system-compare-focus
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/system`
|
||||
|
||||
## Focus Brief
|
||||
|
||||
优先比较哪种系统提示词更能稳定安抚用户情绪并输出风险等级
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
```
|
||||
|
||||
### Reference Prompt
|
||||
|
||||
```text
|
||||
你是一个助手。
|
||||
```
|
||||
|
||||
## Test Case 1
|
||||
- Id: `shared-system-focus-test-case`
|
||||
- Label: `测试内容`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
```text
|
||||
用户说：订单超过一周还没发货，我很着急。
|
||||
```
|
||||
|
||||
## Snapshot 1
|
||||
- Id: `a`
|
||||
- Label: `A`
|
||||
- Test Case Id: `shared-system-focus-test-case`
|
||||
- Model: `siliconflow`
|
||||
- Version: `原始`
|
||||
- Prompt Source: `原始`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
你是一个助手。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
请耐心等待。
|
||||
```
|
||||
|
||||
## Snapshot 2
|
||||
- Id: `b`
|
||||
- Label: `B`
|
||||
- Test Case Id: `shared-system-focus-test-case`
|
||||
- Model: `dashscope`
|
||||
- Version: `工作区`
|
||||
- Prompt Source: `工作区`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
问题类型：物流延迟
|
||||
风险等级：中
|
||||
建议回复：非常抱歉让您久等了，我们理解您现在很着急，会立刻帮您核查物流进度并优先跟进。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "system"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先比较哪种系统提示词更能稳定安抚用户情绪并输出风险等级",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"referencePrompt": "你是一个助手。"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-system-focus-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "用户说：订单超过一周还没发货，我很着急。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-system-focus-test-case",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "你是一个助手。",
|
||||
"output": "请耐心等待。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-system-focus-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "你是一个客服助手。请先判断问题类型，再评估风险等级，并用安抚性的语气给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"output": "问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等了，我们理解您现在很着急，会立刻帮您核查物流进度并优先跟进。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 72,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 60
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 75
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 55
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"明确角色（如客服助手）并加入任务步骤（如判断问题类型、评估风险等级），能显著提升情绪安抚效果与结构化输出质量。",
|
||||
"增加语气要求（如安抚性语气）和输出格式约束，有助于提高回复的一致性和专业性。",
|
||||
"补充禁止项或示例以避免模糊回应（如'请耐心等待'），从而提升用户感知体验。"
|
||||
],
|
||||
"summary": "快照 B 的系统提示词因包含明确角色、任务步骤及语气要求而更稳定地实现情绪安抚与风险分级输出。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732658145,
|
||||
"duration": 7972
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,79 @@
|
||||
# basic-system-compare-focus
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Model: `dashscope`
|
||||
- Duration: `7972ms`
|
||||
- Timestamp: `1773732658145`
|
||||
|
||||
## Score
|
||||
- Overall: `72`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalAchievementRobustness` | 目标达成稳定性 | 60 |
|
||||
| `outputQualityCeiling` | 输出质量上限 | 85 |
|
||||
| `promptPatternQuality` | 提示词模式质量 | 75 |
|
||||
| `crossSnapshotRobustness` | 跨快照鲁棒性 | 55 |
|
||||
| `workspaceTransferability` | 对工作区的可迁移性 | 80 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 明确角色（如客服助手）并加入任务步骤（如判断问题类型、评估风险等级），能显著提升情绪安抚效果与结构化输出质量。
|
||||
- 增加语气要求（如安抚性语气）和输出格式约束，有助于提高回复的一致性和专业性。
|
||||
- 补充禁止项或示例以避免模糊回应（如'请耐心等待'），从而提升用户感知体验。
|
||||
|
||||
## Summary
|
||||
|
||||
快照 B 的系统提示词因包含明确角色、任务步骤及语气要求而更稳定地实现情绪安抚与风险分级输出。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 72,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 60
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 75
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 55
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"明确角色（如客服助手）并加入任务步骤（如判断问题类型、评估风险等级），能显著提升情绪安抚效果与结构化输出质量。",
|
||||
"增加语气要求（如安抚性语气）和输出格式约束，有助于提高回复的一致性和专业性。",
|
||||
"补充禁止项或示例以避免模糊回应（如'请耐心等待'），从而提升用户感知体验。"
|
||||
],
|
||||
"summary": "快照 B 的系统提示词因包含明确角色、任务步骤及语气要求而更稳定地实现情绪安抚与风险分级输出。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732658145,
|
||||
"duration": 7972
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 72,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": 60 },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": 85 },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": 75 },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": 55 },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": 80 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"明确角色（如客服助手）并加入任务步骤（如判断问题类型、评估风险等级），能显著提升情绪安抚效果与结构化输出质量。",
|
||||
"增加语气要求（如安抚性语气）和输出格式约束，有助于提高回复的一致性和专业性。",
|
||||
"补充禁止项或示例以避免模糊回应（如'请耐心等待'），从而提升用户感知体验。"
|
||||
],
|
||||
"summary": "快照 B 的系统提示词因包含明确角色、任务步骤及语气要求而更稳定地实现情绪安抚与风险分级输出。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 对多个执行快照做比较，并判断哪些改进方向真正有证据支撑。\n- Done Criteria: 先解释哪些已观察到的提示词或输出差异真正造成了快照差距，再提炼出可靠、可复用的结论。\n- Non-Goals: 不要把任务简化成“哪一列赢了”。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. improvements 必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。\n5. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。\n6. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。\n4. 再把每条改进建议映射回这条已观察到的差异。\n5. 判断哪些规律可以安全提炼为可复用结论。\n6. 按对比导向维度打分。\n7. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。\n- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为系统提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（1）\n### 测试用例 测试内容\n#### 输入（测试内容)\n用户说：订单超过一周还没发货，我很着急。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n你是一个助手。\n\n#### 输出\n很抱歉。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。\n\n#### 输出\n问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,136 @@
|
||||
# basic-system-compare
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 多快照对比评估专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。
|
||||
|
||||
## Goal
|
||||
- Outcome: 对多个执行快照做比较，并判断哪些改进方向真正有证据支撑。
|
||||
- Done Criteria: 先解释哪些已观察到的提示词或输出差异真正造成了快照差距，再提炼出可靠、可复用的结论。
|
||||
- Non-Goals: 不要把任务简化成“哪一列赢了”。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。
|
||||
2. 判断哪些证据是可复用规律，哪些只是单次快照现象。
|
||||
|
||||
### Skill-2
|
||||
1. 识别“同提示词跨模型”差异场景。
|
||||
2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。
|
||||
3. 把快照差异收敛成可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Rules
|
||||
1. 各快照与公共测试输入是本次评分的唯一证据。
|
||||
2. 不得使用快照之外的提示词文本来影响评分判断。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. improvements 必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。
|
||||
5. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。
|
||||
6. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。
|
||||
|
||||
## Workflow
|
||||
1. 读取公共测试用例和全部执行快照。
|
||||
2. 识别多快照中的强模式、弱模式与重复失败模式。
|
||||
3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。
|
||||
4. 再把每条改进建议映射回这条已观察到的差异。
|
||||
5. 判断哪些规律可以安全提炼为可复用结论。
|
||||
6. 按对比导向维度打分。
|
||||
7. 输出可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalAchievementRobustness
|
||||
- outputQualityCeiling
|
||||
- promptPatternQuality
|
||||
- crossSnapshotRobustness
|
||||
- workspaceTransferability
|
||||
- improvements：0-3 条，可复用洞察。
|
||||
- summary：一句短结论。
|
||||
- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。
|
||||
- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": <0-100> },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": <0-100> },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": <0-100> },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": <0-100> },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为系统提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 公共测试用例（1）
|
||||
### 测试用例 测试内容
|
||||
#### 输入（测试内容)
|
||||
用户说：订单超过一周还没发货，我很着急。
|
||||
|
||||
## 执行快照（2）
|
||||
### 快照 A
|
||||
- 提示词来源：原始
|
||||
- 模型：siliconflow
|
||||
- 版本：原始
|
||||
#### 执行提示词
|
||||
你是一个助手。
|
||||
|
||||
#### 输出
|
||||
很抱歉。
|
||||
|
||||
### 快照 B
|
||||
- 提示词来源：工作区
|
||||
- 模型：dashscope
|
||||
- 版本：工作区
|
||||
#### 执行提示词
|
||||
你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
|
||||
#### 输出
|
||||
问题类型：物流延迟
|
||||
风险等级：中
|
||||
建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。
|
||||
|
||||
---
|
||||
|
||||
请基于这些快照做对比评估，并且只返回合法 JSON。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 对多个执行快照做比较，并判断哪些改进方向真正有证据支撑。\n- Done Criteria: 先解释哪些已观察到的提示词或输出差异真正造成了快照差距，再提炼出可靠、可复用的结论。\n- Non-Goals: 不要把任务简化成“哪一列赢了”。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. improvements 必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。\n5. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。\n6. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。\n4. 再把每条改进建议映射回这条已观察到的差异。\n5. 判断哪些规律可以安全提炼为可复用结论。\n6. 按对比导向维度打分。\n7. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。\n- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为系统提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（1）\n### 测试用例 测试内容\n#### 输入（测试内容)\n用户说：订单超过一周还没发货，我很着急。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n你是一个助手。\n\n#### 输出\n很抱歉。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。\n\n#### 输出\n问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "system"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"referencePrompt": "你是一个助手。"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "用户说：订单超过一周还没发货，我很着急。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-test-case",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "你是一个助手。",
|
||||
"output": "很抱歉。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"output": "问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,132 @@
|
||||
# basic-system-compare
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/system`
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
```
|
||||
|
||||
### Reference Prompt
|
||||
|
||||
```text
|
||||
你是一个助手。
|
||||
```
|
||||
|
||||
## Test Case 1
|
||||
- Id: `shared-test-case`
|
||||
- Label: `测试内容`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
```text
|
||||
用户说：订单超过一周还没发货，我很着急。
|
||||
```
|
||||
|
||||
## Snapshot 1
|
||||
- Id: `a`
|
||||
- Label: `A`
|
||||
- Test Case Id: `shared-test-case`
|
||||
- Model: `siliconflow`
|
||||
- Version: `原始`
|
||||
- Prompt Source: `原始`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
你是一个助手。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
很抱歉。
|
||||
```
|
||||
|
||||
## Snapshot 2
|
||||
- Id: `b`
|
||||
- Label: `B`
|
||||
- Test Case Id: `shared-test-case`
|
||||
- Model: `dashscope`
|
||||
- Version: `工作区`
|
||||
- Prompt Source: `工作区`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
问题类型：物流延迟
|
||||
风险等级：中
|
||||
建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "system"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"referencePrompt": "你是一个助手。"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "用户说：订单超过一周还没发货，我很着急。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-test-case",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "你是一个助手。",
|
||||
"output": "很抱歉。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"output": "问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 65,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 40
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 30
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 20
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确角色（如客服助手）、任务步骤（判断问题类型）和输出格式，以提升输出结构化与目标达成率。",
|
||||
"增加示例或更具体的约束条件，引导模型生成更贴合场景的回复内容。",
|
||||
"统一不同模型间的提示词规范，增强跨模型响应的一致性和可靠性。"
|
||||
],
|
||||
"summary": "快照 B 表现更好，因为它补充了明确的角色、任务步骤和输出格式，而快照 A 的提示词过于模糊，导致输出质量低且缺乏结构。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732666570,
|
||||
"duration": 8418
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,79 @@
|
||||
# basic-system-compare
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Model: `dashscope`
|
||||
- Duration: `8418ms`
|
||||
- Timestamp: `1773732666570`
|
||||
|
||||
## Score
|
||||
- Overall: `65`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalAchievementRobustness` | 目标达成稳定性 | 40 |
|
||||
| `outputQualityCeiling` | 输出质量上限 | 70 |
|
||||
| `promptPatternQuality` | 提示词模式质量 | 30 |
|
||||
| `crossSnapshotRobustness` | 跨快照鲁棒性 | 20 |
|
||||
| `workspaceTransferability` | 对工作区的可迁移性 | 80 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 在提示词中明确角色（如客服助手）、任务步骤（判断问题类型）和输出格式，以提升输出结构化与目标达成率。
|
||||
- 增加示例或更具体的约束条件，引导模型生成更贴合场景的回复内容。
|
||||
- 统一不同模型间的提示词规范，增强跨模型响应的一致性和可靠性。
|
||||
|
||||
## Summary
|
||||
|
||||
快照 B 表现更好，因为它补充了明确的角色、任务步骤和输出格式，而快照 A 的提示词过于模糊，导致输出质量低且缺乏结构。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 65,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 40
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 30
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 20
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确角色（如客服助手）、任务步骤（判断问题类型）和输出格式，以提升输出结构化与目标达成率。",
|
||||
"增加示例或更具体的约束条件，引导模型生成更贴合场景的回复内容。",
|
||||
"统一不同模型间的提示词规范，增强跨模型响应的一致性和可靠性。"
|
||||
],
|
||||
"summary": "快照 B 表现更好，因为它补充了明确的角色、任务步骤和输出格式，而快照 A 的提示词过于模糊，导致输出质量低且缺乏结构。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732666570,
|
||||
"duration": 8418
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 65,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": 40 },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": 70 },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": 30 },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": 20 },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": 80 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确角色（如客服助手）、任务步骤（判断问题类型）和输出格式，以提升输出结构化与目标达成率。",
|
||||
"增加示例或更具体的约束条件，引导模型生成更贴合场景的回复内容。",
|
||||
"统一不同模型间的提示词规范，增强跨模型响应的一致性和可靠性。"
|
||||
],
|
||||
"summary": "快照 B 表现更好，因为它补充了明确的角色、任务步骤和输出格式，而快照 A 的提示词过于模糊，导致输出质量低且缺乏结构。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词设计分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区系统提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区系统提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前系统提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区系统提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区系统提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区系统提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区系统提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区系统提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为系统提示词分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区系统提示词\n你是一个专业客服质检助手。回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。不要输出思考过程。\n\n## Focus Brief\n重点检查是否足够强调“不要输出思考过程”，并判断分类结构是否会让模型遗漏风险等级\n\n---\n\n请分析当前工作区系统提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,118 @@
|
||||
# basic-system-prompt-only-minimal
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 提示词设计分析专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 在不依赖测试输出的前提下，评估当前工作区系统提示词的设计质量。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区系统提示词是否真正回应了该问题。
|
||||
- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。
|
||||
2. 判断当前系统提示词在不同输入下是否更可能保持稳定。
|
||||
|
||||
### Skill-2
|
||||
1. 把观察结果严格映射回当前工作区系统提示词。
|
||||
2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。
|
||||
|
||||
## Rules
|
||||
1. 当前工作区系统提示词是唯一可修改目标。
|
||||
2. 如果无法可靠映射回当前工作区系统提示词，patchPlan 必须返回 []。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. 本任务没有执行结果，不得评价输出质量。
|
||||
5. Focus Brief 是本次任务的最高优先级输入。
|
||||
6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
|
||||
## Workflow
|
||||
1. 读取当前工作区系统提示词，并将其作为本次分析的主对象。
|
||||
2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。
|
||||
3. 按设计导向维度评分。
|
||||
4. 收敛问题与改进方向。
|
||||
5. 仅在存在精确落点时生成 patchPlan。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalClarity
|
||||
- instructionCompleteness
|
||||
- structuralExecutability
|
||||
- ambiguityControl
|
||||
- robustness
|
||||
- improvements：0-3 条，可复用的设计改进建议。
|
||||
- patchPlan：0-3 条，只允许修改当前工作区系统提示词。
|
||||
- summary：一句短结论。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": <0-100> },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": <0-100> },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": <0-100> },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": <0-100> },
|
||||
{ "key": "robustness", "label": "稳健性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "<当前工作区中可精确匹配的片段>",
|
||||
"newText": "<修改后的内容>",
|
||||
"instruction": "<问题说明 + 修复方案>"
|
||||
}
|
||||
],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为系统提示词分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 当前工作区系统提示词
|
||||
你是一个专业客服质检助手。回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。不要输出思考过程。
|
||||
|
||||
## Focus Brief
|
||||
重点检查是否足够强调“不要输出思考过程”，并判断分类结构是否会让模型遗漏风险等级
|
||||
|
||||
---
|
||||
|
||||
请分析当前工作区系统提示词，并返回严格的 JSON 评估结果。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词设计分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区系统提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区系统提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前系统提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区系统提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区系统提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区系统提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区系统提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区系统提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为系统提示词分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区系统提示词\n你是一个专业客服质检助手。回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。不要输出思考过程。\n\n## Focus Brief\n重点检查是否足够强调“不要输出思考过程”，并判断分类结构是否会让模型遗漏风险等级\n\n---\n\n请分析当前工作区系统提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "system"
|
||||
},
|
||||
"focus": {
|
||||
"content": "重点检查是否足够强调“不要输出思考过程”，并判断分类结构是否会让模型遗漏风险等级",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个专业客服质检助手。回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。不要输出思考过程。"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,40 @@
|
||||
# basic-system-prompt-only-minimal
|
||||
|
||||
## Meta
|
||||
- Type: `prompt-only`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/system`
|
||||
|
||||
## Focus Brief
|
||||
|
||||
重点检查是否足够强调“不要输出思考过程”，并判断分类结构是否会让模型遗漏风险等级
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
你是一个专业客服质检助手。回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。不要输出思考过程。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "system"
|
||||
},
|
||||
"focus": {
|
||||
"content": "重点检查是否足够强调“不要输出思考过程”，并判断分类结构是否会让模型遗漏风险等级",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个专业客服质检助手。回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。不要输出思考过程。"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"score": {
|
||||
"overall": 70,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalClarity",
|
||||
"label": "目标清晰度",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "instructionCompleteness",
|
||||
"label": "指令完备度",
|
||||
"score": 60
|
||||
},
|
||||
{
|
||||
"key": "structuralExecutability",
|
||||
"label": "结构可执行性",
|
||||
"score": 75
|
||||
},
|
||||
{
|
||||
"key": "ambiguityControl",
|
||||
"label": "歧义控制",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "robustness",
|
||||
"label": "稳健性",
|
||||
"score": 65
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中进一步明确强调'不要输出思考过程'，例如使用加粗或重复表述以增强约束力。",
|
||||
"将分类结构拆分为更清晰的子步骤（如：先归类问题类型，再评估风险等级），避免模型因顺序模糊而遗漏关键步骤。"
|
||||
],
|
||||
"summary": "当前系统提示词基本符合质检任务需求，但对'不输出思考过程'的约束不够强，且分类结构可能导致风险等级被忽略。",
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。",
|
||||
"newText": "回答前仅输出以下内容：1. 问题归类；2. 风险等级；3. 建议回复。不得包含任何额外解释或思考过程。",
|
||||
"instruction": "原句未明确禁止输出思考过程，且分类和风险评估可能被模型混为一谈。修改后通过分步骤与强化约束来提升可执行性和稳健性。"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729135763,
|
||||
"duration": 23552
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,102 @@
|
||||
# basic-system-prompt-only-minimal
|
||||
|
||||
## Meta
|
||||
- Type: `prompt-only`
|
||||
- Model: `dashscope`
|
||||
- Duration: `23552ms`
|
||||
- Timestamp: `1773729135763`
|
||||
|
||||
## Score
|
||||
- Overall: `70`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalClarity` | 目标清晰度 | 85 |
|
||||
| `instructionCompleteness` | 指令完备度 | 60 |
|
||||
| `structuralExecutability` | 结构可执行性 | 75 |
|
||||
| `ambiguityControl` | 歧义控制 | 70 |
|
||||
| `robustness` | 稳健性 | 65 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 在提示词中进一步明确强调'不要输出思考过程'，例如使用加粗或重复表述以增强约束力。
|
||||
- 将分类结构拆分为更清晰的子步骤（如：先归类问题类型，再评估风险等级），避免模型因顺序模糊而遗漏关键步骤。
|
||||
|
||||
## Patch Plan
|
||||
|
||||
### Patch 1
|
||||
- Op: `replace`
|
||||
- Instruction: 原句未明确禁止输出思考过程，且分类和风险评估可能被模型混为一谈。修改后通过分步骤与强化约束来提升可执行性和稳健性。
|
||||
|
||||
#### Old Text
|
||||
|
||||
```text
|
||||
回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。
|
||||
```
|
||||
|
||||
#### New Text
|
||||
|
||||
```text
|
||||
回答前仅输出以下内容：1. 问题归类；2. 风险等级；3. 建议回复。不得包含任何额外解释或思考过程。
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
||||
当前系统提示词基本符合质检任务需求，但对'不输出思考过程'的约束不够强，且分类结构可能导致风险等级被忽略。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"score": {
|
||||
"overall": 70,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalClarity",
|
||||
"label": "目标清晰度",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "instructionCompleteness",
|
||||
"label": "指令完备度",
|
||||
"score": 60
|
||||
},
|
||||
{
|
||||
"key": "structuralExecutability",
|
||||
"label": "结构可执行性",
|
||||
"score": 75
|
||||
},
|
||||
{
|
||||
"key": "ambiguityControl",
|
||||
"label": "歧义控制",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "robustness",
|
||||
"label": "稳健性",
|
||||
"score": 65
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中进一步明确强调'不要输出思考过程'，例如使用加粗或重复表述以增强约束力。",
|
||||
"将分类结构拆分为更清晰的子步骤（如：先归类问题类型，再评估风险等级），避免模型因顺序模糊而遗漏关键步骤。"
|
||||
],
|
||||
"summary": "当前系统提示词基本符合质检任务需求，但对'不输出思考过程'的约束不够强，且分类结构可能导致风险等级被忽略。",
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。",
|
||||
"newText": "回答前仅输出以下内容：1. 问题归类；2. 风险等级；3. 建议回复。不得包含任何额外解释或思考过程。",
|
||||
"instruction": "原句未明确禁止输出思考过程，且分类和风险评估可能被模型混为一谈。修改后通过分步骤与强化约束来提升可执行性和稳健性。"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729135763,
|
||||
"duration": 23552
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 70,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": 85 },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": 60 },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": 75 },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": 70 },
|
||||
{ "key": "robustness", "label": "稳健性", "score": 65 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中进一步明确强调'不要输出思考过程'，例如使用加粗或重复表述以增强约束力。",
|
||||
"将分类结构拆分为更清晰的子步骤（如：先归类问题类型，再评估风险等级），避免模型因顺序模糊而遗漏关键步骤。"
|
||||
],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "回答前先判断用户问题类型，再输出：问题归类、风险等级、建议回复。",
|
||||
"newText": "回答前仅输出以下内容：1. 问题归类；2. 风险等级；3. 建议回复。不得包含任何额外解释或思考过程。",
|
||||
"instruction": "原句未明确禁止输出思考过程，且分类和风险评估可能被模型混为一谈。修改后通过分步骤与强化约束来提升可执行性和稳健性。"
|
||||
},
|
||||
{
|
||||
"op": "insert",
|
||||
"oldText": "",
|
||||
"newText": "特别注意：严格遵守格式要求，只输出结果，不添加任何解释、说明或推理过程。",
|
||||
"instruction": "补充强调'不要输出思考过程'的要求，确保模型理解这是不可违反的硬性规则。"
|
||||
}
|
||||
],
|
||||
"summary": "当前系统提示词基本符合质检任务需求，但对'不输出思考过程'的约束不够强，且分类结构可能导致风险等级被忽略。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 单结果执行评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑系统提示词提出可靠改进。\n\n## Goal\n- Outcome: 评估执行快照中该执行提示词本身的表现。\n- Done Criteria: 解释输入、执行提示词、输出之间的关系，并给出可执行改进建议。\n- Non-Goals: 不要把单次快照误判成跨多次执行的稳定结论。\n\n## Skills\n### Skill-1\n1. 联合分析执行提示词、测试用例输入与当前输出。\n2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。\n\n### Skill-2\n1. 尽量区分提示词问题与单次输出偶然性。\n2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。\n\n## Rules\n1. 执行提示词、测试输入和输出是本次评分的唯一证据。\n2. 不得使用执行快照之外的提示词内容来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n\n## Workflow\n1. 读取测试用例输入和执行快照。\n2. 判断这次输出是否完成任务、满足约束。\n3. 按执行导向维度打分。\n4. 解释这次快照反映出该执行提示词的哪些问题或优势。\n5. 输出可迁移回可编辑目标的方向性改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievement\n - outputQuality\n - constraintCompliance\n - promptEffectiveness\n- improvements：0-3 条，可复用建议。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievement\", \"label\": \"目标达成度\", \"score\": <0-100> },\n { \"key\": \"outputQuality\", \"label\": \"输出质量\", \"score\": <0-100> },\n { \"key\": \"constraintCompliance\", \"label\": \"约束符合度\", \"score\": <0-100> },\n { \"key\": \"promptEffectiveness\", \"label\": \"提示词引导有效性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为系统提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 测试用例输入（测试内容)\n用户说：订单超过一周还没发货，我很着急。\n\n## 执行快照 A\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n### 执行提示词\n你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。\n\n### 输出\n问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。\n\n---\n\n请基于这一次执行快照做严格评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,113 @@
|
||||
# basic-system-result
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 单结果执行评估专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑系统提示词提出可靠改进。
|
||||
|
||||
## Goal
|
||||
- Outcome: 评估执行快照中该执行提示词本身的表现。
|
||||
- Done Criteria: 解释输入、执行提示词、输出之间的关系，并给出可执行改进建议。
|
||||
- Non-Goals: 不要把单次快照误判成跨多次执行的稳定结论。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 联合分析执行提示词、测试用例输入与当前输出。
|
||||
2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。
|
||||
|
||||
### Skill-2
|
||||
1. 尽量区分提示词问题与单次输出偶然性。
|
||||
2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。
|
||||
|
||||
## Rules
|
||||
1. 执行提示词、测试输入和输出是本次评分的唯一证据。
|
||||
2. 不得使用执行快照之外的提示词内容来影响评分判断。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
|
||||
## Workflow
|
||||
1. 读取测试用例输入和执行快照。
|
||||
2. 判断这次输出是否完成任务、满足约束。
|
||||
3. 按执行导向维度打分。
|
||||
4. 解释这次快照反映出该执行提示词的哪些问题或优势。
|
||||
5. 输出可迁移回可编辑目标的方向性改进建议。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalAchievement
|
||||
- outputQuality
|
||||
- constraintCompliance
|
||||
- promptEffectiveness
|
||||
- improvements：0-3 条，可复用建议。
|
||||
- summary：一句短结论。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievement", "label": "目标达成度", "score": <0-100> },
|
||||
{ "key": "outputQuality", "label": "输出质量", "score": <0-100> },
|
||||
{ "key": "constraintCompliance", "label": "约束符合度", "score": <0-100> },
|
||||
{ "key": "promptEffectiveness", "label": "提示词引导有效性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为系统提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 测试用例输入（测试内容)
|
||||
用户说：订单超过一周还没发货，我很着急。
|
||||
|
||||
## 执行快照 A
|
||||
- 提示词来源：工作区
|
||||
- 模型：dashscope
|
||||
- 版本：工作区
|
||||
### 执行提示词
|
||||
你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
|
||||
### 输出
|
||||
问题类型：物流延迟
|
||||
风险等级：中
|
||||
建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。
|
||||
|
||||
---
|
||||
|
||||
请基于这一次执行快照做严格评估，并且只返回合法 JSON。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 单结果执行评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑系统提示词提出可靠改进。\n\n## Goal\n- Outcome: 评估执行快照中该执行提示词本身的表现。\n- Done Criteria: 解释输入、执行提示词、输出之间的关系，并给出可执行改进建议。\n- Non-Goals: 不要把单次快照误判成跨多次执行的稳定结论。\n\n## Skills\n### Skill-1\n1. 联合分析执行提示词、测试用例输入与当前输出。\n2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。\n\n### Skill-2\n1. 尽量区分提示词问题与单次输出偶然性。\n2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。\n\n## Rules\n1. 执行提示词、测试输入和输出是本次评分的唯一证据。\n2. 不得使用执行快照之外的提示词内容来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n\n## Workflow\n1. 读取测试用例输入和执行快照。\n2. 判断这次输出是否完成任务、满足约束。\n3. 按执行导向维度打分。\n4. 解释这次快照反映出该执行提示词的哪些问题或优势。\n5. 输出可迁移回可编辑目标的方向性改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievement\n - outputQuality\n - constraintCompliance\n - promptEffectiveness\n- improvements：0-3 条，可复用建议。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievement\", \"label\": \"目标达成度\", \"score\": <0-100> },\n { \"key\": \"outputQuality\", \"label\": \"输出质量\", \"score\": <0-100> },\n { \"key\": \"constraintCompliance\", \"label\": \"约束符合度\", \"score\": <0-100> },\n { \"key\": \"promptEffectiveness\", \"label\": \"提示词引导有效性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为系统提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 测试用例输入（测试内容)\n用户说：订单超过一周还没发货，我很着急。\n\n## 执行快照 A\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n### 执行提示词\n你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。\n\n### 输出\n问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。\n\n---\n\n请基于这一次执行快照做严格评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
{
|
||||
"type": "result",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "system"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"referencePrompt": "你是一个助手。"
|
||||
},
|
||||
"testCase": {
|
||||
"id": "a-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "用户说：订单超过一周还没发货，我很着急。"
|
||||
}
|
||||
},
|
||||
"snapshot": {
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "a-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"output": "问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,95 @@
|
||||
# basic-system-result
|
||||
|
||||
## Meta
|
||||
- Type: `result`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/system`
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
```
|
||||
|
||||
### Reference Prompt
|
||||
|
||||
```text
|
||||
你是一个助手。
|
||||
```
|
||||
|
||||
## Test Case
|
||||
- Id: `a-test-case`
|
||||
- Label: `测试内容`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
```text
|
||||
用户说：订单超过一周还没发货，我很着急。
|
||||
```
|
||||
|
||||
## Snapshot 1
|
||||
- Id: `a`
|
||||
- Label: `A`
|
||||
- Test Case Id: `a-test-case`
|
||||
- Model: `dashscope`
|
||||
- Version: `工作区`
|
||||
- Prompt Source: `工作区`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
问题类型：物流延迟
|
||||
风险等级：中
|
||||
建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "result",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "system"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"referencePrompt": "你是一个助手。"
|
||||
},
|
||||
"testCase": {
|
||||
"id": "a-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "用户说：订单超过一周还没发货，我很着急。"
|
||||
}
|
||||
},
|
||||
"snapshot": {
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "a-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "你是一个客服助手。请先判断问题类型，再给出建议回复。输出格式固定为：问题类型、风险等级、建议回复。",
|
||||
"output": "问题类型：物流延迟\n风险等级：中\n建议回复：非常抱歉让您久等，我们会立即帮您核查物流状态，并优先跟进处理。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,39 @@
|
||||
{
|
||||
"type": "result",
|
||||
"score": {
|
||||
"overall": 85,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievement",
|
||||
"label": "目标达成度",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "outputQuality",
|
||||
"label": "输出质量",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "constraintCompliance",
|
||||
"label": "约束符合度",
|
||||
"score": 100
|
||||
},
|
||||
{
|
||||
"key": "promptEffectiveness",
|
||||
"label": "提示词引导有效性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"可以进一步细化问题类型分类逻辑，例如区分‘物流延迟’与‘仓库处理延迟’，以提高回复的针对性。",
|
||||
"在建议回复中增加安抚性措辞或补偿措施选项（如优惠券、优先发货等），可增强用户体验。"
|
||||
],
|
||||
"summary": "本次执行基本完成任务，输出结构清晰，但可优化分类颗粒度和回复情感温度。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729142369,
|
||||
"duration": 6599
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,71 @@
|
||||
# basic-system-result
|
||||
|
||||
## Meta
|
||||
- Type: `result`
|
||||
- Model: `dashscope`
|
||||
- Duration: `6599ms`
|
||||
- Timestamp: `1773729142369`
|
||||
|
||||
## Score
|
||||
- Overall: `85`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalAchievement` | 目标达成度 | 90 |
|
||||
| `outputQuality` | 输出质量 | 85 |
|
||||
| `constraintCompliance` | 约束符合度 | 100 |
|
||||
| `promptEffectiveness` | 提示词引导有效性 | 80 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 可以进一步细化问题类型分类逻辑，例如区分‘物流延迟’与‘仓库处理延迟’，以提高回复的针对性。
|
||||
- 在建议回复中增加安抚性措辞或补偿措施选项（如优惠券、优先发货等），可增强用户体验。
|
||||
|
||||
## Summary
|
||||
|
||||
本次执行基本完成任务，输出结构清晰，但可优化分类颗粒度和回复情感温度。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "result",
|
||||
"score": {
|
||||
"overall": 85,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievement",
|
||||
"label": "目标达成度",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "outputQuality",
|
||||
"label": "输出质量",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "constraintCompliance",
|
||||
"label": "约束符合度",
|
||||
"score": 100
|
||||
},
|
||||
{
|
||||
"key": "promptEffectiveness",
|
||||
"label": "提示词引导有效性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"可以进一步细化问题类型分类逻辑，例如区分‘物流延迟’与‘仓库处理延迟’，以提高回复的针对性。",
|
||||
"在建议回复中增加安抚性措辞或补偿措施选项（如优惠券、优先发货等），可增强用户体验。"
|
||||
],
|
||||
"summary": "本次执行基本完成任务，输出结构清晰，但可优化分类颗粒度和回复情感温度。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729142369,
|
||||
"duration": 6599
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 85,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievement", "label": "目标达成度", "score": 90 },
|
||||
{ "key": "outputQuality", "label": "输出质量", "score": 85 },
|
||||
{ "key": "constraintCompliance", "label": "约束符合度", "score": 100 },
|
||||
{ "key": "promptEffectiveness", "label": "提示词引导有效性", "score": 80 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"可以进一步细化问题类型分类逻辑，例如区分‘物流延迟’与‘仓库处理延迟’，以提高回复的针对性。",
|
||||
"在建议回复中增加安抚性措辞或补偿措施选项（如优惠券、优先发货等），可增强用户体验。"
|
||||
],
|
||||
"summary": "本次执行基本完成任务，输出结构清晰，但可优化分类颗粒度和回复情感温度。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区用户提示词应如何改进。\n- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. Focus Brief 是本次任务的最高优先级输入。\n5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n6. improvements 仍必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。\n7. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。\n8. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。\n4. 再把每条改进建议映射回这条已观察到的差异。\n5. 判断哪些规律可以安全提炼为可复用结论。\n6. 按对比导向维度打分。\n7. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。\n- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（2）\n### 测试用例 测试内容-无附加输入\n#### 输入（测试内容)\n无额外测试输入，输出直接基于当前提示词生成。\n\n### 测试用例 测试内容-指定意象\n#### 输入（测试内容)\n额外限制了意象范围\n请尽量使用霜叶、孤灯、归雁三个意象。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n写一首诗\n\n#### 输出\n《秋思》\n\n秋风秋雨愁煞人。\n\n这首诗表达思念。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n#### 输出\n《秋思》\n\n霜叶摇灯夜色长，孤窗一点对潇湘。\n归雁无声穿暮霭，离怀有意入秋光。\n\n#### 推理\n该版本没有再追加解释性尾注。\n\n## Focus Brief\n优先比较哪种写法更能稳定避免解释性尾注\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,154 @@
|
||||
# basic-user-compare-focus
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 多快照对比评估专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区用户提示词应如何改进。
|
||||
- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。
|
||||
2. 判断哪些证据是可复用规律，哪些只是单次快照现象。
|
||||
|
||||
### Skill-2
|
||||
1. 识别“同提示词跨模型”差异场景。
|
||||
2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。
|
||||
3. 把快照差异收敛成可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Rules
|
||||
1. 各快照与公共测试输入是本次评分的唯一证据。
|
||||
2. 不得使用快照之外的提示词文本来影响评分判断。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. Focus Brief 是本次任务的最高优先级输入。
|
||||
5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
6. improvements 仍必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。
|
||||
7. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。
|
||||
8. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。
|
||||
|
||||
## Workflow
|
||||
1. 读取公共测试用例和全部执行快照。
|
||||
2. 识别多快照中的强模式、弱模式与重复失败模式。
|
||||
3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。
|
||||
4. 再把每条改进建议映射回这条已观察到的差异。
|
||||
5. 判断哪些规律可以安全提炼为可复用结论。
|
||||
6. 按对比导向维度打分。
|
||||
7. 输出可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalAchievementRobustness
|
||||
- outputQualityCeiling
|
||||
- promptPatternQuality
|
||||
- crossSnapshotRobustness
|
||||
- workspaceTransferability
|
||||
- improvements：0-3 条，可复用洞察。
|
||||
- summary：一句短结论。
|
||||
- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。
|
||||
- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": <0-100> },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": <0-100> },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": <0-100> },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": <0-100> },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为用户提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 公共测试用例（2）
|
||||
### 测试用例 测试内容-无附加输入
|
||||
#### 输入（测试内容)
|
||||
无额外测试输入，输出直接基于当前提示词生成。
|
||||
|
||||
### 测试用例 测试内容-指定意象
|
||||
#### 输入（测试内容)
|
||||
额外限制了意象范围
|
||||
请尽量使用霜叶、孤灯、归雁三个意象。
|
||||
|
||||
## 执行快照（2）
|
||||
### 快照 A
|
||||
- 提示词来源：原始
|
||||
- 模型：siliconflow
|
||||
- 版本：原始
|
||||
#### 执行提示词
|
||||
写一首诗
|
||||
|
||||
#### 输出
|
||||
《秋思》
|
||||
|
||||
秋风秋雨愁煞人。
|
||||
|
||||
这首诗表达思念。
|
||||
|
||||
### 快照 B
|
||||
- 提示词来源：工作区
|
||||
- 模型：dashscope
|
||||
- 版本：工作区
|
||||
#### 执行提示词
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
|
||||
#### 输出
|
||||
《秋思》
|
||||
|
||||
霜叶摇灯夜色长，孤窗一点对潇湘。
|
||||
归雁无声穿暮霭，离怀有意入秋光。
|
||||
|
||||
#### 推理
|
||||
该版本没有再追加解释性尾注。
|
||||
|
||||
## Focus Brief
|
||||
优先比较哪种写法更能稳定避免解释性尾注
|
||||
|
||||
---
|
||||
|
||||
请基于这些快照做对比评估，并且只返回合法 JSON。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区用户提示词应如何改进。\n- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. Focus Brief 是本次任务的最高优先级输入。\n5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n6. improvements 仍必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。\n7. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。\n8. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。\n4. 再把每条改进建议映射回这条已观察到的差异。\n5. 判断哪些规律可以安全提炼为可复用结论。\n6. 按对比导向维度打分。\n7. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。\n- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（2）\n### 测试用例 测试内容-无附加输入\n#### 输入（测试内容)\n无额外测试输入，输出直接基于当前提示词生成。\n\n### 测试用例 测试内容-指定意象\n#### 输入（测试内容)\n额外限制了意象范围\n请尽量使用霜叶、孤灯、归雁三个意象。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n写一首诗\n\n#### 输出\n《秋思》\n\n秋风秋雨愁煞人。\n\n这首诗表达思念。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n#### 输出\n《秋思》\n\n霜叶摇灯夜色长，孤窗一点对潇湘。\n归雁无声穿暮霭，离怀有意入秋光。\n\n#### 推理\n该版本没有再追加解释性尾注。\n\n## Focus Brief\n优先比较哪种写法更能稳定避免解释性尾注\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先比较哪种写法更能稳定避免解释性尾注",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"referencePrompt": "写一首诗"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-test-case-a",
|
||||
"label": "测试内容-无附加输入",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "无额外测试输入，输出直接基于当前提示词生成。"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "shared-test-case-b",
|
||||
"label": "测试内容-指定意象",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"summary": "额外限制了意象范围",
|
||||
"content": "请尽量使用霜叶、孤灯、归雁三个意象。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-test-case-a",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "写一首诗",
|
||||
"output": "《秋思》\n\n秋风秋雨愁煞人。\n\n这首诗表达思念。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-test-case-b",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"output": "《秋思》\n\n霜叶摇灯夜色长，孤窗一点对潇湘。\n归雁无声穿暮霭，离怀有意入秋光。",
|
||||
"reasoning": "该版本没有再追加解释性尾注。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,178 @@
|
||||
# basic-user-compare-focus
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/user`
|
||||
|
||||
## Focus Brief
|
||||
|
||||
优先比较哪种写法更能稳定避免解释性尾注
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
### Reference Prompt
|
||||
|
||||
```text
|
||||
写一首诗
|
||||
```
|
||||
|
||||
## Test Case 1
|
||||
- Id: `shared-test-case-a`
|
||||
- Label: `测试内容-无附加输入`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
```text
|
||||
无额外测试输入，输出直接基于当前提示词生成。
|
||||
```
|
||||
|
||||
## Test Case 2
|
||||
- Id: `shared-test-case-b`
|
||||
- Label: `测试内容-指定意象`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
额外限制了意象范围
|
||||
|
||||
```text
|
||||
请尽量使用霜叶、孤灯、归雁三个意象。
|
||||
```
|
||||
|
||||
## Snapshot 1
|
||||
- Id: `a`
|
||||
- Label: `A`
|
||||
- Test Case Id: `shared-test-case-a`
|
||||
- Model: `siliconflow`
|
||||
- Version: `原始`
|
||||
- Prompt Source: `原始`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
写一首诗
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
《秋思》
|
||||
|
||||
秋风秋雨愁煞人。
|
||||
|
||||
这首诗表达思念。
|
||||
```
|
||||
|
||||
## Snapshot 2
|
||||
- Id: `b`
|
||||
- Label: `B`
|
||||
- Test Case Id: `shared-test-case-b`
|
||||
- Model: `dashscope`
|
||||
- Version: `工作区`
|
||||
- Prompt Source: `工作区`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
《秋思》
|
||||
|
||||
霜叶摇灯夜色长，孤窗一点对潇湘。
|
||||
归雁无声穿暮霭，离怀有意入秋光。
|
||||
```
|
||||
|
||||
### Reasoning
|
||||
|
||||
```text
|
||||
该版本没有再追加解释性尾注。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先比较哪种写法更能稳定避免解释性尾注",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"referencePrompt": "写一首诗"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-test-case-a",
|
||||
"label": "测试内容-无附加输入",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "无额外测试输入，输出直接基于当前提示词生成。"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "shared-test-case-b",
|
||||
"label": "测试内容-指定意象",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"summary": "额外限制了意象范围",
|
||||
"content": "请尽量使用霜叶、孤灯、归雁三个意象。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-test-case-a",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "写一首诗",
|
||||
"output": "《秋思》\n\n秋风秋雨愁煞人。\n\n这首诗表达思念。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-test-case-b",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"output": "《秋思》\n\n霜叶摇灯夜色长，孤窗一点对潇湘。\n归雁无声穿暮霭，离怀有意入秋光。",
|
||||
"reasoning": "该版本没有再追加解释性尾注。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 68,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 75
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 70
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确禁止解释性尾注，如添加『不要追加解释』或『直接以诗作结』等指令。",
|
||||
"补充具体格式要求（如押韵、句数）有助于引导模型生成更符合预期的结构化内容。",
|
||||
"通过指定意象或场景增强约束条件，可提升输出聚焦度和风格一致性。"
|
||||
],
|
||||
"summary": "快照 B 更能稳定避免解释性尾注，因其明确禁止了此类输出并提供了结构化约束。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732650164,
|
||||
"duration": 15042
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,79 @@
|
||||
# basic-user-compare-focus
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Model: `dashscope`
|
||||
- Duration: `15042ms`
|
||||
- Timestamp: `1773732650164`
|
||||
|
||||
## Score
|
||||
- Overall: `68`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalAchievementRobustness` | 目标达成稳定性 | 70 |
|
||||
| `outputQualityCeiling` | 输出质量上限 | 85 |
|
||||
| `promptPatternQuality` | 提示词模式质量 | 75 |
|
||||
| `crossSnapshotRobustness` | 跨快照鲁棒性 | 50 |
|
||||
| `workspaceTransferability` | 对工作区的可迁移性 | 70 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 在提示词中明确禁止解释性尾注，如添加『不要追加解释』或『直接以诗作结』等指令。
|
||||
- 补充具体格式要求（如押韵、句数）有助于引导模型生成更符合预期的结构化内容。
|
||||
- 通过指定意象或场景增强约束条件，可提升输出聚焦度和风格一致性。
|
||||
|
||||
## Summary
|
||||
|
||||
快照 B 更能稳定避免解释性尾注，因其明确禁止了此类输出并提供了结构化约束。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 68,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 75
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 70
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确禁止解释性尾注，如添加『不要追加解释』或『直接以诗作结』等指令。",
|
||||
"补充具体格式要求（如押韵、句数）有助于引导模型生成更符合预期的结构化内容。",
|
||||
"通过指定意象或场景增强约束条件，可提升输出聚焦度和风格一致性。"
|
||||
],
|
||||
"summary": "快照 B 更能稳定避免解释性尾注，因其明确禁止了此类输出并提供了结构化约束。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732650164,
|
||||
"duration": 15042
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 68,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": 70 },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": 85 },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": 75 },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": 50 },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": 70 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确禁止解释性尾注，如添加『不要追加解释』或『直接以诗作结』等指令。",
|
||||
"补充具体格式要求（如押韵、句数）有助于引导模型生成更符合预期的结构化内容。",
|
||||
"通过指定意象或场景增强约束条件，可提升输出聚焦度和风格一致性。"
|
||||
],
|
||||
"summary": "快照 B 更能稳定避免解释性尾注，因其明确禁止了此类输出并提供了结构化约束。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 对多个执行快照做比较，并判断哪些改进方向真正有证据支撑。\n- Done Criteria: 先解释哪些已观察到的提示词或输出差异真正造成了快照差距，再提炼出可靠、可复用的结论。\n- Non-Goals: 不要把任务简化成“哪一列赢了”。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. improvements 必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。\n5. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。\n6. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。\n4. 再把每条改进建议映射回这条已观察到的差异。\n5. 判断哪些规律可以安全提炼为可复用结论。\n6. 按对比导向维度打分。\n7. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。\n- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（2）\n### 测试用例 测试内容-无附加输入\n#### 输入（测试内容)\n无额外测试输入，输出直接基于当前提示词生成。\n\n### 测试用例 测试内容-指定意象\n#### 输入（测试内容)\n额外限制了意象范围\n请尽量使用霜叶、孤灯、归雁三个意象。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n写一首诗\n\n#### 输出\n《秋思》\n\n秋风秋雨愁煞人。\n\n这首诗表达思念。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n#### 输出\n《秋思》\n\n霜叶摇灯夜色长，孤窗一点对潇湘。\n归雁无声穿暮霭，离怀有意入秋光。\n\n#### 推理\n该版本没有再追加解释性尾注。\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,149 @@
|
||||
# basic-user-compare
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 多快照对比评估专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。
|
||||
|
||||
## Goal
|
||||
- Outcome: 对多个执行快照做比较，并判断哪些改进方向真正有证据支撑。
|
||||
- Done Criteria: 先解释哪些已观察到的提示词或输出差异真正造成了快照差距，再提炼出可靠、可复用的结论。
|
||||
- Non-Goals: 不要把任务简化成“哪一列赢了”。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。
|
||||
2. 判断哪些证据是可复用规律，哪些只是单次快照现象。
|
||||
|
||||
### Skill-2
|
||||
1. 识别“同提示词跨模型”差异场景。
|
||||
2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。
|
||||
3. 把快照差异收敛成可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Rules
|
||||
1. 各快照与公共测试输入是本次评分的唯一证据。
|
||||
2. 不得使用快照之外的提示词文本来影响评分判断。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. improvements 必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。
|
||||
5. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。
|
||||
6. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。
|
||||
|
||||
## Workflow
|
||||
1. 读取公共测试用例和全部执行快照。
|
||||
2. 识别多快照中的强模式、弱模式与重复失败模式。
|
||||
3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。
|
||||
4. 再把每条改进建议映射回这条已观察到的差异。
|
||||
5. 判断哪些规律可以安全提炼为可复用结论。
|
||||
6. 按对比导向维度打分。
|
||||
7. 输出可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalAchievementRobustness
|
||||
- outputQualityCeiling
|
||||
- promptPatternQuality
|
||||
- crossSnapshotRobustness
|
||||
- workspaceTransferability
|
||||
- improvements：0-3 条，可复用洞察。
|
||||
- summary：一句短结论。
|
||||
- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。
|
||||
- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": <0-100> },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": <0-100> },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": <0-100> },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": <0-100> },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为用户提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 公共测试用例（2）
|
||||
### 测试用例 测试内容-无附加输入
|
||||
#### 输入（测试内容)
|
||||
无额外测试输入，输出直接基于当前提示词生成。
|
||||
|
||||
### 测试用例 测试内容-指定意象
|
||||
#### 输入（测试内容)
|
||||
额外限制了意象范围
|
||||
请尽量使用霜叶、孤灯、归雁三个意象。
|
||||
|
||||
## 执行快照（2）
|
||||
### 快照 A
|
||||
- 提示词来源：原始
|
||||
- 模型：siliconflow
|
||||
- 版本：原始
|
||||
#### 执行提示词
|
||||
写一首诗
|
||||
|
||||
#### 输出
|
||||
《秋思》
|
||||
|
||||
秋风秋雨愁煞人。
|
||||
|
||||
这首诗表达思念。
|
||||
|
||||
### 快照 B
|
||||
- 提示词来源：工作区
|
||||
- 模型：dashscope
|
||||
- 版本：工作区
|
||||
#### 执行提示词
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
|
||||
#### 输出
|
||||
《秋思》
|
||||
|
||||
霜叶摇灯夜色长，孤窗一点对潇湘。
|
||||
归雁无声穿暮霭，离怀有意入秋光。
|
||||
|
||||
#### 推理
|
||||
该版本没有再追加解释性尾注。
|
||||
|
||||
---
|
||||
|
||||
请基于这些快照做对比评估，并且只返回合法 JSON。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 对多个执行快照做比较，并判断哪些改进方向真正有证据支撑。\n- Done Criteria: 先解释哪些已观察到的提示词或输出差异真正造成了快照差距，再提炼出可靠、可复用的结论。\n- Non-Goals: 不要把任务简化成“哪一列赢了”。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. improvements 必须从快照之间已观察到的差异中提炼，不能先发散到证据里从未出现过的增强项。\n5. 如果某个快照之所以更强，是因为它补充了更明确的角色、任务步骤、输出格式、禁止项或示例，summary 必须直接点名这类已观察到的差异，且第一条 improvement 必须优先补它。\n6. 不得虚构公共测试用例或输出里没有出现的额外场景设定、用户状态或配置条件。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 先识别最能解释快照差距的那条“已观察到的提示词差异”。\n4. 再把每条改进建议映射回这条已观察到的差异。\n5. 判断哪些规律可以安全提炼为可复用结论。\n6. 按对比导向维度打分。\n7. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n- summary 不能只说哪一列更好，必须点名最关键的“已观察到的差异”是什么。\n- 第一条 improvement 必须优先处理这条已观察到的关键差异，再谈次级增强项。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（2）\n### 测试用例 测试内容-无附加输入\n#### 输入（测试内容)\n无额外测试输入，输出直接基于当前提示词生成。\n\n### 测试用例 测试内容-指定意象\n#### 输入（测试内容)\n额外限制了意象范围\n请尽量使用霜叶、孤灯、归雁三个意象。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n写一首诗\n\n#### 输出\n《秋思》\n\n秋风秋雨愁煞人。\n\n这首诗表达思念。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n#### 输出\n《秋思》\n\n霜叶摇灯夜色长，孤窗一点对潇湘。\n归雁无声穿暮霭，离怀有意入秋光。\n\n#### 推理\n该版本没有再追加解释性尾注。\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,62 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"referencePrompt": "写一首诗"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-test-case-a",
|
||||
"label": "测试内容-无附加输入",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "无额外测试输入，输出直接基于当前提示词生成。"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "shared-test-case-b",
|
||||
"label": "测试内容-指定意象",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"summary": "额外限制了意象范围",
|
||||
"content": "请尽量使用霜叶、孤灯、归雁三个意象。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-test-case-a",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "写一首诗",
|
||||
"output": "《秋思》\n\n秋风秋雨愁煞人。\n\n这首诗表达思念。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-test-case-b",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"output": "《秋思》\n\n霜叶摇灯夜色长，孤窗一点对潇湘。\n归雁无声穿暮霭，离怀有意入秋光。",
|
||||
"reasoning": "该版本没有再追加解释性尾注。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,169 @@
|
||||
# basic-user-compare
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/user`
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
### Reference Prompt
|
||||
|
||||
```text
|
||||
写一首诗
|
||||
```
|
||||
|
||||
## Test Case 1
|
||||
- Id: `shared-test-case-a`
|
||||
- Label: `测试内容-无附加输入`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
```text
|
||||
无额外测试输入，输出直接基于当前提示词生成。
|
||||
```
|
||||
|
||||
## Test Case 2
|
||||
- Id: `shared-test-case-b`
|
||||
- Label: `测试内容-指定意象`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
额外限制了意象范围
|
||||
|
||||
```text
|
||||
请尽量使用霜叶、孤灯、归雁三个意象。
|
||||
```
|
||||
|
||||
## Snapshot 1
|
||||
- Id: `a`
|
||||
- Label: `A`
|
||||
- Test Case Id: `shared-test-case-a`
|
||||
- Model: `siliconflow`
|
||||
- Version: `原始`
|
||||
- Prompt Source: `原始`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
写一首诗
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
《秋思》
|
||||
|
||||
秋风秋雨愁煞人。
|
||||
|
||||
这首诗表达思念。
|
||||
```
|
||||
|
||||
## Snapshot 2
|
||||
- Id: `b`
|
||||
- Label: `B`
|
||||
- Test Case Id: `shared-test-case-b`
|
||||
- Model: `dashscope`
|
||||
- Version: `工作区`
|
||||
- Prompt Source: `工作区`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
《秋思》
|
||||
|
||||
霜叶摇灯夜色长，孤窗一点对潇湘。
|
||||
归雁无声穿暮霭，离怀有意入秋光。
|
||||
```
|
||||
|
||||
### Reasoning
|
||||
|
||||
```text
|
||||
该版本没有再追加解释性尾注。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"referencePrompt": "写一首诗"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-test-case-a",
|
||||
"label": "测试内容-无附加输入",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "无额外测试输入，输出直接基于当前提示词生成。"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "shared-test-case-b",
|
||||
"label": "测试内容-指定意象",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"summary": "额外限制了意象范围",
|
||||
"content": "请尽量使用霜叶、孤灯、归雁三个意象。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-test-case-a",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "写一首诗",
|
||||
"output": "《秋思》\n\n秋风秋雨愁煞人。\n\n这首诗表达思念。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-test-case-b",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"output": "《秋思》\n\n霜叶摇灯夜色长，孤窗一点对潇湘。\n归雁无声穿暮霭，离怀有意入秋光。",
|
||||
"reasoning": "该版本没有再追加解释性尾注。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 78,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 65
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 60
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 85
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在原始提示词中补充明确的任务类型（如七言律诗）、表达方式要求（含蓄、不解释）和意象范围，可以显著提升模型输出的质量与一致性。",
|
||||
"为提高跨快照鲁棒性，建议在提示词中加入格式规范（如八句四联、押平声韵），以减少模型因理解偏差导致的输出不稳定。",
|
||||
"在需要控制输出风格时，应避免模糊指令（如“写一首诗”），而应使用更具体的任务描述，引导模型聚焦于特定文学形式或情感表达。"
|
||||
],
|
||||
"summary": "快照 B 的输出质量更高，主要得益于其明确了任务类型、格式约束及禁止项，这些差异直接影响了生成结果的文学性和一致性。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732635109,
|
||||
"duration": 10153
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,79 @@
|
||||
# basic-user-compare
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Model: `dashscope`
|
||||
- Duration: `10153ms`
|
||||
- Timestamp: `1773732635109`
|
||||
|
||||
## Score
|
||||
- Overall: `78`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalAchievementRobustness` | 目标达成稳定性 | 70 |
|
||||
| `outputQualityCeiling` | 输出质量上限 | 90 |
|
||||
| `promptPatternQuality` | 提示词模式质量 | 65 |
|
||||
| `crossSnapshotRobustness` | 跨快照鲁棒性 | 60 |
|
||||
| `workspaceTransferability` | 对工作区的可迁移性 | 85 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 在原始提示词中补充明确的任务类型（如七言律诗）、表达方式要求（含蓄、不解释）和意象范围，可以显著提升模型输出的质量与一致性。
|
||||
- 为提高跨快照鲁棒性，建议在提示词中加入格式规范（如八句四联、押平声韵），以减少模型因理解偏差导致的输出不稳定。
|
||||
- 在需要控制输出风格时，应避免模糊指令（如“写一首诗”），而应使用更具体的任务描述，引导模型聚焦于特定文学形式或情感表达。
|
||||
|
||||
## Summary
|
||||
|
||||
快照 B 的输出质量更高，主要得益于其明确了任务类型、格式约束及禁止项，这些差异直接影响了生成结果的文学性和一致性。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 78,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 65
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 60
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 85
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在原始提示词中补充明确的任务类型（如七言律诗）、表达方式要求（含蓄、不解释）和意象范围，可以显著提升模型输出的质量与一致性。",
|
||||
"为提高跨快照鲁棒性，建议在提示词中加入格式规范（如八句四联、押平声韵），以减少模型因理解偏差导致的输出不稳定。",
|
||||
"在需要控制输出风格时，应避免模糊指令（如“写一首诗”），而应使用更具体的任务描述，引导模型聚焦于特定文学形式或情感表达。"
|
||||
],
|
||||
"summary": "快照 B 的输出质量更高，主要得益于其明确了任务类型、格式约束及禁止项，这些差异直接影响了生成结果的文学性和一致性。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732635109,
|
||||
"duration": 10153
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 78,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": 70 },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": 90 },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": 65 },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": 60 },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": 85 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在原始提示词中补充明确的任务类型（如七言律诗）、表达方式要求（含蓄、不解释）和意象范围，可以显著提升模型输出的质量与一致性。",
|
||||
"为提高跨快照鲁棒性，建议在提示词中加入格式规范（如八句四联、押平声韵），以减少模型因理解偏差导致的输出不稳定。",
|
||||
"在需要控制输出风格时，应避免模糊指令（如“写一首诗”），而应使用更具体的任务描述，引导模型聚焦于特定文学形式或情感表达。"
|
||||
],
|
||||
"summary": "快照 B 的输出质量更高，主要得益于其明确了任务类型、格式约束及禁止项，这些差异直接影响了生成结果的文学性和一致性。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词迭代分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区用户提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区用户提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前用户提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区用户提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区用户提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区用户提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区用户提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区用户提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词迭代分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区用户提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n## 迭代要求\n保持“秋日思念的七言律诗”任务不变，只增强“不要解释”的约束，避免任何诗后说明、注释、总结。\n\n## Focus Brief\n优先强化“不要解释”，避免诗后追加说明、注释或尾注\n\n---\n\n请分析当前工作区用户提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,121 @@
|
||||
# basic-user-prompt-iterate-focus
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 提示词迭代分析专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 在不依赖测试输出的前提下，评估当前工作区用户提示词的设计质量。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区用户提示词是否真正回应了该问题。
|
||||
- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。
|
||||
2. 判断当前用户提示词在不同输入下是否更可能保持稳定。
|
||||
|
||||
### Skill-2
|
||||
1. 把观察结果严格映射回当前工作区用户提示词。
|
||||
2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。
|
||||
|
||||
## Rules
|
||||
1. 当前工作区用户提示词是唯一可修改目标。
|
||||
2. 如果无法可靠映射回当前工作区用户提示词，patchPlan 必须返回 []。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. 本任务没有执行结果，不得评价输出质量。
|
||||
5. Focus Brief 是本次任务的最高优先级输入。
|
||||
6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
|
||||
## Workflow
|
||||
1. 读取当前工作区用户提示词，并将其作为本次分析的主对象。
|
||||
2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。
|
||||
3. 按设计导向维度评分。
|
||||
4. 收敛问题与改进方向。
|
||||
5. 仅在存在精确落点时生成 patchPlan。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalClarity
|
||||
- instructionCompleteness
|
||||
- structuralExecutability
|
||||
- ambiguityControl
|
||||
- robustness
|
||||
- improvements：0-3 条，可复用的设计改进建议。
|
||||
- patchPlan：0-3 条，只允许修改当前工作区用户提示词。
|
||||
- summary：一句短结论。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": <0-100> },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": <0-100> },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": <0-100> },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": <0-100> },
|
||||
{ "key": "robustness", "label": "稳健性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "<当前工作区中可精确匹配的片段>",
|
||||
"newText": "<修改后的内容>",
|
||||
"instruction": "<问题说明 + 修复方案>"
|
||||
}
|
||||
],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为用户提示词迭代分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 当前工作区用户提示词
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
|
||||
## 迭代要求
|
||||
保持“秋日思念的七言律诗”任务不变，只增强“不要解释”的约束，避免任何诗后说明、注释、总结。
|
||||
|
||||
## Focus Brief
|
||||
优先强化“不要解释”，避免诗后追加说明、注释或尾注
|
||||
|
||||
---
|
||||
|
||||
请分析当前工作区用户提示词，并返回严格的 JSON 评估结果。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词迭代分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区用户提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区用户提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前用户提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区用户提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区用户提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区用户提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区用户提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区用户提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词迭代分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区用户提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n## 迭代要求\n保持“秋日思念的七言律诗”任务不变，只增强“不要解释”的约束，避免任何诗后说明、注释、总结。\n\n## Focus Brief\n优先强化“不要解释”，避免诗后追加说明、注释或尾注\n\n---\n\n请分析当前工作区用户提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
{
|
||||
"type": "prompt-iterate",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先强化“不要解释”，避免诗后追加说明、注释或尾注",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"iterateRequirement": "保持“秋日思念的七言律诗”任务不变，只增强“不要解释”的约束，避免任何诗后说明、注释、总结。",
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,45 @@
|
||||
# basic-user-prompt-iterate-focus
|
||||
|
||||
## Meta
|
||||
- Type: `prompt-iterate`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/user`
|
||||
|
||||
## Focus Brief
|
||||
|
||||
优先强化“不要解释”，避免诗后追加说明、注释或尾注
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
## Iterate Requirement
|
||||
|
||||
保持“秋日思念的七言律诗”任务不变，只增强“不要解释”的约束，避免任何诗后说明、注释、总结。
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "prompt-iterate",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先强化“不要解释”，避免诗后追加说明、注释或尾注",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"iterateRequirement": "保持“秋日思念的七言律诗”任务不变，只增强“不要解释”的约束，避免任何诗后说明、注释、总结。",
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
{
|
||||
"type": "prompt-iterate",
|
||||
"score": {
|
||||
"overall": 80,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalClarity",
|
||||
"label": "目标清晰度",
|
||||
"score": 95
|
||||
},
|
||||
{
|
||||
"key": "instructionCompleteness",
|
||||
"label": "指令完备度",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "structuralExecutability",
|
||||
"label": "结构可执行性",
|
||||
"score": 80
|
||||
},
|
||||
{
|
||||
"key": "ambiguityControl",
|
||||
"label": "歧义控制",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "robustness",
|
||||
"label": "稳健性",
|
||||
"score": 75
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在‘不要解释’后增加具体限制，如‘不添加诗后说明、注释或总结’以增强约束明确性。",
|
||||
"可以考虑加入‘仅输出诗句内容’等措辞，进一步减少附加输出的可能性。"
|
||||
],
|
||||
"summary": "当前提示词整体表现良好，但‘不要解释’的约束需进一步强化以避免额外输出。",
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "3. 语言凝练含蓄，不要解释。",
|
||||
"newText": "3. 语言凝练含蓄，仅输出诗句内容，不得附带任何解释、注释或总结。",
|
||||
"instruction": "原提示词中‘不要解释’较为宽泛，修改为更具体的限制，确保用户意图被准确响应。"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729086704,
|
||||
"duration": 9330
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,102 @@
|
||||
# basic-user-prompt-iterate-focus
|
||||
|
||||
## Meta
|
||||
- Type: `prompt-iterate`
|
||||
- Model: `dashscope`
|
||||
- Duration: `9330ms`
|
||||
- Timestamp: `1773729086704`
|
||||
|
||||
## Score
|
||||
- Overall: `80`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalClarity` | 目标清晰度 | 95 |
|
||||
| `instructionCompleteness` | 指令完备度 | 85 |
|
||||
| `structuralExecutability` | 结构可执行性 | 80 |
|
||||
| `ambiguityControl` | 歧义控制 | 90 |
|
||||
| `robustness` | 稳健性 | 75 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 在‘不要解释’后增加具体限制，如‘不添加诗后说明、注释或总结’以增强约束明确性。
|
||||
- 可以考虑加入‘仅输出诗句内容’等措辞，进一步减少附加输出的可能性。
|
||||
|
||||
## Patch Plan
|
||||
|
||||
### Patch 1
|
||||
- Op: `replace`
|
||||
- Instruction: 原提示词中‘不要解释’较为宽泛，修改为更具体的限制，确保用户意图被准确响应。
|
||||
|
||||
#### Old Text
|
||||
|
||||
```text
|
||||
3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
#### New Text
|
||||
|
||||
```text
|
||||
3. 语言凝练含蓄，仅输出诗句内容，不得附带任何解释、注释或总结。
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
||||
当前提示词整体表现良好，但‘不要解释’的约束需进一步强化以避免额外输出。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "prompt-iterate",
|
||||
"score": {
|
||||
"overall": 80,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalClarity",
|
||||
"label": "目标清晰度",
|
||||
"score": 95
|
||||
},
|
||||
{
|
||||
"key": "instructionCompleteness",
|
||||
"label": "指令完备度",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "structuralExecutability",
|
||||
"label": "结构可执行性",
|
||||
"score": 80
|
||||
},
|
||||
{
|
||||
"key": "ambiguityControl",
|
||||
"label": "歧义控制",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "robustness",
|
||||
"label": "稳健性",
|
||||
"score": 75
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在‘不要解释’后增加具体限制，如‘不添加诗后说明、注释或总结’以增强约束明确性。",
|
||||
"可以考虑加入‘仅输出诗句内容’等措辞，进一步减少附加输出的可能性。"
|
||||
],
|
||||
"summary": "当前提示词整体表现良好，但‘不要解释’的约束需进一步强化以避免额外输出。",
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "3. 语言凝练含蓄，不要解释。",
|
||||
"newText": "3. 语言凝练含蓄，仅输出诗句内容，不得附带任何解释、注释或总结。",
|
||||
"instruction": "原提示词中‘不要解释’较为宽泛，修改为更具体的限制，确保用户意图被准确响应。"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729086704,
|
||||
"duration": 9330
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 80,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": 95 },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": 85 },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": 80 },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": 90 },
|
||||
{ "key": "robustness", "label": "稳健性", "score": 75 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在‘不要解释’后增加具体限制，如‘不添加诗后说明、注释或总结’以增强约束明确性。",
|
||||
"可以考虑加入‘仅输出诗句内容’等措辞，进一步减少附加输出的可能性。"
|
||||
],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "3. 语言凝练含蓄，不要解释。",
|
||||
"newText": "3. 语言凝练含蓄，仅输出诗句内容，不得附带任何解释、注释或总结。",
|
||||
"instruction": "原提示词中‘不要解释’较为宽泛，修改为更具体的限制，确保用户意图被准确响应。"
|
||||
}
|
||||
],
|
||||
"summary": "当前提示词整体表现良好，但‘不要解释’的约束需进一步强化以避免额外输出。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1 @@
|
||||
[]
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词设计分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区用户提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区用户提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前用户提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区用户提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区用户提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区用户提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区用户提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区用户提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区用户提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n## Focus Brief\n重点检查“不要解释”是否写得足够强，并判断是否会诱发模型追加说明性尾注\n\n---\n\n请分析当前工作区用户提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,118 @@
|
||||
# basic-user-prompt-only
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 提示词设计分析专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 在不依赖测试输出的前提下，评估当前工作区用户提示词的设计质量。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区用户提示词是否真正回应了该问题。
|
||||
- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。
|
||||
2. 判断当前用户提示词在不同输入下是否更可能保持稳定。
|
||||
|
||||
### Skill-2
|
||||
1. 把观察结果严格映射回当前工作区用户提示词。
|
||||
2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。
|
||||
|
||||
## Rules
|
||||
1. 当前工作区用户提示词是唯一可修改目标。
|
||||
2. 如果无法可靠映射回当前工作区用户提示词，patchPlan 必须返回 []。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. 本任务没有执行结果，不得评价输出质量。
|
||||
5. Focus Brief 是本次任务的最高优先级输入。
|
||||
6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
|
||||
## Workflow
|
||||
1. 读取当前工作区用户提示词，并将其作为本次分析的主对象。
|
||||
2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。
|
||||
3. 按设计导向维度评分。
|
||||
4. 收敛问题与改进方向。
|
||||
5. 仅在存在精确落点时生成 patchPlan。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalClarity
|
||||
- instructionCompleteness
|
||||
- structuralExecutability
|
||||
- ambiguityControl
|
||||
- robustness
|
||||
- improvements：0-3 条，可复用的设计改进建议。
|
||||
- patchPlan：0-3 条，只允许修改当前工作区用户提示词。
|
||||
- summary：一句短结论。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": <0-100> },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": <0-100> },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": <0-100> },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": <0-100> },
|
||||
{ "key": "robustness", "label": "稳健性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "<当前工作区中可精确匹配的片段>",
|
||||
"newText": "<修改后的内容>",
|
||||
"instruction": "<问题说明 + 修复方案>"
|
||||
}
|
||||
],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为用户提示词分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 当前工作区用户提示词
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
|
||||
## Focus Brief
|
||||
重点检查“不要解释”是否写得足够强，并判断是否会诱发模型追加说明性尾注
|
||||
|
||||
---
|
||||
|
||||
请分析当前工作区用户提示词，并返回严格的 JSON 评估结果。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词设计分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区用户提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区用户提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前用户提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区用户提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区用户提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区用户提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区用户提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区用户提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区用户提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n## Focus Brief\n重点检查“不要解释”是否写得足够强，并判断是否会诱发模型追加说明性尾注\n\n---\n\n请分析当前工作区用户提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"focus": {
|
||||
"content": "重点检查“不要解释”是否写得足够强，并判断是否会诱发模型追加说明性尾注",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,40 @@
|
||||
# basic-user-prompt-only
|
||||
|
||||
## Meta
|
||||
- Type: `prompt-only`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/user`
|
||||
|
||||
## Focus Brief
|
||||
|
||||
重点检查“不要解释”是否写得足够强，并判断是否会诱发模型追加说明性尾注
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"focus": {
|
||||
"content": "重点检查“不要解释”是否写得足够强，并判断是否会诱发模型追加说明性尾注",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"score": {
|
||||
"overall": 85,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalClarity",
|
||||
"label": "目标清晰度",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "instructionCompleteness",
|
||||
"label": "指令完备度",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "structuralExecutability",
|
||||
"label": "结构可执行性",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "ambiguityControl",
|
||||
"label": "歧义控制",
|
||||
"score": 80
|
||||
},
|
||||
{
|
||||
"key": "robustness",
|
||||
"label": "稳健性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"将'不要解释'改为更强烈的表述，例如'禁止添加任何说明性文字或尾注'，以明确约束输出格式。"
|
||||
],
|
||||
"summary": "提示词整体设计良好，但'不要解释'的表达力度较弱，可能诱发模型附加说明性内容。",
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "不要解释。",
|
||||
"newText": "禁止添加任何说明性文字或尾注。",
|
||||
"instruction": "当前'不要解释'可能不足以阻止模型在输出后追加解释性内容。强化该指令为'禁止添加任何说明性文字或尾注'，以确保模型严格遵守输出要求。"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729077366,
|
||||
"duration": 8653
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,100 @@
|
||||
# basic-user-prompt-only
|
||||
|
||||
## Meta
|
||||
- Type: `prompt-only`
|
||||
- Model: `dashscope`
|
||||
- Duration: `8653ms`
|
||||
- Timestamp: `1773729077366`
|
||||
|
||||
## Score
|
||||
- Overall: `85`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalClarity` | 目标清晰度 | 90 |
|
||||
| `instructionCompleteness` | 指令完备度 | 85 |
|
||||
| `structuralExecutability` | 结构可执行性 | 90 |
|
||||
| `ambiguityControl` | 歧义控制 | 80 |
|
||||
| `robustness` | 稳健性 | 80 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 将'不要解释'改为更强烈的表述，例如'禁止添加任何说明性文字或尾注'，以明确约束输出格式。
|
||||
|
||||
## Patch Plan
|
||||
|
||||
### Patch 1
|
||||
- Op: `replace`
|
||||
- Instruction: 当前'不要解释'可能不足以阻止模型在输出后追加解释性内容。强化该指令为'禁止添加任何说明性文字或尾注'，以确保模型严格遵守输出要求。
|
||||
|
||||
#### Old Text
|
||||
|
||||
```text
|
||||
不要解释。
|
||||
```
|
||||
|
||||
#### New Text
|
||||
|
||||
```text
|
||||
禁止添加任何说明性文字或尾注。
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
||||
提示词整体设计良好，但'不要解释'的表达力度较弱，可能诱发模型附加说明性内容。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"score": {
|
||||
"overall": 85,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalClarity",
|
||||
"label": "目标清晰度",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "instructionCompleteness",
|
||||
"label": "指令完备度",
|
||||
"score": 85
|
||||
},
|
||||
{
|
||||
"key": "structuralExecutability",
|
||||
"label": "结构可执行性",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "ambiguityControl",
|
||||
"label": "歧义控制",
|
||||
"score": 80
|
||||
},
|
||||
{
|
||||
"key": "robustness",
|
||||
"label": "稳健性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"将'不要解释'改为更强烈的表述，例如'禁止添加任何说明性文字或尾注'，以明确约束输出格式。"
|
||||
],
|
||||
"summary": "提示词整体设计良好，但'不要解释'的表达力度较弱，可能诱发模型附加说明性内容。",
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "不要解释。",
|
||||
"newText": "禁止添加任何说明性文字或尾注。",
|
||||
"instruction": "当前'不要解释'可能不足以阻止模型在输出后追加解释性内容。强化该指令为'禁止添加任何说明性文字或尾注'，以确保模型严格遵守输出要求。"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729077366,
|
||||
"duration": 8653
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 85,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": 90 },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": 85 },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": 90 },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": 80 },
|
||||
{ "key": "robustness", "label": "稳健性", "score": 80 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"将'不要解释'改为更强烈的表述，例如'禁止添加任何说明性文字或尾注'，以明确约束输出格式。"
|
||||
],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "不要解释。",
|
||||
"newText": "禁止添加任何说明性文字或尾注。",
|
||||
"instruction": "当前'不要解释'可能不足以阻止模型在输出后追加解释性内容。强化该指令为'禁止添加任何说明性文字或尾注'，以确保模型严格遵守输出要求。"
|
||||
}
|
||||
],
|
||||
"summary": "提示词整体设计良好，但'不要解释'的表达力度较弱，可能诱发模型附加说明性内容。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 单结果执行评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑用户提示词提出可靠改进。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断这次执行快照是否暴露了当前工作区用户提示词在该问题上的真实缺陷。\n- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的结果复盘代替 Focus Brief。\n\n## Skills\n### Skill-1\n1. 联合分析执行提示词、测试用例输入与当前输出。\n2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。\n\n### Skill-2\n1. 尽量区分提示词问题与单次输出偶然性。\n2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。\n\n## Rules\n1. 执行提示词、测试输入和输出是本次评分的唯一证据。\n2. 不得使用执行快照之外的提示词内容来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. Focus Brief 是本次任务的最高优先级输入。\n5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取测试用例输入和执行快照。\n2. 判断这次输出是否完成任务、满足约束。\n3. 按执行导向维度打分。\n4. 解释这次快照反映出该执行提示词的哪些问题或优势。\n5. 输出可迁移回可编辑目标的方向性改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievement\n - outputQuality\n - constraintCompliance\n - promptEffectiveness\n- improvements：0-3 条，可复用建议。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievement\", \"label\": \"目标达成度\", \"score\": <0-100> },\n { \"key\": \"outputQuality\", \"label\": \"输出质量\", \"score\": <0-100> },\n { \"key\": \"constraintCompliance\", \"label\": \"约束符合度\", \"score\": <0-100> },\n { \"key\": \"promptEffectiveness\", \"label\": \"提示词引导有效性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 测试用例输入（测试内容)\n无额外测试输入，输出直接基于当前提示词生成。\n\n## 执行快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n### 执行提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n### 输出\n《秋思》\n\n霜叶摇灯夜色长，归雁无声过小窗。\n孤枕寒更人未寐，秋心一寸到潇湘。\n\n附：这首诗通过秋景表达了思念之情。\n\n### 推理\n主体已经写成诗，但结尾又补了一句说明性尾注。\n\n## Focus Brief\n优先判断“不要解释”是否真正生效，不要泛泛评价诗歌质量\n\n---\n\n请基于这一次执行快照做严格评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,124 @@
|
||||
# basic-user-result-focus
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 单结果执行评估专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑用户提示词提出可靠改进。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，判断这次执行快照是否暴露了当前工作区用户提示词在该问题上的真实缺陷。
|
||||
- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛而谈的结果复盘代替 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 联合分析执行提示词、测试用例输入与当前输出。
|
||||
2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。
|
||||
|
||||
### Skill-2
|
||||
1. 尽量区分提示词问题与单次输出偶然性。
|
||||
2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。
|
||||
|
||||
## Rules
|
||||
1. 执行提示词、测试输入和输出是本次评分的唯一证据。
|
||||
2. 不得使用执行快照之外的提示词内容来影响评分判断。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. Focus Brief 是本次任务的最高优先级输入。
|
||||
5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
|
||||
## Workflow
|
||||
1. 读取测试用例输入和执行快照。
|
||||
2. 判断这次输出是否完成任务、满足约束。
|
||||
3. 按执行导向维度打分。
|
||||
4. 解释这次快照反映出该执行提示词的哪些问题或优势。
|
||||
5. 输出可迁移回可编辑目标的方向性改进建议。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalAchievement
|
||||
- outputQuality
|
||||
- constraintCompliance
|
||||
- promptEffectiveness
|
||||
- improvements：0-3 条，可复用建议。
|
||||
- summary：一句短结论。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievement", "label": "目标达成度", "score": <0-100> },
|
||||
{ "key": "outputQuality", "label": "输出质量", "score": <0-100> },
|
||||
{ "key": "constraintCompliance", "label": "约束符合度", "score": <0-100> },
|
||||
{ "key": "promptEffectiveness", "label": "提示词引导有效性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为用户提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 测试用例输入（测试内容)
|
||||
无额外测试输入，输出直接基于当前提示词生成。
|
||||
|
||||
## 执行快照 B
|
||||
- 提示词来源：工作区
|
||||
- 模型：dashscope
|
||||
- 版本：工作区
|
||||
### 执行提示词
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
|
||||
### 输出
|
||||
《秋思》
|
||||
|
||||
霜叶摇灯夜色长，归雁无声过小窗。
|
||||
孤枕寒更人未寐，秋心一寸到潇湘。
|
||||
|
||||
附：这首诗通过秋景表达了思念之情。
|
||||
|
||||
### 推理
|
||||
主体已经写成诗，但结尾又补了一句说明性尾注。
|
||||
|
||||
## Focus Brief
|
||||
优先判断“不要解释”是否真正生效，不要泛泛评价诗歌质量
|
||||
|
||||
---
|
||||
|
||||
请基于这一次执行快照做严格评估，并且只返回合法 JSON。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 单结果执行评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑用户提示词提出可靠改进。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断这次执行快照是否暴露了当前工作区用户提示词在该问题上的真实缺陷。\n- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的结果复盘代替 Focus Brief。\n\n## Skills\n### Skill-1\n1. 联合分析执行提示词、测试用例输入与当前输出。\n2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。\n\n### Skill-2\n1. 尽量区分提示词问题与单次输出偶然性。\n2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。\n\n## Rules\n1. 执行提示词、测试输入和输出是本次评分的唯一证据。\n2. 不得使用执行快照之外的提示词内容来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. Focus Brief 是本次任务的最高优先级输入。\n5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取测试用例输入和执行快照。\n2. 判断这次输出是否完成任务、满足约束。\n3. 按执行导向维度打分。\n4. 解释这次快照反映出该执行提示词的哪些问题或优势。\n5. 输出可迁移回可编辑目标的方向性改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievement\n - outputQuality\n - constraintCompliance\n - promptEffectiveness\n- improvements：0-3 条，可复用建议。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievement\", \"label\": \"目标达成度\", \"score\": <0-100> },\n { \"key\": \"outputQuality\", \"label\": \"输出质量\", \"score\": <0-100> },\n { \"key\": \"constraintCompliance\", \"label\": \"约束符合度\", \"score\": <0-100> },\n { \"key\": \"promptEffectiveness\", \"label\": \"提示词引导有效性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 测试用例输入（测试内容)\n无额外测试输入，输出直接基于当前提示词生成。\n\n## 执行快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n### 执行提示词\n请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。\n\n### 输出\n《秋思》\n\n霜叶摇灯夜色长，归雁无声过小窗。\n孤枕寒更人未寐，秋心一寸到潇湘。\n\n附：这首诗通过秋景表达了思念之情。\n\n### 推理\n主体已经写成诗，但结尾又补了一句说明性尾注。\n\n## Focus Brief\n优先判断“不要解释”是否真正生效，不要泛泛评价诗歌质量\n\n---\n\n请基于这一次执行快照做严格评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
{
|
||||
"type": "result",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先判断“不要解释”是否真正生效，不要泛泛评价诗歌质量",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"referencePrompt": "写一首诗"
|
||||
},
|
||||
"testCase": {
|
||||
"id": "focus-result-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "无额外测试输入，输出直接基于当前提示词生成。"
|
||||
}
|
||||
},
|
||||
"snapshot": {
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "focus-result-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"output": "《秋思》\n\n霜叶摇灯夜色长，归雁无声过小窗。\n孤枕寒更人未寐，秋心一寸到潇湘。\n\n附：这首诗通过秋景表达了思念之情。",
|
||||
"reasoning": "主体已经写成诗，但结尾又补了一句说明性尾注。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,114 @@
|
||||
# basic-user-result-focus
|
||||
|
||||
## Meta
|
||||
- Type: `result`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/user`
|
||||
|
||||
## Focus Brief
|
||||
|
||||
优先判断“不要解释”是否真正生效，不要泛泛评价诗歌质量
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
### Reference Prompt
|
||||
|
||||
```text
|
||||
写一首诗
|
||||
```
|
||||
|
||||
## Test Case
|
||||
- Id: `focus-result-test-case`
|
||||
- Label: `测试内容`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
```text
|
||||
无额外测试输入，输出直接基于当前提示词生成。
|
||||
```
|
||||
|
||||
## Snapshot 1
|
||||
- Id: `b`
|
||||
- Label: `B`
|
||||
- Test Case Id: `focus-result-test-case`
|
||||
- Model: `dashscope`
|
||||
- Version: `工作区`
|
||||
- Prompt Source: `工作区`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
《秋思》
|
||||
|
||||
霜叶摇灯夜色长，归雁无声过小窗。
|
||||
孤枕寒更人未寐，秋心一寸到潇湘。
|
||||
|
||||
附：这首诗通过秋景表达了思念之情。
|
||||
```
|
||||
|
||||
### Reasoning
|
||||
|
||||
```text
|
||||
主体已经写成诗，但结尾又补了一句说明性尾注。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "result",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先判断“不要解释”是否真正生效，不要泛泛评价诗歌质量",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"referencePrompt": "写一首诗"
|
||||
},
|
||||
"testCase": {
|
||||
"id": "focus-result-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "无额外测试输入，输出直接基于当前提示词生成。"
|
||||
}
|
||||
},
|
||||
"snapshot": {
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "focus-result-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"output": "《秋思》\n\n霜叶摇灯夜色长，归雁无声过小窗。\n孤枕寒更人未寐，秋心一寸到潇湘。\n\n附：这首诗通过秋景表达了思念之情。",
|
||||
"reasoning": "主体已经写成诗，但结尾又补了一句说明性尾注。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
{
|
||||
"type": "result",
|
||||
"score": {
|
||||
"overall": 65,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievement",
|
||||
"label": "目标达成度",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "outputQuality",
|
||||
"label": "输出质量",
|
||||
"score": 80
|
||||
},
|
||||
{
|
||||
"key": "constraintCompliance",
|
||||
"label": "约束符合度",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "promptEffectiveness",
|
||||
"label": "提示词引导有效性",
|
||||
"score": 60
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确禁止任何形式的解释性文字，包括尾注、说明句等，并提供具体惩罚示例以增强约束力。"
|
||||
],
|
||||
"summary": "输出基本完成任务，但未严格遵守“不要解释”的要求，提示词需加强相关约束的清晰表达。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729101202,
|
||||
"duration": 7320
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,69 @@
|
||||
# basic-user-result-focus
|
||||
|
||||
## Meta
|
||||
- Type: `result`
|
||||
- Model: `dashscope`
|
||||
- Duration: `7320ms`
|
||||
- Timestamp: `1773729101202`
|
||||
|
||||
## Score
|
||||
- Overall: `65`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalAchievement` | 目标达成度 | 70 |
|
||||
| `outputQuality` | 输出质量 | 80 |
|
||||
| `constraintCompliance` | 约束符合度 | 50 |
|
||||
| `promptEffectiveness` | 提示词引导有效性 | 60 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 在提示词中明确禁止任何形式的解释性文字，包括尾注、说明句等，并提供具体惩罚示例以增强约束力。
|
||||
|
||||
## Summary
|
||||
|
||||
输出基本完成任务，但未严格遵守“不要解释”的要求，提示词需加强相关约束的清晰表达。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "result",
|
||||
"score": {
|
||||
"overall": 65,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievement",
|
||||
"label": "目标达成度",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "outputQuality",
|
||||
"label": "输出质量",
|
||||
"score": 80
|
||||
},
|
||||
{
|
||||
"key": "constraintCompliance",
|
||||
"label": "约束符合度",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "promptEffectiveness",
|
||||
"label": "提示词引导有效性",
|
||||
"score": 60
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确禁止任何形式的解释性文字，包括尾注、说明句等，并提供具体惩罚示例以增强约束力。"
|
||||
],
|
||||
"summary": "输出基本完成任务，但未严格遵守“不要解释”的要求，提示词需加强相关约束的清晰表达。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729101202,
|
||||
"duration": 7320
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 65,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievement", "label": "目标达成度", "score": 70 },
|
||||
{ "key": "outputQuality", "label": "输出质量", "score": 80 },
|
||||
{ "key": "constraintCompliance", "label": "约束符合度", "score": 50 },
|
||||
{ "key": "promptEffectiveness", "label": "提示词引导有效性", "score": 60 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"在提示词中明确禁止任何形式的解释性文字，包括尾注、说明句等，并提供具体惩罚示例以增强约束力。"
|
||||
],
|
||||
"summary": "输出基本完成任务，但未严格遵守“不要解释”的要求，提示词需加强相关约束的清晰表达。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 单结果执行评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑用户提示词提出可靠改进。\n\n## Goal\n- Outcome: 评估执行快照中该执行提示词本身的表现。\n- Done Criteria: 解释输入、执行提示词、输出之间的关系，并给出可执行改进建议。\n- Non-Goals: 不要把单次快照误判成跨多次执行的稳定结论。\n\n## Skills\n### Skill-1\n1. 联合分析执行提示词、测试用例输入与当前输出。\n2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。\n\n### Skill-2\n1. 尽量区分提示词问题与单次输出偶然性。\n2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。\n\n## Rules\n1. 执行提示词、测试输入和输出是本次评分的唯一证据。\n2. 不得使用执行快照之外的提示词内容来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. 如果快照里已经出现某条明确指令被违反，或出现明显的输出边界滑移，summary 必须直接点名它，且第一条 improvement 必须先处理它。\n5. 如果输出在请求的成品后又追加了解释、尾注、说明或元评论，应把它视为约束滑移，而不是忽略不计。\n6. 不要让内容质量掩盖明显的执行滑移；一旦出现可见的边界违例，constraintCompliance 必须被实质拉低，overall 也应受到影响。\n\n## Workflow\n1. 读取测试用例输入和执行快照。\n2. 判断这次输出是否完成任务、满足约束。\n3. 先识别当前最高优先级的“被违反指令”或“输出边界滑移”，如果已经存在，必须把它作为首要问题。\n4. 按执行导向维度打分。\n5. 解释这次快照反映出该执行提示词的哪些问题或优势。\n6. 输出可迁移回可编辑目标的方向性改进建议；若存在首要违例，第一条 improvement 必须先处理它。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievement\n - outputQuality\n - constraintCompliance\n - promptEffectiveness\n- improvements：0-3 条，可复用建议。\n- summary：一句短结论。\n- 如果快照里已经出现某条明确的“被违反指令”或“输出边界滑移”，summary 必须显式提到它，且第一条 improvement 必须优先修它。\n- 如果输出在主成品后追加了未被请求的解释、尾注、说明或元评论，constraintCompliance 不应再给高分。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievement\", \"label\": \"目标达成度\", \"score\": <0-100> },\n { \"key\": \"outputQuality\", \"label\": \"输出质量\", \"score\": <0-100> },\n { \"key\": \"constraintCompliance\", \"label\": \"约束符合度\", \"score\": <0-100> },\n { \"key\": \"promptEffectiveness\", \"label\": \"提示词引导有效性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 测试用例输入（测试内容)\n无额外测试输入，输出直接基于当前提示词生成。\n\n## 执行快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n### 执行提示词\n写一首诗\n\n### 输出\n《秋思》\n\n风起云飞叶落时，孤灯照影夜迟迟。\n庭前菊老香犹在，檐下雁归声未移。\n\n旧梦依稀如雾散，新愁漫漫似烟滋。\n凭栏远望天涯路，一缕斜阳照客思。\n\n——愿这首诗能寄托你心中的思绪。\n\n---\n\n请基于这一次执行快照做严格评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,125 @@
|
||||
# basic-user-result
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 单结果执行评估专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑用户提示词提出可靠改进。
|
||||
|
||||
## Goal
|
||||
- Outcome: 评估执行快照中该执行提示词本身的表现。
|
||||
- Done Criteria: 解释输入、执行提示词、输出之间的关系，并给出可执行改进建议。
|
||||
- Non-Goals: 不要把单次快照误判成跨多次执行的稳定结论。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 联合分析执行提示词、测试用例输入与当前输出。
|
||||
2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。
|
||||
|
||||
### Skill-2
|
||||
1. 尽量区分提示词问题与单次输出偶然性。
|
||||
2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。
|
||||
|
||||
## Rules
|
||||
1. 执行提示词、测试输入和输出是本次评分的唯一证据。
|
||||
2. 不得使用执行快照之外的提示词内容来影响评分判断。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. 如果快照里已经出现某条明确指令被违反，或出现明显的输出边界滑移，summary 必须直接点名它，且第一条 improvement 必须先处理它。
|
||||
5. 如果输出在请求的成品后又追加了解释、尾注、说明或元评论，应把它视为约束滑移，而不是忽略不计。
|
||||
6. 不要让内容质量掩盖明显的执行滑移；一旦出现可见的边界违例，constraintCompliance 必须被实质拉低，overall 也应受到影响。
|
||||
|
||||
## Workflow
|
||||
1. 读取测试用例输入和执行快照。
|
||||
2. 判断这次输出是否完成任务、满足约束。
|
||||
3. 先识别当前最高优先级的“被违反指令”或“输出边界滑移”，如果已经存在，必须把它作为首要问题。
|
||||
4. 按执行导向维度打分。
|
||||
5. 解释这次快照反映出该执行提示词的哪些问题或优势。
|
||||
6. 输出可迁移回可编辑目标的方向性改进建议；若存在首要违例，第一条 improvement 必须先处理它。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalAchievement
|
||||
- outputQuality
|
||||
- constraintCompliance
|
||||
- promptEffectiveness
|
||||
- improvements：0-3 条，可复用建议。
|
||||
- summary：一句短结论。
|
||||
- 如果快照里已经出现某条明确的“被违反指令”或“输出边界滑移”，summary 必须显式提到它，且第一条 improvement 必须优先修它。
|
||||
- 如果输出在主成品后追加了未被请求的解释、尾注、说明或元评论，constraintCompliance 不应再给高分。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievement", "label": "目标达成度", "score": <0-100> },
|
||||
{ "key": "outputQuality", "label": "输出质量", "score": <0-100> },
|
||||
{ "key": "constraintCompliance", "label": "约束符合度", "score": <0-100> },
|
||||
{ "key": "promptEffectiveness", "label": "提示词引导有效性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为用户提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 测试用例输入（测试内容)
|
||||
无额外测试输入，输出直接基于当前提示词生成。
|
||||
|
||||
## 执行快照 A
|
||||
- 提示词来源：原始
|
||||
- 模型：siliconflow
|
||||
- 版本：原始
|
||||
### 执行提示词
|
||||
写一首诗
|
||||
|
||||
### 输出
|
||||
《秋思》
|
||||
|
||||
风起云飞叶落时，孤灯照影夜迟迟。
|
||||
庭前菊老香犹在，檐下雁归声未移。
|
||||
|
||||
旧梦依稀如雾散，新愁漫漫似烟滋。
|
||||
凭栏远望天涯路，一缕斜阳照客思。
|
||||
|
||||
——愿这首诗能寄托你心中的思绪。
|
||||
|
||||
---
|
||||
|
||||
请基于这一次执行快照做严格评估，并且只返回合法 JSON。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 单结果执行评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于一次执行快照，评估该次执行本身，并判断它是否支持对可编辑用户提示词提出可靠改进。\n\n## Goal\n- Outcome: 评估执行快照中该执行提示词本身的表现。\n- Done Criteria: 解释输入、执行提示词、输出之间的关系，并给出可执行改进建议。\n- Non-Goals: 不要把单次快照误判成跨多次执行的稳定结论。\n\n## Skills\n### Skill-1\n1. 联合分析执行提示词、测试用例输入与当前输出。\n2. 判断执行快照中的提示词是否提供了足够清晰的引导与约束。\n\n### Skill-2\n1. 尽量区分提示词问题与单次输出偶然性。\n2. 只输出能够稳定迁移回可编辑目标的方向性改进建议。\n\n## Rules\n1. 执行提示词、测试输入和输出是本次评分的唯一证据。\n2. 不得使用执行快照之外的提示词内容来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. 如果快照里已经出现某条明确指令被违反，或出现明显的输出边界滑移，summary 必须直接点名它，且第一条 improvement 必须先处理它。\n5. 如果输出在请求的成品后又追加了解释、尾注、说明或元评论，应把它视为约束滑移，而不是忽略不计。\n6. 不要让内容质量掩盖明显的执行滑移；一旦出现可见的边界违例，constraintCompliance 必须被实质拉低，overall 也应受到影响。\n\n## Workflow\n1. 读取测试用例输入和执行快照。\n2. 判断这次输出是否完成任务、满足约束。\n3. 先识别当前最高优先级的“被违反指令”或“输出边界滑移”，如果已经存在，必须把它作为首要问题。\n4. 按执行导向维度打分。\n5. 解释这次快照反映出该执行提示词的哪些问题或优势。\n6. 输出可迁移回可编辑目标的方向性改进建议；若存在首要违例，第一条 improvement 必须先处理它。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievement\n - outputQuality\n - constraintCompliance\n - promptEffectiveness\n- improvements：0-3 条，可复用建议。\n- summary：一句短结论。\n- 如果快照里已经出现某条明确的“被违反指令”或“输出边界滑移”，summary 必须显式提到它，且第一条 improvement 必须优先修它。\n- 如果输出在主成品后追加了未被请求的解释、尾注、说明或元评论，constraintCompliance 不应再给高分。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievement\", \"label\": \"目标达成度\", \"score\": <0-100> },\n { \"key\": \"outputQuality\", \"label\": \"输出质量\", \"score\": <0-100> },\n { \"key\": \"constraintCompliance\", \"label\": \"约束符合度\", \"score\": <0-100> },\n { \"key\": \"promptEffectiveness\", \"label\": \"提示词引导有效性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为用户提示词结果评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 测试用例输入（测试内容)\n无额外测试输入，输出直接基于当前提示词生成。\n\n## 执行快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n### 执行提示词\n写一首诗\n\n### 输出\n《秋思》\n\n风起云飞叶落时，孤灯照影夜迟迟。\n庭前菊老香犹在，檐下雁归声未移。\n\n旧梦依稀如雾散，新愁漫漫似烟滋。\n凭栏远望天涯路，一缕斜阳照客思。\n\n——愿这首诗能寄托你心中的思绪。\n\n---\n\n请基于这一次执行快照做严格评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
{
|
||||
"type": "result",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"referencePrompt": "写一首诗"
|
||||
},
|
||||
"testCase": {
|
||||
"id": "a-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "无额外测试输入，输出直接基于当前提示词生成。"
|
||||
}
|
||||
},
|
||||
"snapshot": {
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "a-test-case",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "写一首诗",
|
||||
"output": "《秋思》\n\n风起云飞叶落时，孤灯照影夜迟迟。\n庭前菊老香犹在，檐下雁归声未移。\n\n旧梦依稀如雾散，新愁漫漫似烟滋。\n凭栏远望天涯路，一缕斜阳照客思。\n\n——愿这首诗能寄托你心中的思绪。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,101 @@
|
||||
# basic-user-result
|
||||
|
||||
## Meta
|
||||
- Type: `result`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `basic/user`
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。
|
||||
```
|
||||
|
||||
### Reference Prompt
|
||||
|
||||
```text
|
||||
写一首诗
|
||||
```
|
||||
|
||||
## Test Case
|
||||
- Id: `a-test-case`
|
||||
- Label: `测试内容`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `测试内容`
|
||||
- Kind: `text`
|
||||
|
||||
```text
|
||||
无额外测试输入，输出直接基于当前提示词生成。
|
||||
```
|
||||
|
||||
## Snapshot 1
|
||||
- Id: `a`
|
||||
- Label: `A`
|
||||
- Test Case Id: `a-test-case`
|
||||
- Model: `siliconflow`
|
||||
- Version: `原始`
|
||||
- Prompt Source: `原始`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
写一首诗
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
《秋思》
|
||||
|
||||
风起云飞叶落时，孤灯照影夜迟迟。
|
||||
庭前菊老香犹在，檐下雁归声未移。
|
||||
|
||||
旧梦依稀如雾散，新愁漫漫似烟滋。
|
||||
凭栏远望天涯路，一缕斜阳照客思。
|
||||
|
||||
——愿这首诗能寄托你心中的思绪。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "result",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "basic",
|
||||
"subMode": "user"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "请写一首关于秋日思念的七言律诗。具体要求：1. 八句四联，押平声韵。2. 通过秋景间接表达思念。3. 语言凝练含蓄，不要解释。",
|
||||
"referencePrompt": "写一首诗"
|
||||
},
|
||||
"testCase": {
|
||||
"id": "a-test-case",
|
||||
"label": "测试内容",
|
||||
"input": {
|
||||
"kind": "text",
|
||||
"label": "测试内容",
|
||||
"content": "无额外测试输入，输出直接基于当前提示词生成。"
|
||||
}
|
||||
},
|
||||
"snapshot": {
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "a-test-case",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "写一首诗",
|
||||
"output": "《秋思》\n\n风起云飞叶落时，孤灯照影夜迟迟。\n庭前菊老香犹在，檐下雁归声未移。\n\n旧梦依稀如雾散，新愁漫漫似烟滋。\n凭栏远望天涯路，一缕斜阳照客思。\n\n——愿这首诗能寄托你心中的思绪。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
{
|
||||
"type": "result",
|
||||
"score": {
|
||||
"overall": 70,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievement",
|
||||
"label": "目标达成度",
|
||||
"score": 80
|
||||
},
|
||||
{
|
||||
"key": "outputQuality",
|
||||
"label": "输出质量",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "constraintCompliance",
|
||||
"label": "约束符合度",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "promptEffectiveness",
|
||||
"label": "提示词引导有效性",
|
||||
"score": 60
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"当前执行提示词“写一首诗”过于宽泛，未对诗歌风格、主题或格式做出明确约束，导致模型可能自由发挥，无法保证输出一致性。建议补充如‘五言绝句’或‘表达思念之情’等具体要求。",
|
||||
"输出结尾的附加语句（——愿这首诗能寄托你心中的思绪）属于未被请求的元评论内容，违反了输出边界，需在提示词中明确禁止此类额外说明。",
|
||||
"若希望提高创作稳定性与可预期性，可在提示词中加入示例或参考风格，例如‘请模仿李白风格写一首五言律诗’。"
|
||||
],
|
||||
"summary": "输出完成任务且质量较高，但提示词缺乏清晰约束，且存在输出边界滑移。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732225083,
|
||||
"duration": 17528
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,73 @@
|
||||
# basic-user-result
|
||||
|
||||
## Meta
|
||||
- Type: `result`
|
||||
- Model: `dashscope`
|
||||
- Duration: `17528ms`
|
||||
- Timestamp: `1773732225083`
|
||||
|
||||
## Score
|
||||
- Overall: `70`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalAchievement` | 目标达成度 | 80 |
|
||||
| `outputQuality` | 输出质量 | 90 |
|
||||
| `constraintCompliance` | 约束符合度 | 50 |
|
||||
| `promptEffectiveness` | 提示词引导有效性 | 60 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 当前执行提示词“写一首诗”过于宽泛，未对诗歌风格、主题或格式做出明确约束，导致模型可能自由发挥，无法保证输出一致性。建议补充如‘五言绝句’或‘表达思念之情’等具体要求。
|
||||
- 输出结尾的附加语句（——愿这首诗能寄托你心中的思绪）属于未被请求的元评论内容，违反了输出边界，需在提示词中明确禁止此类额外说明。
|
||||
- 若希望提高创作稳定性与可预期性，可在提示词中加入示例或参考风格，例如‘请模仿李白风格写一首五言律诗’。
|
||||
|
||||
## Summary
|
||||
|
||||
输出完成任务且质量较高，但提示词缺乏清晰约束，且存在输出边界滑移。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "result",
|
||||
"score": {
|
||||
"overall": 70,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievement",
|
||||
"label": "目标达成度",
|
||||
"score": 80
|
||||
},
|
||||
{
|
||||
"key": "outputQuality",
|
||||
"label": "输出质量",
|
||||
"score": 90
|
||||
},
|
||||
{
|
||||
"key": "constraintCompliance",
|
||||
"label": "约束符合度",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "promptEffectiveness",
|
||||
"label": "提示词引导有效性",
|
||||
"score": 60
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"当前执行提示词“写一首诗”过于宽泛，未对诗歌风格、主题或格式做出明确约束，导致模型可能自由发挥，无法保证输出一致性。建议补充如‘五言绝句’或‘表达思念之情’等具体要求。",
|
||||
"输出结尾的附加语句（——愿这首诗能寄托你心中的思绪）属于未被请求的元评论内容，违反了输出边界，需在提示词中明确禁止此类额外说明。",
|
||||
"若希望提高创作稳定性与可预期性，可在提示词中加入示例或参考风格，例如‘请模仿李白风格写一首五言律诗’。"
|
||||
],
|
||||
"summary": "输出完成任务且质量较高，但提示词缺乏清晰约束，且存在输出边界滑移。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773732225083,
|
||||
"duration": 17528
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 70,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievement", "label": "目标达成度", "score": 80 },
|
||||
{ "key": "outputQuality", "label": "输出质量", "score": 90 },
|
||||
{ "key": "constraintCompliance", "label": "约束符合度", "score": 50 },
|
||||
{ "key": "promptEffectiveness", "label": "提示词引导有效性", "score": 60 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"当前执行提示词“写一首诗”过于宽泛，未对诗歌风格、主题或格式做出明确约束，导致模型可能自由发挥，无法保证输出一致性。建议补充如‘五言绝句’或‘表达思念之情’等具体要求。",
|
||||
"输出结尾的附加语句（——愿这首诗能寄托你心中的思绪）属于未被请求的元评论内容，违反了输出边界，需在提示词中明确禁止此类额外说明。",
|
||||
"若希望提高创作稳定性与可预期性，可在提示词中加入示例或参考风格，例如‘请模仿李白风格写一首五言律诗’。"
|
||||
],
|
||||
"summary": "输出完成任务且质量较高，但提示词缺乏清晰约束，且存在输出边界滑移。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区上下文消息提示词应如何改进。\n- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. Focus Brief 是本次任务的最高优先级输入。\n5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 判断哪些规律可以安全提炼为可复用结论。\n5. 按对比导向维度打分。\n6. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为上下文消息对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（1）\n### 测试用例 Conversation Snapshot\n#### 输入（Conversation Snapshot)\n目标消息已用“【当前执行提示词见下方快照】”标记，实际内容见下方执行提示词。\nsystem: 【当前执行提示词见下方快照】\nuser: 我想做一个给团队用的笔记系统。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n作为 system 消息，给出建议\n\n#### 输出\n建议你直接选 Notion。\n\n#### 推理\n没有任何澄清问题。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。\n\n#### 输出\n你更关注多人实时协作、权限控制，还是知识沉淀与搜索？\n\n#### 推理\n先澄清了需求，没有直接给方案。\n\n## Focus Brief\n优先判断 system 消息是否真正促使 assistant 先澄清\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,140 @@
|
||||
# pro-multi-compare
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 多快照对比评估专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区上下文消息提示词应如何改进。
|
||||
- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。
|
||||
2. 判断哪些证据是可复用规律，哪些只是单次快照现象。
|
||||
|
||||
### Skill-2
|
||||
1. 识别“同提示词跨模型”差异场景。
|
||||
2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。
|
||||
3. 把快照差异收敛成可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Rules
|
||||
1. 各快照与公共测试输入是本次评分的唯一证据。
|
||||
2. 不得使用快照之外的提示词文本来影响评分判断。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. Focus Brief 是本次任务的最高优先级输入。
|
||||
5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
|
||||
## Workflow
|
||||
1. 读取公共测试用例和全部执行快照。
|
||||
2. 识别多快照中的强模式、弱模式与重复失败模式。
|
||||
3. 判断哪些规律可以安全提炼为可复用结论。
|
||||
5. 按对比导向维度打分。
|
||||
6. 输出可迁移回可编辑目标的改进建议。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalAchievementRobustness
|
||||
- outputQualityCeiling
|
||||
- promptPatternQuality
|
||||
- crossSnapshotRobustness
|
||||
- workspaceTransferability
|
||||
- improvements：0-3 条，可复用洞察。
|
||||
- summary：一句短结论。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": <0-100> },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": <0-100> },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": <0-100> },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": <0-100> },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为上下文消息对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 公共测试用例（1）
|
||||
### 测试用例 Conversation Snapshot
|
||||
#### 输入（Conversation Snapshot)
|
||||
目标消息已用“【当前执行提示词见下方快照】”标记，实际内容见下方执行提示词。
|
||||
system: 【当前执行提示词见下方快照】
|
||||
user: 我想做一个给团队用的笔记系统。
|
||||
|
||||
## 执行快照（2）
|
||||
### 快照 A
|
||||
- 提示词来源：原始
|
||||
- 模型：siliconflow
|
||||
- 版本：原始
|
||||
#### 执行提示词
|
||||
作为 system 消息，给出建议
|
||||
|
||||
#### 输出
|
||||
建议你直接选 Notion。
|
||||
|
||||
#### 推理
|
||||
没有任何澄清问题。
|
||||
|
||||
### 快照 B
|
||||
- 提示词来源：工作区
|
||||
- 模型：dashscope
|
||||
- 版本：工作区
|
||||
#### 执行提示词
|
||||
作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。
|
||||
|
||||
#### 输出
|
||||
你更关注多人实时协作、权限控制，还是知识沉淀与搜索？
|
||||
|
||||
#### 推理
|
||||
先澄清了需求，没有直接给方案。
|
||||
|
||||
## Focus Brief
|
||||
优先判断 system 消息是否真正促使 assistant 先澄清
|
||||
|
||||
---
|
||||
|
||||
请基于这些快照做对比评估，并且只返回合法 JSON。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 多快照对比评估专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 基于多个执行快照做对比评估，并把结论收敛为有证据支撑的改进方向。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，对多个快照进行比较，并判断当前工作区上下文消息提示词应如何改进。\n- Done Criteria: summary、improvements 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛的对比总结替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 横向比较多个快照，识别稳定模式、失败模式和更优写法。\n2. 判断哪些证据是可复用规律，哪些只是单次快照现象。\n\n### Skill-2\n1. 识别“同提示词跨模型”差异场景。\n2. 解释差异更像提示词歧义、弱约束、缺少示例，还是模型能力边界。\n3. 把快照差异收敛成可迁移回可编辑目标的改进建议。\n\n## Rules\n1. 各快照与公共测试输入是本次评分的唯一证据。\n2. 不得使用快照之外的提示词文本来影响评分判断。\n3. 不得杜撰不存在的提示词片段。\n4. Focus Brief 是本次任务的最高优先级输入。\n5. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取公共测试用例和全部执行快照。\n2. 识别多快照中的强模式、弱模式与重复失败模式。\n3. 判断哪些规律可以安全提炼为可复用结论。\n5. 按对比导向维度打分。\n6. 输出可迁移回可编辑目标的改进建议。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalAchievementRobustness\n - outputQualityCeiling\n - promptPatternQuality\n - crossSnapshotRobustness\n - workspaceTransferability\n- improvements：0-3 条，可复用洞察。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalAchievementRobustness\", \"label\": \"目标达成稳定性\", \"score\": <0-100> },\n { \"key\": \"outputQualityCeiling\", \"label\": \"输出质量上限\", \"score\": <0-100> },\n { \"key\": \"promptPatternQuality\", \"label\": \"提示词模式质量\", \"score\": <0-100> },\n { \"key\": \"crossSnapshotRobustness\", \"label\": \"跨快照鲁棒性\", \"score\": <0-100> },\n { \"key\": \"workspaceTransferability\", \"label\": \"对工作区的可迁移性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为上下文消息对比评估专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 公共测试用例（1）\n### 测试用例 Conversation Snapshot\n#### 输入（Conversation Snapshot)\n目标消息已用“【当前执行提示词见下方快照】”标记，实际内容见下方执行提示词。\nsystem: 【当前执行提示词见下方快照】\nuser: 我想做一个给团队用的笔记系统。\n\n## 执行快照（2）\n### 快照 A\n- 提示词来源：原始\n- 模型：siliconflow\n- 版本：原始\n#### 执行提示词\n作为 system 消息，给出建议\n\n#### 输出\n建议你直接选 Notion。\n\n#### 推理\n没有任何澄清问题。\n\n### 快照 B\n- 提示词来源：工作区\n- 模型：dashscope\n- 版本：工作区\n#### 执行提示词\n作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。\n\n#### 输出\n你更关注多人实时协作、权限控制，还是知识沉淀与搜索？\n\n#### 推理\n先澄清了需求，没有直接给方案。\n\n## Focus Brief\n优先判断 system 消息是否真正促使 assistant 先澄清\n\n---\n\n请基于这些快照做对比评估，并且只返回合法 JSON。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "pro",
|
||||
"subMode": "multi"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先判断 system 消息是否真正促使 assistant 先澄清",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。",
|
||||
"referencePrompt": "作为 system 消息，给出建议"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-conversation-test-case",
|
||||
"label": "Conversation Snapshot",
|
||||
"input": {
|
||||
"kind": "conversation",
|
||||
"label": "Conversation Snapshot",
|
||||
"summary": "目标消息已用“【当前执行提示词见下方快照】”标记，实际内容见下方执行提示词。",
|
||||
"content": "system: 【当前执行提示词见下方快照】\nuser: 我想做一个给团队用的笔记系统。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-conversation-test-case",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "作为 system 消息，给出建议",
|
||||
"output": "建议你直接选 Notion。",
|
||||
"reasoning": "没有任何澄清问题。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-conversation-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。",
|
||||
"output": "你更关注多人实时协作、权限控制，还是知识沉淀与搜索？",
|
||||
"reasoning": "先澄清了需求，没有直接给方案。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,157 @@
|
||||
# pro-multi-compare
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `pro/multi`
|
||||
|
||||
## Focus Brief
|
||||
|
||||
优先判断 system 消息是否真正促使 assistant 先澄清
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。
|
||||
```
|
||||
|
||||
### Reference Prompt
|
||||
|
||||
```text
|
||||
作为 system 消息，给出建议
|
||||
```
|
||||
|
||||
## Test Case 1
|
||||
- Id: `shared-conversation-test-case`
|
||||
- Label: `Conversation Snapshot`
|
||||
|
||||
### Input
|
||||
|
||||
- Label: `Conversation Snapshot`
|
||||
- Kind: `conversation`
|
||||
|
||||
目标消息已用“【当前执行提示词见下方快照】”标记，实际内容见下方执行提示词。
|
||||
|
||||
```text
|
||||
system: 【当前执行提示词见下方快照】
|
||||
user: 我想做一个给团队用的笔记系统。
|
||||
```
|
||||
|
||||
## Snapshot 1
|
||||
- Id: `a`
|
||||
- Label: `A`
|
||||
- Test Case Id: `shared-conversation-test-case`
|
||||
- Model: `siliconflow`
|
||||
- Version: `原始`
|
||||
- Prompt Source: `原始`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
作为 system 消息，给出建议
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
建议你直接选 Notion。
|
||||
```
|
||||
|
||||
### Reasoning
|
||||
|
||||
```text
|
||||
没有任何澄清问题。
|
||||
```
|
||||
|
||||
## Snapshot 2
|
||||
- Id: `b`
|
||||
- Label: `B`
|
||||
- Test Case Id: `shared-conversation-test-case`
|
||||
- Model: `dashscope`
|
||||
- Version: `工作区`
|
||||
- Prompt Source: `工作区`
|
||||
|
||||
### Executed Prompt
|
||||
|
||||
```text
|
||||
作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
```text
|
||||
你更关注多人实时协作、权限控制，还是知识沉淀与搜索？
|
||||
```
|
||||
|
||||
### Reasoning
|
||||
|
||||
```text
|
||||
先澄清了需求，没有直接给方案。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "pro",
|
||||
"subMode": "multi"
|
||||
},
|
||||
"focus": {
|
||||
"content": "优先判断 system 消息是否真正促使 assistant 先澄清",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。",
|
||||
"referencePrompt": "作为 system 消息，给出建议"
|
||||
},
|
||||
"testCases": [
|
||||
{
|
||||
"id": "shared-conversation-test-case",
|
||||
"label": "Conversation Snapshot",
|
||||
"input": {
|
||||
"kind": "conversation",
|
||||
"label": "Conversation Snapshot",
|
||||
"summary": "目标消息已用“【当前执行提示词见下方快照】”标记，实际内容见下方执行提示词。",
|
||||
"content": "system: 【当前执行提示词见下方快照】\nuser: 我想做一个给团队用的笔记系统。"
|
||||
}
|
||||
}
|
||||
],
|
||||
"snapshots": [
|
||||
{
|
||||
"id": "a",
|
||||
"label": "A",
|
||||
"testCaseId": "shared-conversation-test-case",
|
||||
"promptRef": {
|
||||
"kind": "original",
|
||||
"label": "原始"
|
||||
},
|
||||
"promptText": "作为 system 消息，给出建议",
|
||||
"output": "建议你直接选 Notion。",
|
||||
"reasoning": "没有任何澄清问题。",
|
||||
"modelKey": "siliconflow",
|
||||
"versionLabel": "原始"
|
||||
},
|
||||
{
|
||||
"id": "b",
|
||||
"label": "B",
|
||||
"testCaseId": "shared-conversation-test-case",
|
||||
"promptRef": {
|
||||
"kind": "workspace",
|
||||
"label": "工作区"
|
||||
},
|
||||
"promptText": "作为 system 消息，要求 assistant 先澄清用户目标，再给出建议，且不要抢答。",
|
||||
"output": "你更关注多人实时协作、权限控制，还是知识沉淀与搜索？",
|
||||
"reasoning": "先澄清了需求，没有直接给方案。",
|
||||
"modelKey": "dashscope",
|
||||
"versionLabel": "工作区"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 60,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 40
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 30
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"明确要求 assistant 在提供建议前必须先澄清用户需求，避免直接给出方案。",
|
||||
"统一使用更结构化的引导语句（如‘请先确认以下几点’）来确保行为一致性。",
|
||||
"在提示词中加入具体问题示例，以帮助模型更好地理解如何逐步推进对话。"
|
||||
],
|
||||
"summary": "当前 system 消息未能稳定促使 assistant 先澄清用户目标，需加强约束与引导。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729237468,
|
||||
"duration": 10268
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,79 @@
|
||||
# pro-multi-compare
|
||||
|
||||
## Meta
|
||||
- Type: `compare`
|
||||
- Model: `dashscope`
|
||||
- Duration: `10268ms`
|
||||
- Timestamp: `1773729237468`
|
||||
|
||||
## Score
|
||||
- Overall: `60`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalAchievementRobustness` | 目标达成稳定性 | 40 |
|
||||
| `outputQualityCeiling` | 输出质量上限 | 70 |
|
||||
| `promptPatternQuality` | 提示词模式质量 | 50 |
|
||||
| `crossSnapshotRobustness` | 跨快照鲁棒性 | 30 |
|
||||
| `workspaceTransferability` | 对工作区的可迁移性 | 80 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 明确要求 assistant 在提供建议前必须先澄清用户需求，避免直接给出方案。
|
||||
- 统一使用更结构化的引导语句（如‘请先确认以下几点’）来确保行为一致性。
|
||||
- 在提示词中加入具体问题示例，以帮助模型更好地理解如何逐步推进对话。
|
||||
|
||||
## Summary
|
||||
|
||||
当前 system 消息未能稳定促使 assistant 先澄清用户目标，需加强约束与引导。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "compare",
|
||||
"score": {
|
||||
"overall": 60,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalAchievementRobustness",
|
||||
"label": "目标达成稳定性",
|
||||
"score": 40
|
||||
},
|
||||
{
|
||||
"key": "outputQualityCeiling",
|
||||
"label": "输出质量上限",
|
||||
"score": 70
|
||||
},
|
||||
{
|
||||
"key": "promptPatternQuality",
|
||||
"label": "提示词模式质量",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "crossSnapshotRobustness",
|
||||
"label": "跨快照鲁棒性",
|
||||
"score": 30
|
||||
},
|
||||
{
|
||||
"key": "workspaceTransferability",
|
||||
"label": "对工作区的可迁移性",
|
||||
"score": 80
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"明确要求 assistant 在提供建议前必须先澄清用户需求，避免直接给出方案。",
|
||||
"统一使用更结构化的引导语句（如‘请先确认以下几点’）来确保行为一致性。",
|
||||
"在提示词中加入具体问题示例，以帮助模型更好地理解如何逐步推进对话。"
|
||||
],
|
||||
"summary": "当前 system 消息未能稳定促使 assistant 先澄清用户目标，需加强约束与引导。",
|
||||
"patchPlan": [],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729237468,
|
||||
"duration": 10268
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 60,
|
||||
"dimensions": [
|
||||
{ "key": "goalAchievementRobustness", "label": "目标达成稳定性", "score": 40 },
|
||||
{ "key": "outputQualityCeiling", "label": "输出质量上限", "score": 70 },
|
||||
{ "key": "promptPatternQuality", "label": "提示词模式质量", "score": 50 },
|
||||
{ "key": "crossSnapshotRobustness", "label": "跨快照鲁棒性", "score": 30 },
|
||||
{ "key": "workspaceTransferability", "label": "对工作区的可迁移性", "score": 80 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"明确要求 assistant 在提供建议前必须先澄清用户需求，避免直接给出方案。",
|
||||
"统一使用更结构化的引导语句（如‘请先确认以下几点’）来确保行为一致性。",
|
||||
"在提示词中加入具体问题示例，以帮助模型更好地理解如何逐步推进对话。"
|
||||
],
|
||||
"summary": "当前 system 消息未能稳定促使 assistant 先澄清用户目标，需加强约束与引导。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词设计分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区上下文消息提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区上下文消息提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前上下文消息提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区上下文消息提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区上下文消息提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区上下文消息提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区上下文消息提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区上下文消息提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为上下文消息分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区上下文消息提示词\n你是一个诗人\n\n## 设计态上下文（Conversation Design Context）\n当前分析目标是 system 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。\n目标消息角色: system\n会话上下文:\n- system: 【当前工作区要优化的提示词】\n- user: 请你写一首关于{{主题}}的诗。\n\n## Focus Brief\n重点检查 system 消息是否足够明确角色定位，并能稳定约束后续 user 写诗任务。\n\n---\n\n请分析当前工作区上下文消息提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,125 @@
|
||||
# pro-multi-prompt-only-system-selected
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 提示词设计分析专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 在不依赖测试输出的前提下，评估当前工作区上下文消息提示词的设计质量。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区上下文消息提示词是否真正回应了该问题。
|
||||
- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。
|
||||
2. 判断当前上下文消息提示词在不同输入下是否更可能保持稳定。
|
||||
|
||||
### Skill-2
|
||||
1. 把观察结果严格映射回当前工作区上下文消息提示词。
|
||||
2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。
|
||||
|
||||
## Rules
|
||||
1. 当前工作区上下文消息提示词是唯一可修改目标。
|
||||
2. 如果无法可靠映射回当前工作区上下文消息提示词，patchPlan 必须返回 []。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. 本任务没有执行结果，不得评价输出质量。
|
||||
5. Focus Brief 是本次任务的最高优先级输入。
|
||||
6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
|
||||
## Workflow
|
||||
1. 读取当前工作区上下文消息提示词，并将其作为本次分析的主对象。
|
||||
2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。
|
||||
3. 按设计导向维度评分。
|
||||
4. 收敛问题与改进方向。
|
||||
5. 仅在存在精确落点时生成 patchPlan。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalClarity
|
||||
- instructionCompleteness
|
||||
- structuralExecutability
|
||||
- ambiguityControl
|
||||
- robustness
|
||||
- improvements：0-3 条，可复用的设计改进建议。
|
||||
- patchPlan：0-3 条，只允许修改当前工作区上下文消息提示词。
|
||||
- summary：一句短结论。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": <0-100> },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": <0-100> },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": <0-100> },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": <0-100> },
|
||||
{ "key": "robustness", "label": "稳健性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "<当前工作区中可精确匹配的片段>",
|
||||
"newText": "<修改后的内容>",
|
||||
"instruction": "<问题说明 + 修复方案>"
|
||||
}
|
||||
],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为上下文消息分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 当前工作区上下文消息提示词
|
||||
你是一个诗人
|
||||
|
||||
## 设计态上下文（Conversation Design Context）
|
||||
当前分析目标是 system 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。
|
||||
目标消息角色: system
|
||||
会话上下文:
|
||||
- system: 【当前工作区要优化的提示词】
|
||||
- user: 请你写一首关于{{主题}}的诗。
|
||||
|
||||
## Focus Brief
|
||||
重点检查 system 消息是否足够明确角色定位，并能稳定约束后续 user 写诗任务。
|
||||
|
||||
---
|
||||
|
||||
请分析当前工作区上下文消息提示词，并返回严格的 JSON 评估结果。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词设计分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区上下文消息提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区上下文消息提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前上下文消息提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区上下文消息提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区上下文消息提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区上下文消息提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区上下文消息提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区上下文消息提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为上下文消息分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区上下文消息提示词\n你是一个诗人\n\n## 设计态上下文（Conversation Design Context）\n当前分析目标是 system 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。\n目标消息角色: system\n会话上下文:\n- system: 【当前工作区要优化的提示词】\n- user: 请你写一首关于{{主题}}的诗。\n\n## Focus Brief\n重点检查 system 消息是否足够明确角色定位，并能稳定约束后续 user 写诗任务。\n\n---\n\n请分析当前工作区上下文消息提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "pro",
|
||||
"subMode": "multi"
|
||||
},
|
||||
"focus": {
|
||||
"content": "重点检查 system 消息是否足够明确角色定位，并能稳定约束后续 user 写诗任务。",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个诗人",
|
||||
"designContext": {
|
||||
"kind": "conversation",
|
||||
"label": "Conversation Design Context",
|
||||
"summary": "当前分析目标是 system 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。",
|
||||
"content": "目标消息角色: system\n会话上下文:\n- system: 【当前工作区要优化的提示词】\n- user: 请你写一首关于{{主题}}的诗。"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,60 @@
|
||||
# pro-multi-prompt-only-system-selected
|
||||
|
||||
## Meta
|
||||
- Type: `prompt-only`
|
||||
- Evaluation Model: `dashscope`
|
||||
- Mode: `pro/multi`
|
||||
|
||||
## Focus Brief
|
||||
|
||||
重点检查 system 消息是否足够明确角色定位，并能稳定约束后续 user 写诗任务。
|
||||
|
||||
## Editable Target
|
||||
|
||||
### Workspace Prompt
|
||||
|
||||
```text
|
||||
你是一个诗人
|
||||
```
|
||||
|
||||
### Design Context
|
||||
|
||||
- Label: `Conversation Design Context`
|
||||
- Kind: `conversation`
|
||||
|
||||
当前分析目标是 system 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。
|
||||
|
||||
```text
|
||||
目标消息角色: system
|
||||
会话上下文:
|
||||
- system: 【当前工作区要优化的提示词】
|
||||
- user: 请你写一首关于{{主题}}的诗。
|
||||
```
|
||||
|
||||
## Raw Request JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"evaluationModelKey": "dashscope",
|
||||
"mode": {
|
||||
"functionMode": "pro",
|
||||
"subMode": "multi"
|
||||
},
|
||||
"focus": {
|
||||
"content": "重点检查 system 消息是否足够明确角色定位，并能稳定约束后续 user 写诗任务。",
|
||||
"source": "user",
|
||||
"priority": "highest"
|
||||
},
|
||||
"target": {
|
||||
"workspacePrompt": "你是一个诗人",
|
||||
"designContext": {
|
||||
"kind": "conversation",
|
||||
"label": "Conversation Design Context",
|
||||
"summary": "当前分析目标是 system 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。",
|
||||
"content": "目标消息角色: system\n会话上下文:\n- system: 【当前工作区要优化的提示词】\n- user: 请你写一首关于{{主题}}的诗。"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"score": {
|
||||
"overall": 40,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalClarity",
|
||||
"label": "目标清晰度",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "instructionCompleteness",
|
||||
"label": "指令完备度",
|
||||
"score": 30
|
||||
},
|
||||
{
|
||||
"key": "structuralExecutability",
|
||||
"label": "结构可执行性",
|
||||
"score": 40
|
||||
},
|
||||
{
|
||||
"key": "ambiguityControl",
|
||||
"label": "歧义控制",
|
||||
"score": 20
|
||||
},
|
||||
{
|
||||
"key": "robustness",
|
||||
"label": "稳健性",
|
||||
"score": 60
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"增加角色行为规范，例如写作风格、情感倾向或格式要求，以明确诗人身份的输出边界。",
|
||||
"补充任务引导语句，使 system 消息能更主动地引导 user 输入中的主题生成高质量诗作。",
|
||||
"引入稳定性约束词（如“请根据用户提供的主题”），防止模型在不同输入下偏离写诗任务。"
|
||||
],
|
||||
"summary": "当前提示词缺乏对角色职责和任务引导的明确说明，需增强表达以确保写诗任务的稳定性。",
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "你是一个诗人",
|
||||
"newText": "你是一位专业的诗人，擅长根据用户提供的主题创作富有情感和意象的诗歌。",
|
||||
"instruction": "原提示词角色定位模糊，无法稳定引导写诗任务；新增描述强化专业性和任务引导性。"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729204349,
|
||||
"duration": 9498
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,104 @@
|
||||
# pro-multi-prompt-only-system-selected
|
||||
|
||||
## Meta
|
||||
- Type: `prompt-only`
|
||||
- Model: `dashscope`
|
||||
- Duration: `9498ms`
|
||||
- Timestamp: `1773729204349`
|
||||
|
||||
## Score
|
||||
- Overall: `40`
|
||||
|
||||
| Key | Label | Score |
|
||||
| --- | --- | --- |
|
||||
| `goalClarity` | 目标清晰度 | 50 |
|
||||
| `instructionCompleteness` | 指令完备度 | 30 |
|
||||
| `structuralExecutability` | 结构可执行性 | 40 |
|
||||
| `ambiguityControl` | 歧义控制 | 20 |
|
||||
| `robustness` | 稳健性 | 60 |
|
||||
|
||||
## Improvements
|
||||
|
||||
- 增加角色行为规范，例如写作风格、情感倾向或格式要求，以明确诗人身份的输出边界。
|
||||
- 补充任务引导语句，使 system 消息能更主动地引导 user 输入中的主题生成高质量诗作。
|
||||
- 引入稳定性约束词（如“请根据用户提供的主题”），防止模型在不同输入下偏离写诗任务。
|
||||
|
||||
## Patch Plan
|
||||
|
||||
### Patch 1
|
||||
- Op: `replace`
|
||||
- Instruction: 原提示词角色定位模糊，无法稳定引导写诗任务；新增描述强化专业性和任务引导性。
|
||||
|
||||
#### Old Text
|
||||
|
||||
```text
|
||||
你是一个诗人
|
||||
```
|
||||
|
||||
#### New Text
|
||||
|
||||
```text
|
||||
你是一位专业的诗人，擅长根据用户提供的主题创作富有情感和意象的诗歌。
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
||||
当前提示词缺乏对角色职责和任务引导的明确说明，需增强表达以确保写诗任务的稳定性。
|
||||
|
||||
## Raw Response JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "prompt-only",
|
||||
"score": {
|
||||
"overall": 40,
|
||||
"dimensions": [
|
||||
{
|
||||
"key": "goalClarity",
|
||||
"label": "目标清晰度",
|
||||
"score": 50
|
||||
},
|
||||
{
|
||||
"key": "instructionCompleteness",
|
||||
"label": "指令完备度",
|
||||
"score": 30
|
||||
},
|
||||
{
|
||||
"key": "structuralExecutability",
|
||||
"label": "结构可执行性",
|
||||
"score": 40
|
||||
},
|
||||
{
|
||||
"key": "ambiguityControl",
|
||||
"label": "歧义控制",
|
||||
"score": 20
|
||||
},
|
||||
{
|
||||
"key": "robustness",
|
||||
"label": "稳健性",
|
||||
"score": 60
|
||||
}
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"增加角色行为规范，例如写作风格、情感倾向或格式要求，以明确诗人身份的输出边界。",
|
||||
"补充任务引导语句，使 system 消息能更主动地引导 user 输入中的主题生成高质量诗作。",
|
||||
"引入稳定性约束词（如“请根据用户提供的主题”），防止模型在不同输入下偏离写诗任务。"
|
||||
],
|
||||
"summary": "当前提示词缺乏对角色职责和任务引导的明确说明，需增强表达以确保写诗任务的稳定性。",
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "你是一个诗人",
|
||||
"newText": "你是一位专业的诗人，擅长根据用户提供的主题创作富有情感和意象的诗歌。",
|
||||
"instruction": "原提示词角色定位模糊，无法稳定引导写诗任务；新增描述强化专业性和任务引导性。"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"model": "dashscope",
|
||||
"timestamp": 1773729204349,
|
||||
"duration": 9498
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": 40,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": 50 },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": 30 },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": 40 },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": 20 },
|
||||
{ "key": "robustness", "label": "稳健性", "score": 60 }
|
||||
]
|
||||
},
|
||||
"improvements": [
|
||||
"增加角色行为规范，例如写作风格、情感倾向或格式要求，以明确诗人身份的输出边界。",
|
||||
"补充任务引导语句，使 system 消息能更主动地引导 user 输入中的主题生成高质量诗作。",
|
||||
"引入稳定性约束词（如“请根据用户提供的主题”），防止模型在不同输入下偏离写诗任务。"
|
||||
],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "你是一个诗人",
|
||||
"newText": "你是一位专业的诗人，擅长根据用户提供的主题创作富有情感和意象的诗歌。",
|
||||
"instruction": "原提示词角色定位模糊，无法稳定引导写诗任务；新增描述强化专业性和任务引导性。"
|
||||
}
|
||||
],
|
||||
"summary": "当前提示词缺乏对角色职责和任务引导的明确说明，需增强表达以确保写诗任务的稳定性。"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词设计分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区上下文消息提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区上下文消息提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前上下文消息提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区上下文消息提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区上下文消息提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区上下文消息提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区上下文消息提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区上下文消息提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为上下文消息分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区上下文消息提示词\n请你写一首关于{{主题}}的诗。\n\n## 设计态上下文（Conversation Design Context）\n当前分析目标是 user 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。\n目标消息角色: user\n会话上下文:\n- system: 你是一个诗人\n- user: 【当前工作区要优化的提示词】\n\n## Focus Brief\n重点检查 user 消息是否足够明确任务目标，并保持变量占位的可执行性。\n\n---\n\n请分析当前工作区上下文消息提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,125 @@
|
||||
# pro-multi-prompt-only-user-selected
|
||||
|
||||
## Rendered Messages
|
||||
|
||||
### Message 1
|
||||
- Role: `system`
|
||||
|
||||
```text
|
||||
# Role: 提示词设计分析专家
|
||||
|
||||
## Profile
|
||||
- Author: Prompt Optimizer
|
||||
- Version: 5.0
|
||||
- Language: zh-CN
|
||||
- Description: 在不依赖测试输出的前提下，评估当前工作区上下文消息提示词的设计质量。
|
||||
|
||||
## Goal
|
||||
- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区上下文消息提示词是否真正回应了该问题。
|
||||
- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。
|
||||
- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。
|
||||
|
||||
## Skills
|
||||
### Skill-1
|
||||
1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。
|
||||
2. 判断当前上下文消息提示词在不同输入下是否更可能保持稳定。
|
||||
|
||||
### Skill-2
|
||||
1. 把观察结果严格映射回当前工作区上下文消息提示词。
|
||||
2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。
|
||||
|
||||
## Rules
|
||||
1. 当前工作区上下文消息提示词是唯一可修改目标。
|
||||
2. 如果无法可靠映射回当前工作区上下文消息提示词，patchPlan 必须返回 []。
|
||||
3. 不得杜撰不存在的提示词片段。
|
||||
4. 本任务没有执行结果，不得评价输出质量。
|
||||
5. Focus Brief 是本次任务的最高优先级输入。
|
||||
6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。
|
||||
|
||||
## Workflow
|
||||
1. 读取当前工作区上下文消息提示词，并将其作为本次分析的主对象。
|
||||
2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。
|
||||
3. 按设计导向维度评分。
|
||||
4. 收敛问题与改进方向。
|
||||
5. 仅在存在精确落点时生成 patchPlan。
|
||||
|
||||
## Output Contract
|
||||
- 只输出合法 JSON。
|
||||
- 评分维度固定为：
|
||||
- goalClarity
|
||||
- instructionCompleteness
|
||||
- structuralExecutability
|
||||
- ambiguityControl
|
||||
- robustness
|
||||
- improvements：0-3 条，可复用的设计改进建议。
|
||||
- patchPlan：0-3 条，只允许修改当前工作区上下文消息提示词。
|
||||
- summary：一句短结论。
|
||||
|
||||
```json
|
||||
{
|
||||
"score": {
|
||||
"overall": <0-100>,
|
||||
"dimensions": [
|
||||
{ "key": "goalClarity", "label": "目标清晰度", "score": <0-100> },
|
||||
{ "key": "instructionCompleteness", "label": "指令完备度", "score": <0-100> },
|
||||
{ "key": "structuralExecutability", "label": "结构可执行性", "score": <0-100> },
|
||||
{ "key": "ambiguityControl", "label": "歧义控制", "score": <0-100> },
|
||||
{ "key": "robustness", "label": "稳健性", "score": <0-100> }
|
||||
]
|
||||
},
|
||||
"improvements": ["<可复用改进建议>"],
|
||||
"patchPlan": [
|
||||
{
|
||||
"op": "replace",
|
||||
"oldText": "<当前工作区中可精确匹配的片段>",
|
||||
"newText": "<修改后的内容>",
|
||||
"instruction": "<问题说明 + 修复方案>"
|
||||
}
|
||||
],
|
||||
"summary": "<一句话结论>"
|
||||
}
|
||||
```
|
||||
|
||||
## Initialization
|
||||
作为上下文消息分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。
|
||||
```
|
||||
|
||||
### Message 2
|
||||
- Role: `user`
|
||||
|
||||
```text
|
||||
## 当前工作区上下文消息提示词
|
||||
请你写一首关于{{主题}}的诗。
|
||||
|
||||
## 设计态上下文（Conversation Design Context）
|
||||
当前分析目标是 user 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。
|
||||
目标消息角色: user
|
||||
会话上下文:
|
||||
- system: 你是一个诗人
|
||||
- user: 【当前工作区要优化的提示词】
|
||||
|
||||
## Focus Brief
|
||||
重点检查 user 消息是否足够明确任务目标，并保持变量占位的可执行性。
|
||||
|
||||
---
|
||||
|
||||
请分析当前工作区上下文消息提示词，并返回严格的 JSON 评估结果。
|
||||
```
|
||||
|
||||
## Raw Messages JSON
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"role": "system",
|
||||
"content": "# Role: 提示词设计分析专家\n\n## Profile\n- Author: Prompt Optimizer\n- Version: 5.0\n- Language: zh-CN\n- Description: 在不依赖测试输出的前提下，评估当前工作区上下文消息提示词的设计质量。\n\n## Goal\n- Outcome: 优先围绕用户提供的 Focus Brief，判断当前工作区上下文消息提示词是否真正回应了该问题。\n- Done Criteria: summary、improvements、patchPlan 都必须直接回应 Focus Brief。\n- Non-Goals: 不要用泛泛而谈的全面分析替代 Focus Brief。\n\n## Skills\n### Skill-1\n1. 评估目标清晰度、约束完整性、结构可执行性与歧义控制。\n2. 判断当前上下文消息提示词在不同输入下是否更可能保持稳定。\n\n### Skill-2\n1. 把观察结果严格映射回当前工作区上下文消息提示词。\n2. 只有在 oldText 能与当前工作区精确匹配时，才生成 patchPlan。\n\n## Rules\n1. 当前工作区上下文消息提示词是唯一可修改目标。\n2. 如果无法可靠映射回当前工作区上下文消息提示词，patchPlan 必须返回 []。\n3. 不得杜撰不存在的提示词片段。\n4. 本任务没有执行结果，不得评价输出质量。\n5. Focus Brief 是本次任务的最高优先级输入。\n6. 如果当前证据不足以支撑 Focus Brief 指向的问题，必须明确说明。\n\n## Workflow\n1. 读取当前工作区上下文消息提示词，并将其作为本次分析的主对象。\n2. 仅在存在且确有帮助时，把设计态上下文作为辅助信息使用。\n3. 按设计导向维度评分。\n4. 收敛问题与改进方向。\n5. 仅在存在精确落点时生成 patchPlan。\n\n## Output Contract\n- 只输出合法 JSON。\n- 评分维度固定为：\n - goalClarity\n - instructionCompleteness\n - structuralExecutability\n - ambiguityControl\n - robustness\n- improvements：0-3 条，可复用的设计改进建议。\n- patchPlan：0-3 条，只允许修改当前工作区上下文消息提示词。\n- summary：一句短结论。\n\n```json\n{\n \"score\": {\n \"overall\": <0-100>,\n \"dimensions\": [\n { \"key\": \"goalClarity\", \"label\": \"目标清晰度\", \"score\": <0-100> },\n { \"key\": \"instructionCompleteness\", \"label\": \"指令完备度\", \"score\": <0-100> },\n { \"key\": \"structuralExecutability\", \"label\": \"结构可执行性\", \"score\": <0-100> },\n { \"key\": \"ambiguityControl\", \"label\": \"歧义控制\", \"score\": <0-100> },\n { \"key\": \"robustness\", \"label\": \"稳健性\", \"score\": <0-100> }\n ]\n },\n \"improvements\": [\"<可复用改进建议>\"],\n \"patchPlan\": [\n {\n \"op\": \"replace\",\n \"oldText\": \"<当前工作区中可精确匹配的片段>\",\n \"newText\": \"<修改后的内容>\",\n \"instruction\": \"<问题说明 + 修复方案>\"\n }\n ],\n \"summary\": \"<一句话结论>\"\n}\n```\n\n## Initialization\n作为上下文消息分析专家，你必须遵守 Rules，按 Workflow 执行，并且只输出合法 JSON。"
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"role": "user",
|
||||
"content": "## 当前工作区上下文消息提示词\n请你写一首关于{{主题}}的诗。\n\n## 设计态上下文（Conversation Design Context）\n当前分析目标是 user 消息；会话中的该位置已用“【当前工作区要优化的提示词】”标记。\n目标消息角色: user\n会话上下文:\n- system: 你是一个诗人\n- user: 【当前工作区要优化的提示词】\n\n## Focus Brief\n重点检查 user 消息是否足够明确任务目标，并保持变量占位的可执行性。\n\n---\n\n请分析当前工作区上下文消息提示词，并返回严格的 JSON 评估结果。"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user