一、国内开发者的现实：不是不会用 AI，而是“接入成本不一样”

在 2026 年，大模型已经成为开发者基础工具之一。

但如果你真的在国内做开发，会发现一个很现实的问题：

并不是“不会用 AI”，而是：

很多主流 AI 服务，在工程接入层面并不顺畅。

🌍 官方生态 vs 现实开发

在 Microsoft.Extensions.AI 的官方示例中，常见的 AI 提供商包括：

这些模型能力都非常强，但在国内实际开发环境中，往往会遇到一些现实约束：

• 网络访问不稳定或不可用
• API Key 获取和支付门槛较高
• 调用链路复杂，部署成本较高

---

因此，工程上更常见的是“替代方案”

在真实项目中，越来越多开发者会选择：

使用兼容 OpenAI 协议的国内模型服务作为替代实现

例如 DeepSeek（DP）这一类模型服务。

---

✔ 为什么 DeepSeek 更常被采用？

从工程角度来看，它的优势非常直接：

• ✔ API 结构与 OpenAI 完全兼容
• ✔ 中文场景表现稳定
• ✔ 成本显著更低，适合高频调用
• ✔ 接入方式简单，改动极小
• ✔ 可以无缝替换 GPT 调用链路

🧩 关键变化：从“换模型”变成“换实现”

在传统开发方式中，不同模型意味着不同 SDK：

• GPT 要用 OpenAI SDK
• Claude 要用 Anthropic SDK
• DeepSeek 又是另一套接口

但在 .NET 的 AI 抽象体系中，这件事被统一了：

👉 所有模型最终都被抽象为同一个接口：IChatClient

二、 核心实战：业务代码彻底无感 AI 厂商

🧩 项目技术栈说明

本示例基于以下环境：

• .NET 8 控制台应用
• Microsoft.Extensions.DependencyInjection 8.0.0
• Microsoft.Extensions.AI / OpenAI SDK 10.0.5
• Microsoft.Extensions.AI 10.0.5

💡完整示例：DeepSeek / GPT 统一调用方式

using Microsoft.Extensions.AI;
using Microsoft.Extensions.DependencyInjection;
using OpenAI;
using OpenAI.Chat;
using System.ClientModel;

internal class Program
{
    private static async Task Main(string[] args)
    {
        var services = new ServiceCollection();
        var client = new OpenAIClient(
            new ApiKeyCredential("sk-310e61a9753647c598015bc8f561565a"),
            new OpenAIClientOptions
            {
                Endpoint = new Uri("https://api.deepseek.com/v1")
            }
        );

        var chatClient = client
            .GetChatClient("deepseek-chat")
            .AsIChatClient();

        services.AddSingleton(chatClient);

        var provider = services.BuildServiceProvider();

        var chat = provider.GetRequiredService<IChatClient>();
        var response = await chat.GetResponseAsync("用一句话解释依赖注入");

        Console.WriteLine(response.Text);
        var a = await chat.GetResponseAsync("北京有什么美食");

        Console.WriteLine(a.Text);
        Console.ReadLine();
    }
}

一行代码接入大模型，不是噱头，是 .NET 给 AI 工程化交出的答卷。