Cursor Start from Scratch 能直接上線嗎？2026 驗收清單

症狀：瀏覽器預覽已經成功，但你不確定能否交給使用者。
最快解法：先把 Cursor Start from Scratch 產生的專案移交到正式程式庫，在全新環境完成 CI、安全檢查、人工審核與回滾；涉及 Xcode 或 macOS 時，再轉入獨立 Mac 驗證。

這篇適合三類人：需要在沒有現成程式庫時快速驗證產品想法的獨立開發者、準備讓 Cursor Cloud Agents 建立新專案的創業團隊，以及負責 CI、權限或 Apple 工具鏈的工程師。你要判斷的不是「頁面能不能打開」，而是這個原型是否已具備可接管、可重建、可審核和可退回的條件。

注意： Cursor 官方已確認 Start from Scratch 可以在未連線第三方原始碼程式庫時啟動 Cloud Agent、建立 Origin 專案並提供瀏覽器即時預覽；Origin 目前仍是 early beta。這些能力不等於官方承諾專案天然符合生產安全、測試、合規或可用性要求。請以官方更新日誌及Origin 文件的現況為準。

先用部署目標對比驗收門檻

同一個生成結果，放在一次性展示、內部工具和對外服務上，放行標準完全不同。你應在首次提示前寫下技術棧、資料類型、外部 API、最終執行平台，以及是否依賴 Xcode、Apple SDK 或 macOS；否則團隊很容易把「看得到」誤寫成「可以上線」。

本文的 5 個階段是你的驗收框架，不是 Cursor 對生成專案提供的品質保證。官方 Cloud Agents 文件描述的是 Agent 的使用與執行能力；生產環境仍由你的程式庫、執行節點、測試和權限設計負責，細節可對照Cloud Agents 官方文件。

第一階段：從「能生成」對比到「能接管」

首次生成完成後，不要立刻反覆追加提示來修補畫面。先停止 Agent，將目前結果當成待接管的交付物，逐項確認：

• 目錄結構是否能讓另一名開發者迅速找到入口、路由、元件、服務端邏輯和設定檔。
• 依賴清單是否完整，啟動、建置、測試指令是否寫入說明文件，而不是只留在對話內容。
• 關鍵商業邏輯是否已保存為可審查的檔案；不能只存在於臨時提示、工作階段狀態或雲端執行環境的快取。
• 變更是否能以檔案差異檢查，並可說明每個新增套件、環境變數和外部服務的用途。
• 樣例密鑰、佔位身份、測試帳號和不應入庫的測試資料是否已移除。

這是 Cursor Start from Scratch 驗收最容易被忽略的分界：生成速度解決的是零到一，責任鏈解決的是一到多人維護。若你無法在沒有原始 Agent 對話的情況下說明專案如何啟動，應退回生成階段，不要先建立公開部署。

可保存的通過證據

保存一次檔案差異、依賴清單、啟動指令、環境變數範例和人工審核備註。證據不必漂亮，但必須讓接手者能重現你的判斷；若只能提供一張預覽截圖，驗收等級仍停留在展示原型。

第二階段：瀏覽器預覽對比真實功能

預覽環境適合快速查看介面和流程，但它可能掩蓋服務端、持久化資料和外部 API 的問題。請把測試拆成四層，而不是只按幾個按鈕：

至少要測試正常輸入、異常輸入、頁面重新整理和執行環境重啟。端口轉發後看見頁面，不代表資料真的保存，也不代表背景工作、權限判斷和第三方服務已通過。把建置日誌、測試結果、失敗畫面與重現步驟存下來，這些才是能否進入正式建庫的依據。

官方文件列明的能力邊界可作為核對資料：Start from Scratch 可在未連線第三方原始碼程式庫的條件下開始，Origin 文件則說明其專案流程與狀態；至於正式部署，應另外核對Vercel 的程式庫整合文件，不要把預覽部署當成你的唯一生產方案。

第三階段：建立 Origin 對比建立正式責任鏈

完成預覽後，才進入建庫和團隊接管。你需要先確認 Origin 專案的所有者、可見範圍、成員角色與 Privacy Mode，再決定誰能審核、合併、修改整合設定或觸發部署。權限問題不是行政細節：如果生成者、審核者和發布者沒有清楚分工，任何一次錯誤提交都可能缺少可追溯責任人。

接著用標準 Git 操作驗證四件事：複製、提交、推送、恢復。可參考Git 官方複製指令說明，在一個全新目錄重新取得程式碼，而不是繼續依賴原本的雲端工作階段。

首個基線版本應留下：

1. 人工審核者與審核日期。
2. 主要變更檔案和已知限制。
3. 建置、測試及安全掃描結果。
4. 使用的環境變數名稱，而非實際密鑰。
5. 回到上一個可運作版本的操作方式。

若專案只能透過 Cursor Cloud Agents 繼續修改，或新開發者無法完成複製與啟動，這不是「文件稍後補上」的小問題，而是尚未完成程式碼接管。

第四階段：CI 通過對比雲端工作階段成功

正式開發環境的核心測試，是在全新執行環境移除快取、重新安裝依賴並重新建置。你要證明成功來自程式庫中的檔案與明確設定，而不是 Agent 留下的隱藏狀態。

CI 至少應建立以下門禁：

• 格式檢查與靜態分析；
• 單元測試及主要流程測試；
• 依賴與密鑰安全掃描；
• 生產建置；
• 部署前設定檢查；
• 失敗時阻止合併或發布。

這裡要把「可重現」寫成可驗證步驟：記錄執行環境、依賴安裝結果、建置日誌、測試失敗原因與產出物雜湊；若第二次在相同設定下無法得到同等結果，就不能以一次成功作為放行證據。對 AI Coding 專案尤其如此，因為生成結果可能快速變動，人工修改也可能沒有完整留下背景。

如果目標是 iOS、macOS，或依賴 Xcode、Apple SDK、簽名憑證，瀏覽器和一般 Linux 執行器都不能代替實際 Apple 工具鏈。你需要在隔離的本地或雲端 Mac 環境執行建置、測試、簽名和產出物驗收，並對照Apple 的 Mac 簽名與發佈文件。尚未完成這一步時，只能說 Web 原型通過，不能說 Apple 平台交付通過。

第五階段：正式發布對比限量試點

發布決策不應只有「通過」或「失敗」兩個按鈕。建議將結果分成三個出口：

• 正式發布：程式碼可接管、全新環境可重建、權限可解釋、密鑰已隔離，且回滾流程已實際驗證。
• 限量試點：仍有非關鍵缺口，但資料範圍、使用者數量和權限已受控；每個缺口必須有負責人與退出條件。
• 退回修正：無法重建、密鑰混入、權限不明、資料狀態不一致，或沒有可用回滾版本。

正式發布後的第一週，不要只看訪問量。記錄失敗任務、人工修復內容、建置耗時、環境差異、外部 API 錯誤和回滾演練結果。這些運行證據能幫你判斷工作流是否值得持續採用，也能揭示哪些問題在瀏覽器預覽階段沒有出現。

Cursor Start from Scratch 驗收：最後評分與放行條件

你可以用下列五項各自評分，分數只是團隊內部的決策工具，不是 Cursor 的官方評級：

• 程式碼接管：2 分——檔案、依賴、指令和業務邏輯完整可讀。
• 功能邊界：2 分——服務端、資料保存、異常輸入和外部 API 均有證據。
• 責任鏈：2 分——Origin 所有者、權限、基線版本和提交歷史清楚。
• 可重現性：2 分——全新環境能安裝、測試、建置，CI 可阻止失敗變更。
• 發布安全：2 分——密鑰隔離、人工審核、獨立平台驗證與回滾均完成。

滿分才可考慮正式發布；缺少任何一項關鍵安全或回滾證據，就降級為限量試點。 即使總分看似足夠，只要 Apple 工具鏈尚未在獨立 Mac 驗證，iOS 或 macOS 專案仍不能宣稱已完成交付驗收。

從雲端原型移交到 Mac 的實際取捨

如果你的專案只是短期 Web 展示，本地開發機或一般 CI 執行器通常更直接；如果需要 Xcode、Apple SDK、簽名憑證或持續運行的 macOS 建置節點，單靠瀏覽器預覽會留下三個實際缺口：工具鏈不一致、簽名流程沒有被驗證，以及失敗時缺少可隔離的回退環境。

因此，準備點擊發布前，先把專案放進全新執行環境重建；涉及 Apple 平台時，再閱讀雲端 Mac 的 Xcode 持續整合部署方向及AI Coding 原型轉生產的驗收思路。若你只需要臨時算力、隔離測試環境或短期 Mac 建置節點，MacPull 的租用方案可避免先購置固定硬體；但長期穩定高負載、需要實體介面或必須完全掌控硬體的團隊，仍應比較自購 Mac 與其他執行環境後再決定。

最後更新於 2026 年 8 月 28 日；功能狀態、Origin beta 狀態、Cloud Agents 權限與整合範圍核實自 Cursor 官方更新日誌、Origin 文件及 Cloud Agents 文件。

常見問題