點樣同開發者合作處理 AI 建立嘅 App

要同開發者良好合作處理你用 AI 建立嘅 App，就要將程式碼放入 Git 儲存庫，附上一頁式說明 App 做乜同原因，並且給一個範圍清楚、有完成定義嘅任務。事先講好邊個改邊部分，免得你同 AI 覆蓋咗佢哋嘅工作；將儲存庫同主機帳戶保留喺你名下，並透過正確嘅設定分享機密資料，而唔係用訊息傳送。

好多人用 AI 建立咗 App 嘅第一個版本之後，就會請開發者加入，例如加入付款功能、修正 AI 一直搞錯嘅嘢、檢視安全性，或者隨住 App 愈做愈大，由開發者接手。如果你仲未決定要唔要請人，可以先睇請開發者定用 AI 建立。本指南假設你已經決定，並希望合作過程順利。

幾時值得請開發者

常見嘅原因包括：

• AI 解決唔到嘅問題，清楚嘗試過幾次、亦還原過之後仍然未能解決。
• 高風險範圍：付款、權限、敏感資料、資料庫遷移。
• 安全或程式碼審查，尤其係上線之前，或者準備接受更大客戶之前。
• 效能，當真正嘅流量開始進來。
• 增長：App 已經變成一門生意，需要有人為程式碼負責。

清楚知道屬於邊一類，會影響以下所有步驟。

第一步：將程式碼放到可以分享嘅地方

開發者係透過 Git 儲存庫工作。聯絡任何人之前：

1. 將專案連接到一個私人 GitHub（或者類似）儲存庫，或者匯出專案。
2. 確保程式碼同歷史紀錄入面冇任何機密資料。見點樣保護 API 金鑰。
3. 用一個全新嘅副本確認專案可以運行，可以叫 AI 寫安裝步驟。

為一位加入呢個專案嘅開發者寫 README：講明 App 做乜、用咗咩技術棧、點樣喺本機安裝同運行、需要嘅環境變數（只列名稱）、資料夾結構，以及任何脆弱或者特別嘅地方。

如果你對 Git 未熟，點樣用 Git 管理 AI 建立嘅 App 會講基礎。

第二步：寫一頁式簡報

開發者冇參與你嘅聊天記錄。請用一頁紙提供背景資料：

• App 做乜，服務邊類人，以及有幾多人使用。
• 最重要嘅係咩：絕對唔可以壞嘅流程。
• 已知問題，以及你已經試過嘅方法。
• 任務內容，以及點樣知道已經完成。
• 限制：預算、期限，以及唔應該改動嘅嘢。

好嘅「完成定義」係可以測試嘅，例如：「已登入用戶可以用 Stripe Checkout 付費訂購月費計劃，計劃會喺佢嘅帳戶頁面顯示；喺客戶入口取消訂閱，就會喺週期結束時降級。」而唔係「整理下付款」。

第三步：安全咁提供權限

• **程式碼：**將佢哋加為儲存庫協作者。工作開始之後，唔好再用 ZIP 檔案來回傳送。
• **建置工具：**如果你嘅 AI App 建置工具支援團隊成員，就邀請佢哋加入一個只包含呢個專案嘅工作區。
• **機密資料：**喺主機嘅設定度加入，或者透過密碼管理工具分享。絕對唔好將金鑰貼入電郵或者即時通訊。
• **測試帳戶：**用測試資料建立帳戶，唔好分享你自己嘅登入資料。
• **正式環境資料：**只有真正需要時先提供，而且只提供所需嘅部分。

將儲存庫、網域同主機帳戶保留喺你名下。加人入去就可以，唔好將帳戶交俾人。

第四步：講清楚邊個改邊部分

最大嘅摩擦來源，係兩方同時改同一份程式碼：一方係你同 AI，另一方係開發者。揀一個規則：

無論揀邊種：每次下 prompt 之前都要 pull 最新程式碼，大型改動就放喺對方可以審閱嘅分支上。

第五步：用文字溝通

• 報告問題時，要寫明步驟、預期結果同實際結果。見點樣寫好嘅錯誤報告。
• 將決定集中記錄喺一個地方：問題追蹤器、共用文件，或者拉取請求嘅留言。
• 要求佢哋喺每個拉取請求入面，用淺白語言解釋改動。
• 講好幾耐見面跟進一次。

第六步：審閱佢哋嘅工作

你唔使睇得明程式碼都可以審閱工作。要檢查：

• 喺預覽或者測試環境度，佢係咪做到簡報所講嘅嘢。
• 冇其他嘢壞咗：運行你嘅關鍵流程。
• 佢哋有冇解釋改咗乜同點解改。
• 程式碼入面冇機密資料出現。

如果想再仔細啲，點樣審查 AI 生成嘅程式碼有一份清單，亦適用於人手寫嘅程式碼。你亦可以叫 AI 建置工具用淺白嘅語言，解釋開發者嘅拉取請求係做緊乜。

第七步：保持擁有權清晰

• 儲存庫、主機、網域同第三方帳戶都應該留喺你名下。
• 工作開始之前，要用文字寫清楚佢哋寫嘅程式碼屬於邊方。至於合約問題，就要查閱當地規例或者諮詢顧問。
• 工作完結時，撤銷佢哋嘅權限，並更換佢哋見過嘅任何金鑰。

例子 prompt

開發者喺最後一次 pull 改動咗結帳程式碼。用淺白語言解釋佢哋改咗乜，以及 App 其他部分有冇依賴呢部分。

列出呢個 App 最複雜或者最高風險嘅部分，等我可以話俾開發者知道審查重點放喺邊度。

我而家將付款交俾一位開發者。由今日起唔好改 src/payments 下面嘅任何檔案，或者 /api/billing 路由。如果某個改動需要用到佢哋，就告訴我，唔好自己改。

常見錯誤

• **冇簡報。**開發者要花付費時間去反推你想要乜。
• 範圍含糊，例如「修正 bug」或者「令佢可以正式上線」。
• 兩方同時改，冇先 pull，之後因為衝突而失去工作。
• 分享自己嘅登入資料，或者將金鑰貼入即時通訊。
• 帳戶登記喺開發者名下，令你日後難以分開。
• 工作完結後忘記撤銷權限同更換金鑰。

檢查清單

• 程式碼放喺一個以我名義開設嘅私人儲存庫，並且冇任何機密資料。
• README 解釋安裝方法；一頁式簡報解釋 App 同任務。
• 任務有一個可以測試嘅完成定義。
• 權限經協作者邀請提供，機密資料透過設定或者密碼管理工具分享。
• 大家已經講好邊個改邊部分，而我每次下 prompt 之前都會 pull。
• 工作會按照簡報同關鍵流程進行審閱。
• 擁有權已用文字寫清楚；工作完結時撤銷權限並更換金鑰。

喺 Mythex 同開發者合作

• **邀請佢哋加入工作區。**擁有者可以無限量邀請協作者，唔使每個座位付費；成員可以處理工作區入面嘅專案。建議用一個獨立嘅工作區，咁佢哋就只會見到呢個專案。已發布 App 嘅點數會由工作區擁有者支付。見邀請。
• **GitHub 同步同匯出（Pro）。**連接儲存庫並進行 push／pull，或者匯出專案，機密資料唔會包含喺內。見 GitHub, export, and import。
• 分享預覽連結，將進行中嘅工作俾冇 Mythex 帳戶嘅人睇；完成之後就刪除佢。
• 問答模式可以回答有關程式碼嘅問題，而唔會改動程式碼，適合用嚟理解開發者嘅改動。

如果開發者會喺其他地方運行 App，見點樣匯出同自行託管 AI 建立嘅 App。

常見問題