linshen
9a4de02438
此次提交整合了上下文编辑器的大规模重构、废弃组件的清理以及workspace文档的更新，旨在提升系统性能、代码可维护性和开发体验。
### 主要更新
- **上下文编辑器重构**:
- 移除 ConversationMessageEditor, ConversationSection 等废弃组件。
- 清理 ConversationManager 和 ContextEditor 未使用的 props。
- 实现无障碍功能增强和焦点管理。
- 创建新的工具 composables 和组件类型。
- 添加全面的测试覆盖和性能监控。
- **组件与代码清理**:
- 移除重构前的 `VariableManager.vue` 组件及其导出（497行），由 `VariableManagerModal.vue` 替代。
- 删除已废弃的 `AdvancedTestPanel.vue` 组件及其导出，已被 `TestAreaPanel` 统一组件完全替代。
- 清理未使用的 `VariableImportExport.vue` 组件、相关测试文件和类型定义。
- 遵循 YAGNI 原则，确保移除的组件在任何地方均未被使用。
- 构建包大小减少约 55KB（3552KB -> 3497KB）。
- **Workspace文档整合**:
- 归档完整的 Naive UI 迁移项目 (包含8个综合文档)。
- 补充上下文编辑器重构缺失的spec工作流文档。
- 建立 `docs/examples/` 目录提供配置模板。
- 更新归档 `INDEX.md` 多维度快速查找索引。
- 清理 workspace 目录中15个重复文档。
### 技术改进与优化
- 优化 Git 配置，将 `tsconfig.tsbuildinfo` 从追踪中移除并增强 `.gitignore` 规则覆盖所有 `tsbuildinfo` 文件。
- 添加高级 TypeScript 类型和组件接口，实现工具调用显示和变量导入导出组件。
- 增强变量管理与编辑器集成，并保持 `VariableManager.ts` 服务层（仍在使用）。
- 添加全面的单元测试和e2e测试覆盖，改进开发文档和API指南。
- 所有现有功能完整性验证通过，无构建错误或运行时错误。
44 lines
8.3 KiB
JSON
44 lines
8.3 KiB
JSON
[
|
||
{
|
||
"role": "system",
|
||
"content": "# 角色：SQL生成专家\n\n你是一个专业的SQL查询生成专家，能够根据业务问题和数据表结构生成准确、高效的SQL查询语句。\n\n## 任务目标\n根据给定的子问题、表结构信息、对话上下文和依赖关系，生成对应的SQL查询语句。\n\n## 可用工具\n- human_assistance: 与用户交互，询问用户问题\n\n## 智能交互策略 - 谨慎使用原则\n仅在以下情况下使用human_assistance：\n1. 字段含义完全无法从表结构和常识推断，且直接影响SQL的正确性\n2. 存在明显的业务逻辑歧义，有多种合理的解释方式\n3. 涉及特定业务规则的关键参数，如特殊的时间范围定义、状态值含义等\n\n## 无需询问用户的情况：\n- 字段名称和含义相对明确或可通过常识推断\n- 可通过常见业务逻辑推断的查询条件（如按时间、金额、状态筛选）\n- 标准的统计、聚合、排序需求\n- 表结构信息足以支撑SQL生成，即使存在轻微不确定性\n- 问题明确指出了字段名和对应的值\n\n## SQL生成要求\n\n### 1. 语法规范\n- 使用标准SQL语法\n- 字段名和表名使用反引号包围（如果包含特殊字符）\n\n### 2. 查询优化\n- 合理使用索引字段进行筛选\n- 避免全表扫描，添加必要的WHERE条件\n- **多表查询策略**：当问题需要的字段分布在多个表中时，应该使用JOIN或子查询来处理\n- 合理使用JOIN类型（INNER、LEFT、RIGHT等）\n- 对于大表查询，考虑添加LIMIT限制\n\n### 3. 业务逻辑\n- 准确理解业务需求\n- 处理数据类型转换\n- 考虑NULL值处理\n- 时间范围查询使用合适的条件\n\n## 【重要】SQL复杂度判断标准\n- **简单SQL**：满足以下所有条件\n - 单表查询（不包含JOIN）\n - 基础WHERE条件筛选\n - 简单GROUP BY聚合\n - 没有子查询或HAVING子句\n - 没有窗口函数\n - 没有复杂的CASE WHEN逻辑\n \n- **复杂SQL**：满足以下任一条件\n - 包含JOIN操作\n - 包含子查询\n - 包含HAVING子句\n - 使用窗口函数\n - 包含复杂的CASE WHEN逻辑\n - 包含UNION/INTERSECT/EXCEPT操作\n - 使用高级函数如PIVOT、UNPIVOT等\n\n## 【强制】输出格式\n必须严格按照以下JSON格式输出，注意type是固定值：\n\n对于简单SQL（满足上述简单SQL的所有条件）：\n```json\n{\n \"type\": \"sql_generation_result\",\n \"sql\": \"生成的SQL查询语句\",\n \"explanation\": \"\",\n \"table_name_list\": [\"涉及的表名1\", \"涉及的表名2\"]\n}\n```\n\n对于复杂SQL（满足上述复杂SQL的任一条件）：\n```json\n{\n \"type\": \"sql_generation_result\",\n \"sql\": \"生成的SQL查询语句\",\n \"explanation\": \"简要说明关键逻辑（不超过30字）\",\n \"table_name_list\": [\"涉及的表名1\", \"涉及的表名2\"]\n}\n```\n\n【注意】：对于\"SELECT 字段 FROM 表 WHERE 条件 GROUP BY 字段 ORDER BY 字段\"这样的简单查询，必须将explanation设为空字符串。\n\n## 【重要】明确查询直接生成规则\n当遇到以下情况时，应该直接生成SQL语句而不是使用human_assistance工具：\n1. 查询涉及的字段在表结构中明确存在\n2. 查询条件是简单的精确匹配或常见的业务筛选条件\n3. 业务逻辑清晰，没有明显歧义\n4. 表结构信息充足，能够完全支撑SQL生成\n5. 查询语句中明确指出了字段名和对应的值，如\"字段为XXX的记录\"\n6. 不包含模糊性词汇，如\"可能\"、\"大概\"、\"左右\"等\n7. 不涉及需要特殊业务规则澄清的复杂术语\n8. 可通过常识和表结构信息推断出查询意图的情况\n\n## 优先直接生成SQL的场景：\n- 统计类查询：COUNT、SUM、AVG等聚合函数\n- 排序查询：ORDER BY + LIMIT 的排名查询\n- 简单筛选：基于明确字段值的WHERE条件\n- 分组统计：GROUP BY + 聚合函数的统计需求\n- 时间范围查询：基于日期/时间字段的筛选\n/no_think"
|
||
},
|
||
{
|
||
"role": "user",
|
||
"content": "广东城际铁路经办的合同有多少？"
|
||
},
|
||
{
|
||
"role": "user",
|
||
"content": "广东城际铁路经办的合同有多少？"
|
||
},
|
||
{
|
||
"role": "assistant",
|
||
"content": "```json\n{\n \"type\": \"check_if_need_split_response\",\n \"need_split\": false\n}\n```"
|
||
},
|
||
{
|
||
"role": "user",
|
||
"content": "## 可用表信息\n=== 数据库表结构信息 ===\n【表名】: ai_v_ht_contract_info (合同信息)\n【表描述】: 合同\n\n【字段信息】:\n- 合同编号 (string)\n- 经办人姓名 (string)\n- 合同状态名称 (string)\n- 经办总部 (string)\n- 合同状态代号 (string)\n- 合同总金额 (float)\n- 合同名称 (string): 定义合同的名称、项目的名称 [取值范围: 字符串，少于200个字符]\n- 合同年度 (integer)\n- 签署日期 (datetime)\n\n## 当前要处理的子问题信息\n- **问题ID**: 1\n- **问题**: 广东城际铁路经办的合同有多少？\n- **目的**: \n- **主要涉及的表**: \n- **预期结果**: \n- **业务上下文**: 无\n\n\n\n\n\n## 【重要】输出要求\n请基于以上信息生成对应的SQL查询语句，并严格遵循以下规则：\n\n1. 对于简单SQL（单表查询+基础WHERE条件+简单GROUP BY），必须将explanation设为空字符串(\"\")\n2. 对于复杂SQL（包含JOIN/子查询/窗口函数等），简要提供关键逻辑说明（不超过30字）\n3. 必须在table_name_list中列出SQL涉及的所有表名\n\n## 【重要】明确查询处理指导\n请特别注意以下几点：\n1. 如果问题中明确指出了字段名和值，应直接生成精确匹配的SQL\n2. 字段含义能从表结构或常识推断的，直接生成SQL，无需询问用户\n3. 对于标准的业务查询（统计、排序、筛选），优先直接生成而非询问\n4. 只有在问题确实存在无法推断的业务规则歧义时才使用human_assistance工具\n5. 对于直接的统计类问题（如\"有多少\"、\"总计\"等），应优先考虑使用COUNT函数\n6. 确保生成的SQL能够准确回答用户问题，不要添加不必要的条件或复杂性\n\n## 直接生成SQL的典型示例：\n- \"查询2024年的合同数量\" → 直接基于年份字段生成COUNT查询\n- \"按部门统计员工数量\" → 直接生成GROUP BY + COUNT查询 \n- \"找出销售额最高的前10个客户\" → 直接生成ORDER BY + LIMIT查询\n- \"统计每个月的订单金额\" → 直接生成按月份分组的SUM查询\n- \"查询用户及其订单信息\" → 如果用户信息在user表，订单信息在order表，使用JOIN查询\n- \"查询产品销量排名\" → 如果需要产品名(product表)和销量(order表)，使用JOIN或子查询\n\n## 多表查询处理策略：\n- **字段分布分析**：首先分析问题需要的字段分布在哪些表中\n- **关联关系识别**：识别表之间的关联字段（如外键关系）\n- **JOIN策略**：优先使用JOIN来关联多个表获取所需字段\n- **子查询策略**：当JOIN复杂时，可以使用子查询来简化逻辑\n\n例如，对于\"SELECT 经办人姓名, COUNT(*) FROM 合同信息 WHERE 条件 GROUP BY 经办人姓名\"这样的简单查询，必须输出：\n```json\n{\n \"type\": \"sql_generation_result\",\n \"sql\": \"SELECT 经办人姓名, COUNT(*) AS 合同数量 FROM 合同信息 WHERE 合同年度 = 2024 GROUP BY 经办人姓名 ORDER BY 合同数量 DESC\",\n \"explanation\": \"\",\n \"table_name_list\": [\"合同信息\"]\n}\n```/no_think"
|
||
},
|
||
{
|
||
"role": "tool",
|
||
"content": {
|
||
"type": "function",
|
||
"function": {
|
||
"name": "human_assistance",
|
||
"description": "此工具用于与用户交互、询问，当遇到不能理解或模糊不清的问题时，请调用此工具询问用户，并根据用户回答更新问题。",
|
||
"parameters": {
|
||
"properties": {
|
||
"query": {
|
||
"description": "询问用户的语句",
|
||
"type": "string"
|
||
}
|
||
},
|
||
"required": [
|
||
"query"
|
||
],
|
||
"type": "object"
|
||
}
|
||
}
|
||
}
|
||
}
|
||
] |