# 影片筆記：2026版AI+Codex零基础全套视频课程，Codex从入门到大神AI编程开发，涵盖安装配置、代码分析、Bug修复及完整项目实战 p13 12、基于 Codex 全流程开发 RAG 智能客服系统

## 一句話總結

本段影片演示了如何使用 **Codex** 工具，遵循「先架構設計、後代碼生成」的原則，全流程開發一個基於 **RAG**（檢索增強生成）技術的智能客服系統，涵蓋了從環境配置、技術棧選擇（Streamlit, LangGraph, Chroma）、需求拆解到最終代碼生成的完整實踐過程。

## 核心重點

1.  **RAG 系統的核心價值**：
    *   解決通用大模型缺乏內部行業知識的問題，提高回答的專業性與準確性。
    *   相比傳統的微調（Fine-tuning）方案，RAG 無需高昂的微調成本，通過掛載內部知識庫即可實現精準回答。
    *   原理類似於學生查閱圖書館書籍後撰寫文章，即先檢索相關知識，再基於檢索結果生成回答。

2.  **技術架構與組件選擇**：
    *   **前端**：使用 **Streamlit** 快速構建 Python 前端頁面，支持聊天界面、側邊欄及多頁面導航，適合快速演示與內部工具開發。
    *   **後端邏輯**：
        *   **LangChain**：負責模型調用、文檔加載、切分及檢索工具封裝。
        *   **LangGraph**：專門用於複雜 Agent 開發，基於圖形式工作流管理 Agent 狀態機、數據流轉及工具調用循環。
    *   **數據存儲**：使用 **Chroma** 作為向量數據庫，存儲向量化後的知識庫內容。
    *   **模型**：默認使用 OpenAI GPT-4o 及 Embedding 模型，但也支持替換為 DeepSeek、Ollama 等本地或雲服務模型。

3.  **Codex 開發最佳實踐**：
    *   **提示詞驅動**：以清晰的提示詞梳理需求，而非直接讓 AI 寫代碼。
    *   **先架構，後代碼**：在生成代碼前，先讓 Codex 輸出項目目錄結構、模塊職責及開發順序。
    *   **任務細化**：將大需求拆解為單一任務，讓 AI 逐步執行，避免一次性生成過於複雜的代碼。
    *   **規範調整**：若 Codex 生成的結構過於複雜（如過度使用 DDD），需調整全局規範文件（如 `.codex/agents.md`）並重新發起對話。

## 詳細大綱

### 一、 系統演示與需求分析
*   **功能演示**：展示簡單的對話頁面，模擬銀行客服場景（查詢餘額、修改密碼）。
*   **痛點與解決方案**：
    *   **痛點**：通用大模型缺乏公司內部知識，回答不專業。
    *   **傳統方案局限**：預訓練與微調成本過高。
    *   **RAG 方案優勢**：無需微調，成本低，回答準確，基於檢索結果生成。

### 二、 技術架構與核心組件
*   **RAG 工作流程**：
    1.  文檔上傳與切分（Chunking）。
    2.  向量化（Embedding）：將文本轉換為向量坐標。
    3.  存儲：存入向量數據庫。
    4.  檢索：用戶提問時，進行向量相似度匹配，檢索最相關內容。
    5.  生成：將檢索內容組裝成提示詞，丟給大模型生成回答。
    6.  流式輸出（Streaming）：實現打字機效果，提升用戶體驗。
*   **技術棧詳細說明**：
    *   **Streamlit**：Python 生態，快速構建前端，對比 Node.js/React/Vue 更適合快速交付與測試。
    *   **LangGraph**：管理 Agent 狀態與流程控制，處理多智能體場景。
    *   **LangChain**：處理基礎模型調用與工具封裝。
    *   **Chroma**：開源向量數據庫，支持本地與服務器部署。

### 三、 Codex 開發環境準備
*   **安裝與配置**：
    *   支持命令行、Codex App 或 VS Code 插件。
    *   配置 API Key 或通過官方網站跳轉授權。
    *   設置環境變量（Mac/Linux 或 Windows 的 `SateX` 命令，疑點見下文）。
    *   配置後需重啟終端生效。
*   **權限設置**：
    *   **Auto Review / Auto Edit**：自動授權模式，適合熟悉後快速提效。
    *   **手動確認模式**：適合初學者，保證安全，敏感操作需用戶確認。
    *   本演示使用自動授權模式。

### 四、 基於 Codex 的開發實踐
*   **開發原則**：提示詞驅動、先架構後代碼、任務細化。
*   **具體步驟**：
    1.  **環境準備**：進入項目目錄，打開終端，配置 Codex 權限。
    2.  **需求與架構設計**：
        *   提供清晰提示詞，限定技術棧與功能需求（知識庫頁面、上傳 Markdown 自動切分、對話啟用知識庫）。
        *   **關鍵指令**：「請先不要寫代碼，先輸出推薦的項目目錄結構、每個模塊的工程職責、建議的開發順序（從底層到上層）。」
    3.  **調整與優化**：
        *   檢查 Codex 生成的目錄結構。
        *   若結構過於複雜，調整全局規範文件（如移除 DDD 規範），重新發起對話以生成更簡潔的結構。
    4.  **代碼生成**：
        *   確認架構無誤後，讓 Codex 按照目錄結構與職責逐步生成代碼。

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

*   **Codex**：AI 編程輔助工具，支持命令行、App 及 VS Code 插件。
*   **RAG (Retrieval-Augmented Generation)**：檢索增強生成，一種通過掛載外部知識庫來增強大模型回答準確性的技術。
*   **Streamlit**：Python 前端框架，用於快速構建數據應用與聊天界面。
*   **LangGraph**：基於圖的工作流框架，用於開發複雜的 Agent，管理狀態機與數據流轉。
*   **LangChain**：LLM 應用開發框架，負責模型調用、文檔處理及工具封裝。
*   **Chroma**：開源向量數據庫，用於存儲和檢索向量數據。
*   **OpenAI GPT-4o**：影片默認使用的大語言模型。
*   **OpenAI Embedding**：用於將文本轉換為向量坐標的模型。
*   **DeepSeek / Ollama**：影片提及的可選模型，支持本地部署或雲服務。
*   **向量數據庫 (Vector Database)**：用於存儲向量化後數據的數據庫。
*   **DDD (Domain-Driven Design)**：領域驅動設計，影片中提到若 Codex 過度使用此設計模式，需調整規範。
*   **API Key**：應用程序接口密鑰，用於身份驗證。
*   **Markdown**：一種輕量級標記語言，用於知識庫文檔上傳。

## 操作流程整理

1.  **環境配置**：
    *   安裝 Codex（命令行/App/插件）。
    *   配置 API Key。
    *   設置環境變量（Windows 使用 `SateX`，疑點見下文）。
    *   重啟終端。
    *   設置權限為 Auto Review / Auto Edit。

2.  **需求分析與架構設計**：
    *   進入項目目錄。
    *   向 Codex 提供清晰提示詞，描述功能需求（知識庫管理、對話功能）及技術棧限制。
    *   發送關鍵指令：要求 Codex 先輸出項目目錄結構、模塊職責及開發順序，暫不寫代碼。

3.  **架構審查與調整**：
    *   檢查 Codex 生成的目錄結構。
    *   若結構過於複雜（如包含不必要的 DDD 規範），修改全局規範文件（`.codex/agents.md`）。
    *   重新發起對話，讓 Codex 生成更簡潔的結構。

4.  **代碼生成與實現**：
    *   確認架構無誤。
    *   讓 Codex 按照確定的目錄結構與職責，逐步生成代碼。
    *   參考 Codex 建議或提供自定義規範，完成系統開發。

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

*   **模型選擇風險**：雖然默認使用 OpenAI 模型，但替換為其他模型（如本地部署模型）時，需確保 Embedding 模型與 LLM 的兼容性。
*   **架構過度複雜風險**：Codex 可能過度使用 DDD 等複雜設計模式，導致項目結構難以維護，需通過調整規範文件進行干預。
*   **環境變量設置風險**：Windows 環境下設置環境變量的命令在逐字稿中識別為 `SateX`，若實際命令錯誤將導致配置失敗。
*   **權限設置風險**：自動授權模式（Auto Edit）雖提高效率，但可能帶來安全風險，需根據用戶熟練度謹慎選擇。

## 逐字稿辨識疑點

*   **RUG / Rug**：逐字稿中多次口誤為「RUG」，根據上下文應為 **RAG**。
*   **Clamour / Clama**：逐字稿中向量數據庫名稱口誤為「Clamour」或「Clama」，根據上下文應為 **Chroma**。
*   **long graph / long chain / long turn**：逐字稿中多次口誤為「long graph」、「long chain」、「long turn」，根據上下文應為 **LangGraph** 與 **LangChain**。
*   **渲電**：逐字稿中提到「模型微调，渲电的这个条件」，疑點為「渲電」，可能為口誤，需查證是否指「渲染」或其他特定術語，或為聽寫錯誤。
*   **下量化 / 限量数据库 / 下量数据库**：逐字稿中多次口誤為「下量化」、「限量数据库」、「下量数据库」，根據上下文應為 **向量化** 與 **向量數據庫**。
*   **抄**：逐字稿中提到「上下文可能會抄」，疑點為「抄」，可能為口誤，意指「超出」或「超載」。
*   **SateX**：逐字稿中提到 Windows 上設置環境變量的命令為「SateX」，疑點為該命令，實際 Windows 命令通常為 `setx`。
*   **Rack System / RockSystem**：逐字稿中項目名稱口誤為「Rack System」或「RockSystem」，需查證實際項目名稱，可能為 **RAG System**。
*   **dv 驱动**：逐字稿中提到「dv 驱动的方式开发」，疑點為「dv」，可能為口誤，意指「DDD」或其他縮寫。
*   **路库**：逐字稿中提到「路库的一些用力」，疑點為「路库」，可能為口誤，意指「知識庫」或「向量庫」。
*   **充用**：逐字稿中提到「共用了限量数据库」，疑點為「充用」，可能為口誤，意指「共用」或「調用」。
*   **介入**：逐字稿中提到「模型的一些介入」，疑點為「介入」，可能為口誤，意指「調用」或「接入」。
*   **命理**：逐字稿中提到「跑命理修bug」，疑點為「命理」，可能為口誤，意指「命令」。
*   **支柔体**：逐字稿中提到「AI制整体应用...支柔体」，疑點為「支柔体」，可能為口誤，意指「智能體」。
*   **Rog**：逐字稿中提到「Rog这一块的一个核心技术」，疑點為「Rog」，可能為口誤，意指 **RAG**。
*   **欧拉玛**：逐字稿中口誤為「欧拉玛」，根據上下文應為 **Ollama**。

## 可延伸追問

*   如何具體配置 `.codex/agents.md` 文件來限制 Codex 使用 DDD 設計模式？
*   在生產環境中，如何監控 RAG 系統的檢索準確率與生成質量？
*   若使用本地部署模型（如 Ollama），如何確保其 Embedding 模型與 OpenAI 模型的向量空間兼容性？
*   Streamlit 在處理高併發聊天請求時有哪些性能瓶頸，如何優化？
*   LangGraph 狀態機在處理多輪對話歷史時，如何設計狀態節點以避免上下文丟失？