圖說：墨寒打開開源鍛造場，也以文件、測試與治理守住作品方向

昨天談如何避免把私人資料帶進 GitHub，今天終於正面談開源。墨寒採 MIT License，任何人都能閱讀、使用、修改與再散布符合授權條件的程式碼；但如果儲存庫只有一堆檔案和一張下載圖，工程師仍不知道從哪裡開始，也不敢確定送來的 PR 會不會破壞角色。

開源不是把門拆掉，而是把入口、地圖與共同規則放在門口。

License 回答可以怎麼用，README 回答這是什麼

MIT License 給出清楚且寬鬆的程式授權，但角色素材也要有自己的授權說明，不能因程式碼開源就假設網路上所有圖片都能任意再利用。

README 則要讓第一次來的人理解：墨寒是 Windows 桌面語音互動助理、目前有哪些功能、需要什麼環境、如何下載與從原始碼執行、哪些第三方整合仍是預覽。繁中、英文、簡中與日文入口也要一致更新，不能只有作者看得懂的版本最完整。

如果一個功能尚未經真實 Home Assistant 或 Microsoft 環境驗證，README 就明說。開源使用者最怕的不是「尚未完成」，而是浪費時間後才發現宣傳與實際狀態不同。

架構文件讓 PR 不必靠猜

墨寒的架構文件說明桌面外殼、控制台、服務、資料與領域規則的方向，並列出幾個單一權威來源：語音嘴型時間、語言政策、等待表情與可攜設定檔各由哪裡負責。

貢獻者若想新增功能，不應把大量邏輯繼續塞進 app.py，也不能從一個視窗直接呼叫另一個視窗的私有方法。先建立小而公開的接口，再加入功能與測試。

這不是要求每位參與者先通過架構考試，而是避免好心 PR 又複製一套計時器、設定或表情邏輯。規則越明確，Codex 與人類越能用相同標準審查。

Issue、PR 與安全通報是三扇不同的門

一般 Bug 可以開 Issue，提供版本、Windows 版本、最小重現步驟、預期與實際結果，附上去識別化截圖。想修改程式則建立獨立分支與 PR，說明範圍、測試與尚未驗證部分。

未修補安全漏洞不應直接公開 Issue，而是使用 GitHub 私人漏洞通報。這既保護使用者，也給維護者協調修正與公告的時間。

Code of Conduct 則提醒參與者保持尊重。角色專案可能涉及審美、人格與文化差異，意見可以尖銳，對人不必尖銳。

PR 不只是「程式可以跑」

墨寒的 PR 要保留原有行為，執行相關測試與完整回歸，通過 Windows CI、安全掃描與祕密檢查；影響使用者行為時，README、CHANGELOG 或版本說明也要更新。

受保護 main 不直接推送，修正放在獨立分支，由 PR 留下審查與 CI 證據。沒有處理完的對話與安全警告不急著合併。測試失敗時追根因，不刪除安全門檻換綠燈。

素材 PR 還要看錨點、眨眼、嘴型與角色一致性；翻譯 PR 要確認穩定內部值沒有被顯示文字取代。不同種類的貢獻，各有真正會破壞產品的地方。

好的第一個貢獻，應該小到能被完整理解

第一次送 PR 不必重寫整套架構。修正一段不自然英文、補一個特定 Windows 語音測試、讓錯誤訊息更清楚，或替一個可重現 Bug 增加回歸測試，都更容易審查與驗證。

Issue 可以先描述使用情境，和維護者確認方向後再動手，避免花很多時間完成一個不符合角色或安全邊界的方案。PR 則保持範圍集中，不順便格式化整個專案或夾帶無關檔案。

這種小步驟不是保守，而是讓每次合併都有清楚理由，出問題也容易追查。對一人工作室而言，可維護的貢獻比一次送來大量難以理解的改寫更珍貴。

文件與測試也是專案的一部分

工程師常最先注意程式碼，但新使用者是否能下載、是否理解 API 費用、海外 Windows 是否能選到女性聲音，往往由文件與測試決定。

翻譯者可以改善英文、簡中與日文說明；測試者可以在不同縮放、螢幕與語音套件回報；設計者可以協助角色素材流程，只要尊重授權與人格。這些工作若留下可重現證據，同樣值得在 Release Notes 感謝。

開源社群真正擴大的是觀察角度，不只是免費程式碼。

非工程師可以維護開源專案嗎？

我不會因為專案放上 GitHub 就突然成為資深工程師。但我能定義墨寒的身分與不可妥協原則，要求修改附上測試證據，也能在角色表現「技術正確、創作錯誤」時拒絕。

Codex 協助我讀差異、追流程、跑測試與準備 PR；外部工程師則能帶來不同 Windows、語言、Home Assistant 與軟體設計經驗。維護者的工作不是假裝什麼都懂，而是讓貢獻可以被理解、被驗收，也能在不合適時說明理由。

我也願意接受文件、翻譯、測試回報與素材流程改善，不只把「寫核心程式」當成貢獻。對國際化的墨寒而言，一台海外 Windows 的女性語音驗證，可能比再加十個按鈕更有價值。

邀請參與，不等於把方向交出去

墨寒屬於炎劍文化工作室的角色宇宙，有明確人格、美術與安全方向。MIT 開源讓技術被使用與改良，不代表任何 PR 都必須接受，也不代表角色可以因一個方便功能變成另一個人。

好的治理同時做到開放與一致：歡迎不同專長提出方案，公開說明驗收規則，最終由維護者對版本品質與角色連續性負責。

明天 Day 29，我會把鏡頭拉回我與 Codex 的合作。非工程師怎麼下需求、怎麼面對 AI 說得很有自信、又怎麼在不知道語法時仍掌握專案方向？

專案原始碼採 MIT License；自有角色素材的實際使用仍請查閱儲存庫內 ASSETS-LICENSE.md。