昨天我們把格式這種「硬」規則搞定了——輸出的骨架該長什麼樣子,已經很明確。但即使格式完全正確,你可能還是會遇到一個常見的抱怨:「格式是對的,可是讀起來就是很像 AI 寫的,怪怪的。」
這就是今天要處理的問題。格式是「容器」,今天談的 Tone(語氣)與 Style(風格)是「灌進容器裡的水的質地」——容器對了,水的質地不對,整體讀起來還是不對勁。
「AI 味」不是一個模糊的感覺,它其實有幾個可以具體指認的特徵:
搞懂這四個具體特徵之後,你會發現:「AI 味」不是玄學,而是幾類可以在 prompt 裡明確禁止或修正的具體毛病。
Day 6 提過,Style 和 Tone 容易搞混,這裡用更具體的方式再拆一次:
一個實用的判斷方法:如果把同一份內容,想像成不同的人來說,句子結構(Style)可能差不多,但「聽起來的感覺」(Tone)會差很多。例如同樣是報告一個異常事件,冷靜的分析師語氣、和緊張兮兮的語氣,講的事實一樣,但態度截然不同。
技巧一:直接列出禁用詞彙與句型
與其抽象地說「不要有 AI 味」,不如具體列出你不想看到的詞彙:
禁止使用以下用語:
- 「值得注意的是」「總的來說」等制式轉折語
- 「經過詳盡的分析與評估」等冗贅修飾語
- 「很高興」「非常樂意」等客服式禮貌用語
句子力求精簡,能一句話講完的事,不要拆成兩句話或加上不必要的修飾。
這個技巧的效果通常立竿見影,因為 AI 很擅長「避免做被明確禁止的事」,遠比它擅長「猜測你抽象講的『不要有 AI 味』是什麼意思」。
技巧二:直接指定句子的目標長度或密度
「精簡」這個詞本身也是抽象的,可以進一步具體化,例如:「事件摘要每一項不超過一句話,一句話中不使用超過一個逗號分隔的子句。」這種具體的長度限制,能有效避免 AI「把簡單的事情講得很長」的傾向。
技巧三:用「反例」明確排除某種寫法
有時候,直接舉一個「不要這樣寫」的反例,比正面描述更有效:
反例(不要這樣寫):「經過本週詳盡的監控與分析,我們很高興地向您報告,系統整體運作情況良好,未發現任何值得特別關注的異常狀況。」
正確寫法:「本週無異常事件。」
這種「錯誤示範 + 正確示範」的對照,是 Day 10 要談的 Few-shot Prompting 技巧的一種簡化應用——先用一個小範例,今天讓你先感受一下這個技巧的威力。
除了消除 AI 味,還有一步是加入你們部門特有的表達習慣,讓報告讀起來更貼近平常同事寫的樣子。這通常包括:
這些細節可以直接寫進 System Prompt 的 Style 區塊,一次講清楚,之後每次使用都會自動套用。
回頭看 AI 幫你產出過的任何一份草稿(或者現在就用你的範本試跑一次),對照今天列出的四個「AI 味」特徵,標出裡面出現了哪幾種。針對每一種,寫一條具體的禁用規則,加進你的 System Prompt 裡。
格式對了,只是解決了「容器」的問題;今天處理的 Tone 與 Style,才是決定一份報告讀起來「像不像自己人寫的」的關鍵。核心心法是:不要用抽象詞彙(例如「自然一點」)去要求 AI,而是把抽象感覺拆解成具體的禁用詞、句型限制、或反例對照——這跟 Day 5 建立品質檢查清單時用的「追問法」,其實是同一套邏輯的延伸應用。
下一篇,我們會把今天最後提到的「反例對照」技巧,正式擴展成一套完整的方法——Few-shot Prompting,談談為什麼「給範例」往往比「說破嘴」更有效。