MBPP

3 秒看懂

MBPP（Mostly Basic Python Problems）是 Google 在 2021 年釋出的公開基準資料集，專門用於評估大語言模型在基礎 Python 程式設計任務上的程式碼生成能力。它由約 1000 道獨立程式設計題組成，每題配有自然語言描述和多個自動化測試用例，是衡量模型“寫出可直接執行的正確程式碼”能力的關鍵標尺。

3 分鐘產業解釋

MBPP 本質是一套標準化考卷，而不是生產技術指標。其題目覆蓋 Python 的基礎語法、內建資料結構、標準庫呼叫和簡單演算法，考察的是模型在明確、獨立、低複雜性任務上的可靠度。

在產業層面，MBPP 的價值體現在五個維度：

1. 產品研發的基線標定
所有主流 AI 程式設計助手（如 GitHub Copilot、Cursor、通義靈碼、Codeium 等）背後的模型都會在 MBPP 上持續刷分。分數越高，通常代表模型生成正確可用程式碼片段的機率越高，這直接支撐產品體驗。

2. 技術能力的橫向透明化
MBPP 完全公開，任何團隊均可下載測試，避免了廠商的封閉自評。Hugging Face 的 Open LLM Leaderboard 和 Papers with Code 的程式碼生成排行榜，令投資者和開發者都能一目瞭然地比較模型的水準。

3. 開源與閉源競爭的風向標
開源模型（如 CodeLlama、DeepSeek-Coder、StarCoder）與閉源模型（GPT-4、Claude、Gemini）在 MBPP 上的差距變化，反映了開源社群的追趕速度。這在創投圈常被用作判斷“大廠護城河深淺”的量化參考。

4. 能力邊界的對映器
MBPP 只測試獨立函式的生成，不涉及多檔案專案、系統設計、需求分析或程式碼維護。因此，它的高分標誌著模型已成為一個“基本功紮實的程式設計新手”，能夠完成明確的小任務，但不能推斷其具備獨立承擔大型工程的能力。

5. 評測生態的基礎元件
MBPP 的成功促使研究者將其範式擴充套件到更多語言（MultiPL-E）、更復雜領域（MBPP+、MBPP-Eval），形成了圍繞“自然語言到可執行程式碼”的評估生態。它是該生態的基石之一。

技術原理

MBPP 的工作原理是一條受控的、可復現的程式碼生成與自動驗證流水線。整個流程可以拆解為生成-取樣-執行三階段：

[輸入] 自然語言任務描述 + 可選函式簽名
  例："Write a python function to find the second largest number in a list."
        ↓
[生成] 大語言模型解碼生成程式碼樣本
(通過調整 temperature 等取樣引數，可生成多個候選)
        ↓
[輸出] 一個或多個 Python 函式體
        ↓
[驗證] 將模型輸出與預設的測試用例合併
  例：assert second_largest([1,2,3,4]) == 3
        ↓
[執行] 在隔離沙箱中執行完整指令碼
        ↓
[判定] 全測試用例通過 → 正確；任一斷言失敗或語法錯誤 → 錯誤

核心評估指標：Pass@k
該指標衡量：對於每個任務，若讓模型生成 k 個程式碼樣本，至少有一個樣本通過所有測試用例，則該任務被視作通過。資料集的整體得分是任務通過率。Pass@1 最貼近實際使用場景（一次生成即可用），Pass@10 和 Pass@100 則反映模型的“潛力上限”。指標計算採用無偏估計公式，避免因有限取樣造成系統偏差。

測試用例設計原則
MBPP 中每題平均配有約 3 個測試用例，設計遵循三個原則：典型輸入覆蓋常規場景；邊界值覆蓋空列表、單元素、極大值等極端情況；負例覆蓋可能出現的不合法輸入，以檢驗程式碼的健壯性。這一機制保證通過的程式碼是“真正理解問題邏輯”而不僅是死記硬背輸入輸出對。

隔離執行環境
為防止生成程式碼包含惡意操作或破壞系統，所有驗證均在沙箱（如 Docker 容器或雲端函式）中完成，並設有超時和資源限制。當前雲端服務商提供的 Function-as-a-Service 和 CI 容器便足以規模化執行此類評估。

關鍵引數

評估一個模型在 MBPP 上的表現，需要關注以下維度及其引數口徑：

1. Pass@1 / Pass@10 / Pass@100
最核心的能力指標。通常以百分比表示，代表對應取樣數下的任務通過率。需註明取樣溫度和去重策略。多數論文報告的 MBPP Pass@1 使用貪婪解碼（temperature=0）或 temperature=0.2；若無特殊說明，預設為貪婪解碼。取值越高說明基礎程式碼生成能力越強。

2. 評估基準版本
MBPP 存在多個變體：原始 MBPP（約 974 題）、MBPP-sanitized（去除部分重複或歧義題，約 400+ 題）、MBPP+（增加更多測試用例）。報告分數時必須標明所用版本。部分研究僅使用 MBPP 的“prompt-only”格式（不含函式簽名），這通常更難，分數會偏低。

3. 多語言擴充套件 Pass@1
通過 MultiPL-E 架構可將 MBPP 的 Python 任務轉化為其他語言版本。該引數用於評估模型在跨語言基礎程式設計上的泛化能力。格式一般為“MultiPL-E (Java) Pass@1”。

4. 平均程式碼長度
成功通過測試的生成程式碼的平均行數或字元數。較短且通過測試的解，通常意味著模型更能寫出簡潔、直接且少冗餘的實現。這也間接反映模型的邏輯歸納能力。

5. 安全與有害性通過率
一些擴充套件工作會在測試集中混入潛在不安全的描述（如“讀取密碼檔案”），檢驗模型是否會生成危險的程式碼。負向指標：不安全程式碼生成率，越低越好。

6. 資料汙染檢測指標
由於 MBPP 已公開多年，存在訓練資料洩露風險。部分報告會輔以資料汙染檢測（如 n-gram 重疊率、字串匹配度），用於輔助判斷高分是否來自“背誦”。此為輔助參考指標。

在參考任何具體分數時，必須同步記錄：模型名稱、引數量、評估版本（如 MBPP-sanitized）、取樣引數（temperature、top_p、取樣次數）及報告來源（論文/排行榜連結），否則橫向對比會失去意義。

技術路線

MBPP 所處的技術路線，可從時間演進和橫向分工兩個維度去理解。

從“程式碼搜尋”到“基礎生成”，再到“真實工程”
2021 年以前，主流程式碼資料集（如 CodeSearchNet）集中在程式碼搜尋和摘要任務，模型並不直接生成可執行程式碼。2021 年，OpenAI 同時釋出 Codex 模型和 HumanEval 基準，首次讓“從自然語言直接生成程式碼並自動驗證”成為大規模可評測的範式。同樣在 2021 年，Google 釋出 MBPP，用更基礎和直白的題目拓寬了測試覆蓋面。兩者共同構成了基礎程式碼生成的雙支柱。

2022 年到 2023 年，圍繞 MBPP 的擴充套件主要朝兩個方向：一是多語言化（MultiPL-E），將同一評估架構複製到 Java、JavaScript、C++ 等；二是資料質量和防作弊（MBPP-sanitized、MBPP+），應對越來越多的模型將被測試資料納入訓練的問題。

2023 年起，當頭部模型在 MBPP 上的 Pass@1 突破 80% 甚至更高，“基礎題”的區分度下降。產業界和研究前沿迅速轉向更難的基準，如 DS-1000（資料科學庫呼叫）、APPS（競賽題），尤其是 SWE-bench（解決真實 GitHub Issue，要求定位並修改多檔案）。MBPP 的角色從“最高競技場”轉變為“入門資格賽”：不再用於決出冠軍，而是用於快速篩掉不合格的模型。

橫向技術路線對比
以下是 MBPP 與其他重要程式碼生成基準的定位與分工對比：

基準	核心側重點	語言覆蓋	評估特點	當前角色
MBPP	基礎Python程式設計，獨立函式	Python為主，通過MultiPL-E擴充套件至數十種語言	自動化驗證，題目直覺化，測試用例較多	基礎能力篩選器，模型初步驗證的必選項
HumanEval	演算法邏輯，Python函式補全	Python	題目略具挑戰性，含型別簽名，每題測試用例較少	與MBPP形成互補，同為入門級基準
DS-1000	資料科學庫實際使用（Pandas, NumPy, Matplotlib等）	Python	側重庫的正確選擇和呼叫，需要真實資料互動	領域專用基準，檢驗資料科學程式碼能力
APPS	程式設計競賽題目，含難度梯度	Python為主	含完整的輸入輸出格式處理，難度遠高於MBPP	複雜演算法與邊界條件評估
SWE-bench	真實GitHub倉庫中的Issue修復	Python為主	要求定位bug並修改多檔案，需理解大型程式碼庫上下文	工程能力試金石，代表技術前沿

這種分層路線意味著：未來任何一個聲稱擅長程式設計的模型，必須先通過 MBPP 驗證基本功，再挑戰更復雜的工程基準。行業評價體系已由此形成清晰的階梯式結構。

上游

MBPP 所處產業鏈的上游，主要包括基準的建立者和確保評估得以運轉的底層資源供給方。

基準建設方

• Google Research：MBPP 的原始建立和維護者。其研究團隊負責題目的收集、清洗、測試用例編寫和公開分發。Google 同時通過 Google DeepMind 在模型中應用該基準，形成“定義規則—參與競賽”的雙重角色。
• 學術機構與開源社群：MBPP-sanitized、MultiPL-E 等擴充套件版本分別由國內外大學和獨立研究者貢獻。社群通過 GitHub 協作持續完善基準質量，Hugging Face 等平台則提供資料集託管和排行榜服務。

算力與沙箱服務商
評估執行需要安全、可擴充套件的程式碼執行環境，主要依賴：

• 雲端運算廠商（AWS、Google Cloud、Microsoft Azure）的容器服務或無伺服器函式，提供隔離沙箱。
• 專用 AI 基礎設施平台（如 Replicate、Together AI）也開始提供模型評估 API，其中常內建 MBPP 等基準的自動化測試流程。

資料來源
MBPP 的題目主要源於早期 Python 教育習題集和程式設計社群（如 Stack Overflow 上的簡化問題），經人工篩選和改編而成。為降低資料汙染，當前一些新版本會引入大規模人工新編題目，這部分資料製作成本較高，屬於上游中的“資料生產”環節。

下游

MBPP 的下游是使用該基準結果來指導產品、投資或研究的各類主體。

AI 程式設計工具廠商
GitHub Copilot、Cursor、Replit、Windsurf、國內的通義靈碼、CodeBuddy、豆包MarsCode 等，其底層模型在釋出前均在 MBPP 上測試。成績直接影響產品更新日誌和宣傳材料中的能力描述，進而影響開發者的採用意願。部分企業版客戶也會內部復現 MBPP 測試，作為採買決策的依據。

模型開發商
OpenAI、Anthropic、Google、Meta、百川智慧、智譜等，均將 MBPP 作為模型迭代的必經評估項。開源模型社群（如 Hugging Face 上的 BigCode、Nous Research 等）通過 MBPP 放榜來建立技術聲譽，吸引算力贊助和貢獻者。

投資與研究機構
一級市場投資者在評估 AI 程式設計初創企業時，會要求創始人提供在 MBPP、HumanEval、SWE-bench 等基準上的對比資料，作為技術盡調的一部分。行業研究機構（如 Gartner、紅杉、高盛）在生成式 AI 研究報告中也頻繁引用程式碼生成基準作為能力成熟度的依據。

企業研發團隊
大型企業內部的平台工程團隊，在採購 AI 編碼輔助工具前，往往會用 MBPP 等公開基準作為初步篩選，然後再結合內部私有程式碼倉庫進行二次評估。MBPP 因此充當了“第一道過濾”，降低企業的試用成本。

受益公司

MBPP 成績的提升與產業受益之間不是直接的“分數→獲利”傳導，但其作用鏈條清晰，主要惠及以下幾類公司（從能力受益邏輯梳理，不構成任何投資建議，未提供任何買賣評等）。

1. 模型能力處於前沿的綜合科技巨頭
長期在 MBPP 和 HumanEval 等基礎基準上保持領先的公司，能夠將優勢轉化為程式設計助手產品的市場競爭力。受益路徑是：高基準分數→模型能力口碑→開發者獲取→生態繫結→營收增長。微軟（通過 GitHub Copilot 的模型編排）、Google（內部應用與雲端 API）、Amazon（CodeWhisperer/Q Developer）均屬此類。需要強調的是，某公司 2023 年財報提及“GitHub Copilot 活躍訂閱者超百萬”（口徑：微軟 FY24Q1 電話會），這屬於可查證的客觀描述。

2. 開源模型陣營的領先玩家
以 Meta 的 CodeLlama、DeepSeek 的 DeepSeek-Coder、BigCode 的 StarCoder 為代表，它們在 MBPP 上持續縮小與閉源模型的差距。受益邏輯是：通過高分數贏得社群影響力，帶動其雲端平台或算力生態的採用。例如 Meta 的開源模型雖不直接收費，但可作為吸引開發者使用其 PyTorch 生態和雲端合作伙伴服務的支點。

3. 評估與安全基礎設施公司
基準運作需依託沙箱執行和評分管線。提供模型評估服務的平台（如 Vellum、Braintrust）、專注於 AI 安全的公司（如 Anthropic 自身也提供安全評估），以及提供計分排行榜的 Hugging Face 等，都會因基準的廣泛使用而獲得流量和客戶。

4. 垂直領域工具初創
許多初創公司會在內部模型迭代中宣稱“MBPP 達到 xx%”，以作為其技術差異化的佐證，間接支撐融資和商業拓展。例如 Magic、Poolside 等專注於程式碼 AI 的初創，曾在部落格或論文中揭露 MBPP 成績。

除上述邏輯性梳理外，暫無公開揭露的直接測算證明某家公司因 MBPP 分數提升而獲得明確市場份額增長，所有受益傳導均需結合產品化能力綜合判斷。

市場規模

MBPP 本身不產生直接市場營收，它作為公共基準屬於學術基礎設施。與其相關的市場規模，指代的是 AI 程式碼生成/程式設計輔助這一應用賽道的規模。

根據公開資料，不同機構的測算口徑如下：

• GitHub 母公司微軟在 2023 年 10 月電話會中揭露，GitHub Copilot 訂閱者已超 100 萬，付費企業客戶超 3.7 萬個（來源：微軟 FY24Q1 財報電話會，2023 年 10 月 24 日）。這為市場體量提供了標杆案例。
• Gartner 在 2023 年 10 月釋出新聞稿預測，“到 2028 年，75% 的軟體工程師將使用 AI 編碼助手”（來源：Gartner 新聞稿，2023 年 10 月 11 日）。此為滲透率預測，並非營收預測。
• 公開資料未見全球 AI 編碼助手市場在 2023 年或 2024 年的統一營收規模統計。多家第三方研究機構（如 MarketsandMarkets、Grand View Research）各自報告了口徑不一的預估值，其指標定義差異較大，在此不具引以避免混淆。
• 國內方面，IDC 中國 2024 年對生成式 AI 在軟體開發領域的市場影響釋出了預測，指出“2024 年中國有超過 30% 的開發組織已在測試或採用 AI 程式設計輔助工具”（來源：IDC FutureScape, 2024 年初）。同樣未公佈精確的市場規模金額。

綜上，可以確認的是：AI 編碼輔助滲透率快速爬升、頭部產品已形成規模化訂閱營收，但缺乏權威、統一口徑的市場總額資料用以衡量 MBPP 的直接經濟影響。

玩家對比

下表基於公開的學術論文、官方技術報告和 Papers with Code 排行榜的綜合資訊，對比了各代表模型在 MBPP 上的大致表現（注：具體數字會因版本、取樣策略和評估環境而異，下表僅供定性對比，不構成精確排名）。資料引用均自主流來源，時間視窗截至 2024 年 7 月。

模型 / 提供商	釋出方	引數量	MBPP Pass@1 大致區間 (sanitized版)	報告來源	備註
GPT-4 / GPT-4o	OpenAI	未公開	~87-92%	OpenAI 2023 技術報告，排行榜	閉源，頭部水平
Claude 3.5 Sonnet	Anthropic	未公開	~90% 左右	第三方評測，排行榜	閉源，程式碼能力極強
Gemini 1.5 Pro	Google DeepMind	未公開	~87% 左右	Google 技術報告	原 MBPP 釋出方
CodeLlama-70B-Instruct	Meta	70B	~82%	Meta 2024 論文	開源，當時最高水平之一
DeepSeek-Coder-V2	DeepSeek	236B (MoE)	~86-91%	DeepSeek 2024 部落格	開源，聲稱追平 GPT-4-Turbo
StarCoder2-15B	BigCode / ServiceNow	15B	~73%	BigCode 技術報告	輕量級開源
Codestral (22B)	Mistral	22B	~82%	Mistral 部落格 2024.5	開源，針對程式碼最佳化

表中的分數區間多為論文或排行榜所公佈的最佳值，實際使用中可能因提示詞、temperature 及具體題集版本而波動。玩家對比不能僅看 Pass@1 一個維度，還需要結合產品整合深度、支援的語言數、私有程式碼庫適配能力和安全合規能力綜合判斷。

風險

1. 基準飽和風險
隨著越來越多模型在 MBPP 上超過 90% 甚至逼近滿分，該基準的區分度急劇下降。此時，高分不再代表巨大技術優勢，而只是“基礎門檻”。投資者若僅盯著 MBPP 分數，會誤判模型真實能力的差距。

2. 資料汙染與評分失真
由於 MBPP 題目和測試用例已在網際網路廣泛傳播，大多數大型模型的預訓練語料中可能已經包含其內容。這導致部分高分可能來自“背誦”，而非真正的程式設計能力。現有研究通過引入 MBPP-sanitized、測試用例變異等方法緩解，但無法根除。資料汙染程度若未被揭露，分數對比便可能失真。

3. 評測生態的“應試化”
當模型廠商以分數為最佳化目標時，會出現專門針對 MBPP 的調整（如強化類似題目的微調），造成在基準上高分但在真實開發任務中表現一般。這種“應試效應”降低了基準反映實際能力的可信度。

4. 能力≠產品價值風險
MBPP 測量的是生成獨立函式的能力，而開發者日常工作中真正耗時的是需求理解、系統設計、程式碼除錯和跨模組協同。基礎程式碼生成水平高，未必能轉化為顯著的開發效率提升。過度依賴分數可能導致對產品價值的誤判。

5. 安全與合規的覆蓋不足
MBPP 並不系統評估程式碼的安全性、許可證合規性以及生成程式碼的智慧財產權風險。若企業在選型時僅參考此基準，可能引入隱性的安全風險和合規隱患。

6. 基準維護滯後
基準的更新速度遠落後於模型能力的增長速度。MBPP 的更新頻率依賴社群貢獻，如果持續滯後，其反映能力變化的能力將進一步降低，需關注替代基準的進展。

誤讀糾偏

誤讀 1：“MBPP 高分 = 可以替代程式設計師”
糾偏：這是對 MBPP 最普遍的誤讀。MBPP 測試的是獨立、簡短、明確的小任務，就像考駕照的科目二，它證明車輛能完成倒庫、側方停車，但不證明能安全行駛在複雜公路上。真實程式設計包含系統設計、跨服務互動、程式碼可維護性、團隊協作等複雜認知活動，這些遠不在 MBPP 的考察範圍內。模型是“程式設計副駕駛”，可以提升編寫特定片段的效率，不是能獨立承擔工程的“無人駕駛程式設計師”。

誤讀 2：“MBPP 是唯一或最重要的程式碼能力指標”
糾偏：MBPP 僅覆蓋程式碼能力的“基礎語法與邏輯”這一維度。無法評估：對特定庫和架構的掌握（需 DS-1000）；理解並修改大型程式碼庫的能力（需 SWE-bench）；程式碼的安全性、可讀性和可維護性。負責任的能力畫像一定是“多基準交叉驗證”，沒有任何一個基準可以當單一標尺。

誤讀 3：“分數高的模型肯定更好用”
糾偏：分數高低與使用者體驗好壞沒有線性關係。一個在 MBPP 上稍低的模型，若在 IDE 補全延遲、上下文理解、拒絕不安全請求方面做得更好，實際使用價值可能更高。產品體驗是多目標最佳化的結果，基準分數只是其中一個輸入。

誤讀 4：“MBPP 只適合評估 Python，不能用於其他語言”
糾偏：MultiPL-E 專案已將 MBPP 的評估範式擴充套件至 19 種以上的程式語言，多語言版本分數同樣具有對比意義。原始 MBPP 的 Python 屬性並不限制其方法論在多語言場景中的複用。

最新事件

• 2024 年 6 月：DeepSeek 釋出 DeepSeek-Coder-V2，宣稱在 MBPP-sanitized 上 Pass@1 達到 90.2%，在 MBPP+ (399題) 上達到 76.2%，直接對標 GPT-4-Turbo。同時公開評測細節和取樣引數（來源：DeepSeek 官方部落格）。
• 2024 年 5 月：Mistral 釋出編碼模型 Codestral，在 MBPP 上報告 Pass@1 超過 80%，並開源權重（來源：Mistral 部落格）。這一成績再次縮小開源與閉源的差距。
• 2024 年 4 月：BigCode 社群釋出 StarCoder2 系列，提供多種引數量版本，在 MBPP 上穩步提升，且公佈了更嚴謹的去汙染評估流程（來源：BigCode 技術報告）。
• 2024 年 3 月：業界圍繞 MBPP 的資料汙染問題展開了新討論，有學者提出了更強的去汙染檢測方法（n-gram 重疊率+語義雜湊），促使排行榜新增“資料汙染風險”標註（來源：相關學術預印本及 Hugging Face 社群討論）。
• 2023 年底至 2024 年初：SWE-bench 成為 AI 程式設計領域最熱的評估指標，客觀上降低了 MBPP“獨霸”的熱度，使行業形成“先過 MBPP 基礎關，再測 SWE-bench 工程關”的雙層評估共識。

追蹤指標

若需持續追蹤 MBPP 及其產業影響，建議關注以下維度的變化：

1. Pass@1 分數趨勢：在 Papers with Code 的程式碼生成板塊，觀察頂級閉源與開源模型分數的收斂速度。重點關注 MBPP-sanitized 版本以避免汙染干擾。
2. 新發布模型的 MBPP 測試條件：必須關注評估時所使用的題集版本、取樣溫度和提示格式。多數誠信報告會詳細說明，若缺失這些資訊，其分數參考價值有限。
3. MultiPL-E 分數：當模型宣稱多語言能力時，查詢其在 MBPP 擴充套件的多語言版本上的表現，可驗證其是否真正具備跨語言基礎程式設計泛化能力。
4. 資料汙染宣告：有責任感的模型釋出方會揭露資料汙染檢測結果。追蹤該宣告的有無和具體數值，是判斷分數真實性的關鍵。
5. 社群對比討論：Hugging Face 論壇、Reddit r/MachineLearning 及相關綜述論文，會定期討論基準作弊和失效模式，這些資訊比單純數字更重要。
6. 權重向 SWE-bench 的遷移：當行業媒體和招聘要求更多提及 SWE-bench 而非 MBPP 時，意味著“基礎能力”泛化已成為前提，評估前沿已轉移。這是一種領先指標。
7. 開源模型與閉源模型差距：以 Pass@1 為軸，統計開源最佳成績與閉源最佳成績之差的縮小速度，這反映了技術普惠的節奏。

信源

• Austin, J. et al. (2021). Program Synthesis with Large Language Models. arXiv:2108.07732.（MBPP 提出論文）
• Chen, M. et al. (2021). Evaluating Large Language Models Trained on Code. arXiv:2107.03374.（HumanEval 提出論文）
• MultiPL-E: A Scalable and Polyglot Approach to Benchmarking Neural Code Generation. Cassano, F. et al. (2023). IEEE/ACM TASLP.
• MBPP 原始資料集及 Sanitized 版本：Hugging Face Datasets 搜尋 “mbpp”。
• Papers with Code — Code Generation Leaderboard：https://paperswithcode.com/task/code-generation
• Gartner 新聞稿 (2023.10.11)：“Gartner Says 75% of Enterprise Software Engineers Will Use AI Code Assistants by 2028”。
• 微軟 FY24Q1 財報電話會記錄 (2023.10.24)：GitHub Copilot 使用者資料揭露。
• DeepSeek-Coder-V2 官方部落格 (2024.6)：“DeepSeek-Coder-V2: Breaking the Barrier of Closed-Source Models in Code Intelligence”。
• Mistral 官方部落格 (2024.5)：“Codestral: Hello, World!”。
• BigCode Project 技術報告 (2024)：“StarCoder 2 and The Stack v2: The Next Generation”。
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues? Jimenez, C. E. et al. (2024). ICLR.
• 分析參考：各模型官方技術報告（OpenAI、Anthropic、Google、Meta）中涉及 MBPP 的章節。