圖說：墨寒、Windows 桌面、控制台與幕後服務各守自己的位置
圖說：墨寒透明桌面角色
昨天我說，墨寒的人格不能只存在提示詞裡。今天要談的是另一個很容易被一張漂亮立繪掩蓋的問題：一位「住在桌面上」的角色，背後其實同時有好幾種工作。
她要在桌面上呼吸、眨眼、看向滑鼠，也要能被拖曳；我打開設定時，又需要另一個比較完整的視窗，管理語音、記憶、任務、提醒與安全權限。再往後還有資料保存、語音播放、雲端連線等看不見的工作。
我一開始很容易把它們全部想成「墨寒程式」。但對 Codex 而言，如果所有東西都塞在同一個地方，每修一個按鈕就可能牽動角色動作，每換一種聲音又可能弄壞整個視窗。這就像讓一位演員同時站在台前演戲、跑去控制燈光，還要在後台記帳，早晚會撞在一起。
我最常看見的是透明背景上的墨寒。她不需要一個方方正正的大視窗包住自己，應該自然地待在 Windows 桌面邊緣。滑鼠靠近時，她會把視線移過來；我拖動她時，位置要跟著走；沒有對話時，仍有很輕的呼吸和眨眼。
這個畫面最重要的任務不是塞滿功能，而是維持「角色在場」的感覺。任何突兀的卡頓、抽動或表情跳轉，都會比一般工具列上的小問題更顯眼。
所以桌面角色應該像舞台上的演員，專心處理顯示、互動與動作。她可以接到「開始說話」、「回到待機」、「現在顯示這個表情」等指令，卻不應該自己包辦所有帳號、資料庫和外部工具的細節。
當我要編輯記憶、查看任務、切換聲音，桌面角色那一小塊空間顯然不夠。於是墨寒還有一個控制台，讓功能可以被看見、被調整，也能清楚顯示現在使用哪種語音或權限。
我喜歡把它想成策士的案桌。角色本人仍在旁邊，但軍報、行程、設定與工具不能全掛在她身上。
這樣的分工也讓介面比較誠實。桌面上的一個微笑，不等於某項雲端整合已經連線；控制台必須明確告訴使用者目前狀態、需要的設定，以及哪些功能仍在實驗階段。角色魅力負責邀請人靠近，清楚的介面則負責讓人知道自己正在做什麼。
真正讓我理解「分工」重要性的，是修改開始變多以後。
語音播放需要知道聲音何時開始、何時結束，嘴型才不會晚半拍；長期記憶要保存資料，卻不能把 API 金鑰一起放進資料庫；設定檔可以轉移到另一台電腦，但不能順便帶走這台電腦的秘密權限。如果每個功能都直接伸手去碰別人的內部狀態，短期看起來很快，長期就會變成誰也不敢動的毛線球。
Codex 後來替專案整理出比較清楚的方向：桌面角色與控制台只透過公開的方式呼叫需要的服務；資料與規則放在各自負責的地方；可以替換的語音或連線方式，從組裝程式的入口交給角色使用。白話一點，就是「需要什麼就正式交接，不要從後門偷拿」。
我不需要背下所有技術名稱，也能理解這個原則。因為它直接對應我最在意的事：修正一個功能時，不要破壞原本正常的另一個功能。
使用者送出一句話後，畫面可能先顯示等待狀態；收到回答時，語音開始播放，嘴型接手；說完後，嘴巴閉起來，表情再回到合適的待機狀態。
這短短幾秒，同時碰到聊天、網路、語音、嘴型與表情。若每一邊都自己決定角色現在是什麼狀態，就會出現「文字已回答，表情還在思考」、「聲音播完，嘴巴仍張開」或「眨眼被特殊表情蓋掉」的怪事。
分工不是把功能切碎後就不管彼此，而是約定交棒方式。等待狀態只負責告訴人正在處理，不應該自行命令角色一定要露出思考表情；語音開始時由說話狀態接手；結束時再交還待機。每一段都知道自己何時開始、何時放手，畫面才會自然。
我不會用程式碼行數判斷。對我而言，有幾個很實際的訊號：
目前墨寒仍不是完美架構，也不會因為寫了一份架構文件就自動安全。但至少每次新增能力前，我們有一張共同地圖，知道功能應該放在哪裡，也知道哪些界線不能穿越。
這張地圖也改變了我和 Codex 說話的方式。以前我可能只說「把這個功能加到墨寒裡」，現在會先問：畫面由誰呈現？資料由誰保存？角色要在什麼時候收到通知？失敗後由誰把狀態恢復？我不必先知道正確的程式檔名，卻可以先把責任問清楚。當 Codex 的方案需要讓控制台直接伸手改角色內部狀態，我也能追問是不是少了一個正式交接點。
對我這種非技術創作者而言，架構真正的價值不是讓文件看起來專業，而是讓我有能力參與維護決策。它把「這樣改會不會牽一髮動全身」從模糊擔心，變成可以和 AI 一起檢查的問題。
明天 Day 5，我會從開發者的後台回到第一次下載墨寒的人：如果他只是想認識她，手上還沒有 OpenAI API 金鑰，第一次啟動到底該看見什麼？
本篇提到的分工以墨寒現行架構文件為依據；它描述的是維護原則，不代表每一項外部整合都已完成所有真實環境驗證。
iThome鐵人賽
看影片追技術