Base44 是以自然語言對話為核心的 AI 應用建置平台，把前端介面、資料實體、登入、後端函式、整合與託管部署集中在一個工作區。建置者先說明產品需求，再從即時預覽與管理介面檢查結果，持續調整頁面、資料、權限和流程。成品可以是公開網站、需登入的業務系統、內部營運工具、客戶入口、AI 服務，或以已發布 Web 應用為核心的行動商店套件。
一體化環境省去了大量技術選型與初始接線，卻不會自動完成產品決策。誰能看見哪筆資料、外部 API 失敗如何復原、信用額度會如何消耗、日後能否遷移，仍要由團隊定義和測試。最可靠的做法不是用一句話產生整個產品後立刻發布，而是先縮小範圍、建立一條完整流程，再逐項驗證資料、角色、整合、安全和失敗路徑。
以下內容以 2026 年 8 月 8 日可取得的官方文件及經身分核對的外部資料為基準。Base44 更新速度快，方案權益、信用額度、模型和測試功能皆應在實際購買或發布時重新確認。已宣布的收購、逐步推出的模型與少量使用者評論，不會被延伸成無條件的產品能力。
Base44 會依自然語言說明建立可執行的應用，並在受管理環境內提供 AI 對話、即時預覽和儀表板。對話可以建立頁面、資料實體、表單、權限和邏輯；預覽可走查使用流程；儀表板則管理使用者、資料、網域、日誌、安全與發布。
這個範圍超過一般靜態網站產生器。官方開發文件涵蓋資料儲存、驗證、即時更新、伺服器端函式、整合與託管，也說明外部前端可透過 JavaScript SDK 與 CLI 使用 Base44 後端。非技術團隊可由對話開始，開發者則能進一步查看程式碼或接入 GitHub。
官方快速入門展示從描述產品、產生頁面與資料，到預覽、設定權限和發布的流程。已發布應用可維護記錄、辨識使用者、執行伺服器端工作和啟動自動化，因此不是只有畫面的原型。
然而，AI 不會知道某項商業規則是否合理，也無法自行證明租戶資料一定隔離。付款、退款、重複事件、速率限制和部分失敗都要有明確設計。Base44 加快實作，產品責任、安全審查與營運責任仍屬於應用擁有者。
Wix 於 2025 年 6 月 18 日宣布完成收購 Base44，並表示後者會維持獨立產品與業務。這項已完成的公司事件，只能說明所有權與公開策略，不能推論 Wix 的任意服務、方案或基礎設施已經提供給 Base44 帳號。
2026 年 6 月的 TechCrunch 報導則描述專用模型 Base1 正在推出。逐步推出代表帳號和時間可能不同；若專案依賴該模型，應在自己的工作區確認是否可選、如何計費及實際輸出，而不是引用新聞作為普遍權益。
Default 會實際套用要求，適合條件清楚的功能變更；Discuss 用於規劃和問答，不應改動應用；Edit 則偏向選取預覽元素後調整視覺。手動與 AI 輔助編輯的信用成本可能不同，應以當下介面提示為準。
先用 Discuss 釐清實體、角色和風險，再用 Default 實作單一變更，通常比不斷追加模糊提示穩定。顏色、間距、字體等視覺問題可交由 Edit；資料與權限則要寫成能驗收的規則。
平台能建立頁面和元件，也提供即時預覽與行動檢視。審查不能只停在好看的首屏；應放入長名稱、空資料、錯誤訊息、狹窄螢幕和不同權限，檢查載入、無結果、驗證失敗與無權限狀態。
若產品要支援多語內容，還要用正式文字驗證導航和表單。佔位資料上的整齊卡片，不足以代表真實資料量和各種邊界值下仍然可用。
Base44 提供受管理的資料實體與記錄介面，AI 可新增欄位並把表單、清單和檢視接到資料。官方開發說明也涵蓋彈性的資料層、即時訂閱與實體安全規則。
設計時應先定義穩定的業務實體、擁有者、組織關係和允許狀態。登入只確認身分，授權才決定可讀寫的範圍。多租戶應用必須用不同組織的測試帳號嘗試越界；隱藏按鈕不是資料保護。
符合方案的工作區可使用後端函式處理敏感 API、Webhook、付款確認或需要密鑰的工作。憑證應放入平台的秘密管理功能，不能寫在前端、一般資料欄位或聊天提示裡。
整合可包含內建動作、授權連接器，以及從 OpenAPI 規格匯入的工作區自訂整合。每個連線都應記錄帳號、範圍、過期方式和失敗策略，也要測試分頁、限流、重複事件與部分完成。
官方文件指出，從 2026 年 7 月 6 日起建立的應用使用 Workflows，舊應用可能仍是 Automations，而且一個應用只會有其中一套。Workflows 可由排程、資料變化、應用內 Agent 或連接器事件啟動，串接步驟、條件和延遲，並顯示每次執行進度。
因此，舊文章中的操作位置未必適用新專案。新流程要避免自己觸發自己，對外部副作用保存冪等識別；舊專案則先確認目前儀表板實際提供哪一套系統。
應用會取得 Base44 託管網址，可從編輯器發布；符合方案時可接自訂網域並由平台處理 HTTPS。另一種做法是把外部前端留在自選主機，只使用 Base44 的後端能力。
發布前仍要確認版本、角色測試、安全掃描、密鑰、重要整合和回復方式。資料模型變更應用既有資料測試，發布後也應以全新一般使用者身分重新走過流程。
官方文件把 ZIP 下載和 GitHub 連線列為 Builder 或更高方案能力。GitHub 工作流程支援雙向同步、本機開發、分支和拉取請求；平台另有程式碼檢視、CLI 與 JavaScript SDK。
匯出程式碼和資料集合並不會把受管理的登入、資料庫和託管完整複製成自架服務。真正的退出計畫要盤點身分、資料、檔案、函式、整合、工作流程和網域，不能只確認有一個下載按鈕。
文件說明可用行動瀏覽器，以及官方 iOS、Android 建置器應用管理專案；發布後的應用可在行動瀏覽器執行或加入主畫面。某些網域和安全管理仍可能需要桌面操作。
商店提交所產生的是包住已發布 Web 應用的 web-view，不是原生重寫。現階段沒有原生推播與完整離線模式。Apple、Google 開發者帳號、商店頁面、隱私揭露及審核回覆仍由擁有者承擔。
創辦人可先建置含登入、表單、記錄和一個關鍵動作的應用，觀察真實使用者能否完成流程。第一版的目的應是驗證假設，而非一次複製成熟產品的全部功能。
先維持小範圍也有助於理解信用消耗和修改成本。推薦或媒合功能可由可稽核規則及人工流程開始，待需求成立再增加 AI 和自動化。
庫存、入職、問題清單、服務佇列和審批記錄可由資料實體、角色和 Workflows 組成。接入前要決定 Base44 是資料來源，還是其他系統的鏡像，並規定同步衝突和失敗由誰處理。
內部不代表低風險。員工、客戶和財務資料仍須權限、保留期限和稽核紀錄。涉及金錢或客戶狀態的自動步驟，應保留人工核對畫面。
登入與角色可支援客戶查訂單、傳文件或追蹤案件。公開網站在還需要個人化、搜尋資料或表單後端時也適合使用 Base44。純內容網站則應同時比較 CMS 的編輯、SEO、重新導向與可及性流程。
儀表板要先定義指標、來源欄位、時區和缺值規則，並與來源系統對帳。漂亮的圖表不會自行保證資料正確；必須用接近正式規模的資料測試查詢與分頁。
內建 AI 動作與外部模型整合可支援文件處理、研究助手或內容工具。模型輸出應與已驗證資料分開，重要權限、退款或記錄覆寫需要確定性檢查和人工核准。
工作流程可以在新線索、行事曆事件或排程後執行多步驟。要保存外部識別碼，讓重試不會重複寄信、開單或扣款；部分失敗必須有可追蹤的處理方式。
列出目標使用者、主要問題、唯一關鍵旅程、資料欄位、角色、敏感資訊、整合、預期規模和第一版不做的事項。與其說「建立現代化入口」，不如描述誰在什麼條件下能進行哪個動作，以及必須留下什麼紀錄。
請 AI 提出實體、關係、角色、失敗情境和未決事項，不立即修改專案。逐一修正假設，並要求解釋租戶欄位、Webhook 驗證或資料分離等決策。這能減少後續重做。
先完成註冊、建立記錄、正確角色檢視並執行一個核心動作。產生後應刷新頁面、重新登入，確認欄位、驗證、資料保存和角色限制，而非立刻增加所有報表和整合。
逐一測試新增、讀取、修改和刪除。將第三方憑據移到密鑰功能，確保敏感操作在後端。執行官方安全掃描並人工審查，不要假設所有建議會自動套用。
確認連線帳號與授權範圍，測試成功、失敗、重複和逾時。為 Workflows 寫下觸發器、每個步驟、條件、延遲、終態與冪等鍵，並建立失敗後的重跑或對帳方式。
加入長文字、空值、特殊字元和邊界數字，在不同螢幕和角色下檢查導覽、焦點、錯誤和慢操作。商店發布前先把 Web 流程測好，因為包裝不會改善網頁本身。
匯出重要資料和程式碼，保留已審版本，記錄方案與整合，確認網域和安全掃描。先讓少數人使用，觀察失敗函式、流程執行和信用額度，再把回饋拆成可驗證的小變更。
明確指定角色、條件、狀態和稽核欄位，避免只指定頁面名稱。功能與視覺提示分開，先證明資料與權限正確，再處理排版和品牌樣式。
一次只做一項實質改動。身份、資料、付款和全面改版不應綁在同一請求。另存變更記錄，包含需求、提示、受影響實體、測試結果和發布時間。
消息信用和整合信用分開計算。先討論再執行、儘早過濾不相關事件、在合約允許時批次處理，能降低浪費。估算時要包含維護和排程，不只算首次生成。
讓授權過期、服務斷線、事件重複、必填資料缺失，確認錯誤可理解且營運者能恢復。持續記錄實體、函式、密鑰、網域和身份假設，並在方案允許時使用 GitHub、ZIP 和資料匯出。
優先檢查接受外部輸入、處理身分、使用服務角色、付款和 Webhook 的程式碼。官方掃描可找出常見問題，卻不是形式化安全證明；敏感專案需要符合風險的獨立評估。
能清楚描述流程和驗收標準，但希望快速驗證互動產品的非技術創辦人很適合。產品與設計團隊可產生含真實資料和角色的功能原型；營運團隊可把零散表格整理為專用系統。
開發者可利用受管理後端和快速 UI，再透過程式碼、GitHub、CLI、SDK 延伸。代理商應在交付前釐清工作區、帳單、網域、資料和維護權責。
若需要完整離線、深度原生體驗、自架基礎設施、特殊資料庫保證、完全自訂登入或獨立稽核的受監管控制，應先評估其他基礎。Base44 可作為原型，但不應在架構決策前累積難以搬移的資料。
主要編輯器在 Web 上運作，已發布應用可在桌面與行動瀏覽器使用。官方另提供 iOS 與 Android 建置器應用；部分安全和網域工作仍需桌面介面。
符合方案時可使用程式碼檢視、GitHub、ZIP、CLI 和 JavaScript SDK。商店提交可產生 IPA 與 AAB，但只是 web-view 套件，不能宣稱擁有未文件化的原生能力。
現行官方帳務文件列出這五個自助層級。本文不複製價格與精確配額，因為權益可能改變。購買時應重新確認應用限制、訊息和整合信用、GitHub、網域、後端與商店功能。
AI 建置互動使用訊息信用，整合與自動化使用整合信用；模型和動作會影響消耗。長期預算也要納入外部 API、網域、商店帳號、迭代與維護。
若必要能力只存在於某層級，單看額度沒有意義。先列出不可妥協的生產需求，再逐項對照當下的官方方案表和結帳流程。
三者同樣可用 AI 加速軟體建立，但在程式碼可見度、後端選擇、部署與遷移責任上不同。應以一個代表性功能比較，而不是只看首次產生速度。
Softr 偏向入口與內部工具；Retool 和 Power Apps 更強調企業連接器和治理。已有企業生態或管理要求的團隊，可能更適合這些較結構化的選擇。
自訂技術棧投入較高，卻能完整控制資料庫、執行環境與部署。深度原生、受監管或特殊效能專案通常需要這種可控性。
Product Hunt 與 G2 有褒貶不同的自選評論；截至查閱時，G2 只有 4 則、Capterra 只有 3 則。這些內容可以轉化為試用問題，不能成為普遍可靠性或品質分數。
安全掃描會檢查權限、憑據、登入、套件弱點和瀏覽器標頭，但官方把最終審查責任交給應用擁有者。資料預設儲存在美國，符合方案與建立日期條件的歐盟或英國選項正在逐步推出，而且儲存地與處理地不同；敏感資料必須依最新文件與合約評估。
程式碼與集合資料可在符合條件時匯出，受管理的身份、資料庫和託管不會自動成為自架替代品。遷移會涉及帳號、資料、檔案、整合與工作流程。
商店包目前沒有原生推播或完整離線，完整自訂登入與完全白標的內建登入畫面也未受到支援。文件中「規劃」「逐步推出」的項目都不是現有一般權益。
資料形狀、查詢、整合和流量會改變效能。應以真實角色、資料量和最難介面做試點，對關鍵業務向供應商確認限制、地區與回應承諾。
可以，官方文件涵蓋介面、資料、驗證、後端函式、整合、流程和託管。是否達到正式環境標準，仍取決於權限、測試、成本與營運設計。
基本建置可透過聊天與視覺編輯完成。資料、安全、複雜整合與遷移會需要技術判斷；開發者也可使用程式碼、GitHub、CLI 和 SDK。
目前文件列出 Free，另有 Starter、Builder、Pro、Elite。權益與配額會更新，應查看即時方案表，不採用舊截圖作決策。
前者用於 AI 建置與修改，後者用於外部服務和自動流程。實際消耗取決於模型與動作，應以工作區的用量記錄為準。
符合方案時可使用 ZIP、GitHub 與資料匯出，但受管理身份、資料庫和主機不會隨之變成自架環境。完整遷移要另行規劃。
符合資格時可掃描商店準備度並產生提交包。擁有者仍需自己的開發者帳號並處理審核；套件是 Web 包裝，目前無原生推播和完整離線。
設定正確可見度與實體權限，密鑰放在安全設施，執行掃描，再用每個角色的帳號嘗試越權。高風險專案需要額外的獨立安全及合規審查。
官方文件有說明，但會受方案和工作區條件限制。自訂網域由平台管理 HTTPS，GitHub 可支援版本控制與本機協作；採購前要確認當前資格。
它們是新舊兩代自動化。2026 年 7 月 6 日以後建立的應用使用 Workflows，較早應用可能仍保留 Automations，而且一個應用不會同時使用兩者。
若產品符合受管理平台的邊界，並已驗證權限、可靠性、費用、可攜性與支援，可以作為正式基礎。若完整基礎設施控制、深度原生行動、特殊規模保證或監管部署不可妥協，應選擇更可控的架構。
