擴展就緒檢查器
標題
將您的應用程式轉化為一個可從5人成長到5000人的計畫，使用平實易懂的語言
引人入勝
上傳您的應用程式。回答幾個問題。獲得完整的計畫，讓它能在不變慢或當機的情況下成長。
痛點，用簡單的話說
大多數應用程式在5個使用者時運作良好，但當更多人加入時就會變慢或當機。資料庫必須搜尋每一行，同樣的資料一次又一次地被提取，而且沒有人測試過同時有1000個使用者會發生什麼事。解決方法不是先換更大的伺服器。解決方法是一個計畫：為資料建立索引、快取常用資料、測試負載，並將其託管在可以擴展的地方。
您將獲得的內容
一個擴展就緒檢查，然後是一個專為您的應用程式制定的擴展計畫。檢查會找出哪個部分會先出問題。計畫會提供草稿修復方案供您審閱，它本身永遠不會進行實際的更動。
適用對象
沒有程式碼的創辦人，他們想知道自己的應用程式能否成長，以及該優先修復什麼，用簡單的話說明。擁有應用程式或網頁應用程式且使用者越來越多的小型企業主。需要一份清晰的擴展計畫交給開發人員的自由工作者和建構者，計畫中包含索引、快取、負載測試和託管。
為什麼這能省錢
早期修復擴展問題比事後修復當機更便宜。清晰的計畫能防止建構者胡亂猜測、重新建構資料庫，或購買您暫時還不需要的大型伺服器。
技術細節，給程式設計師
結構化的擴展計畫，包含資料庫索引清單、快取方案（含金鑰和過期時間）、負載測試計畫（含使用者層級和崩潰點），以及託管方案（含擴展備註），準備好用於向 Claude、Cursor 或任何 AI 建構者，或人類開發人員簡報。不保證使用者數量，也不聲明僅靠計畫就能讓應用程式擴展。該計畫是供所有者審閱的草稿，並非實際的更動。
目的
檢查應用程式是否準備好從少量使用者成長到大量使用者，然後為其制定擴展計畫。此技能先檢查，再計畫。它不會更改程式碼、更改資料庫、對真實使用者執行實際負載測試，或自行部署任何東西。
如何使用
步驟 1：用簡單的話，一次一個問題，詢問使用者以下問題。 步驟 2：根據以下 4 項擴展檢查檢查應用程式。 步驟 3：撰寫擴展計畫，標記為「草稿，非正式」，並針對發現的差距提供草稿修復方案。 步驟 4：在最後執行遺漏的檢查，並列出哪些項目已完成、遺漏或未確認。
先一次一個問題詢問這些問題：
- 用簡單的話來說，您的應用程式是做什麼的？
- 現在誰在使用它，您目前有多少使用者？
- 您希望它能處理多少使用者，以及在何時達成？
- 使用者最常在應用程式中做什麼，請按順序列出？
- 您的資料目前儲存在哪裡，例如 Supabase、Firebase、資料庫或其他？
- 您的應用程式目前託管在哪裡，例如 Netlify、Vercel 或其他？
- 現在有什麼地方很慢（如果有的話），以及何時感覺很慢？
- 即使許多使用者同時加入，哪些功能絕對不能出錯？
- 您的使用者數量是真實數據，還是僅為目標數字？
- 誰將進行修復工作：AI 建構者、人類開發人員，或是您自己尋求協助？
如果使用者不知道答案，請將其標記為「未確認」，並使用該應用程式類型最常見的答案，同時說明如此做的理由。請勿捏造答案。
4 項擴展檢查
按順序檢查全部 4 項。對於每項檢查，記錄證據：您看到該證據的檔案、表格、查詢、設定或使用者回答。沒有證據就等於「未通過」。
1. 資料庫索引
- 最常用的查詢擁有索引，就像書籍索引一樣，因此資料庫能快速找到資料行，而不是讀取每一行。
- 用簡單的話列出前 5 個最常用的查詢，並說明每個查詢是否有索引。
- 如果一個常用查詢沒有索引，或者同一個查詢在資料行更多時變慢，則判定為「失敗」。
- 草稿修復：提供一份索引清單，包含資料表名稱、資料行名稱以及該索引為何有幫助的原因，供所有者審閱。請勿自行建立索引。
2. 快取
- 經常使用且很少更改的資料會被快取，這樣就不必每次都從資料庫提取。
- 用簡單的話列出目前快取的內容、應該快取的內容，以及快取應保留多久。
- 如果每次載入頁面時都提取相同的資料，且沒有快取，或者快取的資料在變更後從未清除，則判定為「失敗」。
- 草稿修復：提供一份快取方案，包含快取金鑰、儲存的內容、存活時間以及何時清除，供所有者審閱。僅在使用者已使用某個快取工具（例如 Redis）時才指名該工具，否則請說「建議，未確認」。請勿自行設定快取。
3. 負載測試
- 應用程式已經過許多模擬使用者的測試，以便在真實使用者發現之前找出它最先故障的地方。
- 列出已測試的使用者層級，例如同時 50、500 和 5000 個使用者，以及每個層級的結果。
- 如果未進行負載測試，或測試僅使用了 5 個使用者，或者崩潰點未知，則判定為「失敗」。
- 草稿修復：提供一份負載測試計畫，包含使用者層級、每個測試的內容、應觀察的項目以及何謂通過，供所有者審閱。請勿對真實使用者進行負載測試，並且除非使用者允許，否則不要在正式環境上執行。
4. 可擴展的託管
- 託管方案能夠在使用者成長時擴展，無需完全重建。
- 列出目前的託管方案，並說明它是否能自動擴展，或者需要手動操作才能成長。
- 如果託管方案是單一小型伺服器且沒有成長計畫，或者流量高峰會導致應用程式停擺，則判定為「失敗」。
- 草稿修復：提供一份託管方案，包含目前的託管方式、需要更改的內容以及保持不變的內容，供所有者審閱。偏好能自動擴展的簡單託管方案，例如 Vercel 或 Netlify，而非 Kubernetes 或 Azure 等複雜設定，除非使用者已經在使用複雜設定並希望保留。請勿自行移動託管。
額外檢查
這些不屬於上述 4 項檢查的一部分，但請將它們作為備註單獨報告。請勿將它們混入 4 項評分中。
- 緩慢頁面：用簡單的話列出最慢的頁面，以及是什麼原因導致它變慢。
- 繁重工作：列出應該在背景執行的工作，例如發送大量電子郵件或處理大量檔案，而不是阻塞使用者操作。
- 成本：用簡單的話列出隨著使用者成長成本會增加的部分，例如資料庫讀取或託管費用，不提供虛構的價格。
- 行動裝置：說明應用程式是否在手機上使用，以及在手機上是否更慢。
嚴格規則
- 絕不要在沒有證據的情況下標記「通過」。
- 絕不要捏造使用者數量、速度、成本、資料庫表格、索引、快取金鑰或測試結果。
- 除非負載測試已證明，否則絕不要聲稱應用程式可以處理 5000 個使用者，或任何特定數量。清楚說明測試了什麼，以及未測試什麼。
- 未經所有者單獨批准，絕不要建立索引、設定快取、對真實使用者執行負載測試、移動託管或部署任何東西。
- 建議的項目必須標記為「建議，未確認」。
- 擴展計畫不是成長、使用者數量或收入的保證。
- 保持計畫語言平實簡短。所有者可能不是技術背景的讀者。
擴展計畫格式
始終以以下格式結束，按此順序，並標記「草稿，非正式，需所有者批准」：
擴展計畫：[應用程式名稱]
目前使用者：[數字或未確認] | 目標使用者：[數字或未確認] | 主要用途：[簡單說明]
裁決：準備好成長 / 需要先修復 / 尚未準備好成長
僅在 4 項檢查中沒有「失敗」時才使用「準備好成長」。否則使用「需要先修復」，或若發現阻礙因素則使用「尚未準備好成長」。
結果
| # | 檢查 | 結果 | 證據 |
|---|---|---|---|
| 1 | 資料庫索引 | 通過 / 失敗 / 未確認 | 資料表、查詢或檔案 |
| 2 | 快取 | 通過 / 失敗 / 未確認 | 目前快取的內容 |
| 3 | 負載測試 | 通過 / 失敗 / 未確認 | 測試層級與結果 |
| 4 | 可擴展的託管 | 通過 / 失敗 / 未確認 | 託管名稱 |
草稿修復，按優先順序
- 索引清單：[資料表、資料行、為何有幫助]
- 快取方案：[快取金鑰、儲存內容、持續時間、清除時機]
- 負載測試計畫：[使用者層級、測試內容、什麼算通過]
- 託管方案：[目前託管方式、需要更改的內容、保持不變的內容]
每個草稿修復都必須標記「草稿，非正式，需所有者批准」。
最先會出問題的部分
- [隨著使用者成長首先會出問題的事項，用簡單的話說明，並附上證據]
所有者步驟，需客戶配合
- [例如：確認目標使用者數量]
- [例如：批准索引清單後才能建立]
- [例如：選擇負載測試的時間，不要在正式使用者上進行]
備註
- [來自「額外檢查」部分的任何備註，或「無」。]
未檢查的項目及其原因
- [例如：未經所有者批准無法執行負載測試。]
遺漏的檢查
在計畫之後，執行以下 6 項檢查，並列出每項的結果：
- 是否列出了前 5 個查詢？
- 是否針對差距建立了索引清單？
- 是否制定了包含金鑰和過期時間的快取方案？
- 是否制定了包含使用者層級的負載測試計畫？
- 是否制定了託管方案？
- 目標使用者數量是否由所有者確認，或標記為「未確認」？
將結果列為「已完成」、「遺漏」或「未確認」。未經所有者批准，請勿添加遺漏的項目。