聘請開發者，定係用 AI 自己建立？點樣決定

當你需要快速得到第一版、App 主要係表格、清單、儀表板同頁面，而且你願意透過自己測試去學習時，就用 AI 建立。當 App 要大規模處理金錢或敏感資料、依賴複雜整合，或者已經係一門承受唔到故障嘅生意時，就聘請開發者。對好多人嚟講，最好嘅答案係兩者兼顧：先用 AI 建立第一版，證明有人想要，然後再請開發者審視同擴充。

每個選擇實際畀你咩

我哋刻意唔喺呢度列出收費率或薪金：佢哋因國家、經驗同專案而差異極大，任何單一數字都會誤導。改為就同一份書面範圍取得兩至三份報價。建立 App 要幾多錢會逐項拆解影響價錢嘅因素。

幾時用 AI 建立係較好嘅選擇

• 你正在測試一個構思。 目標係了解有冇人想要，而唔係追求完美嘅程式碼。參閱如何驗證 App 構思。
• App 主要係 CRUD。 即係建立、讀取、更新、刪除：表格、清單、紀錄、儀表板。AI 建立工具處理呢啲好得心應手。
• 你會經常反覆修改。 改變主意只需要一個提示，而唔係一宗變更申請。
• 係內部工具。 細小、已知嘅使用者會原諒粗糙嘅地方，並且會話你知邊度有問題。
• 預算緊絀。 你寧願將錢花喺爭取用家上，而唔係花喺建立上。
• 你想了解自己嘅產品。 親手建立會教你複雜性真正喺邊度。

佢對你嘅要求係：清晰嘅描述、逐項測試每次更改嘅耐性，以及誠實承認自己何時超出能力範圍。

幾時聘請開發者係較好嘅選擇

• 超出標準結帳嘅付款、資金流動或財務紀錄。
• 敏感資料，例如健康、兒童資料或政府身份證號碼，出錯會有法律後果。
• 複雜整合，連接舊系統、特別嘅 API，或者需要完全同步嘅資料。
• 效能同規模：大量即時功能、大量資料處理、高流量。
• 原生流動 App，上架 App Store 同 Google Play，如果響應式網頁 App 唔夠用嘅話。
• App 已經係你嘅生意。 付費客戶令停機同資料遺失變得十分昂貴。
• 你冇時間。 用 AI 建立仍然需要你花上數小時注意力；如果你抽唔出時間，就請一個抽得出時間嘅人。

混合路線：先用 AI 建立，然後聘請

呢個方法越來越普遍，而且通常係最合理嘅途徑：

1. 寫低你要建立嘅嘢。 一份簡短嘅規格會令之後嘅一切更好。如何用 AI 撰寫產品需求文件附有範本。
2. 用 AI 建立第一版。 保持細小：只做證明構思所需嘅一條流程。
3. 放到真實用家面前。 喺投放更多資源之前，先了解邊啲嘢最重要。
4. 匯出程式碼，或者連接到 GitHub。 開發者需要嘅係實際程式碼，而唔係截圖。
5. 先聘請開發者做一次審查。 一項固定、細小嘅任務：審查安全、資料處理同結構，並列出佢哋會改咩。
6. 根據佢哋嘅發現作決定。 加固並擴充現有程式碼，或者重建無法擴展嘅部分。

審查呢一步好重要。喺投入更多之前，呢個係一個低風險嘅方法去判斷開發者嘅工作，而且會誠實地話你知 AI 建立嘅版本有幾穩陣。如何將 AI 原型推向生產會講到通常需要留意嘅地方。

如果你聘請：點樣做好

同任何人傾偈之前先準備

• 一份書面範圍：用家、核心功能、唔包括嘅範圍、資料、權限。
• 你喜歡嘅 App 例子，以及喜歡嘅原因。
• 一個大致嘅預算範圍同期限。
• 你嘅運作原型（如果有）。通常比任何文件都更加清楚。

要檢查嘅事項

• 你可以使用嘅相關作品。 運作中嘅 App，而唔係只係截圖。
• 佢哋點樣溝通。 佢哋會問好嘅關於你用家嘅問題，定係只問技術問題？
• 一份按範圍而寫嘅報價，連同範圍改變時會點樣處理。
• 擁有權。 合約應該列明你擁有程式碼，並且帳戶（託管、網域、資料庫、付款供應商）都以你嘅名義登記。
• 交接。 文件、儲存庫嘅存取權，以及點樣喺冇佢哋嘅情況下運行 App。
• 推出之後。 邊個負責修復錯誤、維持幾長時間，以及費用幾多。

由細開始

一項細型有償試用任務（例如一次審查、一項功能、一個錯誤修正），比任何面試都更能說明問題。對雙方都比同一個陌生人去做一個大型定價專案更加公平。

如果你用 AI 建立：點樣做好

• 描述產品，而唔係程式碼。 用家、流程、資料、權限。參閱如何為 AI App 建立工具撰寫提示。
• 每次只改一樣嘢，測試過先至改下一樣。
• 使用檢查點，令一次錯誤嘅更改可以還原。
• 認真對待安全：每個私人頁面都要登入，用家只可以睇到自己嘅資料，機密唔可以放喺程式碼入面。
• 保留退出途徑。 揀一個可以匯出程式碼或者同步到 Git 儲存庫嘅工具，咁開發者日後可以接手。
• 知道自己嘅極限。 如果你要求同一個修正三次，而問題仍然存在，可能係時候讓開發者睇一睇。

任何一條路線嘅警告信號

有啲信號會話你知自己揀嘅路線行唔通。

用 AI 建立行唔通嘅情況係……

• 同一個錯誤反覆出現，即使試咗幾次修正。
• 你分唔到佢係咪安全。 你唔知邊個可以睇邊啲資料，而且你又冇辦法檢查。
• 每次更改都會令其他嘢壞咗。 App 已經以冇人計劃過嘅方式增長。
• 你用喺修正嘅時間多過從用家身上學習。 快速建立嘅目的係學習；如果呢樣嘢已經停咗，就要重新考慮。

呢啲情況並唔代表要由頭再來。通常只代表係時候讓開發者審視你手上已有嘅嘢。

聘請行唔通嘅情況係……

• 你睇唔到進度。 第一個協定嘅里程碑之後，都冇一個可以點擊睇嘅運作版本。
• 報價不斷增加，但範圍冇改變。
• 帳戶同程式碼唔係你嘅名義。 無論發生咩事，立即修正呢點。
• 你唔明白自己俾緊錢買咩，而問題得到含糊嘅回答。

一位好嘅開發者會樂意早啲展示作品、用淺白語言解釋取捨，並確保冇佢哋之後你都可以繼續。

快速決定指南

用 Mythex 建立第一版

Mythex 係一個 AI App 建立工具，適合「先自己建立」嘅路線：你描述 App，佢喺即時預覽中寫好並運行程式碼，需要時加入資料庫，並發布到一個真實網址。佢建立嘅網頁 App 可以喺手機上運作，而喺 Pro 方案下，佢可以將網頁 App 包裝成 Android 同 iPhone App，上架 Google Play 同 TestFlight。當你準備好請開發者加入時，Pro 方案容許你匯出專案，或者同步到你自己嘅 GitHub 儲存庫（GitHub 同匯出）；而完整嘅程式碼編輯器意味著開發者都可以直接喺專案入面工作。各方案包括咩內容，請參閱價錢頁。

常見問題