如何與開發者合作處理 AI 建置的應用程式

要與開發者順利合作處理你用 AI 建置的應用程式，請把程式碼放在 Git 儲存庫中，提供一頁說明應用程式做什麼、為什麼要做的摘要，以及一項界定清楚、附有「完成定義」的任務。約定好誰負責修改哪些部分，避免你和 AI 覆蓋掉他們的工作；儲存庫與主機帳戶要以你的名義持有；機密資料則要透過正確的設定分享，而不是透過訊息傳送。

許多人是先用 AI 做出應用程式的第一個版本，然後才找開發者加入，例如為了加入付款功能、修正 AI 一直處理不好的問題、進行安全性審查，或在應用程式成長後接手維護。如果你還在決定要不要聘請人員，請參閱聘請開發者還是用 AI 建置。本指南假設你已經做了決定，並希望合作能順利進行。

什麼時候值得聘請開發者

常見的原因包括：

• AI 在幾次明確的嘗試與回復後仍無法解決的問題。
• 高風險的部分：付款、權限、敏感資料、資料庫遷移。
• 上線前或承接更大客戶前的安全性或程式碼審查。
• 真實流量到來後的效能問題。
• 成長：應用程式已經變成一門生意，需要有人負責程式碼。

清楚知道是哪一種情況，會影響下面的每一個步驟。

步驟一：把程式碼放到可以分享的地方

開發者通常是從 Git 儲存庫開始工作的。在聯絡任何人之前：

1. 把專案連接到一個私人的 GitHub（或類似服務）儲存庫，或匯出專案。
2. 確認程式碼與歷史紀錄中沒有任何機密資料。請參閱如何保護 API 金鑰。
3. 檢查是否能從一份全新的副本正常執行專案，可以請 AI 寫出設定步驟。

為新加入這個專案的開發者撰寫 README：應用程式做什麼、使用的技術堆疊、如何在本機安裝與執行、需要的環境變數（只列名稱）、資料夾結構，以及任何脆弱或不尋常的地方。

如果你對 Git 還不熟悉，如何搭配 AI 建置的應用程式使用 Git會介紹基本概念。

步驟二：寫一頁的簡報

開發者沒有參與你和 AI 的整段聊天紀錄，所以請用一頁的篇幅提供背景資訊：

• 應用程式做什麼，服務的對象是誰，有多少人使用。
• 最重要的部分：絕對不能壞掉的流程。
• 已知的問題，以及你已經嘗試過什麼。
• 任務內容，以及你會如何判定它完成。
• 限制條件：預算、期限，以及不應該更動的東西。

好的「完成定義」是可以測試的：「已登入的使用者可以用 Stripe Checkout 付費購買月費方案，該方案會出現在他的帳戶頁面上，而在客戶入口網站中取消訂閱後，會在本期結束時降級。」而不是「把付款處理好」。

步驟三：安全地提供存取權

• 程式碼： 把開發者加為儲存庫的協作者。工作開始後，不要再來回傳送 ZIP 檔。
• 建置工具： 如果你的 AI 應用程式建置工具支援團隊成員，請邀請他們加入一個只包含這個專案的工作區。
• 機密資料： 在主機的設定中加入，或透過密碼管理工具分享。絕對不要把金鑰貼到電子郵件或聊天中。
• 測試帳號： 建立使用測試資料的帳號，而不是分享你自己的登入資訊。
• 正式環境資料： 只有在他們確實需要時才提供，並且只提供他們需要的部分。

儲存庫、網域與主機帳戶都要以你的名義持有。把人加進來；不要把帳戶交給別人。

步驟四：約定誰負責修改哪些部分

最大的摩擦來源，是兩方同時修改同一份程式碼：你和 AI，以及開發者。選定一個規則：

無論你選擇哪一種：每次開始提示前都要拉取最新的程式碼，而且大型變更要放在另一方能夠審查的分支上。

步驟五：以書面方式溝通

• 回報問題時寫明步驟、預期結果與實際結果。請參閱如何寫出好的錯誤回報。
• 把決策集中在一個地方：問題追蹤器、共用文件，或拉取請求的留言中。
• 請對方在每個拉取請求中用淺顯的語言說明他們改了什麼。
• 約定好多久核對一次進度。

步驟六：審查他們的工作

你不需要讀懂程式碼也能進行審查。請檢查：

• 是否符合簡報的內容，可以在預覽或測試版本上確認。
• 沒有弄壞其他東西：執行你最關鍵的流程。
• 他們有說明改了什麼以及為什麼改。
• 程式碼中沒有出現機密資料。

如果要更仔細地檢查，如何審查 AI 生成的程式碼提供了一份檢查清單，對人工撰寫的程式碼同樣適用。你也可以請 AI 建置工具用淺顯的方式向你解釋開發者的拉取請求。

步驟七：釐清所有權

• 儲存庫、主機、網域與第三方帳戶都應該保留在你的名下。
• 開工前以書面方式約定他們撰寫的程式碼歸屬。如果有合約上的問題，請查看當地法規或諮詢專業顧問。
• 工作結束時，移除他們的存取權，並重新產生他們可能看過的所有金鑰。

範例提示

開發者在上一次拉取中修改了結帳程式碼。請用淺顯的語言說明他們改了什麼，以及應用程式中是否有其他部分依賴它。

列出這個應用程式中最複雜或風險最高的部分，讓我能告訴開發者審查時該把重點放在哪裡。

我把付款交給開發者處理。從現在開始，不要修改 src/payments 底下的任何檔案，也不要動 /api/billing 路由。如果某項修改需要動到它們，請告訴我，而不要自行處理。

常見錯誤

• 沒有簡報。 開發者花費了付費的時間去逆向推敲你想要什麼。
• 範圍模糊，例如「修正 bug」或「讓它達到上線等級」。
• 兩邊同時編輯，卻沒有先拉取，結果因衝突而遺失工作。
• 分享自己的登入資訊，或把金鑰貼到聊天中。
• 帳戶以開發者的名義持有，之後要分開時會很困難。
• 工作結束後忘記移除存取權，也忘記重新產生金鑰。

檢查清單

• 程式碼位於以我的名義持有的私人儲存庫中，且不含任何機密資料。
• README 說明了設定方式；一頁的簡報說明了應用程式與任務。
• 任務有可測試的完成定義。
• 存取權透過協作者邀請提供，機密資料透過設定或密碼管理工具提供。
• 我們約定好誰負責修改哪些部分，而且我會在提示前拉取。
• 工作會依照簡報與關鍵流程進行審查。
• 所有權已有書面約定；工作結束時移除存取權並重新產生金鑰。

在 Mythex 上與開發者合作

• 邀請他們加入工作區。 擁有者可以邀請不限人數的協作者，且不收取每席位費用；成員可以在該工作區的專案中工作。建議使用獨立的工作區，讓他們只能看到這個專案。已發布應用程式的點數由工作區擁有者承擔。請參閱邀請。
• GitHub 同步與匯出（Pro）。 連接儲存庫後即可推送與拉取，或匯出專案（不含機密資料）。請參閱 GitHub、匯出與匯入。
• 分享預覽連結。 可以在沒有 Mythex 帳戶的情況下，把進行中的工作展示給別人看；完成後請刪除該連結。
• 詢問模式可以在不更動程式碼的前提下回答程式碼相關的問題，有助於理解開發者的變更。

如果開發者會在其他地方執行應用程式，請參閱如何匯出並自行架設 AI 建置的應用程式。

常見問題