【AI】AI 評測入門（二）：Prompt 迭代實戰從“能跑通”到“能落地”

“Prompt 不是寫出來的，是測出來的。”

——這是我迭代 5 個版本后，最深的體悟。

上一篇《AI 評測入門（一）：先搞懂你的數據集)》，我們講了標簽體系、自測集、評測集、Langfuse 數據結構化——那是 AI 評測的地基。

而這一篇，我們進入 Prompt 工程。

我會用 “產品評價打標簽” 的功能，從零迭代出一個可工程化落地的 Prompt。

我會盡可能還原我踩過的坑、走過的彎路、改過的字段、崩潰過的模型輸出 —— 希望你少走彎路。

我一共迭代了 5 個版本。每個版本都不是“推翻重來”，而是基于測試反饋后進行修改。

不要追求“完美 Prompt”，而要追求“可評測、可調試、可工程化”的 Prompt。

v0.0.1：從“元提示詞”生成初版

Prompt 生成方式

我直接用 Gemini 2.5pro，通過元提示詞以及下面的提示詞，加上第一篇文章定義好的標簽體系，幫我輸出了第一份 prompt：

元提示詞+標簽體系文檔我有一個標簽體系，分別有一級，二級，三級標簽。
三級標簽，還會有對應描述來詳細描述這個標簽是什么意思。
會有一個評價的輸入，我需要你生成一個提示詞可以很好地運用這個標簽體系來打標簽。
除此之外，還要對這個評價進行情緒判斷，正向，負向和中性。
如果你還需要什么信息，或者你覺得還要補充什么內容請跟我說。

得到的結果

# 指令：你是一個頂級的、一絲不茍的“用戶體驗洞察分析師”。
你的唯一使命是：嚴格依據下方“知識庫”中定義的標簽體系，對給定的“用戶評價”進行精準的情緒分析和多層級標簽分類。
你必須直接匹配最詳細的【三級標簽描述】來做出判斷，然后返回其完整的層級結構。絕對禁止任何形式的即興發揮或模糊猜測。---##  PART 1: 知識庫 (Knowledge Base)
這是你進行所有判斷的唯一依據。
格式輸出如下：# [一級標簽A]## [二級標簽A1]- **[三級標簽A1a]**: [三級標簽A1a的詳細描述]- **[三級標簽A1b]**: [三級標簽A1b的詳細描述]## [二級標簽A2]- **[三級標簽A2a]**: [三級標簽A2a的詳細描述]# [一級標簽B]## [二級標簽B1]- **[三級標簽B1a]**: [三級標簽B1a的詳細描述]# 產品體驗——清潔效果## 掃地效果
- **灰塵&大顆粒**: 評論反饋提到地板上有很多灰塵或大顆粒物的情況，大顆粒物舉例為：薯片、花生、豆子。
- **毛發——寵物毛發**: 評論中提到寵物毛發相關的情況時，例如“地上有很多寵物毛發，掃地機吸不干凈”。
- **毛發——長發**: 標簽描述的是與人類的頭發相關的情況，例如“刷子上纏了長發，清理很麻煩”。
- **毛發——濕潤毛發**: 評論中提到濕潤毛發相關的情況時，例如“掃地機不能有效處理濕的頭發”。(篇幅有限)---## PART 2: 核心任務與規則 (Core Tasks & Rules)1.  **情緒判斷**: 分析評價的整體情緒，輸出 `正向`, `負向`, 或 `中性`。
2.  **標簽分類**:* **規則 1 (核心)**: 你的判斷必須直接基于【三級標簽】的詳細描述，而不是簡單的關鍵詞匹配。* **規則 2**: 確定三級標簽后，必須同時返回它所屬的【一級標簽】和【二級標簽】。* **規則 3**: 如果評價提到多個可分類的問題，請在`labels`數組中輸出多個對象。* **規則 4**: 如果評價內容與知識庫中的所有描述都不符，則`三級標簽`字段輸出`無法歸類`，并在`reasoning`中說明原因。---## PART 3: 思考與輸出格式 (Chain of Thought & Output Format)你的輸出必須是一個嚴格的JSON對象。在輸出前，你必須在內心完成以下思考，并將關鍵邏輯寫入`reasoning`字段。1.  **情緒分析**: 這條評價的核心觀點是什么？表達的是滿意還是抱怨？
2.  **全局掃描與匹配**: 用戶抱怨的具體問題是什么？（例如，“掃不干凈寵物毛發”）。這個抱怨與知識庫中哪個【三級標簽】的【描述】最吻合？
3.  **最終驗證**: 檢查匹配是否精確。然后，根據匹配到的三級標簽，回溯找到其一級和二級父標簽。
4.  **構建JSON**: 將所有分析結果填入下方指定的JSON結構中。### **【輸出格式】**
```json
{"sentiment": {"value": "正向 | 負向 | 中性","reasoning": "【簡述判斷情緒的理由，引用原文關鍵詞】"},"labels": [{"L1": "【根據匹配到的三級標簽，自動帶出】","L2": "【根據匹配到的三級標簽，自動帶出】","L3": "【此處填寫最匹配的三級標簽 或 ‘無法歸類’】","reasoning": "【詳細說明為何此三級標簽的描述與用戶評價內容匹配，必須引用原文作為證據】"}]
}
```## PART 4: 黃金標準示例 (Golden Examples)這是你需要學習的、正確的打標簽案例。你要像這樣思考和輸出。示例1：邊角清潔
{
"userInput": "廚房櫥柜邊角清掃不到。",
"output": {
"sentiment": { "value": "負向", "reasoning": "用戶明確抱怨了產品在特定區域“清掃不到”，是典型的問題反饋。" },
"labels": [ { "一級標簽": "產品體驗——清潔效果", "二級標簽": "清潔覆蓋率", "三級標簽": "邊角覆蓋", "reasoning": "用戶提到“櫥柜邊角”無法清掃，直接對應三級標簽“邊角覆蓋”所描述的場景。" } ]
}
}示例2：動態障礙物
{
"userInput": "追覓不會識別動態障礙物（有時不會補掃），石頭對動態障礙物會補掃。",
"output": {
"sentiment": { "value": "負向", "reasoning": "用戶將產品與其他品牌對比，明確指出了“不會識別動態障礙物”的缺陷。" },
"labels": [ { "一級標簽": "產品體驗——智能性", "二級標簽": "避障", "三級標簽": "動態障礙物", "reasoning": "評價核心是“不會識別動態障礙物”，這與三級標簽“動態障礙物”的定義完全匹配。" } ]
}
}示例3：定位與動作混亂
{
"userInput": "機器人行駛非常混亂，花了15分鐘才找到充電站。",
"output": {
"sentiment": { "value": "負向", "reasoning": "用戶抱怨了“行駛非常混亂”和“花了15分鐘才找到充電站”，清晰地表達了對產品性能的不滿。" },
"labels": [ { "一級標簽": "產品體驗——智能性", "二級標簽": "路線規劃", "三級標簽": "轉圈", "reasoning": "“行駛非常混亂”是“轉圈”標簽所描述的典型場景，即無目的的、不符合邏輯的移動。" } ]
}
}

結構清晰、包含：

角色定義（“頂級用戶體驗洞察分析師”）
知識庫結構（層級標簽+描述）：在第一篇里面描述過，并非都要放到 RAG，可以直接拼接到 prompt 里面
任務規則（情緒判斷 + 標簽匹配）
輸出格式（JSON）
Few-shot 示例

關鍵洞察

不要從 0 開始手寫 Prompt。用大模型生成初版，效率極高。
Prompt 的“完美結構”不重要，可調試性才重要。

導入 Langfuse & Playground 調試

我把 Prompt 上傳到 Langfuse，利用 Playground 快速測試：

支持多模型切換（GPT-3.5 / GPT-4 / Claude 等）
支持 Prompt 版本對比
支持輸入歷史記錄回溯

有了提示詞，創建到 langfuse 的 prompt 里面去，langfuse 可以對 prompt 進行版本管理。

在這里插入圖片描述

可以看到右上角有一個藍色的框，Playground，允許你對 prompt 修改，選擇不同的模型，甚至比較不同的 prompt 的效果，因此在沒有正式跑評測集的時候，我就在這個地方調試我的提示詞。

在這里插入圖片描述

版本復盤

1. 未處理“無法歸類”場景 → 信息丟失風險

問題現象

原始 Prompt 僅要求模型輸出“匹配成功的標簽”，未定義如何處理“部分匹配”或“完全不匹配”的語義片段。導致部分用戶反饋內容被靜默忽略，影響分析完整性。

修正方案

計劃引入 unmatched_feedback 字段，用于捕獲無法歸類的原文片段，并嘗試通過 partial_match_level（如匹配到 L1 但無 L2/L3）提供結構化反饋，甚至建議新增標簽。

?? 事后反思

該方案“步子邁得過大”。讓模型判斷“匹配層級”并“建議新標簽”，超出了其穩定可控的能力邊界，極易引發幻覺或結構錯亂。后續版本果斷放棄模糊匹配，回歸“全匹配 or 無法歸類”的二元策略。

2. 多情緒、多主題未解耦 → 輸出粒度粗糙

問題現象

用戶評價常包含多個獨立觀點（如“掃地效果差，但客服態度好”），每個觀點情緒可能不同。初版僅輸出“整體情緒”，丟失細粒度洞察。

修正方案

需重構輸出結構 ——先拆分評價中的獨立觀點，再為每個觀點打標 + 判斷情緒，最后聚合為整體情緒。

情緒不是“全局屬性”，而是“局部屬性”，需要精細化情緒分析。

3. Few-shot 樣本偏差 → 模型輸出傾向負向

問題現象

示例集中缺少正向評價樣本，導致模型在模糊場景下傾向于輸出負向標簽，引入系統性偏差。

修正方案

補充正向、中性、混合情緒的 Few-shot 示例，確保模型在情緒判斷上保持中立與平衡。

Few-shot 不是“裝飾”，而是“引導”。樣本分布應盡可能貼近真實數據分布，避免模型學習到錯誤的“潛規則”。

4. 標簽體系未校驗 → 垃圾進，垃圾出

問題現象

測試中發現部分標簽描述模糊、缺失或邏輯沖突，導致模型“正確地輸出錯誤結果”。

修正方案

強制要求：任何由他人提供的知識庫或評測集，必須由執行者親自校驗一遍。尤其關注：

標簽描述是否清晰無歧義
層級結構是否互斥完備
是否存在“其他”、“等等”等模糊兜底項

“磨刀不誤砍柴工”在 AI 項目中是鐵律。

數據質量決定模型上限，Prompt 優化只能逼近這個上限，無法突破。

5. 方法論反思：為什么我選擇“邊測邊改”？

初版效果雖不理想，但它的價值不在于“正確”，而在于“暴露問題”。

與部分團隊“先設計完美 Prompt，再批量測試”不同，我選擇在 Langfuse Playground 中快速迭代、小步驗證。原因如下：

零領域背景：我對該垂類產品無先驗知識，無法在初期預設完整規則
需求動態演進：打標邏輯需隨真實數據反饋調整，而非憑空設計
Prompt 是對話，不是文檔：通過測試 → 觀察 → 修改 → 再測試，逐步逼近工程可用狀態

v0.0.2：支持多維度 + 情緒分離 + 模糊匹配嘗試

核心改動

評價內的每個觀點單元獨立打標 + 獨立情緒
增加 is_exact_match 字段，嘗試讓模型識別“部分匹配”
提供 suggestion 字段，讓模型建議新標簽
修正標簽體系知識庫

輸出示例

提示詞這一趴，就不放出來，可以看下輸出結果

{"overall_sentiment": "負向","analysis_details": [{"topic_quote": "安裝師傅服務很好...","topic_sentiment": "正向","labels": [{"is_exact_match": true,"一級標簽": "售中","二級標簽": "售中","三級標簽": "服務態度","reasoning": "..."}]},{"topic_quote": "機器人有點傻回基站...","topic_sentiment": "負向","labels": [{"is_exact_match": false,"一級標簽": "產品體驗——清潔效果","二級標簽": "拖地效果","三級標簽": "邊角覆蓋","suggestion": "建議新增‘基站路徑混亂’標簽","reasoning": "..."}]}]
}

版本復盤

1. 輸出格式含 Markdown → 工程反序列化成本陡增

問題現象

模型輸出被包裹在 json ... 中，導致下游系統需額外處理“剝離 Markdown 標記”，增加解析復雜度與失敗風險。

影響

增加工程處理環節（需正則或字符串裁剪）
降低系統吞吐效率
提高與技術團隊對接成本（需額外文檔說明）

修正方案
在 Prompt 中明確指令：“輸出必須為純 JSON 格式，禁止包含任何 Markdown 語法、代碼塊標記或解釋性文本。”

工程原則：

Prompt 的輸出結構，必須與消費端（工程/BI/前端）的輸入結構對齊。
不要讓工程為你“擦屁股”，而要讓模型為你“鋪好路”。

2. 中文字段名 → 技術協作的“隱形成本”

問題現象

使用 “一級標簽”、“二級標簽” 等中文字段名，雖語義直觀，但：

不符合主流工程規范（JSON 字段名應為 snake_case 或 camelCase 英文）
增加前后端/數據管道字段映射成本
國際化/開源協作場景下易引發歧義

修正方案

統一字段命名規范：level1, level2, level3

3. “模糊匹配 + 標簽建議”機制 → 模型幻覺的溫床

原始設計意圖

希望模型能識別“部分匹配”場景（如匹配 L1 和 L3，但 L2 不匹配），并通過 is_exact_match: false + suggestion 字段，提供結構化反饋，輔助標簽體系迭代。

實際測試結果（GPT-3.5-Turbo）：

is_exact_match 判斷極不穩定 —— 同一輸入多次運行，結果不一致
suggestion 字段時有時無，內容隨機性高
最嚴重問題：模型自行“發明”標簽層級，返回不存在于知識庫中的組合，例如：

{"is_exact_match": true,"level1": "售中","level2": "物流與服務",  // ← 標簽體系中無此二級標簽"level3": "售中服務質量", // ← 自行編造的三級標簽"reasoning": "..."
}

或：

{"is_exact_match": false,"level1": "產品體驗——清潔效果","level2": "拖地效果","level3": "邊角覆蓋",  // ← “邊角覆蓋”實際屬于“清潔覆蓋率”二級標簽"suggestion": "...","reasoning": "..."
}

→ 導致標簽體系污染、分析維度錯亂、評測結果失效。

修正方案

果斷放棄“模糊匹配”機制，回歸“二元判斷”原則：

完全匹配 → 輸出完整三級標簽
不匹配 → 歸入 unmatched_feedback，不提供“建議標簽”

關鍵洞察

大模型不是產品經理，不能讓它“設計標簽體系”。
在可控性與靈活性之間，優先選擇可控性。

衍生價值

雖然“模糊匹配”機制被廢棄，但該嘗試啟發我們設計了一個新的評測維度：
“標簽體系合規性校驗” —— 自動檢查模型輸出的 level1/level2/level3 是否存在于知識庫中，作為模型“是否幻覺”的核心指標。

4. 方法論升級：從“功能設計”到“系統約束”

誤以為“更復雜的 Prompt = 更智能的輸出”
忽視了“模型能力邊界”與“工程落地成本”
未建立“Prompt 即接口”的契約意識

v0.0.3：工程友好化改造

核心改動

移除 ```json 包裹 → 純 JSON 輸出
字段名全改英文：level1, level2, level3
放棄 is_exact_match → 只保留“完全匹配”或“無法歸類”
新增 unmatched_feedback 數組，專門收容無法打標的片段

輸出結構

{"overall_sentiment": "負向","analysis_details": [{"level1": "產品體驗——運動與智能","level2": "路線規劃","level3": "轉圈","topic_sentiment": "負向","topic_quote": "機器人有點傻回基站老是在門口轉圈圈","reasoning": "..."}],"unmatched_feedback": [{"quote": "在說下機器","reasoning": "內容不具體，無法歸類"}]
}

版本復盤

1. 輸出結構未聚類 → 工程需二次加工，引入冗余成本

問題現象
Prompt 要求模型“按分句打標”，導致同一標簽被重復輸出多次（如“轉圈”標簽出現 3 次，對應 3 個 quote）。雖然語義正確，但：

評測維度不穩定：相同語義內容因分句策略不同，導致標簽數量波動，影響準確率/召回率計算
工程需額外聚類：下游系統必須遍歷數組、按 level1+level2+level3 做 group by，才能還原“一個標簽對應多個語義單元”的結構

修正方向
在 Prompt 中明確要求：

“請將指向相同三級標簽的所有語義單元，聚合到同一個對象中，以 semantic_units 數組形式輸出。”

→ 讓模型做聚類，而不是讓工程做聚類。

設計原則：

大模型的輸出，應盡可能貼近最終消費結構。
每一次“工程后處理”，都是系統復雜度和失敗率的來源。

2. 字段名“局部修改” → Prompt 一致性崩塌

問題現象

僅在“輸出格式”部分將“一級標簽”改為 level1，但 Prompt 的“知識庫描述”、“任務說明”、“Few-shot 示例”中仍保留中文字段名，導致：

模型混淆輸入輸出語義
輸出質量下降（相比 v0.0.2 準確率反而降低）
調試成本上升（需反復確認 Prompt 哪里沒改干凈）

修正方案

Prompt 修改必須“全局一致”：

知識庫結構描述 → 使用 level1, level2, level3
任務規則說明 → 使用英文字段名
Few-shot 示例 → 輸出結構與字段名完全對齊
輸出格式定義 → 無歧義、無冗余

3. 為什么堅持“可打標”與“不可打標”分離？——接口設計的哲學

原始疑問

“為什么不讓模型輸出一個數組，工程再 split 成 matched / unmatched？反正代碼遍歷一下就行。”

深度認知

這背后是兩種思維模式的對抗：

? “模型輸出原始數據，工程負責清洗” → 傳統數據流水線思維
? “模型輸出即最終結構，工程直接消費” → AI-Native 接口設計思維

我選擇后者，原因如下：

降低系統耦合度：工程不再依賴“后處理邏輯”來理解模型意圖
提升評測準確性：unmatched_feedback 是明確信號，可直接納入 Bad Case 分析
增強可解釋性：業務方/產品方無需懂代碼，即可理解“哪些內容模型無法處理”
符合 Langfuse 評測范式：結構化輸出便于自動比對 expected vs actual

核心理念

不要讓工程為 Prompt 的“不完整”買單。
大模型已具備理解復雜指令和輸出結構化 JSON 的能力 —— 我們要做的，是“設計好接口”，而不是“寫好膠水代碼”。

4. 方法論升級：Prompt 即產品接口

每一個字段、每一個結構、每一個術語，都影響下游消費、評測、協作效率。
“改 Prompt”不是局部優化，而是系統重構 —— 必須全局對齊、版本可控、影響可測。

v0.0.4：按標簽聚類 + 語義單元初探

核心改動

輸出結構改為 按標簽聚類 → 相同標簽的多個 quote 合并
全局替換字段名：Prompt 里所有“一級標簽”改為 level1
優化知識庫描述措辭，明確“格式”與“內容”分離

輸出結構

{"analysis_details": [{"level1": "產品體驗——智能性","level2": "路線規劃","level3": "轉圈","topic_sentiment": "負向","topic_quotes": ["機器人有點傻回基站老是在門口轉圈圈"],"reasoning": "..."}]
}

版本復盤

v0.0.4 實現了我們一直追求的“工程友好結構”：相同標簽自動聚類，語義片段歸入 topic_quotes 數組，無需下游二次加工。從工程角度看，這是一次巨大進步 —— 但從語義和評測角度看，它暴露了更深層的問題：

1. 機械聚類 → 語義割裂與斷章取義

問題現象

模型按“相同標簽”聚合 quote，但 quote 的劃分仍基于“標點分句”或“關鍵詞切分”，導致：

前后語義連貫的句子被強行拆分（如：“掃地效果差，尤其是邊角，根本掃不到” → 被拆成“掃地效果差”和“邊角掃不到”）
同一語義單元被打到不同標簽（如前半句歸“清潔效果”，后半句歸“邊角覆蓋”）
上下文丟失，導致標簽匹配表面正確，實則偏離用戶原意

修正方向

在 Prompt 中明確引入：

“語義單元識別（Semantic Unit Identification）”
你必須識別表達完整觀點的語義塊，它可能跨越多個句子，只要它們在邏輯上共同描述同一個問題或情緒。
禁止按標點或關鍵詞機械切分。

2. `topic_quotes` 缺失獨立情緒 → 情緒分析顆粒度坍塌

問題現象

雖然每個 quote 被歸入相同標簽，但不同 quote 可能攜帶不同情緒（如：一個標簽下既有抱怨，也有認可），而當前結構僅支持“標簽級情緒”，導致：

情緒分析失真（如：整體標為“負向”，但其中包含正向反饋）
無法支持“同一功能點下的情緒分布分析”（如：80% 用戶抱怨“轉圈”，但 20% 表示“偶爾能接受”）
評測指標無法細化到“語義單元級準確率”

修正方向

重構 topic_quotes 為對象數組，每個 quote 攜帶獨立情緒：

"semantic_units": [{"quote": "機器人回基站時轉圈，很煩人","sentiment": "負向"},{"quote": "但重啟后能恢復正常，勉強接受","sentiment": "中性"}
]

💡 產品價值：
我們要的不是“這個功能被提到多少次”，而是“用戶對這個功能的真實感受分布”。

v0.0.5：語義單元識別 + 獨立情緒標注

核心改動

在 Prompt 的“思考步驟”中，明確加入：

你的思考過程必須如下： 1. 整體評估：判斷整個評論是否與知識庫相關。若完全無關，則直接歸入`unmatched_feedback`并停止。 
2. 觀點提取：若相關，則提取出所有具體的觀點片段。 
3. 逐一標記：為每個片段找到最合適的標簽（level1, level2, level3）。 
4. 聚合歸并：將所有指向相同level1, level2, level3標簽的觀點片段合并到同一個條目下，形成`topic_quotes`數組。 你的輸出必須是純粹的JSON，不含任何解釋性文本或Markdown標記。==> 改為1. 整體評估：判斷整個評論是否與知識庫相關。若完全無關，則直接歸入`unmatched_feedback`并停止。 
2. 語義單元識別 (Semantic Unit Identification): 這是最關鍵的一步。你必須通讀全文，識別出表達完整、自洽觀點的語義單元。一個語義單元可能是一個短句，也可能是多個邏輯上緊密相連、共同描述一個問題的連續句子。你必須抵制機械按標點切分的誘惑。
3. 逐一標記與情感判斷: 為每個識別出的“語義單元”找到最合適的標簽（level1, level2, level3），并同時判斷該單元的獨立情感（正向/負向/中性/混合）。
4. 聚合歸并: 將所有指向相同level1, level2, level3標簽的“語義單元”合并到同一個條目下。在新結構中，為每個語義單元創建一個包含`quote`和`sentiment`的對象。