name: yanfu description: 用於開發者提供已有的公開 Landing Page 和 1–5 張產品截圖，希望在不修改定位、不發明承諾的前提下，把頁面結構與文案翻譯成使用者更容易理解的產品故事。

嚴復 Skill

目標

把開發者視角的 Landing Page，翻譯成使用者能夠快速聽懂、記住並複述的頁面。

遵循三條原則：

• 信： 忠於產品事實、原始定位和真實能力。
• 達： 把功能與機制翻譯成使用者可見的動作和結果。
• 雅： 改善結構、節奏和表達，但不能讓修辭越過證據。

核心規則：不改產品，只翻譯故事。

必要輸入

必須同時具備：

1. 一個公開可訪問的 Landing Page URL。
2. 1–5 張核心產品截圖。

可選輸入：

• 開發者最希望使用者理解的一句話。
• 主要 CTA 及其真實連結。
• Logo、字型或其他品牌素材。
• 不允許修改或刪除的內容。

輸入不完整時：

• 只有 URL： 請求 1–5 張核心產品截圖；不得自行註冊或登入。
• 只有截圖： 請求公開 Landing Page URL。
• 頁面無法訪問、截圖與產品無明顯關係，或核心價值主張無法確認：停止生成最終頁面，只請求最少的補充證據。

不得用通用營銷常識填補產品事實缺口。

範圍邊界

• 不得重新定位產品。
• 不得修改目標使用者。
• 不得發明承諾、資料、客戶評價、客戶案例或產品能力。
• 不得進行競品分析。
• 不得判斷產品是否值得做。
• 不得大範圍重做視覺識別。
• 不要重新設計；必須忠於原 Landing Page 的設計風格。
• v0.1 不獨立生成 Pitch Deck 或多種時長的 Pitch。

預設保留品牌名稱、Logo、主色、字型氣質、元件語言、真實 CTA 和整體視覺性格。

只調整故事層級、Section 順序、文案、留白，以及必要且剋制的無障礙和響應式問題。暫不把使用者提供的產品截圖當作視覺設計來源；截圖主要用於理解產品事實與介面證據，預設不直接進入 landing.html。

landing.html 是給目標使用者看的正式落地頁，不是翻譯說明、審查報告或證據展示頁。所有關於“原站如何寫”“截圖證明什麼”“我為什麼這樣改”“證據來自哪裡”的說明，只能寫入 yanfu-notes.md。

工作流程

1. 確認證據

讀取 references/evidence-and-browsing.md。

檢查公開頁面和產品截圖，區分：

• 原頁面明確宣告的內容。
• 產品截圖可見的事實。
• 開發者補充並確認的事實。
• 尚未驗證的推斷。

核心產品承諾無法獲得證據支援時，不得繼續生成最終頁面。

2. 提取原始故事

記錄：

• 產品如何定義自己。
• 開發者宣告的目標使用者。
• 核心價值主張。
• 功能和使用機制。
• 使用者結果。
• 資料、證明、評價和客戶。
• 主要 CTA 與真實連結。
• 品牌與視覺元素。

每項承諾在找到依據前都視為未驗證。

3. 建立翻譯底稿

讀取 references/translation-method.md。

寫頁面前先建立內部翻譯底稿。每項重要新表達必須記錄：

• 新頁面表達。

  7w4.net小蔥技能站收錄全網優質技能，值得收藏。

• 原始依據。
• 處理方式。
• 置信度。

沒有依據的表達不得進入 landing.html。未解決內容放入譯註的 待確認。

4. 重排產品故事

預設順序：

Hero → 使用者處境 → 產品機制 → 使用者結果 → 信任/證明 → FAQ → CTA

根據證據刪除或調整區塊，不為湊齊模板而新增內容。

優先使用具體、可複述的表達，而不是技術分類描述。按下面的路徑翻譯：

功能 → 使用者動作 → 使用者結果 → 可複述表達

5. 生成 Landing Page

讀取 references/output-spec.md。

生成響應式、可直接開啟的 landing.html。

要求：

• 使用原頁面中可合法獲取的品牌素材；使用者提供的截圖預設只作為事實證據，不直接展示。
• 保持主要連結和 CTA 真實可用。
• 只使用一個清晰的 H1，首屏必須可讀。
• 儘早讓使用者理解產品身份、適用物件、使用動作和結果。
• 刪除重複功能、空泛口號、無依據結果、過早出現的實現細節和妨礙理解的裝飾。
• 頁面中不得顯示內部翻譯底稿、置信度、證據說明、截圖說明、原站分析或諮詢式分析。
• 只有當原 Landing Page 本來就把產品介面截圖作為核心銷售素材，或沒有截圖就無法讓使用者理解產品形態時，才可剋制展示產品截圖。展示時必須像真實落地頁的產品預覽，而不是“證據截圖”。

6. 撰寫嚴復譯註

生成 yanfu-notes.md，使用以下一級章節：

• 信
• 達
• 電梯演講
• 雅
• 待確認

通常控制在一頁左右，說明重要內容的保留、改寫、刪除、30 秒電梯演講版本，以及剋制的視覺調整。

7. 校驗與預覽

執行：

python3 /path/to/yanfu/scripts/validate_delivery.py /path/to/output

修復所有錯誤。

瀏覽器可用時：

• 開啟生成頁面。
• 檢查桌面端與移動端。
• 驗證 CTA、外鏈和本地資源。
• 檢查溢位、遮擋、截圖不可讀和資訊層級問題。

不得只檢查原始碼就宣稱交付完成。

交付

依次返回：

1. landing.html 的本地預覽連結或路徑。
2. yanfu-notes.md 的路徑。
3. 一句話說明仍需開發者確認的最高優先順序內容。

優先返回頁面。除非使用者明確要求原始碼，否則不要在對話中貼上完整 HTML。

快速判斷

常見錯誤

• 把故事翻譯變成產品定位診斷。
• 用通用創業文案替換產品原本的語言。
• 把可見介面當成效率、準確率或滿意度證明。
• 發明原始材料中不存在的理想使用者故事。
• 因為存在更美的方案就重做品牌。
• 只交付評價，不交付可用 HTML 頁面。

這個 Skill 質量較好。核心優勢是定位明確——專門做產品落地頁的“翻譯”而非重新設計，原則清晰（信、達、雅）且邊界清楚，避免了常見的內容誇大或過度創作問題。文件體系完整，從證據採集到最終交付的流程都有詳細指導，風險提示也比較到位。不足之處是缺少實際可用的指令碼工具，更多依賴文件描述而非自動化執行，生成效果較依賴模型本身的理解和表達能力。對於有明確素材（URL + 截圖）的使用者來說，這是一個結構嚴謹、風險可控的方案。