docs/workspace/compare-evaluation-analysis/history/input-minimization-spec.md
本文档用于收敛一个核心约束： 在一次 LLM 请求中，同一份长内容应尽量只出现一次。
这里的“长内容”包括但不限于：
- 原始提示词
- 当前工作区提示词
- 历史版本提示词
- 变量值
- 测试文本
- 会话上下文
- 大段 JSON / 结构化上下文
当前分析 / 评估链路已经完成语义重构，但还存在一个独立问题：
因此需要补上一条更强的设计原则：
prompt-only / prompt-iterateresultcomparebasic/user 与 basic/system默认只发送：
workspacePromptfocus，如果有默认不发送：
referencePrompt原因：
pro/variable默认只发送：
workspacePromptfocus，如果有按需可发送的最小设计态上下文：
默认不发送：
建议格式：
## 当前工作区变量提示词
...
## 变量结构说明
- 风格: 诗歌风格
- 主题: 诗歌主题
不建议格式：
## 变量上下文
风格=中文古典
主题=一大段很长的业务输入
原因：
当前已落地验证：
basic-user / basic-system 已完成最小输入收敛pro/variable prompt-only 已完成最小结构上下文收敛real-api-samples/pro-variable-prompt-onlyreal-api-samples/pro-variable-prompt-only-currentreal-api-samples/pro-variable-prompt-only-minimalpro/multi默认只发送：
focus，如果有按需可发送的最小设计态上下文：
默认不发送：
原因：
推荐格式：
当选中 system 消息时：
## 当前工作区上下文消息提示词
你是一个诗人
## 会话上下文
目标消息角色: system
- system: 【当前工作区要优化的提示词】
- user: 请你写一首关于{{主题}}的诗。
当选中 user 消息时：
## 当前工作区上下文消息提示词
请你写一首关于{{主题}}的诗。
## 会话上下文
目标消息角色: user
- system: 你是一个诗人
- user: 【当前工作区要优化的提示词】
不推荐格式：
## 会话摘要
这是一个诗歌创作场景，system 负责定义角色，user 负责提出写诗需求...
也不推荐：
## 完整会话 JSON
{
"targetMessage": ...,
"conversationMessages": [...]
}
原因：
pro/multi 左侧分析仍然是设计分析，不是执行复盘真实对照补充：
real-api-samples/pro-multi-prompt-only-current
workspacePrompt / referencePrompt / targetMessage.content / conversationMessagesreal-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 左侧分析现在默认不再发送 referencePromptdesignContext 已收敛为：
real-api-samples/pro-multi-prompt-onlyreal-api-samples/pro-multi-prompt-only-system-selectedreal-api-samples/pro-multi-prompt-only-user-selectedimage/*当前仍按左侧分析处理，建议遵守同样规则：
右侧单结果评估只发送这一次执行所必需的证据：
testCase.inputsnapshot.promptTextsnapshot.outputsnapshot.executionInput，仅当其不同于公共测试输入且确有必要focus，如果有默认不发送：
target.workspacePrompt 全文target.referencePrompt 全文basic/user / basic/system推荐结构：
## 测试用例输入
...
## 执行快照 A
### 执行提示词
...
### 输出
...
不应额外再出现：
## 当前工作区提示词
...
## 参考提示词
...
原因：
pro/variable右侧 result 时，变量值是执行证据的一部分，因此可以发送，但应只出现一次。
推荐：
testCase.inputsnapshot.executionInput不推荐：
pro/multi右侧 result 时，会话片段也是执行证据的一部分，因此可以发送，但必须控制长度。
推荐：
testCase.inputsnapshot.executionInput不推荐：
testCase.input 和 executionInput凡是多个快照共享的信息，应上提到 testCases[]，只出现一次。
包括：
每个 snapshot 只保留自己的：
promptTextoutputreasoning，如果有modelKeyversionLabelexecutionInput，仅当该输入是该快照独有信息workspacePrompt 全文referencePrompt 全文basic/user / basic/system推荐结构：
## 公共测试用例（1）
### 测试用例 测试内容
#### 输入
...
## 执行快照（2）
### 快照 A
#### 执行提示词
...
#### 输出
...
### 快照 B
#### 执行提示词
...
#### 输出
...
不应再出现：
## 当前工作区提示词
...
因为 compare 的评分证据应是多快照本身，而不是工作区全文。
pro/variable推荐：
不推荐：
因为变量和提示词都可能很长，重复一次成本就会快速放大。
pro/multi推荐：
executionInput不推荐：
referencePrompt 的最终策略为避免行为复杂化，建议先采用简单稳定规则：
referencePromptreferencePromptreferencePrompt如果未来确实需要保留“原始意图”的辅助价值，建议不要做“长度阈值判断”这种隐式策略，而是显式设计成另一种任务模式，例如：
在当前阶段，不建议：
原因：
designContext 的最终策略designContext 只应保留真正服务于“设计语义理解”的内容。
允许：
不允许：
workspacePromptfocus 就加 focusreferencePromptdesignContextdesignContext，只允许极短摘要，且不得包含执行态证据testCase.inputsnapshot.promptTextsnapshot.outputsnapshot.executionInputfocus 就加 focusworkspacePromptfocus 就加 focusworkspacePrompt如果按这份规范继续收敛，当前最优先的方向应是：
basic/user prompt-only
referencePromptdesignContextprompt-only
result / compare