在過去的二十多天裡，我們見證了 AI 在演算法拆解、代碼重構、API 串接與測試生成上的驚人爆發力。然而，在享受 AI 帶來數倍開發效率的同時，每位工程師心中都必須時刻拉起警報——「大型語言模型不是編譯器，它本質上是一個機率預測模型。」

相信很多開發者都遇過這種令人哭笑不得的場景：

• AI 推薦了一個看似極其好用的 Java 方法或 Spring 註解，寫得言之鑿鑿，結果貼到 IDE 裡直接噴紅字：Cannot resolve symbol。
• 詢問某個開源套件的用法，AI 貼了一行 Maven 依賴配置，結果到 Maven Central 一查，根本沒有這個套件（甚至可能落入套件投毒攻擊的陷阱）。
• AI 混淆了不同版本的語法（例如把 Java 21 的特有語法套用到 Java 8 專案中）。

今天我們就來深入探討：為什麼 AI 代碼會產生幻覺（Hallucination）？工程師又該如何建立一套高效的查核工作流，避免被 AI 的「自信胡說」帶進坑裡！

一、AI 代碼幻覺的常見三大型態

大型語言模型在生成代碼時，是在預測「語意上看起來最合理、最流暢的下一個 Token」，而非即時連線編譯驗證。常見的幻覺樣態包含：

1. API 捏造（Invented APIs）：
   當官方標準庫缺乏某個直覺功能時，模型會「望文生義」自己發明一個方法。例如在 Java String 上捏造一個不存在的 .reverse() 或 .removeWhitespace()。
2. 版本混淆（Version Mismatch）：
   將過期棄用（Deprecated）的類別與最新版特性混在一起。例如在 Spring Boot 3 中依然推薦早已廢棄的 WebSecurityConfigurerAdapter。
3. 幻覺套件與供應鏈投毒（Package Hallucination & Typosquatting）：
   模型憑空想像出一個名字極為真實的 npm / Maven 套件。黑客若發現多個模型常幻覺出某個特定套件名稱，便會故意在官方倉庫註冊該惡意套件，等待盲從 AI 的開發者下載安裝！

二、實戰案例：看似完美的「幽靈方法」

假設我們詢問 AI：「如何在 Java 中將清單（List）依固定大小快速分割成多個子清單（Chunking）？」

[AI 可能給出的幻覺代碼範例]

import java.util.List;

public class ChunkDemo {
    public static void main(String[] args) {
        List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6, 7);

        // 幻覺陷阱：Java 原生 Collections 根本沒有 chunk 方法！
        List<List<Integer>> chunks = java.util.Collections.chunk(numbers, 3);
        System.out.println(chunks);
    }
}

這段代碼如果只看變數名稱與邏輯，流暢得天衣無縫，但按下編譯（javac）就會瞬間失敗。

三、工程師的「三重查核防線」工作流

為了把 AI 的產出安全落地到真實專案中，我們需要建立起肌肉記憶般的查核機制：

1. 善用「反向自檢 Prompt」逼退幻覺

當 AI 給出一個沒看過的類別或方法時，不要立刻採用，追問一句：

【自檢提示詞】
「請確認你剛才使用的 Collections.chunk 是否屬於 Java 17 標準庫？如果是第三方庫，請明確給出 Maven GroupId 與 ArtifactId，並指出該方法的官方 Javadoc 來源。」

在追問壓力下，模型通常會立刻自我校正：「抱歉，Java 原生 Collections 並無此方法，這需要引入 Google Guava 或 Apache Commons Collections...」

2. 查驗官方權威來源（Ground Truth Verification）

• Java 原生 API：直接查閱 Oracle 官方 API 文件或在 IDE 中按 Ctrl + 點擊 進入原始碼。
• 第三方依賴：在把任何依賴寫進 pom.xml 或 package.json 前，先到 Maven Central (mvnrepository.com) 或 npmjs.com 搜尋該套件是否存在、最新更新時間、以及下載量是否正常。

3. IDE 即時回饋與編譯器鐵證

• 永遠以本機的編譯器（Compiler）為最終裁判。
• 善用 VS Code / IntelliJ 的即時靜態分析，凡是紅字警報，第一時間判定為語法不符或方法捏造，絕不盲目複製到生產環境。

四、真實驗證：正確的原生與第三方解法對照

經過查證後，我們確認 Java 原生標準庫需自行實作分片，或借力成熟套件：

[正解方案 A：Java 原生純手寫（無依賴）]

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class ChunkUtils {
    public static <T> List<List<T>> chunkList(List<T> list, int chunkSize) {
        if (list == null || list.isEmpty() || chunkSize <= 0) {
            return Collections.emptyList();
        }
        List<List<T>> result = new ArrayList<>();
        for (int i = 0; i < list.size(); i += chunkSize) {
            result.add(list.subList(i, Math.min(i + chunkSize, list.size())));
        }
        return result;
    }
}

[正解方案 B：引入經過驗證的 Google Guava]
// 需先於 pom.xml 引入 com.google.guava:guava

import com.google.common.collect.Lists;
import java.util.List;

public class GuavaChunkDemo {
    public static void main(String[] args) {
        List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6, 7);
        // 官方保證存在的真實方法
        List<List<Integer>> chunks = Lists.partition(numbers, 3);
        System.out.println(chunks);
    }
}

五、人機協同的最高準則：信任但需驗證（Trust, but Verify）

1. AI 擅長發想，人類負責裁決：
   AI 可以幫你腦力激盪 5 種不同的演算法架構，但哪一種是業界通用的安全實務，必須由工程師把關。
2. 警惕過度流暢的自信口吻：
   模型愈是說「當然，這完全沒問題」，工程師愈要抱持健康的懷疑心態，檢視底層邏輯與相依性。
3. 保持技術底層敏感度：
   持續閱讀語言規格書（JLS）、官方 Release Notes 與開源庫文檔。只有具備深厚基礎的工程師，才能一眼識破 AI 的微妙幻覺。

今日小結與預告

今天我們探討了大型語言模型在程式碼生成上的本質侷限——幻覺，並建立了「反向自檢、官方查證、編譯器判定」的三重過濾網，守護系統的代碼正確性與軟體供應鏈安全。

到今天為止，第五模組（單元測試、自動化與資安實務）正式圓滿落幕！