本文全面介紹了提示詞相關內容，包括提示詞工程的重要性，如何寫好一個提示詞，以及使用 Coze 平台進行實操，適合零基礎小白入門。

面對洶涌而來的 AI 浪潮，很多研發同學感到焦慮。但其實，對於非算法背景的我們來説，不需要成為研發「發動機」的算法科學家，而是要成為能夠駕馭「賽車」的 AI 工程師。

今天，我們就來學習第一項、也是最核心的駕駛技術：提示詞工程（Prompt Engineering，簡稱 PE）。

提示詞工程聽上去很高大上，實際上説白了就是我們給大模型寫指示，想辦法讓它更聽話。

這就像帶實習生一樣：你説得越清楚，他幹得越靠譜。如果任務沒説清楚，實習生可能會把事情辦砸；大模型也一樣，Prompt 寫得好不好，直接決定它能不能完美完成任務。

1. 重要性：為什麼PE 是必備技能？

翻開現在各大公司的 AI 工程師招聘 JD，你會發現“熟練掌握提示詞工程”幾乎已經成了硬性標配。

很多純開發的同學可能會不屑：“寫提示詞不就是跟機器人聊天嗎？這玩意兒有什麼技術含量？”

這實際上是一個巨大的認知誤區。

（1） 從“自由閒聊”到“工程協議”

在普通用户眼裏，Prompt 是對話；但在開發者眼裏，Prompt 其實是代碼邏輯的自然語言化。

• 用户在“對話”： 輸出是發散、隨性的，好壞全看 AI 心情。
• 工程在“封裝”： 我們需要輸出是收斂、確定、格式化的。

如果 Prompt 寫得不好，大模型哪怕只是多返回了一個句號，或者 JSON 格式稍微錯位，業務系統在解析數據時可能就會直接報錯，導致整個業務鏈路崩潰。

因此，PE 的核心價值在於：建立一套人機交互的工程化協議，讓原本不可控的“黑盒”，變成一個能穩定輸出結果的“函數”。

（2）ROI（投資回報率）極高的 AI 技能

對於普通開發者而言，PE 是最容易掌握、見效最快的 AI 核心能力。

• 零成本： 你不需要深究底層的複雜數學原理，不需要排隊購買昂貴的顯卡去微調模型，甚至不需要改動一行的業務邏輯代碼。

• 高收益： 僅僅是把提示詞寫清楚，同一個任務的準確率就能從 60%（勉強及格） 飆升到 90% 以上（工業級水平）。這中間 30% 的差距，往往就是你的 AI 業務能不能落地、老闆和用户滿不滿意的關鍵決勝點！

一句話總結：提示詞工程，就是讓大模型更聽話。這是我們普通人最容易掌握、見效最快的 AI 能力。

2. 理論：如何寫好一個 Prompt？

我們知道 LLM 本質上是一個 “概率預測機”，它讀取文本，計算概率，預測下一個詞，循環往復。在這個過程中，我們給 LLM 的所有輸入統稱為 Prompt（提示詞）。

但這裏有個工程難題：如果輸入是發散的，輸出必然也是發散的。

舉個例子，我們想讓 LLM 判斷用户反饋是正面還是負面：

• ❌ 寫法 A：這條評論是正面的還是負面的？用户説界面太醜了，卸載了。

  • LLM 可能回答： “是負面的”、“負面情緒” 或者 “由於用户提到了卸載，這顯然是負面的...”。
  • 後果：輸出不穩定，回答可能五花八門。這在聊天時沒問題，但如果需要解析結果（比如存入數據庫、觸發告警），這種不統一的格式簡直是開發者的噩夢。

• ✅ 寫法B：你是一個情感分析專家。請判斷以下用户反饋的情感傾向，只返回"正面"或"負面"或"中性"，不要輸出任何解釋。用户反饋："界面太醜了，卸載了！"

  • LLM 回答： 負面。
  • 後果： 輸出更加穩定。

這就是提示詞工程（Prompt Engineering） 的核心：通過精心設計 Prompt，讓 LLM 的輸出更穩定、更準確、更符合業務需求。

我們繼續用"判斷用户反饋情感"這個例子，按照以下幾個步驟進行調優：

(1) 先把話清楚：明確角色和任務

第一步是“定義人設”，告訴 LLM：你是誰，要做什麼。在 API 開發中，這通常通過 System Prompt（系統提示詞） 來實現。

• 角色定義："你是一個情感分析專家"——這樣 LLM 會自動調整"專業程度"，知道要從用户反饋中提取情感信號。
• 任務指令："請判斷用户反饋的情感傾向"——不要讓 LLM 去猜你想幹什麼，直接説清楚。

# 角色
你是一個情感分析專家，擅長從用户反饋中識別情緒。
# 任務
請判斷用户反饋的情感傾向，只返回"正面"或"負面"或"中性"：

（2）給出模板：讓 LLM 照着做

直接下指令，LLM 有時仍會“放飛自我”。比如你要求“只返回正面或負面”，它可能會輸出“這條反饋是負面的”或者“Negative”。這些都是"負面"的意思，但格式不一致。這時候，給他幾個示例最有效，這叫 少樣本學習（Few-Shot Learning）。

# 角色
你是一個情感分析專家，擅長從用户反饋中識別情緒。
# 任務
請判斷用户反饋的情感傾向，只返回"正面"或"負面"或"中性"：
# 示例
## 示例1輸入：
這個APP太棒了！
## 示例1輸出：
正面
## 示例2輸入：
用了一天就崩了，垃圾軟件。
## 示例2輸出：
負面

就像給實習生一個"參考答案模板"，他看了幾個例子，自然就明白該怎麼幹了。而且這不需要重新訓練模型，完全靠 LLM 強大的"上下文學習能力"，給它幾個例子，它就能學會新任務的規律。

（3）讓它慢下來：逐步推理

在處理複雜情感時（比如陰陽怪氣、轉折句），LLM 容易直接“跳步”給錯答案。

比如用户評論：“界面漂亮但反應慢，每次加載都要等一分鐘，果斷卸載了”。LLM 可能看到“漂亮”就直覺式地判斷為“正面”，忽略了核心的負面訴求。

如果加一句話： "請逐步思考（Let's think step by step）" ，準確率會神奇地提升。這就是 CoT（Chain of Thought，思維鏈）。

LLM 的內部邏輯流會變為：

1. 關鍵詞提取：“界面漂亮”（正）、“反應慢”（負）、“想卸載”（極負）。
2. 意圖分析：雖然有視覺上的誇讚，但最終行為是卸載，表達了強烈的挫敗感。
3. 最終結論：負面。

核心邏輯： 強迫 LLM 先把推理過程寫出來，這個過程會成為後續生成的“上下文”，相當於模型在 “自我檢查”，確保結論是推導出來的，而不是“猜”出來的。

# 角色
你是一個情感分析專家，擅長從用户反饋中識別情緒。
# 任務
請判斷用户反饋的情感傾向。請逐步思考後再輸出結果。只返回"正面"或"負面"或"中性"：
# 示例
## 示例1輸入：
這個APP太棒了！
## 示例1輸出：
正面
## 示例2輸入：
界面漂亮但反應慢，每次加載都要等一分鐘，果斷卸載了。
## 示例2輸出：
負面

除了簡單地加上"請逐步思考"外，更有效的方式是我們在 Prompt 中定義好大模型的每一步推理過程，給出固定模板：

# 角色
你是一個情感分析專家，擅長從用户反饋中識別情緒。
# 任務
請判斷用户反饋的情感傾向。請按照以下步驟逐步思考後再輸出結果，只返回"正面"或"負面"或"中性"：
# 分析步驟
1. **關鍵詞提取**：從句子中找出所有具有情感傾向的詞，標註每個詞彙的情感極性（正面/負面/中性）
2. **上下文分析**：
   - 分析詞彙間的邏輯關係（轉折、遞進、並列、正話反説等），判斷核心情感訴求（如轉折句中，後半句通常為核心；正話反説需結合語境判斷真實情緒）；
   - 識別中性場景：若反饋中無明顯正面/負面詞彙，僅為客觀描述，或正面與負面詞彙權重相當、相互抵消，均判定為中性場景；
   - 區分網絡用語的情感傾向（如“666”表示認可<正面>，“6”表示諷刺<負面>，“還行”表示中性）；
3. **情感權重判斷**：對提取的情感詞彙進行權重排序，核心訴求對應的詞彙權重高於次要描述；中性詞彙不參與權重競爭，僅在無明顯正負傾向或正負權重相當時生效；
4. **最終結論**：
    - 正面信號權重＞負面信號權重，返回“正面”；
    - 負面信號權重＞正面信號權重，返回“負面”；
    - 正面與負面信號權重相當，或無明顯正負信號、僅為客觀描述，返回“中性”。
# 示例
## 示例1輸入：這個APP太棒了！
## 示例1輸出：正面

## 示例2輸入：界面漂亮但反應慢，每次加載都要等一分鐘，果斷卸載了。
## 示例2輸出：負面

CoT 雖然能夠帶來準確率的提升，但也會增加推理成本和響應延遲。因此我們需要根據任務複雜度靈活使用：

• 簡單任務（如情感分析、分類） ：無需使用 CoT 優化。

  • 優點：響應快、Token 成本低
  • 適用場景：輸入清晰的簡單分類、問答

• 複雜任務（如代碼生成、多步驟推理） ：必須開啓 CoT。

  • 優點：顯著提升準確率
  • 適用場景：數學題、代碼生成、需要多步驟思考的複雜任務

（4）格式約束：讓程序能讀懂

前面解決的是“答得對”，但在代碼場景下，還有一個關鍵問題：讓 LLM “答得能被程序解析”。

業務系統中，我們通常希望 LLM 返回 JSON 這種結構化數據。但 LLM 是個“話癆”，你讓它返回 JSON，它可能隨口回一句：“好的，這是你要的結果：{...}”。這多出來的幾個字，就會導致 json.loads() 直接報錯。

為了解決這個問題，工程上通常採用“事前約束 + 事後糾錯”的組合拳：

1. 結構化 Prompt（事前約束）

• 直接給模型一個標準的 JSON 模板，並約束它不要輸出多餘的解釋。

# 角色
你是一個情感分析專家，擅長從用户反饋中識別情緒。
# 任務
請判斷用户反饋的情感傾向。請按照以下步驟逐步思考後再輸出結果，只返回"正面"或"負面"或"中性"：
# 分析步驟
1. **關鍵詞提取**：從句子中找出所有具有情感傾向的詞，標註每個詞彙的情感極性（正面/負面/中性）
2. **上下文分析**：
   - 分析詞彙間的邏輯關係（轉折、遞進、並列、正話反説等），判斷核心情感訴求（如轉折句中，後半句通常為核心；正話反説需結合語境判斷真實情緒）；
   - 識別中性場景：若反饋中無明顯正面/負面詞彙，僅為客觀描述，或正面與負面詞彙權重相當、相互抵消，均判定為中性場景；
   - 區分網絡用語的情感傾向（如“666”表示認可<正面>，“6”表示諷刺<負面>，“還行”表示中性）；
3. **情感權重判斷**：對提取的情感詞彙進行權重排序，核心訴求對應的詞彙權重高於次要描述；中性詞彙不參與權重競爭，僅在無明顯正負傾向或正負權重相當時生效；
4. **最終結論**：
    - 正面信號權重＞負面信號權重，返回“正面”；
    - 負面信號權重＞正面信號權重，返回“負面”；
    - 正面與負面信號權重相當，或無明顯正負信號、僅為客觀描述，返回“中性”。
# 輸入格式
{
  "feedback": "<用户反饋內容>"
}
# 輸出格式
{
  "sentiment": "正面/負面/中性",
  "reason": "<原因分析>"
}
# 約束
1. 必須僅返回 JSON 數據，禁止任何解釋性文字
2. sentiment 字段只能是 "正面" 或 "負面" 或 "中性"
3. reason字段需結合關鍵詞提取、上下文分析，説明判斷依據，中性反饋需明確“無明顯正負傾向”“客觀描述”等核心依據，不遺漏核心情感點。
# 示例
## 示例1輸入
{"feedback": "這個APP太棒了！"}
## 示例1輸出
{"sentiment": "正面", "reason": "用户使用正面詞彙 “太棒了” 直接誇讚 APP，核心情感為滿意，無負面訴求，情感傾向正面"}
## 示例2輸入
{"feedback": "界面漂亮但反應慢，每次加載都要等一分鐘，果斷卸載了"}
## 示例2輸出
{"sentiment": "負面", "reason": "提取到正面詞彙 “漂亮”，負面詞彙 “反應慢”“加載要等一分鐘”“果斷卸載”；上下文通過 “但” 轉折，後半句為核心訴求，負面描述及卸載行為體現用户的不滿，負面信號權重遠高於正面信號權重，情感傾向負面"}

2. 工程化魯棒性（事後糾錯） 在實際業務中，單靠 Prompt 依然會有概率遇到非法格式。研發通常會引入以下兜底方案：

• 原生 JSON 模式：調用 API 時開啓模型自帶的 response_format: { "type": "json_object" } 模式，強制模型輸出。（如果平台支持的話）。
• 自動修復（Repair）：使用類似 json_repair 的庫。這些庫利用算法修復模型輸出中缺失的引號、括號或多餘的解釋語。
• 重試機制（Retry）：如果解析失敗，自動進行 2-3 次重試，或者在重試時把錯誤信息返還給模型（“你剛才返回的格式錯了，請修正”）。

3. 實戰：Coze 平台構建智能體

理論講完了，現在我們上實戰。

在現代 AI 開發中，將 Prompt 與代碼解耦是最佳實踐。硬編碼 Prompt 不僅維護困難，而且難以測試和迭代。

這裏以 Coze（釦子） 平台作為演示。作為一個極佳的 Bot 構建平台，它的優勢在於：

注：Coze 平台也支持知識庫、工作流等能力，後續講到 RAG、Workflow 等內容時會再次用到。

下面通過 Coze 平台快速上手，完成情感分析 Bot：

1. 登錄 Coze 平台，網站：https://www.coze.cn/home

2. 點擊創建->創建智能體，命名：情感分析助手

3. 配置人設與回覆邏輯（也就是我們理論部分的 System Prompt），模型使用默認即可。

4. 在右側對話區輸入測試數據進行實時調試，比如輸入{"feedback": "這 APP 太棒了，棒的我想卸載！！！"}，模型便會分析出對應情感。

https://mmbiz.qpic.cn/sz_mmbiz_png/rWLTJ1H6NeLuwM2hALdn8LfsQlFlY8wcTv6CDZuWTV3l3X1UNOiabrzs7ohmvhxysheoswyIfhYqJ4Keanobp2a6nEbxpH40SkaCP9k83ic14/640?wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=6

5. 如果希望通過 API 調用，可以參考官方文檔：https://www.coze.cn/open/docs/developer_guides/coze_api_overview。

4. 總結

Prompt Engineering 絕非簡單的“搭話”，它是目前連接自然語言與計算機代碼最重要的一座橋樑。通過 定義角色、明確約束、提供示例 (Few-Shot) 以及 激發思維鏈 (CoT) 等方式，我們能把一個不穩定的概率模型，變成業務中可靠的“智能外腦”。

而藉助 Coze 這樣的平台，我們能完美實現 Prompt 與代碼的解耦，讓 AI 工程化變得前所未有的順暢。

上一篇文章我們全面概述了大模型的相關知識，今天則正式解鎖了至關重要的提示詞工程 (PE)。

但這僅僅是開始。在接下來的實戰系列中，我將繼續帶大家深度解鎖更多 AI 核心知識點：檢索增強生成（RAG）、工作流（Workflow）、智能體（Agent）、LangChain、Coze、n8n 等等。

如果覺得文章還不錯，別忘了關注、點贊、收藏三連支持！

關注同名公眾號，讓我們一起持續進化，成為真正能夠駕馭“賽車”的 AI 工程師。