CloudAI Fusion 是一个开源的云原生 AI 一体化管理平台，将多云管理、GPU 拓扑感知调度、AI 智能体与安全合规统一到一个平台中。本文将带你了解它的下一步路线图——包括 Live 基础设施集成 CI、L16 集群级数据平面强制执行与 AI 引擎深度化三大方向，并给出完整的社区贡献指南：从本地环境搭建、DCO 签署到 PR 合并的全流程，帮助你快速成为项目贡献者。

一、先认识 CloudAI Fusion：以"诚实"为设计原则的平台

CloudAI Fusion 最独特的地方是运行模式诚实框架：每个依赖边界（数据库、缓存、消息、共识、调度等）都会如实报告自己是真实后端还是内存模拟，由单一的run_mode配置管控：

通过GET /api/v1/capabilities可以随时查看每个子系统的真实/模拟状态。这意味着平台不会"假装"一个假的后端是真实的——进度由可查询的 API 客观度量，而非营销话术。详见 README.md。

💡 这一原则贯穿全部 53 个功能模块，也是理解后续路线图的关键：下一步计划本质上就是让更多"模拟"变成"真实"。

二、当前版本已交付的能力

根据 README 官方路线图，当前版本已完成：

• ✅诚实运行模式框架+ 能力注册表 + 生产环境快速失败
• ✅真实驱动：Redis / NATS / Kafka / Kubernetes Lease 选主 / ArgoCD + Flux
• ✅可验证控制平面：Ed25519 签名、哈希链、Merkle 透明日志（pkg/evidence）
• ✅可验证 AI 红队：范围门控、证据签名、LLM 规划器（pkg/redteam）
• ✅AISecOps 16 个深度井：L1 情报（ClickHouse + STIX 2.1）、L3 端点 EDR、L8 自动响应
• ✅DevSecOps + SLSA：cosign 无密钥签名、SLSA L3 溯源、SBOM

三、下一步路线图：三大方向

3.1 方向一：Live 基础设施集成 CI（真环境验证）

这是最核心的下一步——把目前"依赖外部资源、暂时报告为模拟"的能力，放进 CI 用真实环境验证：

作为参照，现有 CI 已经在.github/workflows/ci.yml中引入了真实 PostgreSQL 16、Redis 7、ClickHouse服务容器——L1 情报后端的"真实"就是靠 CI 活体测试变成"可验证的事实"而非口头声明，而非跳过。Live 基础设施 CI 将沿用同一思路，向 L16 集群协调与红队评测扩展。

3.2 方向二：L16 集群协调的数据平面强制执行

跨集群故障转移（L16 Deep Well）目前完成度约 50%，目标是实现集群协调的数据平面强制执行：备用集群切换时，用 Merkle Tree 校验配置一致性，配合 TEE 可信硬件（L15）实现"可验证的容灾"。

• 详细方案：L15_L16_DeepWell_Integration_Plan.md
• 差距修复计划：HOLLOW_FUNCTION_REMEDIATION_PLAN.md

3.3 方向三：AI 引擎深度化

Python AI 引擎（FastAPI 实现，端口 8090）是下一版本的重点投入方向，提供/scheduling/optimize、/anomaly/detect、/chat、/models/status等能力。下一步聚焦：

• RL 调度优化器深度化：M10 强化学习调度环境已修复并通过 7 天生产仿真验收，Q-learning 超越基线 +24.49%，PPO/SAC 训练器已接线待激活
• 训练编排器（M14）落地 Kubernetes：核心实现（6,587 行 Go 代码，含 Θ(1) Gang 屏障、Checkpoint I/O 流水线、贝叶斯超参调优）已完成，K8s 集成目标节点为2026 年 10 月 15 日，详见 docs/M14_IMPLEMENTATION_ROADMAP.md
• 异常检测算法增强：在线 Welford + Ledoit-Wolf 收缩 + 流式联合异常检测（ai/anomaly/、docs/algorithms/）
• 新 LLM Provider 接入与提示工程优化：ai/agents/

此外，整体技术护城河成熟度计划从 75% 提升到95%+，分 P0/P1/P2 三阶段推进，进度对照表见 MOAT_FORTIFICATION_ROADMAP.md。

四、社区贡献指南：从克隆到合并的 6 步

4.1 一键安装步骤：搭建本地开发环境

环境要求：Go 1.22+、Python 3.11+、Docker、Kubernetes 1.30+（集群功能）、Helm 3.x、Make。

git clone https://gitcode.com/gh_mirrors/cl/cloudai-fusion cd cloudai-fusion go mod download # Go 依赖 cd ai && pip install -r requirements.txt && cd .. # Python 依赖 docker compose up -d postgres redis kafka # 基础设施 make run-apiserver # 启动开发模式 make test # 运行测试

完整流程见 docs/quickstart.md 与 CONTRIBUTING.md。开发模式下平台会以simulation模式启动并如实报告各后端状态，新手无需任何云资源即可上手。

4.2 提交规范：DCO 签署 + Conventional Commits

所有贡献必须按 DCO 签署开发者证书：

git checkout -b feature/your-feature develop git commit -s -m "feat(scheduler): add topology-aware placement"

提交信息遵循 Conventional Commits 格式<type>(<scope>): <description>，type 包括feat、fix、docs、test等，scope 包括apiserver、scheduler、ai-engine、security等（CONTRIBUTING.md）。

4.3 最快 PR 合并路径

1. 提交前确保make test与make lint全部通过
2. PR 描述写明：改了什么、为什么、关联 Issue、UI 变更附截图
3. 需至少 1 位维护者批准 + CI 检查（lint、测试、安全扫描）全绿 + 无合并冲突
4. 合并后删除特性分支，在 develop 环境验证

完整规则：CONTRIBUTING.md PR Process。

4.4 新手友好：我们最需要帮助的方向

来源：CONTRIBUTING.md Areas We Need Help。🌱 标记good first issue的 Issue 最适合新手入门。

4.5 常用测试命令速查

4.6 进阶贡献路径

项目为有经验的贡献者规划了 5 条进阶路径：云厂商集成（研究 pkg/cloud/interfaces.go）、调度器增强（pkg/scheduler/）、边缘计算（pkg/edge/）、FinOps/AIOps（pkg/finops/）、AI 引擎（ai/agents/），详见 CONTRIBUTING.md。重要技术决策需提交 ADR 到 docs/adr/。

五、社区治理与成长路径

• SIG 工作组：Scheduling（周一）、Security（周二）、Edge（周三）、AI（周四）双周例会，FinOps 月度例会
• 贡献者等级：Contributor（1 个 PR）→ Regular Contributor（5 个 PR）→ Reviewer（10 个 PR + 领域专长）→ Core Contributor → Maintainer
• 社区渠道：GitHub Discussions、CNCF Slack#cloudai-fusion、微信群、双周四 UTC 10:00 Office Hours
• 许可证：Apache License 2.0，参与即表示同意贡献代码以该协议授权并签署 DCO

六、写在最后

CloudAI Fusion 的路线图可以用一句话概括：让更多能力从"如实报告的模拟"变成"CI 验证过的真实"——Live 基础设施集成 CI、L16 集群级强制执行、AI 引擎深度化，每一条都欢迎你的参与。无论你是 Go 后端开发者、Python 算法工程师，还是文档与测试贡献者，都有明确的切入点和成长路径。现在克隆仓库，从第一个good first issue开始吧！🚀

📌 延伸阅读：架构文档 · API 指南 · 最佳实践 · 安全政策 · 治理文档