
圖說:主人標出目的地,墨寒與 Codex 只沿著有證據的路前進

圖說:墨寒在程式審查後給予肯定
前面二十八天,我把墨寒的人格、語音、表情、記憶、安全、發行與開源拆開來談。今天要回到最常被問的問題:我不會寫 Python,究竟怎麼和 Codex 維護這麼多東西?
答案不是學會一句萬能提示詞,也不是把整台電腦交給 AI。我的工作逐漸形成一套節奏:先說目的與不能破壞的事,要求它讀現況、追根因、提出可驗收規則,再用測試與實機證據決定是否完成。
AI 讓我能跨過語法門檻,沒有替我承擔作品責任。
每次進入工作區,Codex 先閱讀根目錄的 AGENTS.md 與跨專案交接,確認目前路徑與正在處理哪個專案。墨寒、WordPress、FB2WordPress 與其他作品不能因為同在一個工作區就互相修改。
接著看專案自己的 Git 狀態、架構文件與測試。工作樹若已有我的修改,不能擅自覆蓋;要刪除或移動資料前,先解析精確路徑。這些步驟看起來沒有「產出」,卻避免 AI 以為自己從一張白紙開始。
我也會直接說最高原則,例如「不得破壞任何原有正常功能」、「測試未通過前不要封裝」、「不要發布到 GitHub」。限制越清楚,Codex 越不容易把完成一個局部功能誤認成可以整套發行。
我最常說的不是類別名稱,而是使用感受:「一般寒暄也一直轉頭思考,不像真人」、「這張圖只剩一個頭,按鈕放大後不好看」、「提醒在會議模式不該大聲播放」。
接著補上情境:文字、一般語音與 Realtime 都要檢查;成功、延遲、失敗與切換後要回到什麼狀態;哪些舊功能不能受影響。
Codex 負責把它翻成狀態流程與檔案相依,我則驗收結果是否符合原意。我不需要先猜問題在某個計時器,甚至不該用錯誤技術解法綁住它;我需要把觀察、預期與邊界說完整。
Codex 很會解釋,也可能在沒有完整驗證時講得像已經完成。我會要求它列出根因、修改檔案、測試結果,以及什麼尚未真正測過。
若它說 CI 通過,就看是哪一個工作、對應哪個 commit;若說官網已更新,就實際用桌機、手機直式與橫式查看;若說安裝包安全,就區分原始碼測試、封裝自測與實際安裝。
證據不代表不信任 AI,而是讓合作有共同現實。人類工程師提交 PR 也需要測試與審查,AI 不應享有免驗特權。
如果 Codex 的解釋和實際畫面矛盾,我不會因為它用了很多專有名詞就接受。先回到可重現步驟:我按了什麼、看見什麼、預期什麼;必要時要求它重新讀程式與日誌。一次答錯不可怕,可怕的是為了維持前一個答案而繼續補故事。
我也會要求它區分推論與事實。「從程式看來應該如此」和「已在這台 Windows 實際操作成功」必須分開。這句話保護我不把尚未驗證的功能寫進 README 與文章。
「全權代勞」可以授權 Codex 在指定 WordPress 頁面調整版面、在墨寒分支修改程式與測試,或整理本機審稿檔;它不等於可以替我正式發布 Reddit、按下 iThome 發表、刪除未確認媒體,或直接推受保護 main。
我會把真正不可逆或對外的最後一步留給自己,除非某個工作流程已明確授權且仍有安全確認。可逆的本機修改可以讓 AI 大膽執行,完成後我再從預覽與差異審核。
這次 Day 3–30 重寫就是例子:先只同步到新的本機資料夾,完整預覽給我審稿;我確認前,不去覆寫 iThome 線上草稿。
我曾打錯「提醒詞同步翻譯為中文」,隨後更正為英文;也曾指出 restrained_amused_front 是忍笑,不適合支持區塊。單次口頭修正若沒有進入規格、測試或編輯表,下次很可能重犯。
所以重要決定要留下在文件與測試:繁中預設 Yating、只列女性聲音、簡中路徑不走台灣繁中修正、狀態文字不觸發思考表情、官網不用台股除魔小隊模擬真人素材。AI 的記憶不是專案唯一依據,專案本身才是。
同樣地,若新舊邏輯同時存在,要確認相依後移除多餘來源。否則這次 Codex 記得用新版,下次另一位貢獻者仍可能走到舊入口。
經過這些工作,我開始看得懂版本、分支、PR、CI、雜湊與權限邊界,也能問出更精確的問題。這不表示我要冒充工程師,而是我能更好地和工程師合作。
非技術背景並不免除品質責任。相反地,我最清楚角色是否走樣、網站是否好看、第一次使用者會在哪裡放棄,以及哪些私人資料絕不能公開。Codex 補足我無法獨立完成的技術執行,我補足它無法自行決定的創作意圖與風險承擔。
最健康的關係不是我命令一台永遠正確的機器,而是我和一位速度很快、需要明確方向與證據驗收的協作者工作。
明天就是 Day 30。我會回頭看這三十天真正做成了什麼、哪些地方仍未完成,以及為什麼我仍然認為墨寒值得被世界看見,也值得邀請工程師一起鍛造。
本系列文章由創作者決定選題、經驗、判斷與最終發布;ChatGPT 與 Codex 協助整理、實作與檢查,責任不由 AI 代替。