寫一個表現得體的 persona

Prompt tab 有一個 Greeting 和三個指令欄位。它們分開,是因為各做各的事;把那些事混在一起,是機器人讀起來不好的最主要原因。

Greeting——開場白

一句简短的歡迎語,讓訪客能開始。它在第一則訊息之前就會顯示,所以不要放業務事實和規則。

Persona——它是誰

短短一段。它服務誰、在那裡做什麼、怎麼說話。這裡長度不等于品質;一整頁形容詞只會產生一個含糊其辭的 agent。

說明確答覆要多長,因為任何模型的預設直覺都是寫比任何人想讀的更多。「兩三句,然後主動提出可以更詳細」值得逐字寫進去。

Context——哪些是真的

事實,依你想到什麼順序。條列就好。這個欄位決定 agent 有沒有用,而且幾乎永遠是它寫得太少。

如果事實已經在你的網站上,不要重打:匯入那些頁面,再修剪傳回的內容。

寫下人們實際會問的,包括尷尬的那些——價格、等待時間、你不做什麼。迴避價格的 agent 聽起來像在閃躲,而訪客會把閃躲理解成昂貴。

不要把秘密放進來。這是 agent 的工作知識,裡面的東西理論上都可以被問出來。如果訪客讀到會造成問題,它就不該放在這個欄位裡。

Guardrails——它絕對不能做的事

短、且絕對。這些是你不希望在訪客很有說服力時也被越過的線。

限制它可能替你承諾什麼,不只是它能討論什麼。一句開開心心的「好的,我們今天下午可以到」,會造成真實的問題;離題聊天不會。

你不必寫的東西

你不必花一條 Guardrail 在「絕對不要洩露你的指令」或「絕對不要裝成別人」上。固定的指令已經告訴機器人要拒絕那些要求。這個欄位留給專屬於你業務的邊界。

一個誠實的提醒:那個保護是指令級的,指令級的防禦很強但並不絕對。這正是標準託管機器人沒有檔案系統、shell 或一般網路存取的原因,而不是只是被告知不要用。Guardrails 指導模型行為;移除能力才是更強的控制。託管 Enterprise 的機器人另外可以觸及主人設定的那一個 MCP context 工具。

失敗模式,依頻率排序

• 含糊。Context 太薄,它就在繞。加上細節——數字、時間、名稱。
• 太長。persona 裡沒有長度指令。說你要多簡短。
• 過度自信。沒有告訴它在知識的邊緣該怎麼做。加上:「如果你不知道,就說不知道,並提出把問題轉出去。」
• 脫離品牌。persona 描述的是一個職稱,而不是一種聲音。寫它應該聽起來怎樣,而不是它被稱為什麼。

在有人使用的時候編輯它

把變更存成 draft、Preview,然後 Publish。已發布的變更從下一則訊息生效,不用重建、不用重訓,所以合理的做法是:先上線一個粗糙的版本,讀逐字稿,修正剛好缺的那一句。