app-offer 是做什麼的？
僅執行一次，從頭到尾。將一個建議的方案寫入檔案，並將替代方案放在附錄中。
檔案
| 檔案 | 何時閱讀 |
|---|---|
reference/frameworks.md (F§) | 當步驟提到「閱讀 F§n」時。包含應用程式翻譯、評分標準與範例的框架；F§16 列出被認為不適用的點子；F§17 包含執行公式。 |
reference/app-store-constraints.md (C§) | 在步驟 7、8、9 之前，以及在任何價格、聲明、計時器、保證或名稱撰寫之前。它有一個「資料截至」日期。任何將要上線的內容都需要重新驗證。 |
reference/100m-offers-transcript.txt | 可選。可用於 grep 搜尋特定細節。此技能必須能在沒有它時正常運作。每次引用不得超過連續 15 個單詞。 |
硬性規則（每個步驟）
- 僅限誠實。 無虛假計時器、計數或稀缺性；無虛假、AI 生成或未標明來源的評論或推薦，並且必須揭露背後的任何誘因；無虛構的「原價」、理由；無隱藏續訂條款；無未在產品中實現的功能。違反此規則會導致應用程式被拒絕（Apple 2.3.1, 5.6；Google 欺騙行為）並違反歐盟/英國/FTC 法規（C§7, C§8）。
- 每個美元價值都需要一個理由： 節省的小時數 x 用戶的每小時價值，現實世界替代方案的價格，或真實的獨立價格。沒有理由，就沒有數字。未經估值的項目在每個比率中都計為零。切勿為了通過測試而填充數字。
- 收費金額是最顯眼的價格。 每日或每月等值金額應小且次要（C§2）。
- 在以下情況出現時標記這些風險：
- 成果 + 截止日期聲明：廣告網路限制它們（C§7）；App Review 會移除應用程式無法提供或證實的聲明（2.3.1）。
- 健康、認知、金錢或收入聲明需要證據（C§7）。僅聲明在應用程式內可衡量的技能提升，而非轉移到工作、學校或大腦。
- 兒童或青少年：兒童類別、家長監護、COPPA 以及各州年齡法案，這些適用於任何類別中 18 歲以下的用戶（C§10）。
- 敏感資料（金融、健康、親密、位置）：C§16。
- 保證必須在每個平台和其展示的每個方案上都能兌現（C§5）。
- 市場 > 方案 > 說服。 先修復最弱的環節。
- 改寫書籍內容。 每次最多引用 15 個單詞，並且很少引用。
- 最多問 3 個問題，僅當無法推斷目標用戶或核心工作時；其中一個問題可以是在無法得知獲取渠道時，同時獲取步驟 0.7 中的創始人數字。否則，將假設標記為 [A]，將基準替代值標記為 C§14 中的 [B]，然後繼續前進。
- 連接器： 除非用戶確認專案或應用程式 ID 屬於此應用程式，否則不要查詢分析或收入連接器。否則請提問或標記為 [A]。
- 風格和長度： 簡潔直接，規則使用表格，無廢話。正文約 3000-4000 字加上表格；超出部分放入附錄。
步驟 0：輸入與假設
- 分類輸入： 一句話 / 文件 / URL / 現有儲存庫。僅當輸入指定了此應用程式的專案名稱或其程式碼和說明與點子匹配時，工作目錄才是此應用程式的專案。否則將輸入視為全新點子：不要 grep 工作目錄，並將結果寫入
./<app-slug>-grand-slam-offer.md。 - 現有應用程式：在設計任何內容之前，先基於證據。
- 產品和價格：
grep -rniE 'purchases_flutter|revenuecat|Purchases\.|offering|entitlement|productId|product_id|weekly|annual|lifetime|StoreKit|BillingClient' --include='*.dart' --include='*.swift' --include='*.kt' --include='*.ts' --include='*.tsx' --include='*.json' --include='*.storekit' --exclude-dir={build,Pods,.dart_tool,node_modules,.git} . - 付費牆和入門引導：命名為
*paywall* *onboard* *intro* *upgrade* *pro* *premium*的檔案，加上本地化文案（.arb,.strings,strings.xml）。記錄已上架的語言環境。 - 分析：
track(,logEvent, Mixpanel/Amplitude/Firebase 呼叫；記錄paywall_view,trial_start,purchase,cancel和retention事件是否存在。 - 說明：
CLAUDE.md,README*,docs/,research/, 記憶檔案,fastlane/metadata,CHANGELOG，以及匹配*brand* *voice* *tone* *style* *listing* *aso* *keyword* *mascot* *pricing* *monetis* *paywall的檔案（包括圖片）。
- 產品和價格：
- 證據模式。 使用 WebSearch/WebFetch：花約 12 次查詢來獲取 5-10 個競爭對手的價格和評分，前 3 名的 1-3 星評論主題，以及一個社群討論串；在附錄 B 中引用 URL 和日期。無網路：將每個項目標記為 [A: 記憶，未驗證] 並列出在「定價前需驗證」之下。無即時數據：使用命名的 C§14 行作為 [B] 替代值（退款率 = 類別退款行；付費期數見 F§17.1；流量 = 安裝量 x 到達付費牆的比例）。發布前：評論挖掘為「n/a: pre-launch」；改為挖掘競爭對手的評論。
- 當前方案 以書中的三部分呈現：他們得到什麼，他們如何付費，條款（F§1.2）。全新點子：「之前」 = 陳述的點子（僅功能，無方案）。
- 現有應用程式：審計 目前的付費牆和入門引導是否符合 C§2、C§7 和 C§8（忽略、揭露、標籤估算、暗示結果、徽章）。在 §0 中列出違規。無論方案如何，優先修正這些。
- 先前決策 在說明或記憶中發現的內容，成為 §0 中的限制條件，每個都標記為保留或挑戰（附帶理由）。切勿無聲地覆蓋任何一個；將挑戰者放入附錄 A。
- 創始人數字（預設 [A]）：收入目標（每年 $100k，費用淨額）；獲取渠道（有機）；建置能力（獨立開發者，兼職）；平台費用（若為小型企業計畫則 15%，否則 30%；Google 依 C§1）；增值稅佔總收入比例（根據商店組合，否則 8%）；所得稅率（30%）；用戶每小時價值（當地中位數工資）；每週付費牆觀看次數（已測量，否則 300）。
- 標記： 兒童或青少年用戶；健康、認知或金錢聲明；敏感資料；每位用戶的可變成本（推理、人工分鐘、簡訊、第三方數據或 API 費用，如銀行聚合、OCR 或 KYC、儲存）；多用戶產品（情侶、家庭、團隊、班級：誰必須加入才能獲得價值，誰付費）；可能對弱勢用戶的濫用（強迫、監控、未成年人）。
寫入 §0，以及 §11 和 §12 中使用的「之前」欄位。
步驟 1：飢餓群眾市場測試（閱讀 F§2）
| 測試 | 1 | 3 | 5 | 證據 |
|---|---|---|---|---|
| 痛苦 | 有則更好，沒人抱怨 | 反覆出現的困擾 | 絕望的、代價高昂的或令人尷尬的；未經提示即提出 | 競爭對手 1-3 星評論、Reddit、搜尋詞 |
| 購買力 | 付費者無法支付（兒童、失業者） | 混合 | 付費者有錢且有理由（職業、考試、健康、父母） | 付費者 vs 用戶、商店組合、用戶地理 LTV（C§14） |
| 容易觸及 | 沒有聚集地，沒有關鍵字 | 一些渠道 | 自己的關鍵字集群、社群、創作者；自訂產品頁面可以只對他們說話 | ASA 關鍵字熱門度、subreddits、創作者 |
| 成長性 | 正在萎縮，或即將被 OS 或免費 AI 取代 | 持平 | 順風（人口統計、平台、季節、法規） | 類別趨勢，「Sherlock」風險 |
- 將應用程式映射到健康、財富或關係。純娛樂：直接說明；基於痛苦的定價在該處較弱。
- 評分候選方案： 陳述的市場（現有應用程式：當前上架和品牌所服務的階層）加上 2-4 個子群體。
- 結論。 評估陳述的市場（現有應用程式：當前上架和品牌所服務的階層）。按此順序檢查：
- 轉向：沒有候選方案在所有測試中得分 3+。直接說明；方案無法解決這個問題。
- 前進：陳述的市場在所有測試中得分 3+ 且總分 14+。前進（正常市場）：在所有測試中得分 3+，總分 12-13，且沒有任何子群體在所有測試中得分 3+ 且總分更高；方案承載了它（F§2.7）。
- 利基化：否則。選擇在所有測試中得分 3+ 的最高分子群體；說明其分數，是否達到前進條件，差距以及如何彌補。
- 現有應用程式處於利基化狀態： 除非用戶要求重新定位，否則將主要付費牆保留在當前階層。將子群體作為入門目標軌道、自訂產品頁面和其自身的 Offering 來添加；僅在其內容上線並通過測試後才推廣它。
- 將市場 / 方案 /說服 評為極好 / 正常 / 糟糕。說明努力應該優先放在哪裡。
- 利基階梯： 從通用到超具體的 4 個階層，附帶每個階層的價格含義。預計整個階梯會有約 2-5 倍的溢價，而非書中的 100 倍（F§16）。你承諾的階層就是前進時的陳述市場，否則就是利基化的子群體（現有應用程式：上述規則）。
- 用戶畫像： 4 個具體的資格條件，它不適合誰，以及可能因產品或其誤用而受到傷害的人（以及哪些方案元素應變成選擇加入或排除）。
- 定位：「我們幫助 [用戶畫像] 透過 [獨特機制] 獲得 [結果]，而無需 [最深恐懼]。」
- 總可觸及市場： 可觸及的付費者 x 每位付費者的生命週期總利潤 = 天花板。全新點子：暫定 LTGP = 類別中位數年價格 x (1 - 費用) x (1 - 增值稅比例) x 1.3 期 [A]；如果結論在步驟 7 中改變，則重新計算並更新 §1.3。僅在計算出的天花板（而非高原期）低於目標時，才規劃相鄰的利基市場；高原期意味著應優先改進方案。
- 承諾。 其他用戶畫像將在後續成為自訂產品頁面或入門軌道。在一次測試失敗後不要跳轉利基市場。
寫入 §1。
步驟 2：商品化檢查（閱讀 F§1.6, F§4.10, F§4.12）
- 列出至少 5 個替代方案，包括免費的：2-3 個指定的競爭對手應用程式、YouTube/TikTok、ChatGPT 或其他免費 AI、OS 功能、紙筆 / 書 / 家教，以及什麼都不做。收集價格和評論主題（如步驟 0.3）。
- 表格：替代方案 | 金錢成本 | 達到成果的時間 | 努力 | 夢想 / 可能性 / 時間 / 努力 評分 0、0.5 或 1（1 = 有利於買家：大夢想、高可能性、短時間、低努力） | 總分 /4 | 為什麼有人選擇它。
- 回答：(1) 潛在客戶如何在商店搜尋中比較這些（圖示、第一張截圖、評分、價格）？(2) 這個應用程式在哪個方面在時間或努力上勝出？快速勝過免費。(3) 哪一句話讓它成為獨一無二的類別（命名的方法 + 用戶畫像 + 成果 + 時間間隔）？如果需要解釋，就失敗了。
寫入 §2。
步驟 3：價值方程式審計（閱讀 F§4）
價值 = (夢想成果 x 感知可能性) / (時間延遲 x 努力與犧牲)。每個驅動因素評分 1-5；分數越高越好，因此時間和努力是根據它們有多小來評分。根據應用程式的自然節奏進行校準（每日遊戲、每週預算、每月報告）；F§4.11 有三種應用程式類型的範例。
| 驅動因素 | 應用程式衡量指標 | 1 | 5 |
|---|---|---|---|
| 夢想成果 | 用戶的同儕或伴侶會注意到的成果 | 一個功能（「解鎖 Pro」） | 一個具體的結果加上時間間隔，在用戶同儕群體或伴侶關心的一個場景中 |
| 可能性 | 評分和數量、衡量的成果統計數據、個人基準線、個人化計劃、結果演示、適合度訊號、風險反轉 | 無證據 | 基準線 + 「像你這樣的人」的數據 + 計劃 + 保證 |
| 時間延遲 | 首次感受到的勝利時間；在試用期結束或首次續訂之前可衡量的進展；可見的進度 | 在首次收費前沒有感受到勝利 | 在首次會話內感受到勝利（目標為秒）；在試用期結束前有可衡量的進展 |
| 努力與犧牲 | 點擊次數、打字、帳戶、設定、權限、每個週期的分鐘數、意志力、尷尬 | 在獲得價值之前有帳戶 + 設定 + 權限牆；長時間的會話 | 僅核心工作真正需要的步驟，且在價值之前沒有；錯誤保持私密 |
- 對於每個評分為 3 或更低的驅動因素，列出邏輯修復（更改建置）和心理修復（進度條、計劃螢幕、下一個解鎖倒數計時、每日框架、重新命名）。先嘗試心理修復；它們更便宜。
- 將分母推向零：代辦版本會是什麼樣子？
- 命名長期夢想和人們留下的好處，並在應用程式的節奏上設置里程碑（例如第 1 / 3 / 7 / 30 天）。
寫入 §3（之前的評分；之後的評分在步驟 11 中加入）。
步驟 4：問題清單（閱讀 F§7.2）
- 走訪整個旅程：發現 > 商店頁面 > 安裝 > 入門引導 > 首次會話 >（多用戶：發送邀請 > 第二位用戶加入）> 第二天 > 第一週 > 高原期或無聊 > 帳單與續訂 > 生活事件（旅行、忙碌的一週、新手機、共享設備）> 分享 > 成功後的下一個問題。
- 在每個階段檢查四個類別：不值得（夢想）；對我沒用 / 我不會堅持（可能性）；太難了 / 我看起來很笨（努力）；太慢了 / 沒時間（時間）。
- 用用戶自己的限制性信念詞彙寫下每個障礙。從評論、Reddit、支援電子郵件、取消原因、入門流程流失點中挖掘（發布前：從競爭對手的評論中挖掘）。
- 用其驅動因素標記每個障礙。目標是 20+；30-60 是正常的。按頻率 x 嚴重程度排序。
正文：前 25 行（# | 階段 | 用戶的話 | 驅動因素 | 來源）。其餘放入附錄 D。
寫入 §4。
步驟 5：解決方案與交付載具（閱讀 F§6, F§7.3-7.8）
- 將每個問題翻轉為「如何 [受益] 即使 [障礙]」。正文顯示前 10 個；其餘放入附錄 D。
- 為每個問題列出載具：前 10 個每個至少 3 個，其餘每個至少 1 個，然後再判斷任何載具（先發散，再收斂）。將共享一個載具的問題分組。使用交付立方體：
| 軸 | 選項 |
|---|---|
| 關注度 | 1:1（創始人、人類教練、AI 導師）/ 小團體（朋友對決、家庭聯賽、同儕小組）/ 1:多（功能、內容、排行榜、直播活動） |
| 努力程度 | DIY 工具 / DWY 引導式計劃或 AI 教練 / DFY 自動化 |
| 媒介 | 應用程式內、小工具、通知、手錶、鎖定螢幕 / Live Activity、電子郵件、聊天、語音、直播會話、可列印內容 |
| 回應速度 | 即時 24/7（軟體、AI）/ 當天 / 每週 |
- 積木練習：一次更改一個屬性（表面、格式、會話長度、社交規模、受眾、付費者）並記錄新想法。
- 10倍 / 1/10 測試：如果你以 10 倍的價格交付，你會交付什麼？用戶如何在 1/10 的價格下仍然獲勝？從兩端各保留一個最佳想法。
寫入 §5：問題 | 如何做陳述 | 載具（立方體代碼）。
步驟 6：修剪與堆疊（閱讀 F§7.9-7.10）
- 對步驟 5 中的每個潛在載具，問「這能為用戶的核心工作提供什麼？」和「這能提供更多保證嗎？」。
- 核心價值堆疊：從不可協商的（如果我們移除這個，核心工作就無法完成）到逐漸可選的。每個項目應包括功能、其承諾的成果，以及如果用戶跳過它會失去什麼。
- 驚喜堆疊：期望之外但用戶會珍惜的元素。從步驟 4 的問題和競爭對手評論中的未滿足需求中挖掘。
- 主要堆疊（前 5-7 項，包括核心）和完整堆疊（所有項目）。目標是讓完整堆疊感覺像個驚喜，而主要堆疊則強到足以單獨定價。
- 10 倍測試：如果我們只提供核心堆疊，用戶還會付費嗎？如果會，主要堆疊應該作為更高階的方案。如果不會，它必須是主要方案的一部分。
寫入 §6：層級 | 包含項目 | 成果 | 遺漏的代價。
步驟 7：定價（閱讀 F§17）
- 定價基準： 根據步驟 1 的利基階梯和步驟 2 的比較產品，設定一個初始價格範圍。使用 C§14 中的類別中位數和平均值。
- 定價模型： 一次性、訂閱（每週、每月、每年）、終身、試用期、免費增值。選一個或多個。對照 C§2、C§5、C§7 檢查。
- 方案結構： 基於步驟 6 的堆疊。通常為 3 個方案：免費 / 基本（主要堆疊）/ Pro（完整堆疊）。確保明顯的升級路徑。
- 價格點： 使用心理定價（.99, .97）。確保每個價格都有步驟 0 中的理由。
- 試用和折扣： 設定試用長度（7 天、14 天）和折扣（年度 vs 每月）。確保試用期內能展示核心價值。
- 財政檢查： 計算每個付費者的生命週期總收入（LTGP）與總可觸及市場（TAM），確保能達到步驟 0 的收入目標。如果不夠，回到步驟 1 尋找更昂貴的利基市場。
寫入 §7：方案 | 價格 | 包含的堆疊 | 理由。
步驟 8：稀缺性與緊迫性
- 誠實的稀缺性： 僅使用真實的和可驗證的稀缺性。例如：時間限制的免費功能、限量的創始人定價、級別的席位限制。
- 避免虛假： 無「3 人正在看這個」或「僅剩 2 個名額」除非是真實的。
- 基於時間的緊迫性： 預購折扣、發布窗口、假日特賣。清楚說明結束日期。
- 基於數量的稀缺性： 獨家計畫、邀請制。如果達到限制則停止。
- 道德審查： 對照 C§2（標籤估算）、C§7（誤導性聲明）和 EU/UK/FTC 規則檢查。無預設隱藏續訂。
寫入 §8：類型 | 元素 | 真實性證據 | 實施方式。
步驟 9：獎勵與保證
- 獎勵： 提供與核心產品相關且對用戶有價值的獎勵。想想範本、指南、額外內容、社群訪問。它們必須是交付或產生成本的真實事物。
- 保證： 設計一個保證，讓用戶的風險降至最低。常見保證：30 天退款保證、績效保證（如果 x 沒發生）、滿意保證。
- 支付能力： 對照 C§5 檢查：保證必須在每個平台和每個展示的方案上都能兌現。如果無法兌現，不要提供。
- 保證的措辭： 清晰、簡單、在應用程式和商店頁面上顯眼。包括如何申請退款的說明。
寫入 §9：獎勵 | 描述 | 價值 | 保證 | 兌現方法。
步驟 10：命名
- 命名準則： 名稱應傳達核心好處或成果，易於記憶和拼寫，並在商店搜尋中可用。
- 與定位保持一致： 使用步驟 1 中的定位陳述。名稱應強化獨特機制或主要成果。
- 檢查可用性： 對照 App Store、Google Play 和商標資料庫檢查。名稱必須是獨特的。
- 子名稱： 對於方案（如「基礎」與「Pro」），使用能反映價值增加的名稱。
寫入 §10：應用程式名稱 | 理由 | 方案名稱 | 可用性檢查。
步驟 11：收費牆與佈局
- 收費牆位置： 決定收費牆出現的位置：入門時、首次成果後、每次使用時。使用步驟 3 中的時間延遲數據來優化時機。
- 收費牆設計： 對照 C§2（最顯眼的價格）、C§7（無誤導聲明）和 C§8（披露）檢查。使用評分、推薦和價值堆疊。
- 方案呈現： 三個方案，中間的作為預設選項。突出顯示最受歡迎的方案。使用比較表格。
- 入門引導流程： 設計一個「快速勝利」體驗，讓用戶在收費牆前感受到價值。目標：在首次會話內完成。
- 本地化： 如果應用程式已本地化，確保收費牆文案在每個語言環境中都有效。
寫入 §11：之前（當前收費牆） | 之後（建議收費牆） | 佈局決策 | 快速勝利。
步驟 12：測試計劃
- A/B 測試： 定義關鍵指標（轉換率、每位付費者平均收入、留存率）。列出要測試的假設（例如，「Pro 方案已包含 X」 vs 「X 是付費功能」）。
- 實驗設計： 每個測試一個變量。確保統計顯著性。設定持續時間（通常 1-2 週）。
- 測試項目： 價格、方案結構、獎勵、保證措辭、收費牆時機、按鈕顏色（較不重要）。
- 成功標準： 定義什麼構成勝利：轉換率提升 10%、留存率提升 5%、每位付費者平均收入提升 15%。
寫入 §12：測試 # | 假設 | 變量 | 指標 | 持續時間 | 成功標準。
步驟 13：上線計劃
- 優先事項： 從步驟 3 中的心理修復開始（快速勝利）。然後處理邏輯修復（建置更改）。然後實施收費牆更改。
- 依賴項： 列出任何第三方服務（RevenueCat、A/B 測試工具、分析工具）。確保它們已設定並配置。
- 時間線： 預估每個階段的時間。從 1 週（心理修復）到 4 週（邏輯修復）不等。
- 風險： 列出可能出錯的地方以及如何減輕風險。例如，新保證可能導致退款率上升；設定自家限額。
- 部署： 逐步推出。先對 10% 的用戶推出新收費牆，然後再擴大到 100%。監控關鍵指標。
寫入 §13：階段 | 動作 | 時間線 | 風險 | 減輕措施。
步驟 14：附錄
附錄 A：被挑戰的先前決策
- 步驟 0.6 中的任何挑戰，附帶理由和建議的替代方案。
附錄 B：研究來源
- 步驟 0.3 和步驟 1 中使用的所有 URL、搜尋詞和社交媒體討論串。每個帶有日期和簡短摘要。
附錄 C：替代方案
- 步驟 6、7、8 和 9 中考慮過但未選擇的方案、價格和保證。每個都附帶未選擇的理由。
附錄 D：完整問題清單
- 步驟 4 中未包含在前 25 行中的所有問題（階段 | 用戶的話 | 驅動因素 | 來源）。
此檔案由 app-offer 技能生成。所有價格和主張應在提交審查前由開發者驗證其合規性（對照 C§2、C§5、C§7、C§8、C§10、C§16）。