云萱 AI 原生工程平台：从需求到上线的全链路 AI 自动化实践

前言

在 AI 编程工具飞速发展的今天，我们已经习惯了用 Copilot 补全代码、用 ChatGPT 解答问题。但真正的 AI 原生工程远不止于此——它应该是一种从需求到上线的全链路思维方式变革。

云萱 AI 原生工程平台（Yunxuan AI Engineering Platform） 正是基于这个理念构建的。它不是一个简单的代码生成器，而是一套完整的 AI 驱动软件工程工作流系统，目标是让 AI 真正参与到软件研发的每一个环节。

本文将带你深入了解这个平台的技术栈、核心架构、运行逻辑，以及一些真实的运行数据。

---

一、平台定位与核心理念

1.1 我们要解决什么问题？

传统软件开发流程中，存在大量的”摩擦成本”：

• 📝 需求文档编写耗时、规范不统一
• 🎯 任务拆解依赖人工经验，粒度难以把控
• 🐛 Bug 跟踪与测试管理在多个系统间来回切换
• 📊 项目状态同步滞后，决策缺乏实时数据支撑
• 🔄 重复劳动多（创建 ticket、写测试用例、生成报告…）

AI 不应该只在”写代码”这一个环节发挥作用，而应该贯穿整个研发生命周期。

1.2 核心理念：HITL + 工作流引擎

我们采用 Human-in-the-Loop（人在回路） 设计：

AI 负责执行重复性、结构化的工作；人类负责决策、审查和创造性劳动。

整个平台基于状态机工作流引擎构建，将软件开发过程拆解为 10 个标准阶段，4 个人工确认节点，确保 AI 的每一步产出都经过质量把控。

---

二、技术栈总览

2.1 后端技术栈

层次	技术选型	用途
语言	Python 3.12+	核心开发语言
Web 框架	FastAPI	API 服务层
工作流引擎	自研状态机	10 阶段流程编排
LLM	Claude / 通义千问 / 豆包	多模型支持，可切换
向量数据库	Qdrant	RAG 语义检索
任务队列	Celery + Redis	异步任务处理
数据存储	PostgreSQL	结构化数据持久化

2.2 外部系统集成

平台的一个核心能力是与现有研发工具链无缝对接，目前支持：

• Jira — 任务管理（Atlassian Cloud）
• Confluence — 文档管理（Atlassian Cloud）
• 禅道 (ZenTao) — 国产项目管理工具（可选项）
• Kiwi TCMS — 测试用例管理
• GitLab / GitHub — 代码仓库集成

💡 平台设计了统一的抽象层，新增一个外部系统只需要实现对应的 Client 接口。以禅道集成为例，从需求到落地仅用了不到一周时间。

2.3 前端与 CLI

• CLI 工具 — 基于 Typer 构建，支持 workflow、testm、docs 等命令组
• Web Dashboard — React + TypeScript（开发中）
• 配置管理 — Pydantic Settings + YAML + 环境变量，三层配置合并

---

三、核心架构解析

3.1 整体架构图

┌─────────────────────────────────────────────────────────────┐
│                        用户交互层                              │
│   CLI 工具   │   Web Dashboard   │   API 接口   │   SDK     │
└─────────────┴───────────────────┴──────────────┴───────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│                      工作流引擎层                              │
│  ┌──────────────────────────────────────────────────────┐  │
│  │              WorkflowEngine（状态机）                  │  │
│  │  10 阶段 │ 4 HITL 检查点 │ 断点续跑 │ 并发执行        │  │
│  └──────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                              │
    ┌─────────────────────────┼─────────────────────────┐
    │                         │                         │
┌───▼──────────┐    ┌─────────▼────────┐    ┌───────────▼─────┐
│  文档管理模块  │    │   任务分解模块    │    │   测试管理模块    │
│DocumentManager│    │ TaskDecomposer   │    │  TestManager    │
└──────────────┘    └──────────────────┘    └─────────────────┘
    │                         │                         │
┌───▼──────────┐    ┌─────────▼────────┐    ┌───────────▼─────┐
│  RAG 向量检索 │    │  LLM 推理服务    │    │  Bug 自动跟踪    │
│  Qdrant      │    │  多模型适配层     │    │  BugIntegration │
└──────────────┘    └──────────────────┘    └─────────────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│                    外部系统集成层                              │
│   Jira    │  Confluence  │  禅道 ZenTao  │  Kiwi TCMS  │  Git │
└───────────┴──────────────┴───────────────┴─────────────┴─────┘

3.2 工作流引擎的 10 个阶段

平台将软件开发流程标准化为以下 10 个阶段：

阶段	名称	主要工作	AI/人工
1	需求输入	用户输入项目描述	人工
2	需求文档生成	AI 生成结构化需求文档	AI
3	需求评审	人工确认需求完整性	人工 (HITL)
4	向量化存储	文档存入向量数据库	AI
5	任务拆解	Story + Sub-task 自动拆解	AI
6	任务创建	同步到 Jira/禅道	AI
7	任务确认	人工审核任务清单	人工 (HITL)
8	代码开发	AI 辅助/自动编码	AI + 人工
9	测试管理	用例生成、自动化、执行、报告	AI
10	评测与交付	AI 代码评审 + 交付报告	AI + 人工

每个阶段都有明确的输入输出、成功标准和回滚机制，确保流程可控。

3.3 多后端抽象设计

一个典型的设计模式是双后端（甚至多后端）抽象。以任务管理为例：

class TaskDecomposer:
    def __init__(self, jira_client=None, zentao_client=None):
        self.jira = jira_client
        self.zentao = zentao_client

    @property
    def use_zentao(self) -> bool:
        return self.zentao is not None and self.zentao.enabled

    def create_issues(self, decomposition):
        if self.use_zentao:
            return self.create_in_zentao(decomposition)
        return self.create_in_jira(decomposition)

这种设计让上层业务逻辑完全不感知底层用的是 Jira 还是禅道，实现了配置驱动的工具切换。

---

四、核心模块详解

4.1 文档管理模块（DocumentManager）

功能定位：需求文档的生成、版本管理、向量化和同步。

核心能力：

• ✍️ AI 需求文档生成 — 基于一句话需求，输出完整的 PRD 文档
• 📚 多平台同步 — 一键发布到 Confluence 或禅道文档
• 🔍 RAG 向量化 — 文档切片后存入 Qdrant，支持语义检索
• 🔄 版本追踪 — 记录文档的每次变更历史

向量化的设计要点：

• 按”段落 + 标题”的方式切片，保留上下文
• 同时存储结构化 metadata（分类、标签、优先级）
• 支持混合检索（语义 + 关键词）

4.2 任务分解模块（TaskDecomposer）

功能定位：将需求文档转化为可执行的任务结构。

分解策略：

1. 两层拆解法：先拆出 Epic/Story（业务维度），再拆 Sub-task（技术维度）
2. 估算注入：每个任务自动附上预估工时和优先级建议
3. 验收标准：每个 Story 自动生成 Acceptance Criteria

一个典型的分解输出：

Story: 项目初始化（估算：2h，优先级：高）
  ├─ Sub-task: 搭建 Astro + Firefly 项目骨架
  ├─ Sub-task: 配置 Tailwind CSS 与主题系统
  ├─ Sub-task: 建立内容目录与 MDX 支持
  └─ Sub-task: 基础组件库搭建

Story: 博客核心功能（估算：8h，优先级：高）
  └─ ...

4.3 测试管理模块（TestManager）

这是平台最有特色的模块之一，实现了测试全流程自动化：

1. 测试用例生成 — 基于需求文档自动生成测试用例（正向 + 边界 + 异常）
2. 自动化脚本生成 — 将测试用例转化为 pytest/playwright 脚本
3. 测试执行调度 — 本地或 CI 环境执行，收集结果
4. Bug 自动创建 — 失败用例自动在 Jira/禅道创建 Bug
5. 测试报告上传 — 报告同步到 Confluence/禅道，含通过率、覆盖率等指标
6. 回归联动 — Bug 修复后自动重跑相关用例

📊 目前测试用例生成的准确率约 85%，仍需人工抽查确认。这也是 HITL 设计的价值所在。

4.4 Bug 集成模块（BugIntegration）

智能 Bug 生命周期管理：

• 自动创建：测试失败 → 提取错误信息 → 生成 Bug 描述 → 创建 Issue
• 状态同步：双向同步 Bug 状态（Jira/禅道 ↔ 平台）
• 智能关联：自动关联失败的测试用例和对应代码文件
• 回归验证：Bug 标记为 resolved 后，自动触发回归测试

---

五、真实运行数据

5.1 项目数据概览

以本文（云萱 AI 工程平台博客）的生成过程为例，展示平台的实际运行效果：

指标	数值
需求处理时间	~2 分钟
生成的需求文档	1 篇，约 3000 字
拆解的 Story 数量	5 个
生成的 Sub-task 数量	20 个
总估算工时	~32 人时
Jira Issue 总数	25 个
Confluence 文档	2 篇（需求 + 报告）
人工介入次数	2 次（需求评审、任务确认）

5.2 Jira 看板数据

在 Jira 中，项目 AN（AI Native）下已创建：

• AN-100 ~ AN-120 — 博客重构项目的 5 个 Story + 20 个 Sub-task
• 任务类型涵盖：需求、开发任务、测试任务、部署任务
• 优先级分布：P0 × 3、P1 × 12、P2 × 10

5.3 Confluence 文档结构

My_Blog 项目空间/
├── 需求文档/
│   └── My_Blog 重构：Firefly Astro 技术博客
├── 测试报告/
│   └── 2026-10-05 测试执行报告
└── 项目周报/
    └── ...

5.4 效率提升估算

对比传统人工流程：

环节	人工耗时	AI 辅助耗时	提升倍数
需求文档编写	4-6h	5-10 min	~30x
任务拆解与创建	2-4h	2-5 min	~40x
测试用例设计	4-8h	10-20 min	~20x
测试报告生成	1-2h	1-2 min	~60x
整体	11-20h	20-40 min	~25x

⚠️ 注意：上述数据不包含代码开发本身的时间（那仍然是主要工作量）。但考虑到需求澄清、任务管理、测试管理等通常占项目总时间的 30-40%，整体效率提升仍然非常显著。

---

六、禅道集成：一个典型的扩展案例

作为平台扩展性的一个实证，我们最近完成了**禅道（ZenTao）**的集成，这里分享一些技术细节。

6.1 为什么要支持禅道？

• 国内大量中小团队使用禅道作为项目管理工具
• 开源版本功能足够，私有化部署成本低
• 平台的设计目标就是”工具无关”，禅道是很好的试金石

6.2 集成中的挑战

禅道的 API 生态不如 Jira 成熟，我们遇到了一些挑战：

1. 版本差异大 — 禅道 18.x 和 22.x 的 API 行为差异明显
2. REST API 不完整 — 部分模块（如任务创建）在旧版 API 中无法正常工作
3. 认证方式特殊 — 传统模式使用 Session + md5 嵌套加密

6.3 解决方案：混合客户端架构

我们最终采用了 REST API v1（查询） + REST API v1 POST（写入） 的混合模式：

• 查询类操作：走 REST API v1，稳定可靠
• 创建/更新类操作：用 REST API v1 POST 方式，带上完整必填字段
• 文档模块：使用 REST API v2 接口

以任务创建为例，必填字段比文档中多得多：

payload = {
    "name": task_name,
    "type": "devel",        # 任务类型
    "pri": 3,               # 优先级
    "estimate": 1,          # 预估工时（必填！）
    "estStarted": today,    # 预计开始日期（必填！）
    "deadline": deadline,   # 截止日期（必填！）
    "assignedTo": "",
    "module": 0,
    "story": 0,
}

💡 经验总结：集成企业级工具时，实际调试发现的必填字段往往是官方文档的 2-3 倍。做好预期管理很重要。

---

七、未来规划

7.1 短期（3 个月内）

• 🔧 代码生成模块增强 — 接入更多代码仓库上下文，提升 AI 编码准确率
• 📊 Dashboard 可视化 — 项目进度、AI 效率数据的可视化展示
• 🔌 更多集成 — 飞书、钉钉、企业微信等 IM 通知集成

7.2 中期（6-12 个月）

• 🤖 Multi-Agent 协作 — 不同角色的 AI Agent 协作完成复杂项目
• 🧠 长期记忆系统 — 跨项目的知识沉淀与复用
• 📈 智能预估 — 基于历史数据的工时和排期预测

7.3 长期愿景

让每个开发者都拥有一支 24 小时工作的 AI 工程团队。

---

八、写在最后

云萱 AI 原生工程平台不是要取代开发者，而是要把开发者从繁琐的流程工作中解放出来，让我们能把更多精力投入到真正需要创造力和判断力的事情上。

如果你对这个项目感兴趣，欢迎：

• ⭐ Star 关注项目进展
• 💬 提出你的想法和建议
• 🤝 参与贡献代码

AI 时代的软件工程，才刚刚开始。

---

本文由云萱 AI 原生工程平台辅助生成，人工审校发布。