AI 遊戲主持人設計
當 AI 角色扮演遊戲出錯時，提示詞真的是問題所在嗎？
以 GPT-6 Astra 與 Claude Opus 5.5 指引為例，排查 AI RPG 擲骰場景中的上下文、API、執行與儲存狀態，再決定是否修改提示詞。
從實際出錯的回合開始
更好的提示詞無法修復每一個損壞的 AI 角色扮演回合。想像這個示意場景：你的遊俠試圖穿越一座腐爛的橋樑，遊戲要求進行一次檢定，而可見的骰子顯示 9 加 3，目標值為 15。總和是 12，但下一段卻說遊俠安全地穿過了橋樑。在加入更強硬的指示之前，先找出分歧是在回合的哪個環節進入的。這是一個診斷範例，而非 Playworlds 記錄在案的失敗案例。
寫下玩家的動作、要求的檢定、記錄的擲骰結果、預期後果、敘述後果，以及重新載入後顯示的狀態。這些觀察能讓問題可重現。玩家可以將場景與可見的骰子結果和角色卡進行比對，如果它影響下一個選擇，就能直接描述矛盾。
將任務措辭與缺失的上下文分開
措辭層面詢問模型是否收到明確的工作。請求是否要求它敘述一個已解決的失敗，或是決定穿越是否成功？它是否說明要停在哪裡、什麼留給玩家處理？如果這些邊界模糊，就明確說明工作、必要輸出以及必須遵守的事實。
上下文層面詢問提供了哪些事實。一個從未收到 12 總和、目標值 15 或橋樑狀況的敘述者，無法忠實地交代它們。檢查實際的請求負載或追蹤記錄。它應包含地點、相關能力、已結算的檢定以及確立的後果。如果輸入資訊過時，先修正其組裝方式，再評判文字。
檢查設定與 API 路徑
模型升級可能會改變支援的控制項和工具行為，即使提示詞保持不變。針對目前文件檢查模型、端點、推理設定、輸出限制、結構和工具。例如，OpenAI 的 GPT-6 指南指出 Astra 工具呼叫需要 Responses API。將 Chat Completions 工具工作流程複製到該設定中，是整合問題。這並未宣布 Astra 為 Playworlds 的遊戲主持人選項。
在編輯指示之前，先尋找錯誤、截斷回應、不完整的工具呼叫或解析器拒絕。使用相同的模型和端點測試一個最小化的支援請求。如果該請求成功而完整回合失敗，就比較負載。如果它也失敗，先修正相容性或設定。
先檢查執行過程，再歸咎於敘述者
一個角色扮演回合可能涉及擲骰請求、工具結果、敘述和儲存。詢問這些步驟中哪些實際完成了。擲骰是否產生了結果，該結果是否傳遞給敘述者？敘述是否在擲骰解決之前到達？一次儲存失敗是否後來被誤認為已完成的回合？流暢的句子是文字已生成的證據；它不是遊戲記錄了預期狀態的證明。
這個區分也適用於無人監督的代理。Anthropic 的 Opus 5.5 指南警告，僅文字的回合結束可能是進度報告，而非多步驟任務完成的證明。透過應用程式事件定義 RPG 回合完成：已結算的檢定、被接受的後果，以及持久儲存。不要從模型的結尾詞推斷全部三項。
檢查狀態並驗證結果
假設第一個回應說遊俠滑倒並抓住鋼索，但重新載入後遊俠卻在橋的另一側。這指向狀態或儲存問題。將被接受的擲骰結果和允許的狀態變更與已儲存的冒險進行比對，然後從全新會話重新開啟。如果儲存狀態正確但文字錯誤，檢查敘述。如果文字正確但儲存錯誤，檢查提交路徑。
驗證應使用可觀察的條件。在此範例中，成功意味著顯示的 12 在選定的規則下仍是一次失敗的檢定，敘述描述可遊玩的後果而不捏造成功，且重新開啟冒險保留相同的地點和結果。如果重試或重新整理會改變結果，單一看似良好的回應是不夠的。在變更後執行相同的小型場景，並記錄預期和觀察到的狀態。
用於下一次不匹配的六層檢查清單
當遊戲主持人回應看似錯誤時，使用此順序：(1) 任務措辭——敘述者是被要求描述已解決的結果，還是決定一個？(2) 上下文——它是否收到相關的擲骰和場景事實？(3) 設定——模型控制項和限制是否受支援？(4) API——端點和工具協定是否與模型相符？(5) 執行與狀態——每個步驟是否完成並儲存？(6) 驗證——重新載入並重複驗證後，結果是否保持一致？在第一個被證實的失敗處停止，修復它，並重新測試該回合。
當那些檢查之後任務或期望回應仍不清楚時，再修改提示詞。Playworlds 將骰子、角色資訊和持續的冒險整合到一個瀏覽器遊戲中；這些可見的部分讓玩家在敘述感覺不對時有事實可比較。使用我們的指南練習撰寫清晰的動作，然後選擇一個世界去探索。