小編精選 - 技術文章翻譯 · 08月16日

為什麼在 AI 時代，C# 是最適合的程式語言之一？

前言

AI 已經進入開發現場的今天，我們有必要重新思考：「要用哪種語言撰寫，才能和 AI 一起提升生產力？」

對這個問題，我非常想強力推薦 C#。

理由很單純。C# 是一門專為讓 AI 生成的程式碼能被人類快速看出問題，並且安全運用而設計的語言。

AI 的特性是，即使文法正確，也可能大量產生語意已經失真的程式碼。也就是說，在這個時代真正重要的，不是「AI 能不能自己寫程式碼」，而是能不能立刻驗證並修正 AI 寫出來的程式碼。

在這一點上，C# 非常強。

擁有強型別系統
採用靜態型別
透過 Roslyn 可在編譯時立即偵測問題
連 .editorconfig 這類規則，都能在建置時落實為警告／錯誤
BCL 與標準函式庫很完整，能快速建立產品基礎

這 5 點齊備，使 C# 在 AI 時代成為更上一層樓的「安全實作基礎」。

本文結論

C# 之所以適合 AI 時代，是因為它對於生成程式碼的「誤差」有非常優秀的攔截機制。

AI 在大量撰寫新內容時，常會輸出表面看起來沒問題、但內部契約已經破壞的程式碼。

例如下列情況：

var user = new User { Name = "Alice" };
var age = user.Age + "歲";

這在語法上是成立的，但因為 Age 是 int 卻和 string 做加法，從設計角度來看就是破綻。

這類錯誤在動態型別語言中，常常要到執行時才會發現。相對地，在 C# 中，把 int 和 string 用奇怪方式混在一起的設計，往往能在編譯前就先被攔下。

也就是說，在 AI 時代，比起「生成的程式碼正不正確」，更重要的是「能不能立刻、安全地驗證生成的程式碼」。C# 在這個觀點上非常出色。

1. AI 時代需要的是「能驗證」，而不只是「能寫」

與 AI 一起開發時，單純能寫很多程式碼並不重要。

更重要的是，能不能立刻找出並修正生成的程式碼。

C# 的優勢就在於，它很容易在生成程式碼之後把品質守住。

變數與參數的型別明確
編譯器能早早指出不合法程式碼
IDE 會即時顯示警告
dotnet CLI 將建置、測試、修正標準化
可用 .editorconfig 自動化規範

這整個流程，讓 AI 與人類的協作更穩定。

AI 雖然擅長「寫」，但辨識錯誤設計的能力，目前仍有很大一部分需要人類來把關。C# 作為一門更容易及早發現錯誤的語言，因而佔有優勢。

2. 透過強型別系統與靜態型別消除模糊性

C# 的一大優勢在於，型別本身就是設計的一部分。

透過型別，可以清楚表達函式的輸入與輸出、狀態邊界，以及商業規則的前提。

public record UserId(Guid Value);

public sealed record User(UserId Id, string Name, int Age);

public sealed class UserService
{
    public User GetAdultUser(User user)
    {
        if (user.Age < 18)
        {
            throw new InvalidOperationException("僅限成人");
        }

        return user;
    }
}

像這樣把 UserId 和 User 等型別分開，能大幅降低 AI 生成程式碼的粗糙度。

例如把 Guid 直接當成 string 處理這類實作，編譯器或 IDE 會很容易發出不協調的訊號。

這種型別的力量，代表開發者能更快攔下「說起來合理，但實作上危險」的程式碼。

若考慮與 AI 的相容性，這一點極為重要。

生成式 AI 很容易對某個變數塞入語意上似乎合理的值
但型別可以建立語意邊界
因此，可以用型別快速約束 AI 的模糊性

靜態型別的好處，在於可以在執行前就讓錯誤失敗。

const user = { name: "Alice", age: 30 };
console.log(user.age.toUpperCase());

這類錯誤在 JavaScript 中很容易拖到執行時才暴露，也常在開發階段被漏掉。

相對地，在 C# 中，對 int 使用 ToUpper() 這種不合法用法，可以在編譯時直接擋下。

var user = new User("Alice", 30);
Console.WriteLine(user.Age.ToUpper()); // 編譯錯誤

在 AI 時代的開發中，與其每次都把生成的程式碼跑一次來看能不能動，先靠編譯擋掉反而效率高得多。

3. Roslyn 讓編輯器與編譯器形成單一回饋迴圈

C# 的強項不只是編譯器最後才做判斷。

Roslyn 是讓 C# 與 Visual Basic 的編譯器、以及 IDE 分析功能，在同一套基礎上運作的機制。

也就是說，在 IDE 裡就能即時發生這些事情：

變數未使用
未妥善處理可為 null 的值
回傳型別不一致
async / await 使用不正確
例外處理不完整

這些都會直接在編輯器中被通知。

由於以 Roslyn 為前提，開發者不必等到「建置結束才發現」，而是可以在撰寫時就修正。

這在與 AI 對話時尤其重要。

AI 擅長「提案程式碼」，但需要回饋迴圈把提案導向正確方向。Roslyn 就能把這個迴圈變得更快。

例如 AI 隨便用了 Task.Run(...)，之後若少了 CancellationToken，IDE 就能立刻指出來。開發者會馬上知道「這裡要改，然後再產生下一版」。

C# 不只是讓 AI「寫程式碼」的語言，更適合當成穩定接住 AI 寫出來的程式碼的語言。

4. 可透過 .editorconfig 自動檢查團隊規範

與 AI 協作開發時，另一個很大的重點是，能把團隊規則固定成程式碼。

在 C# 中，透過 .editorconfig 可以把以下規則同時反映到 IDE 與建置流程中。

root = true

[*.cs]
indent_style = space
indent_size = 4

dotnet_diagnostic.IDE0060.severity = warning
dotnet_diagnostic.CA1822.severity = error

csharp_style_var_when_type_is_obvious = true
csharp_prefer_simple_using_statement = true

這不只是「程式碼風格」的問題，而是自動確認團隊設計理念的機制。

你可以在 .editorconfig 中定義這些規則：

要不要使用 var
async / await 的使用方式
未使用變數是否要警告
要不要使用 new()
是否強制命名規則
是否禁止某些例外用法

當這些規則會在建置時被檢查時，即使是 AI 生成的程式碼，也會變成不符合團隊方針就直接擋下來。

這對開發者來說非常強大。

不必用文件逐條說明編碼規範
可將規則自動化
AI 生成的程式碼也會套用同樣規則
一致性更容易維持

讓 AI 在團隊的護欄中運作，而不是只依靠工程師主觀判斷，C# 的設計非常自然地就能做到。

5. BCL／NuGet／GitHub 的資產支撐 AI 的學習與實作

C# 的強大，不只來自語言本身，也來自標準函式庫的品質。

System 命名空間下，日常所需的東西幾乎都備齊了。

可用 System.Text.Json 安全處理 JSON
HttpClient 可輕鬆撰寫 HTTP 通訊
Task 與 async / await 可自然撰寫非同步處理
LINQ 可用宣告式方式處理集合
IEnumerable<T>、Dictionary<TKey, TValue> 等集合基礎完備
MemoryCache、Channel<T> 等實務上常用的結構也都有
Cryptography 與 Security 功能也內建且容易使用

using System.Text.Json;

var json = JsonSerializer.Serialize(new { name = "Alice", age = 30 });
var user = JsonSerializer.Deserialize<User>(json);

這對與 AI 共同開發來說意義很大。

因為 AI 雖然很會寫「常見處理」，但也很容易在函式庫選擇與設計上出錯。C# 的 BCL 已經備好符合慣例的實作基礎，能降低 AI 過度自行實作的風險。

但不只 BCL 如此。C# 的實力也來自 NuGet 的豐富性與 GitHub 上大量 OSS 程式碼。

NuGet 不只是套件管理工具，也是 AI 尋找「現成正解」的地方。

ASP.NET Core、Entity Framework Core、xUnit、FluentValidation
Polly、MediatR、Microsoft.Extensions.*
Serilog、OpenTelemetry 等等，實務上常見的模式都很齊全

這些函式庫通常比 AI 從零設計更可靠，因為它們已經被驗證過，開發者也更容易維持設計共識與品質。

此外，GitHub 上與 C# 相關的程式碼量非常龐大。無論是 OSS 實作範例、範例應用程式、函式庫原始碼，還是 Issue、PR 的討論，甚至設計理念，都有大量可作為學習材料的資產。

這種環境對 AI 也非常有利。

看得多，較能學會既有慣例
函式庫用法更容易變得理所當然
參考實作豐富，較能快速選定設計方向
透過公開程式碼，更容易比較安全與危險的用法

換句話說，C# 是一門在動手寫之前，就已經有大量參考程式碼可看的語言。這在 AI 時代是相當大的優勢。

6. dotnet CLI 與測試基礎讓執行與驗證迴圈標準化

C# 的強大不只在語言與函式庫。dotnet CLI 本身，就是用來快速驗證、執行與改善 AI 生成程式碼的標準介面。

例如，下列命令是標準配備這件事本身就非常重要：

dotnet new webapi
dotnet add package Serilog
dotnet restore
dotnet build
dotnet test
dotnet format
dotnet watch run

這些命令涵蓋了從建立專案、加入相依性、建置、測試、格式化到監看執行的一致流程。

在與 AI 協作時，這種標準化很有用。

生成的程式碼可立刻用 dotnet build 確認
可用 dotnet add package 自然導入相依套件
可用 dotnet test 驗證規格與邊界條件
可用 dotnet watch 快速迭代小修改
在 CI／本機／容器環境都能用相同命令

有了這套流程，AI 就不只是「寫完就算」，而是更容易進入執行、驗證、修正的循環。

此外，C# 也備有標準測試基礎。

dotnet new xunit
dotnet new nunit
dotnet new mstest
dotnet test

這些步驟在語言層級幾乎已經標準化。

也就是說，只要 AI 生成了程式碼，就能自然地立刻補上測試、用 dotnet test 驗證、修正失敗處再重新生成。

這對 AI 時代非常重要。

能立刻驗證生成程式碼
容易補上例外與邊界條件
更容易阻止迴歸
團隊能安全管理「AI 做出來」的程式碼

7. 破壞性變更少，即使在大規模營運也較可靠

在 AI 時代，所使用的語言如果只是「容易快速寫新東西」還不夠。

更重要的是，是否容易破壞既有程式碼。在實務上採用 AI 建議、再逐步改善的流程裡，這個觀點尤其重要。

C# 一向被認為是破壞性變更相對少、設計遷移較容易的語言。這在與 AI 協作時，特別有價值。

這裡的「破壞性變更少」是指，即使每年都有主版本更新，實務上也很少出現大規模相容性破壞。例如，升級到新的 .NET 執行階段後，只要確認所依賴的 NuGet 套件支援情況，必要時做最小幅度調整，程式碼往往就能直接繼續運作。

更重要的是，.NET 執行階段的品質非常高。C# 也被用於 Azure、Microsoft 365 這類全球規模、需要大量流量與複雜營運的服務。那些在一般應用程式中不容易看見的問題與事故，已經在實際大規模營運中反覆被回報並改善。從這點來看，「有在大規模營運中使用」本身就等同於可靠性的證據。

這點在資安方面也很有意義。NuGet 已經整理好相依性管理與弱點檢查機制，搭配 dotnet list package --vulnerable 與 dotnet restore 的運作方式也很標準。因為有這些機制，即使是 AI 生成的程式碼，也能一眼確認相依套件是否有漏洞，並容易納入修正範圍。

由於 C# 的語言規格與 .NET 設計理念都偏向重視向後相容性，因此很容易在維持原有 AS-IS 的前提下，持續加入新功能與新程式碼。

在與 AI 共同開發時，這種「不容易破壞」的特性非常重要。

AI 常常會忽略現有設計前提，直接建議大幅度重寫，看起來很方便。但在實務上，C# 很容易透過型別、編譯錯誤與設計影響範圍來判斷這種大改到底是否真的必要。

在 C# 的世界裡，這些機制會幫你降低風險：