intention-coding 0.4.0 → 0.4.3

package/dist/services/requirement-analyzer/prompt/api-template.js

@@ -1,302 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.apiTemplatePrompt = void 0;
-exports.apiTemplatePrompt = `你是一位专业的后端技术文档编写专家。请基于用户提供的输入内容，生成一份完整、详细的API接口技术需求文档。
-
-## 任务要求
-- 必须输出完整的Markdown格式技术需求文档
-- 不要只给出总结，要输出完整的文档内容
-- 每个章节都要有详细的内容，不能省略
-- 文档长度应该在3000字以上
-- 重点描述API接口设计、数据结构、交互逻辑等后端相关内容
-
-## 输入信息
-- **功能名称**: {featureName}
-- **业务领域**: {businessDomain}
-- **生成时序图**: {generateSequenceDiagram}
-
-## 原始需求内容
-\`\`\`
-{inputContent}
-\`\`\`
-
-## 文档结构要求
-请严格按照以下结构输出完整的需求文档，每个章节都要有详实的内容：
-
-# {featureName} - API接口技术需求文档
-
-> **生成时间**: {currentTime}
-> **业务领域**: {businessDomain}
-> **接口类型**: RESTful API
-
----
-
-## 1. 需求背景
-
-**背景**: [详细描述API接口的背景、业务需求和目标]
-
-**关键功能**: [列出API接口的主要功能点]
-
-**涉及角色**: [列出所有相关系统角色]
-
-## 2. {featureName}功能设计说明
-
-| | | | | |
-|---|---|---|---|---|
-|**流程编号**|F001|**流程名称**|{featureName}|
-|**业务功能编号**|BF001|**业务功能名称**|{featureName}|
-|**功能设计编号**|FD001|**系统功能名称**|{featureName}|
-|**前置条件**|[详细描述API调用的前置条件]|
-|**角色（岗位）**|[详细描述调用方角色及其权限]|
-|**入口渠道**|[描述API调用入口]|
-|**功能描述**|[详细的功能描述]|
-|**调用能力域/中心**|[如适用的其他系统接口]|
-
-## 3. 数据建模
-## 3.1 ER逻辑图设计
-
-[描述数据库表之间的关系和ER图设计]
-\`\`\`mermaid
-\`\`\`
-
-## 4. 数据表实体设计
-
-[详细描述涉及的数据表实体结构，包括字段名、类型、约束条件等]
-
-## 5. API接口设计
-
-### 5.1 接口列表
-[列出所有相关的API接口]
-
-### 5.2 接口详细说明
-
-#### 5.2.1 接口1 - [接口名称]
-#### 5.2.2 基本信息
-- **接口地址**: [URL路径]
-- **请求方法**: [只允许使用POST请求]
-- **协议**: [只允许使用HTTPS]
-- **内容类型**: [application/json等]
-
-#### 5.2.3 请求参数
-[详细说明请求参数]
-
-|参数名|类型|是否必填|位置|说明|
-|------|----|--------|----|----|
-|[参数1]|[string/int等]|[是/否]|[query/body/path]|[详细说明]|
-|[参数2]|[string/int等]|[是/否]|[query/body/path]|[详细说明]|
-
-#### 5.2.4 响应参数
-[详细说明响应参数]
-
-|参数名|类型|说明|
-|------|----|----|
-|[参数1]|[string/object等]|[详细说明]|
-|[参数2]|[string/object等]|[详细说明]|
-
-#### 5.2.5 错误码说明
-[详细说明该接口的错误码]
-
-|错误码|说明|
-|------|----|
-|[错误码1]|[详细说明]|
-|[错误码2]|[详细说明]|
-
-#### 5.2.6 详细实现逻辑
-[分步骤详细描述该接口的详细逻辑，如果存在sql语句，需要添加sql语句并在sql语句中添加注释说明]
-
-## 6. 业务对象时序图
-
-#### 6.2.1 正向流程
-\`\`\`mermaid
-sequenceDiagram
-    participant 客户端
-    participant API网关
-    participant 认证服务
-    participant 权限服务
-    participant 业务服务
-    participant 日志服务
-    
-    客户端->>API网关: 发送API请求
-    API网关->>认证服务: 验证请求令牌
-    alt 令牌有效
-        认证服务-->>API网关: 返回认证成功
-        API网关->>权限服务: 检查访问权限
-        权限服务-->>API网关: 返回权限信息
-        API网关->>业务服务: 转发请求
-        业务服务-->>API网关: 返回响应数据
-        API网关->>客户端: 返回响应
-    else 令牌无效
-        认证服务-->>API网关: 返回认证失败
-        API网关->>日志服务: 记录认证失败
-        API网关->>客户端: 返回401错误
-    end
-\`\`\`
-
-### 6.3 异常流程（逻辑中出现异常情况的下的处理）
-
-#### 6.3.1 xx异常处理流程
-\`\`\`mermaid
-sequenceDiagram
-    participant 客户端
-    participant API网关
-    participant 限流服务
-    participant 日志服务
-    
-    客户端->>API网关: 发送API请求
-    API网关->>限流服务: 检查请求频率
-    限流服务-->>API网关: 返回限流决定
-    alt 请求频率正常
-        API网关->>后续服务: 处理请求
-    else 请求频率过高
-        API网关->>日志服务: 记录限流事件
-        API网关->>客户端: 返回429错误(请求过多)
-    end
-\`\`\`
-
-#### 6.3.2 xx异常处理流程
-\`\`\`mermaid
-sequenceDiagram
-    participant 客户端
-    participant API网关
-    participant 业务服务
-    participant 数据验证器
-    participant 日志服务
-    
-    客户端->>API网关: 发送包含无效数据的请求
-    API网关->>业务服务: 转发请求
-    业务服务->>数据验证器: 验证数据格式
-    数据验证器-->>业务服务: 返回验证失败
-    业务服务->>日志服务: 记录验证错误
-    业务服务-->>API网关: 返回400错误(请求数据无效)
-    API网关->>客户端: 返回400错误及错误详情
-\`\`\`
-
-### 6.4 边缘情况流程（并发、超时、数据边界等）
-
-#### 6.4.1 并发冲突处理
-\`\`\`mermaid
-sequenceDiagram
-    participant 客户端
-    participant API网关
-    participant 数据库
-    participant 日志服务
-    participant 缓存服务
-    
-    alt 高并发场景
-        客户端->>API网关: 并发请求
-        API网关->>数据库: 执行数据操作
-        数据库-->>API网关: 返回结果
-        API网关->>缓存服务: 缓存响应数据
-        API网关->>日志服务: 记录并发冲突
-    else 非高并发场景
-        API网关->>数据库: 执行数据操作
-        数据库-->>API网关: 返回结果
-        API网关->>缓存服务: 缓存响应数据
-    end
-    API网关->>客户端: 返回响应
-\`\`\`
-#### 6.4.2 超时处理
-\`\`\`mermaid
-sequenceDiagram
-    participant 客户端
-    participant API网关
-    participant 业务服务
-    participant 日志服务
-    participant 监控服务
-    participant 备用服务
-    
-    客户端->>API网关: 发送包含无效数据的请求
-    API网关->>业务服务: 转发请求
-    业务服务->>日志服务: 记录超时事件
-    业务服务->>监控服务: 上报超时指标
-    业务服务-->>业务服务: 重试请求
-    业务服务-->>API网关: 返回408错误(请求超时)
-    API网关->>备用服务: 转发请求
-    备用服务-->>API网关: 返回错误响应
-    API网关->>日志服务: 日志记录备用服务响应
-    API网关->>监控服务: 记录备用服务失败
-    API网关->>客户端: 返回备用服务响应
-\`\`\`
-
-## 7. 业务状态描述
-
-| | | |
-|---|---|---|
-|**状态编号**|**状态名称**|**描述**|
-|01|收到审核申请|当接收到审核申请时，系统会记录申请信息并返回审核中状态|
-|02|审批审核状态|当审批人对申请进行审批后，系统会更新审核状态并返回审批结果|
-|[添加更多状态...]||
-
-## 8. 伪代码示例
-
-\`\`\`gherkin
-Scenario Outline: 用户通过API查询订单信息
-  Given 用户已通过认证并拥有查询权限
-  When 用户向/orders/<order_id>接口发送POST请求
-  Then 系统应返回订单信息或 <error_message>
-
-  Examples:
-    | order_id | error_message        |
-    | 12345    | null (成功返回订单信息) |
-    | 99999    | "订单不存在"          |
-
-Scenario Outline: API认证与授权流程
-  Given 客户端使用<auth_type>方式进行认证
-  When 客户端访问<api_endpoint>接口时
-  Then 系统应:
-    1. 验证认证凭证的有效性
-    2. 检查用户权限
-    3. 根据验证结果返回相应响应
-
-  Examples:
-    | auth_type | api_endpoint | 预期行为                              |
-    | Bearer Token | /orders     | 验证令牌有效性，检查订单访问权限      |
-    | API Key      | /products   | 验证API Key，检查产品访问权限         |
-    | 无效令牌     | /orders     | 返回401未授权错误                     |
-    | 无权限用户   | /admin      | 返回403禁止访问错误                   |
-
-Scenario Outline: API调用与数据处理流程
-  Given 客户端向<api_endpoint>发送<http_method>请求
-  When 请求包含<data_status>数据时
-  Then 系统应:
-    1. 验证请求参数格式
-    2. 执行业务逻辑处理
-    3. 返回标准化响应格式
-
-  Examples:
-    | api_endpoint | http_method | data_status | 处理逻辑                                       |
-    | /users       | POST        | 有效数据    | 创建新用户，返回用户ID和创建时间              |
-    | /users       | POST        | 缺失必填项  | 返回400错误，详细说明缺失字段                  |
-    | /users/123   | PUT         | 更新数据    | 更新用户信息，返回更新后的完整用户信息        |
-    | /users/123   | DELETE      | 存在资源    | 删除用户，返回204状态码                       |
-    | /users/999   | POST         | 不存在资源  | 返回404错误，说明资源未找到                   |
-    | /users       | POST         | 大量数据    | 分页返回用户列表，包含总数和分页信息           |
-
-Scenario Outline: API限流与错误恢复处理
-  Given 客户端在<time_window>内发送<request_count>个请求
-  When 系统检测到<traffic_pattern>时
-  Then 系统应:
-    1. 应用限流策略控制请求频率
-    2. 返回适当的限流响应码
-    3. 提供重试建议和时间窗口信息
-
-  Examples:
-    | time_window | request_count | traffic_pattern | 限流策略                                   |
-    | 1分钟       | 60个请求      | 正常流量        | 允许请求通过，记录访问日志                  |
-    | 1分钟       | 120个请求     | 突发流量        | 返回429状态码，建议等待30秒后重试           |
-    | 1分钟       | 1000个请求    | 恶意攻击        | 立即拒绝请求，记录IP并触发安全防护机制      |
-    | 5分钟       | 50个请求      | 周期性请求      | 允许请求通过，优化缓存策略提升响应速度      |
-    | 1小时       | 10000个请求   | 正常业务高峰    | 动态调整限流阈值，启用负载均衡策略          |
-\`\`\`
-
----
-
-**重要提醒**: 
-1. 请输出完整的Markdown文档，不要省略任何章节
-2. 每个章节都要有实质性的内容，不能只是模板
-3. 根据输入的原始内容进行具体分析，不要使用通用模板
-4. 文档总长度应该在3000字以上
-5. 表格中的内容要填写具体信息，不要保留占位符
-6. 重点关注API接口设计、数据结构、交互逻辑等技术细节
-
-现在请开始生成完整的API接口技术需求文档：`;