# AI全流程兜底闭环 ## 1. 核心理念 两个月自研一套对标泰岳的4A系统，**不可能靠纯人工完成**。AI不是锦上添花，而是项目成功的前提条件。 核心策略：**AI最大化替代重复性工作，人工聚焦架构设计、安全审查和关键决策。** --- ## 2. AI在各个阶段的介入点 ### 2.1 开发阶段 ``` ┌─────────────────────────────────────────────────────────────────────┐ │ 开发阶段 AI 介入 │ │ │ │ ┌────────────────────┐ ┌────────────────────┐ │ │ │ AI代码生成 │ │ AI代码审查 │ │ │ │ │ │ │ │ │ │ • API层CRUD代码 │ │ • 安全漏洞扫描 │ │ │ │ • 数据模型→SQL │ │ (SQL注入/XSS/越权) │ │ │ │ • Service层业务逻辑 │ │ • 接口规范一致性检查 │ │ │ │ • 前端列表/表单页面 │ │ • 日志埋点完整性检查 │ │ │ │ • 单元测试代码 │ │ • 异常处理覆盖率检查 │ │ │ │ • 接口文档生成 │ │ • 代码风格统一 │ │ │ └────────────────────┘ └────────────────────┘ │ │ │ │ ┌────────────────────┐ ┌────────────────────┐ │ │ │ AI数据模型辅助 │ │ AI对接适配器生成 │ │ │ │ │ │ │ │ │ │ • 从泰岳界面反推 │ │ • 金科人脸API适配器 │ │ │ │ 数据模型 │ │ • 消息中心API适配器 │ │ │ │ • 字段映射脚本生成 │ │ • 现网账号同步适配器 │ │ │ │ • 数据迁移/同步 │ │ • 亚信接口规范适配器 │ │ │ │ 代码生成 │ │ • 泰岳接口模拟器 │ │ │ └────────────────────┘ └────────────────────┘ │ └─────────────────────────────────────────────────────────────────────┘ ``` **AI代码生成策略**： 1. **模型选型**：使用 DeepSeek/Claude 等具有编程能力的模型 2. **Prompt模板化**：为每种代码类型（API CRUD、数据模型、单元测试、接口适配层）建立标准 Prompt 3. **微调/知识注入**：将本项目的表结构定义、接口规范作为 System Prompt 上下文 4. **人机协作**：AI生成初稿 → 人工审查 → AI根据Review意见修正 → 循环至满意 5. **生成量目标**：争取 60-70% 的业务代码由AI完成初稿 ### 2.2 测试阶段 ``` ┌──────────────────────────────────────────────────────────────────────┐ │ 测试阶段 AI 介入 │ │ │ │ 1. 测试用例自动生成 │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ 输入: API接口定义/数据模型/业务规则描述 → AI生成: │ │ │ │ - 正常流程测试用例集 │ │ │ │ - 异常路径测试用例集（参数错误/越权/并发/超时） │ │ │ │ - 边界条件测试用例集（空值/超长/特殊字符/数据溢出） │ │ │ │ - 安全性测试用例（SQL注入/XSS/CSRF/越权枚举） │ │ │ │ - 压力测试基准脚本 │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ 2. 与泰岳版行为比对测试 │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ AI Agent 框架： │ │ │ │ │ │ │ │ ① AI录制泰岳版操作 → 生成操作序列 │ │ │ │ ② AI将操作序列转为自动化测试脚本 │ │ │ │ ③ AI同时在泰岳版和自研版执行测试脚本 │ │ │ │ ④ AI比对两系统的： │ │ │ │ - 接口请求/响应差异 │ │ │ │ - 界面元素/流程差异 │ │ │ │ - 数据持久化结果差异 │ │ │ │ ⑤ AI输出差异报告，标注关键程度 │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ 3. 回归测试自愈 │ │ - 当代码变更导致测试失败时，AI自动分析失败原因 │ │ - 测试预期结果过时？AI自动更新测试用例 │ │ - 产品逻辑改变？AI识别并标记为"预期变化" │ │ - 测试环境问题？AI标记为"环境异常"而非"功能失败" │ └──────────────────────────────────────────────────────────────────────┘ ``` ### 2.3 部署阶段 ``` ┌──────────────────────────────────────────────────────────────────────┐ │ 部署阶段 AI 介入 │ │ │ │ 1. 基础设施编排 │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ AI生成 Ansible Playbook / Terraform 配置: │ │ │ │ - 服务器初始化（OS调优、安全基线配置） │ │ │ │ - 中间件部署（Nginx/Redis/MySQL/ES/MinIO） │ │ │ │ - 应用部署（认证中心/资源中心/审计中心各模块） │ │ │ │ - 网络策略配置（防火墙规则、反向代理、TLS证书） │ │ │ └───────────────────────────────────────────────────────────┘ │ │ │ │ 2. 配置差异自适应 │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ 当部署失败时，AI分析错误日志： │ │ │ │ - 配置参数与环境不匹配？AI推荐正确值 │ │ │ │ - 依赖组件版本冲突？AI推荐兼容版本组合 │ │ │ │ - 权限问题？AI生成正确的权限设置命令 │ │ │ │ - 网络不可达？AI诊断网络路径 + 推荐修复方案 │ │ │ └───────────────────────────────────────────────────────────┘ │ │ │ │ 3. CI/CD Pipeline │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ 流水线步骤（AI辅助维护）： │ │ │ │ │ │ │ │ [代码提交] → [AI代码审查] → [AI生成测试] → [自动编译] │ │ │ │ → [单元测试] → [集成测试] → [AI比对测试] → [安全扫描] │ │ │ │ → [构建镜像] → [部署到测试环境] → [冒烟测试] → [通知] │ │ │ └───────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────────┘ ``` ### 2.4 运维阶段 ``` ┌──────────────────────────────────────────────────────────────────────┐ │ 运维阶段 AI 介入 │ │ │ │ 1. 智能告警与根因分析 │ │ ┌───────────────────────────────────────────────────────────┐ │ │ 场景1：用户反馈"登录不上了" │ │ │ AI排查链路：API超时？→ Redis连接失败？→ Redis进程挂了？ │ │ │ → OOM被Killed？→ 内存泄漏？ │ │ │ 根因定位后AI自动在5分钟内输出根因报告 + 修复方案 │ │ │ │ │ 场景2：SSO跳转后白屏 │ │ │ AI排查链路：前端报错→ API返回500 → 后端日志ClassNotFound │ │ │ → 发版时删了jar包 → 回滚建议 │ │ │ └───────────────────────────────────────────────────────────┘ │ │ │ │ 2. 数据一致性巡检 │ │ ┌───────────────────────────────────────────────────────────┐ │ │ AI Agent定时任务（每天凌晨执行）： │ │ │ ✓ 自研系统账号数与现网账号平台对比 → 偏差 > 0.1% 告警 │ │ │ ✓ 昨日新增的日志量与API调用量匹配度 → 缺漏事件告警 │ │ │ ✓ 授权数据完整性和无循环引用 → 数据损坏告警 │ │ │ ✓ 密钥轮换成功率检测 → 失败操作通知管理员 │ │ │ └───────────────────────────────────────────────────────────┘ │ │ │ │ 3. 性能基线追踪 │ │ ┌───────────────────────────────────────────────────────────┐ │ │ 持续采集： │ │ │ - API响应时间 P50/P95/P99（按接口维度） │ │ │ - 认证成功率/耗时趋势 │ │ │ - ES查询响应时间趋势 │ │ │ - 堡垒机并发数/响应延迟趋势 │ │ │ │ │ 当性能偏离基线 > 20%时，AI自动生成性能分析报告 │ │ │ 与上一发版/配置变更/流量突增做关联分析 │ │ │ └───────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────────┘ ``` --- ## 3. 与泰岳版的比对验证方案 ### 3.1 验证框架 ``` ┌────────────────────────────────────────────────────────────────────────┐ │ 比对验证框架 │ │ │ │ ┌────────────────────┐ ┌────────────────────┐ │ │ │ 功能覆盖度验证 │ │ 行为一致性验证 │ │ │ ├────────────────────┤ ├────────────────────┤ │ │ │ 工具: AI扫描 + │ │ 工具: AI Agent │ │ │ │ 功能矩阵表 │ │ 录制→回放→比对 │ │ │ │ 方法: │ │ 方法: │ │ │ │ ① 列出泰岳版所有 │ │ ① 录制泰岳版操作 │ │ │ │ 功能点 │ │ ② 生成测试脚本 │ │ │ │ ② 逐项标记自研版 │ │ ③ 在两系统执行 │ │ │ │ 覆盖状态 │ │ ④ AI比对行为差异 │ │ │ │ ③ AI辅助识别遗漏 │ │ ⑤ 输出差异报告 │ │ │ └────────────────────┘ └────────────────────┘ │ │ │ │ ┌────────────────────┐ ┌────────────────────┐ │ │ │ 性能基准验证 │ │ 安全基准验证 │ │ │ ├────────────────────┤ ├────────────────────┤ │ │ │ 工具: JMeter/k6 │ │ 工具: 安全扫描器+AI │ │ │ │ 方法: │ │ 方法: │ │ │ │ ① 相同硬件上运行 │ │ ① OWASP Top10扫描 │ │ │ │ ② 定义核心场景 │ │ ② 认证机制审查 │ │ │ │ (登录/SSO/授权/ │ │ ③ 敏感数据加密审计 │ │ │ │ 日志查询) │ │ ④ 越权测试 │ │ │ │ ③ 逐步增加并发 │ │ ⑤ AI对比差异 + │ │ │ │ ④ AI输出对比曲线 │ │ 给出安全建议 │ │ │ └────────────────────┘ └────────────────────┘ │ └────────────────────────────────────────────────────────────────────────┘ ``` ### 3.2 功能覆盖度矩阵（示例片段） | 功能模块 | 功能点 | 泰岳版 | 自研版 | 完成度 | 备注 | |---------|--------|--------|--------|--------|------| | 认证 | 密码认证 | ✓ | ✓ | 100% | | | 认证 | 短信验证码 | ✓ | ✓ | 100% | | | 认证 | 人脸识别认证 | ✓ | ✓ | 100% | 金科接口 | | 认证 | SIM卡无感认证 | — | ✓ | 100% | 自研特有 | | 认证 | LDAP集成 | ✓ | ☐ | 0% | 二期 | | 认证 | MFA策略配置 | ✓ | ✓ | 100% | | | 账号 | 账号新建 | ✓ | ✓ | 100% | | | 账号 | 账号批量导入 | ✓ | ✓ | 100% | | | 账号 | 账号同步(多源) | ✓ | ✓ | 100% | | | 账号 | 密码策略配置 | ✓ | ✓ | 100% | | | 应用SSO | OIDC协议 | ✓ | ✓ | 100% | | | 应用SSO | SAML协议 | ✓ | ✓ | 80% | 部分场景验证中 | | 应用权限 | RBAC模型 | ✓ | ✓ | 100% | | | 应用权限 | ABAC策略 | — | ✓ | 100% | 自研特有 | | 应用权限 | 临时授权 | ✓ | ✓ | 100% | | | 系统资源 | 资产纳管 | ✓ | ✓ | 100% | | | 系统资源 | 批量导入资产 | ✓ | ✓ | 100% | | | 系统资源 | 命令白名单 | ✓ | ✓ | 100% | | | 系统资源 | 命令拦截 | ✓ | ✓ | 100% | | | 系统资源 | 密码轮换 | ✓ | ✓ | 50% | 实现中 | | 堡垒机 | SSH单点登录 | ✓ | ✓ | 100% | | | 堡垒机 | RDP单点登录 | ✓ | ☐ | 0% | 二期 | | 堡垒机 | 会话录制 | ✓ | ✓ | 100% | | | 堡垒机 | 会话回放 | ✓ | ✓ | 80% | 播放器优化中 | | 审计 | 操作日志 | ✓ | ✓ | 100% | | | 审计 | 合规规则引擎 | — | ✓ | 100% | 自研特有 | | 审计 | 定时报表 | ✓ | ✓ | 100% | | | 审计 | 自定义报表 | ✓ | ✓ | 80% | 查询条件还在完善 | ### 3.3 比对验证AI Agent（核心设计） ```yaml 验证Agent设计: 输入: - 泰岳版API/界面操作录制 - 自研版API/界面操作 - 期望行为描述 处理流程: 1. 理解场景: 从录制内容中提取操作步骤和预期结果 2. 脚本生成: 将操作步骤转换为可执行的测试脚本 3. 双系统执行: 并行在泰岳版和自研版中执行 4. 结果采集: 捕获接口请求/响应、页面状态、数据变更 5. 差异分析: - 返回JSON字段差异 - 流程状态机步骤差异 - 数据持久化差异 - 错误处理差异 6. 差异分级: Critical: 功能缺失/数据丢失 Major: 行为不符合预期 Minor: 界面/错误提示文本差异 Info: 实现方式不同但结果一致 7. 报告生成: 输出结构化差异报告 输出: - 功能覆盖度百分比 - 行为一致度评分 - 差异清单（含分级和截图/调用链） - 建议排期（哪些差异需要立即修复） ``` --- ## 4. 用户发现问题 → 闭环解决的AI全链路支持 ### 4.1 问题闭环流程 ``` ┌──────────────────────────────────────────────────────────────────────┐ │ 用户反馈 → AI初步诊断 → 自动修复/路由 → 人工确认 → 知识沉淀 │ │ │ │ 阶段1: 用户反馈 │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ 用户: "我通过4A跳转到报销系统，显示'无权限'，但我昨天还能用" │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 阶段2: AI初步诊断 │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ AI Agent 自动排查： │ │ │ │ ① 查询该用户的权限分配记录（最近变更） │ │ │ │ ② 查询报销系统的应用注册配置是否变更 │ │ │ │ ③ 查询用户所属组织的角色继承链路 │ │ │ │ ④ 检查授权有效期是否已过期 │ │ │ │ ⑤ 模拟该用户的权限验证请求 │ │ │ │ │ │ │ │ 初步结论：用户角色有效期已过期（昨日到期） │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 阶段3: 自动修复 / 路由 │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ 自动处理： │ │ │ │ ① 生成角色续期申请单（自动填充用户信息+原有角色） │ │ │ │ ② 推送给用户的直接上级审批 │ │ │ │ ③ 回复用户："经排查，您对报销系统的访问权限已于昨日到期。 │ │ │ │ 已为您生成续期申请，请等待审批人确认，预计5分钟内恢复。" │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 阶段4: 人工确认 │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ 审批人确认 → 权限生效 │ │ │ │ AI自动通知用户："权限已恢复，请重新登录报销系统" │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 阶段5: 知识沉淀 │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ AI将本次问题 + 排查链路 + 修复方案 存入"问题知识库" │ │ │ │ 同类问题下次出现时，AI可更快定位 + 自动修复 │ │ │ │ 定期输出"常见问题处理SOP" 给运维团队 │ │ │ └──────────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────────┘ ``` ### 4.2 问题知识库设计 ```sql CREATE TABLE T_ISSUE_KNOWLEDGE ( id BIGINT PRIMARY KEY AUTO_INCREMENT, issue_type VARCHAR(64) NOT NULL COMMENT '问题类型', symptom TEXT NOT NULL COMMENT '用户描述的症状', diagnosis_steps JSON NOT NULL COMMENT '排查步骤(结构化)', root_cause TEXT COMMENT '根因分析', solution TEXT COMMENT '解决方案', auto_fixable TINYINT NOT NULL DEFAULT 0 COMMENT '是否可自动修复', auto_fix_script TEXT COMMENT '自动修复脚本/指令', severity VARCHAR(16) COMMENT 'high/medium/low', occurrence_count INT NOT NULL DEFAULT 1, last_occurrence DATETIME, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_issue_type (issue_type), INDEX idx_symptom (symptom(100)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='问题知识库'; ``` ### 4.3 AI闭环成熟度模型 | 阶段 | 能力 | 目标月份 | |------|------|---------| | L1: 人工全流程 | 用户反馈 → 人工排查 → 人工修复 | 第1个月 | | L2: AI辅助诊断 | AI根据知识库推荐排查路径 + 建议修复方案 | 第1-2个月 | | L3: AI半自动修复 | AI可处理 >50% 的常见问题（权限过期、配置错误等） | 第2个月+ | | L4: AI全自动闭环 | AI自动发现、自动诊断、自动修复、自动通知 | 后续迭代 | --- ## 5. 技术实现要点 ### 5.1 AI工具链选型 | 用途 | 工具/平台 | 备注 | |------|----------|------| | 代码生成 | Claude / DeepSeek Coder | 用于核心逻辑编写 | | 代码审查 | DeepSeek + 自定义规则 | 自动化Review | | 测试生成 | AI Agent（自定义实现） | 基于接口定义生成 | | 比对验证 | AI Agent | 录制→回放→比对 | | 部署编排 | Ansible + AI生成Playbook | 配置即代码 | | 运维Agent | 自建Agent框架 | 使用LLM API | | 知识库 | 向量数据库（Milvus/Chroma） | 问题案例语义搜索 | ### 5.2 Prompt策略 | 场景 | Prompt策略 | |------|-----------| | 代码生成 | 给出完整的表结构、接口规范、业务规则描述，要求严格遵循 | | 测试生成 | 给出API定义，要求覆盖正常/异常/边界/安全场景 | | 问题诊断 | 给出系统日志、用户描述、相关配置，要求结构化输出排查链路 | | 比对验证 | 给出双系统的操作结果，要求逐字段比对并分级差异 | ### 5.3 重要提醒 > **AI不是银弹**。关键约束： > 1. AI生成的代码必须经过人工安全审查——尤其涉及认证和授权的逻辑 > 2. AI不擅长系统架构决策——架构师责任不可外包 > 3. AI生成的测试用例依赖人类确认预期结果是否正确 > 4. 数据一致性场景AI不能100%信任——关键路径需人工复核 > 5. 泰岳版接口反推中，AI只能辅助分析，最终结论需人工验证