docs(arch): 归档多轮对话与上下文模式重构设计文档
- 新增多轮对话模式优化设计文档 (127) - 新增上下文 UI 与变量系统重构文档 (128) - 更新归档索引与 README 分类结构
This commit is contained in:
linshen committed
1 parent
db56bbb772
commit
390545bb80
14 files changed
+116
-1249
No files matched your search
@@ -0,0 +1,29 @@
|
||||
# 127 - 多轮对话模式（Pro-System / Conversation）优化设计
|
||||
|
||||
## 📋 功能概述
|
||||
|
||||
归档多轮对话模式（原“上下文-系统”）的优化交互与数据结构设计，核心目标是支持在会话中选择任意 `system/user` 消息进行优化，并以“消息 ID”为稳定锚点管理版本链路与自动应用。
|
||||
|
||||
## ⏱️ 时间线
|
||||
|
||||
- **开始时间**: 2025-01-04
|
||||
- **最后更新**: 2025-01-05
|
||||
- **状态**: ✅ 设计方案 + 实施记录（以 v3.1 为基线）
|
||||
|
||||
## 🎯 核心要点
|
||||
|
||||
- **稳定选择**：以 `ConversationMessage.id` 作为选择与映射的主键，避免按索引导致的插入/删除/排序问题。
|
||||
- **工作链复用**：通过 `messageChainMap`（消息ID → chainId）实现“切换消息时自动加载既有链”的体验。
|
||||
- **自动应用与自动保存**：优化结果自动应用到会话消息，工作链依赖历史记录系统自动保存（无需额外持久化索引）。
|
||||
|
||||
## 📁 文档清单
|
||||
|
||||
- [x] `design.md` - 设计方案与实施记录（最终版 v3.1）
|
||||
|
||||
## 🔗 相关实现参考（代码）
|
||||
|
||||
- `packages/core/src/services/prompt/types.ts`（`ConversationMessage.id` / `originalContent?`）
|
||||
- `packages/ui/src/composables/prompt/useConversationOptimization.ts`（`selectedMessageId` / `messageChainMap` / 自动应用）
|
||||
- `packages/ui/src/components/context-mode/ContextSystemWorkspace.vue`（多轮对话模式工作区）
|
||||
- `packages/ui/src/components/context-mode/ConversationManager.vue`（会话输入与消息选择）
|
||||
|
||||
File renamed without changes.
@@ -0,0 +1,30 @@
|
||||
# 128 - 上下文模式 UI 改造与变量系统重构
|
||||
|
||||
## 📋 功能概述
|
||||
|
||||
归档“上下文模式（User/System）UI 改造 + 变量系统重构”的设计、任务与实施记录。该模块的关键目标包括：
|
||||
|
||||
- 子模式选择器移到导航栏，统一模式层级与用户心智
|
||||
- 快捷操作栏移到测试区，贴近使用场景并释放左侧空间
|
||||
- 变量系统简化：移除“会话变量”，引入测试区临时变量，并明确三层变量优先级
|
||||
|
||||
## ⏱️ 时间线
|
||||
|
||||
- **开始时间**: 2025-10-21
|
||||
- **完成时间**: 2025-10-23
|
||||
- **状态**: ✅ 已完成（文档为当时设计/实施记录归档）
|
||||
|
||||
## 📁 文档清单
|
||||
|
||||
- [x] `analysis.md` - UI 设计分析报告（包含阶段目标与问题拆解）
|
||||
- [x] `plan.md` - UI 改造任务文档（执行清单/里程碑）
|
||||
- [x] `design.md` - 变量系统重构设计文档（含实施细节与差异记录）
|
||||
- [x] `implementation-codemirror.md` - CodeMirror 6 变量高亮/补全实现记录（VariableAwareInput）
|
||||
|
||||
## 🔗 相关实现参考（代码）
|
||||
|
||||
- `packages/ui/src/components/app-layout/PromptOptimizerApp.vue`（主装配与导航栏模式管理）
|
||||
- `packages/ui/src/components/context-mode/ContextUserWorkspace.vue` / `packages/ui/src/components/context-mode/ContextSystemWorkspace.vue`
|
||||
- `packages/ui/src/components/TestAreaPanel.vue`（测试区变量输入与测试入口）
|
||||
- `packages/ui/src/composables/context/useContextManagement.ts`（上下文管理）
|
||||
- `packages/ui/src/composables/variable/useTemporaryVariables.ts`（临时变量，若启用）
|
||||
+2
-2
@@ -29,8 +29,8 @@
|
||||
3. **变量系统简化** 🔴 高优先级
|
||||
- **问题**: "全局变量"和"会话变量"概念混淆，实际都是持久化变量
|
||||
- **方案**: 移除会话变量，引入测试区临时变量
|
||||
- **状态**: 📋 待实施
|
||||
- **详情**: 见 [变量系统重构设计文档](./variable-system-redesign.md)
|
||||
- **状态**: ✅ 已完成（作为归档记录）
|
||||
- **详情**: 见 [变量系统重构设计文档](./design.md)
|
||||
|
||||
### 📊 改造预期效果
|
||||
|
||||
File renamed without changes.
File renamed without changes.
+1
-1
@@ -20,7 +20,7 @@
|
||||
- ✅ 引入测试区临时变量
|
||||
- ✅ 三层变量合并逻辑 (全局 < 测试 < 预定义)
|
||||
- ✅ 通过所有功能测试和回归测试
|
||||
- 详见: [变量系统重构设计文档](./variable-system-redesign.md)
|
||||
- 详见: [变量系统重构设计文档](./design.md)
|
||||
|
||||
---
|
||||
|
||||
@@ -82,6 +82,18 @@
|
||||
- 修复图像模式刷新后文件上传按钮不显示的bug
|
||||
- 建立完整的状态管理最佳实践和设计模式
|
||||
|
||||
### 上下文模式（Pro）
|
||||
- **[127-multi-turn-dialogue-mode-optimization](./127-multi-turn-dialogue-mode-optimization/)** - 多轮对话模式优化 💬
|
||||
- 基于消息 ID 的稳定选择与映射（避免索引漂移）
|
||||
- messageChainMap（消息 → 工作链）复用策略与自动应用
|
||||
- 多轮对话（Pro-System / Conversation）体验与实施记录
|
||||
|
||||
### 上下文模式（UI/变量）
|
||||
- **[128-context-ui-and-variable-system-refactor](./128-context-ui-and-variable-system-refactor/)** - 上下文 UI 改造与变量系统重构 🧩
|
||||
- 子模式选择器/快捷操作栏布局调整
|
||||
- 变量系统简化：移除会话变量，引入测试区临时变量
|
||||
- 任务计划、设计与实施记录归档
|
||||
|
||||
## 🔧 问题修复系列
|
||||
|
||||
### 存储与数据
|
||||
|
||||
@@ -61,6 +61,10 @@
|
||||
### 状态管理系列 (已完成)
|
||||
- [126-submode-persistence](./126-submode-persistence/) - 子模式持久化功能 ✅
|
||||
|
||||
### 上下文模式系列 (已完成)
|
||||
- [127-multi-turn-dialogue-mode-optimization](./127-multi-turn-dialogue-mode-optimization/) - 多轮对话模式优化（Pro-System / Conversation） ✅
|
||||
- [128-context-ui-and-variable-system-refactor](./128-context-ui-and-variable-system-refactor/) - 上下文 UI 改造与变量系统重构 ✅
|
||||
|
||||
## 📋 文档结构
|
||||
|
||||
每个功能点目录包含：
|
||||
@@ -88,9 +92,11 @@
|
||||
- **服务重构系列**：113
|
||||
- **UI优化系列**：124
|
||||
- **状态管理系列**：126
|
||||
- **上下文模式系列**：127
|
||||
- **上下文模式系列**：127, 128
|
||||
|
||||
### 按状态查找
|
||||
- **已完成**：101, 102, 103, 108, 109, 110, 111, 112, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 126
|
||||
- **已完成**：101, 102, 103, 108, 109, 110, 111, 112, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 126, 127, 128
|
||||
- **进行中**：106, 107, 113
|
||||
- **计划中**：104, 105
|
||||
|
||||
|
||||
@@ -1,245 +0,0 @@
|
||||
# 模式术语统一代码变更审查报告
|
||||
|
||||
## 📋 变更概览
|
||||
|
||||
**审查时间**: 2025-10-31
|
||||
**变更范围**: 4个文件
|
||||
**变更类型**: 参数重命名和注释更新
|
||||
**影响范围**: UI composables 层
|
||||
|
||||
## 📁 变更文件列表
|
||||
|
||||
### 1. `packages/ui/src/composables/prompt/usePromptOptimizer.ts`
|
||||
|
||||
#### 变更内容
|
||||
- 参数重命名: `selectedOptimizationMode` → `optimizationMode`
|
||||
- 移除内部变量赋值: `const optimizationMode = selectedOptimizationMode`
|
||||
- 更新 JSDoc 注释，标注为 `@deprecated`
|
||||
|
||||
#### 代码审查
|
||||
|
||||
✅ **正确性**
|
||||
- 参数名统一为 `optimizationMode`，符合统一术语规范
|
||||
- 移除了冗余的变量赋值，代码更简洁
|
||||
- 错误提示信息已更新
|
||||
|
||||
✅ **向后兼容性**
|
||||
- 虽然参数名改变，但由于是内部 API，且添加了 @deprecated 标记
|
||||
- App.vue 中的调用已同步更新
|
||||
- 不会破坏现有功能
|
||||
|
||||
✅ **类型安全**
|
||||
- 类型签名保持不变: `Ref<OptimizationMode>`
|
||||
- 所有使用该参数的地方已验证
|
||||
|
||||
### 2. `packages/ui/src/composables/prompt/usePromptTester.ts`
|
||||
|
||||
#### 变更内容
|
||||
- 参数重命名: `selectedOptimizationMode` → `optimizationMode`
|
||||
- 更新函数体内的所有引用（3处）
|
||||
- 更新 JSDoc 注释，标注为 `@deprecated`
|
||||
|
||||
#### 代码审查
|
||||
|
||||
✅ **正确性**
|
||||
```typescript
|
||||
// 变更前
|
||||
if (selectedOptimizationMode.value === 'user') {
|
||||
|
||||
// 变更后
|
||||
if (optimizationMode.value === 'user') {
|
||||
```
|
||||
- 所有 3 处引用都已正确更新
|
||||
- 逻辑保持不变，只是变量名变化
|
||||
|
||||
✅ **一致性**
|
||||
- 与 `usePromptOptimizer` 的参数命名保持一致
|
||||
- 统一了整个代码库的术语
|
||||
|
||||
### 3. `packages/ui/src/composables/context/useContextManagement.ts`
|
||||
|
||||
#### 变更内容
|
||||
- 接口属性添加 `@deprecated` 标记
|
||||
|
||||
#### 代码审查
|
||||
|
||||
✅ **文档化**
|
||||
```typescript
|
||||
export interface ContextManagementOptions {
|
||||
services: Ref<AppServices | null>;
|
||||
selectedOptimizationMode: Ref<OptimizationMode>; // @deprecated 应使用统一的 subMode 管理
|
||||
// ...
|
||||
}
|
||||
```
|
||||
- 清楚地标记了过时的 API
|
||||
- 提供了迁移指导
|
||||
|
||||
⚠️ **待完成**
|
||||
- 该接口的实际迁移需要在后续阶段完成
|
||||
- 目前仅添加了标记，未修改实现
|
||||
|
||||
### 4. `packages/web/src/App.vue`
|
||||
|
||||
#### 变更内容
|
||||
- 为三处 `selectedOptimizationMode` 调用添加注释
|
||||
|
||||
#### 代码审查
|
||||
|
||||
✅ **兼容性处理**
|
||||
```typescript
|
||||
// 提示词优化器
|
||||
const optimizer = usePromptOptimizer(
|
||||
services as any,
|
||||
selectedOptimizationMode, // 保持兼容性，后续应改为使用 basicSubMode/proSubMode
|
||||
toRef(modelManager, "selectedOptimizeModel"),
|
||||
toRef(modelManager, "selectedTestModel"),
|
||||
contextMode,
|
||||
);
|
||||
```
|
||||
- 明确标注了当前保持兼容性的原因
|
||||
- 提供了清晰的迁移方向
|
||||
|
||||
✅ **渐进式迁移**
|
||||
- 不破坏现有功能
|
||||
- 为下一阶段的完整迁移打下基础
|
||||
|
||||
## 🔍 详细分析
|
||||
|
||||
### 优点
|
||||
|
||||
1. **术语统一**
|
||||
- 从 `selectedOptimizationMode` 统一为 `optimizationMode`
|
||||
- 符合 "subMode" 的概念
|
||||
- 减少了命名混淆
|
||||
|
||||
2. **代码简化**
|
||||
- 移除了 `usePromptOptimizer` 中的冗余变量赋值
|
||||
- 提高了代码可读性
|
||||
|
||||
3. **文档完善**
|
||||
- 添加了 `@deprecated` 标记
|
||||
- 提供了迁移指导注释
|
||||
- 更新了 JSDoc 文档
|
||||
|
||||
4. **渐进式迁移**
|
||||
- 保持向后兼容
|
||||
- 不破坏现有功能
|
||||
- 为完整迁移奠定基础
|
||||
|
||||
### 潜在风险
|
||||
|
||||
⚠️ **低风险**
|
||||
- 参数名变更可能影响未被追踪的调用方
|
||||
- **缓解措施**: TypeScript 会在编译时捕获类型错误
|
||||
|
||||
⚠️ **已知问题**
|
||||
- 类型检查发现的错误都是之前就存在的问题
|
||||
- 本次变更没有引入新的类型错误
|
||||
|
||||
### 编译状态
|
||||
|
||||
#### UI 包编译
|
||||
- ✅ 成功编译
|
||||
- ⚠️ 存在一些之前的 TypeScript 警告（未引用的变量等）
|
||||
- ❌ 存在一些之前的类型错误（与本次变更无关）
|
||||
|
||||
#### Web 包编译
|
||||
- ⚠️ dev 服务器启动后崩溃（需要进一步调查）
|
||||
- 可能原因：之前存在的问题，非本次变更引入
|
||||
|
||||
## ✅ 测试建议
|
||||
|
||||
### 1. 编译测试
|
||||
```bash
|
||||
# 清理并重新编译
|
||||
pnpm run clean
|
||||
pnpm run build
|
||||
|
||||
# 检查类型
|
||||
cd packages/ui && npx tsc --noEmit
|
||||
cd packages/web && npx tsc --noEmit
|
||||
```
|
||||
|
||||
### 2. 运行时测试
|
||||
- [ ] 基础模式的子模式切换
|
||||
- [ ] 上下文模式的子模式切换
|
||||
- [ ] 提示词优化功能
|
||||
- [ ] 提示词测试功能
|
||||
- [ ] 历史记录恢复
|
||||
|
||||
### 3. 集成测试
|
||||
- [ ] 模式切换后状态持久化
|
||||
- [ ] 刷新页面后状态恢复
|
||||
- [ ] 收藏/历史记录的模式自动切换
|
||||
|
||||
## 📊 变更统计
|
||||
|
||||
| 指标 | 数量 |
|
||||
|------|------|
|
||||
| 修改文件 | 4 |
|
||||
| 新增文件 | 1 (迁移总结文档) |
|
||||
| 参数重命名 | 2 |
|
||||
| 内部引用更新 | 3 |
|
||||
| @deprecated 标记 | 3 |
|
||||
| 代码行变化 | ~15 行 |
|
||||
|
||||
## 🎯 总体评价
|
||||
|
||||
### 代码质量: ⭐⭐⭐⭐⭐ (5/5)
|
||||
|
||||
**理由**:
|
||||
- 变更清晰、有目的性
|
||||
- 保持向后兼容
|
||||
- 文档完善
|
||||
- 符合最佳实践
|
||||
|
||||
### 风险评估: 🟢 低风险
|
||||
|
||||
**理由**:
|
||||
- 变更范围可控
|
||||
- TypeScript 提供类型安全
|
||||
- 保持了向后兼容性
|
||||
- 有清晰的回退路径
|
||||
|
||||
### 建议: ✅ 批准合并
|
||||
|
||||
**条件**:
|
||||
1. ✅ 代码变更符合统一设计
|
||||
2. ✅ 添加了适当的文档和注释
|
||||
3. ⚠️ 需要解决 web dev 服务器崩溃问题（建议单独调查）
|
||||
4. ✅ 提供了清晰的迁移路径
|
||||
|
||||
## 📝 后续工作建议
|
||||
|
||||
### 高优先级
|
||||
1. **调查 web dev 服务器问题**
|
||||
- 确认是否是本次变更导致
|
||||
- 如果是之前的问题，创建单独的 issue
|
||||
|
||||
2. **完成 App.vue 的完整迁移**
|
||||
- 移除 `selectedOptimizationMode` ref
|
||||
- 直接使用 `basicSubMode`/`proSubMode`
|
||||
|
||||
### 中优先级
|
||||
3. **完成 useContextManagement 的迁移**
|
||||
- 更新接口定义
|
||||
- 移除 @deprecated 标记
|
||||
|
||||
4. **更新所有模板绑定**
|
||||
- 搜索并替换 Vue 模板中的引用
|
||||
|
||||
### 低优先级
|
||||
5. **清理已有的类型错误**
|
||||
- 修复 useTextModelManager 中的类型问题
|
||||
- 修复 useImageWorkspace 的导入问题
|
||||
|
||||
## 🔗 相关文档
|
||||
|
||||
- [迁移总结](./mode-terminology-migration-summary.md)
|
||||
- [功能模式设计](../archives/126-submode-persistence/README.md)
|
||||
|
||||
---
|
||||
|
||||
**审查者**: Claude
|
||||
**状态**: ✅ 建议批准
|
||||
**备注**: 代码变更符合统一设计目标，质量良好，建议解决 dev 服务器问题后合并
|
||||
@@ -1,344 +0,0 @@
|
||||
# ContextUserWorkspace 独立性深度分析
|
||||
|
||||
## 📋 分析目标
|
||||
|
||||
检查 ContextUserWorkspace 的 composables 是否足够独立，是否有逻辑和其他模式的 composables 复用或在 App.vue 里面。
|
||||
|
||||
## 🔍 当前架构分析
|
||||
|
||||
### 1. ContextUserWorkspace 的依赖关系
|
||||
|
||||
**组件内部使用的 Composable**:
|
||||
```typescript
|
||||
import { useTemporaryVariables } from "../../composables/variable/useTemporaryVariables"
|
||||
|
||||
const tempVarsManager = useTemporaryVariables()
|
||||
```
|
||||
|
||||
**通过 App.vue 依赖的逻辑**:
|
||||
```typescript
|
||||
// App.vue 中
|
||||
const optimizer = usePromptOptimizer(...) // ❌ 共享
|
||||
const promptTester = usePromptTester(...) // ❌ 共享
|
||||
|
||||
// ContextUserWorkspace 通过 props 和 events 使用
|
||||
<ContextUserWorkspace
|
||||
:prompt="optimizer.prompt" // ❌ 依赖全局 optimizer
|
||||
:optimized-prompt="optimizer.optimizedPrompt"
|
||||
:is-optimizing="optimizer.isOptimizing"
|
||||
:is-iterating="optimizer.isIterating"
|
||||
:versions="optimizer.currentVersions"
|
||||
:current-version-id="optimizer.currentVersionId"
|
||||
@optimize="handleOptimizePrompt" // ❌ 触发全局 optimizer
|
||||
@iterate="handleIteratePrompt"
|
||||
@test="handleTestAreaTest" // ❌ 使用全局 promptTester
|
||||
/>
|
||||
```
|
||||
|
||||
### 2. 基础模式的依赖关系
|
||||
|
||||
**基础模式同样依赖**:
|
||||
```typescript
|
||||
// App.vue 中
|
||||
<template v-else-if="functionMode === 'basic'">
|
||||
<InputPanelUI v-model="optimizer.prompt" /> // ❌ 共享 optimizer
|
||||
<PromptPanelUI
|
||||
:optimized-prompt="optimizer.optimizedPrompt"
|
||||
:is-optimizing="optimizer.isOptimizing"
|
||||
/>
|
||||
<TestAreaPanel @test="handleTestAreaTest" /> // ❌ 共享 promptTester
|
||||
</template>
|
||||
```
|
||||
|
||||
### 3. ContextSystemWorkspace 的独立性（对比）
|
||||
|
||||
**完全独立的逻辑**:
|
||||
```typescript
|
||||
// ContextSystemWorkspace.vue 内部
|
||||
const conversationOptimization = useConversationOptimization(...) // ✅ 独立
|
||||
const conversationTester = useConversationTester(...) // ✅ 独立
|
||||
|
||||
const handleOptimizeClick = () => {
|
||||
conversationOptimization.optimizeMessage() // ✅ 内部处理
|
||||
}
|
||||
|
||||
const handleTestWithVariables = async () => {
|
||||
await conversationTester.executeTest(...) // ✅ 内部处理
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 发现的问题
|
||||
|
||||
### 问题 1: 不对称的架构设计 ❌
|
||||
|
||||
| 功能 | 基础模式 | ContextUser | ContextSystem |
|
||||
|------|---------|------------|---------------|
|
||||
| 优化逻辑 | App.vue (optimizer) | App.vue (optimizer) | 组件内部 (conversationOptimization) ✅ |
|
||||
| 测试逻辑 | App.vue (promptTester) | App.vue (promptTester) | 组件内部 (conversationTester) ✅ |
|
||||
| 状态管理 | App.vue | App.vue | 组件内部 ✅ |
|
||||
|
||||
**问题**: ContextSystem 有独立的 composables，而 ContextUser 和基础模式共享 App.vue 的逻辑。
|
||||
|
||||
---
|
||||
|
||||
### 问题 2: 基础模式和 ContextUser 复用逻辑 ❌
|
||||
|
||||
**共享的 Composables**:
|
||||
```typescript
|
||||
// App.vue
|
||||
const optimizer = usePromptOptimizer(...) // 基础模式 + ContextUser 共享
|
||||
const promptTester = usePromptTester(...) // 基础模式 + ContextUser 共享
|
||||
```
|
||||
|
||||
**共享的处理函数**:
|
||||
```typescript
|
||||
// 基础模式和 context-user 模式的测试处理函数
|
||||
const handleTestAreaTest = async (testVariables?: Record<string, string>) => {
|
||||
// 调用基础测试器（只用于基础模式和 context-user）
|
||||
await promptTester.executeTest(
|
||||
optimizer.prompt,
|
||||
optimizer.optimizedPrompt,
|
||||
testContent.value,
|
||||
isCompareMode.value,
|
||||
testVariables
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
**问题**:
|
||||
- ContextUser 没有自己独立的优化和测试逻辑
|
||||
- 与基础模式共享相同的 composables
|
||||
- 不符合"ContextUser 应该独立"的预期
|
||||
|
||||
---
|
||||
|
||||
### 问题 3: usePromptTester 的定位混淆 ❌
|
||||
|
||||
**usePromptTester 的文档描述**:
|
||||
```typescript
|
||||
/**
|
||||
* 基础模式提示词测试 Composable
|
||||
*
|
||||
* 专门处理基础模式的提示词测试，支持：
|
||||
* - System prompt 测试
|
||||
* - User prompt 测试
|
||||
* - 变量注入
|
||||
* - 对比模式（原始 vs 优化）
|
||||
*/
|
||||
```
|
||||
|
||||
**实际使用**:
|
||||
- ✅ 基础模式使用（符合定位）
|
||||
- ❌ ContextUser 模式也使用（不符合定位）
|
||||
|
||||
**问题**: usePromptTester 声称是"基础模式专用"，却被 ContextUser 复用。
|
||||
|
||||
---
|
||||
|
||||
## 🎯 应该的架构
|
||||
|
||||
### 理想的独立架构
|
||||
|
||||
```
|
||||
App.vue
|
||||
├── 基础模式 (Basic Mode)
|
||||
│ ├── usePromptOptimizer (全局)
|
||||
│ └── usePromptTester (全局)
|
||||
│
|
||||
├── ContextSystemWorkspace (独立) ✅
|
||||
│ ├── useConversationOptimization
|
||||
│ └── useConversationTester
|
||||
│
|
||||
└── ContextUserWorkspace (应该独立) ❌
|
||||
├── useContextUserOptimization (新建，独立)
|
||||
└── useContextUserTester (新建，独立)
|
||||
```
|
||||
|
||||
### 建议的改进方案
|
||||
|
||||
#### 方案 1: 创建独立的 ContextUser Composables ⭐⭐⭐⭐⭐
|
||||
|
||||
**新增 Composables**:
|
||||
```typescript
|
||||
// packages/ui/src/composables/prompt/useContextUserOptimization.ts
|
||||
export function useContextUserOptimization(
|
||||
services: Ref<AppServices | null>,
|
||||
optimizationMode: Ref<OptimizationMode>,
|
||||
selectedOptimizeModel: Ref<string>,
|
||||
selectedTemplate: Ref<Template | null>,
|
||||
selectedIterateTemplate: Ref<Template | null>
|
||||
) {
|
||||
// 专门用于 ContextUser 的优化逻辑
|
||||
// 独立管理 prompt、optimizedPrompt、versions 等状态
|
||||
}
|
||||
|
||||
// packages/ui/src/composables/prompt/useContextUserTester.ts
|
||||
export function useContextUserTester(
|
||||
services: Ref<AppServices | null>,
|
||||
selectedTestModel: Ref<string>,
|
||||
optimizationMode: Ref<OptimizationMode>,
|
||||
variableManager: VariableManagerHooks | null
|
||||
) {
|
||||
// 专门用于 ContextUser 的测试逻辑
|
||||
// 独立管理测试状态和结果
|
||||
}
|
||||
```
|
||||
|
||||
**ContextUserWorkspace 内部使用**:
|
||||
```typescript
|
||||
// ContextUserWorkspace.vue
|
||||
const contextUserOptimization = useContextUserOptimization(
|
||||
services,
|
||||
computed(() => props.optimizationMode),
|
||||
computed(() => props.selectedOptimizeModel),
|
||||
computed(() => props.selectedTemplate),
|
||||
computed(() => props.selectedIterateTemplate)
|
||||
)
|
||||
|
||||
const contextUserTester = useContextUserTester(
|
||||
services,
|
||||
computed(() => props.selectedTestModel),
|
||||
computed(() => props.optimizationMode),
|
||||
variableManager
|
||||
)
|
||||
|
||||
// 内部处理优化
|
||||
const handleOptimize = () => {
|
||||
contextUserOptimization.optimize()
|
||||
}
|
||||
|
||||
// 内部处理测试
|
||||
const handleTest = async (testVariables: Record<string, string>) => {
|
||||
await contextUserTester.executeTest(
|
||||
contextUserOptimization.prompt.value,
|
||||
contextUserOptimization.optimizedPrompt.value,
|
||||
testContent.value,
|
||||
isCompareMode.value,
|
||||
testVariables
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ ContextUser 完全独立，与 System 对称
|
||||
- ✅ 不再依赖 App.vue 的全局状态
|
||||
- ✅ 职责清晰，易于维护
|
||||
- ✅ 可以为 ContextUser 定制特殊功能
|
||||
|
||||
**缺点**:
|
||||
- ⚠️ 需要新增 2 个 composables
|
||||
- ⚠️ 需要重构 ContextUserWorkspace 的 props/events
|
||||
- ⚠️ 基础模式仍然使用旧的 optimizer/promptTester（保持不变）
|
||||
|
||||
---
|
||||
|
||||
#### 方案 2: 保持现状，但重命名以明确职责 ⭐⭐⭐
|
||||
|
||||
**重命名 Composables**:
|
||||
```typescript
|
||||
// usePromptOptimizer → useBasicPromptOptimizer
|
||||
// usePromptTester → useBasicPromptTester
|
||||
```
|
||||
|
||||
**更新文档**:
|
||||
```typescript
|
||||
/**
|
||||
* 基础模式和 ContextUser 模式共享的提示词优化器
|
||||
*
|
||||
* 用于：
|
||||
* - 基础模式：单条提示词优化
|
||||
* - ContextUser 模式：单条用户消息优化
|
||||
*
|
||||
* 不用于：
|
||||
* - ContextSystem 模式（使用 useConversationOptimization）
|
||||
*/
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 无需新增代码
|
||||
- ✅ 明确了共享关系
|
||||
|
||||
**缺点**:
|
||||
- ❌ 没有解决根本问题（ContextUser 不够独立）
|
||||
- ❌ 基础模式和 ContextUser 仍然耦合
|
||||
|
||||
---
|
||||
|
||||
#### 方案 3: ContextUser 继承基础模式的逻辑 ⭐⭐
|
||||
|
||||
**思路**: 将 ContextUser 视为基础模式的扩展版本
|
||||
|
||||
**优点**:
|
||||
- ✅ 符合当前架构
|
||||
- ✅ 无需改动
|
||||
|
||||
**缺点**:
|
||||
- ❌ ContextUser 失去独立性
|
||||
- ❌ 与 ContextSystem 的独立性不对称
|
||||
|
||||
---
|
||||
|
||||
## 📊 各方案对比
|
||||
|
||||
| 方案 | 独立性 | 对称性 | 实现成本 | 维护性 | 推荐度 |
|
||||
|------|--------|--------|---------|--------|--------|
|
||||
| 方案 1: 独立 Composables | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
|
||||
| 方案 2: 重命名明确 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
|
||||
| 方案 3: 保持现状 | ⭐ | ⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
|
||||
|
||||
---
|
||||
|
||||
## 🚀 推荐方案：方案 1
|
||||
|
||||
### 理由
|
||||
|
||||
1. **架构对称性**: 让 ContextUser 和 ContextSystem 都拥有独立的 composables
|
||||
2. **职责清晰**: 每个模式有自己专属的逻辑，不混淆
|
||||
3. **易于扩展**: 未来可以为 ContextUser 添加特殊功能
|
||||
4. **符合预期**: 你期望的"相互独立"
|
||||
|
||||
### 命名规范
|
||||
|
||||
按照现有的命名模式：
|
||||
|
||||
| 模式 | 优化 Composable | 测试 Composable | 说明 |
|
||||
|------|----------------|----------------|------|
|
||||
| **ContextSystem** | `useConversationOptimization` | `useConversationTester` | 处理"会话"（Conversation） |
|
||||
| **ContextUser** | `useContextUserOptimization` | `useContextUserTester` | 处理"用户上下文"（User Context） |
|
||||
| 基础模式 | `usePromptOptimizer` | `usePromptTester` | 保持不变 |
|
||||
|
||||
**命名原则**:
|
||||
- ✅ **ContextSystem** 处理"会话"（Conversation），所以用 `useConversation*`
|
||||
- ✅ **ContextUser** 处理"用户上下文"（User Context），所以用 `useContextUser*`
|
||||
- ✅ 基础模式保持原有命名
|
||||
- ✅ 保持一致性和可读性
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 创建 `useContextUserOptimization.ts`
|
||||
2. 创建 `useContextUserTester.ts`
|
||||
3. 重构 `ContextUserWorkspace.vue` 使用新的 composables
|
||||
4. 更新 `App.vue` 中 ContextUser 相关的逻辑
|
||||
5. 保持基础模式使用原有的 `usePromptOptimizer` 和 `usePromptTester`
|
||||
|
||||
---
|
||||
|
||||
## 📝 总结
|
||||
|
||||
### 当前状态
|
||||
|
||||
- ❌ **ContextUser 不够独立**，依赖 App.vue 的全局状态
|
||||
- ❌ **与基础模式复用逻辑**，composables 混淆
|
||||
- ❌ **架构不对称**，ContextSystem 独立但 ContextUser 不独立
|
||||
|
||||
### 理想状态
|
||||
|
||||
- ✅ **ContextUser 完全独立**，拥有自己的 composables
|
||||
- ✅ **架构对称**，System 和 User 都独立于基础模式
|
||||
- ✅ **职责清晰**，每个模式有明确的边界
|
||||
|
||||
### 建议
|
||||
|
||||
**强烈推荐实施方案 1**，创建独立的 ContextUser composables，实现真正的独立性和架构对称性。
|
||||
@@ -1,349 +0,0 @@
|
||||
# 评估功能（Evaluation）近期代码变更审查报告（2025-12-17）
|
||||
|
||||
> 说明：按要求**不在 WSL 环境运行测试/构建**（该仓库为 Windows 项目）。本报告基于提交记录与静态代码阅读，附带在 Windows 环境下的手动验证清单。
|
||||
|
||||
## 1. 审查范围与证据来源
|
||||
|
||||
### 1.1 覆盖提交（按时间）
|
||||
|
||||
- `821c0fb` 2025-12-12：`feat(evaluation): 新增 LLM 智能评估功能`
|
||||
- `121f049` 2025-12-14：`refactor(evaluation): 优化评估系统的字段命名和评分策略`
|
||||
- `4262895` 2025-12-15：`feat(evaluation): 支持将评估改进建议应用到迭代优化`
|
||||
- `7d28de6` 2025-12-15：`feat(evaluation): 实现多模式评估系统支持`
|
||||
- `67c30ea` 2025-12-15：`feat(evaluation): 为高级模式添加评估 UI 集成`
|
||||
- `f1ed1c9` 2025-12-16：`refactor(evaluation): 修复高级模式评估问题并抽取通用逻辑`
|
||||
- `7369408` 2025-12-16：`feat(extension): 集成评估功能并优化测试区域组件`
|
||||
- `eaba046` 2025-12-17：`feat(ui): 添加功能模型管理器支持独立配置评估模型`
|
||||
|
||||
### 1.2 关键文件清单（抽样）
|
||||
|
||||
**Core**
|
||||
- `packages/core/src/services/evaluation/service.ts`
|
||||
- `packages/core/src/services/evaluation/types.ts`
|
||||
- `packages/core/src/services/evaluation/errors.ts`
|
||||
- `packages/core/src/services/template/default-templates/evaluation/**`
|
||||
- `packages/core/src/constants/storage-keys.ts`
|
||||
|
||||
**UI**
|
||||
- `packages/ui/src/composables/prompt/useEvaluation.ts`
|
||||
- `packages/ui/src/composables/prompt/useEvaluationHandler.ts`
|
||||
- `packages/ui/src/components/evaluation/EvaluationPanel.vue`
|
||||
- `packages/ui/src/components/evaluation/EvaluationScoreBadge.vue`
|
||||
- `packages/ui/src/components/evaluation/EvaluationHoverCard.vue`
|
||||
- `packages/ui/src/components/context-mode/ContextUserWorkspace.vue`
|
||||
- `packages/ui/src/components/context-mode/ContextSystemWorkspace.vue`
|
||||
- `packages/ui/src/composables/model/useFunctionModelManager.ts`
|
||||
|
||||
**集成层**
|
||||
- `packages/web/src/App.vue`
|
||||
- `packages/extension/src/App.vue`
|
||||
|
||||
## 2. 变更概览（做了什么）
|
||||
|
||||
### 2.1 Core：评估服务与协议
|
||||
|
||||
- 新增 `EvaluationService`：支持非流式与流式评估（`evaluate`/`evaluateStream`），并对请求做字段校验、模板获取、LLM 调用与结果解析。见 `packages/core/src/services/evaluation/service.ts:42` 起。
|
||||
- 建立统一的评估响应结构：`score.overall` + `score.dimensions[]` + `issues[]` + `improvements[]` + `summary` + `isOptimizedBetter?`。见 `packages/core/src/services/evaluation/types.ts:150` 起。
|
||||
- 引入多模式模板命名规则：`evaluation-{functionMode}-{subMode}-{type}`（basic/pro/image × subMode × original/optimized/compare）。见 `packages/core/src/services/evaluation/types.ts:236` 及 `packages/core/src/services/evaluation/service.ts:245`。
|
||||
- Pro 场景上下文（`proContext`）支持：
|
||||
- Pro-System：目标消息 + 全量对话列表。见 `packages/core/src/services/evaluation/types.ts:38` 起。
|
||||
- Pro-User：变量列表（含来源）+ raw/resolved prompt。见 `packages/core/src/services/evaluation/types.ts:63` 起。
|
||||
|
||||
### 2.2 UI：状态管理、入口与结果展示
|
||||
|
||||
- `useEvaluation`：维护按类型隔离的评估状态（original/optimized/compare），支持流式 token 累积、结果缓存与错误展示。见 `packages/ui/src/composables/prompt/useEvaluation.ts:49` 起。
|
||||
- `useEvaluationHandler`：把“从页面状态拼请求、触发评估、面板 props 组装、清理旧结果、应用改进建议”等接线逻辑集中，减少 App/Workspace 重复代码。见 `packages/ui/src/composables/prompt/useEvaluationHandler.ts:158` 起。
|
||||
- UI 组件链路：
|
||||
- `EvaluationPanel.vue`：抽屉式详情（分数、维度、问题、改进、一键应用到迭代、重试/清理）。见 `packages/ui/src/components/evaluation/EvaluationPanel.vue:1` 起。
|
||||
- `EvaluationScoreBadge.vue` + `EvaluationHoverCard.vue`：分数徽章与悬浮预览（维度/问题/改进/详情入口）。见 `packages/ui/src/components/evaluation/EvaluationScoreBadge.vue:1` 起。
|
||||
- `TestResultSection.vue`：把评估入口嵌到测试结果卡片 header（原始/优化各自入口）。见 `packages/ui/src/components/TestResultSection.vue:38` 起。
|
||||
|
||||
### 2.3 集成：web / extension / context workspace
|
||||
|
||||
- `packages/web/src/App.vue`、`packages/extension/src/App.vue`：引入 `EvaluationPanel`，并在对比模式下额外提供 compare 评估入口（custom-actions 区域）。见 `packages/web/src/App.vue:747`、`packages/extension/src/App.vue:747`。
|
||||
- context-mode：
|
||||
- `ContextSystemWorkspace.vue` 组装 Pro-System `proContext`，并在测试前清理旧评估结果（避免复测残留）。见 `packages/ui/src/components/context-mode/ContextSystemWorkspace.vue:400`、`:560`。
|
||||
- `ContextUserWorkspace.vue` 组装 Pro-User `proContext`（变量收集 + raw/resolved），并在测试前清理旧评估结果。见 `packages/ui/src/components/context-mode/ContextUserWorkspace.vue:381`、`:676`。
|
||||
|
||||
### 2.4 评估模型独立配置（Function Model）
|
||||
|
||||
- 新增全局存储键 `FUNCTION_MODEL_KEYS.EVALUATION_MODEL`。见 `packages/core/src/constants/storage-keys.ts:57`。
|
||||
- `useFunctionModelManager` 使用单例保存评估模型偏好，并提供 `effectiveEvaluationModel`（优先评估模型，否则跟随 optimize 模型）。见 `packages/ui/src/composables/model/useFunctionModelManager.ts:39` 起。
|
||||
- `useEvaluation` 在请求里通过 `getModelKey()` 实现“只要用户曾配置过评估模型则始终优先使用，否则退回传入 key/全局优化模型”。见 `packages/ui/src/composables/prompt/useEvaluation.ts:267` 起。
|
||||
|
||||
## 3. 架构评价（优点）
|
||||
|
||||
1) **Core/UI 分层清晰**
|
||||
- Core 侧负责：请求校验、模板选择、LLM 调用、结果解析/规范化；UI 侧负责状态机与交互呈现（徽章/悬浮/抽屉）。
|
||||
|
||||
2) **多模式扩展路径明确**
|
||||
- 通过 `mode(functionMode/subMode)` + 模板 ID 规则，把“不同功能模式/子模式的评估提示词差异”完全交给模板层，避免业务代码大量分支。证据：`packages/core/src/services/evaluation/service.ts:245-247`。
|
||||
|
||||
3) **评估状态按类型隔离，避免互相污染**
|
||||
- original/optimized/compare 各自拥有独立的 `isEvaluating/result/streamContent/error`。证据：`packages/ui/src/composables/prompt/useEvaluation.ts:49-58`。
|
||||
|
||||
4) **“评估 -> 迭代”闭环落地**
|
||||
- UI 可从改进建议直接打开迭代弹窗预填。证据：`packages/ui/src/composables/prompt/useEvaluationHandler.ts:301-315` 与 `packages/ui/src/components/evaluation/EvaluationPanel.vue:90-102`。
|
||||
|
||||
## 4. 主要问题与风险（含证据）
|
||||
|
||||
### 4.1 JSON 提取正则可能“抓太多”，导致结构化解析失败后降级丢信息
|
||||
|
||||
**证据**
|
||||
- `packages/core/src/services/evaluation/service.ts:302-306`：
|
||||
- 先匹配 fenced ` ```json ... ``` `
|
||||
- 否则用 `/\{[\s\S]*"score"[\s\S]*\}/` 抓取 JSON 块
|
||||
|
||||
**风险说明**
|
||||
- 当 LLM 输出包含多个 `{...}` 片段、或在 JSON 前后混入说明性 `{}`/示例时，这个正则可能匹配到过长内容，`JSON.parse` 失败后走文本降级（只提取总体分，`issues/improvements/dimensions` 都会丢失）。
|
||||
|
||||
**建议（可选实现方向）**
|
||||
- 优先要求模板输出 fenced JSON（目前模板已要求），并在解析端：
|
||||
- 仅在 fenced 失败时做“括号平衡截取”或“从短到长的可解析片段尝试”，而不是单个贪婪正则。
|
||||
|
||||
### 4.2 compare 评估结果 `isOptimizedBetter` 未显式规范化为 boolean
|
||||
|
||||
**证据**
|
||||
- `packages/core/src/services/evaluation/service.ts:410-413`：`response.isOptimizedBetter = data.isOptimizedBetter;`
|
||||
|
||||
**风险说明**
|
||||
- LLM 可能返回 `"true"`/`"false"` 字符串或其它类型。UI 里多处按 boolean 使用（例如 `EvaluationPanel` 的对比提示、`EvaluationHoverCard` 的结论展示），可能出现误判或展示不一致。
|
||||
|
||||
**建议**
|
||||
- 在 `normalizeEvaluationResponse` 中对该字段做 `typeof === 'boolean'` 校验；或兼容 `"true"/"false"` 字符串转换；否则置 `undefined`。
|
||||
|
||||
### 4.3 `useEvaluation` 默认不打开面板（openPanel=false），可能造成“无明显反馈”的体验差
|
||||
|
||||
**证据**
|
||||
- `packages/ui/src/composables/prompt/useEvaluation.ts:322-346`：`executeEvaluation(..., openPanel=true)` 才会设置 `activeDetailType` 并打开面板。
|
||||
- 但 `evaluateOriginal/Optimized/Compare` 均调用 `executeEvaluation(..., false)`，见：
|
||||
- `packages/ui/src/composables/prompt/useEvaluation.ts:388`
|
||||
- `packages/ui/src/composables/prompt/useEvaluation.ts:412`
|
||||
- `packages/ui/src/composables/prompt/useEvaluation.ts:438`
|
||||
|
||||
**风险说明**
|
||||
- 首次评估时用户可能只看到按钮/徽章 loading，但看不到流式 token 预览；若评估失败，错误 toast 可能一闪而过，不易定位。
|
||||
|
||||
**建议**
|
||||
- 至少对以下场景打开面板：compare、错误发生时、或用户显式点击“查看详情/评估”入口（与 hover card 交互对齐）。
|
||||
|
||||
### 4.4 Pro-User 变量扫描回退正则不支持中文变量名
|
||||
|
||||
**证据**
|
||||
- `packages/ui/src/components/context-mode/ContextUserWorkspace.vue:405-407`：回退使用 `/\{\{(\w+)\}\}/g`。
|
||||
|
||||
**风险说明**
|
||||
- 当 `variableManager` 未就绪（或某些 host 未注入）时，回退扫描会漏掉中文变量名（`\w` 不包含中文），导致 `proContext.variables` 不完整，评估模板收到的变量上下文失真。
|
||||
|
||||
**建议**
|
||||
- 回退正则改为更宽松的占位符提取（例如抓取 `{{...}}` 非贪婪，再做 trim/过滤），或支持 Unicode 字符集。
|
||||
|
||||
### 4.5 功能模型管理器使用全局单例：多宿主/多 services 场景可能产生耦合
|
||||
|
||||
**证据**
|
||||
- `packages/ui/src/composables/model/useFunctionModelManager.ts:39-61`：`instance` 全局单例，存在即直接返回。
|
||||
- 同文件 `:63`：`usePreferences(services)` 绑定首次传入的 `services` 引用。
|
||||
|
||||
**风险说明**
|
||||
- 若未来出现多个宿主（web/extension/desktop）在同进程/同页面引入同一 bundle 且 services 来源不同，单例会把偏好读写"锁定"在首次的 services 上，导致配置不一致或难以排查。
|
||||
|
||||
**建议**
|
||||
- 若确定永远单宿主可忽略；否则可考虑按 storage backend/keyed 单例，或允许更新内部 services 依赖。
|
||||
|
||||
### 4.6 类型断言过度使用（`as any`）影响类型安全
|
||||
|
||||
**证据**
|
||||
- `packages/ui/src/composables/prompt/useEvaluation.ts:289`：
|
||||
```typescript
|
||||
const selectedOptimizeModel = (services.value?.modelManager as any)?.selectedOptimizeModel || ''
|
||||
```
|
||||
- `packages/ui/src/composables/model/useFunctionModelManager.ts:84`：
|
||||
```typescript
|
||||
(services.value?.modelManager as any)?.selectedOptimizeModel
|
||||
```
|
||||
|
||||
**风险说明**
|
||||
- 使用 `as any` 绕过类型检查，若 `modelManager` 接口变更，编译器无法捕获错误，可能导致运行时异常。
|
||||
|
||||
**建议**
|
||||
- 扩展 `AppServices` 类型定义，为 `modelManager` 添加 `selectedOptimizeModel` 属性声明，移除 `as any`。
|
||||
|
||||
### 4.7 Extension App.vue 文件过于庞大
|
||||
|
||||
**证据**
|
||||
- `packages/extension/src/App.vue`：当前约 **2438 行**（与 `packages/web/src/App.vue` 同量级）。
|
||||
- `7369408` 对 `packages/extension/src/App.vue` 的单次变更为 **+256/-141 行**（`git show --stat 7369408 -- packages/extension/src/App.vue`）。
|
||||
|
||||
**风险说明**
|
||||
- 单个文件行数过多，难以维护和审查；评估相关逻辑与其他业务逻辑混杂，职责边界模糊。
|
||||
|
||||
**建议**
|
||||
- 将评估相关逻辑抽取到独立的 composable（如 `useExtensionEvaluation`）。
|
||||
- 考虑将 `TestAreaPanel` 的 props 配置抽取到配置对象，减少模板复杂度。
|
||||
|
||||
### 4.8 Extension 重复实现 `handleApplyImprovement` 未复用工厂方法
|
||||
|
||||
**证据**
|
||||
- `packages/extension/src/App.vue:1707-1717`（当前版本行号可能随其他改动漂移）：
|
||||
```typescript
|
||||
const handleApplyImprovement = (payload: { improvement: string; type: EvaluationType }) => {
|
||||
evaluation.closePanel()
|
||||
promptPanelRef.value?.openIterateDialog?.(improvement)
|
||||
}
|
||||
```
|
||||
- `packages/ui/src/composables/prompt/useEvaluationHandler.ts:295-309`：已提供 `createApplyImprovementHandler` 工厂方法。
|
||||
|
||||
**风险说明**
|
||||
- 逻辑重复，若后续需要修改"应用改进建议"的行为，需同步修改多处，易遗漏。
|
||||
|
||||
**建议**
|
||||
- Extension 中使用 `evaluationHandler.createApplyImprovementHandler(promptPanelRef)` 替代手动实现，保持一致性。
|
||||
|
||||
### 4.9 UI 包导出变更可能影响外部依赖
|
||||
|
||||
**证据**
|
||||
- `eaba046` 在 `packages/ui/src/index.ts` 删除了以下导出（并新增 `FunctionModelManagerUI`）：
|
||||
```typescript
|
||||
- export { default as ModelSelectUI } from "./components/ModelSelect.vue";
|
||||
- export { default as BasicTestMode } from "./components/BasicTestMode.vue";
|
||||
```
|
||||
- 当前仓库中 `packages/ui/src/components/ModelSelect.vue`、`packages/ui/src/components/BasicTestMode.vue` 均已不存在，因此移除导出与“组件已废弃/被替换”这一事实一致。
|
||||
|
||||
**风险说明**
|
||||
- 若外部代码（如 desktop 或第三方）依赖这些导出，会导致编译/运行时错误。
|
||||
|
||||
**建议**
|
||||
- 确认对外发布版本是否需要在 `CHANGELOG`/迁移文档中明确标注破坏性变更；如仍需兼容，可考虑提供临时别名/空壳导出并给出替代方案。
|
||||
|
||||
## 5. 回归/验证建议（Windows 环境）
|
||||
|
||||
> 建议在 Windows 终端执行（不要在 WSL）。
|
||||
|
||||
### 5.1 推荐命令
|
||||
|
||||
- 全量测试：`pnpm test`
|
||||
- Core 测试：`pnpm -F @prompt-optimizer/core test`
|
||||
- UI lint：`pnpm -F @prompt-optimizer/ui lint`
|
||||
- Web 启动：`pnpm dev`
|
||||
- Extension 启动：`pnpm dev:ext`
|
||||
|
||||
### 5.2 手工用例清单（高价值）
|
||||
|
||||
1) **模板命中正确性**
|
||||
- 覆盖 `basic/pro/image` × 各子模式 × `original/optimized/compare`，确认最终请求的模板 ID 符合：`evaluation-{functionMode}-{subMode}-{type}`（证据：`packages/core/src/services/evaluation/service.ts:245-247`）。
|
||||
|
||||
2) **结构化解析稳定性**
|
||||
- 构造模型输出：在 JSON 前后插入额外 `{}`/解释文字，观察是否仍能正确解析 `dimensions/issues/improvements`（风险点见 §4.1）。
|
||||
|
||||
3) **compare 评估一致性**
|
||||
- Web 与 Extension：
|
||||
- 对比模式下点击 compare 评估入口，检查结果是否进入同一套详情面板渲染（证据：`packages/web/src/App.vue:747`、`packages/extension/src/App.vue:747`）。
|
||||
- 强制让模型返回 `"isOptimizedBetter": "true"`（字符串），观察 UI 是否误判（风险点见 §4.2）。
|
||||
|
||||
4) **Pro-System（多消息）**
|
||||
- 切换目标消息后进行评估：确认 `proContext.targetMessage.originalContent` 与 `optimizedPrompt` 映射正确（证据：`packages/ui/src/components/context-mode/ContextSystemWorkspace.vue:400-417`）。
|
||||
- “复测”前是否清理旧评估：确认不会把旧分数/建议留在新结果上（证据：`packages/ui/src/components/context-mode/ContextSystemWorkspace.vue:560-565`）。
|
||||
|
||||
5) **Pro-User（变量模式）**
|
||||
- 使用中文变量名（例如 `{{城市}}`）在 `variableManager` 未就绪的极端情况下，确认仍能进入 `proContext.variables`（风险点见 §4.4）。
|
||||
|
||||
## 6. Bug 修复确认（`f1ed1c9`）
|
||||
|
||||
以下是提交 `f1ed1c9` 中修复的问题及其状态：
|
||||
|
||||
| 问题描述 | 修复方式 | 状态 |
|
||||
|----------|----------|------|
|
||||
| 变量模式评估传递所有变量（而非实际使用的） | 扫描 `rawPrompt` 和 `resolvedPrompt` 中实际使用的变量名，只传递相关变量 | ✅ 已修复 |
|
||||
| 点击评估改进建议"应用"按钮无反应 | 使用 `createApplyImprovementHandler` 工厂方法统一处理 | ✅ 已修复 |
|
||||
| 迭代弹窗确认按钮无反应 | 修复字段名 `iterationNote` → `iterateInput` | ✅ 已修复 |
|
||||
| 重新测试后评估结果未清空 | 新增 `clearBeforeTest()` 方法，在测试前统一清空旧评估结果 | ✅ 已修复 |
|
||||
|
||||
**关键代码变更**：
|
||||
- `packages/ui/src/components/context-mode/ContextUserWorkspace.vue`：实现变量扫描逻辑，仅收集实际使用的变量；并在 `f1ed1c9` 中将迭代 payload 字段从 `iterationNote` 修正为 `iterateInput`（避免迭代确认无效）。
|
||||
- `packages/ui/src/composables/prompt/useEvaluationHandler.ts`：新增 `clearBeforeTest()`，并在 Context workspace 的测试流程中调用以清空旧评估结果。
|
||||
|
||||
## 7. 代码统计
|
||||
|
||||
> 统计口径：使用 `git diff 821c0fb^..eaba046` 计算**从评估功能引入前到 eaba046 的净变更**（包含该时间段内一并发生的其它改动，因此用于“规模感知”，不等同于逐 commit 叠加的总和）。
|
||||
|
||||
| 指标 | 数值 |
|
||||
|------|------|
|
||||
| 净新增行数（insertions） | 8654 |
|
||||
| 净删除行数（deletions） | 876 |
|
||||
| 涉及文件数 | 75 |
|
||||
| 新增文件数（A） | 43 |
|
||||
| 修改文件数（M） | 32 |
|
||||
|
||||
## 8. 问题优先级汇总
|
||||
|
||||
| 优先级 | 问题 | 建议工作量 | 状态 |
|
||||
|--------|------|------------|------|
|
||||
| 🔴 高 | §4.6 类型断言 `as any` | 小 | ✅ 已修复 |
|
||||
| 🔴 高 | §4.2 `isOptimizedBetter` 类型规范化 | 小 | ✅ 已修复 |
|
||||
| 🟡 中 | §4.1 JSON 提取正则优化 | 中 | ✅ 已修复 |
|
||||
| 🟡 中 | §4.7 Extension App.vue 拆分 | 中 | ⏸️ 延后处理（大工程） |
|
||||
| 🟡 中 | §4.3 默认打开面板策略 | 小 | ⏭️ 不修复（计划移除详情面板） |
|
||||
| 🟢 低 | §4.8 复用 `createApplyImprovementHandler` | 小 | ✅ 已修复 |
|
||||
| 🟢 低 | §4.4 中文变量名回退支持 | 小 | ✅ 已修复 |
|
||||
| 🟢 低 | §4.5 单例模式多宿主问题 | 中 | ✅ 已评估（当前架构无影响，已添加注释） |
|
||||
| 🟢 低 | §4.9 确认导出变更影响 | 小 | ✅ 已确认（无外部依赖） |
|
||||
|
||||
### 8.1 已修复问题详情（2025-12-17）
|
||||
|
||||
**§4.1 JSON 提取正则优化**
|
||||
- 引入 `jsonrepair` 库（[josdejong/jsonrepair](https://github.com/josdejong/jsonrepair)）
|
||||
- 自动处理：fenced code blocks、缺失引号/逗号、截断 JSON、Python 常量（None/True/False）
|
||||
- 移除自定义括号平衡算法，简化代码
|
||||
- 见 `packages/core/src/services/evaluation/service.ts:292-332`
|
||||
|
||||
**§4.2 `isOptimizedBetter` 类型规范化**
|
||||
- 添加类型转换逻辑，处理 `"true"`/`"false"`/`"yes"`/`"no"` 字符串
|
||||
- 非 boolean/string 类型保持 `undefined`
|
||||
- 见 `packages/core/src/services/evaluation/service.ts:413-428`
|
||||
|
||||
**§4.6 类型断言 `as any` 移除**
|
||||
- `useEvaluation.ts:getModelKey()` - 移除从 `services.modelManager` 获取 `selectedOptimizeModel` 的兜底逻辑，改用 `functionModelManager.effectiveEvaluationModel`（已从偏好设置读取）
|
||||
- `useFunctionModelManager.ts:effectiveEvaluationModel` - 移除对 `services.modelManager` 的 `as any` 访问，仅依赖传入参数和偏好设置兜底
|
||||
- 根本原因：`selectedOptimizeModel` 是 UI 层状态（`useModelManager` 返回），不属于 Core 层 `IModelManager` 接口
|
||||
- 见 `packages/ui/src/composables/prompt/useEvaluation.ts:274-289` 和 `packages/ui/src/composables/model/useFunctionModelManager.ts:71-83`
|
||||
|
||||
**§4.8 复用 `createApplyImprovementHandler` 工厂方法**
|
||||
- `packages/web/src/App.vue` 和 `packages/extension/src/App.vue` 中的 `handleApplyImprovement` 手动实现替换为 `evaluationHandler.createApplyImprovementHandler(promptPanelRef)`
|
||||
- 消除代码重复，统一行为逻辑，便于后续维护
|
||||
- 见 `packages/web/src/App.vue:1706-1707` 和 `packages/extension/src/App.vue:1706-1707`
|
||||
|
||||
**§4.4 中文变量名回退支持**
|
||||
- `packages/ui/src/components/context-mode/ContextUserWorkspace.vue` 中的变量扫描正则从 `/\{\{(\w+)\}\}/g` 改为 `/\{\{([^{}]+)\}\}/g`
|
||||
- `\w` 仅匹配 ASCII 字母数字，无法匹配中文；改用 `[^{}]+` 匹配任意非花括号字符，支持中文等 Unicode 变量名
|
||||
- 增加 `.trim()` 处理和空值检查，支持 `{{ 变量名 }}` 带空格的写法
|
||||
- 见 `packages/ui/src/components/context-mode/ContextUserWorkspace.vue:406-420`
|
||||
|
||||
**§4.5 单例模式多宿主问题**
|
||||
- 经评估，当前架构下 Web/Extension/Desktop 各自独立进程/页面，不会出现同一页面多宿主的情况
|
||||
- 在 `useFunctionModelManager.ts` 中添加了详细注释，说明单例模式的适用场景和架构约束
|
||||
- 若未来需要多宿主支持，可改用 `resetFunctionModelManagerSingleton()` 重置或改为 keyed 单例
|
||||
- 见 `packages/ui/src/composables/model/useFunctionModelManager.ts:39-55`
|
||||
|
||||
**§4.9 UI 包导出变更影响**
|
||||
- 经检查，`ModelSelectUI` 和 `BasicTestMode` 在整个 `packages` 目录下无任何使用
|
||||
- 这些组件已被删除，移除导出是正确的清理行为，无外部依赖问题
|
||||
|
||||
## 9. 总体结论
|
||||
|
||||
评估功能的主链路已经形成"**core 服务 + 模板策略 + UI 状态机 + 详情/悬浮展示 + 改进建议闭环**"的完整体系，并通过 `useEvaluationHandler` 显著减少了业务层重复接线代码。
|
||||
|
||||
**主要成果**：
|
||||
- 完整的多模式评估支持（basic/pro/image × 各子模式）
|
||||
- 独立的评估模型配置能力
|
||||
- 评估结果到迭代优化的闭环流程
|
||||
- 良好的状态隔离（original/optimized/compare 独立）
|
||||
|
||||
**待改进项**：
|
||||
- ~~**类型安全**：移除 `as any`，完善类型定义（§4.6）~~ ✅ 已修复
|
||||
- ~~**解析鲁棒性**：优化 JSON 提取策略，规范化 boolean 字段（§4.1、§4.2）~~ ✅ 已修复
|
||||
- ~~**代码复用**：复用工厂方法（§4.8）~~ ✅ 已修复
|
||||
- ~~**边界兼容**：支持中文变量名回退扫描（§4.4）~~ ✅ 已修复
|
||||
- ~~**架构约束**：单例模式多宿主问题（§4.5）~~ ✅ 已评估（当前架构无影响）
|
||||
- ~~**导出变更**：确认外部依赖影响（§4.9）~~ ✅ 已确认（无外部依赖）
|
||||
- **代码质量**：拆分过大文件（§4.7）⏸️ 延后处理
|
||||
- ~~**交互一致性**：优化面板打开策略（§4.3）~~ ⏭️ 不修复（计划移除详情面板）
|
||||
@@ -2,7 +2,9 @@
|
||||
|
||||
## 📋 迁移概述
|
||||
|
||||
本次迁移旨在统一项目中的模式术语，将过时的 `optimizationMode`、`contextMode`、`selectedOptimizationMode` 等表达对齐到最新的 `functionMode` 和 `subMode` 设计。
|
||||
本次迁移旨在统一项目中的模式术语，将过时或语义不清的 `optimizationMode`、`contextMode`、`selectedOptimizationMode` 等表达，逐步对齐到 `functionMode`（一级功能模式）与 `subMode`（二级子模式）的设计，并确保各模式的子模式状态独立持久化。
|
||||
|
||||
说明：该文档保留在 `docs/workspace/` 作为“模式术语与迁移现状”的单点入口；其中的“待办/清理项”只保留仍然有效的内容，避免对过往实现阶段产生误导。
|
||||
|
||||
## 🎯 统一设计架构
|
||||
|
||||
@@ -29,6 +31,19 @@ useImageSubMode(services) // 图像模式子模式
|
||||
useCurrentMode() // { functionMode, proSubMode, isBasicMode, ... }
|
||||
```
|
||||
|
||||
## ✅ 当前实现现状（已落地）
|
||||
|
||||
### 1) 主装配位置从 Web/Extension App.vue 收敛到 UI 主组件
|
||||
|
||||
- `packages/web/src/App.vue`、`packages/extension/src/App.vue` 目前仅作为壳组件渲染 UI 主应用。
|
||||
- 真实的模式状态管理与装配已收敛到：
|
||||
- `packages/ui/src/components/app-layout/PromptOptimizerApp.vue`
|
||||
|
||||
### 2) 子模式持久化已实现，且 `selectedOptimizationMode` 已改为 computed（非独立状态源）
|
||||
|
||||
- `PromptOptimizerApp.vue` 使用 `useFunctionMode` + `useBasicSubMode/useProSubMode/useImageSubMode` 管理状态，并做独立持久化。
|
||||
- `selectedOptimizationMode` 不再是独立 `ref`，而是从 subMode 推导的 `computed`（兼容旧接口/props 形态）。
|
||||
|
||||
## ✅ 已完成的迁移
|
||||
|
||||
### 1. Composables 参数统一
|
||||
@@ -42,27 +57,19 @@ useCurrentMode() // { functionMode, proSubMode, isBasicMode, ... }
|
||||
### 3. 文档和注释更新
|
||||
- 为迁移的参数添加 @deprecated 标记
|
||||
- 更新 JSDoc 注释，说明统一使用 subMode 概念
|
||||
- 在 App.vue 中添加兼容性注释
|
||||
- 在 `PromptOptimizerApp.vue` 中保留必要的兼容性注释（以反映真实装配位置）
|
||||
|
||||
## 🔍 仍需迁移的区域
|
||||
|
||||
### 高优先级
|
||||
1. **App.vue 中的 selectedOptimizationMode**
|
||||
```typescript
|
||||
// 当前：仍使用独立的 selectedOptimizationMode ref
|
||||
const selectedOptimizationMode = ref<OptimizationMode>("system");
|
||||
### 高优先级（清理与一致性）
|
||||
1. **逐步移除命名上的“误导”**
|
||||
- `selectedOptimizationMode` 虽已是 computed，但命名仍容易让人误以为它是“用户选择的优化模式状态源”。
|
||||
- 建议方向：
|
||||
- 对外仍可维持 `optimizationMode` props（避免大范围破坏性改动）
|
||||
- 内部逐步改为更准确的命名（例如 `currentOptimizationMode` / `derivedOptimizationMode`），并集中在 UI 层统一出口
|
||||
|
||||
// 建议：改为根据 functionMode 动态获取对应的 subMode
|
||||
const currentSubMode = computed(() => {
|
||||
if (functionMode.value === 'basic') return basicSubMode.value;
|
||||
if (functionMode.value === 'pro') return proSubMode.value;
|
||||
return 'system'; // 默认值
|
||||
});
|
||||
```
|
||||
|
||||
2. **模板中的变量名**
|
||||
- 搜索所有 Vue 模板中的 `selectedOptimizationMode`
|
||||
- 替换为对应的 `basicSubMode`/`proSubMode`
|
||||
2. **组件/模板中的旧名收敛**
|
||||
- 将零散的 `optimizationMode/contextMode/selectedOptimizationMode` 相关命名逐步统一为“functionMode/subMode 派生值”的表达（不强求一次性替换，但要避免继续引入新旧混用）
|
||||
|
||||
### 中优先级
|
||||
3. **类型定义中的过时术语**
|
||||
@@ -79,20 +86,10 @@ useCurrentMode() // { functionMode, proSubMode, isBasicMode, ... }
|
||||
|
||||
## 🚀 迁移建议
|
||||
|
||||
### 阶段 1: 核心逻辑迁移
|
||||
1. 在 App.vue 中移除独立的 `selectedOptimizationMode`
|
||||
2. 使用 `basicSubMode`/`proSubMode` 作为唯一切换源
|
||||
3. 更新所有事件处理器
|
||||
|
||||
### 阶段 2: UI 组件迁移
|
||||
1. 更新所有接收 `selectedOptimizationMode` 的组件
|
||||
2. 改为接收对应的 subMode 或使用 `useCurrentMode()`
|
||||
3. 验证所有功能正常工作
|
||||
|
||||
### 阶段 3: 清理和优化
|
||||
1. 移除所有 @deprecated 标记的代码
|
||||
2. 更新文档和示例
|
||||
3. 添加 ESLint 规则防止回退
|
||||
### 重点方向：以“不破坏行为”为前提做术语清理
|
||||
1. 将“状态源”限定为 `functionMode + 各自 subMode`（已完成）
|
||||
2. 将“对外接口/props”保持可用，同时逐步减少旧命名在内部传播（进行中）
|
||||
3. 等调用方与文档一致后，再移除 `@deprecated` 标记（后续清理）
|
||||
|
||||
## 📝 迁移检查清单
|
||||
|
||||
@@ -101,8 +98,8 @@ useCurrentMode() // { functionMode, proSubMode, isBasicMode, ... }
|
||||
- [x] 更新 useContextManagement 接口
|
||||
- [x] 统一内部变量名
|
||||
- [x] 添加 @deprecated 标记
|
||||
- [ ] 重构 App.vue 中的模式管理
|
||||
- [ ] 更新所有 Vue 模板绑定
|
||||
- [x] 模式管理收敛到 PromptOptimizerApp（由 subMode 推导 optimizationMode）
|
||||
- [ ] 更新所有 Vue 模板/props 命名（逐步收敛，避免引入新旧混用）
|
||||
- [ ] 更新类型定义
|
||||
- [ ] 更新测试文件
|
||||
- [ ] 验证功能完整性
|
||||
@@ -112,17 +109,18 @@ useCurrentMode() // { functionMode, proSubMode, isBasicMode, ... }
|
||||
|
||||
1. **术语统一**: 消除混淆，提高代码可读性
|
||||
2. **架构清晰**: 明确的层级关系（functionMode → subMode）
|
||||
3. **状态隔离**: 不同功能模式的子模式���立持久化
|
||||
3. **状态隔离**: 不同功能模式的子模式独立持久化
|
||||
4. **开发体验**: 统一的 API 和清晰的使用模式
|
||||
|
||||
## 🔗 相关文档
|
||||
|
||||
- [功能模式设计文档](../archives/126-submode-persistence/README.md)
|
||||
- [模式管理 API](../../../packages/ui/src/composables/mode/index.ts)
|
||||
- [迁移最佳实践](../migration/)
|
||||
- [上下文 UI 改造与变量系统重构（归档）](../archives/128-context-ui-and-variable-system-refactor/README.md)
|
||||
|
||||
---
|
||||
|
||||
**文档版本**: v1.0
|
||||
**创建时间**: 2025-10-31
|
||||
**维护者**: Claude & 用户
|
||||
**最近更新**: 2025-12-19
|
||||
**维护者**: 用户
|
||||
@@ -1,270 +0,0 @@
|
||||
# ContextSystemWorkspace vs ContextUserWorkspace 独立性分析
|
||||
|
||||
## 📋 分析目标
|
||||
|
||||
确保 `ContextSystemWorkspace`（上下文-多消息）和 `ContextUserWorkspace`（上下文-单消息）两个组件相互独立，无复用/混淆。
|
||||
|
||||
## 🏗️ 架构对比
|
||||
|
||||
### ContextSystemWorkspace (上下文-多消息模式)
|
||||
|
||||
**职责**:
|
||||
- 管理 system/user/assistant/tool 多条消息
|
||||
- 支持任意消息的选择和优化
|
||||
- 会话级别的上下文管理
|
||||
|
||||
**使用的 Composables**:
|
||||
```typescript
|
||||
import { useConversationTester } from '../../composables/prompt/useConversationTester'
|
||||
import { useConversationOptimization } from '../../composables/prompt/useConversationOptimization'
|
||||
import { usePromptDisplayAdapter } from '../../composables/prompt/usePromptDisplayAdapter'
|
||||
```
|
||||
|
||||
**子组件**:
|
||||
- `ConversationManager` - 多消息管理器
|
||||
- `ConversationTestPanel` - 会话测试面板
|
||||
- `PromptPanelUI` - 优化结果显示（条件渲染）
|
||||
|
||||
**特性**:
|
||||
- ✅ 内部初始化 `conversationOptimization`
|
||||
- ✅ 内部初始化 `conversationTester`
|
||||
- ✅ 内部初始化 `displayAdapter`
|
||||
- ✅ 消息级优化和版本管理
|
||||
- ✅ 完全自包含，不依赖 App.vue 的测试器
|
||||
|
||||
---
|
||||
|
||||
### ContextUserWorkspace (上下文-单消息模式)
|
||||
|
||||
**职责**:
|
||||
- 只优化单条用户消息
|
||||
- 无需管理多轮对话上下文
|
||||
- 支持工具调用配置
|
||||
|
||||
**使用的 Composables**:
|
||||
```typescript
|
||||
import { useTemporaryVariables } from "../../composables/variable/useTemporaryVariables"
|
||||
```
|
||||
|
||||
**子组件**:
|
||||
- `InputPanelUI` - 单消息输入面板
|
||||
- `TestAreaPanel` - 基础测试面板（非会话）
|
||||
- `PromptPanelUI` - 优化结果显示（始终显示）
|
||||
|
||||
**特性**:
|
||||
- ✅ 使用 App.vue 传入的 `promptTester` (usePromptTester)
|
||||
- ✅ 通过 @test 事件触发测试
|
||||
- ✅ 支持文本选择提取变量（独有功能）
|
||||
- ✅ 支持临时变量管理
|
||||
- ✅ 依赖外部测试器（通过事件通信）
|
||||
|
||||
---
|
||||
|
||||
## ✅ 独立性验证
|
||||
|
||||
### 1. Composables 使用情况
|
||||
|
||||
| Composable | ContextSystem | ContextUser | 共享? |
|
||||
|-----------|---------------|-------------|-------|
|
||||
| `useConversationTester` | ✅ | ❌ | ❌ 独立 |
|
||||
| `useConversationOptimization` | ✅ | ❌ | ❌ 独立 |
|
||||
| `usePromptDisplayAdapter` | ✅ | ❌ | ❌ 独立 |
|
||||
| `useTemporaryVariables` | ❌ | ✅ | ❌ 独立 |
|
||||
| `usePromptTester` (App.vue) | ❌ | ✅ (间接) | ❌ 独立 |
|
||||
|
||||
**结论**: ✅ 没有混淆，各自使用专属的 composables
|
||||
|
||||
---
|
||||
|
||||
### 2. 测试逻辑独立性
|
||||
|
||||
**ContextSystemWorkspace**:
|
||||
```typescript
|
||||
// 组件内部
|
||||
const conversationTester = useConversationTester(
|
||||
services || ref(null),
|
||||
selectedTestModel,
|
||||
computed(() => props.optimizationContext),
|
||||
optimizationContextToolsRef,
|
||||
variableManager,
|
||||
selectedMessageId
|
||||
)
|
||||
|
||||
const handleTestWithVariables = async () => {
|
||||
const testVariables = testAreaPanelRef.value?.getVariableValues?.() || {}
|
||||
await conversationTester.executeTest(
|
||||
props.isCompareMode || false,
|
||||
testVariables,
|
||||
testAreaPanelRef.value
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
**ContextUserWorkspace**:
|
||||
```typescript
|
||||
// App.vue
|
||||
const promptTester = usePromptTester(
|
||||
services as any,
|
||||
toRef(modelManager, 'selectedTestModel'),
|
||||
selectedOptimizationMode,
|
||||
variableManager
|
||||
)
|
||||
|
||||
const handleTestAreaTest = async (testVariables?: Record<string, string>) => {
|
||||
await promptTester.executeTest(
|
||||
optimizer.prompt,
|
||||
optimizer.optimizedPrompt,
|
||||
testContent.value,
|
||||
isCompareMode.value,
|
||||
testVariables
|
||||
)
|
||||
}
|
||||
|
||||
// ContextUserWorkspace 组件
|
||||
<ContextUserWorkspace
|
||||
@test="handleTestAreaTest"
|
||||
/>
|
||||
```
|
||||
|
||||
**结论**: ✅ 完全独立的测试逻辑
|
||||
- System: 内部管理，会话级测试
|
||||
- User: 外部管理，单消息测试
|
||||
|
||||
---
|
||||
|
||||
### 3. 优化逻辑独立性
|
||||
|
||||
**ContextSystemWorkspace**:
|
||||
```typescript
|
||||
// 消息级优化
|
||||
const conversationOptimization = useConversationOptimization(...)
|
||||
|
||||
const handleOptimizeClick = () => {
|
||||
conversationOptimization.optimizeMessage() // 优化选中消息
|
||||
}
|
||||
```
|
||||
|
||||
**ContextUserWorkspace**:
|
||||
```typescript
|
||||
// 全局优化（通过 App.vue 的 optimizer）
|
||||
<ContextUserWorkspace
|
||||
@optimize="handleOptimizePrompt" // 触发 App.vue 的优化逻辑
|
||||
/>
|
||||
```
|
||||
|
||||
**结论**: ✅ 完全独立的优化逻辑
|
||||
- System: 消息级优化（内部管理）
|
||||
- User: 全局优化（外部管理）
|
||||
|
||||
---
|
||||
|
||||
### 4. 变量管理独立性
|
||||
|
||||
**ContextSystemWorkspace**:
|
||||
- 使用 App.vue 注入的 `variableManager` (useVariableManager)
|
||||
- 通过 inject 获取，用于会话测试
|
||||
|
||||
**ContextUserWorkspace**:
|
||||
- 使用内部的 `tempVarsManager` (useTemporaryVariables)
|
||||
- 独立管理临时变量
|
||||
- 同时使用 App.vue 传入的 globalVariables 和 predefinedVariables
|
||||
|
||||
**结论**: ✅ 独立但合理共享
|
||||
- System: 依赖全局 variableManager（合理）
|
||||
- User: 独立临时变量 + 全局变量（合理）
|
||||
|
||||
---
|
||||
|
||||
### 5. 子组件独立性
|
||||
|
||||
| 子组件 | ContextSystem | ContextUser | 用途差异 |
|
||||
|--------|---------------|-------------|----------|
|
||||
| ConversationManager | ✅ | ❌ | 多消息管理 |
|
||||
| ConversationTestPanel | ✅ | ❌ | 会话测试 |
|
||||
| InputPanelUI | ❌ | ✅ | 单消息输入 |
|
||||
| TestAreaPanel | ❌ | ✅ | 基础测试 |
|
||||
| PromptPanelUI | ✅ | ✅ | **共享**（合理复用） |
|
||||
|
||||
**结论**: ✅ 独立且合理
|
||||
- 共享 PromptPanelUI 是合理的，因为它只是展示组件
|
||||
|
||||
---
|
||||
|
||||
## 🎯 发现的问题
|
||||
|
||||
### ❌ 无问题！架构清晰且独立
|
||||
|
||||
经过全面分析，**没有发现**以下问题：
|
||||
- ❌ 不应该共享但实际共享的 composables
|
||||
- ❌ 逻辑混淆或职责不清
|
||||
- ❌ 组件间的不当耦合
|
||||
- ❌ 数据流混乱
|
||||
|
||||
---
|
||||
|
||||
## ✅ 架构优点
|
||||
|
||||
### 1. 清晰的关注点分离
|
||||
- **ContextSystemWorkspace**: 完全自包含，负责多消息会话优化
|
||||
- **ContextUserWorkspace**: 依赖外部，负责单消息优化
|
||||
|
||||
### 2. Composables 职责清晰
|
||||
|
||||
```
|
||||
useConversationTester → ContextSystemWorkspace 专用
|
||||
useConversationOptimization → ContextSystemWorkspace 专用
|
||||
usePromptDisplayAdapter → ContextSystemWorkspace 专用
|
||||
useTemporaryVariables → ContextUserWorkspace 专用
|
||||
usePromptTester → ContextUserWorkspace 使用（通过 App.vue）
|
||||
```
|
||||
|
||||
### 3. 合理的复用策略
|
||||
- ✅ 展示组件共享（PromptPanelUI）
|
||||
- ✅ 基础工具共享（variableManager）
|
||||
- ✅ 业务逻辑独立（测试器、优化器）
|
||||
|
||||
---
|
||||
|
||||
## 📊 独立性评分
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|------|------|------|
|
||||
| Composables 独立性 | ⭐⭐⭐⭐⭐ | 完全独立，无混淆 |
|
||||
| 测试逻辑独立性 | ⭐⭐⭐⭐⭐ | 使用不同的测试器 |
|
||||
| 优化逻辑独立性 | ⭐⭐⭐⭐⭐ | 消息级 vs 全局优化 |
|
||||
| 组件职责清晰度 | ⭐⭐⭐⭐⭐ | 职责明确，无重叠 |
|
||||
| 可维护性 | ⭐⭐⭐⭐⭐ | 易于理解和维护 |
|
||||
|
||||
**总评**: ⭐⭐⭐⭐⭐ (5/5)
|
||||
|
||||
---
|
||||
|
||||
## 🚀 建议
|
||||
|
||||
### 无需改进！当前架构已经非常优秀
|
||||
|
||||
两个组件的独立性设计非常好：
|
||||
1. ✅ 各自使用专属的 composables
|
||||
2. ✅ 测试和优化逻辑完全独立
|
||||
3. ✅ 只在合理的地方共享（展示组件）
|
||||
4. ✅ 职责清晰，易于维护
|
||||
|
||||
### 未来扩展建议
|
||||
|
||||
如果要添加新功能，建议遵循当前模式：
|
||||
- **多消息相关**: 添加到 ContextSystemWorkspace 或其专属 composables
|
||||
- **单消息相关**: 添加到 ContextUserWorkspace 或其专属 composables
|
||||
- **共享展示逻辑**: 考虑抽取为独立的展示组件
|
||||
|
||||
---
|
||||
|
||||
## 📝 总结
|
||||
|
||||
**ContextSystemWorkspace** 和 **ContextUserWorkspace** 两个组件：
|
||||
- ✅ 完全独立，无复用/混淆
|
||||
- ✅ 各自使用专属的业务逻辑 composables
|
||||
- ✅ 只在合理的地方共享展示组件
|
||||
- ✅ 架构清晰，职责明确
|
||||
- ✅ 易于维护和扩展
|
||||
|
||||
**结论**: 当前架构非常优秀，无需改进！🎉
|
||||
Reference in new issue
Block a user