開發者常常先解釋產品如何運作，卻沒有先說它能帶來什麼。本文協助你把已確認的產品事實改寫成清楚的標題候選，再測試目標使用者能不能看懂完整首屏。
寫標題前，先回答四個問題：
| 資訊 | 需要回答的問題 |
|---|---|
| 目標使用者 | 誰會一再遇到這個問題？ |
| 想要的結果 | 使用者最後要得到什麼具體結果？ |
| 目前阻力 |
| 他們現在要忍受什麼緩慢、脆弱、昂貴或重複的流程？ |
| 已確認的依據 | 關於安裝、效能、隱私、相容性或所有權，你能如實說什麼？ |
可以先用這個結構整理思路：
Eren
學習循環標題假設 = 想要的結果 + 必要的使用情境 - 目前阻力
這只是起草工具，不是通用定律。H1 不需要塞進所有資訊。目標使用者可能已經能從頁面脈絡看出來；產品機制和事實依據則可以放在副標題或事實說明裡。
標題的任務很簡單：讓適合的人願意繼續往下看。
選擇公式時，要看產品特點和訪客已經了解多少。不要硬把所有產品套進同一個句型。
| 類型 | 公式 | 適用情況 | 範例 |
|---|---|---|---|
| 1. 去掉已知麻煩 | [完成任務]，不必[痛苦的替代做法] | 使用者已經知道舊做法很麻煩 | 驗證資料庫還原，不必維護自訂還原指令碼。 |
| 2. 把輸入變成結果 | 把[原始輸入]變成[可用輸出] | 產品有清楚的輸入和輸出 | 把 Stripe Webhook 事件變成可對帳的交易紀錄。 |
| 3. 說清楚專用定位 | 為[特定使用者或環境]打造的專用[類別] | 聚焦的小範圍確實是差異點 | 為單一容器家用伺服器打造的運作狀態監控工具。 |
| 4. 取代脆弱流程 | 別再[脆弱流程]。[得到結果]。 | 使用者熟悉這個問題，而且後果明顯 | 別再手動清理正式環境日誌。匯出前先移除金鑰。 |
| 5. 劃分人機工作 | 你負責[高價值工作]，我們處理[重複的系統工作] | 使用者需要自動化，但不想失去控制 | 你來寫查詢，我們處理連線池、快取和容錯移轉。 |
這些公式只負責幫你產出草稿。它們不能證明文案裡的主張是真的，也不能保證文案有說服力。
假設有一款開源 CLI 工具。它會在 staging 環境的日誌上傳到物件儲存空間前，先移除其中的金鑰。
這個範例只使用以下已確認的產品事實：
這些事實就是文案邊界。我們不能憑空加入速度、偵測準確率、法規遵循或「零設定」等說法。
一個非同步權杖檢查代理，使用正規表示式和以熵值為基礎的金鑰分類。
這句話介紹了內部實作，卻沒有直接說明使用者要完成什麼工作、在什麼環境使用，以及最後能得到什麼結果。
| 資訊 | 本例答案 |
|---|---|
| 目標使用者 | 維護容器化 staging 環境的開發者 |
| 想要的結果 | 上傳可用日誌，同時避免暴露常見憑證 |
| 目前阻力 | 維護自訂遮罩規則，或逐筆人工檢查日誌 |
| 已確認的依據 | 本機 Go 執行檔、標準輸入輸出流程、MIT License |
公式 1：去掉已知麻煩
把 staging 日誌傳到物件儲存空間，同時避免暴露 API Key 或資料庫憑證。
這個版本先說操作結果和風險。它較適合已經擔心日誌洩漏金鑰的訪客。
公式 4：取代脆弱流程
別再維護日誌清理指令碼。匯出前自動移除常見金鑰。
這個版本先說舊做法。它較適合正在維護脆弱正規表示式規則的訪客。
公式 3：說清楚專用定位
為容器化 staging 環境打造的本機日誌遮罩 CLI。
這個版本吸引力稍弱，但類別很清楚。它較適合正在比較日誌遮罩工具的人。
現在還不能誠實地選出「贏家」。三個版本分別假設訪客已經知道不同資訊，也在意不同問題。
上面的每一句都能追溯到已確認的資訊。能否追溯，比聽起來是否厲害更重要。
下面這段 Prompt 可以產生英文候選文案。它會限制模型只使用你提供的事實，不把資訊空缺補成行銷承諾。
你正在協助一位技術創辦人起草英文著陸頁首屏文案。
只能使用下面已確認的產品資訊。不要推論或編造效能、隱私、
法規遵循、客戶、價格、整合或安裝方面的主張。
產品資訊：
- 產品名稱：[名稱]
- 目標使用者：[準確的角色或使用環境]
- 要完成的工作：[使用者想得到的具體結果]
- 目前替代做法或阻力：[使用者現在怎麼做]
- 產品機制：[使用者要安裝、連接或提供什麼]
- 已確認的安裝事實：[只寫已確認的資訊]
- 已確認的依據或差異點：[只寫已確認的資訊]
- 主要轉換動作：[下載、查看示範、開始試用等]
可用標題公式：
1. [完成任務] without [痛苦的替代做法]
2. Turn [原始輸入] into [可用輸出]
3. The focused [類別] for [特定使用者或環境]
4. Stop [脆弱流程]. [得到結果].
5. You [高價值工作]. We handle [重複的系統工作].
要求：
1. 選擇最符合產品事實的三個公式。
2. 說明每個公式為什麼合適。
3. 使用主動、具體、容易理解的英文。
4. 不要使用 effortless、seamless、next-gen、all-in-one、
supercharge、unleash 或 revolutionary。
5. 如果某項有用的主張沒有事實支持，寫 Missing evidence，
不要替產品補完這項主張。
6. 產品資訊沒有提供時，不要加入數字、時限、安全、隱私或法規遵循承諾。
請用英文輸出。每個公式使用以下結構：
### Pattern [編號]: [名稱]
- Reason for selection:
- H1 headline:
- Sub-headline:
- Primary CTA:
- Proof line，或 No verified proof provided:
- Key audience assumption:
- What could be misunderstood:
- Test hypothesis:
最後用表格比較各候選版本更重視哪一項：
- 結果是否清楚；
- 受眾是否具體；
- 是否能讓使用者認出目前的麻煩；
- 類別是否清楚。
Prompt 不能替你驗證定位。它的作用，是產生界線清楚、方便審核、也值得測試的候選版本。
5 秒測試用來觀察使用者短暫看過頁面後記住了什麼、理解了什麼。常見做法是展示頁面 5 秒，接著隱藏頁面並提問。詳細流程可參考 Lyssna 的 5 秒測試說明。
測試完整首屏，不要只展示標題。找目標使用者看過頁面後，問四個問題：
記錄參與者自己的用詞。如果多人出現同一種誤解，就修改造成誤解的文案。如果答案很分散，而參與者並不屬於目標使用者，先改善招募條件，不要急著再次重寫標題。
5 秒測試只能檢查第一印象、理解和記憶，不能證明標題會提高註冊或營收。等兩個版本都能準確說明產品後，再在相近的流量和轉換條件下比較。
清楚的文案不是終點。它只是一個可以讓目標使用者檢驗的產品說明。
準備公開測試定位時，可以先比較 Product Hunt、Reddit 和 Hacker News 的特點和風險。
Tomako 是為軟體開發者打造的 Always-On AI CMO。核心原則很簡單：行銷工作要以真實的產品資訊為基礎，並且能在公開前由人審核。如果你想建立穩定的發布習慣，也可以參考一人開發者的每日 30 分鐘行銷流程。
