
1. 這篇文章真正要解決的問題先說結論Jupyter Notebook 不只是寫 Python 的筆記本工具它是目前最適合把生成式 AI 落地到日常開發工作中的“交互式實驗臺”。很多程序員對 Jupyter Notebook 的態度分兩種要么覺得它只是數據分析師和數據科學家的玩具寫工程代碼根本用不上要么覺得 AI 時代該用各種新出現的 AI 編程工具Jupyter 這種老牌交互式環境已經過時。這兩種判斷在生成式 AI 爆發之后都被推翻了。為什么這樣說回想一下你平時寫 AI 相關代碼會遇到什么情況調用大模型 API 時明明在終端里能跑通一旦放到腳本里就各種報錯。想快速驗證一個提示詞Prompt在不同參數下的效果卻要反復修改代碼、重新執行整個腳本。處理一份數據想把 AI 生成的 JSON 結果可視化看看得先把結果保存成文件再用另一個腳本讀取。想調試一段內嵌了 AI 調用的業務代碼卻看不清每一步的中間輸出。這些痛點本質上不是代碼能力問題而是工具形態問題。終端腳本是線性執行的你無法輕易地停在某個變量上觀察、修改、再繼續而 Jupyter Notebook 把代碼拆成一個個單元格可以獨立運行、重復執行、即時看到輸出這種交互方式恰好和生成式 AI 的“實驗-觀察-調整”節奏完全匹配。另外一個更關鍵的變化是OpenAI、Anthropic、Hugging Face 等主流 AI 生態的官方示例代碼大量以 Jupyter Notebook 的形式發布。模型評測、RAG 問答、Agent 工具調用、微調數據準備隨便打開一個開源項目十有八九能在examples目錄里看到.ipynb文件。換句話說Jupyter Notebook 已經成了生成式 AI 領域的“事實標準演示格式”。不會用它你連很多官方示例都跑不起來。這篇文章要解決的就是如何把 Jupyter Notebook 配置成一個能用于生成式 AI 開發調試的完整環境從安裝、創建內核、安裝依賴到調用大模型 API、處理流式輸出、集成工具調用再到多環境隔離和常見問題排查。讀完你可以直接照著一套流程在手邊搭起一個屬于自己的 AI 實驗環境。文章不會只講怎么打開 Notebook 寫兩行print(hello)而是從實際需求出發一步步走完環境配置、代碼實現、運行驗證和排錯的全過程。2. 環境準備與前置條件在動手配置之前先明確我們要搭什么。很多人在“環境配置”這一步就放棄了不是因為難而是因為網上的教程版本混亂、工具選擇太多不知道聽誰的。這里直接給出一份保守、穩定、適合生成式 AI 開發的環境清單組件推薦方案說明操作系統Windows 10/11 / Ubuntu 20.04 / macOS本文以 Windows 為主演示Linux/macOS 命令基本通用Python 版本Python 3.9 - 3.12太老版本不支持最新依賴太新版本部分庫可能不兼容包管理工具pip venv 或 conda二選一新手推薦 Anaconda工程化推薦 venvJupyter 環境Jupyter Notebook / JupyterLab兩者可以共存建議直接使用 JupyterLabAI 相關依賴openai、langchain 等按實際項目安裝不要一次裝太多瀏覽器Chrome / Edge不要用太老的瀏覽器Jupyter 前端依賴現代瀏覽器特性關于 Python 版本這里先給一個明確建議如果你的電腦上已經有 Anaconda直接用它創建新的虛擬環境如果不想裝 Anaconda就用系統 Python 加 venv。不要在系統 Python 里直接pip install jupyter然后把所有包都裝到全局環境這在后續管理項目依賴時會出現嚴重問題。Jupyter Notebook 和 JupyterLab 的區別很多新手會混淆。簡單對比一下Jupyter Notebook經典的單文檔交互界面一個瀏覽器標簽頁對應一個.ipynb文件操作簡單適合輕量使用。JupyterLabJupyter 官方打造的下一代集成開發環境支持多標簽頁、文件資源管理器、終端、代碼高亮、插件系統更適合做完整項目開發。從生成式 AI 的開發需求來看推薦直接選擇 JupyterLab。它能在同一個界面里同時打開 Notebook、終端、文本編輯器一邊調試 AI 代碼一邊看日志體驗接近一個輕量級 IDE。Jupyter Notebook 稍后也可以繼續使用兩者共享相同的內核機制并不沖突。還有一點需要提前確認你的網絡環境能否訪問大模型的 API 服務。生成式 AI 開發免不了調用云端大模型接口不同服務商的訪問要求不同。在使用任何 API 之前請先確認你使用的服務商提供的接入說明以及你的網絡環境是否滿足訪問條件。這個前置條件如果沒確認好后面的示例代碼即使完全正確也可能出現連接超時。3. Jupyter 環境搭建與基礎配置3.1 方案一使用 Anaconda 安裝推薦新手Anaconda 自帶 Python、conda 包管理器、Jupyter Notebook、JupyterLab 和大量科學計算庫是最省事的方案。下載 Anaconda 安裝包后一路按默認選項安裝。安裝完成后在命令行執行conda --version如果能輸出版本號說明 conda 安裝成功。接下來創建一個專門用于 AI 開發的虛擬環境conda create -n ai-dev python3.10 -y conda activate ai-dev簡要解釋一下這兩條命令conda create -n ai-dev python3.10 -y創建名為ai-dev的虛擬環境并指定 Python 3.10。conda activate ai-dev激活這個環境。注意Windows 命令行和 PowerShell 環境下可能需要先執行conda init初始化 shell。創建完虛擬環境后安裝 Jupyter 相關組件conda install jupyter jupyterlab -y安裝完成后在終端啟動jupyter lab正常情況下瀏覽器會自動打開http://localhost:8888/lab進入 JupyterLab 界面。3.2 方案二使用 venv 安裝推薦工程化如果你不喜歡 Anaconda 的“大而全”更希望保持項目依賴干凈可以使用 Python 自帶的venv。首先確認系統 Python 版本python --version然后創建虛擬環境python -m venv ai-envWindows 下激活ai-env\Scripts\activateLinux/macOS 下激活source ai-env/bin/activate激活后命令行提示符前面會出現(ai-env)表示當前在虛擬環境中。然后安裝 Jupyter 和 JupyterLabpip install --upgrade pip pip install jupyter jupyterlab同樣啟動時執行jupyter lab3.3 配置遠程訪問與固定密碼實際開發中你可能需要在另一臺機器或服務器上訪問 Jupyter。默認啟動方式只監聽本機不方便遠程使用。生成密碼配置文件jupyter server password按提示輸入兩次密碼后會生成一個帶哈希值的配置文件。然后執行jupyter server --generate-config在生成的配置文件中修改以下幾項# 文件路徑~/.jupyter/jupyter_server_config.py c.ServerApp.ip 0.0.0.0 c.ServerApp.port 8888 c.ServerApp.open_browser False c.ServerApp.allow_remote_access True需要說明的是遠程訪問 Jupyter 必須考慮安全邊界特別是當 Jupyter 運行在有公網 IP 的云服務器上時一定要設置強密碼、禁用 root 用戶直接運行 Notebook并建議通過 SSH 隧道或內網環境訪問不要直接把 Jupyter 暴露到公網。更穩妥的方式是使用--no-browser參數僅將 Jupyter 作為本機或內網的開發調試工具使用。3.4 為虛擬環境創建 Jupyter 內核這一步是新手最容易忽略的坑。我們創建了ai-dev或ai-env虛擬環境但在 JupyterLab 的新建 Notebook 中通常只看到默認的Python 3內核。如果直接在默認內核里安裝 AI 依賴會裝到 base 環境或系統環境導致虛擬環境里安裝的包加載不到。解決辦法是在激活的虛擬環境中把當前環境注冊為 Jupyter 的內核pip install ipykernel python -m ipykernel install --user --name ai-dev --display-name Python (ai-dev)參數解釋--name ai-dev內核的唯一名稱。--display-name Python (ai-dev)顯示在 Jupyter 界面中的名稱。創建完成后在 JupyterLab 中新建 Notebook 時就能看到名為Python (ai-dev)的內核選項。以后每個項目都可以通過這種方式創建獨立內核避免依賴沖突。3.5 環境配置的最終檢查完成以上步驟后建議在 Notebook 中執行以下代碼確認環境正確import sys import jupyter print(Python 解釋器路徑:, sys.executable) print(Python 版本:, sys.version) print(Jupyter 版本:, jupyter.__version__)預期輸出中解釋器路徑應該指向你的虛擬環境目錄而不是系統 Python 目錄。這一步能幫你確認“當前 Notebook 用的到底是哪個環境”也是排查各種“我怎么裝了包但導入失敗”問題的入口。同時要注意項目的需求依賴建議寫進requirements.txt或environment.yml方便以后重建環境。不要憑記憶手動安裝依賴。4. 生成式 AI 開發的核心概念配置好 Jupyter 之后先別急著寫代碼。要把生成式 AI 開發跑通需要先理解幾個核心概念。這些概念看起來簡單但在實際調試時如果理解不透很容易被各種報錯折磨。4.1 大模型 API 與提示詞生成式 AI 應用的最基本形式就是調用大模型 API。你把一段輸入文本Prompt提示詞發給模型模型返回一段生成結果。在 Jupyter 單元格中調用過程通常是這樣from openai import OpenAI client OpenAI(api_keyyour-api-key) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一個擅長代碼審查的助手。}, {role: user, content: 請幫我解釋下面的代碼是做什么的...} ] ) print(response.choices[0].message.content)這里的messages列表是 Chat Completion API 的核心結構包含三類角色system系統指令用來設定模型的行為和身份。user用戶輸入也就是你希望模型回答的問題。assistant模型的回復在多輪對話中帶上歷史回復讓模型記住上下文。在這個示例中需要注意 API Key 千萬不要直接寫在 Notebook 中并提交到代碼倉庫。更安全的做法是使用環境變量import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY))在終端設置環境變量export OPENAI_API_KEYyour-api-keyWindows PowerShell 下$env:OPENAI_API_KEYyour-api-key4.2 流式輸出與實時交互調用大模型時如果模型生成內容較長等待完整結果返回會讓人感覺“卡住了”。實際上大模型本身是逐 token 生成內容的API 也支持流式輸出Stream像 ChatGPT 那樣一個字一個字地出現在屏幕上。在 Jupyter 中實現流式輸出尤其有價值因為 Notbook 可以逐行顯示輸出效果非常直觀from openai import OpenAI import os client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) stream client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 寫一段 Python 代碼實現斐波那契數列。}], streamTrue, ) for chunk in stream: if chunk.choices[0].delta.content is not None: print(chunk.choices[0].delta.content, end, flushTrue)這段代碼的核心區別在于streamTrue后API 返回的是一個生成器對象可以逐個區塊讀取內容。flushTrue確保內容能實時打印而不是攢到緩沖區才顯示。這里真正容易踩坑的地方是部分模型服務商的兼容接口對stream參數的處理方式不完全一致有的返回delta.content有的返回choices[0].delta但content為None。如果輸出為空可以先打印一個chunk看完整結構再決定取值字段。4.3 上下文管理與多輪對話很多人把多輪對話理解成“把用戶每句話拼接起來發給模型”這其實不對。正確的做法是把整個對話歷史作為messages列表傳給模型讓模型自己理解上下文messages [ {role: system, content: 你是一個 Python 導師回答要簡潔。}, ] messages.append({role: user, content: 什么是生成式 AI}) response client.chat.completions.create(modelgpt-4o-mini, messagesmessages) assistant_reply response.choices[0].message.content messages.append({role: assistant, content: assistant_reply}) messages.append({role: user, content: 那它和普通 AI 有什么區別}) response client.chat.completions.create(modelgpt-4o-mini, messagesmessages) print(response.choices[0].message.content)隨著對話輪次增加messages會越來越長最終超過模型的最大上下文長度。這時要考慮上下文壓縮、摘要或滑動窗口策略。在生成式 AI 應用里這部分通常需要專門的框架或向量數據庫支持不是簡單拼接就能解決的。4.4 工具調用與 Agent 雛形生成式 AI 不只是“問答機器”。通過工具調用Function Calling / Tool Use模型能夠決定在某些時候調用外部函數比如查詢數據庫、搜索網頁、執行代碼從而完成更復雜的任務。用通俗的方式理解模型就像一個聰明的實習生它能聽懂你的需求但很多具體操作需要調用你提供的工具完成。工具調用就是給這個實習生一套“工具箱”并告訴他每個工具怎么用。在 Jupyter 中你可以非常方便地驗證工具調用流程模型返回一個“意圖”你根據意圖執行本地代碼然后把結果返回給模型讓模型根據結果生成最終回復。這種“模型-工具-模型”的循環就是 Agent 應用的核心機制。5. Jupyter Notebook 集成生成式 AI 完整示例理清基礎概念后我們用一個完整示例把整個流程串起來。這個示例雖然不大但覆蓋了生成式 AI 開發的典型套路環境變量管理、模型調用、流式輸出、結構化輸出以及將復雜邏輯封裝成類以便在 Jupyter 中反復調試。5.1 安裝依賴在虛擬環境激活狀態下執行pip install openai python-dotenvopenaiOpenAI 官方 Python SDK目前大多數兼容接口也通過該 SDK 調用。python-dotenv用于加載.env文件中的環境變量。然后創建.env文件放在項目根目錄# 文件路徑.env OPENAI_API_KEYyour-api-key-here5.2 加載環境變量在 Jupyter 第一個單元格中from dotenv import load_dotenv import os load_dotenv() api_key os.getenv(OPENAI_API_KEY) print(API Key 是否已加載:, bool(api_key))如果輸出True說明環境變量加載成功。如果輸出False請檢查.env文件路徑是否與 Notebook 所在目錄一致。Jupyter 的工作目錄默認是啟動時所在的目錄不是 Notebook 文件所在目錄這一點很容易搞混。5.3 封裝一個通用的大模型調用類為了后續在多個 Notebook 中復用建議把大模型調用封裝成一個簡單的類# 文件ai_client.py from openai import OpenAI from dotenv import load_dotenv import os load_dotenv() class AIClient: def __init__(self, modelgpt-4o-mini): self.client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) self.model model def chat(self, messages, streamFalse): response self.client.chat.completions.create( modelself.model, messagesmessages, streamstream, ) return response def stream_chat(self, messages): stream self.chat(messages, streamTrue) collected [] for chunk in stream: if chunk.choices[0].delta.content is not None: content chunk.choices[0].delta.content print(content, end, flushTrue) collected.append(content) print() return .join(collected)在 Jupyter 中導入并使用from ai_client import AIClient ai AIClient(modelgpt-4o-mini) messages [ {role: system, content: 你是一個代碼審查助手回答使用中文。}, {role: user, content: 請審查以下 Python 代碼指出潛在問題\n\ndef calculate_average(nums):\n return sum(nums) / len(nums)}, ] ai.stream_chat(messages)這個類的好處是模型名稱、API 密鑰、調用方式都集中管理在 Notebook 中調試時只需要修改一個地方。實際項目中你還可以增加日志、重試、超時控制等功能。5.4 使用生成式 AI 分析代碼文件現在模擬一個更貼近開發者的場景我們有一段程序員的代碼希望 AI 幫忙分析復雜度、指出問題并給出優化建議。先把代碼定義為字符串避免在 Notebook 中創建臨時文件target_code def fetch_user_data(user_id): conn create_connection() cursor conn.cursor() cursor.execute(SELECT * FROM users WHERE id ?, (user_id,)) rows cursor.fetchall() result [] for row in rows: result.append({id: row[0], name: row[1], email: row[2]}) return result analysis_prompt f 請對以下代碼進行審查輸出 JSON 格式的結果包含三個字段 - summary: 代碼功能概述 - issues: 潛在問題列表 - suggestion: 改進建議 代碼 {target_code} messages [ {role: system, content: 你是資深后端工程師擅長代碼審查。}, {role: user, content: analysis_prompt}, ] response ai.chat(messages) content response.choices[0].message.content print(content)這里用了提示詞強制要求模型輸出 JSON 結構。在實際項目中更推薦使用 API 的響應格式參數或工具調用來獲得穩定的結構化輸出而不是僅靠提示詞約束。5.5 在 Notebook 中繪制結果生成式 AI 的響應經常包含文本和結構化數據。在 Notebook 中你可以直接用 Pandas 和 Matplotlib 把 AI 生成的結果可視化這是終端腳本很難做到的體驗。例如讓 AI 生成一份包含“代碼問題嚴重程度”的 JSON 數據然后讀取并繪圖import json import pandas as pd import matplotlib.pyplot as plt data json.loads(content) issues data.get(issues, []) # 簡單統計每個問題的關鍵詞 issue_keywords [issue[:4] for issue in issues] # 取前4個字作為簡易類別 df pd.DataFrame({問題: issue_keywords}) df[數量] 1 summary_df df.groupby(問題).count().reset_index() plt.figure(figsize(8, 4)) plt.bar(summary_df[問題], summary_df[數量]) plt.title(代碼審查問題統計) plt.xlabel(問題類別) plt.ylabel(數量) plt.xticks(rotation45) plt.show()這個例子不算復雜但它展示了 Jupyter 集成生成式 AI 的核心優勢在同一個文檔里完成“生成數據-處理數據-可視化數據”的完整閉環。6. 運行結果與效果驗證以上代碼運行后我們需要驗證是否真的成功了。生成式 AI 開發與普通 Web 開發不同判斷“成功”不只是看有沒有報錯還要看輸出質量是否符合預期。6.1 驗證模型連接是否成功最簡單的驗證方式是調用一次短文本生成觀察輸出test_messages [ {role: user, content: 請回答11等于幾只輸出數字。}, ] response ai.chat(test_messages) print(response.choices[0].message.content)預期輸出2如果這一步能輸出內容說明 API 密鑰、網絡連接、SDK 版本都正常。這是整個 AI 開發流程的“最小可行驗證”。6.2 驗證流式輸出是否正常執行 5.3 中的stream_chat方法如果終端或 Notebook 單元格逐字打印出內容說明流式輸出生效。如果內容一次性打印說明flushTrue未生效或輸出緩沖機制不同。如果完全沒有輸出需要檢查chunk結構stream ai.chat(test_messages, streamTrue) for chunk in stream: print(chunk)觀察打印出來的對象結構確認字段名。不同版本 SDK 的字段結構可能略有不同。6.3 驗證結構化輸出是否可解析在 5.4 節模型返回的內容是 JSON 字符串。需要驗證能否被json.loads解析try: parsed json.loads(content) print(JSON 解析成功) print(字段列表:, list(parsed.keys())) except json.JSONDecodeError as e: print(JSON 解析失敗:, e)如果失敗常見原因是模型在 JSON 前后添加了 Markdown 代碼塊標記比如json {...}解決辦法是清洗內容 python def extract_json(text): # 去掉可能的 markdown 標記 if text.startswith(): text text.strip() if text.startswith(json): text text[4:] return json.loads(text)6.4 驗證環境隔離是否生效在 Jupyter 單元格中執行import sys print(sys.executable)如果輸出路徑指向虛擬環境如/path/to/ai-env/bin/python或C:\...\ai-env\Scripts\python.exe說明當前 Notebook 使用的確實是虛擬環境的內核。如果輸出指向系統 Python 或 Anaconda base 環境說明內核選擇錯誤需要重新執行第 3.4 節的內核創建步驟。7. 環境配置與 AI 開發常見問題排查在實際操作中環境配置和 AI 調用是兩大問題高發區。這里整理一份排查清單按出現頻率排序。問題現象可能原因排查方式解決方案Jupyter 啟動后瀏覽器空白瀏覽器版本過舊、內核崩潰、端口被占用檢查瀏覽器控制臺報錯更換瀏覽器訪問更新瀏覽器重啟 Jupyter換端口啟動jupyter lab --port 8890Notebook 導入了虛擬環境之外的包當前內核不是目標虛擬環境print(sys.executable)查看解釋器路徑激活虛擬環境后重新執行python -m ipykernel install --user --name my-env并在 Notebook 中切換內核ModuleNotFoundError: No module named openai依賴裝錯環境查看 pip 安裝時的提示路徑確認虛擬環境已激活后重新pip install openaiAPI 調用超時網絡不通、代理干擾、模型服務端異常先測試網絡連通性查看錯誤碼檢查網絡環境重試使用支持超時參數的 SDK 配置API 返回401 UnauthorizedAPI Key 錯誤或未設置打印api_key前綴確認來源檢查.env文件、環境變量是否正確加載API 返回RateLimitError觸發調用頻率限制查看錯誤響應中的 Retry-After 時間降低調用頻率升級套餐增加退避重試邏輯流式輸出沒有逐字顯示緩沖機制、SDK 版本差異檢查flushTrue打印 chunk 結構改用display()方法或在循環中收集后統一顯示json.loads解析失敗模型輸出中包含 Markdown 標記或多余文本打印原始content查看頭尾字符編寫清洗函數去除 Markdown 標記后解析7.1 關于ModuleNotFoundError的深層排查很多人在 Jupyter 中import包失敗但在終端中import成功這是因為 Jupyter 的內核環境與終端環境不一致。排查步驟在 Notebook 中執行python -c import sys; print(sys.executable)。在終端中執行pip show package-name查看包安裝路徑。對比兩者路徑是否一致。如果不一致執行# 激活目標環境 conda activate ai-dev # 重新安裝 ipykernel 并注冊 python -m ipykernel install --user --name ai-dev --display-name Python (ai-dev)然后在 JupyterLab 中選擇內核Kernel - Change Kernel - Python (ai-dev)。7.2 關于 Jupyter 啟動后空白頁Windows 上經常出現 Jupyter 啟動后瀏覽器打開但頁面空白的問題。原因可能是筆記本默認瀏覽器不支持 WebSocket或者瀏覽器插件攔截。建議按以下順序排查手動復制終端輸出的http://localhost:8888/lab地址在 Chrome 或 Edge 中打開。清除瀏覽器緩存。查看終端日志是否出現KernelRestarter或WebSocket相關錯誤。如果仍空白嘗試在啟動命令中加入--no-browser后手動打開地址。7.3 關于 API Key 管理這里要特別強調任何形式的 API Key 泄露都可能造成資金損失和安全問題。不要把 Key 寫到代碼里更不要直接把.env文件提交到 Git 倉庫。建議在.gitignore中添加.env *.env同時在云服務器上運行 Jupyter 時不要直接用 root 賬號啟動建議創建普通用戶并限制目錄訪問權限。8. 生產環境與工程化最佳實踐如果只是個人學習把 Jupyter 和生成式 AI 跑通就足夠了。但如果你想把這個流程用到團隊項目或生產環境中下面這些實踐值得提前了解。8.1 環境隔離與依賴管理在生成式 AI 項目中依賴版本變化非常快。今天能用openaiSDK 的 1.x 版本明天模型服務商可能就更新接口。所以環境隔離不是可選項而是必須項。推薦做法每個項目單獨創建虛擬環境單獨注冊 Jupyter 內核。使用requirements.txt或pyproject.toml鎖定依賴版本。定期更新依賴但更新前先在虛擬環境測試。不要直接在 base 環境安裝包。生成依賴鎖定文件的方式pip freeze requirements-lock.txt8.2 提示詞版本管理與測試生成式 AI 應用與傳統軟件最大的不同提示詞就是代碼的一部分但它很難做單元測試。同一個提示詞換一個模型版本輸出可能完全不一樣。因此工程化項目中通常會把提示詞抽取到單獨的模塊并用測試用例維護# 文件prompts.py CODE_REVIEW_SYSTEM_PROMPT 你是一個資深后端工程師擅長代碼審查。 CODE_REVIEW_USER_PROMPT_TEMPLATE 請對以下代碼進行審查輸出 JSON 格式的結果包含三個字段 - summary: 代碼功能概述 - issues: 潛在問題列表 - suggestion: 改進建議 代碼 {code} 這樣做的價值是可以在 Notebook 或測試腳本中引用同一個提示詞模板保證線上和實驗環境一致。避免在 Notebook 里寫死提示詞部署到生產時又復制一份到代碼里最后兩邊不一致。8.3 模型調用的可觀測性調用大模型 API 時一定要記錄日志。原因是大模型接口是黑盒出錯時需要知道請求參數、響應內容、耗時和錯誤碼。在AIClient中增加簡單日志import logging import time logger logging.getLogger(__name__) class AIClient: def __init__(self, modelgpt-4o-mini): self.client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) self.model model def chat(self, messages, streamFalse): start_time time.time() logger.info(開始調用模型 %s消息數量 %d, self.model, len(messages)) response self.client.chat.completions.create( modelself.model, messagesmessages, streamstream, ) elapsed time.time() - start_time logger.info(模型調用完成耗時 %.2f 秒, elapsed) return response在生產環境中應把日志輸出到收集系統而不是全部打到控制臺。這部分根據團隊實際技術棧選擇。8.4 安全與合規提醒涉及生成式 AI 開發有幾個安全邊界必須注意不要將敏感數據直接發送給大模型 API。在發送前盡量做脫敏處理。不要自動執行模型生成的代碼。模型輸出可能包含惡意內容如果需要執行必須在沙箱環境中。對模型輸出做校驗特別是涉及 SQL、文件路徑、命令執行時禁止直接拼接執行。遵守模型服務商的使用條款不要批量抓取或濫用接口。這些提醒看起來很基礎但在實際生產中正是這些細節決定了系統能否穩定運行。8.5 Notebook 與生產代碼的邊界最后給一個明確的工程建議Jupyter Notebook 適合做實驗和調試但不適合直接作為生產代碼運行。如果你已經在 Notebook 中驗證了一個 AI 功能把它遷移到生產時應該將核心邏輯抽到 Python 模塊或服務中。去掉 Notebook 特有的狀態依賴。使用配置管理工具管理環境和密鑰。編寫自動化測試至少覆蓋“調用成功”“調用失敗”“輸入為空”三類場景。部署前在實際環境跑一次冒煙測試。Notebook 的最大價值是讓你更快地探索和驗證想法生產系統的穩定性還是要靠規范的代碼和流程來保障。9. Jupyter Notebook 與 JupyterLab 的選型參考回到很多新手糾結的問題Jupyter Notebook 和 JupyterLab 到底選哪個給出直接的結論新項目直接用 JupyterLab老教程里涉及.ipynb文件的用 JupyterLab 打開也一樣可以運行。兩者能處理的文件格式相同JupyterLab 是 Jupyter Notebook 的超集界面。不過如果只是臨時打開別人分享的.ipynb文件看一下運行結果那么 Jupyter Notebook 更輕量啟動速度更快。另一種情況是你的項目代碼主要是純 Python 腳本只有少數幾個 Notebook 用來做試驗也可以混合使用。兩者對比對比項Jupyter NotebookJupyterLab界面形態單文檔界面多標簽頁集成界面文件瀏覽器無有終端支持弱內置終端插件生態較少豐富適用場景輕量查看、簡單實驗完整開發、調試、AI 項目未來趨勢維護模式官方主推方向從生成式 AI 開發的實際體驗來看JupyterLab 的多標簽頁支持非常實用一個標簽頁寫 Notebook一個標簽頁打開終端一個標簽頁看文檔效率比來回切換窗口高很多。10. 總結與后續學習方向這篇內容差不多把“Jupyter Notebook 生成式 AI 環境配置”這條線完整走了一遍理解了 Jupyter 系列工具在 AI 開發中的定位它本質上是交互式實驗臺和 AI 的探索式工作流非常匹配。完成了從 Anaconda/venv 到 Jupyter 內核注冊的環境搭建解決了“包裝錯環境”“內核選錯”等經典問題。通過完整示例實現了大模型 API 調用、流式輸出、結構化輸出、代碼審查與結果可視化。整理了常見問題排查表覆蓋環境配置和 API 調用兩大高頻故障區。探討了生產環境中的依賴管理、提示詞版本管理、日志可觀測性、安全邊界等工程化問題。下一步的學習方向可以根據自己的目標選想深入理解生成式 AI 的原理學習 Transformer 的核心架構理解 Token、注意力機制、上下文窗口等基礎概念這對調優提示詞和選擇模型有很大幫助。想做 RAG 應用把 LLM 和向量數據庫結合起來在 Jupyter 中試驗文檔切分、嵌入、檢索的完整流程。想做 Agent 應用研究工具調用機制在 Notebook 中搭建一個能自動調用外部函數的 Agent 原型。想進入生產部署學習如何把 Notebook 中驗證過的代碼打包成服務配置 CI/CD處理模型 API 的并發和降級策略。一個比較實用的建議是把你日常開發中的一個低頻重復任務比如代碼審查、日志分析、測試用例生成用 Jupyter 生成式 AI 做一個原型。花兩個小時跑通感受一下交互式調試帶來的效率變化比看再多教程都有用。環境配置是第一步也是最容易勸退的一步現在照著上面的步驟跑通一次后面就順暢了。建議收藏備用遇到環境問題的時候回來對照排查清單能省下不少搜索時間。