如何從一則日常訊息重新設計 AI 角色的文字回覆
實用的 AI 角色回覆應始於發信者的實際請求與當下語境，而非性格口頭禪。在虛構的文字對話中，首先明確陳述發信者需要什麼、已知什麼，以及哪些細節仍不明確。接著為回覆寫下幾條簡短的規則，並針對訊息的微小變化進行測試。這個過程可以讓角色表現出一致性，而無需抄襲真實人物的私密訊息，或假裝成真人。
從一個虛構的對話開始
使用一個虛構的日常情境。例如：
> 瑪雅：「你明天可以把藍色資料夾帶過來嗎？我放在大門口旁邊了。」 > > AI 角色：「沒問題，我會帶過去。」
這是一個為了本練習而設計的虛構範例。發信者要求一項具體行動：帶資料夾。「明天」提供了時間，「藍色」指明了物品，而「大門口」則給出了位置線索。收件者可以直接回答，因為請求足夠具體，容易理解。無需編造背景故事、推測情緒，或添加冗長的修飾來讓回覆顯得個性化。
第一次的解讀是一種設計上的詮釋，而不是每個讀者必然會推論出的證據。Google 的對話設計指南將使用者的目標和語境視為互動設計的一部分，這提供了一種分析訊息的實用方法：同時記錄任務及圍繞任務的情境。Google 的對話設計概述
在起草規則之前，先用日常語言寫下一份簡短的訊息摘要：
請求：帶藍色資料夾。
時間：明天。
地點或哪一個：在大門口旁邊的藍色資料夾。
不明確的細節：訊息未說明明天幾點。
回覆需要做的事：確認該行動，而不增加未經證實的時間或承諾。
這份摘要是本文的決策輔助工具：它將單一訊息轉化為四項檢查——行動、語境、不確定性與回應任務。它有助於區分文字實際包含的資訊與作者可能會忍不住自行補充的細節。
將請求與角色語調分開
在加入語調之前，先寫出最簡潔正確的回覆：「好的，我明天會帶藍色資料夾過去。」這句話回應了請求，並重複了足夠的細節以確認角色所理解的內容。只有在這之後，才決定角色會如何自然地表達——也許是「好喔，我明天順便拿那個藍色資料夾過去。」說法變了，但任務沒有變。
這種順序讓語調成為角色的體現，而不是取代理解的工具。如果一句話既風趣又溫暖，卻未能確認行動，它就沒有完成回覆的基本任務。相反地，簡潔的確認仍然可以透過常見的縮寫語、溫和的感嘆詞或特有的正式程度來展現個性。
保持語調規則具備可觀察性。「聽起來很有魅力」留下了太多詮釋空間；「使用日常詞彙、避免繁複的笑話，並將例行確認保持在一句話之內」則給了創作者可以應用和比較的具體標準。W3C 網頁無障礙倡議在其清晰簡練寫作指南中，建議使用簡短明確的句子以及適合語境的簡單語言。該頁面針對的是網頁內容，因此將其應用於虛構的文字訊息是一種設計選擇，而非主張它硬性規範了角色對話。
將初稿轉化為回覆規則
針對這段對話的一套精簡規則可以寫成：
優先回答所請求的行動。
在有助於確認理解時，重複關鍵物品或時間。
例行確認使用一句簡短、自然的句子。
不要憑空捏造訊息中未確立的時間、地點或額外承諾。
如果缺失的細節會改變角色能做的事，提出一個針對性的問題。
這些規則結合了任務處理與語調限制。它們也指明了角色的行為應該止於何處：該訊息支持確認明天會帶資料夾；但並不支持承諾在特定時間帶去，或聲稱已經拿到它了。
OpenAI 的提示詞生成文件建議將任務、限制條件和預期輸出明確化，並將範例描述為展示預期結果的選用方式。對於寫作練習而言，這支持了將模糊的方向轉化為一組簡短、可測試的規則，並搭配範例對話。這並不意味著單一組措辭就能保證每個模型都能產生特定結果。OpenAI 的提示詞生成指南
一次測試一個微小的變化
適用於某條訊息的規則，在相近的情況下可能過於模糊或過於僵化。保持基礎對話不變，然後每次測試只更改一個細節。這能揭示哪條規則發揮了實質作用，以及哪種回覆需要進一步釐清。
測試訊息：「你明天可以把藍色資料夾帶過來嗎？」；變更內容：移除了位置線索；嘗試回覆：「好的，我明天會帶藍色資料夾過去。」
測試訊息：「你明天早上可以把藍色資料夾帶過來嗎？」；變更內容：縮小了時間範圍；嘗試回覆：「好的，我明天早上帶過去。」
測試訊息：「你明天可以把資料夾帶過來嗎？」；變更內容：移除了顏色；資料夾指代可能不明確；嘗試回覆：「好的——你指的是哪一個資料夾？」
測試訊息：「你可以帶藍色資料夾過來嗎？」；變更內容：省略了日期；嘗試回覆：「沒問題。你希望我什麼時候帶過去？」
這些範例回覆是說明性的設計，而非實測數據。這些變化的用意在於檢查當識別特徵或時間缺失時，規則集會如何反應。微軟關於釐清客戶意圖的指引指出，釐清細節可以縮小使用者的意圖範圍，同時也建議設計師在清晰度與避免提出不必要問題之間取得平衡。在此處，僅在缺失的細節會影響行動時，才提出針對性的問題。
避免一次更改多個要素。如果在一次測試中同時修改了發信者的措辭、添加了新地點並更改了角色語調，就很難判斷答案為何改變。一份簡單的測試記錄可以記下訊息、受測規則、回覆以及該回覆合適的原因。將任何非預期的答案視為修改規則或範例的契機——而不是證明角色需要更複雜的性格描寫。
在不捏造語境的前提下處理不確定性
簡短的文字訊息通常會省略細節，因為發信者預期對方已經知情。本練習應保留這種限制。如果訊息中說「資料夾」，但可能有多個符合的資料夾，角色可以詢問是哪一個。如果對話中只確立了一個資料夾，創作者可以使用該語境。如果不存在這樣的語境，憑空捏造確定性只會讓回覆偏離原本的對話。
微軟關於備援機制與人工轉接的指引，區分了旨在尋求理解的回應與在請求無法滿足時進行轉向的回應。對於這個日常虛構場景來說，可以借鑑的概念很簡潔：當角色無法有把握地完成當下的對話任務時，給予發信者一個明確的下一步。像「你指的是哪一個資料夾？」這樣自然的釐清，比泛泛的「我不確定」更有用，因為它直接指出了缺失的細節。
同時也要區分不確定的推測與已知的事實。「我明天會帶資料夾過去」是一個明確的確認，前提是虛構的發信者提出了該請求，且角色可以同意。「我會在 9 點帶過去」則增加了訊息中從未提供的資訊。精心設計的回覆不應悄悄將猜測變成承諾。
在測試後修訂規則
測試完成後，尋找具體的不匹配處。角色是否在細節無關緊要的情況下仍要求釐清？它是否確認了一個從未給出的時間？語調規則是否讓回覆變長卻沒有讓意思更清晰？修改能解釋該問題的最小規則，然後重新執行相同的變體測試，看看這項更改是否解決了一種情況，卻讓另一種情況變得彆扭。
例如，如果原始訊息已經明確寫了「明天」，而「詢問時間」卻產生了不必要的問題，則將其精確修改為：「僅在日期或時間是完成請求所必需且尚未給出的情況下，才詢問時間。」這條規則描述的是一種決策條件，而非一體適用的習慣。將測試訊息保留在規則旁，以便後續的編輯能夠對照同一組少量的範例進行檢查。
目標是建立一套可重複的寫作方法：使用一個虛構的對話，識別其請求與語境，將回覆的任務轉化為幾條可觀察的規則，並測試相近的變體。角色的語調隨後會從服務於對話的選擇中自然生成，而訊息本身則始終是角色所知範疇的邊界。