重點摘要：打造讓人難以拒絕的提案，然後將其轉化為網站文案。 提案本身比文字更重要：先建立提案，再撰寫文案。
此技能有嚴格的標準清單（請參閱「強制標準」）。在每項標準都達到「通過」或經過合理判斷為「不適用」之前，提案和文案不算完成。
工作流程
請依序執行以下步驟。在步驟 5 之前，請勿開始撰寫文案。
步驟 1 — 程式碼庫偵查
在提出任何問題之前，先從儲存庫中提取所有可能的資訊：
- 頁面內容：頁面/區塊組件（
src/、app/、pages/、components/）、內容檔案（content/、*.md、*.mdx）、翻譯檔案（locales/、i18n/、messages/*.json）、CMS 資料、README、package.json（名稱、描述）。 - 以多種語言搜尋與提案相關的關鍵字，例如：
grep -riE "price|pricing|plan|tier|package|guarantee|refund|bonus|free|limit|spots|seats|deadline|testimonial|case study|faq|cen|zł|pln|eur|pakiet|gwaranc|zwrot|gratis|miejsc|opini" --include=*.{tsx,jsx,ts,js,vue,svelte,astro,html,md,mdx,json} . - 識別品牌的語調（正式/非正式、使用敬稱）。
將結果記錄為「我已知的資訊」表格，欄位包括：提案元素 | 我找到的內容 | 來源（檔案） | 信心程度（高/低/無）。
步驟 1a — 文案語言（強制）
決定文案將使用哪種語言撰寫。文案語言與本次對話使用的語言以及此技能的語言無關。
- 從網站上下文偵測文案語言，依據以下證據的優先順序：
<html lang="…">屬性、框架的 i18n 設定（next.config.*的i18n.defaultLocale、astro.config.*、nuxt.config.*、vite/i18next設定）、語言環境資料夾/檔案（locales/pl/、messages/de.json）、- 現有可見文案的語言（標題、按鈕、Meta 標題/描述）、
- 貨幣、日期格式和法律頁面（例如「Regulamin」、「Impressum」、「條款」）。
- 僅在證據明確無誤時（一個語言環境、現有文案明確使用該語言），無需詢問即可使用偵測到的語言。
- 在以下任一情況下詢問使用者要使用哪種語言撰寫：
- 沒有現有文案或語言訊號（新建/空專案）、
- 網站有多個語言環境（詢問：哪個是主要/來源語言，以及是否需要同時撰寫其他語言環境，或是留待後續翻譯）、
- 訊號衝突（例如
lang="en"但內容是波蘭文、範本佔位文字、lorem ipsum）、 - 使用者明確提及與網站顯示不同的目標市場。
- 如果語言有敬稱用法（例如波蘭文的「Ty」vs.「Państwo」、德文的「du」vs.「Sie」、法文的「tu」vs.「vous」），且在現有文案中無法推斷，也請確認敬稱形式。
- 在提案簡報中記錄決定：
文案語言：<語言>（來源：從 <檔案/訊號> 偵測 | 由使用者選擇）。
所有對客戶的輸出內容（提案名稱、將用於頁面的提案簡報內容，以及所有文案）都使用所選的文案語言撰寫。與使用者溝通時，則使用他們在對話中使用的語言。
步驟 2 — 差距分析
將「我已知的資訊」與 references/intake-questions.md 中列出的輸入項目進行比較。信心程度為「無」或「低」的每個元素都要加入問題清單。對於程式碼就能清楚回答的事情，不要提問，以免浪費使用者的時間。
步驟 3 — 訪談
閱讀 references/intake-questions.md，並僅詢問缺失的問題。
- 如果可以使用
AskUserQuestion工具，請使用它（每輪最多 3–4 個問題，提供合理的可點擊選項 + 自訂答案的空間）。否則，在聊天中提問，每輪最多 5 個問題。 - 如果在步驟 1a 後仍未確定文案語言，請在第一輪提問中包含此問題。
- 提問順序：(1) 客戶與夢想成果，(2) 產品與交付方式，(3) 證明與障礙，(4) 限制條件：實際容量、截止日期、企業能接受的保證，(5) 價格與利潤。
- 當使用者不知道答案時，提出 2–3 個具體選項，讓他們選擇，而不是留下空白。
- 切勿捏造事實：客戶數量、成果、推薦、認證、可提供名額數量。如果缺少，請在文案中插入明確的佔位符號：
[待填寫：...]（佔位符號標籤使用文案語言撰寫，例如波蘭文用[DO UZUPEŁNIENIA: …]）。
步驟 4 — 建立提案（提案簡報）
閱讀 references/offer-framework.md、references/guarantees-scarcity.md 和 references/pricing-packages.md。按以下順序建立提案：
- 夢想成果 — 一句話，用客戶的語言，具體且可衡量。
- 價值方程式 — 列出槓桿：我們如何提高成果及實現的感知可能性，我們如何縮短時間延遲以及減少努力與犧牲。
- 問題/障礙清單 — 客戶在購買前、購買中和購買後必須克服的所有事項（至少 8 項）。
- 問題 → 解決方案 — 將每個障礙轉化為解決方案（「如何...」）。
- 交付方式 — 每個解決方案的交付方式（一對一、小組、範本、工具、代辦服務等），然後進行精簡與堆疊：刪除對客戶價值低但交付成本高的項目；保留交付成本低但客戶重視的項目。
- 價值堆疊 — 每個元件包含名稱、成果和價值。
- 贈品 — 每個贈品移除一個特定障礙。
- 風險逆轉 — 保證（或保證堆疊）。
- 稀缺性與急迫性 — 基於實際限制條件。
- 方案/價格架構 — 如果產品符合資格（請參閱
pricing-packages.md中的資格標準）。 - 提案名稱 — MAGIC 公式。
將結果儲存為 docs/offer/offer-brief.md（或使用者指定的位置），使用「輸出格式」中的範本。向使用者展示簡報，並在撰寫文案前請求批准或修改。
步驟 5 — 網站文案
閱讀 references/copy-blueprint.md。按照藍圖逐區塊撰寫文案，並根據網站類型（單一登陸頁面 vs. 較大網站 — 請參閱藍圖）進行調整。使用步驟 1a 中選擇的文案語言，以符合該語言習慣的方式撰寫，而非從英文翻譯。
實作方式：預設將文案儲存到 docs/offer/landing-copy.md。如果使用者希望，可以直接將文案放入組件/內容檔案中 — 保留現有結構、i18n 鍵值和樣式。對於多語言環境網站，僅寫入已同意的語言環境。未經許可，請勿重建版面。在較大的網站上，一旦新的文案就定位，建議使用 site-consistency 技能來調整其餘頁面以符合新的提案。
步驟 6 — 品質控制
檢閱下列「強制標準」，並在回覆中包含一個表格：標準 | 通過/失敗/不適用 | 證據（從文案中引用或解釋不適用的理由）。在交付之前，修正所有「失敗」的項目。只有在標準明確允許的情況下，才能標記為「不適用」。
強制標準
L. 語言
- L1. 文案語言已依照步驟 1a 決定（從明確的網站訊號偵測或由使用者明確選擇），並在簡報中記錄其來源。
- L2. 所有對客戶的文案、提案名稱、行動呼籲和佔位符號都使用該語言，並以符合語言習慣的方式撰寫，使用已同意的敬稱形式。
A. 基於價值的提案 — 禁止基於價格的提案
- A1. 文案絕不以價格競爭：禁止使用如「最便宜」、「最低價格」、「比競爭對手便宜」、「全網最低價」或「五折促銷」作為主要訴求的訊息（及其文案語言中的對應詞）。
- A2. 價格僅在展示價值之後出現（成果 → 堆疊 → 贈品 → 保證 → 價格）。絕不可出現在英雄區或頁面頂端作為誘餌。
- A3. 價格必須與總堆疊價值（「總價值：X — 您的投資：Y」）和/或問題的成本（不解決問題會讓客戶付出多少代價）進行對比。
- A4. 總堆疊價值應為價格的倍數（目標：至少 5–10 倍）。每個元件的估價都必須有理由（替代方案的費用、市場行情、節省的時間）— 在簡報中記錄理由。
- A5. 價格應根據成果對客戶的價值來設定，而非生產成本或競爭對手價格。如果使用者提出的價格低於價值所應得，請指出並建議透過增加價值而非降低價格來調整。
B. 價值方程式
- B1. 在英雄區中，具體說明夢想成果（數字、狀態、時間框架）。
- B2. 文案透過證據（推薦、案例研究、數據、方法、權威性）來提高成果實現的感知可能性 — 真實的證據或佔位符號。
- B3. 文案傳達更短的初始成果時間（「在...內獲得初步成果」）。
- B4. 文案傳達減少努力與犧牲（「無需...」、「我們為您完成」）。
C. 堆疊與贈品
- C1. 提案至少包含 3 個有名稱的元件，每個元件都有成果描述和估價。
- C2. 每個贈品都解決問題清單中的一個特定障礙（在簡報中說明解決了哪個障礙）。
- C3. 每個贈品都有名稱、成果和估價；贈品總價值至少與核心提案的價值相當。
- C4. 至少有一個贈品能幫助客戶達成目標（不僅是「免費電子書」），例如實作指南、範本、啟動諮詢、執行檢查清單。
D. 風險逆轉
- D1. 提案包含至少一個明確說明的保證：類型（無條件/有條件/反向保證/隱含保證）、時間框架、條件、客戶確切能獲得什麼。
- D2. 在可能的情況下，保證應與成果相關，而不僅僅是「滿意度」（例如「如果您在 Y 天內按照步驟操作後仍未達成 X，我們將免費繼續為您服務/退款...」）。
- D3. 保證必須獲得使用者批准 — 切勿承諾企業未同意的任何事項。
- D4. 保證應顯示在價格和主要行動呼籲旁邊。
E. 稀缺性與急迫性
- E1. 提案包含稀缺性（名額/時段/數量有限）和/或急迫性（時間有限：報名截止日期、贈品截止日期、價格上漲）。
- E2. 每個限制條件都必須是真實的，來自實際容量或業務決策（例如每月最多服務 10 位客戶、某期課程在某日截止報名）。禁止使用虛假的倒數計時器、無依據的「僅剩 3 個名額」以及會重設的計時器 — 這些會誤導客戶，且在歐盟及許多其他司法管轄區屬於不公平商業行為。
- E3. 文案必須說明限制條件的原因（服務品質、團隊容量、課程開始時間）。
- E4. 如果名額數量是動態的，請在文案中使用佔位符號/變數（
[SPOTS_LEFT]）標記，並建議從何處更新該數值。
F. 方案與定價心理學
- F1. 已評估方案資格（請參閱
pricing-packages.md），並在簡報中記錄決定與理由。 - F2. 如果產品符合資格：至少使用一種機制 — 數量方案（「買 4 送 6」、「買 2 送 1」）、分層（好/更好/最好，附有錨定選項和推薦選項）、誘餌效應、一次性付款 vs. 分期付款（全額付款有贈品）。
- F3. 如果不符合資格：使用價格呈現心理學（價值錨定、按時間/成果單位分解、與問題成本比較），並將 F2 標記為「不適用」並說明理由。
- F4. 突出顯示一個推薦選項（例如「最受歡迎」），並且方案機制要在 3 秒內可理解。
- F5. 如果在歐盟市場傳達降價訊息：告知使用者有義務顯示降價前 30 天內的最低價格（綜合指令）。傾向於增加價值（贈品、更多單位）而非折扣。
G. 命名與文案
- G1. 提案名稱使用 MAGIC 公式建立（至少包含 5 個元素中的 3 個），且文案語言中自然順暢。
- G2. 英雄區：以成果為導向的標題 + 副標題（針對誰、在多久時間內、無需什麼） + 行動呼籲。
- G3. 文案使用客戶的語言（來自訪談/推薦中的客戶用語），直接與讀者對話，並專注於好處和成果，而非功能特性。
- G4. 每個頁面區塊都有行動呼籲或導向行動呼籲；行動呼籲應描述下一步驟和好處，而非「提交」。
- G5. 零捏造數據：每個數字、推薦和承諾都來自使用者或是一個佔位符號。
- G6. 常見問題集應回答主要異議（價格、時間、「這對我有效嗎」、風險），並指向保證。
輸出格式
offer-brief.md
# 提案簡報：[依 MAGIC 公式命名的提案名稱]
文案語言：[語言]（來源：從 [訊號] 偵測 | 由使用者選擇）· 敬稱形式：[...]
## 1. 客戶（人物誌）與夢想成果
## 2. 價值方程式（4 個槓桿）
## 3. 問題 → 解決方案（表格：障礙 | 解決方案 | 交付方式 | 交付成本 | 客戶價值 | 精簡/堆疊決定）
## 4. 價值堆疊（表格：元件 | 成果 | 估價 | 估價理由）
## 5. 贈品（表格：贈品 | 移除的障礙 | 成果 | 估價）
## 6. 風險逆轉（類型、完整保證措辭、條件、使用者批准狀態）
## 7. 稀缺性與急迫性（限制條件 | 真實來源 | 原因 | 如何更新）
## 8. 價格與方案（資格決定、選項、錨定、推薦選項）
## 9. 待辦事項 / 待填寫的佔位符號
簡報的結構和分析可以使用對話語言；任何預定在網站上顯示的文字（提案名稱、元件名稱、保證措辭、標題）都應使用文案語言撰寫。
landing-copy.md
依照 copy-blueprint.md 逐區塊撰寫文案，包含區塊標題、內文和行動呼籲 — 使用文案語言。最後附上標準檢查表（L、A–G 標準）。
避免事項
- 在提案建立之前撰寫文案 — 華麗的文字無法挽救一個薄弱的提案。
- 根據對話語言假設文案語言。
- 提問...
……
[為翻譯進行截斷]