Z-Image Atelier企业级实战：基于.NET框架构建内部AI绘图平台
最近和几个做企业IT的朋友聊天，发现大家都有个共同的烦恼：公司里设计资源永远不够用。市场部要海报，产品部要配图，运营部要活动图，设计团队天天加班也忙不过来。外购图片版权贵，找外包沟通成本高，自己招设计师又得养一个团队。
正好我们公司前段时间用Z-Image Atelier搭了个内部的AI绘图平台，现在市场、产品、运营的同事都能自己生成一些基础的图片素材，设计团队终于能腾出手来做更核心的创意工作了。整个过程用.NET技术栈实现，和公司现有的OA系统、权限体系无缝对接，跑了大半年，效果挺不错的。
今天我就把这个实战案例分享出来，如果你也在.NET技术栈的企业里，想解决类似的设计资源瓶颈问题，这篇文章应该能给你一些直接的参考。
1. 为什么要在企业内部搭建AI绘图平台？
先说说我们当初为什么要做这件事。最直接的痛点就是设计需求爆炸式增长，但设计人力跟不上。一个简单的产品介绍图，从提需求到设计出稿，走完流程可能要两三天，如果中间有修改，时间就更长了。
我们也试过让市场同事用一些在线的AI绘图工具，但很快就遇到了新问题。一是数据安全顾虑，公司产品图、宣传素材上传到第三方平台总是不太放心；二是账号管理混乱，每个人自己注册账号，费用不好管控，生成的素材也散落在各处；三是效果不稳定，不同人用的提示词五花八门，生成的图片质量参差不齐。
所以我们就想，能不能在公司内部搭一个自己的AI绘图平台？让有需求的同事在内部系统里就能生成图片，既保证数据不出内网，又能统一管理账号和素材，还能沉淀一些好的提示词模板给大家复用。
Z-Image Atelier这个开源项目正好进入了我们的视野。它基于Stable Diffusion，功能比较完整，而且提供了API接口，方便我们做二次开发和集成。最关键的是，它可以用Docker部署，和我们现有的.NET技术栈能很好地结合。
2. 整体架构设计思路
我们的目标很明确：不是做一个给技术玩家用的玩具，而是做一个企业员工能真正用起来的生产力工具。所以整个平台的设计都围绕着“易用、安全、可控”这三个核心原则。
平台的整体架构分为四层：
基础服务层：就是Z-Image Atelier本身，我们把它部署在公司的GPU服务器上，通过Docker容器化，确保环境隔离和资源可控。
业务逻辑层：用ASP.NET Core开发的管理后台，处理所有的业务逻辑，比如用户管理、任务调度、素材库管理、权限控制等。
集成接口层：这一层负责和公司现有的系统打通，主要是单点登录集成和消息通知集成。
前端展示层：一个简洁的Web界面，让非技术同事也能轻松上手使用。
2.1 技术选型考虑
为什么选择.NET技术栈？其实很简单，因为我们公司现有的系统大部分都是基于.NET开发的，技术团队对这套技术栈最熟悉，开发效率最高。而且.NET Core的跨平台特性也让我们在Linux服务器上部署毫无压力。
具体的技术组件我们用了这些：
- 后端框架：ASP.NET Core 6.0
- 数据库：SQL Server（公司标准数据库）
- 缓存：Redis，用于任务队列和会话管理
- 消息队列：RabbitMQ，处理图片生成任务的异步调度
- 前端：Vue 3 + Element Plus，前后端分离
- 容器化：Docker + Docker Compose
这样的技术栈选择，既能充分利用团队现有技术积累，又能保证系统的稳定性和可扩展性。
3. 核心功能模块实现
3.1 用户权限与组织架构集成
这是企业级应用首先要解决的问题。我们公司已经有完善的AD域控和OA系统，员工信息、部门架构都在里面。所以我们的平台第一件事就是实现单点登录。
我们在ASP.NET Core里配置了Windows身份验证，员工用公司电脑登录，自动就获取了Windows身份信息。然后通过一个同步服务，定期从OA系统同步部门组织和员工信息到本地数据库。
权限设计我们做了两级控制：
- 功能权限：谁能使用绘图功能，谁能管理素材库，谁能查看使用统计等
- 资源权限：不同部门只能看到自己部门的素材，敏感部门的生成记录有特殊保护
代码实现上，我们用了ASP.NET Core的Policy-Based授权，定义了一系列的策略：
// 定义绘图权限策略 services.AddAuthorization(options => { options.AddPolicy("CanGenerateImage", policy => policy.RequireClaim("Permission", "image.generate")); options.AddPolicy("CanManageTemplates", policy => policy.RequireClaim("Permission", "template.manage")); options.AddPolicy("DepartmentAccess", policy => policy.Requirements.Add(new DepartmentRequirement())); }); // 部门访问权限检查 public class DepartmentHandler : AuthorizationHandler<DepartmentRequirement> { protected override Task HandleRequirementAsync( AuthorizationHandlerContext context, DepartmentRequirement requirement) { var userDept = context.User.FindFirst("Department")?.Value; var resourceDept = requirement.DepartmentId; if (userDept == resourceDept || IsDepartmentManager(context.User, userDept)) { context.Succeed(requirement); } return Task.CompletedTask; } }这样设计的好处是，新员工入职后，只要在OA系统里分配好部门，就能自动获得相应的绘图权限，不需要额外配置。
3.2 任务调度与队列管理
图片生成是个比较耗时的操作，特别是高清大图，可能需要几十秒甚至几分钟。如果让用户同步等待，体验会很差。所以我们设计了异步任务调度系统。
当用户提交一个生成任务时，前端立即返回一个任务ID，然后任务被放入RabbitMQ队列。后端有专门的Worker服务从队列中取出任务，调用Z-Image Atelier的API生成图片，生成完成后把结果保存到存储服务器，并更新任务状态。
我们给任务设计了几个状态：等待中、生成中、已完成、失败、已取消。用户可以在任务列表里看到自己所有任务的状态，对于生成中的任务，还会显示预估剩余时间。
// 任务提交服务 public class ImageGenerationService { private readonly IMessageProducer _producer; private readonly ITaskRepository _taskRepository; public async Task<GenerateTask> SubmitGenerationTask(GenerationRequest request, string userId) { // 创建任务记录 var task = new GenerateTask { TaskId = Guid.NewGuid().ToString(), UserId = userId, Prompt = request.Prompt, Status = TaskStatus.Pending, CreatedAt = DateTime.UtcNow }; await _taskRepository.AddAsync(task); // 发送到消息队列 var message = new GenerationMessage { TaskId = task.TaskId, Request = request }; await _producer.PublishAsync(message, "image.generation.queue"); return task; } } // Worker服务处理任务 public class GenerationWorker : BackgroundService { protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { var message = await _consumer.ConsumeAsync("image.generation.queue"); if (message != null) { try { await ProcessGenerationTask(message); } catch (Exception ex) { // 更新任务状态为失败 await UpdateTaskStatus(message.TaskId, TaskStatus.Failed, ex.Message); } } await Task.Delay(1000, stoppingToken); } } private async Task ProcessGenerationTask(GenerationMessage message) { // 调用Z-Image Atelier API var result = await _atelierClient.GenerateImageAsync(message.Request); // 保存生成的图片 var imageUrl = await _storageService.SaveImageAsync(result.ImageData); // 更新任务状态 await UpdateTaskStatus(message.TaskId, TaskStatus.Completed, imageUrl); } }我们还做了任务优先级管理。比如市场部的紧急活动图可以设置高优先级，插队到队列前面。同时限制了单个用户的同时任务数，防止有人占用太多资源。
3.3 提示词模板与素材库管理
让非设计专业的同事写出好的提示词是个挑战。我们观察发现，大家最需要的是“开箱即用”的模板。所以我们在系统里内置了一个模板库，按使用场景分类。
比如“电商产品图”模板，里面预置了背景、灯光、风格等参数，用户只需要替换产品名称和主要卖点就行。“社交媒体配图”模板则针对不同平台做了优化，微信朋友圈的尺寸和风格，小红书又是另一套。
模板管理后台让设计团队的同事可以创建和维护这些模板。他们可以把一些成功的案例保存为模板，分享给全公司使用。我们还加了模板评分功能，用的人多的、好评多的模板会排在前面。
素材库的管理我们借鉴了网盘的设计。每个用户有自己的个人空间，每个部门有共享空间。生成的图片自动保存到个人空间，如果觉得某张图特别好，可以移动到部门共享空间，或者申请放到公司公共素材库。
为了防止素材库变成垃圾场，我们设定了自动清理规则：个人空间里30天未使用的图片会自动标记，60天后自动删除。重要的图片可以手动加星标，避免被清理。
3.4 与现有系统的工作流集成
光有绘图功能还不够，要真正融入工作流程才有价值。我们做了几个关键的集成点：
OA审批集成：有些敏感场景的图片生成需要审批，比如涉及公司品牌形象的。我们在OA里加了一个“AI绘图申请”的流程，审批通过后，申请单里的信息会自动带到绘图平台，生成好的图片也会回传到申请单附件。
企业微信通知：图片生成完成后，自动通过企业微信通知用户。如果生成失败，也会通知用户和系统管理员。
设计软件对接：设计团队的同事经常用Photoshop、Figma，我们提供了插件，让他们可以直接从这些软件里调用平台的AI绘图功能，生成的图片直接插入到设计稿中。
这些集成看起来是小功能，但实际用起来特别顺手。市场部的小王说，以前做一个活动海报，要在OA提需求、等设计出图、反复修改，现在大部分基础图自己就能搞定，只有最后的精修需要找设计师，效率提升了一大截。
4. 实际运行效果与优化
平台上线运行了半年多，接入的部门从最初的市场部，慢慢扩展到了产品、运营、销售甚至HR部门。有些数据还挺有意思的：
- 平均每天有200多个生成任务，高峰期（比如大型活动前）能达到500+
- 用户最喜欢的模板前三名：产品展示图、社交媒体配图、活动海报背景
- 平均每个任务节省设计沟通时间约2小时
- 设计团队用于基础制图的时间减少了40%，能更多投入在创意设计上
当然过程中也遇到一些问题，我们做了不少优化：
性能优化：最初图片生成慢，用户抱怨多。我们分析发现主要是GPU资源争抢。后来我们做了任务调度优化，把高清大图任务安排在夜间批量处理，白天优先处理小图、快速图任务。同时加了资源监控，GPU使用率超过80%时自动限流。
提示词优化：很多同事一开始写的提示词太简单，生成的图片质量不高。我们做了两件事：一是在生成界面加了提示词建议，根据用户选择场景推荐关键词；二是开了几次培训小课堂，教大家怎么写好提示词。
成本控制：GPU服务器不便宜，我们设定了部门额度管理。每个部门每月有一定的免费额度，超出部分需要部门负责人审批。这样既避免了资源浪费，也让各部门更合理地规划使用。
5. 总结
回过头看这个项目，我觉得最大的价值不是技术有多先进，而是真正解决了业务部门的实际问题。技术团队容易陷入“为技术而技术”的陷阱，总想用最新最炫的技术方案。但这个项目让我们意识到，有时候最简单的方案就是最好的方案。
用.NET技术栈，因为团队熟悉；集成现有OA系统，因为用户习惯；设计模板库，因为大多数用户不是专业人士。每一个设计决策都围绕着“怎么让用户用得更顺手”这个核心。
如果你也在考虑在企业内部搭建类似的AI绘图平台，我的建议是：从小处着手，快速验证。不用一开始就追求大而全的系统，可以先搭一个最小可用版本，找一两个部门试点，收集反馈，快速迭代。技术方案选择团队最熟悉的，集成优先考虑用户最常用的系统。
我们平台现在还在持续迭代，下一步计划加入图片编辑功能，让用户能在生成的图片上直接加文字、调颜色。也在探索多模型支持，不同的绘图任务用不同的模型，效果会更好。
技术最终要服务于业务，能解决实际问题的技术才有生命力。这个基于Z-Image Atelier和.NET的AI绘图平台，就是我们在这个方向上的一次实践。希望这个案例能给你带来一些启发。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
