python/finyx_data_frontend

Fork 0

李季 0891e67715 完成初版功能页面，提交更新。

2026-01-11 08:26:28 +08:00

27 KiB

Raw Blame History

数据资产盘点工作总结报告 - 大模型接口设计文档

📋 文档说明

本文档详细说明如何通过大模型对话接口生成数据资产盘点工作总结报告页面的内容数据，包括接口数据格式设计、提示词工程方案以及可行性评估。

🎯 页面概述

页面路径: src/pages/engagement/DeliveryStep.vue

页面功能: 展示数据资产盘点工作的完整总结报告，包含企业数字化情况、数据资源统计、数据资产盘点结果以及专家建议。

页面复杂度: ⭐⭐⭐⭐ (较高)

📊 页面数据结构分析

1. 报告头部信息

interface ReportHeader {
  reportDate: string        // 报告生成时间，格式：YYYY年MM月DD日 HH:mm
  projectName: string       // 项目名称
}

数据来源:

reportDate: 前端自动生成（当前时间）
projectName: 需要从项目配置或大模型返回

2. 章节导航

interface Section {
  id: number
  title: string
}

const sections: Section[] = [
  { id: 1, title: '企业数字化情况简介' },
  { id: 2, title: '数据资源统计' },
  { id: 3, title: '数据资产情况盘点' },
  { id: 4, title: '专家建议与下一步计划' }
]

数据来源: 固定结构，无需大模型生成

3. 章节一：企业数字化情况简介

interface Section1 {
  enterpriseBackground: {
    description: string      // 企业背景描述（1-2段文字）
  }
  informatizationStatus: {
    overview: string         // 信息化建设现状概述
    privateCloud: {
      title: string
      description: string
    }
    publicCloud: {
      title: string
      description: string
    }
  }
  businessDataFlow: {
    overview: string         // 业务流与数据流概述
    manufacturing: {
      title: string
      description: string
    }
    logistics: {
      title: string
      description: string
    }
    retail: {
      title: string
      description: string
    }
    dataAggregation: {
      title: string
      description: string
    }
  }
}

复杂度: ⭐⭐⭐ (中等)

需要生成3个主要部分的描述性文本
文本需要专业、准确、符合企业实际情况

4. 章节二：数据资源统计

interface Section2 {
  summary: {
    totalDataVolume: string      // 数据总量，如 "58 PB"
    totalDataObjects: {
      tables: string              // 数据表数量，如 "14,582 张表"
      fields: string              // 字段数量，如 "24.5万+ 字段"
    }
  }
  storageDistribution: Array<{
    category: string              // 分类名称，如 "供应链物流"
    volume: string                // 数据量，如 "25.4 PB"
    storageType: string           // 存储类型描述，如 "主要存储于 HDFS / NoSQL"
    color: 'blue' | 'purple' | 'amber' | 'gray'  // 用于UI显示的颜色标识
  }>
  dataSourceStructure: {
    structured: {
      percentage: number          // 百分比，如 35
      description: string         // 描述文本
    }
    semiStructured: {
      percentage: number          // 百分比，如 65
      description: string         // 描述文本
    }
  }
}

复杂度: ⭐⭐⭐⭐ (较高)

需要生成准确的统计数据（数据量、百分比）
数据需要符合逻辑（百分比总和应为100%）
需要生成多个分类的存储分布数据

5. 章节三：数据资产情况盘点

interface DataAsset {
  id: string                      // 资产ID，如 "customer360", "inventory"
  title: string                   // 资产名称，如 "消费者全景画像"
  subtitle: string                // 副标题，如 "Customer 360"
  composition: {
    description: string           // 资产构成描述
    coreTables: string[]          // 核心表名列表
  }
  applicationScenarios: {
    description: string           // 应用场景描述
  }
  complianceRisks: {
    warnings: Array<{
      type: string                // 风险类型，如 "个人信息预警"
      content: string             // 风险描述
      highlights?: string[]       // 需要高亮的关键信息
    }>
  }
}

interface Section3 {
  overview: {
    assetCount: number            // 识别出的数据资产数量
    highValueAssets: string[]     // 高价值资产名称列表
    description: string           // 概述描述
  }
  assets: DataAsset[]             // 数据资产列表（通常2-3个）
}

复杂度: ⭐⭐⭐⭐⭐ (很高)

需要识别和描述具体的数据资产
需要生成详细的合规风险分析
需要引用具体的表名和字段
需要符合数据合规法规要求

6. 章节四：专家建议与下一步计划

interface Section4 {
  complianceRemediation: {
    title: string                 // "合规整改"
    items: Array<{
      order: number               // 序号
      category: string            // 分类，如 "跨境传输"
      description: string         // 详细建议
      codeReferences?: string[]   // 涉及的表名或代码引用
    }>
  }
  technicalEvolution: {
    title: string                 // "技术演进"
    description: string           // 技术建议描述
    technologies?: string[]       // 推荐的技术栈
  }
  valueDeepening: {
    title: string                 // "价值深化"
    items: Array<{
      description: string         // 建议描述
      scenarios?: string[]        // 相关场景
    }>
  }
}

复杂度: ⭐⭐⭐⭐ (较高)

需要生成专业的建议和计划
建议需要具有可操作性
需要引用前面章节提到的资产和问题

🔌 大模型接口数据格式设计

接口请求格式

interface GenerateReportRequest {
  // 项目基础信息
  projectInfo: {
    projectName: string
    industry: string              // 行业类型
    companyName?: string           // 企业名称（可选）
  }
  
  // 数据盘点结果（从盘点步骤获取）
  inventoryData: {
    totalTables: number            // 总表数
    totalFields: number            // 总字段数
    totalDataVolume: string        // 总数据量
    storageDistribution: Array<{
      category: string
      volume: string
      storageType: string
    }>
    dataSourceStructure: {
      structured: number
      semiStructured: number
    }
    identifiedAssets: Array<{
      name: string
      coreTables: string[]
      description: string
    }>
  }
  
  // 背景调研信息（从背景调研步骤获取）
  contextData: {
    enterpriseBackground: string
    informatizationStatus: string
    businessFlow: string
  }
  
  // 价值挖掘结果（从价值挖掘步骤获取）
  valueData: {
    selectedScenarios: Array<{
      name: string
      description: string
    }>
  }
  
  // 可选配置
  options?: {
    language?: 'zh-CN' | 'en-US'   // 语言，默认 zh-CN
    detailLevel?: 'brief' | 'standard' | 'detailed'  // 详细程度
    focusAreas?: string[]           // 重点关注领域
  }
}

接口返回格式

interface GenerateReportResponse {
  success: boolean
  data?: {
    // 报告头部
    header: {
      projectName: string
      // reportDate 由前端生成，不需要返回
    }
    
    // 章节一：企业数字化情况简介
    section1: {
      enterpriseBackground: {
        description: string
      }
      informatizationStatus: {
        overview: string
        privateCloud: {
          title: string
          description: string
        }
        publicCloud: {
          title: string
          description: string
        }
      }
      businessDataFlow: {
        overview: string
        manufacturing: {
          title: string
          description: string
        }
        logistics: {
          title: string
          description: string
        }
        retail: {
          title: string
          description: string
        }
        dataAggregation: {
          title: string
          description: string
        }
      }
    }
    
    // 章节二：数据资源统计
    section2: {
      summary: {
        totalDataVolume: string
        totalDataObjects: {
          tables: string
          fields: string
        }
      }
      storageDistribution: Array<{
        category: string
        volume: string
        storageType: string
        color: 'blue' | 'purple' | 'amber' | 'gray'
      }>
      dataSourceStructure: {
        structured: {
          percentage: number
          description: string
        }
        semiStructured: {
          percentage: number
          description: string
        }
      }
    }
    
    // 章节三：数据资产情况盘点
    section3: {
      overview: {
        assetCount: number
        highValueAssets: string[]
        description: string
      }
      assets: Array<{
        id: string
        title: string
        subtitle: string
        composition: {
          description: string
          coreTables: string[]
        }
        applicationScenarios: {
          description: string
        }
        complianceRisks: {
          warnings: Array<{
            type: string
            content: string
            highlights?: string[]
          }>
        }
      }>
    }
    
    // 章节四：专家建议与下一步计划
    section4: {
      complianceRemediation: {
        title: string
        items: Array<{
          order: number
          category: string
          description: string
          codeReferences?: string[]
        }>
      }
      technicalEvolution: {
        title: string
        description: string
        technologies?: string[]
      }
      valueDeepening: {
        title: string
        items: Array<{
          description: string
          scenarios?: string[]
        }>
      }
    }
  }
  error?: {
    code: string
    message: string
  }
}

JSON Schema 示例

{
  "type": "object",
  "required": ["success", "data"],
  "properties": {
    "success": {
      "type": "boolean"
    },
    "data": {
      "type": "object",
      "required": ["header", "section1", "section2", "section3", "section4"],
      "properties": {
        "header": {
          "type": "object",
          "properties": {
            "projectName": {
              "type": "string"
            }
          }
        },
        "section1": {
          "type": "object",
          "properties": {
            "enterpriseBackground": {
              "type": "object",
              "properties": {
                "description": {
                  "type": "string",
                  "minLength": 100
                }
              }
            }
            // ... 其他属性
          }
        }
        // ... 其他章节
      }
    }
  }
}

💬 提示词工程设计方案

1. 系统提示词（System Prompt）

你是一位专业的数据资产管理咨询专家，擅长撰写数据资产盘点工作总结报告。你的任务是基于提供的数据盘点结果、企业背景信息和价值挖掘场景，生成一份专业、准确、符合数据合规要求的工作总结报告。

## 你的专业能力
- 深入理解数据资产管理、数据合规（PIPL、数据安全法）等法规要求
- 熟悉企业数字化转型、数据架构设计、数据治理最佳实践
- 能够识别数据资产价值、合规风险，并提供专业建议
- 具备优秀的报告撰写能力，能够生成结构清晰、逻辑严谨的专业报告

## 输出要求
1. **准确性**：所有统计数据必须基于输入数据，不得虚构
2. **专业性**：使用专业术语，符合行业标准
3. **合规性**：合规风险分析必须符合中国数据保护法规要求
4. **可操作性**：专家建议必须具体、可执行
5. **结构化**：严格按照JSON格式输出，确保数据结构完整

## 输出格式
请严格按照提供的JSON Schema格式输出，确保：
- 所有必需字段都存在
- 字符串长度符合要求（描述性文本不少于100字）
- 数字和百分比符合逻辑（百分比总和为100%）
- 数组元素数量合理（数据资产通常2-4个）

2. 用户提示词模板（User Prompt Template）

请基于以下信息生成数据资产盘点工作总结报告：

## 项目信息
- 项目名称：{projectName}
- 行业类型：{industry}
- 企业名称：{companyName}

## 数据盘点结果
### 数据规模
- 总数据量：{totalDataVolume}
- 数据表数量：{totalTables} 张
- 字段数量：{totalFields} 个

### 存储分布
{storageDistribution}

### 数据来源结构
- 结构化数据：{structuredPercentage}%
- 半结构化与非结构化数据：{semiStructuredPercentage}%

### 识别的数据资产
{identifiedAssets}

## 企业背景信息
{enterpriseBackground}

## 信息化建设现状
{informatizationStatus}

## 业务流与数据流
{businessFlow}

## 价值挖掘场景
{selectedScenarios}

## 输出要求
1. 生成完整的报告内容，包含四个主要章节
2. 对于数据资产，需要详细分析其构成、应用场景和合规风险
3. 合规风险分析必须识别：
   - 个人信息（SPI）风险
   - 重要数据风险
   - 数据出境风险
   - 数据安全风险
4. 专家建议需要针对识别出的问题提供具体、可操作的解决方案
5. 所有描述性文本需要专业、准确，符合企业实际情况

请以JSON格式输出，严格按照以下结构：
{jsonSchema}

3. 提示词优化策略

3.1 分阶段生成策略

由于报告内容复杂，建议采用分阶段生成策略：

阶段一：生成章节一和章节二

请基于企业背景和数据盘点结果，生成报告的前两个章节：
1. 企业数字化情况简介
2. 数据资源统计

重点关注：
- 企业背景描述要准确反映实际情况
- 数据统计要基于输入数据，确保准确性

阶段二：生成章节三

基于已识别的数据资产，生成详细的资产盘点分析。

对于每个数据资产，需要：
1. 详细描述资产构成（核心表、字段、数据来源）
2. 说明应用场景和价值
3. 识别合规风险（必须符合PIPL、数据安全法等要求）
4. 提供风险等级评估

阶段三：生成章节四

基于前面章节的分析结果，生成专家建议和下一步计划。

建议需要：
1. 针对识别出的合规风险提供整改方案
2. 提供技术演进建议（架构优化、技术选型）
3. 提供价值深化建议（场景优化、数据应用）

3.2 少样本学习（Few-Shot Learning）

在提示词中提供示例，帮助模型理解输出格式：

## 输出示例

### 数据资产示例
{
  "id": "customer360",
  "title": "消费者全景画像",
  "subtitle": "Customer 360",
  "composition": {
    "description": "核心依赖 Dim_Customer（客户维度表）与 Fact_Sales（销售事实表），并整合了线上电商ID、线下门店会员卡号及社交媒体账号。",
    "coreTables": ["Dim_Customer", "Fact_Sales"]
  },
  "applicationScenarios": {
    "description": "旨在构建OneID体系，支持计算客户生命周期价值（CLV），进行精准营销（如针对流失风险自动触发挽留策略），提升复购率。"
  },
  "complianceRisks": {
    "warnings": [
      {
        "type": "个人信息预警",
        "content": "共识别出 12 项敏感个人信息（SPI），包含生物识别信息（人脸）、医疗健康（体检报告）、金融账户及行踪轨迹。",
        "highlights": ["12 项", "敏感个人信息", "SPI"]
      }
    ]
  }
}

3.3 约束条件明确化

在提示词中明确约束条件：

## 重要约束
1. **数据准确性**：
   - 所有统计数据必须基于输入数据
   - 不得虚构或夸大数据
   - 百分比总和必须为100%

2. **合规性要求**：
   - 必须识别所有涉及个人信息的场景
   - 必须识别重要数据（涉及国家安全、公共利益）
   - 必须识别数据出境风险
   - 风险描述必须符合PIPL、数据安全法等法规

3. **专业性要求**：
   - 使用专业术语（如：数据湖、数据仓库、星型架构等）
   - 技术建议需要具体（如：Iceberg、Hudi等具体技术）
   - 避免使用模糊表述

4. **可操作性要求**：
   - 专家建议必须具体、可执行
   - 需要提供实施步骤或技术方案
   - 需要引用具体的表名、字段名

4. 提示词变量替换

在实际调用时，需要将模板中的变量替换为实际值：

function buildPrompt(request: GenerateReportRequest): string {
  const template = `
请基于以下信息生成数据资产盘点工作总结报告：

## 项目信息
- 项目名称：${request.projectInfo.projectName}
- 行业类型：${request.projectInfo.industry}
${request.projectInfo.companyName ? `- 企业名称：${request.projectInfo.companyName}` : ''}

## 数据盘点结果
### 数据规模
- 总数据量：${request.inventoryData.totalDataVolume}
- 数据表数量：${request.inventoryData.totalTables} 张
- 字段数量：${request.inventoryData.totalFields} 个

### 存储分布
${request.inventoryData.storageDistribution.map(item => 
  `- ${item.category}：${item.volume}（${item.storageType}）`
).join('\n')}

### 数据来源结构
- 结构化数据：${request.inventoryData.dataSourceStructure.structured}%
- 半结构化与非结构化数据：${request.inventoryData.dataSourceStructure.semiStructured}%

### 识别的数据资产
${request.inventoryData.identifiedAssets.map(asset => 
  `- ${asset.name}：${asset.description}\n  核心表：${asset.coreTables.join('、')}`
).join('\n')}

## 企业背景信息
${request.contextData.enterpriseBackground}

## 信息化建设现状
${request.contextData.informatizationStatus}

## 业务流与数据流
${request.contextData.businessFlow}

## 价值挖掘场景
${request.valueData.selectedScenarios.map(scenario => 
  `- ${scenario.name}：${scenario.description}`
).join('\n')}

## 输出要求
1. 生成完整的报告内容，包含四个主要章节
2. 对于数据资产，需要详细分析其构成、应用场景和合规风险
3. 合规风险分析必须识别个人信息、重要数据、数据出境等风险
4. 专家建议需要针对识别出的问题提供具体、可操作的解决方案
5. 所有描述性文本需要专业、准确，符合企业实际情况

请以JSON格式输出，严格按照提供的JSON Schema结构。
  `
  
  return template
}

✅ 可行性评估

1. 复杂度分析

章节	复杂度	大模型生成难度	可行性
章节一：企业数字化情况简介	⭐⭐⭐	中等	✅ 可行
章节二：数据资源统计	⭐⭐⭐⭐	较高	✅ 可行（需验证数据准确性）
章节三：数据资产情况盘点	⭐⭐⭐⭐⭐	很高	⚠️ 需要高质量输入数据
章节四：专家建议与下一步计划	⭐⭐⭐⭐	较高	✅ 可行

2. 技术可行性

✅ 可行的部分

文本生成（章节一、部分章节四）
- 大模型擅长生成描述性文本
- 可以基于企业背景信息生成专业描述
- 难度：低
结构化数据生成（章节二）
- 可以基于输入数据生成统计数据
- 需要确保数据逻辑正确性
- 难度：中
专业建议生成（章节四）
- 大模型具备专业知识，可以生成专业建议
- 需要结合前面章节的分析结果
- 难度：中

⚠️ 需要特别注意的部分

数据资产合规风险分析（章节三）
- 挑战：
  - 需要准确识别合规风险（PIPL、数据安全法）
  - 需要引用具体的表名、字段名
  - 风险描述必须准确、专业
- 解决方案：
  - 在提示词中明确合规要求
  - 提供合规风险检查清单
  - 使用少样本学习提供示例
  - 考虑使用专门的合规分析模型或规则引擎
数据准确性验证（章节二）
- 挑战：
  - 统计数据必须准确
  - 百分比总和必须为100%
  - 数据量单位必须一致
- 解决方案：
  - 在提示词中明确约束条件
  - 后端验证数据逻辑
  - 使用JSON Schema验证

3. 实施建议

方案一：全量生成（推荐用于MVP）

优点：

实现简单，一次调用生成完整报告
用户体验好，等待时间短

缺点：

如果某个章节生成质量不佳，需要重新生成整个报告
Token消耗较大

适用场景：

报告内容相对简单
对生成速度要求高
可以接受一定的质量波动

方案二：分阶段生成（推荐用于生产环境）

优点：

可以针对每个章节优化提示词
如果某个章节生成失败，只需重新生成该章节
可以逐步展示内容，提升用户体验
便于质量控制和人工审核

缺点：

需要多次API调用
实现复杂度较高
需要考虑章节间的依赖关系

实施步骤：

生成章节一和章节二（基于盘点数据）
生成章节三（基于识别的数据资产）
生成章节四（基于前面章节的分析结果）

方案三：混合生成（推荐）

策略：

章节一、二、四：大模型生成
章节三：大模型生成 + 规则引擎验证

实施：

使用大模型生成章节三的初稿
使用规则引擎验证合规风险分析的准确性
如果验证失败，调整提示词重新生成

4. 质量保证措施

4.1 输入数据验证

function validateInputData(request: GenerateReportRequest): ValidationResult {
  const errors: string[] = []
  
  // 验证数据盘点结果
  if (!request.inventoryData.totalTables || request.inventoryData.totalTables <= 0) {
    errors.push('数据表数量必须大于0')
  }
  
  // 验证百分比总和
  const { structured, semiStructured } = request.inventoryData.dataSourceStructure
  if (structured + semiStructured !== 100) {
    errors.push('数据来源结构百分比总和必须为100%')
  }
  
  // 验证数据资产
  if (!request.inventoryData.identifiedAssets || request.inventoryData.identifiedAssets.length === 0) {
    errors.push('必须至少识别一个数据资产')
  }
  
  return {
    valid: errors.length === 0,
    errors
  }
}

4.2 输出数据验证

function validateOutputData(response: GenerateReportResponse): ValidationResult {
  const errors: string[] = []
  
  if (!response.data) {
    return { valid: false, errors: ['响应数据为空'] }
  }
  
  // 验证章节二：百分比总和
  const { structured, semiStructured } = response.data.section2.dataSourceStructure
  if (structured.percentage + semiStructured.percentage !== 100) {
    errors.push('数据来源结构百分比总和必须为100%')
  }
  
  // 验证章节三：数据资产数量
  if (!response.data.section3.assets || response.data.section3.assets.length === 0) {
    errors.push('必须至少包含一个数据资产')
  }
  
  // 验证文本长度
  if (response.data.section1.enterpriseBackground.description.length < 100) {
    errors.push('企业背景描述长度不足')
  }
  
  return {
    valid: errors.length === 0,
    errors
  }
}

4.3 合规风险验证

interface ComplianceRisk {
  type: 'personalInfo' | 'importantData' | 'crossBorder' | 'dataSecurity'
  severity: 'high' | 'medium' | 'low'
  description: string
}

function validateComplianceRisks(assets: DataAsset[]): ComplianceValidationResult {
  const issues: string[] = []
  
  for (const asset of assets) {
    // 检查是否包含个人信息风险分析
    const hasPersonalInfoRisk = asset.complianceRisks.warnings.some(
      w => w.type.includes('个人信息') || w.type.includes('SPI')
    )
    
    if (!hasPersonalInfoRisk && asset.title.includes('客户') || asset.title.includes('用户')) {
      issues.push(`${asset.title} 可能涉及个人信息，但未识别相关风险`)
    }
    
    // 检查风险描述是否具体
    for (const warning of asset.complianceRisks.warnings) {
      if (warning.content.length < 50) {
        issues.push(`${asset.title} 的风险描述过于简单`)
      }
    }
  }
  
  return {
    valid: issues.length === 0,
    issues
  }
}

5. 错误处理策略

interface ErrorHandlingStrategy {
  // 重试策略
  retry: {
    maxAttempts: number        // 最大重试次数，默认3次
    backoff: 'exponential'    // 退避策略：指数退避
    retryableErrors: string[] // 可重试的错误类型
  }
  
  // 降级策略
  fallback: {
    useTemplate: boolean       // 是否使用模板作为降级方案
    templatePath: string       // 模板文件路径
    partialGeneration: boolean // 是否允许部分生成（生成部分章节）
  }
  
  // 人工审核
  review: {
    requireReview: boolean     // 是否需要人工审核
    reviewThreshold: number   // 审核阈值（置信度低于此值需要审核）
  }
}

🚀 实施路线图

阶段一：MVP实现（2-3周）

目标：实现基本的报告生成功能

任务：

✅ 设计接口数据格式
✅ 设计提示词模板
✅ 实现基础的大模型调用
✅ 实现数据验证
✅ 前端集成

验收标准：

能够生成完整的报告内容
数据格式正确
基本的数据验证通过

阶段二：质量优化（2-3周）

目标：提升生成质量和准确性

任务：

✅ 优化提示词（少样本学习、约束条件）
✅ 实现分阶段生成
✅ 实现合规风险验证
✅ 实现错误处理和重试机制
✅ 添加人工审核流程

验收标准：

生成内容专业、准确
合规风险分析准确
统计数据逻辑正确

阶段三：性能优化（1-2周）

目标：优化生成速度和用户体验

任务：

✅ 实现流式输出（逐步展示内容）
✅ 优化Token使用（减少不必要的上下文）
✅ 实现缓存机制（相同输入复用结果）
✅ 优化错误提示和用户反馈

验收标准：

生成时间 < 30秒
用户体验流畅
错误提示清晰

📝 注意事项

1. 数据隐私和安全

敏感信息处理：确保输入数据中的敏感信息（如企业名称、具体数据）不会泄露
数据脱敏：在调用大模型API前，对敏感数据进行脱敏处理
API安全：使用安全的API调用方式，避免API密钥泄露

2. 成本控制

Token优化：优化提示词，减少不必要的Token消耗
缓存策略：对相同输入进行缓存，避免重复调用
模型选择：根据需求选择合适的模型（平衡成本和质量）

3. 可维护性

提示词版本管理：使用版本控制管理提示词
配置化：将提示词模板配置化，便于调整
监控和日志：记录API调用日志，便于问题排查

4. 用户体验

加载状态：显示生成进度和预计时间
错误提示：提供清晰的错误信息和解决建议
预览功能：允许用户预览生成内容后再确认

📚 参考资源

大模型API文档

OpenAI API: https://platform.openai.com/docs
文心一言 API: https://cloud.baidu.com/product/wenxinworkshop
通义千问 API: https://help.aliyun.com/zh/model-studio/

数据合规法规

《个人信息保护法》(PIPL)
《数据安全法》
《网络安全法》

提示词工程

OpenAI Prompt Engineering Guide: https://platform.openai.com/docs/guides/prompt-engineering
LangChain Prompt Templates: https://python.langchain.com/docs/modules/model_io/prompts/

📅 更新记录

2025-01-XX: 初始版本创建

👥 贡献者

Finyx AI Team

27 KiB Raw Blame History Unescape Escape

数据资产盘点工作总结报告 - 大模型接口设计文档

📋 文档说明

🎯 页面概述

📊 页面数据结构分析

1. 报告头部信息

2. 章节导航

3. 章节一：企业数字化情况简介

4. 章节二：数据资源统计

5. 章节三：数据资产情况盘点

6. 章节四：专家建议与下一步计划

🔌 大模型接口数据格式设计

接口请求格式

接口返回格式

JSON Schema 示例

💬 提示词工程设计方案

1. 系统提示词（System Prompt）

2. 用户提示词模板（User Prompt Template）

3. 提示词优化策略

3.1 分阶段生成策略

3.2 少样本学习（Few-Shot Learning）

3.3 约束条件明确化

4. 提示词变量替换

✅ 可行性评估

1. 复杂度分析

2. 技术可行性

✅ 可行的部分

⚠️ 需要特别注意的部分

3. 实施建议

方案一：全量生成（推荐用于MVP）

方案二：分阶段生成（推荐用于生产环境）

方案三：混合生成（推荐）

4. 质量保证措施

4.1 输入数据验证

4.2 输出数据验证

4.3 合规风险验证

5. 错误处理策略

🚀 实施路线图

阶段一：MVP实现（2-3周）

阶段二：质量优化（2-3周）

阶段三：性能优化（1-2周）

📝 注意事项

1. 数据隐私和安全

2. 成本控制

3. 可维护性

4. 用户体验

📚 参考资源

大模型API文档

数据合规法规

提示词工程

📅 更新记录

👥 贡献者

27 KiB

Raw Blame History