wvvb/網站文案撰寫

網站文案撰寫 是做什麼的？

一個網站應該讓對的人辨識出自己的處境，理解產品的功能，並知道下一步該怎麼做。

原則： 從訪客的現實出發向外書寫，而不是從產品功能列表向內寫。文案必須聽起來像一個理解這項工作的人所寫，而不是像一個行銷人員在解釋行銷如何運作。

這是一個寫作和資訊設計的技能，不是AI檢測器，也不是僵化的轉換公式。不要為了聽起來「像人類」而犧牲真實性、可及性或精準度。

證據標籤

版本 1.1。 標籤僅出現在效用主張上：即聲稱能改善辨識度、理解度、信任度或轉換率的陳述。義務和工作流程步驟則不進行分級。

• [E] 經驗證的直接證據：經同儕審查的研究或有文件記錄的測試，衡量了所聲稱的效果，並附有效果大小與限制。
• [P] 合理的實務：在沒有針對此受眾的直接衡量證據下，仍屬有用的做法。
• [S] 編輯風格偏好。風格項目在 references/evidence.md 中分級；它們不會在此技能中內聯標記。

此技能中沒有任何規則是 [E] 級別（就落地頁轉換而言）。請將轉換建議視為需要在實際網站上測試的假設，並且在沒有進行測量的情況下切勿承諾提升。此處未標記的效用主張均屬 [P] 級的建議實務；義務和工作流程步驟則不進行分級。每個項目的完整分類、來源和候選實驗，均記載於 references/evidence.md。

非協商規則

1. 以相關性為先。 指出目標訪客能夠識別的具體問題、任務或成果。盡快提及產品，讓訪客理解所提供的內容。[P]
2. 解釋因果連結。 展示產品實際上做了什麼來提供幫助。不要用承諾取代機制。[P]
3. 聽起來自然。 偏好日常用語、具體名詞和普通動詞。對於技術受眾，需維持技術準確性。
4. 在建議的網站文案中不要使用長破折號或短破折號。 改用句號、逗號、冒號或自然改寫。引用來源資料時，保留原始標點符號。如果使用者明確要求不同風格，則遵循該要求。
5. 不製造情緒。 不要捏造痛苦、急迫感、恐懼、統計數據、社會認同、結果或功能。
6. 不強制使用模板。 不要讓每個網站都使用相同的「問題 / 激化 / 解決方案 / 功能 / 見證 / 行動呼籲」順序。根據訪客決策所需來選擇章節。
7. 不要為了重寫而重寫。 如果原文更清晰，就保留它。做出能改善理解度的最小變更。

決定訪客需要理解什麼

在編輯前，檢查使用者提供的資料：即時頁面、螢幕截圖、現有文案、簡報或原始碼。確定：

• 受眾： 誰需要這個？使用可識別的職位或情境，而不是「所有人」。
• 觸發事件： 什麼事件使他們現在尋求幫助？
• 任務： 他們正試圖完成什麼？
• 障礙： 為什麼現有方法失敗或需要太多努力？
• 代價： 這個障礙對他們實際意味著什麼？損失時間、未回答的問題、困惑、風險或金錢。僅包含有背景支持的後果。
• 期望的改變： 什麼能讓他們的下一小時、一天或工作流程變得更好？
• 產品機制： 產品實際上如何促成這種改變？
• 證據： 展示了什麼、記錄了什麼或驗證了什麼？
• 行動： 他們實際上可以點擊、嘗試、請求或閱讀什麼？

保持事實與假設之間清晰的區別。如果缺少細節，請使用保守的語言，並在向使用者的解釋中標記重大假設。不要虛構具體的客戶或工作流程。

建立內部問題模型

將此作為推理輔助工具，切勿作為要發布的文字：

某位處於[真實情境]的人，正試圖[任務]，但[障礙]。他們想要[結果]。產品透過[具體機制]提供幫助。

然後將其提煉為一個可識別的時刻。這個時刻比抽象的分類更重要。

• 抽象：「財務團隊需要簡化的對帳工作流程。」
• 具體：「付款總額與您的交易記錄不符。」
• 抽象：「改善跨分散式部署的可觀測性。」
• 具體：「一次部署失敗了。您正在搜尋三項服務來尋找錯誤。」

一個好的標題可以以問題開頭，也可以以期望結果開頭。選擇能最快告訴目標訪客「這是為我準備的」的方式。如果受眾已經確切知道他們想要什麼，那麼以問題為先的標題不一定是最好的。

組成訊息

在內部思考這些節拍。不要將它們列印為六個相同的網站章節。

1. 識別： 訪客曾經歷過或可以想像的實際情境。
2. 重要性： 那些尚未解決、困難、昂貴或不確定的事項。通常一個具體的後果就足夠了。
3. 緩解： 什麼變得可能或更簡單。
4. 機制： 產品如何幫助訪客達成目標。
5. 可信度： 一個真實的例子、示範、能力、限制或來源，能贏得信任。
6. 下一步行動： 一個行動呼籲，其目標頁面能兌現其承諾。

第一個畫面通常應傳遞識別、解決方案和一個可信的機制，無需訪客滾動。不要花上半頁篇幅來戲劇化一個訪客已經理解的問題。

撰寫主視覺區

• 標題： 關於訪客任務、問題或期望結果的一個清晰想法。具體勝過聰明。
• 支持說明： 用一兩句自然的句子指出幫助對象並描述其運作方式。刪除任何不會改變讀者理解的詞語。
• 行動呼籲： 一個實際的行動，例如「查看範例」、「閱讀文件」、「嘗試示範」或「與維護者交談」，僅在該行動確實存在時使用。
• 視覺元素： 如果存在或需要，優先選用真實的工作流程、介面狀態或前後對比的資料範例，而非抽象的裝飾性隱喻。

標題和支持說明應發揮不同的作用。不要用不同的詞語重複三次相同的承諾。

將解決方案解釋為原因，而非口號

對於每個重要功能，逐步推理：

它做了什麼 -> 對訪客改變了什麼 -> 為什麼這很重要 -> 什麼證據支持這個說法。

範例：

• 能力：在客戶的基礎設施上，針對 Parquet、JSON 和 CSV 執行生成的 SQL。
• 改變了什麼：客戶可以調查這些檔案，而無需將其內容發送給託管分析供應商。
• 意義：他們的資料停留在他們所操作的基礎設施內。
• 範圍：這並不能證明整個系統沒有安全風險。

在主視覺區使用這個鏈結中最相關的部分。如有需要，將其餘部分放在示範、工作流程章節、常見問題或文件中。

讓文案感覺像真人寫的

聽起來像人類的文案通常更具體、較不對稱、且較不熱衷於自我解釋。它感覺像是經過編輯，而非一次生成的。

偏好

• 具體情境而非分類標籤。
• 熟悉的措辭而非概念性術語。
• 僅對該受眾和產品有意義的細節。
• 直接的描述而非空洞的興奮感。
• 在幫助讀者理解想法時，使用不同的句子節奏。
• 能釐清說法的有用範例。
• 誠實的限制、實際的取捨，以及能建立信任的精確技術術語。
• 遵循實際想法的自然過渡，而非預製的連接短語。

移除或改寫

• 行銷填充詞： 當它們取代了實際意義時，請移除「解鎖」、「增壓」、「無縫」、「尖端」、「顛覆性」、「下一代」、「革新」、「賦能」等詞彙。
• 虛假對比： 「它不只是X。它是Y。」、「停止做X。開始做Y。」、「X的未來已經到來。」僅在解釋實際差異時才使用對比，並使用正常語言。
• 宣告式結構： 「在本節中，我們將探討...」、「讓我們開始吧。」、「這就是為什麼這很重要。」不要告訴訪客你即將解釋某事；直接解釋它。
• 重複性陳述： 一個標題、副標題、三個功能卡片和結尾段落都在重複相同的說法。
• 完美對稱的章節： 三張卡片使用相同的語法模式、相同的字數和一個整潔的小結，僅是為了完成版面配置。
• 過度解釋的意義： 「這賦能企業掌控其成功。」如果後果顯而易見，就停止書寫。
• 空洞的情感語言： 「告別頭痛」或「無需再擔心」，卻沒有具體理由。
• 強加的對話技巧： 重複的反問句、虛構的軼事、強迫的幽默、過多的縮寫和做作的脆弱感。
• 聽起來不自然的句法修飾： 密集的名詞片語、形容詞串，以及標點符號在代替清晰句子的功能。

不要將詞彙黑名單作為你的編輯策略。 一個詞在適當的上下文中可能是合適的。上述標點符號要求是一個專案風格規則；更深的任務是修正思想、結構和證據。一個僅僅移除破折號並將「利用」替換為「使用」的文案撰寫者，並未解決問題。

在兩個層級上編輯

結構性檢查：

• 讀者的實際問題是否可見，還是頁面在談論自己？
• 每個章節是否教授了新東西或消除了真正的異議？
• 產品是否在訪客失去興趣之前出現？
• 論述是否只是因為模型預設了模板而顯得線性？
• 是否存在不必要的總結、重複的階段標籤或誇大的新舊對比敘事？
• 內容是否遵循這位特定訪客的決策方式，而非通用的銷售漏斗？

句子層級檢查：

• 一個知識淵博的人真的會對另一個人說這句話嗎？
• 是否有更具體的名詞或動詞？
• 這個句子能否在不移除事實的情況下被刪減？
• 這個句子是否試圖聽起來令人印象深刻，而不是在解釋某事？
• 事實是否準確，好處是否可支持？
• 建議的文案中是否有長破折號或短破折號？移除它們。

以訪客而非作者的身份閱讀結果。如果它聽起來像一場排練過的推銷，請簡化思路，而不是添加更多「人性化」的技巧。

負責任地運用心理學

將心理學上有用的原則作為診斷視角，而非操控人們的藉口。以下每個原則均為 [P]。

• 辨識度： 當人們能識別出所描述的情境時，他們就會參與其中。[P]
• 認知流暢度： 具體的語言和一貫的路徑能減少努力。[P]
• 資訊線索： 標題和行動呼籲應準確預測下一步。[P]
• 控制感： 人們想知道他們可以檢查、更改、保留或撤銷什麼。[P]
• 信任： 證據、實際機制和承認的限制可能比誇大的主張更有用。[P]
• 動機： 文案應連結到訪客想實現的目標，而不是創造不安全感或壓力。[P]

避免虛假的稀缺性、社會認同、捏造的成本節省、無支持的效能比較、操控性的預設選項或暗示的保證。

頁面架構視情況而定

不要為開發者 CLI、財務運營產品和消費者工具製作相同的落地頁。

對於專家或開發者受眾： 通常以實際任務或技術成果為先。及早顯示一個命令、介面、範例、架構細節或文件連結。避免過度解釋一個熟悉的問題。

對於營運買家： 以一個可識別的事件或責任為先。解釋他們可以調查、預防或完成什麼，然後展示工作流程和限制。

對於不熟悉的分類： 及早定義產品，將其錨定在一個已知情境中，並展示人們實際上會如何使用它。新奇本身不是價值主張。

對於單一功能或已經很清晰的頁面： 進行精確的變更。不要硬加上一個冗長的問題故事。

每個章節必須透過回答一個真實的問題或異議來贏得自己的位置。如果不能，就移除它。

範例：Queryance

弱點：以功能為先的版本

為財務運營而生的開源分析工具。將自然語言轉換為 SQL，並在您的基礎設施上對 Parquet、JSON 和 CSV 檔案執行。

這首先描述了機制。它讓訪客自己弄清楚關心的理由。

人類問題版本

找出您的付款數字為何不符。

Queryance 幫助 SaaS 財務團隊調查其記錄之間的差異。提出問題、審查 SQL，並在您自己的基礎設施上對 Parquet、JSON 或 CSV 檔案執行。

行動呼籲： 與維護者交談

第一句話指出了一個實際的工作。第二句話解釋了產品是為誰設計的以及如何運作。僅在確實存在聯繫維護者的方式時，該行動呼籲才適用。

過於誇張的版本

還在淹沒在財務混亂中？

告別過時的試算表。解鎖輕鬆對帳，擁抱下一代智慧財務運營。

這虛構了情緒，依賴行業陳腔濫調，且從未解釋機制。它比好的版本更短，但資訊量更少。

這些範例是起點，而非強制模式。如果真實客戶使用不同的語言，在驗證其含義後，優先採用他們的語言。

執行模式

遵循使用者請求的範圍。

審計

提供前 3 到 5 個具體的文案或層級結構問題。引用相關文字，描述訪客會誤解或錯過什麼，並推薦有針對性的修正。辨識出已經做得好的部分。未經測量，不要聲稱轉換率的提升。

重寫

為請求的章節提供可正式上線的文案，使用網站現有的品牌語調

...

[因翻譯而截斷]