1. 为什么C#开发者现在入场AI正合适
说实话,这几年我一直有个感受:C#社区聊AI的声音,比Python社区小太多了。打开各种技术社区,铺天盖地都是Python、PyTorch、TensorFlow,好像不会Python就没资格碰AI一样。但作为一个搞了十多年C#的老开发,我心里一直不服气——C#做AI应用,真的不行吗?
答案显然是否定的。
先说个最简单的例子。很多C#程序员都在做上位机、桌面应用、工业控制软件,手里攒了一堆WINFORM、WPF的项目经验。如果想把AI能力塞进这些老项目里,用Python重构?不现实,成本太高。最务实的路线就是:原项目保持不动,用C#直接调用大模型API,把AI能力作为一个模块嵌进去。
再说一个更实际的现象。我最近在带几个同事做内部工具,需求很简单——做一个能自动生成产品描述图的桌面工具。技术栈就是C# + WinForm,调用大模型API,用户输入一句话,自动生成四张图,还能预览、保存。整个过程大概用了一个周末,代码量不到五百行。如果换成Python加Flask再加前端页面,反而要折腾半天环境。
所以我想写一篇真正适合C#程序员的AI入门实战,把你从"看过不少AI文章但不知道从哪下手"的状态,直接拉到"能独立写一个能用的小工具"的水平。
这篇文章里的所有代码,都是我实际跑通过的,不是那种复制下来就报错的Demo。我会尽量把每一个"为什么这样做"讲明白,毕竟干咱们这行的都知道,光有代码没有思路,换个场景就抓瞎。
适合谁来读?已经在写C#但还没碰过AI方向的开发者;想做AI工具但不想换语言栈的人;以及那些想给现有项目加AI功能,又怕搞不定的朋友。前提是你得会基本的C#语法,知道什么是类、什么是方法、什么是异步。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选型:AI能力怎么接进来,用哪家的API
2.1 三类接入方式,先搞清楚你的场景
C#接入AI能力大概有三条路,我先把它们摆出来对比一下:
| 接入方式 | 适合场景 | 技术门槛 | 可控性 | 成本 |
|---|---|---|---|---|
| 调用云端大模型API | 快速出活,想要最强大模型能力 | 低,一个HTTP请求的事 | 一般,受API限制 | 按调用量计费 |
| 本地跑开源模型 | 数据敏感、离线环境 | 高,要处理模型推理和加速 | 高,完全掌控 | 需要买显卡或服务器 |
| 用现成SDK封装 | 不想自己写底层交互 | 最低 | 低 | 看SDK供应商 |
对于绝大多数C#开发者,尤其是第一次做AI应用的朋友,我的建议是:先从调用云端API开始。原因很简单:本地跑模型要处理CUDA、内存管理、模型格式转换,这一套下来没个把月摸不透,而且C#生态里这块资料确实少。云端API一个HTTP请求就行,让你把注意力放在"怎么用AI的能力"而不是"怎么把模型跑起来"。
2.2 为什么我推荐用HTTP请求而不是官方SDK
很多人一上来就找"有没有C#版SDK"。有,有一些大模型厂商确实提供了.NET SDK,但我个人更推荐直接用HTTP请求调API。
第一,HTTP请求是普适的。不管你今天用哪家的大模型,还是明天想换一家,底层交互方式本质上都是POST一个JSON过去,再收一个JSON回来。学会一次,终身受用。SDK的封装虽然省事,但每家的SDK设计风格都不一样,换一家就要重学一套。
第二,SDK本质也是包了一层HTTP请求,你在外面套SDK反而不好排查问题。API返回报错了,SDK把错误信息一包装,你反而搞不清楚到底是参数问题还是网络问题。直接看原始请求和原始返回,啥都清清楚楚。
第三,有些SDK更新不及时,尤其是偏门一点的模型服务。等他们适配,不如自己写一个HttpClient调用类,十分钟的事,稳定可控。
2.3 模型选哪个:理解一下"能聊天的"和"能画图的"
AI应用分两大类,一类是文字对话,一类是生成图片。初次上手,我建议你先做图片生成。为什么?因为图片生成的效果反馈非常直观——你说一句话,出来四张图,肉眼可见,特别有成就感。文字对话你还要考虑上下文、流式输出这些交互细节,上手门槛其实更高。
图片生成这块,大多数大模型厂商都有对应的API接口,参数大同小异,核心就是给一个Prompt提示词,返回图片的URL或Base64编码。我用的方案是部署在云端的一个图像生成模型,背后是英文提示词理解能力比较强的模型,直接用HTTP POST调用。
这里提醒一句:无论你选哪家,一定要先看清楚API文档里的鉴权方式和请求格式。现在大模型API基本都是用Token做鉴权,一个Key走天下,但有的放请求头里,有的放请求体里,有的要求Bearer前缀,别搞混了。
3. 动手前的准备:密钥申请、项目骨架、环境细节
3.1 获取API密钥,注意几个容易踩的坑
每个大模型平台都有自己的密钥申请流程,大致都是:注册账号、实名认证、开通对应服务、拿到API密钥。这里重点提醒几个坑:
第一,密钥一定要放服务端环境变量里,千万不要硬编码进代码。我见过不少人把API Key直接写在WinForm的cs文件里,然后代码传到Gitee私有仓库,后来仓库泄露,一夜之间被刷了几千块钱的调用量。正确做法是在本地环境变量里设置,代码里用Environment.GetEnvironmentVariable去读。
第二,开通服务之后,先看一眼免费额度或用完即止的设置。有些平台默认是持续扣费模式,没有额度上限管控,新手很容易在调试循环里把额度烧完。建议先把每次调用上限、每日限额设好再动手。
第三,密钥创建后只显示一次,如果你没有保存下来,只能重新创建一个。这个纯属个人经验教训,别问我是怎么知道的。
3.2 项目结构:WinForm程序怎么组织代码最顺手
既然是C#程序员入门AI,我默认你用的是Visual Studio,项目类型就选"Windows窗体应用(.NET Framework)"或者".NET Core Windows Forms"。如果你用的是.NET 6及以上,项目结构会清爽很多,依赖管理也方便。
我的建议是项目建好之后,把代码稍微分一下文件夹,不要全部堆在Form1.cs一个文件里:
code复制AIDemo/
├── Form1.cs // 界面逻辑
├── AIService/ // AI服务调用
│ └── ImageGenService.cs // 图片生成服务类
├── Models/ // 数据模型
│ └── ImageGenResult.cs // 生成结果模型
├── Common/
│ └── HttpHelper.cs // HTTP请求封装(其实可以不用)
└── app.config // 配置文件
说实话,只有几百度行的工具,不分文件夹也不影响运行。但分一下的好处是:后续你想扩展功能时,不用在Form1里翻几百行去找一个方法。我做这类工具的习惯是:界面代码和业务逻辑严格分离,窗体文件里只管按钮点击、ListView绑定这些UI操作,真正的API调用、数据处理全放独立的Service类里。
3.3 一个关键细节:目标平台的设置
如果你是64位Win11系统,项目用默认的"AnyCPU"平台目标,大概率能正常运行。但如果你在代码里要加载本地方言模型做音频识别,或者用到了某些需要本机DLL的库,就得注意把"平台目标"改成"X64"。这一块很多人容易忽略,等到报"未能加载DLL"错误时才开始排查,白白浪费一个小时。我的建议是一开始就把目标平台设为X64,省得后面麻烦。
这里顺手提一句:模型服务调用不需要GPU,也不需要本地装什么CUDA Toolkit,你的机器只要能上网,能跑Visual Studio,就足够了。
4. 第一个能跑通的AI应用:生成一张图片
4.1 API调用到底是怎么一回事,先理解再写代码
大模型的API调用,本质上就是一次HTTP POST请求。你给服务器发送一段JSON,里面包含你的指令(Prompt)、模型名称、参数设置,服务器处理完,给你返回一段JSON,里面就有生成结果。
类比一下:你就像在饭店点菜。你递给服务员一张菜单(Prompt指令),服务员送到后厨(大模型服务器),后厨做完菜端出来(返回结果)。中间过程你不用管,只需要把菜单写清楚,然后等着收菜就行。
C#里面发HTTP请求很简单,用HttpClient就够了。核心代码长这样:
csharp复制using System.Net.Http;
using System.Text;
using System.Text.Json;
public class ImageGenService
{
private readonly HttpClient _httpClient;
private readonly string _apiKey;
private readonly string _endpoint;
public ImageGenService()
{
_httpClient = new HttpClient();
_apiKey = Environment.GetEnvironmentVariable("AIModelAPIKey");
_endpoint = "https://api.xxx.com/v1/images/generations";
}
public async Task<string> GenerateImageAsync(string prompt)
{
var request = new
{
prompt = prompt,
n = 1,
size = "1024x1024"
};
var json = JsonSerializer.Serialize(request);
var content = new StringContent(json, Encoding.UTF8, "application/json");
_httpClient.DefaultRequestHeaders.Clear();
_httpClient.DefaultRequestHeaders.Add("Authorization", $"Bearer {_apiKey}");
var response = await _httpClient.PostAsync(_endpoint, content);
var responseBody = await response.Content.ReadAsStringAsync();
if (!response.IsSuccessStatusCode)
{
throw new Exception($"API调用失败:{response.StatusCode} - {responseBody}");
}
using JsonDocument doc = JsonDocument.Parse(responseBody);
var imageUrl = doc.RootElement
.GetProperty("data")[0]
.GetProperty("url")
.GetString();
return imageUrl;
}
}
这段代码建议你亲手敲一遍,不要复制。敲的过程中你会自然注意到HttpClient的用法、JSON序列化的结构、如何从响应里取数据——这些都是AI应用开发的"肌肉记忆"。
4.2 UI界面怎么写:两分钟搞定的WinForm
窗体设计很简单,我用了一个ListBox显示任务状态,一个RichTextBox显示结果URL,一个TextBox输入提示词,一个Button触发生成。
这里有一个新手很容易掉进去的坑:直接在线程池里调用async方法,导致UI卡死。WinForm的UI线程和后台线程是有严格区分的,你在按钮点击事件里用async void异步方法,没问题的;但如果你在一个同步循环里等待异步方法,就会死锁。
正确写法是:
csharp复制private async void btnGenerate_Click(object sender, EventArgs e)
{
try
{
btnGenerate.Enabled = false;
listBox1.Items.Add("正在生成,请稍候...");
var service = new ImageGenService();
var imageUrl = await service.GenerateImageAsync(txtPrompt.Text.Trim());
listBox1.Items.Add("生成成功!");
txtResult.Text = imageUrl;
AddImageToListView(imageUrl);
}
catch (Exception ex)
{
listBox1.Items.Add($"生成失败:{ex.Message}");
MessageBox.Show($"出错了:{ex.Message}");
}
finally
{
btnGenerate.Enabled = true;
}
}
几点说明:
async void在UI事件里是唯一合法的用法,其他地方一律用async Task,这个约定别打破。await关键字会保留UI上下文,所以await之后是可以直接操作UI控件的,不需要BeginInvoke那套老写法。- 生成过程中把按钮禁掉,防止用户狂点导致重复请求。
4.3 跑起来了,然后呢:图片拿到之后怎么处理
API返回的通常是一个图片URL,你需要把它下载下来显示在界面上。这里给一个图片下载方法:
csharp复制private async void AddImageToListView(string url)
{
using var client = new HttpClient();
byte[] imageBytes = await client.GetByteArrayAsync(url);
using var ms = new MemoryStream(imageBytes);
var img = Image.FromStream(ms);
var newImg = new Bitmap(img, new Size(256, 256));
var imgList = new ImageList { ImageSize = new Size(256, 256) };
imgList.Images.Add(newImg);
listView1.LargeImageList = imgList;
var item = new ListViewItem($"图片 {listView1.Items.Count + 1}", 0);
listView1.Items.Add(item);
// 顺手把图片保存到本地
string fileName = $"output_{DateTime.Now:yyyyMMdd_HHmmss}.png";
newImg.Save(fileName);
listBox1.Items.Add($"已保存到 {Path.GetFullPath(fileName)}");
}
注意Image.FromStream这个方法有个坑:Stream必须保持打开状态直到图片被完全使用,否则会报"参数无效"。所以我用using块包裹MemoryStream,再在using块里完成图片处理和Bitmap转换,确保不出问题。
到这里,你已经拥有了一个真正能用的AI图片生成工具。虽然简陋,但千里之行始于足下,这个Demo成功跑通的意义在于:你验证了从C#程序调通大模型API的整条链路,后面所有的扩展都是在这条链路上做加法。
5. 进阶玩法:生成四张图、流式输出与并发优化
5.1 从一张到四张:参数与代码调整
只生成一张图不过瘾,我很快就把功能升级成了"一句话生成四张图"。改起来其实很简单,大多数图像生成API有一个n参数,表示一次要生成几张,改成4就行:
csharp复制var request = new
{
prompt = prompt,
n = 4, // 让模型一次返回四张
size = "1024x1024"
};
但如果你用的API不支持一次返回多张图,那就得在代码里并发调用四次。这里有个很关键的性能问题:四次串行请求要等四次网络往返时间,并发请求只需等最慢的那一次。
用C#的Task.WhenAll做并发非常简单:
csharp复制var tasks = new List<Task<string>>();
for (int i = 0; i < 4; i++)
{
tasks.Add(GenerateOneImageAsync(prompt + $" - 风格变体{i+1}"));
}
string[] urls = await Task.WhenAll(tasks);
Task.WhenAll会把多个任务并行执行,全部完成后一次性返回。这个模式在AI应用里非常常见,因为大模型API的调用是纯IO操作,天然适合异步并发。但要注意:并发数量不要太高,一般API都会限流,并发10个以上很可能被拒。
5.2 让进度可视化:加一个流式输出的状态提示
生成四张图的时候,用户会在界面干等。如果没有任何反馈,用户会怀疑程序卡死了。我给ListBox加了一个简单的进度提示:
csharp复制listBox1.Items.Add($"正在生成第1张...");
await Task.Delay(500);
这个做法其实是取巧了,因为我也不知道每张图具体什么时候完成。更好的方案是,把每个生成任务包装成一个带状态的对象:
csharp复制public class GenerateTask
{
public int Index { get; set; }
public string ImageUrl { get; set; }
public bool IsCompleted { get; set; }
}
然后在每个任务完成时,通过Progress<T>报告进度,更新UI。这样用户就能看到"第2张已完成,正在生成第3张..."这种直观的反馈。
5.3 解决WinForm的UI冻结问题:await和Task的组合落地
WinForm的UI冻结,本质原因是UI线程被阻塞了。很多新手写多线程,喜欢用Thread.Sleep(1000)去模拟等待,但这会把UI线程睡死,界面立刻无响应。
正确的做法是,用async/await配合Task.Delay,让出UI线程:
csharp复制// 错误示范:这会冻住界面
Thread.Sleep(1000);
// 正确示范:异步等待,UI还能响应用户操作
await Task.Delay(1000);
这里面的原理是:await会把后续代码注册为回调,先让出线程回到消息循环,等异步操作完成后再继续执行后续代码。用生活里的事打比方:你可以边烧水边拖地,而不是死盯着水壶等它烧开。
5.4 进阶优化:把七张图的耗时压缩到理论极限
有一次我的需求是生成七张图,如果串行跑,每张假设30秒,总共210秒,用户体验极差。用了并发之后,理论耗时压缩到最慢一张的时间,也就是30秒左右。
但我很快发现了一个新问题:七张图同时并发请求,有可能触发API的限流机制,十次里有两三次直接返回429(请求过多)。
解决方案有两种:
- 限制最大并发数,比如最多并发3张,其余排队等待。
- 每次请求之间加一个随机小延迟,错开请求高峰。
我现在用的是SemaphoreSlim控制并发,类似这样:
csharp复制private static readonly SemaphoreSlim _semaphore = new SemaphoreSlim(3);
private async Task<string> RateLimitedGenerateAsync(string prompt)
{
await _semaphore.WaitAsync();
try
{
return await GenerateOneImageAsync(prompt);
}
finally
{
_semaphore.Release();
}
}
SemaphoreSlim可以把它理解成"限流闸门":同一时间最多放三个请求通过,第四个必须等前三批有空位了再进。这样既不浪费并发能力,又不至于把API逼疯。
6. 边界条件处理:错误重试、输入校验与防呆设计
6.1 大模型API调用失败的几种常见情况和应对
开发AI应用跟开发普通应用最大的区别是:AI应用的不确定性更大。API可能因为各种原因失败,比如网络超时、模型负载高、内容安全策略拦截、超过免费额度等。所以一个健壮的AI应用必须包含错误重试机制。
我的做法是引入一个简单的重试循环,配合指数退避算法:
csharp复制public async Task<string> GenerateWithRetryAsync(string prompt, int maxRetry = 3)
{
int retryCount = 0;
int baseDelayMs = 2000;
while (true)
{
try
{
return await GenerateOneImageAsync(prompt);
}
catch (Exception ex) when (IsRetryable(ex))
{
retryCount++;
if (retryCount >= maxRetry) throw;
int delay = baseDelayMs * (int)Math.Pow(2, retryCount - 1);
listBox1.Items.Add($"第{retryCount}次调用失败,{delay/1000}秒后重试...");
await Task.Delay(delay);
}
}
}
IsRetryable这个方法判断哪些错误值得重试,哪些错误重试也没用。一般规则是:429(限流)、500(服务器错误)、503(服务不可用)可以重试;400(参数错误)、401(鉴权失败)不要重试,重试一万次也不会成功。
6.2 输入校验:不要让你的密钥和提示词裸奔
用户在大模型产品里输入的内容,会经过内容安全审查,违规内容会被拒绝。我们在做工具时也要做好这层防护,但更重要的是在客户端就拦截掉明显不合适的输入。
我的做法是在点击"生成"按钮之前,对提示词做了几个简单的校验:
- 非空校验:提示词为空直接弹提示,不调API。
- 长度校验:超过500字符提示用户精简,因为过长提示词会被模型截断,效果反而不好。
- 敏感词前置拦截:这层是一个黑名单过滤,虽然简单粗暴,但能挡掉大部分无意义的API调用。
这个前置校验看起来很不起眼,但真的能省不少钱和时间。你想,如果用户输了一个明显违规的词,你不前置拦截,API调用100%会返回审查不通过。不仅浪费一次调用额度,响应时间还很慢。
6.3 我在实际调试中踩过的一个坑:返回值非JSON格式
有一次调用一个图像生成API,返回的内容竟然是HTML格式的页面,我当时就懵了。排查了一圈发现,原来是我请求头的Accept字段写错了,服务器直接返回了一个错误提示页面。
这个教训让我养成一个习惯:所有API调用,第一件事先输出原始响应文本,不要急着解析JSON。看一眼响应原文,八成问题都能定位。如果原始响应是JSON,你再放心大胆地加反序列化逻辑。
另外还有一个很容易被忽略的问题,就是HTTP状态码为200,但业务状态码是失败。有些API会返回200,但JSON里带个success字段是false,老手也得翻车。所以解析响应时,不能只看HTTP状态码,还要看响应体里的业务状态码。
6.4 图片文件的保存策略和资源释放
生成的图片保存到本地时,我建议用时间戳命名,不要覆盖旧文件:
csharp复制string folder = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyPictures), "AIGenerated");
Directory.CreateDirectory(folder);
string fileName = $"ai_img_{DateTime.Now:yyyyMMdd_HHmmss_fff}.png";
string fullPath = Path.Combine(folder, fileName);
image.Save(fullPath, ImageFormat.Png);
库System.Drawing创建的Bitmap和Graphics对象,用完之后一定要释放,否则会出现内存占用越来越高,最终变成"内存泄漏"的假象。我的习惯是:凡是创建了Bitmap、Graphics、Pen、Brush这类对象的,能using就using。
这里有个小细节:如果你要把生成的图片显示在ListView或PictureBox里,同时又要保存到本地,不能只调用一次Save就完事。显示用的Image对象和保存用的Image对象是有区别的——你保存之后可能就把Image对象Dispose了,界面上就显示不出来了。我的做法是先保存,后显示,并且显示用的Image是保存前克隆出来的一份:
csharp复制// 先存盘
image.Save(fullPath);
// 再显示
var clone = (Bitmap)image.Clone();
pictureBox1.Image = clone;
这样保存和显示互不干扰,两个对象各自释放自己的资源。
7. 把工具变成"产品":界面增强和交互体验优化
7.1 一个ListView搞定历史记录
当我开始频繁使用这个工具,我发现在界面上加一个历史记录区域非常有必要。每次生成的图片URL、时间、提示词,都记录在案,方便回溯。
我用的方法是:
csharp复制public class GenerationRecord
{
public string Prompt { get; set; }
public string ImageUrl { get; set; }
public DateTime CreatedAt { get; set; }
}
然后把这些记录绑定到ListView上,每一列显示一个字段。WinForm的ListView有网格线模式View.Details,配合列的设置就能做出一个看起来像模像样的历史记录面板。
不过WinForm的ListView功能其实挺基础的,如果你后续想做得更好看,建议换DataGridView,或者干脆引入一个简单的第三方UI库。但作为第一个AI应用,ListView完全够用了。
7.2 给按钮加取消功能
大模型生成图片很耗时,用户难免会在等待过程中后悔,想取消。特别是你用WinForm做多图并发生成时,取消功能几乎是刚需。我的做法是用一个CancellationTokenSource:
csharp复制private CancellationTokenSource _cts;
private async void btnGenerate_Click(object sender, EventArgs e)
{
_cts?.Cancel();
_cts?.Dispose();
_cts = new CancellationTokenSource();
try
{
var result = await GenerateWithRetryAsync(prompt, _cts.Token);
}
catch (OperationCanceledException)
{
listBox1.Items.Add("已取消生成。");
}
}
private void btnCancel_Click(object sender, EventArgs e)
{
_cts?.Cancel();
}
注意:API请求一旦发出,服务器那边是无法撤回的,CancellationToken只能取消客户端的等待和后续的重试。也就是说,用户点击取消后,界面马上恢复响应,但服务器可能仍然会生成完那张图并计入费用。这一点在使用时要跟用户讲清楚。
7.3 把密钥存到配置文件还是环境变量
上一节我提过密钥要放在环境变量里,但有些WinForm程序是要发给别人使用的,你不能要求每个用户都去配环境变量。这种情况,我建议把密钥和模型名都写到 app.config 或 JSON 配置文件里:
xml复制<appSettings>
<add key="AIModelAPIKey" value="你的密钥" />
<add key="AIModelEndpoint" value="https://api.xxx.com/v1/images/generations" />
<add key="AIModelName" value="image-gen-v1" />
</appSettings>
然后代码里统一用ConfigurationManager去读:
csharp复制var apiKey = ConfigurationManager.AppSettings["AIModelAPIKey"];
var endpoint = ConfigurationManager.AppSettings["AIModelEndpoint"];
这样做的好处是,后续如果你想适配另一个厂商的API,不需要重新编译代码,改一下配置文件就能切换。写死在代码里的密钥是灾难,写在配置文件里是专业,写在环境变量里是推荐,按需选择。
8. 下一个实战目标:把AI接到你的老项目里去
8.1 最保守的接法:独立通信的本地服务
如果你的老项目是一个复杂的WinForm或者WPF系统,你完全不想碰它的核心代码,但又想加上AI能力,我的建议是:搞一个独立的本地AI服务程序,老项目通过HTTP或者命名管道跟它通信。
把这个AI服务单独做成一个控制台应用或Windows服务,监听本地端口,收到请求就调大模型API,返回结果给主程序。这样两边彻底解耦,AI服务挂了不影响主程序运行,主程序升级也不影响AI服务。
C#里写一个简单的HTTP监听服务,用HttpListener就够了,网上教程一搜一大把。核心代码大概就是这个雏形:
csharp复制HttpListener listener = new HttpListener();
listener.Prefixes.Add("http://localhost:58888/");
listener.Start();
while (true)
{
var context = await listener.GetContextAsync();
var request = context.Request;
var response = context.Response;
// 读取request里的prompt,调大模型API,写回response
}
这种架构的好处是:你的AI服务可以用任何语言写,主程序用什么语言都无所谓。今天用C#写,明天想换Python重写,主程序一行都不用改。
8.2 更深入的接法:在C#上层封装一个统一的AI接口
如果你的项目里有多个地方要用到AI能力,比如一个地方做智能客服,一个地方做内容审核,一个地方做图像识别。这时候再到处散布API调用代码,就成灾难了。
我的做法是设计一个统一接口,把AI能力抽象化:
csharp复制public interface IAIService
{
Task<string> ChatAsync(string message, CancellationToken token = default);
Task<string[]> GenerateImagesAsync(string prompt, int count, CancellationToken token = default);
Task<string> AnalyzeImageAsync(string imagePath, string question, CancellationToken token = default);
}
然后在主项目里注册这个接口的实现,业务层只需要注入IAIService,根本不用关心底层是调用哪家的大模型。将来换供应商,或者从云端API换成私有化部署,只改实现类就够了。
这种"面向接口编程"的思路,在C#里算是基础功,但你一旦把AI能力也纳入这个模式,你的老项目对AI的适应能力就会强很多。
8.3 在C#里真正落地AI的场景举例
最后分享几个我实际做过的场景,给你们找找灵感:
- 工业上位机里的AI质量检测:C#上位机通过串口读传感器数据,数据在C#这边做简单判断后,把异常图片发给大模型API做进一步分析,返回不良原因。
- WinForm报表工具里的智能摘要:导出数据报表的同时,自动生成一段文字总结,描述数据的核心特征。底层就是拼接一个Prompt,调用Chat接口。
- 老系统里的智能搜索:用户用自然语言搜索,C#后端先把自然语言转成数据库查询条件,再执行查询。这就是最简单的"Text-to-SQL"应用。
每一个场景都不复杂,几百行代码就能搞定。关键在于你愿不愿意把手伸进AI这个领域,先写一个能跑的东西出来。
我做这个AI图片生成工具时,刚开始也就想着"试试看",结果跑通之后发现——原来AI应用没那么玄乎。它就是一个API调用,跟你在C#里调用微信支付接口、调用短信服务接口没什么本质区别。区别只在于,参数怎么调、返回值怎么用,需要多一些试错和沉淀。
如果你看完这篇文章,能自己动手把第一个AI应用跑起来,那这篇文章的目的就达到了。后面越做越熟之后,你会发现,真正难的不是调用API,而是怎么把AI能力和你的业务场景结合起来——这个问题,任何教程都代替不了你对自己业务的理解。
