一條 prompt 裏到底有哪些組成部分？
整理版優先睇
寫 prompt 唔係亂打字，拆開四個要素先係關鍵：角色、任務、上下文、約束，缺一不可。
呢篇文章嚟自一個專欄，作者係想教人點樣寫好 prompt，尤其係唔熟 AI 嘅開發者同內容創作者。佢用咗一個後端工程師叫李明嘅真實例子：頭兩次亂寫 prompt，AI 畀嘅嘢完全用唔到，到第三次跟足結構先出到可執行嘅代碼。作者發現，好多人以為 prompt 就係「講清楚想做咩」，但其實仲有更深嘅框架可以拆。佢提出一個四要素模型：角色、任務、上下文、約束，並且用圖表解釋每個要素點樣影響 AI 嘅輸出。整體結論係：結構化 prompt 先係提高 AI 回覆質量嘅關鍵，而唔係靠感覺亂撞。
文章詳細拆解每個要素嘅作用：角色決定 AI 嘅知識範圍同語氣；任務係核心指令；上下文提供背景減少猜測；約束控制格式同範圍。佢話簡單任務只需要任務，中等就要加上下文，複雜先要四要素齊全。作者仲特別提醒一個常見誤區：好多人將上下文同任務撈埋一齊寫，搞到 AI 要自己估任務，容易錯。佢建議分開寫，用結構化方式（背景、任務、要求）去組織 prompt。
最後作者提到 System Prompt 同 User Prompt 嘅分別，仲有個實戰改寫例子，將一句「幫我寫個推廣文案」變成完整四要素版本。成篇文係實用導向，適合想提升 prompt 效率嘅讀者。
- 結論：一條好 prompt 離唔開四個要素——角色、任務、上下文、約束，缺一就會影響輸出質量。
- 方法：複雜任務要四要素齊全，簡單任務只需要任務；上下文同任務要分開寫，避免 AI 誤解。
- 差異：結構化 prompt 比流水賬式 prompt 效果好得多，因為 AI 唔使估你想做咩。
- 啟發：角色設定可以聚焦知識範圍同語氣，係提升 prompt 效率嘅低成本方法。
- 可行動點：下次寫 prompt 前，先問自己「角色係咩？任務係咩？背景資料？有咩限制？」然後結構化輸出。
四要素 prompt 模板
角色：[角色描述]；背景：[上下文資訊]；任務：[具體要做嘅事]；要求：[格式、長度、限制等約束]
一個真實例子：由亂寫到精準
作者用後端工程師李明嘅故事開頭，佢要寫數據庫遷移腳本，頭兩次 prompt 好求其，AI 畀嘅代碼完全用唔到。直到第三次先將角色、任務、上下文、約束全部寫清楚，先得到幾乎可直接用嘅輸出。
Prompt 嘅四要素拆解
- 1 角色：話畀 AI 佢係邊個，決定知識範圍同語氣。例子：「你是一個資深 Python 後端工程師」
- 2 任務：明確話畀 AI 要做咩，動詞要具體，對象要清晰。例子：「寫一個數據庫遷移腳本」
- 3 上下文：提供背景資訊，減少 AI 嘅猜測。例子：「項目用 FastAPI + SQLModel + MySQL 8.0」
- 4 約束：話畀 AI 邊啲做得、邊啲唔做得，控制格式範圍。例子：「使用 JSON 輸出，長度 500 字以內」
呢四個要素可以按任務複雜度自由組合，簡單嘅只需任務，複雜嘅就要齊全。作者特別提醒一個常見誤區：唔好將上下文同任務撈埋一齊寫，否則 AI 容易錯誤理解任務重點。
進階：System Prompt 同 User Prompt 點樣分工？
System Prompt 係系統級設定，好似員工手冊，規矩喺對話開始前定好；User Prompt 係用戶實際輸入，似客戶嘅具體需求。兩層配合使用可以提升 prompt 穩定性。
messages = [
{"role": "system", "content": "你是一個專業的法律顧問，專注於勞動法領域。"},
{"role": "user", "content": "我被公司無故辭退了，能要求多少賠償金？"}
]System Prompt 設定規則框架，User Prompt 提供具體任務。實際應用時，記住呢個分工可以令角色設定更穩定。
實戰改寫：由一句變結構化
原始 prompt「幫我寫個推廣文案」得 6 個字，作者用四要素改寫成結構化版本：
- 角色：擅長社交媒體營銷嘅文案寫手，風格活潑有趣
- 上下文：記賬 App，目標用戶 20-30 歲年輕人，賣點自動識別小票等
- 任務：寫一條小紅書風格嘅推廣筆記
- 約束：標題有 emoji，正文 300 字以內，包含 3 個亮點，結尾引導下載但唔好太硬廣
改寫之後，輸出質量明顯提升。作者強調：結構化 prompt 令 AI 唔使估，自然令結果更精準。
一條 prompt 裏面其實有啲咩組成部分？
一個真實場景
李明係一個後端工程師，老細叫佢用 AI 幫手寫一段數據庫遷移腳本。
佢嘅第一版 prompt 係咁樣：
幫我寫一個數據庫遷移腳本。
AI 俾咗一段通用嘅 Alembic 遷移代碼，但冇指定數據庫類型、表結構、遷移方向——基本上用唔到。
佢改咗第二版：
幫我寫一個 Alembic 遷移腳本，把 users 表的 email 字段從 VARCHAR(100) 改成 VARCHAR(255)。
好咗少少，但 AI 唔知個項目嘅技術棧、數據庫引擎、需唔需要處理現有數據。
第三版：
你是一個 Python 後端工程師，熟悉 FastAPI 和 Alembic。
項目背景：
- 數據庫：MySQL 8.0
- ORM：SQLModel
- 已有 users 表，email 字段當前是 VARCHAR(100)
任務：
寫一個 Alembic 遷移腳本，把 email 字段改成 VARCHAR(255)。
要求：
- 使用 Alembic 的 op.alter_column 方法
- 遷移文件名格式：YYYYMMDD_HHMMSS_alter_user_email_length.py
- 包含 upgrade 和 downgrade
- 不需要處理已有數據（純 schema 變更）
呢一次，AI 輸出嘅代碼幾乎可以直接用。
三個版本嘅差距喺邊？信息嘅完整性。 而呢個「完整性」，係可以拆解嘅。
Prompt 嘅四要素
一條完整嘅 prompt，可以拆解成四個核心要素：
┌─────────────────────────────────────┐
│ Prompt │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 角色 │ │ 任務 │ │
│ │ (Role) │ │ (Task) │ │
│ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 上下文 │ │ 約束 │ │
│ │(Context) │ │(Constraint)│ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────┘
1. 角色（Role）——「你係邊個」
話俾 AI 知佢扮演咩角色。呢個決定咗 AI 嘅知識範圍、語氣風格同回答角度。
你是一個資深的 Python 後端工程師。
你是一個兒童科普作家。
你是一個嚴格的代碼審查者。
角色嘅作用：
聚焦知識：指定角色相當於同 AI 講「用呢個領域嘅知識嚟回答」 設定語氣：律師同文案寫手嘅講嘢方式完全唔同 明確立場：客服代表同產品經理睇同一個問題嘅角度唔一樣
2. 任務（Task）——「你要做咩」
明確話俾 AI 知你想佢完成嘅具體任務。呢個係 prompt 嘅核心。
寫一個數據庫遷移腳本。
分析這份銷售數據，找出增長最快的三個品類。
把這段英文翻譯成日語，保持技術術語不變。
好嘅任務描述：
動詞明確：寫、分析、翻譯、生成、優化、檢查…… 對象清晰：咩數據、咩代碼、咩內容 結果可預期：輸出係咩形式——代碼、表格、文章、列表
3. 上下文（Context）——「背景係咩」
提供 AI 完成任務需要嘅相關信息。冇上下文，AI 只能用默認假設。
項目使用 FastAPI + SQLModel + MySQL 8.0。
我們的目標用戶是 25-35 歲的一線城市白領。
這份報告是給 CEO 看的，他不是技術背景。
上下文嘅價值：
減少猜測：AI 唔使估你嘅技術棧、用戶畫像、受眾背景 提高相關性：AI 嘅輸出會更加貼合你嘅實際場景 避免返工：一次過俾夠信息，慳返來回補充嘅麻煩
4. 約束（Constraint）——「邊界喺邊」
話俾 AI 知咩可以做、咩唔可以做、輸出應該係咩格式。
- 長度控制在 500 字以內
- 使用 JSON 格式輸出
- 不要使用專業術語
- 必須包含錯誤處理
- 不要編造數據，不確定的標註"待確認"
約束嘅作用：
控制格式：JSON、Markdown、表格、純文本 控制範圍：淨係做咩、唔做咩 控制質量：一定要包含咩、避免咩
四要素嘅組合方式
四要素唔係每次都要全部出現，根據任務複雜度靈活組合：
簡單任務：任務就得
把這段話翻譯成英文：今天天氣真好。
唔需要角色、上下文、約束——任務本身已經夠清晰。
中等任務：任務 + 上下文
我是一個前端工程師，項目用 React + TypeScript。
幫我寫一個表單組件，包含用戶名、郵箱、密碼三個字段。
有上下文（技術棧）同任務（寫組件），角色隱含喺上下文裏面。
複雜任務：四要素齊全
你是一個資深的數據分析師，擅長用 Python 做數據可視化。
背景：我們有一份電商平台的銷售數據（CSV 格式），包含日期、品類、銷售額、訂單量四列。
數據時間範圍：2024年1月-12月。
任務：分析數據，生成一份年度銷售報告。
要求：
- 包含以下圖表：月度趨勢折線圖、品類佔比餅圖、Top10 商品柱狀圖
- 使用 matplotlib + seaborn
- 圖表標題和標籤使用中文
- 輸出一個完整的 Python 腳本，可以直接運行
- 不要使用 mock 數據，直接讀取 CSV 文件
四要素齊全，AI 有清晰嘅角色定位、充足嘅背景信息、明確嘅任務目標同嚴格嘅輸出約束。
一個常見誤區：將上下文當任務
好多人會犯一個錯誤——將大量背景信息同任務描述撈埋一齊：
❌ 我們公司是做電商的，有 50 個人，最近在做雙十一活動，老闆說要提升轉化率，
我想了一個方案是做滿減，但是運營說滿減太老套了，然後我們討論了一下決定做
盲盒，但是技術說盲盒的隨機邏輯比較複雜，需要一週時間開發，老闆說時間太緊了，
你能幫我想想別的方案嗎？
呢段說話裏面，任務俾背景敍述淹沒咗。AI 要自己由一大段文字裏面「提取」任務——佢可能會提取錯。
更好嘅寫法：將上下文同任務分開。
✅ 背景：
我們是一家電商公司，雙十一需要一個促銷活動方案。
約束：技術開發時間不超過 3 天，不做滿減（太老套），不做盲盒（開發週期長）。
任務：
請給出 3 個替代的促銷活動方案，每個方案包含：活動形式、技術實現難度、預期效果。
結構化嘅 prompt 比流水賬式嘅 prompt 效果好得多。
進階：System Prompt 同 User Prompt
喺實際嘅 AI 應用中，prompt 通常分為兩層：
System Prompt（系統提示詞）
系統級嘅設定，通常喺對話開始之前就確定好，用戶睇唔到。
你是一個專業的法律顧問，專注於勞動法領域。
回答要引用具體的法律條文，語言嚴謹準確。
如果用戶的問題超出勞動法範圍，請明確告知並建議諮詢對應領域的律師。
User Prompt（用戶提示詞）
用戶喺對話中輸入嘅內容。
我被公司無故辭退了，能要求多少賠償金？
兩層 prompt 嘅關係：
System Prompt 設定「規則框架」——AI 嘅角色、行為邊界、輸出規範 User Prompt 提供「具體任務」——用戶當下嘅需求
類比一下：
System Prompt 好似公司嘅員工手冊——規定咗你應該點樣工作 User Prompt 好似客戶嘅具體需求——你要處理嘅嘢
喺 API 調用中，佢哋通常咁樣組織：
messages = [
{"role": "system", "content": "你是一個專業的法律顧問..."},
{"role": "user", "content": "我被公司無故辭退了..."}
]
System Prompt 嘅設計會喺第 11 篇詳細展開。
實戰：用四要素框架改寫 prompt
嚟睇一個改寫嘅例子。
原始 prompt：
幫我寫個推廣文案。
用四要素框架改寫：
角色：你是一個擅長社交媒體營銷的文案寫手，風格活潑有趣。
背景：我們是一款記賬 App，目標用戶是 20-30 歲的年輕人。
主要賣點：自動識別小票、智能分類、月度消費報告。
競品：隨手記、微力記賬。
任務：寫一條小紅書風格的推廣筆記。
約束：
- 標題要有吸引力，包含 emoji
- 正文 300 字以內
- 包含 3 個產品亮點
- 結尾引導下載，但不要太硬廣
- 語氣親切，像朋友推薦
由 6 個字變咗做一段結構化嘅 prompt。輸出質量嘅差距，你自己試嚇就知。
核心要點
一條 prompt 有四個核心要素：角色、任務、上下文、約束 根據任務複雜度靈活組合：簡單任務只需要任務本身，複雜任務就四要素齊全 結構化 > 流水賬：將上下文同任務分開寫，唔好撈埋一齊 System Prompt 設定規則，User Prompt 提供任務：兩層配合使用
下一篇預告
你已經知道咗 prompt 嘅四個組成部分。其中「角色」呢個要素，睇落簡單，效果卻出奇咁好。
下一篇，我哋深入探討：俾 AI 一個角色，點解效果即刻變好？ 角色設定背後嘅原理係咩？點樣設定一個好嘅角色？
一條 prompt 裏到底有哪些組成部分？
一個真實場景
李明是一名後端工程師，老闆讓他用 AI 幫忙寫一段數據庫遷移腳本。
他的第一版 prompt 是這樣的：
幫我寫一個數據庫遷移腳本。
AI 給了一段通用的 Alembic 遷移代碼，但沒有指定數據庫類型、表結構、遷移方向——基本沒法用。
他改了第二版：
幫我寫一個 Alembic 遷移腳本，把 users 表的 email 字段從 VARCHAR(100) 改成 VARCHAR(255)。
好了一些，但 AI 不知道項目的技術棧、數據庫引擎、是否需要處理已有數據。
第三版：
你是一個 Python 後端工程師，熟悉 FastAPI 和 Alembic。
項目背景：
- 數據庫：MySQL 8.0
- ORM：SQLModel
- 已有 users 表，email 字段當前是 VARCHAR(100)
任務：
寫一個 Alembic 遷移腳本，把 email 字段改成 VARCHAR(255)。
要求：
- 使用 Alembic 的 op.alter_column 方法
- 遷移文件名格式：YYYYMMDD_HHMMSS_alter_user_email_length.py
- 包含 upgrade 和 downgrade
- 不需要處理已有數據（純 schema 變更）
這一次，AI 輸出的代碼幾乎可以直接用。
三個版本的差距在哪？信息的完整性。 而這個"完整性"，是可以拆解的。
Prompt 的四要素
一條完整的 prompt，可以拆解為四個核心要素：
┌─────────────────────────────────────┐
│ Prompt │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 角色 │ │ 任務 │ │
│ │ (Role) │ │ (Task) │ │
│ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 上下文 │ │ 約束 │ │
│ │(Context) │ │(Constraint)│ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────┘
1. 角色（Role）——"你是誰"
告訴 AI 它扮演什麼角色。這決定了 AI 的知識範圍、語氣風格和回答角度。
你是一個資深的 Python 後端工程師。
你是一個兒童科普作家。
你是一個嚴格的代碼審查者。
角色的作用：
聚焦知識：指定角色相當於告訴 AI "用這個領域的知識來回答" 設定語氣：律師和文案寫手的說話方式完全不同 明確立場：客服代表和產品經理看同一個問題的角度不一樣
2. 任務（Task）——"你要做什麼"
明確告訴 AI 你想要它完成的具體任務。這是 prompt 的核心。
寫一個數據庫遷移腳本。
分析這份銷售數據，找出增長最快的三個品類。
把這段英文翻譯成日語，保持技術術語不變。
好的任務描述：
動詞明確：寫、分析、翻譯、生成、優化、檢查…… 對象清晰：什麼數據、什麼代碼、什麼內容 結果可預期：輸出是什麼形式——代碼、表格、文章、列表
3. 上下文（Context）——"背景是什麼"
提供 AI 完成任務所需的相關信息。沒有上下文，AI 只能用默認假設。
項目使用 FastAPI + SQLModel + MySQL 8.0。
我們的目標用戶是 25-35 歲的一線城市白領。
這份報告是給 CEO 看的，他不是技術背景。
上下文的價值：
減少猜測：AI 不用假設你的技術棧、用戶畫像、受眾背景 提高相關性：AI 的輸出會更貼合你的實際場景 避免返工：一次給夠信息，省去來回補充的麻煩
4. 約束（Constraint）——"邊界在哪"
告訴 AI 什麼可以做、什麼不可以做、輸出應該是什麼格式。
- 長度控制在 500 字以內
- 使用 JSON 格式輸出
- 不要使用專業術語
- 必須包含錯誤處理
- 不要編造數據，不確定的標註"待確認"
約束的作用：
控制格式：JSON、Markdown、表格、純文本 控制範圍：只做什麼、不做什麼 控制質量：必須包含什麼、避免什麼
四要素的組合方式
四要素不是每次都要全部出現，根據任務複雜度靈活組合：
簡單任務：任務即可
把這段話翻譯成英文：今天天氣真好。
不需要角色、上下文、約束——任務本身就足夠清晰。
中等任務：任務 + 上下文
我是一個前端工程師，項目用 React + TypeScript。
幫我寫一個表單組件，包含用戶名、郵箱、密碼三個字段。
有上下文（技術棧）和任務（寫組件），角色隱含在上下文裏。
複雜任務：四要素齊全
你是一個資深的數據分析師，擅長用 Python 做數據可視化。
背景：我們有一份電商平台的銷售數據（CSV 格式），包含日期、品類、銷售額、訂單量四列。
數據時間範圍：2024年1月-12月。
任務：分析數據，生成一份年度銷售報告。
要求：
- 包含以下圖表：月度趨勢折線圖、品類佔比餅圖、Top10 商品柱狀圖
- 使用 matplotlib + seaborn
- 圖表標題和標籤使用中文
- 輸出一個完整的 Python 腳本，可以直接運行
- 不要使用 mock 數據，直接讀取 CSV 文件
四要素齊全，AI 有清晰的角色定位、充足的背景信息、明確的任務目標和嚴格的輸出約束。
一個常見誤區：把上下文當任務
很多人會犯一個錯誤——把大量背景信息和任務描述混在一起：
❌ 我們公司是做電商的，有 50 個人，最近在做雙十一活動，老闆說要提升轉化率，
我想了一個方案是做滿減，但是運營說滿減太老套了，然後我們討論了一下決定做
盲盒，但是技術說盲盒的隨機邏輯比較複雜，需要一週時間開發，老闆說時間太緊了，
你能幫我想想別的方案嗎？
這段話裏，任務被淹沒在背景敍述中。AI 需要自己從一大段文字裏"提取"任務——它可能會提取錯。
更好的寫法：把上下文和任務分開。
✅ 背景：
我們是一家電商公司，雙十一需要一個促銷活動方案。
約束：技術開發時間不超過 3 天，不做滿減（太老套），不做盲盒（開發週期長）。
任務：
請給出 3 個替代的促銷活動方案，每個方案包含：活動形式、技術實現難度、預期效果。
結構化的 prompt 比流水賬式的 prompt 效果好得多。
進階：System Prompt 和 User Prompt
在實際的 AI 應用中，prompt 通常分為兩層：
System Prompt（系統提示詞）
系統級的設定，通常在對話開始前就確定好，用戶看不到。
你是一個專業的法律顧問，專注於勞動法領域。
回答要引用具體的法律條文，語言嚴謹準確。
如果用戶的問題超出勞動法範圍，請明確告知並建議諮詢對應領域的律師。
User Prompt（用戶提示詞）
用戶在對話中輸入的內容。
我被公司無故辭退了，能要求多少賠償金？
兩層 prompt 的關係：
System Prompt 設定"規則框架"——AI 的角色、行為邊界、輸出規範 User Prompt 提供"具體任務"——用戶當下的需求
類比一下：
System Prompt 像是公司的員工手冊——規定了你該怎麼工作 User Prompt 像是客戶的具體需求——你要處理的事情
在 API 調用中，它們通常這樣組織：
messages = [
{"role": "system", "content": "你是一個專業的法律顧問..."},
{"role": "user", "content": "我被公司無故辭退了..."}
]
System Prompt 的設計會在第 11 篇詳細展開。
實戰：用四要素框架改寫 prompt
來看一個改寫的例子。
原始 prompt：
幫我寫個推廣文案。
用四要素框架改寫：
角色：你是一個擅長社交媒體營銷的文案寫手，風格活潑有趣。
背景：我們是一款記賬 App，目標用戶是 20-30 歲的年輕人。
主要賣點：自動識別小票、智能分類、月度消費報告。
競品：隨手記、微力記賬。
任務：寫一條小紅書風格的推廣筆記。
約束：
- 標題要有吸引力，包含 emoji
- 正文 300 字以內
- 包含 3 個產品亮點
- 結尾引導下載，但不要太硬廣
- 語氣親切，像朋友推薦
從 6 個字變成了一段結構化的 prompt。輸出質量的差距，你自己試試就知道。
核心要點
一條 prompt 有四個核心要素：角色、任務、上下文、約束 根據任務複雜度靈活組合：簡單任務只需任務本身，複雜任務四要素齊全 結構化 > 流水賬：把上下文和任務分開寫，不要混在一起 System Prompt 設定規則，User Prompt 提供任務：兩層配合使用
下一篇預告
你已經知道了 prompt 的四個組成部分。其中"角色"這個要素，看起來簡單，效果卻出奇地好。
下一篇，我們深入探討：給 AI 一個角色，為什麼效果立馬變好？ 角色設定背後的原理是什麼？怎麼設定一個好的角色？