CppCon 2026 新議程：AI 不該是系統本身，而是連接系統的翻譯層
isocpp.org · 2026-08-24
CppCon 官方部落格於 8 月 24 日公布 2026 年會議的新增議程，由 Andy Soffer 與 Matt Kulukundis 共同主講的〈AI is UB with Better PR〉將於 9 月 16 日上午在美國科羅拉多州 Aurora 登場。這場演講被排入 Robotics & AI 議程軌，涵蓋軟體設計、安全性與測試品質等子主題。Andy Soffer 曾在 Google 領導 C++ Core Libraries 團隊（負責 Abseil 與 GoogleTest），現任職於 2024 年底成立的新創公司 BrontoSource。
核心論點
講題標題把 AI 直接類比成「包裝精美的未定義行為」（undefined behavior，簡稱 UB）。核心比喻在於：C++ 裡的 UB 之所以危險，不是因為它總是立即出錯，而是因為它在多數情況下看起來運作正常，直到某個邊界條件被踩到才會整組炸開；講者主張，把 AI 當成系統中的自主決策者放進關鍵基礎設施，會出現同樣的風險模式——表面順暢，實際上沒有任何可驗證的行為保證。
議程摘要中寫道，AI 真正擅長的場景是「協調、翻譯定義良好且具決定性的元件之間的關係，而不是被信任去自主推理」。換句話說，AI 適合放在元件與元件的邊界上做轉譯與黏合，而不是取代其中任一元件本身的判斷邏輯；一旦 AI 被要求「成為系統」而非「連接系統」，講者觀察到的結果是系統整體失靈。
影響範圍
這場演講並不主張完全拒絕在 C++ 系統中使用 AI，而是討論在不設防的情況下，把 AI 放進安全關鍵基礎設施會帶來的風險，以及該如何劃出可驗證的邊界。由於議程尚未舉行，目前只有 isocpp.org 的預告文與 CppCon 官方議程頁公開了摘要與講者背景，投影片與錄影要等會後才會釋出。
對於正在評估是否在 C++ 專案中導入 LLM 輔助工具（例如程式碼生成、日誌摘要、自動化測試產生）的團隊，這場演講提出的「AI 只做協調、不做決策」框架，提供了一個劃定信任邊界的具體參考點：把 AI 放在元件之間的接縫上，而不是放進任何單一元件的核心判斷路徑。
C# 15 預覽功能出爐：聯合型別、封閉階層與記憶體安全模型重寫
devblogs.microsoft.com · 2026-08-24
Microsoft 於 8 月 24 日在 .NET 部落格公布隨 .NET 11 Preview 7 釋出的 C# 15 預覽功能，其中份量最重的兩項是聯合型別（union types）與封閉階層（closed hierarchies），另外還附帶一套針對 unsafe 語意的重新設計。C# 15 將隨 .NET 11 於 11 月正式 GA，文中列出的功能目前都仍是預覽狀態，需要專案手動切換到預覽語言版本才會生效。
核心改動：聯合型別與封閉階層
聯合型別透過新的 union 關鍵字宣告一個值只能是固定集合中的一種型別，並讓編譯器在 switch 陳述式中強制做窮盡性（exhaustiveness）檢查：
public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);
public union Pet(Cat, Dog, Bird);
Pet pet = new Dog("Rex");
string name = pet switch
{
Dog d => d.Name,
Cat c => c.Name,
Bird b => b.Name,
};只要少列出一種型別分支，編譯器就會直接報錯，而不是留到執行期才丟例外。與聯合型別搭配使用的是封閉階層：在類別宣告前加上 closed 修飾字，會讓該類別隱性變成 abstract，並限制只有同一組件（assembly）內的型別可以繼承它：
public closed record class JobStatus;
public record class Queued : JobStatus;
public record class Running(int PercentComplete) : JobStatus;
public record class Completed(TimeSpan Elapsed) : JobStatus;
public record class Failed(string Error) : JobStatus;這讓對 JobStatus 做模式比對的 switch 同樣能被編譯器的窮盡性檢查覆蓋，不再需要額外補一個 default 分支來滿足編譯器。
規格細節：記憶體安全模型重寫
這次預覽同時重寫了 unsafe 的語意邊界，把它從單純的語法標記，改造成一份可驗證的合約。指標型別的宣告本身不再需要 unsafe 環境，但實際的解參考操作（*p、p->m、p[i]）仍然需要；被標記為 unsafe 的成員也只能在 unsafe 情境下被呼叫。這項改動目前仍在預覽階段，需要在專案檔中手動加入下列設定才會啟用：
<Features>$(Features);updated-memory-safety-rules</Features>
<LangVersion>preview</LangVersion>其他語法調整
這次預覽還包含幾項較小但實用的語法擴充：
- 集合運算式建構參數：新增
with(...)語法，可在集合運算式中直接傳入建構子或工廠方法的參數，例如List<string> names = [with(capacity: values.Length * 2), .. values];。 - 擴充索引子：允許透過具名接收者（named receiver）語法，為既有型別加上索引子擴充方法。
- 具名標籤的 break／continue：可在巢狀迴圈中用標籤直接跳出或跳過指定的外層迴圈，取代過去常見的旗標變數寫法。
影響範圍
這些功能全數標示為預覽狀態，團隊在部落格中明確表示使用者回饋會直接影響最終設計，並引導開發者透過 dotnet/csharplang 儲存庫回報意見。由於聯合型別與封閉階層都牽涉到編譯器窮盡性檢查與底層 IL 表示方式的設計，已經在採用預覽版的專案需要留意：目前的語法與行為在 GA 前仍可能調整，不建議直接用在正式產品程式碼中。
原始來源：.NET Blog：Explore new features available in C# 15 preview
Hot Chips 2026：NVIDIA 公布 CUDA 移植到 RISC-V 的技術門檻，SiFive 展示原型系統
Chips and Cheese · 2026-08-24
NVIDIA 在 8 月 23 日至 25 日於史丹佛大學舉行的 Hot Chips 2026（HC38）上，首度公開讓 CUDA 支援 RISC-V 處理器所需的具體技術條件，使 RISC-V 成為繼 x86-64 與 AArch64 之後第三個受官方支援的 CPU 架構。Chips and Cheese 作者 Chester Lam 在 8 月 24 日發布的技術分析文章中整理了 NVIDIA 對 RISC-V 平台開出的門檻清單，合作夥伴 SiFive 同場展示了對應的原型系統。
規格細節：基準門檻
NVIDIA 要求 RISC-V 系統至少符合三項標準規範：RVA23 設定檔（profile）合規、RISC-V Server SoC 規格，以及RISC-V Server Platform 規格，並具備對應的 RAS（可靠性、可用性、可維護性）機能與獨立的安全處理器。這三項是 CUDA 移植的準入門檻，而不是加分項；不符合任一項，就沒有討論後續的空間。
在這條基準線之上，NVIDIA 額外列出四項要求：
- 向量擴充的斷言（predication）支援，用來減少分支、提高程式碼執行效率；
- ACPI 支援，用於硬體探索與電源、溫度管理——這項能力直到 2025 年由 RISC-V
BRS（Boot and Runtime Services）規格批准後才補齊； - PCIe 一致性（coherency），避免 CPU 快取與 GPU DMA 之間出現資料不一致；文章指出若缺少這項支援，軟體就得自行手動 invalidate 快取；
- PCIe 對等傳輸（peer-to-peer），讓裝置之間可以直接互傳資料，不必經過 CPU 端記憶體中轉。
影響範圍：SiFive 與 NVLink Fusion
SiFive 在會場展示了一套符合上述條件的 CUDA 相容系統，文章形容其規格對應到「高核心數的伺服器晶片」，而非消費級硬體，顯示第一波支援 CUDA 的 RISC-V 產品會先出現在伺服器市場，而不是嵌入式裝置或單板電腦。這個方向與同期 Tom's Hardware 的報導一致。
NVIDIA 同時在會中談到 NVLink Fusion——允許第三方廠商把 NVLink IP 整合進自製 CPU（包含 RISC-V 設計）。採用 NVLink Fusion 除了要滿足前述所有 CUDA 門檻，還必須額外支援 DOCA 與 NCCL 等框架，代表廠商需要與 NVIDIA 建立更緊密的合作關係，而不是單靠取得一份規格文件就能自行實作完成。