# App 點子怎麼找：寫程式前的 5 個測試

> 用 AI 寫程式前，先驗證你的 App 點子：問題、使用者、第一個功能和一張練習表。

原始頁面：[App 點子怎麼找：寫程式前的 5 個測試](https://devoria.fr/zh-hant/blog/find-app-idea-5-tests-before-coding)
作者：[Mehdi Azizi](https://devoria.fr/zh-hant/mehdi-azizi)
發布日期：2026-10-01
內容最後修訂：2026-10-09


要找 App 點子，先從大家已經遇到的問題開始。看看他們現在怎麼解決，聊聊他們最近一次的經驗，然後只挑一個改善點來測試。之後 AI 可以幫你做出第一個版本，但它無法取代這些驗證。

你不需要想出一個前所未有的點子：guideline 4.1 禁止的是抄襲別人的 App，不是去解決一個別人解決過的問題。你需要弄清楚的是：你的 App 會幫到誰、在什麼情境下，以及這個人為什麼會想再次使用它。

在你請 Codex、Claude Code 或某個生成工具幫你做 App 之前，這裡有五個測試可以先做。

## 1. 描述一個情境，而不是一堆功能

「一個結合 AI 的生產力 App」範圍太大，你根本不知道要做什麼。

比較有用的一句話長這樣：

> 當［某人］想要［做某件事］時，他會用［目前的解法］，但是［具體的困難］。

**虛構例子：**一位登山愛好者在整理背包時，會拿出手機裡的舊筆記，但常常忘了依照天氣和行程長短做調整。

這句話裡有一個人、一個時刻和一個問題。它不能證明一定需要一個 App，但它給了你一個可以去驗證的東西。

針對你的點子，寫出這句話，而且不要用「平台」、「社群」或「顛覆」這些詞。如果寫不出來，就先把功夫花在釐清範圍，不要急著開發。

## 2. 看看大家現在用什麼解法

去找競品 App，也要看那些平凡的解法：一則筆記、一張試算表、一則傳給自己的訊息、一張紙本清單。

App 的評論可以給你一些值得深入的問題。但單一一則抱怨，不足以斷定大家都想要一個新 App。

記下三件事：

- 目前的解法已經做得不錯的地方。
- 在類似情境中反覆出現的困難。
- 一個人即使如此仍會繼續用這個解法的原因。

以背包的虛構例子來說，一張簡單的清單可能就已經很好用了。只有當你觀察到這張清單解決得不夠好的問題時，這個點子才值得繼續。

你的第一份工作是搞懂這個缺口。加更多功能，並不會自動讓它變得更重要。

## 3. 針對真實經驗發問

「你會用我的 App 嗎？」很容易讓對方說好聽話給你聽。改問已經發生過的事。

你可以先從幾個真的會遇到這個情境的人開始。這不是具代表性的研究，而是幫你找出對的問題的方法。

例如：

- 你上一次遇到這個問題是什麼時候？
- 那時候你怎麼做？
- 這個解法哪裡讓你覺得麻煩？
- 你試過別的方法嗎？
- 什麼原因會讓你繼續用現在的解法？

仔細聽細節，以及不同回答之間的差異。一個人講述自己準備得很辛苦的過程，比一個覺得你的點子「不錯啊」的人更能讓你學到東西。

不要把三次讓你受到鼓舞的對話當成市場證明。如果回答都很模糊，或描述的是不同的問題，就把目標族群縮得更精確，重新釐清範圍。

## 4. 只挑一個功能來測試

回頭看那些對話，找出最小、可能有幫助的那個動作。

以我們的虛構例子來說，第一版可以讓使用者準備並重複使用一張符合某次行程的背包清單。社群動態、路線地圖和自動推薦都可以晚點再說。

接著寫下你想觀察到什麼：

> 使用者能完成他的清單，理解自己可以修改哪些地方，並在下次出發時再次使用。

這個結果比十個畫面的清單更有用。它幫你決定要做什麼、要測什麼。

我的[一頁式需求規格範本](https://devoria.fr/zh-hant/blog/mobile-app-requirements-template-one-page)能幫你讓第一版保持精簡。需求明確之後，就交給 [Codex 教學](https://devoria.fr/zh-hant/blog/build-app-with-codex-beginner-guide)或 [Claude Code 教學](https://devoria.fr/zh-hant/blog/claude-code-iphone-app-tutorial)接手開發。

## 5. 觀察一個動作，再決定下一步

用草圖、幾個畫面或夠簡單的原型，展示你預想的運作方式。請對方實際做一次你想讓它變簡單的那個動作。

觀察發生了什麼：他看得懂畫面嗎？他有完成任務嗎？他願意在真實情境中再測一次嗎？下一次相關的時機到來時，他會回來用嗎？

這些行為能幫你做決定，但還不能證明訂閱賣得出去。

如果你的目標是付費 App，也要聊聊他現在用什麼、可能有付費的東西，以及他期待得到的價值。只要還沒有真正購買，付費意願就只是意願。

投入更多時間之前，先看看 [iPhone App 的預算](https://devoria.fr/zh-hant/blog/iphone-app-development-cost)。一個點子可能讓使用者感興趣，但以預想的形式來營運卻太花錢。

## 寫第一個 prompt 前要填的表

把這幾行複製到一份文件裡：

```text
我的明確目標族群：
問題出現的情境：

目前使用的解法：
仍然困難的地方：
對話真正讓我學到的事：

第一版唯一的功能：
測試時我想觀察的動作：

我暫時不會做的東西：
我必須確認的成本：
什麼會讓我繼續、調整或
停止：
```

如果有好幾行還很模糊，你就知道該往哪裡繼續研究。如果都很具體，你就可以準備一個小版本來測試。接下來的步驟在[如何打造一個 App](https://devoria.fr/zh-hant/blog/how-to-make-an-app-4-steps)：做出核心功能、接上付款、上架。

點子在上線之後也可能演變。TradaZen 一開始是交易日誌，之後經歷了好幾次產品調整。我把這些階段記錄在 [TradaZen 經驗分享](https://devoria.fr/zh-hant/blog/tradazen-case-study-launch-iphone-app)裡。這段歷程呈現的是真實的演變，但不保證其他 App 也會成功。

## 想把你的點子變成工作計畫嗎？

[iOS Kit](https://devoria.fr/zh-hant/kits/ios) 把接下來的路分成四個階段，照你自己的步調走：挑一個能賺錢的 App、做出核心、接上金流、上架並讓人找到。

不確定你的點子對不對？[免費診斷](https://devoria.fr/zh-hant/diagnostic)會從你目前的進度出發，告訴你第一步該做什麼。

想在有架構的方式下前進，可以看看 [vibe coding 課程](https://devoria.fr/zh-hant/expertise/vibe-coding-course-iphone-app)，用 AI 打造你的 iPhone App。

## 常見問題

### 怎麼找到 App 點子？

先從大家已經遇到的問題開始。看看他們怎麼解決，聊聊他們最近一次的經驗，然後只挑一個改善點來測試。之後 AI 可以幫你做出第一版，但無法取代這些驗證。這些驗證可以歸納成寫程式前要做的五個測試。

### 簡單的手機 App 點子是什麼樣子？

簡單的點子會描述一個人、一個時刻和一個明確的問題。虛構例子：一位登山愛好者在整理背包時，會拿出手機裡的舊筆記，但常常忘了依照天氣和行程長短做調整。在這個例子裡，一張簡單的清單可能就已經很好用：只有當你觀察到清單解決得不夠好的問題時，這個點子才值得繼續。

### 新手可以做什麼樣的 App？

一個解決大家已經遇到的明確問題、第一版只有一個功能的 App。你不需要前所未有的點子。你需要弄清楚你的 App 會幫到誰、在什麼情境下，以及這個人為什麼會想再次使用它。

### 寫程式前怎麼驗證 App 點子？

做五個測試：描述一個明確的情境、看看大家現在用什麼解法、針對真實經驗發問、只挑一個功能來測試，然後觀察一個動作。不要把三次讓你受到鼓舞的對話當成市場證明。如果回答都很模糊，或描述的是不同的問題，就把目標族群縮得更精確，重新釐清範圍。[一頁式需求規格範本](https://devoria.fr/zh-hant/blog/mobile-app-requirements-template-one-page)能幫你讓第一版保持精簡。

### 測試 App 點子時要問別人什麼？

問已經發生過的事：上一次遇到問題是什麼時候、那時候對方怎麼做、他的解法哪裡麻煩。避免問對方會不會用你的 App，因為這會讓人說好聽話給你聽。你可以先從幾個會遇到這個情境的人開始：這不是具代表性的研究，而是幫你找出對的問題的方法。

### 怎麼知道有沒有人願意為我的 App 付費？

只要還沒有真正購買，付費意願就只是意願。如果你的目標是付費 App，就問對方現在用什麼、可能有付費的東西，以及他期待得到的價值。觀察到他看得懂畫面、完成任務並且回來使用，能幫你做決定，但還不能證明訂閱賣得出去。


## 你的專案

[iOS Kit](https://devoria.fr/zh-hant/kits/ios)：用 Claude Code 打造你的 iPhone App：我的 App 所用的 Starter Code、檢查成果的 skills，以及 Apple Review Kit、App Store Screenshots Kit 與 ASO Kit。129.99 €。