沒有程式背景的人，可以用 AI 做出含會員登入、資料庫與外部服務串接的完整網站，但要預期會卡關，並先想好卡關時的規則。我訪談的這位需求分析師，約花一個月，九成以上的開發工作靠與 AI 對話完成，做出一個塔羅占星網站。過程中他遇到三個大問題：同一個錯誤修不好、手機版跑版、AI 為了修一個功能改壞其他地方。這篇文章整理他各自怎麼處理，並對照 Anthropic 的 Claude Code 官方文件，看哪些做法與官方建議一致、哪些不同。
他做出了什麼網站？
受訪者做出的塔羅占星網站，有 Google 登入、抽牌動畫、AI 牌卡解析、星盤計算、每日占卜，以及桌機與手機自動適應的介面。
這位受訪者的本行，是把使用者需求寫成規格文件、流程圖與功能說明，讓工程團隊照著開發。他沒有前後端實作經驗，也不是所謂的 AI 原生世代。市場開始討論 AI 可能取代部分職務時，他選擇主動學習，先從自動化工作上的繁瑣任務練習，成功做出幾個作品後，才挑戰完整產品。
網站涉及前端、後端、資料庫、第三方登入與外部 API 串接，網址是 gatabar.online。
上圖是每日抽牌畫面，左側是抽到的牌與解讀文字，右側是使用紀錄與功能選單。
牌卡的排列會依占卜模式而不同，上圖是名為事業金字塔的牌陣。書稿圖說稱這個成果為原型，受訪者自己稱為最小可行產品（MVP）。本文只依畫面確認網站具備每日抽牌、會員與 AI 解析，沒有使用者人數或營運數據。
AI 一直修不好同一個問題，要怎麼辦？
同一個問題嘗試三次仍修不好，就停止修補：換高階模型、開新對話，或直接重構該模組。這是受訪者的個人規則，Anthropic 官方建議的門檻是兩次。
受訪者的第一個大困難不在功能設計，而在環境建置與部署。套件安裝、版本衝突、NPM 指令、專案結構，對沒有前後端經驗的人都是阻礙，他多次卡在本地環境設定，一度懷疑是否該放棄。後來他訂下一條規則：同一問題嘗試三次仍無法解決，就停損。他發現與其在錯誤的基礎上反覆修補，不如重來，效率反而更高。
Anthropic 的 Claude Code 官方文件給了相近的建議，細節有差異（Anthropic，Claude Code Best practices）。
| 比較項目 | 受訪者的做法 | Anthropic 官方文件 |
|---|---|---|
| 停損門檻 | 同一問題嘗試三次 | 在同一個對話裡對同一問題修正超過兩次，就視為上下文已被失敗的做法佔滿 |
| 停損後的動作 | 換高階模型、開新對話、重構模組，並檢查上次的指令能不能拆得更細 | 清空上下文（/clear），用更具體、包含已學到內容的提示重新開始 |
| 為什麼重來 | 在錯誤基礎上修補，不如重來 | 官方稱乾淨的對話加上更好的提示，通常勝過累積多次修正的長對話 |
| 保存可回復的版本 | 隨時使用版本回溯 | Checkpoints 可還原程式碼與對話，但不追蹤 Bash 指令造成的檔案變更，也不能取代 git（Anthropic，Checkpointing 文件） |
三次或兩次，都只是經驗法則，重點是事先決定好停損點，避免當下越修越投入。受訪者沒有說明他選三次的依據，也沒有說明三次是否適用所有專案，本文不把它當成通則。
額度有限時，手機版跑版要怎麼分工模型？
受訪者先用一般模型挑出跑版相關的樣式檔，再讓高階模型只分析這些檔案找出原因，最後由一般模型套回專案，用較少額度解決問題。
第二個困難是桌機版正常、手機版嚴重跑版，原因是 CSS 的層級錯誤。他一開始用 Claude Sonnet 4.6 修，多次嘗試仍找不到問題。他訂閱的是每月 20 美元等級的方案，若直接讓 Claude Opus 4.6 分析整個專案，單日的 token 額度會先用完，任務做不完。
token 是 AI 計算輸入與輸出內容的單位，也是計費與額度的基礎；模型越高階，每個 token 通常越貴。受訪者因此設計出三步分工。
| 步驟 | 誰做 | 做什麼 | 目的 |
|---|---|---|---|
| 1 | 一般模型（Sonnet） | 從整個專案中挑出與跑版相關的樣式檔 | 讓需要分析的範圍變小，不必處理無關檔案 |
| 2 | 高階模型（Opus） | 只分析被挑出的檔案，找出關鍵問題並提出解法 | 把高階模型的額度花在最需要推理的地方 |
| 3 | 一般模型（Sonnet） | 把修好的樣式套回專案 | 套用修改不需要高階推理 |
縮小範圍再交給高階模型的做法，與 Anthropic 官方文件的原則一致：把探索的範圍收窄，避免模型讀入大量無關內容；官方也建議把需要大量讀檔的調查交給獨立的子代理，讓主要對話保持乾淨（Anthropic，Claude Code Best practices）。
這套分工是在小額度方案的限制下摸索出來的。各方案的額度與可用模型會調整，請以 Anthropic 官方的方案頁為準；使用較高額度方案的人，未必需要這麼拆。受訪者的結論是：Vibe Coding 並不是依賴單一 AI，而是策略性地運用不同模型的強項。
AI 修改過頭，破壞既有功能，怎麼避免？
受訪者的做法是明確指定修改範圍、隨時使用版本回溯，必要時整段重寫；官方文件也建議把範圍與驗證方式寫清楚，並用 git 保留可回復的版本。
第三個困難，是 AI 為了修好一個功能，意外改動其他區塊。受訪者學到三個原則：明確指定修改範圍、隨時使用版本回溯（Undo）、必要時整段重寫。他的觀察是，對 AI 而言，在既有的複雜結構上微調，往往比重新開始更容易出錯，因此「重新開始」是他的標準策略，而不是最後手段。
官方文件把「指定範圍」與「提供驗證方式」講得更具體。下表的左欄是官方原有的範例改寫成中文，不是受訪者的指令。
| 模糊的指令 | 具體的指令 |
|---|---|
| 修好登入的 bug | 使用者回報 session 逾時後無法登入，請檢查 src/auth/ 的驗證流程，特別是 token 更新；先寫一個能重現問題的失敗測試，再修正 |
| 幫 foo.py 加測試 | 為 foo.py 寫一個測試，涵蓋使用者已登出的邊界情況，不要使用 mock |
（Anthropic，Claude Code Best practices）
官方文件也提醒，要給 AI 一個它能自己執行的檢查，例如測試或建置結果；若無法驗證，就不應該上線（Anthropic，Claude Code Best practices）。對沒有程式背景的人，這代表動工前要先想好「怎樣算改對了」，並先保存一個能回去的版本。
要注意版本回溯的限制。依官方文件，Checkpoints 只追蹤 Claude 的檔案編輯工具所做的修改，不包含 Bash 指令造成的變更、多數子代理的修改，以及你自己在工具外手動修改的檔案，也不能取代 git（Anthropic，Checkpointing 文件）。想永久保留的版本，仍要用 git 提交。
約一個月的時間是怎麼分配的？
受訪者約在一個月內完成可運作的最小可行產品，核心架構前幾天搭好，第一週每天約八小時，之後每天一到兩小時，其餘時間用在除錯、模組化與體驗優化。
| 階段 | 投入時間 | 主要工作 |
|---|---|---|
| 前幾天 | 第一週每天約八小時 | 搭建核心架構 |
| 之後約三週 | 每天約一至兩小時 | 除錯、將功能模組化、使用者體驗優化 |
最耗時的是前期把架構立起來，後面是小量持續的調整。
需求分析的本事，怎麼變成與 AI 協作的能力？
受訪者把需求拆解與規格思維轉成五項做法：模型應用、任務拆解、全局理解、停損機制與指令拆解；其中拆任務靠的是對領域的熟悉，而不是軟體工程能力。
| 能力 | 做法 |
|---|---|
| 模型應用 | 判斷何時用高階模型，何時一般模型就夠 |
| 任務拆解 | 靠對自己領域的熟悉；拆不動時，回想自己一開始接觸這個任務是怎麼操作的 |
| 對軟體開發全局的理解 | 透過 AI 學習建置本地端環境，慢慢理解 npm 與套件是什麼 |
| 停損機制 | 多次嘗試仍修不好，就請 AI 重新生成，並檢查上一次的指令能不能拆得更細 |
| 指令拆解 | 把功能拆細、分開請 AI 完成，或限定修改範圍 |
前兩項來自需求分析的本行，後三項是他為了讓 AI 的產出穩定而補上的開發常識。不寫程式的人要補的，是對系統怎麼運作的基本概念，而不是語法。
哪些條件可以借鏡？
塔羅占星網站案例可借鏡的是先用小任務練習、預先決定卡關規則、把領域熟悉度當成拆任務的資產；但一個月的投入與 20 美元等級方案的額度限制，不適用所有人。
- 先從工作上的小自動化開始，累積成功經驗，再挑戰完整產品。
- 動工前就決定停損規則，避免在錯誤的基礎上無止盡修補。
- 動工前先想好驗收方式，並保存可回復的版本。
- 方案額度小時，先縮小範圍再交給高階模型。
常見問題
沒有程式背景，可以自己做出有會員登入的完整網站嗎？
以這個案例來說可以，但花了約一個月，前期每天約八小時，且他具備需求分析背景、擅長拆解需求。完整網站涉及前後端、資料庫與第三方登入，卡關是常態。
AI 修不好同一個問題時，要試幾次才放棄？
受訪者的規則是三次，Anthropic 官方文件的建議是同一對話修正超過兩次就重開。數字不是重點，重點是動工前就決定停損點，之後改成新對話、更具體的提示，必要時重構。
用 AI 改程式，怎麼避免它改壞其他功能？
指定要改的檔案與情境、先寫好驗證方式、保存可回復的版本。必要時整段重寫，比在複雜的舊結構上微調更不容易出錯，這是受訪者的觀察。
手機版跑版，要用最貴的模型嗎？
不一定。受訪者在小額度方案下，先用一般模型縮小範圍，再讓高階模型分析少數檔案。各方案的額度會調整，請以官方方案頁為準。
這個塔羅占星網站是正式營運的產品嗎？
書稿只確認網站有每日抽牌、會員與 AI 解析等功能，沒有使用者人數或營運數據。書稿圖說稱為原型，受訪者稱為最小可行產品。
資料來源與說明
本文的案例整理自我在撰寫書稿期間，對十多位具有 Vibe Coding 或 AI 寫程式經驗的使用者所做的訪談，內容為受訪者的自述，開發時程、使用的模型與方案未經第三方查核；訪談時間書稿未標示。與官方文件的對照，引自下列頁面。
參考資料
- Anthropic，〈Best practices for Claude Code〉，現行文件，存取日期：2026 年 10 月 19 日。
- Anthropic，〈Checkpointing〉，Claude Code 文件，現行文件，存取日期：2026 年 10 月 19 日。
延伸閱讀
- AI 一天寫完工具，為什麼上線卻卡了近一個月？一位資安分析師的部署卡關紀錄：同樣是非工程背景者，卡在環境與部署的案例。
- AI 時代，為什麼懂工作流程的人也能參與系統開發？：從職務能力角度看需求分析這類角色的優勢。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19