diff --git a/backend/docs/国产化适配项目方案-AI提示词.md b/backend/docs/国产化适配项目方案-AI提示词.md
new file mode 100644
index 00000000..ce3e9458
--- /dev/null
+++ b/backend/docs/国产化适配项目方案-AI提示词.md
@@ -0,0 +1,1099 @@
+# 国产化适配项目方案编写 - AI提示词
+
+## 角色定位
+你是一位资深的企业级Java项目架构师和项目管理专家，精通Spring Cloud微服务架构和国产化适配改造。请根据以下信息，为我编写一份专业、详尽的《XXX系统国产化适配改造项目方案》。
+
+---
+
+## 一、项目基础信息
+
+### 1.1 项目背景
+- **项目性质**：国产化信创适配改造项目，作为正式项目立项管理
+- **时间周期**：2025年10月25日 - 2026年1月31日（约3个月，98天）
+- **团队配置**：8人兼职团队
+  * 邓骐辰 - 项目协调（项目经理）
+  * 汤峰岷 - 架构师（技术负责人）
+  * 路宽 - 引擎开发工程师
+  * TBD - ETL开发工程师
+  * 彭川 - 应用开发经理
+  * 刘铁瑞 - 测试经理
+  * 田伟 - 产品经理
+  * 杨帆 - 运维工程师
+
+### 1.2 系统规模
+- **微服务模块数量**：约12个Spring Cloud微服务
+- **系统分层**：
+  * ETL层（数据抽取转换加载）
+  * 引擎层（核心计算引擎）
+  * 应用层（业务应用服务）
+
+### 1.3 现有技术栈
+- **微服务框架**：Spring Cloud
+- **注册/配置中心**：Nacos
+- **缓存**：Redis
+- **数据库**：MySQL/Oracle
+- **Web容器**：Tomcat（内嵌）
+- **内存网格**：Apache Ignite（待确认）
+- **求解器**：待确认型号
+
+### 1.4 国产化目标技术栈
+- **注册/配置中心**：TongNCS（东方通消息中间件）
+- **Web容器**：TongWeb（东方通应用服务器）
+- **缓存**：TongRDS（东方通缓存服务）
+- **数据库**：达梦数据库DM8 + 高斯数据库openGauss
+- **Web服务器**：Tengine（阿里云定制Nginx）
+- **操作系统**：麒麟OS
+
+---
+
+## 二、核心问题与挑战
+
+### 2.1 代码分支混乱问题（重点）
+- **现状**：存在7-8套代码分支，不同功能分散在不同分支
+- **问题**：
+  * 功能分支、环境分支、客户定制分支混杂
+  * 代码合并冲突风险高
+  * 缺乏统一的代码基线版本
+- **目标**：合并出两套清晰分支
+  * **baseline基线版本**：统一的主干功能版本
+  * **localization国产化版本**：基于baseline的国产化适配版本
+
+### 2.2 技术挑战
+1. **全面中间件替换**：5类中间件同时替换，技术风险高
+2. **兼职团队协调**：所有成员兼职，资源协调难度大
+3. **时间紧迫**：3个月完成12个微服务适配
+4. **未知技术风险**：
+   - Ignite内存网格的国产化替代方案未定
+   - 求解器ARM架构兼容性未知
+   - 第三方依赖库兼容性未知
+
+### 2.3 方案编写定位
+- **受众**：技术领导、公司管理层、项目团队成员
+- **目标**：
+  * 体现充分的前期准备和技术调研
+  * 展示深度的技术方案设计
+  * 证明风险可控、方案可行
+  * 提供可落地执行的详细计划
+- **风格**：专业严谨、逻辑清晰、数据支撑、可操作性强
+
+---
+
+## 三、方案文档结构要求
+
+请按以下结构编写完整的项目方案文档（Word/Markdown格式）：
+
+### 第一章：项目概述（战略高度）
+
+#### 1.1 项目背景与意义
+```
+要求：
+- 阐述国家信创政策背景（2+8+N信创体系）
+- 说明企业数字化转型与技术自主可控的重要性
+- 强调项目的战略意义和必要性
+- 篇幅：1-2页
+```
+
+#### 1.2 项目目标与范围
+```
+要求：
+- 明确的适配改造目标（量化指标）
+  * 功能兼容性达到100%
+  * 性能损耗≤5%
+  * 系统可用性≥99.5%
+- 技术范围界定：
+  * 列出12个微服务模块清单及职责描述
+  * 明确改造的中间件范围
+  * 说明数据迁移范围
+- 明确不包含的内容（项目边界）
+- 输出成果清单
+```
+
+#### 1.3 项目成功标准
+```
+要求：
+- 功能完整性标准（核心业务流程验证通过）
+- 性能基准标准（响应时间、吞吐量对比）
+- 稳定性标准（连续运行时长、错误率）
+- 验收标准（UAT测试通过率）
+```
+
+---
+
+### 第二章：现状分析（体现充分调研）
+
+#### 2.1 系统架构现状分析
+```
+要求：
+1. 绘制当前系统架构图（三层架构示意图）
+2. 提供12个微服务模块清单：
+   模块名称 | 所属层次 | 核心职责 | 技术栈 | 代码规模
+   --------|---------|---------|--------|----------
+   control-panel-server | 应用层 | ... | Spring Boot 2.x | 约XXX行
+   planner-workbench-server | 应用层 | ... | ... | ...
+   （依次列出其他模块）
+   
+3. 绘制技术组件依赖关系图
+4. 分析当前架构的优势与不足
+```
+
+#### 2.2 代码分支现状深度分析（核心重点）
+```
+要求：
+1. **分支清单与分类**
+   分支名称 | 分支类型 | 用途 | 最后更新时间 | 领先/落后主分支提交数 | 独有功能
+   --------|---------|------|-------------|---------------------|----------
+   develop | 开发主分支 | ... | 2025-10-20 | - | -
+   feature/xxx | 功能分支 | ... | ... | +50/-30 | 功能A、B
+   env/test | 环境分支 | ... | ... | +20/-10 | 测试环境配置
+   customer/xxx | 定制分支 | ... | ... | +100/-50 | 客户定制功能
+   （列出所有7-8个分支）
+
+2. **分支差异分析**
+   - 使用Git命令分析分支差异：
+     git log --oneline --graph --all
+   - 统计每个分支的独有提交数
+   - 识别关键功能差异
+   - 评估代码冲突风险（高/中/低）
+
+3. **代码质量现状**
+   - 总代码行数统计
+   - 代码重复率分析
+   - 技术债务评估（TODO、FIXME统计）
+   - 单元测试覆盖率现状
+
+4. **合并风险评估**
+   - 预估冲突文件数量
+   - 识别高风险模块
+   - 评估合并工作量（人天）
+```
+
+#### 2.3 技术栈适配影响分析
+```
+要求：对每个待替换组件进行详细分析
+
+##### 2.3.1 Nacos → TongNCS 适配分析
+- 功能对比表（服务注册、配置管理、健康检查等）
+- 代码影响范围：
+  * 配置文件修改点（bootstrap.yml）
+  * 依赖包替换（pom.xml）
+  * 代码改造点（注解、API调用）
+- 影响的微服务模块清单
+- 预估改造工作量：XX人天
+
+##### 2.3.2 Redis → TongRDS 适配分析
+（同上结构）
+
+##### 2.3.3 MySQL/Oracle → 达梦/高斯 适配分析
+- SQL语法差异重点分析：
+  * 分页语法（LIMIT vs ROWNUM）
+  * 日期函数差异
+  * 字符串函数差异
+  * 存储过程/函数适配
+- 数据迁移影响分析：
+  * 表结构迁移复杂度
+  * 数据量统计
+  * 迁移时间预估
+- ORM框架适配（MyBatis/JPA/QueryDSL）
+
+##### 2.3.4 Tomcat → TongWeb 适配分析
+（同上结构）
+
+##### 2.3.5 第三方依赖库兼容性分析
+- 梳理pom.xml中的第三方依赖
+- 识别潜在不兼容的库
+- 提供替代方案
+```
+
+#### 2.4 风险识别与预评估
+```
+要求：
+1. 技术风险矩阵（使用表格展示）
+   风险项 | 概率 | 影响程度 | 风险等级 | 应对策略
+   ------|------|---------|---------|----------
+   Ignite替代方案不成熟 | 高 | 高 | 高 | 提前POC验证
+   数据库迁移数据丢失 | 中 | 高 | 高 | 完整备份+灰度验证
+   （列出10-15个风险项）
+
+2. 进度风险分析
+3. 资源风险分析（兼职团队协调）
+4. 质量风险分析
+```
+
+---
+
+### 第三章：技术解决方案（体现技术深度）
+
+#### 3.1 代码分支合并策略（核心重点章节）
+```
+要求：这是方案的核心亮点，需要详细设计
+
+##### 3.1.1 合并策略总体设计
+1. **目标分支架构**
+   ```
+   master (锁定，仅用于发布)
+   ├── baseline (基线版本主分支)
+   │   ├── baseline-develop (基线开发分支)
+   │   └── baseline-hotfix/* (基线热修复分支)
+   └── localization (国产化版本主分支)
+       ├── localization-develop (国产化开发分支)
+       ├── localization-feature/* (国产化功能分支)
+       └── localization-hotfix/* (国产化热修复分支)
+   ```
+
+2. **合并原则**
+   - 以develop分支为合并基准
+   - 功能完整性优先原则
+   - 代码质量优先原则
+   - 充分测试验证原则
+
+##### 3.1.2 分支合并详细步骤
+
+**阶段一：分支分析与准备（1周）**
+```bash
+# 步骤1：备份所有分支
+git branch -a > branches_backup.txt
+for branch in $(git branch -a | grep remotes | grep -v HEAD); do
+  git checkout -b backup/${branch##*/} $branch
+done
+
+# 步骤2：分析分支差异
+git log --oneline --graph --decorate --all > git_history.txt
+
+# 步骤3：识别每个分支的独有提交
+for branch in feature/xxx env/test customer/xxx; do
+  git log baseline-develop..$branch --oneline > diff_$branch.txt
+done
+```
+
+**阶段二：创建baseline基线分支（1周）**
+```bash
+# 步骤1：基于当前主develop创建baseline分支
+git checkout develop
+git pull origin develop
+git checkout -b baseline-main
+git push origin baseline-main
+
+# 步骤2：合并核心功能分支
+# 按优先级合并功能分支，每次合并后进行编译测试
+git merge --no-ff feature/core-function-1
+mvn clean compile
+# 如果编译失败，解决冲突后继续
+git merge --no-ff feature/core-function-2
+mvn clean compile
+
+# 步骤3：剔除环境特定配置
+# 将环境配置外部化到配置中心
+
+# 步骤4：剔除客户定制功能
+# 通过feature-toggle方式保留钩子，但默认关闭
+```
+
+**阶段三：创建localization国产化分支（1周）**
+```bash
+# 基于baseline创建国产化分支
+git checkout baseline-main
+git checkout -b localization-main
+git push origin localization-main
+
+# 创建国产化开发分支
+git checkout -b localization-develop
+```
+
+##### 3.1.3 冲突解决机制
+1. **冲突分类处理策略**
+   - 配置文件冲突：选择最新版本，手动合并差异配置
+   - 业务代码冲突：召开技术评审会，选择最优实现
+   - 依赖冲突：统一升级到最新稳定版本
+
+2. **冲突解决流程**
+   ```
+   发现冲突 → 冲突分类 → 责任人分配 → 解决方案评审 → 实施解决 → 代码审查 → 测试验证
+   ```
+
+3. **冲突记录模板**
+   ```markdown
+   ## 冲突记录 #001
+   - 冲突文件：src/main/java/com/xxx/Service.java
+   - 冲突分支：feature/A vs feature/B
+   - 冲突类型：业务逻辑冲突
+   - 负责人：张三
+   - 解决方案：采用feature/A的实现，补充feature/B的异常处理
+   - 审查人：李四
+   - 状态：已解决
+   ```
+
+##### 3.1.4 代码评审流程
+- 所有合并必须经过Code Review
+- 评审检查清单：
+  * 代码风格规范
+  * 业务逻辑正确性
+  * 单元测试覆盖率
+  * 性能影响评估
+  * 安全漏洞检查
+
+##### 3.1.5 合并后的分支管理策略
+1. **双主干并行维护策略**
+   - baseline分支：维护原有技术栈版本，用于非国产化客户
+   - localization分支：国产化适配版本，向上合并baseline的bug修复
+
+2. **代码同步机制**
+   ```bash
+   # 定期将baseline的bug修复合并到localization
+   git checkout localization-develop
+   git merge baseline-develop
+   ```
+
+3. **分支保护规则**
+   - baseline-main和localization-main设置为保护分支
+   - 禁止直接推送，必须通过PR/MR
+   - 至少2人审查通过才能合并
+
+##### 3.1.6 回滚预案
+- 每次合并前打tag标记
+- 保留原有分支至少3个月
+- 提供快速回滚脚本
+
+##### 3.1.7 工作量与进度安排
+- 分支分析与准备：1周（5人天）
+- baseline分支合并：1周（10人天）
+- localization分支创建：0.5周（3人天）
+- 测试验证：1.5周（8人天）
+- 总计：4周，26人天
+```
+
+#### 3.2 中间件适配技术方案（需收集互联网经验）
+```
+要求：对每个中间件提供详细适配方案，并引用互联网实际案例
+
+##### 3.2.1 Nacos → TongNCS 适配方案
+
+**1. TongNCS技术特性介绍**
+- 产品介绍：东方通TongNCS是企业级分布式配置与服务治理平台
+- 核心功能：服务注册发现、配置管理、服务路由、负载均衡
+- 与Nacos的关系：TongNCS兼容部分Nacos API
+
+**2. 功能对比分析**
+| 功能项 | Nacos | TongNCS | 兼容性 | 适配难度 |
+|--------|-------|---------|--------|----------|
+| 服务注册 | ✓ | ✓ | 高 | 低 |
+| 服务发现 | ✓ | ✓ | 高 | 低 |
+| 配置管理 | ✓ | ✓ | 中 | 中 |
+| 配置热更新 | ✓ | ✓ | 中 | 中 |
+| 命名空间 | ✓ | ✓ | 高 | 低 |
+| 多环境管理 | ✓ | ✓ | 高 | 低 |
+| 权限控制 | ✓ | ✓ | 中 | 中 |
+| API兼容性 | - | 部分兼容 | 中 | 中 |
+
+**3. 配置迁移方案**
+```yaml
+# Nacos配置示例（修改前）
+spring:
+  cloud:
+    nacos:
+      discovery:
+        server-addr: 192.168.1.100:8848
+        namespace: dev
+        group: DEFAULT_GROUP
+      config:
+        server-addr: 192.168.1.100:8848
+        file-extension: yml
+        namespace: dev
+        group: DEFAULT_GROUP
+
+# TongNCS配置示例（修改后）
+spring:
+  cloud:
+    tongncs:
+      discovery:
+        server-addr: 192.168.1.200:8848
+        namespace: dev
+        group: DEFAULT_GROUP
+      config:
+        server-addr: 192.168.1.200:8848
+        file-extension: yml
+        namespace: dev
+        group: DEFAULT_GROUP
+```
+
+**4. 代码改造点清单**
+- Maven依赖替换：
+  ```xml
+  <!-- 移除Nacos依赖 -->
+  <dependency>
+      <groupId>com.alibaba.cloud</groupId>
+      <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
+  </dependency>
+  
+  <!-- 添加TongNCS依赖 -->
+  <dependency>
+      <groupId>com.tongtech</groupId>
+      <artifactId>tongncs-spring-cloud-starter</artifactId>
+      <version>x.x.x</version>
+  </dependency>
+  ```
+
+- 配置文件修改（bootstrap.yml）
+- 如使用Nacos Java SDK的直接调用代码需要适配
+
+**5. 互联网已知适配经验（重要）**
+请收集并引用：
+- 某银行核心系统Nacos迁移TongNCS案例
+- 某政务云平台信创改造经验
+- 东方通官方迁移指南文档
+- 技术社区的实践经验分享
+
+示例格式：
+```
+【案例1】某股份制银行核心交易系统国产化改造
+- 系统规模：20+微服务
+- 迁移周期：2个月
+- 关键经验：
+  * TongNCS在高并发场景下的心跳间隔需要调优
+  * 配置中心的加密配置需要重新设置
+  * 建议先迁移非核心服务进行验证
+- 参考资料：[链接]
+
+【案例2】某省政务服务平台信创适配
+- 遇到的坑：TongNCS某版本与Spring Cloud 2.x兼容性问题
+- 解决方案：升级TongNCS到x.x版本
+- 参考资料：[链接]
+```
+
+**6. 潜在问题与解决方案**
+| 问题 | 影响 | 解决方案 |
+|------|------|----------|
+| API兼容性差异 | 中 | 封装适配层，统一接口 |
+| 性能差异 | 中 | 调优参数，压测验证 |
+| 监控告警迁移 | 低 | 对接Prometheus |
+
+**7. 改造工作量评估**
+- 依赖包替换：0.5人天/服务 × 12服务 = 6人天
+- 配置文件修改：0.5人天/服务 × 12服务 = 6人天
+- 代码适配（如有SDK调用）：2人天/服务 × 3服务 = 6人天
+- 联调测试：1人天/服务 × 12服务 = 12人天
+- **总计：30人天**
+
+---
+
+##### 3.2.2 Redis → TongRDS 适配方案
+
+**1. TongRDS技术特性**
+（按相同结构展开）
+
+**2. 功能对比**
+| 功能项 | Redis | TongRDS | 兼容性 | 适配难度 |
+|--------|-------|---------|--------|----------|
+| 数据结构 | String/Hash/List/Set/ZSet | 全支持 | 高 | 低 |
+| 持久化 | RDB/AOF | 支持 | 高 | 低 |
+| 主从复制 | ✓ | ✓ | 高 | 低 |
+| 哨兵模式 | ✓ | ✓ | 中 | 中 |
+| 集群模式 | ✓ | ✓ | 中 | 中 |
+| Lua脚本 | ✓ | 部分支持 | 中 | 中 |
+| 发布订阅 | ✓ | ✓ | 高 | 低 |
+
+**3. 配置迁移**
+（提供配置示例对比）
+
+**4. 代码改造点**
+（列出具体改造点）
+
+**5. 互联网已知经验**
+（收集实际案例）
+
+**6. 潜在问题与解决方案**
+
+**7. 工作量评估：XX人天**
+
+---
+
+##### 3.2.3 MySQL/Oracle → 达梦DM8/高斯openGauss 适配方案
+
+**1. 数据库技术特性对比**
+| 特性 | MySQL | Oracle | 达梦DM8 | 高斯openGauss |
+|------|-------|--------|---------|---------------|
+| SQL标准 | SQL-2003 | SQL:2016 | SQL-2003 | SQL:2011 |
+| 存储过程 | ✓ | ✓ | ✓ | ✓ |
+| 触发器 | ✓ | ✓ | ✓ | ✓ |
+| 分区表 | ✓ | ✓ | ✓ | ✓ |
+| 物化视图 | ✗ | ✓ | ✓ | ✓ |
+
+**2. SQL语法差异分析（重点）**
+
+**2.1 分页语法差异**
+```sql
+-- MySQL分页
+SELECT * FROM user ORDER BY id LIMIT 10 OFFSET 20;
+
+-- Oracle分页
+SELECT * FROM (
+  SELECT A.*, ROWNUM RN FROM (
+    SELECT * FROM user ORDER BY id
+  ) A WHERE ROWNUM <= 30
+) WHERE RN > 20;
+
+-- 达梦DM8分页（兼容MySQL和Oracle语法）
+SELECT * FROM user ORDER BY id LIMIT 10 OFFSET 20;  -- MySQL方式
+SELECT * FROM user ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;  -- 标准SQL
+
+-- 高斯openGauss分页（兼容PostgreSQL）
+SELECT * FROM user ORDER BY id LIMIT 10 OFFSET 20;
+```
+
+**2.2 日期函数差异**
+```sql
+-- MySQL
+NOW(), DATE_FORMAT(date, '%Y-%m-%d')
+
+-- Oracle
+SYSDATE, TO_CHAR(date, 'YYYY-MM-DD')
+
+-- 达梦DM8（兼容Oracle）
+SYSDATE, TO_CHAR(date, 'YYYY-MM-DD')
+
+-- 高斯openGauss（兼容PostgreSQL）
+NOW(), TO_CHAR(date, 'YYYY-MM-DD')
+```
+
+**2.3 字符串函数差异**
+（列出常用函数对比）
+
+**2.4 自增主键差异**
+（列出序列、IDENTITY等差异）
+
+**3. 数据迁移方案**
+
+**3.1 Schema迁移**
+- 使用达梦DTS工具或官方迁移工具
+- 手动核对表结构定义
+- 索引、约束、触发器迁移检查清单
+
+**3.2 数据迁移**
+- 全量数据迁移策略
+- 增量数据同步策略
+- 数据一致性校验方案
+
+**3.3 迁移时间预估**
+| 数据库 | 表数量 | 数据量 | 预估迁移时间 |
+|--------|--------|--------|-------------|
+| 业务库1 | 50 | 10GB | 2小时 |
+| 业务库2 | 30 | 5GB | 1小时 |
+
+**4. ORM框架适配**
+
+**4.1 MyBatis适配**
+```xml
+<!-- MySQL配置 -->
+<select id="findUserPage" resultType="User">
+  SELECT * FROM user
+  ORDER BY id
+  LIMIT #{offset}, #{limit}
+</select>
+
+<!-- 达梦DM8适配后 -->
+<select id="findUserPage" resultType="User" databaseId="dm">
+  SELECT * FROM user
+  ORDER BY id
+  OFFSET #{offset} ROWS FETCH NEXT #{limit} ROWS ONLY
+</select>
+```
+
+**4.2 JPA/Hibernate适配**
+- Dialect配置修改
+- 方言差异处理
+
+**4.3 QueryDSL适配**
+- 数据库方言配置
+- 自定义函数注册
+
+**5. 性能优化建议**
+- 索引优化策略
+- 执行计划分析
+- SQL调优checklist
+
+**6. 互联网已知经验**
+（收集Oracle→达梦、MySQL→高斯的实际案例）
+
+示例：
+```
+【案例1】某保险公司核心业务系统Oracle迁移达梦
+- 数据库规模：200+表，500GB数据
+- 迁移周期：3个月
+- 关键经验：
+  * 存储过程需要逐个改造和测试
+  * 达梦的优化器与Oracle有差异，需要重新调优
+  * CLOB/BLOB字段迁移需要特别注意
+  * 建议使用达梦的Oracle兼容模式
+
+【案例2】某互联网公司MySQL迁移高斯
+- 遇到的坑：字符集编码问题
+- 解决方案：统一使用UTF8MB4
+```
+
+**7. 工作量评估**
+- Schema迁移：5人天
+- 数据迁移：3人天
+- SQL语句适配：15人天（假设100+处SQL需要修改）
+- 存储过程改造：10人天
+- ORM框架适配：5人天
+- 性能调优：10人天
+- 测试验证：15人天
+- **总计：63人天**
+
+---
+
+##### 3.2.4 Tomcat → TongWeb 适配方案
+
+**1. TongWeb技术特性**
+（按相同结构展开）
+
+**2. 功能对比**
+
+**3. 部署配置变更**
+- Spring Boot内嵌容器改为外置容器
+- 打包方式从jar改为war
+- 启动参数调整
+
+**4. 代码改造点**
+```java
+// 修改Application主类
+@SpringBootApplication
+public class Application extends SpringBootServletInitializer {
+    
+    @Override
+    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
+        return application.sources(Application.class);
+    }
+    
+    public static void main(String[] args) {
+        SpringApplication.run(Application.class, args);
+    }
+}
+```
+
+**5. 互联网已知经验**
+（收集实际案例）
+
+**6. 工作量评估：XX人天**
+
+---
+
+##### 3.2.5 其他适配项
+
+**1. Tengine部署方案**
+（Nginx配置迁移）
+
+**2. 麒麟OS环境适配**
+- JDK选择（OpenJDK vs 毕升JDK）
+- 系统依赖库检查
+
+**3. 第三方依赖库兼容性处理**
+（列出需要替换的库）
+
+```
+
+#### 3.3 技术选型与替代方案
+
+##### 3.3.1 Ignite内存网格替代方案
+```
+要求：
+1. Ignite功能分析
+2. 替代方案对比：
+   | 方案 | 优点 | 缺点 | 适配成本 | 推荐指数 |
+   |------|------|------|----------|----------|
+   | Hazelcast | ... | ... | 高 | ⭐⭐⭐ |
+   | Redis Cluster | ... | ... | 中 | ⭐⭐⭐⭐ |
+   | TongRDS集群 | ... | ... | 低 | ⭐⭐⭐⭐⭐ |
+   | Apache Geode | ... | ... | 高 | ⭐⭐ |
+
+3. 技术验证POC计划
+4. 推荐方案及理由
+```
+
+##### 3.3.2 求解器ARM兼容性方案
+```
+要求：
+1. 当前求解器技术分析
+2. ARM架构兼容性调研
+3. 替代方案对比
+4. 技术决策建议
+```
+
+#### 3.4 系统架构设计
+
+##### 3.4.1 国产化后的目标架构图
+```
+要求：
+- 绘制完整的系统架构图（使用工具绘制）
+- 标注所有国产化组件
+- 说明架构变化点
+```
+
+##### 3.4.2 部署架构图
+```
+要求：
+- 绘制物理部署架构
+- 标注服务器配置
+- 说明网络规划
+```
+
+##### 3.4.3 数据架构图
+```
+要求：
+- 绘制数据流转图
+- 说明数据迁移路径
+```
+
+---
+
+### 第四章：实施计划（体现项目管理能力）
+
+#### 4.1 项目阶段与里程碑
+```
+要求：
+基于提供的5阶段任务清单，细化WBS到3级，并制定详细进度计划
+
+使用甘特图或表格形式展示：
+阶段 | 里程碑 | 活动 | 子活动 | 负责人 | 工期 | 前置任务 | 计划开始 | 计划结束 | 交付物
+-----|--------|------|--------|--------|------|----------|----------|----------|--------
+PHASE 1 | 项目启动 | 项目启动准备 | 项目团队组建 | 邓骐辰 | 1d | - | 2025-10-25 | 2025-10-25 | 项目启动会纪要
+... | ... | ... | ... | ... | ... | ... | ... | ... | ...
+
+关键路径标注：
+- 识别关键路径任务
+- 标注时间缓冲
+- 说明并行任务安排
+```
+
+#### 4.2 人力资源计划
+```
+要求：
+1. 团队组织架构图
+2. 角色职责矩阵（RACI）
+   任务 | 邓骐辰 | 汤峰岷 | 路宽 | TBD | 彭川 | 刘铁瑞 | 田伟 | 杨帆
+   -----|--------|--------|------|-----|------|--------|------|------
+   分支合并 | A | R | C | C | C | I | I | I
+   框架适配 | A | R | I | I | C | I | I | C
+   （R=负责, A=批准, C=咨询, I=知情）
+
+3. 人力资源甘特图
+4. 兼职人员协调机制
+```
+
+#### 4.3 沟通管理计划
+```
+要求：
+1. 会议机制
+   - 每日站会：15分钟，同步进展和问题
+   - 每周例会：1小时，项目回顾和计划
+   - 里程碑评审：2小时，阶段性验收
+
+2. 沟通渠道
+   - 即时通讯：企业微信/钉钉
+   - 项目管理：禅道/JIRA
+   - 文档协作：企业网盘
+
+3. 汇报机制
+   - 日报：每日提交
+   - 周报：每周五提交
+   - 月报：每月底提交
+   - 里程碑报告：里程碑完成后3日内
+```
+
+#### 4.4 质量管理计划
+```
+要求：
+1. 代码质量标准
+   - 代码规范：阿里巴巴Java开发手册
+   - 单元测试覆盖率：≥70%
+   - 代码审查：必须进行
+
+2. 测试策略
+   - 单元测试：开发人员编写
+   - 集成测试：开发+测试
+   - 系统测试：测试团队
+   - 性能测试：运维+测试
+   - UAT测试：产品+业务
+
+3. 质量检查点
+   - 代码提交检查
+   - 每日构建检查
+   - 里程碑质量评审
+```
+
+---
+
+### 第五章：风险管理计划
+
+#### 5.1 风险登记册
+```
+要求：
+编制完整的风险登记册（15-20个风险项）
+
+风险ID | 风险描述 | 类别 | 概率 | 影响 | 风险等级 | 应对策略 | 责任人 | 应急预案
+-------|---------|------|------|------|----------|----------|--------|----------
+R001 | Ignite替代方案技术验证失败 | 技术 | 高 | 高 | 高 | 提前POC，准备多个备选方案 | 汤峰岷 | 采用Redis Cluster方案
+R002 | 代码分支合并冲突严重 | 技术 | 中 | 高 | 高 | 详细分析后分阶段合并 | 邓骐辰 | 延长合并周期，增加人力
+R003 | 数据库迁移数据丢失 | 技术 | 中 | 高 | 高 | 完整备份+分批迁移 | 杨帆 | 回滚到备份版本
+...
+
+风险等级 = 概率 × 影响（高=3，中=2，低=1）
+高风险：≥6，中风险：3-5，低风险：1-2
+```
+
+#### 5.2 风险应对措施
+```
+要求：
+针对高风险项制定详细应对措施，包括：
+- 预防措施
+- 减轻措施
+- 应急预案
+- 责任人和时间表
+```
+
+---
+
+### 第六章：测试方案
+
+#### 6.1 测试策略
+```
+要求：
+说明各层次测试策略和范围
+```
+
+#### 6.2 测试环境规划
+```
+要求：
+| 环境 | 用途 | 配置 | 部署时间 |
+|------|------|------|----------|
+| DEV | 开发测试 | ... | 11月1日 |
+| SIT | 集成测试 | ... | 11月15日 |
+| UAT | 验收测试 | ... | 12月20日 |
+```
+
+#### 6.3 测试用例设计
+```
+要求：
+- 功能测试用例框架
+- 性能测试场景设计
+- 兼容性测试矩阵
+```
+
+#### 6.4 验收标准
+```
+要求：
+明确的量化验收标准
+```
+
+---
+
+### 第七章：应急预案与回滚方案
+
+#### 7.1 应急响应机制
+```
+要求：
+- 问题分级标准
+- 应急响应流程
+- 升级机制
+```
+
+#### 7.2 数据回滚方案
+```
+要求：
+- 数据库回滚步骤
+- 配置回滚步骤
+- 代码回滚步骤
+```
+
+#### 7.3 业务连续性保障
+```
+要求：
+- 服务降级方案
+- 灰度发布策略
+```
+
+---
+
+### 第八章：成本预算
+
+#### 8.1 硬件成本
+```
+要求：
+| 项目 | 数量 | 单价 | 小计 | 备注 |
+|------|------|------|------|------|
+| 云服务器（8核16G） | 10台 | X元/月 | XX万 | 3个月 |
+| 达梦数据库授权 | 2套 | X万 | XX万 | 永久授权 |
+| TongWeb授权 | 10个 | X万 | XX万 | 永久授权 |
+...
+```
+
+#### 8.2 人力成本
+```
+要求：
+估算人力投入成本
+```
+
+#### 8.3 总成本估算
+```
+要求：
+汇总总成本，说明成本效益分析
+```
+
+---
+
+### 第九章：项目成果与知识沉淀
+
+#### 9.1 预期交付成果
+```
+要求：
+列出所有交付物清单
+- 国产化适配后的源代码
+- 数据库迁移脚本
+- 部署文档
+- 测试报告
+- 用户手册
+- 培训材料
+- 项目总结报告
+```
+
+#### 9.2 知识沉淀计划
+```
+要求：
+- 技术文档库建设
+- 最佳实践总结
+- 问题案例库
+- 培训体系建设
+```
+
+---
+
+### 第十章：总结与展望
+
+#### 10.1 项目总结
+```
+要求：
+总结本方案的核心要点和创新点
+```
+
+#### 10.2 后续规划
+```
+要求：
+说明国产化适配后的运维、优化计划
+```
+
+---
+
+## 四、附录要求
+
+### 附录A：12个微服务模块清单
+```
+要求：
+详细列出12个微服务的信息：
+模块名称 | 所属层次 | 核心职责 | 技术栈 | 代码规模 | 外部依赖 | 改造优先级
+```
+
+### 附录B：技术调研报告
+```
+要求：
+提供各中间件的详细技术调研报告
+```
+
+### 附录C：代码分支详细分析报告
+```
+要求：
+提供Git分支分析的详细数据
+```
+
+### 附录D：术语表
+```
+要求：
+解释文档中的专业术语和缩写
+```
+
+### 附录E：参考资料
+```
+要求：
+列出所有参考的互联网资料、官方文档、技术博客等
+```
+
+---
+
+## 五、文档格式要求
+
+### 5.1 整体要求
+- **格式**：Word文档（.docx）或Markdown（可导出PDF）
+- **篇幅**：60-80页（A4纸）
+- **字体**：
+  * 标题：黑体，一级标题18pt，二级16pt，三级14pt
+  * 正文：宋体，12pt
+  * 代码：Consolas，10pt
+- **行距**：1.5倍
+- **页边距**：上下2.54cm，左右3.17cm
+
+### 5.2 图表要求
+- 所有架构图使用专业绘图工具（draw.io、Visio、PlantUML）
+- 图表必须清晰可读，统一风格
+- 图表必须有编号和标题
+- 复杂图表提供图例说明
+
+### 5.3 代码示例要求
+- 使用代码高亮
+- 提供必要的注释
+- 展示前后对比（修改前vs修改后）
+
+### 5.4 数据支撑要求
+- 工作量评估必须有明确数据支撑
+- 风险评估必须量化
+- 成本预算必须详细
+
+---
+
+## 六、方案编写提示
+
+### 6.1 体现"用心良苦"的要点
+1. **充分的前期调研**
+   - 详尽的代码分支分析（用数据说话）
+   - 全面的技术栈影响评估
+   - 深入的互联网经验收集
+
+2. **深度的技术方案**
+   - 代码分支合并的详细步骤（可直接执行）
+   - 中间件适配的完整方案（有实际案例支撑）
+   - 多维度的风险评估和应对
+
+3. **严谨的项目管理**
+   - 科学的WBS分解
+   - 合理的进度安排
+   - 完善的质量保障机制
+
+4. **可落地的执行计划**
+   - 每个任务都有明确的负责人
+   - 每个阶段都有清晰的交付物
+   - 每个风险都有应急预案
+
+### 6.2 避免的问题
+- 避免空洞的理论，要有实际数据和案例
+- 避免过于乐观的估算，要预留风险缓冲
+- 避免忽略细节，要考虑实施中的各种问题
+- 避免文档过于冗长，要突出重点
+
+### 6.3 重点突出的章节
+1. **代码分支合并策略**（核心亮点，占方案15-20%篇幅）
+2. **中间件适配方案**（技术深度体现，占方案30-35%篇幅）
+3. **风险管理计划**（体现风险意识，占方案10-15%篇幅）
+4. **实施计划**（体现项目管理能力，占方案15-20%篇幅）
+
+---
+
+## 七、请开始编写
+
+请严格按照以上要求，编写一份完整、专业、可落地的《XXX系统国产化适配改造项目方案》。
+
+**特别强调**：
+1. 代码分支合并策略必须详细到可以直接执行的程度
+2. 中间件适配方案必须包含互联网实际案例（至少每个中间件2个案例）
+3. 所有工作量评估必须有数据支撑
+4. 所有风险必须有应对措施
+5. 方案必须体现充分准备和技术深度
+
+请使用Markdown格式输出完整方案文档。
+
diff --git a/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/JenkinsBuildInputMapping.java b/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/JenkinsBuildInputMapping.java
index 900340d3..1ac9dc08 100644
--- a/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/JenkinsBuildInputMapping.java
+++ b/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/JenkinsBuildInputMapping.java
@@ -1,5 +1,6 @@
 package com.qqchen.deploy.backend.workflow.dto.inputmapping;
 
+import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
 import lombok.Data;
 import jakarta.validation.constraints.NotNull;
 import jakarta.validation.constraints.NotBlank;
@@ -11,6 +12,7 @@ import jakarta.validation.constraints.NotBlank;
  * @since 2025-10-22
  */
 @Data
+@JsonIgnoreProperties(ignoreUnknown = true)
 public class JenkinsBuildInputMapping {
     
     /**
diff --git a/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/NotificationInputMapping.java b/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/NotificationInputMapping.java
index 2a2556b1..1461d09a 100644
--- a/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/NotificationInputMapping.java
+++ b/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/NotificationInputMapping.java
@@ -1,5 +1,6 @@
 package com.qqchen.deploy.backend.workflow.dto.inputmapping;
 
+import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
 import lombok.Data;
 import jakarta.validation.constraints.NotNull;
 
@@ -10,6 +11,7 @@ import jakarta.validation.constraints.NotNull;
  * @since 2025-10-22
  */
 @Data
+@JsonIgnoreProperties(ignoreUnknown = true)
 public class NotificationInputMapping {
     
     /**
diff --git a/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/ShellInputMapping.java b/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/ShellInputMapping.java
index 1638b220..5ff74e96 100644
--- a/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/ShellInputMapping.java
+++ b/backend/src/main/java/com/qqchen/deploy/backend/workflow/dto/inputmapping/ShellInputMapping.java
@@ -1,5 +1,6 @@
 package com.qqchen.deploy.backend.workflow.dto.inputmapping;
 
+import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
 import lombok.Data;
 
 import java.util.Map;
@@ -11,6 +12,7 @@ import java.util.Map;
  * @since 2025-10-22
  */
 @Data
+@JsonIgnoreProperties(ignoreUnknown = true)
 public class ShellInputMapping {
     
     /**