# 影片筆記：2026版AI+Codex零基础全套视频课程，Codex从入门到大神AI编程开发，涵盖安装配置、代码分析、Bug修复及完整项目实战 p08 7、Codex Rules 体系构建与代码可控性治理

## 一句話總結

本節課程介紹了 Codex 中的 **Lulus** 規範體系，旨在通過細粒度的規則配置（如 `.lulus` 文件），實現對代碼執行權限、命令執行（特別是沙箱外操作）的精確管控與安全治理，並解釋了其命令拆分評估機制與語法規範。

## 核心重點

*   **Lulus 規範體系定義**：Lulus 是 Codex 內部用於控制「執行類」命令的規範體系，比項目結構規範更細粒度，主要用於管理沙箱外的命令執行權限。
*   **配置與加載機制**：
    *   必須在項目根目錄創建 `.lulus` **目錄**，並在該目錄下創建 `.lulus` **文件**。
    *   Codex 優先掃描 `.lulus` 目錄加載規則；若結構錯誤（如僅創建文件未創建目錄），可能導致加載失敗或誤讀 `agents.md`。
*   **權限管控策略**：
    *   支持三種決策類型：**不提示 (No Prompt)**、**提示 (Prompt)**、**禁止 (Forbidden)**。
    *   命中規則後，需根據配置進行用戶確認或直接執行/拒絕。
    *   即使設置為禁止，若命令涉及網絡訪問（如 GitHub 操作），仍可能觸發提權或額外授權流程。
*   **命令評估與腳本拆分**：
    *   Codex 將命令視為參數列表進行評估。
    *   **安全腳本拆分**：對於純字面量、無變量展開的安全命令，Codex 會將其拆分為單條命令分別評估，並以最嚴格結果為準。
    *   **保守執行**：若命令包含變量展開、環境變量替換、通配符或不安全因素，則不拆分，採取保守方案直接運行。
*   **測試與語法**：
    *   提供測試規則生效的方法，Codex 會輸出 JSON 格式的評估結果。
    *   Lulus 採用類似 Python 但專為安全執行設計的語法，旨在無副作用下運行。

## 詳細大綱

### 一、 Lulus 規範體系概述
*   **定位**：屬於細節規範，針對「執行類」命令，特別是沙箱外的命令執行。
*   **應用場景**：
    *   運行代碼、運行 Case、自動化測試。
    *   涉及刪除文件、調用工具等可能影響權限的操作。

### 二、 Lulus 的配置與加載
*   **文件結構要求**：
    *   項目根目錄需創建 `.lulus` 目錄。
    *   目錄內需創建 `.lulus` 文件。
    *   若僅創建文件而未創建目錄，加載可能失敗，需確保目錄結構正確並重啟。
*   **加載邏輯**：
    *   Codex 優先掃描 `.lulus` 目錄。
    *   支持全局規則與項目級別規則（用戶級別、項目級別）。
    *   若配置錯誤，Codex 可能錯誤讀取 `agents.md` 而非 `.lulus` 內容。

### 三、 權限管控與匹配規則
*   **匹配機制**：
    *   基於命令前綴或精確匹配（如 `GHPRVU` 開頭的命令）。
    *   若不匹配規則，但涉及網絡訪問（如訪問 GitHub），仍可能觸發網絡權限申請或提權流程。
*   **決策類型 (Decision)**：
    *   **不提示 (No Prompt)**：直接在沙箱環境下執行。
    *   **提示 (Prompt)**：每次命中規則時，需用戶確認請求。
    *   **禁止 (Forbidden)**：直接拒絕該命令執行。
*   **權限互動邏輯**：
    *   即使設置為 `Forbidden`，若命令涉及網絡訪問且沙箱受限，Codex 可能會嘗試「提權」或額外授權申請。
    *   若命令僅為查詢且不涉及修改風險，默認可能放行。
    *   最終執行結果取決於具體場景及環境權限需求。

### 四、 命令評估與腳本拆分
*   **命令解析**：
    *   Codex 將命令看作參數列表（如 `EKCVP` 參數方式）進行接收和評估。
*   **安全腳本拆分 (Safe Script Splitting)**：
    *   **拆分條件**：純字面量單詞、不包含變量展開、僅通過安全運算服務、有規則的安全場景。
    *   **拆分邏輯**：將複合命令拆分為單條命令，分別用 Lulus 評估，並以最嚴格的結果為準。
    *   **不拆分條件**：包含重令像、替換表達式、環境變量複製、通配符等，代表執行關鍵點為規範，採取保守方案直接運行。
*   **危險命令處理**：
    *   如 `RM`、`RF` 等刪除文件命令，即使混在允許的規則中，Codex 也會單獨評估，因其屬於危險操作，可能違背安全指令要求。

### 五、 測試與語法規範
*   **規則測試**：
    *   可通過特定指令測試規則是否生效，Codex 會輸出 JSON 格式的規則評估結果。
    *   用於驗證規則文件編寫是否正確，以及命令是否被拒絕或允許。
*   **Lulus 語法**：
    *   採用專門的語法規範（提及 `Specific` 語法）。
    *   設計目標為安全執行，類似 Python 語法風格。
    *   引擎設計為在不產生副作用（如不觸碰文件系統邏輯）的前提下運行。

## 工具 / 模型 / 名詞整理

*   **Codex**：影片討論的主體產品/模型。
*   **Lulus**：Codex 內部的規範體系或組件名稱（逐字稿中多次出現，部分語境下聽似 "Lulis" 或 "Glueless"，但核心指代此規範體系）。
*   **GHPRVU**：逐字稿中提到的命令前綴或示例命令。
*   **GonRepo**：逐字稿中提到的另一個命令示例，用於對比匹配規則。
*   **agents.md**：Codex 可能默認讀取的配置文件，若 `.lulus` 配置錯誤可能被誤讀。
*   **PowerShell**：逐字稿中提到的執行環境或命令類型。
*   **JSON**：規則測試輸出的格式。
*   **Specific 語法**：逐字稿中提到 "專門有一套語法叫這個 Specific 的這麼一個語法"。

## 操作流程整理

1.  **創建規範目錄結構**：
    *   在項目根目錄創建 `.lulus` 目錄。
    *   在 `.lulus` 目錄下創建 `.lulus` 文件。
2.  **配置權限規則**：
    *   在 `.lulus` 文件中定義命令匹配規則（如前綴匹配）。
    *   設置決策類型：`No Prompt`、`Prompt` 或 `Forbidden`。
3.  **驗證配置**：
    *   確保目錄結構正確，避免 Codex 誤讀 `agents.md`。
    *   重啟 Codex 以加載新規則。
4.  **測試規則生效**：
    *   執行特定指令測試規則。
    *   檢查 Codex 輸出的 JSON 格式評估結果，確認命令是被拒絕、允許還是需要確認。
5.  **執行命令**：
    *   Codex 解析命令為參數列表。
    *   根據命令內容判斷是否進行「安全腳本拆分」。
    *   若拆分，分別評估並取最嚴格結果；若不拆分，直接保守運行。
    *   若命中規則，根據配置執行提示確認或直接執行/拒絕。

## 值得注意的限制或風險

*   **配置結構錯誤風險**：若僅創建 `.lulus` 文件而未創建對應目錄，Codex 可能無法正確加載規則，甚至誤讀 `agents.md`，導致安全策略失效。
*   **網絡訪問的權限互動**：即使設置了 `Forbidden`，若命令涉及網絡訪問（如 GitHub 操作），Codex 仍可能嘗試「提權」或額外授權，這可能與預期行為不符。
*   **命令拆分的不確定性**：對於包含變量展開、環境變量替換、通配符或「重令像」的命令，Codex 採取保守方案不拆分，這可能導致複雜命令的安全評估不夠精細。
*   **危險命令的單獨評估**：刪除文件等危險命令（如 `RM`、`RF`）會被單獨評估，即使它們混在允許的規則中，這可能導致預期外的拒絕行為。

## 逐字稿辨識疑點

*   **Codex Lulers / Lulis / Lulus / Glueless**：逐字稿中對該規範體系的稱呼不一致，分別出現過 "Codex Lulers"、"Lurus"、"Lulis"、"Glueless"、"Lulus"。根據上下文，核心指代應為 "Lulus" 或 "Lulis"，但存在聽寫混亂。
*   **GHPRVU / GHPR**：逐字稿中提到的命令前綴，疑似為 `gh` (GitHub CLI) 相關命令的聽寫錯誤，但無法確定具體命令，標為疑點。
*   **GonRepo**：逐字稿中提到的命令，疑似為 `gh repo` 的聽寫錯誤，標為疑點。
*   **EKCVP**：逐字稿中提到的參數方式，疑似為 `--key=value` 或類似參數格式的聽寫錯誤，標為疑點。
*   **prodx**：逐字稿中提到的測試項目名稱，疑似為 `prod` 或某個具體開源項目名的聽寫錯誤，標為疑點。
*   **gitty**：逐字稿中提到的項目來源，疑似為 `GitHub` 的聽寫錯誤，標為疑點。
*   **Specific 語法**：逐字稿中提到 "專門有一套語法叫這個 Specific 的這麼一個語法"，需查證是否為特定名稱或聽寫錯誤。
*   **殺箱 / 沙箱**：逐字稿中交替使用 "殺箱" 和 "沙箱"，應為 "沙箱" (Sandbox) 的聽寫錯誤，但保留原文記錄。
*   **提權 / 提現 / 收取**：逐字稿中描述權限流程時，出現 "提權"、"提現"、"收取"，應均指 "提權" (Privilege Escalation/Authorization) 的聽寫錯誤。
*   **貧固**：逐字稿中提到 "按照更加保守的一個方案去做一個貧固"，應為 "保護" 或 "固化" 的聽寫錯誤，標為疑點。
*   **通費符**：逐字稿中提到 "加了一些通費符了"，應為 "通配符" 的聽寫錯誤，標為疑點。
*   **重令像**：逐字稿中提到 "加了一些重令像的一些東西了"，應為 "正則" 或 "變量" 相關詞彙的聽寫錯誤，標為疑點。

## 可延伸追問

*   Lulus 規範體系與 Codex 其他規則（如 `agents.md`）的優先級和衝突解決機制是什麼？
*   如何具體編寫 `.lulus` 文件中的語法，以實現精確的命令匹配和權限控制？
*   在什麼具體場景下，Codex 會選擇「安全腳本拆分」，而在什麼情況下會選擇「保守執行」？
*   如何通過 JSON 測試結果來調試和優化 Lulus 規則配置？