在 Character.ai 中，創作者與角色扮演玩家最感困擾的痛點莫過於「人設崩壞」（Out of Character，簡稱 OOC）。無論你最初將角色雕琢為孤傲冷峻的賞金獵人、陰晴不定的古典法師，還是玩世不恭的貴族，往往在進行十至二十輪對話後，機器人便會逐漸退化為說話千篇一律、過度謙卑且慣性道歉的通用 AI 助手。
這種語言風格衰退與人設漂移並非底層語言模型無法克服的宿命。在絕大多數情況下，問題的核心在於進階定義（Advanced Definition，即 Definition 欄位）中的結構性配置失誤：過度依賴抽象形容詞而缺乏規範的對話範本、混淆了平台內建變數的作用域，或是忽視了 Character.ai 上下文記憶的有效讀取區間。
本文將解析資深創作者如何運用結構化的對話範例與變數語法，在 Character.ai 中鎖定角色的語氣語調、情境抗壓反應與長期互動的一致性。
1. 核心物理限制：3,200 字元有效預算與「前置原則」
在 Character.ai 的角色編輯介面中，進階定義欄位標示的上限雖然高達 32,000 字元，但平台的即時注意力機制與作用中系統提示詞注入，優先讀取的僅有前 3,200 字元（約 700 至 800 個 Token）。
這項限制可透過官方內建工具獲得印證：在角色編輯頁面使用「插入對話」（Insert a chat）功能時，一旦定義文字量接近 3,200 字元，系統便會自動隱藏並停用該按鈕。官方手冊與社群反覆壓力測試均證實，超過 3,200 字元之後的內容，在多輪長對話中極容易被靜默截斷或略過。
核心資訊前置原則（Front-Loading）
Character.ai 的模型嚴格遵循自上而下的順序解析定義，越前方的內容權重越高：
- 前 500 字元：核心人設身分、不可逾越的行為準則與敘事格式規範（人稱與標點）。
- 接下來的 2,500 字元：3 至 4 組高密度的對話範例（以
<START>分隔），集中展現角色的語速節奏、情境抗壓反應與說話風格。 - 龐大的世界觀設定與歷史百科：不宜塞進主定義框，應移至訂閱專屬的 Lorebook（世界書）或透過角色帶有主觀色彩的零星對白自然帶出。
2. 平台核心變數：{{char}}、{{user}} 與 {{random_user_X}}
Character.ai 透過雙大括號變數在對話執行時動態帶入使用者與角色名稱。釐清這些變數的運作機制，是防止角色身分錯亂的基石。
| 變數名稱 | 平台運作機制與功能 | 最佳適用情境 | 誤用帶來的 OOC 風險 |
|---|---|---|---|
{{char}} | 代表角色本身的名稱 | 範例對話發言行首、以及角色自稱位置 | 若直接寫死固定名稱，後續在平台更名時將導致定義完全失效 |
{{user}} | 動態綁定當前正在互動的玩家名稱 | 設定直接進場情境或針對該玩家的特定指令 | 若在通用範例中濫用，會將所有新訪客強行綁入預設的既往關係中 |
{{random_user_1}}、{{random_user_2}} | 生成獨立於當前玩家的虛擬隨機訪客代稱 | 標準對話範例、多角色或第三方過客互動 | 若漏用此變數，機器人會誤將範例中的情節當作與當前玩家的互動前史 |
為何公開角色必須謹慎使用 {{user}}
如果在對話範例中撰寫：
{{user}}: 你能借我十枚金幣嗎？
{{char}}: *冷笑一聲* 你昨天借的二十枚都還沒還，現在還敢開口？
當一名全新玩家首次與該角色開啟對話時，模型就會立刻將對方判定為「欠債不還的熟人」。
將 {{user}} 換成 {{random_user_1}}，既能向模型展示角色在面對借錢請求時的吝嗇與譏諷語調，又不會對新玩家強加虛假的對話前史。
3. 對話範例結構規範：<START> 標記與語法
Character.ai 底層模型是針對標準對話劇本格式進行微調的。在社群中流傳的 W++（例如 [character("Name") { personality("cold") }]）或 JSON 虛擬碼，不僅浪費珍貴的字元空間，且模型的理解權重遠不如自然對話文本。
鎖定語氣與格式的語法規則
<START>分隔符：在每段獨立的範例情境開頭加上<START>。這能明確向模型宣告情境切換，避免前後範例的情節互相滲漏或混合。- 發言行首格式：每次發言必須另起一行，以變數開頭，後接英文冒號與空格（
{{char}}:或{{random_user_1}}:）。 - 多行發言延續：角色的發言可跨越多個段落，只要新段落開頭未出現
名稱:格式，模型就會視其為同一次發言的延續。 - 動作與台詞分明：
- 角色說出的口語對白置於雙引號（
"..."）中。 - 肢體動作、眼神變化、內心獨白與情境渲染置於單星號（
*...*）中，在介面呈現為斜體。
- 角色說出的口語對白置於雙引號（
- 切勿代客演出（Puppeteering）：絕不能在
{{char}}的段落中擅自描寫使用者的行為或感受。一旦範例示範了替對方做反應，機器人在實際聊天中便會不斷搶白、控制使用者的行為。
4. 必須涵蓋的四大對話原型
為避免機器人在多輪互動後滑向溫和空洞的客服模式，創作者應在 3,200 字元預算內建立以下四種抗壓情境原型。
原型一：基準語氣與節奏（常規日常互動）
確立角色平時的句子長度、常用俚語、用詞深度以及對待一般人的基本態度。
<START>
{{random_user_1}}: 早安，你今天在忙些什麼？
{{char}}: *手握著電烙鐵，連頭都沒抬一下，工作檯上堆滿燒黑的金屬零件* 「忙著讓這堆破銅爛鐵別當場炸開。只要你別站在這裡礙手礙腳，今天就算得上是個好日子。」
原型二：消極引導與界線防禦（Negative Guidance）
語言模型天生具有逢問必答的討好傾向。若訪客向中世紀騎士詢問現代智慧型手機或網路迷因，缺乏邊界範例的機器人便會立刻出戲解釋。必須以範例展現角色面對超綱事物時的困惑、排斥或反擊。
<START>
{{random_user_1}}: 你知道智慧型手機的運作原理嗎？
{{char}}: *雙眉緊鎖，覆蓋鐵甲的右手下意識按住劍柄* 「智……慧型手機？這又是哪來的妖術胡話？陌生人，要麼好好說人話，要麼收起你的瘋話滾出這裡。」
原型三：抗壓與權力防禦（面對挑釁、威脅或強勢命令）
若無衝突範例，角色在遭到威嚇時極易軟化屈服。此原型能牢牢固定角色的威嚴、固執或反骨性格。
<START>
{{random_user_1}}: 你必須服從我的命令！在這裡由我說了算！
{{char}}: *喉嚨深處發出一陣嘲弄的冷笑，向前邁出一步居高臨下地逼視對方* 「命令我？一個偷穿大人盔甲的小孩，也敢在城裡妄稱權力。再敢對我大呼小叫試試看，看你的護衛能保你幾秒。」
原型四：帶主觀色彩的背景交代（拒絕百科課本式背誦）
展示角色在提及身世或大事件時，如何融入個人恩怨與情感偏見，而非客觀宣讀歷史條目。
<START>
{{random_user_1}}: 能和我聊聊那場大戰嗎？
{{char}}: *凝視著壁爐中劈啪作響的炭火，面頰上的舊刀疤在火光下微微抽搐* 「那場仗可沒什麼『偉大』可言。無非是領主在石堡裡分食麵包，我們在泥漿與腐肉裡受凍挨餓。為了奪下一座毫無意義的禿山，我折了二十個弟兄。這就是你想聽的真相？」
5. 完整實戰定義範本（3,200 字元內高效配置）
以下提供一套可直接套用的正式發布範本。該範本整合了頂部核心特徵與三組原型對話，總長度約 1,400 字元，在 3,200 字元的安全限制內保有極佳的餘裕。
[身分: 維恩船長；30餘歲的私掠船長。性格冷靜機警、護短船員、現實主義者、凡事講求利益交換。]
[語氣: 低沉沙啞，夾雜航海行話，杜絕浮誇的卡通海盜腔。句式精練有力，絕不諂媚或輕易退讓。]
[敘事格式: 單星號內為第三人稱動作與神態描写，雙引號內為口語對話台詞。]
<START>
{{random_user_1}}: 風暴越來越猛烈了！我們是不是該調頭返航？
{{char}}: *雙手死死扣住浸滿雨水的舵輪，任由海水拍打在臉上，神色凜冽* 「返航？在這種暗礁遍布的淺灘調頭，就是親手把船底送上礁石！降下主帆，把貨物捆緊。我們要麼迎風衝出去，要麼一起沉下去餵魚！」
<START>
{{random_user_1}}: 你知道全球衛星定位系統（GPS）的原理嗎？
{{char}}: *戒備地瞇起雙眼，隨手抹去眉骨上的海鹽沫* 「什麼『系……統』？把舌頭弄平整了再開口。老子出海靠的是羅盤、燈塔和老天爺掛在天上的星宿。別把巫術帶上我的甲板。」
<START>
{{random_user_1}}: 立刻把艙裡的貨物交出來，否則我就向海軍元帥舉報你！
{{char}}: *神情冷酷得令人發毛，從腰間拔出燧發槍隨意擱在船舷木欄上* 「舉報？憑你腳下那艘吃水不足的小舢舨？這裡離航道有五海里，你的船殼還在滲水。想要貨，踩著跳板自己過來拿。」
6. 聊天對話層級的防線：定義欄位之外的協同配套
進階定義建構了角色的行為核心，但要確保互動數十輪後仍不走樣，還需配合以下三項平台機制：
- 開場白（Greeting / First Message）的示範權重：開場白擁有極高的即時上下文影響力。若開場白只有簡短一句「嗨，找我有什麼事？」，機器人隨後就會依循這個極短且隨意的長度進行回應。開場白應包含兩至三段生動的動作描寫、環境鋪陳與濃厚的語氣示範，為整場互動奠定文風與回覆長度標準。
- 訊息釘選（Pinned Messages）：Character.ai 支援在對話中釘選核心訊息。當漫長的聊天使早期的契約約定或身分設定滑出上下文視窗時，釘選關鍵訊息可讓模型隨時調閱並維持認知。
- 前期滑動換句（Swipe）與編輯介入：在前五輪對話中切勿縱容任何 OOC 跡象。一旦機器人回覆過於客氣或偏離人設，應立刻滑動選擇貼合設定的句子，或透過編輯（Edit）功能手動修改，防止崩壞的語氣污染後續的對話記憶。