前兩天講的是把信件洗乾淨、學會怎麼找出意思相近的案例。今天接上最後一段:客人來信,系統自動檢索出 5 個相似的歷史案例,交給 AI 生成一份中英文草稿。第一次看到成品的時候,語氣、用詞都很像公司同事會寫的東西,好到我差點忘記自己該做的事是檢查它,不是直接寄出去。
寫給模型的東西不是一大段話,是固定的三段骨架:
第一段:你是誰、不准做什麼
- 角色:一位熟悉台灣各地行程的資深旅遊顧問
- 硬限制:不得承諾價格、不得承諾房型或機位的可售狀態、
不得寫出沒有出現在參考案例裡的飯店或景點、
任何不確定的地方一律寫成 [待確認]
第二段:參考素材(這裡放檢索到的 5 個歷史案例摘要)
第三段:這次客人的來信原文
順序是刻意的。限制寫在最前面而不是最後,差別比我想像中大——同樣的限制放在整段指示的結尾,模型照做的比例明顯比較低,尤其是輸入變長的時候。把「不准做什麼」放在模型讀到客人需求之前,它比較不會被客人的語氣帶著走。
另一個設定是把生成的隨機性調到很低。寫行銷文案的時候,讓模型自由發揮是好事;寫報價草稿不是。我要的是同一封信今天跑跟明天跑,產出大致一樣的東西——會浮動的草稿,人審起來反而更累,因為你沒辦法建立「通常它哪裡會錯」的直覺。
這是一開始做錯、後來才改的。最早我把檢索到的 5 組對話原封不動塞進第二段,結果是輸入長得誇張,而且裡面一半是引文、簽名檔、免責聲明——就是前天那篇在清的那些東西。模型要在這堆雜訊裡自己找出重點,品質自然不穩。
後來改成塞「清理過的摘要加上標籤」:這一團幾個人、幾天、去了哪些地方、客人在意什麼、最後成交沒有。原始信件本身不進提示詞,只留一個連結讓人自己回去看。輸入長度掉了一大截,草稿品質反而變好——模型需要的是整理過的事實,不是更多的原料。
這件事還有一個現實的好處:輸入變短,成本就下來了。這支系統每次生成的花費,絕大部分不是在產出那幾百字,是在讀進去的那五個案例。
一開始我讓模型一次產出中英文兩個版本,想說省一次呼叫。實際用下來發現兩邊內容會對不起來——英文版寫了某個安排,中文版漏掉,或者兩邊的語氣差很多。
改成分兩次呼叫之後就穩了:先生成英文版(多數客人看的是這版),再把英文版當素材生成中文版,而不是從客人的原始來信重新生成一次。這樣中文版是英文版的對照,不是另一份獨立的創作,兩邊的內容必然一致。多付一次呼叫的錢,換掉一個很難察覺的錯誤來源,我覺得划算。
拿一組真實案例試過:十一位海外企業客戶來台灣六天,要求高規格的住宿與餐飲,行程要從台北一路安排到中南部。系統抓到的檢索案例大多是過去成交過的同類型團,生成出來的草稿,每天的行程節奏跟語氣都抓得很準,唯獨幾個細節被我攔了下來。
從客人來信進系統到草稿出現在信箱裡,整段大約十幾秒,其中檢索只佔不到半秒,其餘都是模型在寫字。這個速度不需要優化——反正業務不會盯著螢幕等它,他是等等回頭看信箱的時候才發現草稿已經在那裡了。
技術上最容易被忽略、但實際上最影響好不好用的一步,是草稿要建在原本那封信的討論串底下,而不是變成一封孤立的新信。
Gmail 建立草稿的時候,如果沒有把原信的討論串識別碼帶進去,那份草稿會單獨躺在草稿匣裡。業務打開客人的信,看不到任何東西,得自己跑去草稿匣翻——多這一步,這套系統就不會有人用。帶了討論串識別碼之後,業務點開客人來信,草稿就接在下面,按一下就能改、改完直接送出。
同一封信也不能被生成兩次草稿。做法跟前面轉寄信件、自動建檔那幾篇是同一套:處理完就在那封信上貼一個標籤,下一輪搜尋條件直接排除貼過標籤的信。不靠時間戳、不靠記憶體裡的狀態,因為程式隨時可能重跑。
至於 [待確認] 這個標記,我特地選了一個好搜尋的固定寫法。業務拿到草稿的第一個動作,就是在內文搜尋這四個字,跳出來幾個就代表有幾件事要自己確認。這比在文章裡寫「請注意檢查」有用得多。
第一種是檢索到的歷史案例本身就是回錯的示範,模型跟著學壞。第二種是客人的需求太新,檢索不到相像的案例,模型只能硬拼。第三種是幻覺,捏造出根本不存在的飯店或行程細節。第四種比較難抓,語氣完全對,但商業判斷是錯的——比如在不該給折扣的地方,暗示了可以給折扣。
這四種裡最麻煩的是第四種,因為文字讀起來完全通順,不會讓人一眼看出哪裡有問題,必須是熟悉業務判斷的人看過才抓得出來。前三種還有機會靠限制條件擋掉一部分,第四種只能靠人。
所以這支系統從一開始就只做到「生成草稿」為止,永遠寫進 Gmail 的草稿匣,不會直接寄出。人審永遠是最後一關,這條界線我沒有打算讓步。導入之後最明顯的變化,是同事回信的起手速度變快了,尤其是新進的規劃師,看著草稿學怎麼組織一封回信,上手的速度比過去單靠帶教快不少。
讓 AI 幫你寫草稿,不要讓 AI 幫你按寄出。這句話聽起來像廢話,但真正照做需要一點紀律——尤其是草稿寫得越好,你越容易想跳過檢查那一步。這條界線值得整間公司寫進標準作業流程裡。