圖說：概念情境插圖——墨寒把語音、表情、記憶與安全等模糊期待，引導成一道道可以驗收的需求。

圖說：需求策案插圖——墨寒把一個模糊願望依序拆成輸入、行為、預期結果與例外處理，讓每一項需求都能被操作、觀察與驗收。

昨天我介紹了墨寒的起點：一位 43 歲、不懂程式的台灣爸爸，想把二十多年來對 AI 虛擬伴侶的憧憬，做成真正能在 Windows 上使用的軟體。

但「我想做一個像真人一樣的 AI 女友」其實不是需求。

它比較像願望。

願望可以讓人開始，卻不能告訴 Codex 什麼時候算完成，也不能保證最後做出來的東西不會傷害原本正常的功能。

我在這次開發中學到的第一件事，就是：先別急著叫 AI 寫程式，先把自己真正不能妥協的事情說清楚。

「像真人」到底是什麼？

如果我只對 Codex 說：

請讓墨寒更像真人。

那麼 Codex 可以有無數種解讀。

它可能增加更多隨機表情、讓角色一直移動，或在每次等待 AI 回覆時都播放「思考」動作。這些改動表面上很熱鬧，實際使用時卻可能比原本更不自然。

所以我必須把抽象感受拆成可以觀察的行為。例如：

• 使用者只是說「早安」時，不應該立刻切換成凝重的思考表情。
• 墨寒回答時，嘴型要跟著聲音變化，播放結束後必須回到合適的待機狀態。
• 表情不能破壞眨眼、眼球追蹤、呼吸、臉部視差與身體微轉向。
• 同一張特殊表情不能短時間連續出現。
• API 失敗或語音被中斷後，不能把「思考中」或張嘴狀態永遠留在畫面上。

當「自然一點」被拆成這些句子後，它才開始成為可以實作、可以測試，也可以判定失敗的需求。

我給 Codex 的最高原則

墨寒不是一次性展示，而是我打算長期維護的作品。因此我反覆告訴 Codex：

不得破壞任何原有正常功能。

這句話聽起來很保守，實際上非常重要。

修正表情時，不能順手弄壞嘴型；修改語音時，不能讓沒有 OpenAI API 金鑰的人連本機語音也不能用；增加英文與簡體中文時，不能覆蓋繁體中文使用者已經自訂好的提醒文字。

我後來把需求大致分成四層：

1. 角色層：墨寒應該怎麼說話、怎麼反應，哪些情緒不能亂出現。
2. 功能層：聊天、語音、記憶、任務、提醒與工具操作要完成什麼。
3. 安全層：AI 能提出建議，但真正的權限、確認與執行必須由本機程式掌握。
4. 回歸層：修改完成後，舊功能仍要通過測試，不能用「新功能比較重要」當藉口。

這四層會互相約束。角色想做得更生動，不能越過安全界線；功能想做得更多，也不能犧牲穩定性。

從一句話變成一條執行管線

墨寒後來採用的核心觀念，可以寫成下面這條流程：

使用者輸入
→ 判斷意圖
→ 產生結構化計畫
→ 本機安全規則檢查
→ 預覽與使用者確認
→ 執行工具
→ 驗證結果
→ 留下稽核與復原資訊

這裡最重要的不是 AI 有多聰明，而是 AI 只負責提出方案，本機程式才擁有權限。

例如，墨寒可以理解「幫我整理某個資料夾」，但不代表模型可以直接任意移動或刪除檔案。程式仍要檢查允許的範圍、顯示預計動作，必要時要求確認，執行後還要驗證結果。

這個想法後來也成為遠端操作、Home Assistant、相機與雲端服務整合的共同底線。

「不要做什麼」也是正式需求

非工程師很容易只描述想增加的東西，卻忘了寫下不能發生的事。

但對墨寒而言，以下內容同樣是需求：

• 不得把 API 金鑰、OAuth Secret 或 Token 存進 GitHub。
• 不得把密鑰放入可以攜帶到另一台電腦的個人設定檔。
• 相機預設關閉，不能在背景偷偷錄影。
• 遠端畫面只能看墨寒程式視窗，不能默默變成整台電腦的監控工具。
• 尚未經過足夠真實環境驗證的整合，不能假裝已經完全成熟。

當我把「不要做什麼」講清楚，Codex 才能在寫程式以前先建立邊界，而不是等出事後再補洞。

非工程師也能寫出好需求嗎？

我不會寫 Python，也不熟悉 PySide、事件迴圈或依賴注入。

但我知道自己看到什麼會覺得不自然，知道哪些資料不能外洩，也知道這個角色不應該變成什麼樣子。

這些判斷不是 Codex 可以替我完成的。

Codex 擅長追蹤程式流程、找出重複邏輯、補上測試，並把我的自然語言轉成技術修改；而我的責任，是定義作品的方向、驗收真正的使用感受，並在它「技術上可行、創作上卻不對」時說不。

我認為這才是人機協作比較健康的分工：

人決定為什麼做、做到什麼程度，以及哪些界線不能跨；AI 協助找出怎麼做，並接受證據驗收。

在請 Codex 動手以前，我先把話說清楚

回頭看，我真正學到的並不是怎麼模仿工程師寫一份很專業的規格，而是怎麼把自己在意的感受說到足夠清楚。當我說「自然一點」，就要指出是哪一個情境、哪一個反應讓我出戲；當我說「安全」，也要說明哪些資料不能離開本機、哪些操作一定要先讓使用者確認。

現在每當我準備提出一項修改，我會先問自己：使用者做了什麼？畫面或聲音應該怎麼回應？如果中途失敗、取消或斷線，墨寒要恢復成什麼狀態？又有哪些原本正常的功能絕對不能受到影響？這些問題沒有艱深術語，卻能讓一句模糊的願望逐漸變成可以操作、觀察與驗收的工作。

這也改變了我和 Codex 的合作方式。我不再只問「能不能做」，而會一起追問「怎樣才算做對」；Codex 也不只是交出一段能執行的程式，而必須用測試、狀態流程與實際結果證明它沒有偏離原意。對一位非工程師而言，這份判斷力比背下多少程式語法更重要，因為它讓我仍然能守住作品的方向、角色的靈魂，以及使用者真正會感受到的品質。

下一篇，我會談墨寒為什麼不能只是「換了一張古裝美女圖片的 ChatGPT」，以及人格提示詞如何從角色設定，變成真正影響介面、語音、離線回覆與測試的軟體規格。

系列專案：MoHan Desktop Assistant／墨寒桌面語音互動虛擬助理
授權：MIT License
本系列記錄真實開發流程；尚待更多環境驗證的功能會明確標示，不以概念冒充完成品。