TL;DR

Q: 真的能用 Vibe Coding 把 App 做到上架嗎？
A: 做到了。不過如果條件是「商用、且要安全」，我覺得對非工程師來說，現在還是很吃力。

• 我從零開始獨立開發了一款 AI 英語學習 App，並成功在 Web 與 iOS App Store 雙平台上架
• AI 可以取代「寫程式碼」，但無法取代「該檢查什麼」的判斷
• 最難的不是程式碼，而是資安、領域知識、資料設計與除錯能力

AI 與 Vibe Coding 的時代

自從 ChatGPT 出現後，已經過了幾年，像 Cursor、Claude Code 這類專注於程式開發的 AI 工具逐漸普及，「就算不會寫程式，也能做 App」的說法也開始流行。X 的時間軸上，也幾乎每週都會看到只靠 AI 做出 SaaS、達成每月經常性收入（MRR）幾萬元的貼文。

Vibe Coding 這個詞也漸漸固定下來了。意思就是「靠感覺寫程式」，也就是在 AI 的協助下，自己不太理解程式內容，邊下指令邊把 App 做出來的方式。

這絕不是要否定 Vibe Coding。AI 讓開發門檻下降，讓更多人能把想法做成產品，我認為這是非常棒的事。
而且，這也絕對不是在帶風向。

這次我實際在個人開發中使用 Claude Code，真的把 App 做到上架；在過程中，我也切身感受到：非工程師到底能不能真的把 App 上架？我想把我現在最真實的想法寫下來。

關於我，以及我做了什麼

我原本就有 AWS 基礎架構建置經驗，也能寫一些簡單的 JS，算是工程師。這次才第一次比較正式地接觸 TypeScript 和 Next.js。

這次我使用 Claude Code，從 0 開始打造了名為 Engy 的 AI 英語學習 Web App，並上架到 Web 與 Apple App Store。

Engy 是什麼

這是一個運用 AI 的英語四技能學習平台，主要功能如下：

• AI Speaking：與 Bedrock AgentCore（語音 AI）即時練習英文對話，並自動產生對話內容與表達方式的回饋
• AI Writing：由 Amazon Bedrock 批改英文作文
• Grammar / Vocabulary：文法測驗與字彙學習卡
• Listening / Reading：長篇閱讀與聽力題目

基礎架構是完全 AWS 無伺服器化（Lambda + DynamoDB + Cognito + CloudFront + Bedrock AgentCore），Web 端付費透過 Stripe，iOS 端透過 Apple IAP（RevenueCat），行動版則使用 Capacitor 打包成 iOS App 並上架到 App Store。

如果有興趣，歡迎試用看看。

• Web: engy.academy
• iOS: App Store

老實說，我覺得非工程師會很吃力

先說明一下，這次我沒有使用 Vercel、Firebase、Supabase、Replit Agent 這種「只要輸入點子就會一路幫你部署到完成」的服務。若有使用那些工具，情況可能會不一樣。

不過在維持實務等級的資安，同時以商用服務形式上架這個條件下，我覺得現階段對非工程師來說仍然很難。以下我具體說明原因。

1. 資安與收費：「因為不懂，所以很可怕」

資安：不知道自己是否已經完整涵蓋的恐懼

我因為有工程師經驗，所以看到「IAM 最小權限已經設定、JWT 驗證有做、Webhook 有做簽章驗證、WAF 也加上了」這種狀態時，可以判斷「至少基本盤有顧到」。這種感覺來自經驗，很難用系統化方式完整說明。（即使如此，心裡還是會想：如果被攻擊而出事怎麼辦……）

對非工程師的 Vibe Coder 來說，會缺少這條 「做到哪裡才算安全」的基準線。

最近因攻擊而導致個資外洩，或是把 API Key 誤提交到 GitHub、進而被濫用的新聞越來越多。這些往往不是「因為沒知識才發生」，而是「因為不知道問題是什麼，所以沒察覺」所導致的事故。即使 AI 幫你寫程式，也可能產生不小心含有資安問題的程式。AI 擅長的是「寫出能動的程式」，但要「全面指出程式裡潛藏的風險」，那是另一回事。

在一知半解的情況下按下上線按鈕，連工程師都會怕。反過來說，隨著你一步步搭建系統、累積知識，了解得越多，越會看見風險，最後也會跟工程師一樣開始害怕。

雲端計費：在真正使用之前的「莫名恐懼」

Engy 使用的 AWS 服務幾乎都是無伺服器按量計費。Lambda、DynamoDB、API Gateway 只有真的有請求進來時才會產生費用。沒人使用時幾乎是 0 元，就算流量暴增，也可以透過上限設定控制住。因為我知道這些，所以能安心使用。

但對不熟 AWS 的人來說，雲端總會讓人覺得：「如果一直開著，會不會收到很高的帳單？」「萬一哪裡設定錯了，費用會不會無上限？」這種不安其實很常見。網路上也真的找得到因設定錯誤而產生數百萬日圓帳單的案例。

在不清楚「哪個服務會花多少錢」的情況下往前走，會很難。這也是建立在工程師知識上的前提。

2. 自己不知道的東西，沒辦法從 AI Agent 裡主動挖出來

你可能會說：「可是資安和成本，AI 也可以幫你教啊，那就連這些都不用擔心了吧？」如果預算夠，也許可以。但 Vibe Coding 還有一個很大的難點，我想再談一次。

假設你對 AI 說：「資安沒問題嗎？全部幫我確認一下。」AI 會回你一些答案。然而系統規模越大，要判斷這些答案是否真的完整，最終還是取決於下指令的人的知識量。

AI 的表現，和輸入品質成正比。到了 Coding Agent 的時代，這件事仍然沒有改變。

舉個例子。若要系統性檢查 AWS 的安全設定是否合理，可以使用 AWS Security Hub。它會依照 CIS 基準與 AWS 最佳實踐，自動找出設定問題。知道這個工具的人，就能指示 AI：「請用 Security Hub 幫我確認。」不知道的人，則很難從 AI 身上把 Security Hub「問」出來。

成本面也是一樣。Bedrock 有一個叫做 Prompt Caching 的功能，當你反覆送出同一個提示詞的前半段時，可以利用快取降低 API 成本。知道這個功能的人，就能要求 AI：「請實作 Prompt Caching。」但如果你根本不知道它存在，就不會有「要用它」的想法。

同樣地：

• 滲透測試
• SAST
• DAST

這些都是「知道了就能用」的工具或方法；但如果你連這些詞都不知道，就連去問 AI 的契機都不會出現。Coding Agent 通常會優先處理「把功能做出來」。沒有寫進提示詞的審查與驗證，往往就會被往後擺。

沒有知識，就問不出「正確的問題」

這不只適用於 AI。你找工程師幫忙時也是一樣，如果只說「資安麻煩幫我處理」，通常很難精準傳達你要他檢查什麼。不過工程師會根據經驗去解讀：「你是指認證流程嗎？還是傳輸加密？」AI 目前還沒辦法像人類工程師那樣可靠地補完這種上下文。

我認為，Vibe Coding 能做出來的 App 品質上限，取決於下指令的人有多少知識。AI 可以代替你寫程式碼，但無法代替你判斷要做什麼、要檢查什麼。

另外，如果你一路都在一邊做一邊問 AI，成本也不能忽視。Claude Code 的 MAX 方案每月要 200 美元，在還沒賺到錢的情況下持續投入這筆費用，壓力其實不小。

3. 實際踩過的坑，以及應該注意的點

接下來我會列出在 App 上架過程中，實際遇到的卡關點，以及我認為 Vibe Coder 應該特別注意的地方。

AWS 的資安基本設定

在開始使用 AWS 之前，建議先看像是 AWS 中的資安基本概念 這類文章，先掌握應該設定哪些項目。

不需要一開始就全部做完，但如果要作為商用服務運營，能做的最好都做。只是資安強化與成本之間有些地方本來就存在取捨，所以還是得一邊評估優先順序一邊推進。

這次我做了以下設定：

• 最小權限原則：每個 Lambda 的 IAM Role 只給該函式真正需要的權限。IAM Identity Center 的使用者也一樣，只分配符合操作內容的最低權限集合
• 保護 Root 使用者：日常操作禁止使用 Root，並設定 MFA（多重要素驗證）
• AWS Organizations 與 IAM Identity Center：用多帳戶方式分開管理測試環境與正式環境
• SCP（Service Control Policy）：例如限制只能在特定區域建立資源，從組織層級限制操作
• WAF 等安全服務：在 CloudFront 上套用 WAF 做存取控制

AWS 的成本基本設定

和資安一樣，成本管理的基本設定也應該一開始就先完成。AWS 是按量計費，若有設定錯誤或預期外的流量暴增，等到發現時帳單可能已經很可觀了。

這次我做了以下設定：

• 選擇按量計費服務：Bedrock、API Gateway、DynamoDB（On-Demand 模式）、Lambda 在沒有請求時幾乎不會產生成本。S3 與 CloudFront 也屬於依儲存量與傳輸量計費，適合初期小規模階段把成本壓低
• AWS Budgets：設定月預算，超過門檻時寄信通知
• Cost Anomaly Detection：根據過往使用模式，自動偵測異常的成本增加
• API Gateway Throttling：設定速率限制，避免暴衝或惡意請求造成過度計費
• Lambda 同時執行數限制：為了防止突發流量讓費用失控，替每個函式設定上限
• Bedrock Prompt Caching：當重複送出相同提示詞前半段時，透過快取降低 API 成本

Bedrock 的區域與配額

這次 Speaking 使用 Amazon Nova Sonic，Writing 使用 Nova Pro，但這兩個模型在東京區域的預設配額都非常小。新帳號的情況下，同時連線數可能只被分配到 Nova Sonic 1、Nova Pro 10 左右。即使提出提高配額的申請，如果帳號沒有使用實績，也常常不會通過，只能先累積使用紀錄。不了解這點就直接設計架構，後面卡住是很典型的坑。模型選型要和區域、配額一起確認，這是我這次最大的學習之一。

DynamoDB 的資料設計

DynamoDB 和關聯式資料庫（RDB）的設計思維根本不同。RDB 可以先隨便建表，再慢慢想查詢；但 DynamoDB 需要一開始就決定 Partition Key 和 Sort Key，之後要改幾乎等於整張表重做。

這次隨著功能增加，表也越來越多。像是課金生命週期管理（訂閱狀態、更新日期、方案變更紀錄）、AI 功能的每月使用次數重置、Speaking/Writing 各自的使用紀錄等，都有不少是後來才想到「這個資料需要存」而追加的。若能先整理好存取模式，表設計其實可以更乾淨。

在 Vibe Coding 時，如果太優先追求「先動起來」，資料設計很容易被往後擺。但不只 DynamoDB，資料模型本來就是後改成本很高的東西。最好在建立資料表前，先把需要哪些查詢完整想過一輪。

Cognito × Apple Sign In 的坑

我在 Cognito 實作 Apple Sign In 時，一度連正式環境在內都得把 User Pool 重建一次。

我把 Cognito 的 email 屬性設成 mutable: false，但 Apple Sign In 在第二次之後登入時，會從 IdP 再次送出屬性。這時 Cognito 會判定「這個 email 屬性不能更新」，導致第二次以後的 Apple 登入失敗。

Cognito 的 User Pool Schema 設定在建立後無法修改。 你想把 mutable: false 改成 true，AWS CLI 和 CDK 都會報錯。再加上 Apple Sign In 的規格就是只在首次認證時才送使用者資訊，如果事先不知道也很容易踩雷。第二次以後只會送 ID Token 的 claims。若要在該 ID Token 中包含 email claim，就必須在 Apple IdP 的 scope 中加上 email；但 CDK 預設只有 name。scope 不夠時，ID Token 內就不會有 email，而 email: required: true 的 User Pool 便會在第二次登入時擋下來。這也是無法事後修改、只能重建的設定。

一旦重建 User Pool，AgentCore Runtime 的 JWT 驗證設定、API Gateway 的 authorizer、iOS App 的 Pool ID / Client ID 全都要重做，影響會一路擴散。和 DynamoDB 一樣，最初設計判斷一旦錯了，後面修正成本會暴增。

框架的限制

Next.js 大致有兩種運作方式。靜態匯出（Static Export）是把 HTML/CSS/JS 在建置時產生好，放到 S3 就能運作。因為不需要伺服器，所以成本低，也可以透過 CloudFront 發佈。另一方面，伺服器模式（SSR）則是在每次請求時由伺服器動態產生 HTML，因此可以依照使用者顯示不同內容，也能為 SEO 動態產生 meta tag。電商網站或新聞媒體比較適合這種方式。

這次我選擇把網站以 S3 + CloudFront 的靜態方式部署。因為使用者個人資料會在登入後再透過 API 取得，所以靜態匯出就已經足夠。不過這也代表 Next.js 內建的 API 功能（Route Handlers）無法使用，後端全部都得另外用 Lambda 實作。

而且這個選擇之後若要改，幾乎等於整個託管架構都要一起換。如果未來想「每個頁面動態產生 OGP，方便在社群分享」，或「回傳對搜尋引擎友善的動態內容」，從 Static Export 轉到 SSR 會需要相當的工時。最初就先思考 SEO 和伺服器功能要用到什麼程度，之後選擇會更寬裕。

行動版對應方針

要以 iOS App 形式上架，通常會在 Capacitor、React Native、Swift（原生）之間做選擇。這也是一個一旦選下去，之後幾乎等於重寫全部的決定。

老實說，這次我一開始並沒有打算直接上 App Store。原本只是一路用 Next.js 做 Web App，後來才剛好知道可以用 Capacitor 直接包成 iOS App，於是後續才補上這部分。結果是成功了，但如果一開始就是以 mobile-first 設計，可能會選別的方案。

選擇標準其實很簡單：你想和 Web 共用多少程式碼。

如果一開始就有要往行動裝置延伸的計畫，這個方向最好和 Web 技術選型一起決定。我這次用 Capacitor，基本上沒有感受到太大的落差。

4. 程式碼以外的世界：領域知識

比我預期多很多的工作，其實都不是寫程式本身。尤其是 App Store、法規要求、領域知識、收費相關，真的應該提早處理。

Apple App Store 申請

要以 iOS App 上架，除了程式碼以外，還有大量額外工作。而且其中很多都需要 Apple 生態系專屬知識，門檻其實不低。

Xcode 只能在 Mac 上跑，所以編譯環境需要 Mac。這次我用 GitHub Actions 的 macOS runner 來自動化建置，因此即使手邊沒有 Mac 也能處理。不過那套設定本身也花了不少工夫。實機測試則還需要 iPhone。

另外還有：

• 憑證與 Provisioning Profile 管理 — Apple 的簽章流程很獨特，若過期或設定錯誤，建置就會失敗
• 上傳二進位檔到 App Store Connect — 可透過 Xcode 或 altool / xcrun 上傳，步驟相當複雜
• Apple IAP（App 內購） — 若要在 iOS 提供付費功能，除了 Web 上的 Stripe，還必須另外實作 Apple IAP（In-App Purchase）。即使使用 RevenueCat 這類 SDK，購買流程、購買還原、透過 Webhook 同步購買狀態到資料庫等，還是有不少工作要做，工時相當可觀。此外，還得在 App Store Connect 登錄 IAP 商品並提出審查申請，並在隱私標籤中申報資料用途
• Apple 審查 — 有自己的一套審查標準，被退件並不罕見。這次我也因為「隱私標籤申報內容不正確」、「App 說明沒有充分附上使用條款連結」而被退回。每次退件都必須重新提交、重新審查
• 加入 Apple Developer Program — 年費 99 美元。從申請、審查到正式公開，通常要幾天到一週以上

法律文件

要推出有收費功能的服務，除了程式之外，還需要以下文件：

• 隱私權政策 — 個資處理方針，也是 App Store 審查的必要項目
• 服務條款 — 服務使用規範，也與發生爭議時的免責有關
• 特定商業交易法標示 — 在日本提供付費服務時的法定要求，需要記載營運者資訊、價格、取消方式等內容

這些文件可以讓 AI 先產出草稿，但內容是否符合自己的服務、是否有法律問題，仍然必須自己確認。若之後才發現標示不完整，會影響信任。

網域取得

服務名稱決定後，最好儘早把網域買下來。等開發到一半才發現「那個網域已經被註冊了」，就會被迫連服務名稱一起重想。

想要的 TLD 常常早就被註冊光了。現在 .ai 在 AI 相關服務裡很熱門，但年費也可能高達數萬日圓，應該要先把這筆初期成本算進去。Engy 選的是 .academy，不同 TLD 也會影響品牌給人的印象。

另外，從取得網域後開始，還會有 Cognito、CloudFront、寄信服務（SES）等的自訂網域設定要做。若之後才換網域，這些設定都得重來，所以越早決定越輕鬆。

收費生命週期

要做訂閱制收費，首先得理解 SaaS 的收費模式本身。看似只是「加入月費方案，下一個月自動續訂」的簡單流程，背後其實藏著很多狀態轉換。

• 方案升級／降級（是立即生效，還是下次續訂時生效）
• 付款失敗時的重試，以及持續失敗後是否停用帳號
• 取消訂閱（是立刻停止，還是使用到當期結束）
• 退款與按比例計費（pro-rate）

這些都會以 Webhook 事件通知，但要如何針對每種事件更新資料庫欄位，還是得自己設計。只對 AI 說「幫我接 Stripe webhook」的話，很難期待它正確涵蓋所有這些狀態轉換。

收費設計是 SaaS 的根本，這裡若出錯，會直接造成「明明取消了還被扣款」「方案變更沒有生效」之類的使用者問題。比起先寫程式，先把自己的收費規則用文字清楚定義出來更重要。

5. 除錯：分辨「為什麼沒有動起來」的能力

AI 很擅長產生程式碼，但要找出「為什麼不能動」則是另一回事。像這種無伺服器架構，請求會經過 CloudFront → API Gateway → Lambda → DynamoDB 等多層，所以即使症狀都叫做「API 沒回應」，原因也可能完全不同：

• CORS 的 Origin 標頭不對（API Gateway 設定）
• Cognito Token 過期了（認證層）
• Lambda 的 IAM 權限不夠（執行權限）
• DynamoDB 的表名在不同環境（dev / prod）不一樣（設定錯誤）
• CloudFront 快取還是舊的（CDN 層）

要確認「到底卡在哪一層」，可以看瀏覽器 DevTools 的 Network 分頁，也可以到 AWS Console 查看 API Gateway、Lambda 的指標與日誌。CORS 錯誤不會出現在 Lambda 日誌裡，只能在瀏覽器端看到；而有些錯誤根本沒到 Lambda，只會出現在 AWS Console。要能切分問題，最好同時準備多種手段。

另外，根本沒有把必要的日誌打開 也是常見問題。API Gateway 的 Access Log 預設是關閉的，不啟用就不會記錄請求。Vibe Coding 一路把功能堆上去，如果把日誌設定拖到最後，本機或正式環境出問題時就會完全沒有線索。

6. 對 AI 做出來的東西「負責理解」的責任

Vibe Coding 很容易掉進一個陷阱：做出一套「能動，但自己說不清楚」的系統。你不一定要一行一行都看懂，但至少要掌握到「它是怎麼運作的」這個層級。

例如：

• 認證是透過什麼機制實現的？Token 在哪裡驗證？
• 使用者的請求會依序經過哪些服務？
• 收費狀態放在哪裡？什麼條件會觸發更新？
• 出問題時，要看哪裡才知道原因？

如果在完全答不出來的狀態下就上線，之後出問題時你就只能一直依賴「問 AI 看看能不能解決」。但 AI 也有極限，尤其當 session 中斷、上下文消失後，要精準掌握狀況並下對指令，最後還是得靠人。

所謂「理解 AI 做出來的東西」，不是指你要把程式逐行背起來，而是要能用自己的話說明系統結構、資料流向、判斷依據。如果做不到，每次加功能時你都會越來越搞不清楚「和前一版到底差在哪裡」，技術負債就會一直累積。

實務上很有用的方法，是把設計意圖與「為什麼這樣做」記錄到檔案裡。當 AI session 中斷、上下文遺失時，只要文件還在，就能更順利地接續下去。把專案方針、限制條件、決策結果寫進 .md 裡，新 session 也比較容易維持一致行為。把「理解」和「留下紀錄」一起做，會比較好。

結論：「寫程式的能力」不如「決定要做什麼、要確認什麼」的能力重要

AI 可以寫程式，這真的很厲害，也確實大幅提升了工程師的開發速度。就連我這次也是，第一次比較正式地使用 TypeScript 和 React，卻仍然成功把一套 AWS 全無伺服器架構系統做出來，並完成 Web 與 App Store 上架。

但 Vibe Coding 無法跨過的是判斷與責任。

• 這個服務能不能用這個方案？
• 這樣的資安設計真的夠嗎？
• 這裡如果妥協，之後會變成什麼樣子？

AI 會把這些問題的「答案」端給你，但最後能不能判斷這是不是對你的系統正確的決策，終究還是只有人能做。

完全非工程師如果先用 Vercel、Firebase 這類簡化工具做出原型，我覺得是可行的。但如果要以商用服務形式、安全地、可擴充地，並且整合收費後正式上線，我仍然覺得需要對基礎架構、資安與領域知識有一定理解。

這裡所說的「理解」，不是指你要把某個服務的用法研究得很深，而是要理解：有哪些攻擊手法、系統是怎麼運作的、脆弱點通常會出現在哪裡——這類系統性的概念。個別服務怎麼用，可以透過 AI 補；但「要注意什麼」這種視角，AI 不會自動幫你長出來。

寫程式的能力可以由 AI 代替。也因此，理解 AI 生成的程式碼的能力，以及判斷要做什麼、要檢查什麼的能力，才是我這次實作後真正感受到被要求的技能。

最後感謝你讀到這裡。

這次介紹的 Engy，是一款運用 AI 的英語四技能學習 App。它把 AI 即時英會話練習（AI Speaking）、英文作文自動批改（AI Writing）、文法測驗與字彙學習等功能整合在一起，讓日常英語學習可以集中在同一個 App 裡。Web 瀏覽器與 iOS App 都可以使用。

從免費方案就能開始試用，如果你對英語學習有興趣，或想實際跟 AI 對話看看，歡迎試試。也很歡迎你分享使用心得，或告訴我希望改進的地方。

• Web: engy.academy
• iOS: App Store

原文出處：https://qiita.com/yutaka_kozuka/items/cc3be5930b972130885d