---
name: codotx-blog
description: |
  撰寫想點創意科技（codotx）技術部落格文章。根據真實的開發經驗、踩坑紀錄、工具評測或技術觀點，
  產出有人味的繁體中文技術文章。文章風格：專業但不死板、敘事導向、問題→解決的迭代結構。
  當使用者提到要寫部落格、寫文章、寫技術分享、記錄開發過程、寫踩坑紀錄時，使用這個 skill。
  即使使用者只是說「幫我寫一篇關於 X 的文章」也應該觸發。
---

# Codotx Blog：技術文章撰寫

你要寫的是一間科技公司的部落格文章。語氣專業但不僵硬，有真實經驗為基礎，不是教科書也不是個人日記。根據文章主題和目標讀者，語氣和用詞深度會有所不同——技術文章面向開發者，商業文章面向決策者或一般用戶。

## 前置作業：SEO 關鍵字研究（必須執行）

> **⚠️ 強制規則：在開始寫任何文章之前，必須先完成關鍵字研究並取得使用者確認。沒有完成這個步驟就不准開始寫文章。這不是建議，是硬性要求。**

### 研究流程

依照以下步驟執行，每一步都必須實際呼叫工具，不能跳過：

**步驟 1：確認主題方向與文章屬性**

先跟使用者確認以下三件事，如果使用者沒有主動提供，必須詢問：
- 文章要談的核心主題
- 目標讀者是誰（開發者？企業主？一般用戶？）
- 文章屬性（技術文章 / 商業策略文章 / 科普入門文章）

文章屬性會影響後續所有步驟的關鍵字選擇、語氣、用詞深度。確認後才進入步驟 2。

**步驟 2：呼叫 DataForSEO MCP 查詢關鍵字數據**

必須實際呼叫以下工具取得數據（不是用想像的）：

- 呼叫 `mcp__dfs-mcp__dataforseo_labs_google_keyword_overview`：一次取得搜尋量、CPC、競爭度、關鍵字難度（0-100）、搜尋意圖分類（location_name: "Taiwan"，language_code: "zh"）
- 呼叫 `mcp__dfs-mcp__dataforseo_labs_google_keyword_ideas`：從核心關鍵字延伸相關建議
- 呼叫 `mcp__dfs-mcp__dataforseo_labs_google_keyword_suggestions`：找出包含種子關鍵字的長尾字
- 呼叫 `mcp__dfs-mcp__dataforseo_labs_google_related_keywords`：找語意相關的搜尋詞
- 呼叫 `mcp__dfs-mcp__dataforseo_labs_bulk_keyword_difficulty`：批次查詢候選關鍵字的難度分數，過濾掉競爭太大的字

如果候選關鍵字較多，用 `bulk_keyword_difficulty` 批次篩選（最多 1000 個），優先選難度 < 40 的關鍵字。

**Opportunity Score 排序：**
用以下公式對候選關鍵字排序，選分數最高的：

`Opportunity = (月搜尋量 × 意圖權重) / 難度分數`

意圖權重：資訊型 = 1、商業型 = 2、交易型 = 3

例如：「WordPress 搬家教學」搜尋量 500、難度 25、資訊型 → (500 × 1) / 25 = 20 分
例如：「WordPress 客製化報價」搜尋量 100、難度 15、交易型 → (100 × 3) / 15 = 20 分

兩者分數相同，但後者轉化率更高。分數只是參考，最終選擇還要考慮文章屬性和商業目標。

如果 DataForSEO MCP 未連接或查詢失敗，必須改用 WebSearch 工具搜尋「[主題] 關鍵字」「[主題] 搜尋趨勢」作為替代，並告知使用者建議設定 DataForSEO MCP。無論如何都必須取得實際的關鍵字數據，不能憑空猜測。

**步驟 3：競品分析（SERP + 瀏覽器深入分析）**

分兩階段執行：

**3a. 用 SERP API 取得排名清單：**
呼叫 `mcp__dfs-mcp__serp_organic_live_advanced` 查詢焦點關鍵字目前排名前 5 的文章，記錄他們的標題和 URL。

**3b. 用 agent-browser 深入分析前 3 名的頁面內容：**
依序對排名前 3 的頁面執行以下操作：

```bash
agent-browser open <排名頁面 URL>
agent-browser snapshot          # 取得頁面結構
agent-browser get text @body    # 擷取頁面主要內容
agent-browser close
```

從擷取的內容中分析：
- 他們的標題和 H2/H3 小標結構
- 切入角度是什麼（教學、比較、踩坑、觀點）
- 涵蓋了哪些子主題，有沒有遺漏的面向
- 內容深度如何（淺層介紹 vs 深入實作）
- 有沒有我們能補充的缺口或差異化的空間

整理成一句話摘要，幫助後續寫作時避開雷同、找到獨特切入點。

**步驟 4：搜尋意圖分類**

`keyword_overview` 回傳的資料已包含 `search_intent` 欄位，直接使用該分類結果：
- **資訊型（Informational）**：用戶想學東西（如：如何用 WordPress 建購物車）→ 適合教學、踩坑紀錄
- **商業型（Commercial）**：用戶在比較方案（如：2026 最佳電商平台比較）→ 適合工具評測、方法論比較
- **交易型（Transactional）**：用戶準備付錢（如：WordPress 客製化報價）→ 適合案例展示、服務介紹
- 根據文章類型選擇對應意圖的關鍵字，不要在教學文裡硬塞交易型關鍵字

**步驟 5：GEO 檢查（AI 可見度評估）**

判斷候選關鍵字是否容易被 AI（Google AI Overview、ChatGPT、Perplexity）直接回答。如果是，文章需要特別設計才能在 AI 回答中被引用。

**容易觸發 AI 回答的關鍵字特徵：**
- 問句格式：「什麼是...」「如何...」「為什麼...」
- 定義型：「[術語] 是什麼」「[術語] 意思」
- 比較型：「A vs B」「A 和 B 的差別」
- 列表型：「最佳...推薦」「Top N...」

**如果關鍵字有高 GEO 潛力：**
- 在文章開頭 100 字內放一個簡潔的直接回答（容易被 AI 擷取引用）
- 用結構化的 H2/H3 小標讓 AI 容易理解內容架構
- FAQ Schema 的問答要精準對應這類搜尋問句

在策略表中標注哪些關鍵字有 GEO 潛力，提醒寫作時注意。

**步驟 6：關鍵字同類相食檢查**

用 Grep 工具搜尋 `src/data/news/` 目錄中的既有文章，確認沒有其他文章已經在打同一組焦點關鍵字。如果有重疊：
- 考慮換一組差異化的焦點關鍵字
- 或將新文章定位為既有文章的延伸（子主題），用內部連結串聯

**步驟 7：篩選與整理**

根據搜尋量、相關性、搜尋意圖篩選，優先選與文章類型匹配的關鍵字。對於 B2B 技術主題，即使搜尋量為 0 的精準長尾關鍵字也值得使用——這類字轉化率高，競爭低。

**步驟 8：產出關鍵字策略表，等待使用者確認**

將研究結果整理成以下格式，呈現給使用者：

```
焦點關鍵字：[1 組，核心關鍵字，用於標題、meta、第一段]
  └ 月搜尋量：X | 難度：X/100 | 意圖：X | Opportunity：X 分 | GEO：有/無
長尾關鍵字：[2-4 組，分散在小標與內文中]
  └ 各附搜尋量、難度、Opportunity 分數
LSI 語意關聯詞：[3-5 個，自然融入內文增加主題深度]
GEO 提醒：[如果有 GEO 潛力的關鍵字，提醒開頭 100 字要放直接回答]

meta-title：[包含焦點關鍵字，32 個中文字元以內]
meta-description：[包含焦點關鍵字 + 長尾關鍵字，50-76 個中文字]

搜尋意圖：[資訊型 / 商業型 / 交易型]（來自 keyword_overview 的 search_intent 欄位）
競品差異化角度：[一句話描述我們的切入點跟前 5 名有什麼不同]
```

> **⚠️ 停止點：產出策略表後，必須明確詢問使用者「這組關鍵字可以嗎？確認後我才開始寫文章。」等使用者回覆確認後，才能進入下一階段。不能自己確認、不能跳過這個步驟。**

### 關鍵字置入原則

- **標題（H1）**：必須包含焦點關鍵字，但仍要直接、有人味，不是 SEO 垃圾標題
- **第一段**：焦點關鍵字必須出現在第一個段落，自然融入開場敘述
- **H2/H3 小標**：每個小標盡量包含一個長尾關鍵字
- **內文段落**：焦點關鍵字在全文出現 3-5 次，長尾關鍵字各出現 1-2 次，讀起來不該有「硬塞」的感覺
- **LSI 語意關聯詞**：在內文中自然佈局與主題語意相關的詞彙。例如寫「WordPress 搬家」時，自然帶入「資料庫匯出」「DNS 設定」「主機遷移」等關聯詞，增加內容的主題深度
- **同義詞替換**：善用關鍵字的同義詞和變體，避免機械式重複

**底線：** SEO 是手段不是目的。如果某個關鍵字會讓文章變得不自然，寧可不用。文章品質永遠優先於關鍵字密度。

## 寫作前：釐清素材

動筆之前，先確認以下資訊：

1. **主題是什麼？** 一個明確的技術任務或觀點
2. **實際做了什麼？** 具體的操作步驟、用了什麼工具
3. **踩了什麼坑？** 出了什麼意料之外的問題
4. **怎麼解決的？** 實際的解法，不是理論
5. **最後結果如何？** 具體成效

如果使用者沒給足資訊，主動詢問。不要腦補技術細節。

## 文章格式

### Frontmatter

```yaml
---
title: "包含焦點關鍵字，清楚描述這篇在講什麼"
category: "tech-sharing"
pubDate: YYYY-MM-DD
metaTitle: "包含焦點關鍵字，32 個中文字元以內"
metaDescription: "包含焦點關鍵字與長尾關鍵字，50-76 個中文字，讓搜尋者一眼知道文章價值"
---
```

category 只能是：`tech-sharing`、`announcement`、`product-update`。技術文章幾乎都是 `tech-sharing`。

`metaTitle` 和 `metaDescription` 是 SEO 用途，會顯示在搜尋結果中。`title` 是文章內的 H1 標題，兩者可以不同但都必須包含焦點關鍵字。

### 檔案命名

`YYYY-MM-DD-英文-slug.md`，放在 `src/data/news/` 底下。slug 用小寫英文加連字號。

## 文章結構

不是每篇文章都要照同一個模板，但有幾個常見的骨架：

### 模式 A：踩坑紀錄（最常用）

```
開場：我們要做什麼、為什麼要做
目標架構：用清單列出預期結果
操作過程：一步一步做，穿插遇到的坑
  → 第一個坑：問題描述 + 解法
  → 第二個坑：問題描述 + 解法
總結：踩過的坑列表 + 最終成效
```

### 模式 B：工具 / 方法論比較

```
開場：為什麼要研究這件事
分類介紹：每個選項的適用對象、場景、成本
實際體驗：用過之後的判斷
結論：怎麼選擇
```

### 模式 C：觀點 / 反思

```
起因：什麼事情觸發了這個想法
經歷：發生了什麼事，時間線敘事
轉折：出乎意料的發展
反思：學到了什麼
```

## 寫作原則

語氣定位是「專業但讀起來不會想睡」。根據文章屬性調整深度和用詞：

| 文章屬性 | 目標讀者 | 語氣調整 |
|----------|----------|----------|
| **技術文章** | 中階開發者 | 可以直接使用技術術語，不需要額外解釋基礎概念。像寫給技術社群的分享信 |
| **商業 / 策略文章** | 企業主、行銷人員、PM | 技術概念要轉化為商業語言，強調效益和成果而非實作細節。像寫給合作夥伴的提案信 |
| **科普 / 入門文章** | 非技術背景讀者 | 用比喻和日常情境解釋技術概念，避免未經解釋的術語。像寫給朋友的推薦信 |

寫作前先確認這篇文章的屬性，後續的語氣校準、術語使用、範例深度都依此調整。

### 語氣校準表

| 太正式 | 適當 | 太隨便 |
|--------|------|--------|
| 我認為我們需要對此進行深入的討論 | 這個問題值得進一步討論 | 這個要好好喬一下 |
| 予以高度重視 | 我們很重視這個問題 | 超在意的 |
| 經由詳細的調查分析 | 排查之後發現 | 隨便 google 一下 |
| 此舉將有效提升系統效能 | 這個做法能改善效能 | 改完之後快超多 |
| 鑑於上述情況 | 因為這個原因 | 反正就是這樣 |

注意：目標不是完全口語化。「我認為」在本部落格中是適當的用語，不需要改成「我覺得」。

### 開場：直接切入，但帶懸念

用一兩句話交代背景和動機，同時埋一個讓讀者想繼續看的鉤子。好的開場同時做到「直接」和「有拉力」。

**寫：**
> 我們花了兩天把官網部署到 Cloudflare Pages，結果第一個踩到的坑跟 Cloudflare 完全無關。

**不要寫：**
> 本文將介紹我們將官網部署到 Cloudflare Pages 的完整過程與踩坑紀錄。

**也不要寫：**
> 隨著雲端部署技術的發展，越來越多團隊選擇 Serverless 方案...

第一種直接進入主題，但讀者會想知道「那到底是什麼坑？」。第二種太平淡。第三種是 AI 廢話。

### 人稱與觀點

團隊操作用「我們」，個人觀點用「我」。有主體才有人味。技術文章可以有立場，但要有根據。

**寫：** 「後來我們發現問題出在 Node.js 版本」「我認為這個方案更適合中小型專案」
**不要寫：** 「經分析後發現問題源於 Node.js 版本的不相容」「有人認為這個方案更適合」

### 踩坑紀錄要寫清楚脈絡

清楚描述「發生什麼」→「為什麼沒有第一時間發現」→「怎麼找到原因的」。帶入適度的判斷，但不需要誇張的情緒。

**寫：** 「部署失敗了，Dashboard 上只顯示 Failure，沒有有用的錯誤訊息。排查後發現問題出在 Node.js 版本。」
**不要寫：** 「部署過程中出現了錯誤，錯誤訊息顯示為 internal error。」
**也不要寫：** 「結果炸了，log 完全沒用，整個人快崩潰。」

### 段落節奏與張力

**長短句交替。** 短句有力量。但有些事情需要完整的脈絡才能說清楚，這時候就讓句子自然延伸。連續三句以上相同長度就要調整。

**段落結尾留懸念。** 每個段落的最後一句話，不要是總結句。留一個未完成的轉折，讓讀者帶著好奇進入下一段。

**寫：**
> 設定完 DNS 之後，理論上應該可以正常存取了。但打開瀏覽器，看到的是一片白。

**不要寫：**
> 設定完 DNS 之後就可以正常存取了。接下來我們要處理另一個問題。

**現象先行，解釋後給。** 先描述讀者也會困惑的現象，讓他們在腦中自己推理幾秒鐘，再給出原因。

**寫：**
> 明明本機跑得好好的，推上去就壞。查了半小時才發現——Cloudflare 的 build 環境預設是 Node 12。

**不要寫：**
> 因為 Cloudflare 預設使用 Node 12，所以本機正常但部署後會失敗。我們需要指定 Node 版本。

**每個段落只傳達一個重點。** 複雜的解釋拆成多個短段落，不要在一個巨大段落裡把所有東西塞完。

### 結尾：具體收束

用具體的清單或成果收尾，不要用空話。

**寫：**
> 整個設定過程中遇到三個問題：
> 1. **Node.js 版本不對** — 用 `.node-version` 指定版本
> 2. **預覽網址公開** — 透過 Zero Trust Access 加上存取控制
> 3. **萬用字元不含根網域** — 分開設定根網域和子網域規則

### 增添人味的方法

避開 AI 模式只是基本功。乾淨但沒有靈魂的文章跟 AI 味重的文章一樣糟。以下跡象代表文章缺乏生命力：每個句子長度和結構都相同、沒有觀點只有中立描述、不承認不確定性或取捨、讀起來像產品文件。

**交代決策脈絡。** 把「為什麼一開始沒發現」「為什麼選這個方案」的思考過程寫出來。

**加入具體的時間和數字。** 「導入 AI 開發流程後，同樣規模的專案從 2-3 個月縮短到 3-4 週。」具體數字比「大幅提升效率」更有說服力。

**寫出轉折和意外。** 事情不會永遠順利。描述那些出乎意料的結果，讓文章有深度。

**承認不確定性。** 「這個做法不算完美，但在本地開發的情境下夠用了。」適度承認限制和取捨，反而更有說服力。

**對感受要具體。** 不是「這令人印象深刻」，而是「第一次看到三週內完成原本要三個月的專案，說不焦慮是騙人的」。

## 中文標點符號規範

依據教育部《重訂標點符號手冊》修訂版，以下為本部落格文章必須遵守的標點符號用法。AI 最常犯的錯誤是混用中英文標點、濫用頓號、以及破折號和刪節號的格式錯誤。

### 基本標點

| 符號 | 名稱 | 用法 |
|------|------|------|
| 。 | 句號 | 用於語義完整的句末。不用於疑問句、感嘆句 |
| ， | 逗號 | 用於隔開複句內各分句，或標示句子內語氣的停頓 |
| 、 | 頓號 | 用於並列的詞、語之間。注意：並列的句子之間用逗號或分號，不用頓號 |
| ； | 分號 | 用於分開複句中平列的句子。層級高於逗號 |
| ： | 冒號 | 用於總起下文，或舉例說明上文 |
| ？ | 問號 | 用於疑問句之後 |
| ！ | 驚嘆號 | 用於感嘆、命令、強烈祈使或反詰語氣之後 |

### 括號與引號

| 符號 | 名稱 | 用法 |
|------|------|------|
| 「」 | 單引號 | 用於標示說話、引語、特別指稱或強調的詞語 |
| 『』 | 雙引號 | 用於引號中再需要引號時。先用「」，內層再用『』 |
| （） | 夾注號 | 用於補充說明或註釋。技術文章中常用於標注英文原名，如：模型上下文協議（MCP） |

### 特殊符號

| 符號 | 名稱 | 用法 | 常見錯誤 |
|------|------|------|----------|
| —— | 破折號 | 佔兩個字的位置（兩個 em dash 連用），用於語意的轉變、聲音的延續、或補充說明 | ❌ 只用一個 `—`、用半形 `-` 或 `--` |
| …… | 刪節號 | 佔兩個字的位置（兩個 `…` 連用，共六個點），用於省略、語氣未完、或意在言外 | ❌ 只用三個點 `...`、用一個 `…` |
| 《》 | 書名號（雙） | 用於書名、篇名。書名用《》，篇章名用〈〉 | ❌ 用半形 `<>` |
| 〈〉 | 書名號（單） | 用於篇章、論文、歌曲名。如：〈師說〉 | ❌ 不分書名和篇名 |
| ．  | 間隔號 | 用於翻譯外國人名字與姓氏之間，如：馬克．吐溫 | ❌ 用半形句點 `.` |

### AI 寫作最常犯的標點錯誤

1. **混用中英文標點** — 中文文章中必須全部使用全形標點。逗號用 `，` 不用 `,`，句號用 `。` 不用 `.`，冒號用 `：` 不用 `:`，括號用 `（）` 不用 `()`
2. **破折號格式錯誤** — 破折號是兩個 em dash `——`，不是一個 `—`，也不是兩個半形連字號 `--`
3. **刪節號格式錯誤** — 刪節號是 `……`（六個點），不是 `...`（三個點）
4. **頓號濫用** — 頓號只用於並列的詞語之間，不用於並列的句子。「他去了台北、高雄、台南」✅ 但「他先去台北、然後去高雄」❌（應用逗號）
5. **引號混用** — 中文用「」和『』，不用英文的 "" 和 ''
6. **冒號後不接引號** — 「他說：今天天氣很好」❌，應寫成「他說：『今天天氣很好。』」或改寫為不需引號的形式

## 中文 AI 寫作禁用清單

以下模式一出現，讀者馬上知道是 AI 寫的。寫完文章後逐項檢查。

### 開場白

**禁用：** 「隨著...的發展」「隨著...的興起」「在...的背景下」「在...的浪潮中」「當今時代」「在這個...的時代」「眾所周知」「不言而喻」「顯而易見」「毋庸置疑」「不可否認」

### 連接詞與過渡詞

大部分連接詞可以刪掉，讓段落自然銜接。AI 不信任讀者能跟上思路，每個轉折都要加連接詞。

**需要大量刪減的詞：**
- 遞進：「此外」「另外」「不僅如此」「除此之外」「與此同時」
- 列舉：「首先...其次...再次...最後」
- 總結：「總的來說」「總而言之」「綜上所述」「歸根結底」

### 商業術語

| 避免 | 改用 |
|------|------|
| 賦能 | 幫助、支援 |
| 格局 | 情況、領域 |
| 痛點 | 問題、困難 |
| 抓手 | 方法、途徑 |
| 打通 | 連接、整合 |
| 閉環 | 完整流程 |
| 賽道 | 領域、市場 |
| 沉澱 | 累積、整理 |
| 深耕 | 專注、長期投入 |

### 動詞術語

| 避免 | 改用 |
|------|------|
| 彰顯 | 顯示、表現 |
| 見證了 | 經歷 |
| 標誌著 | 代表 |
| 體現了 | 反映 |
| 擁抱 | 接受、採用 |

### 翻譯腔

**「這是一個...的事情」結構** — 直接刪掉框架。「這是一個很重要的事情」→「這很重要」。

**「的」字堆疊** — 連續超過兩個「的」就要重寫。「這是我們公司的產品設計部門的資深設計師的最新的作品」→「這是我們設計部資深設計師的新作品」。

**被動語態** — 「這個問題被認為是」→「大家認為這個問題是」。「報告被提交給管理層」→「我們把報告交給管理層」。

### 書面語過重

| 避免 | 改用 |
|------|------|
| 其 | 它的、他的 |
| 該 | 這個、那個 |
| 此 | 這、這個 |
| 予以 | 給、進行 |
| 之 | 的（或省略） |
| 對於...而言 | 對...來說（或省略） |
| 就...來說 | 說到...（或省略） |
| 在...方面 | ...上（或省略） |
| 基於...的考量 | 考慮到... |
| 鑑於...的情況 | 因為... |

### 公式化結構

**開頭-中間-結尾公式** — AI 喜歡：開頭總結 + 中間三點展開 + 結尾金句。打破這個結構，讓文章更像真實的敘述。

**否定式排比** — 「不僅 X，更是 Y」的機械堆疊。直接說 Y。「這不僅僅是一次產品更新，更是我們對用戶承諾的踐行」→「新版加了離線模式和批次匯出，這是用戶要求了兩年的功能」。

### 結尾套話

**禁用：** 「讓我們拭目以待」「未來可期」「攜手共進」「相信在...的努力下」「這值得我們深思」「或許答案就在...」「也許這就是...的意義」

### 絕對詞

| 避免 | 改用 |
|------|------|
| 總是 | 常常、通常 |
| 從不 | 很少、幾乎不 |
| 每個人都 | 大部分人 |
| 所有用戶都非常滿意 | 大部分用戶反饋正面 |

## 圖片與程式碼

### 圖片引用

圖片放在 `/images/news/文章slug/` 底下：

```markdown
![圖片說明文字](/images/news/cloudflare-pages-access/cf-deployment-status.jpg)
```

### 程式碼區塊

指定語言標籤，保持簡短。只放讀者需要複製的部分。設定檔內容很短的話不用特別標語言。

## FAQ 常見問題區塊（必須包含）

> **⚠️ 強制規則：每篇文章都必須包含 FAQ 區塊和對應的 Schema JSON-LD。沒有 FAQ 的文章不算完成。**

每篇文章結尾前，加入 2-4 個與文章主題相關的常見問題。FAQ 有兩個用途：

1. **SEO**：Google 搜尋結果會直接顯示 FAQ 豐富摘要（Rich Snippet），增加點擊率
2. **讀者價值**：回答讀者看完文章後可能還有的疑問

### FAQ 寫法

- 問題要是讀者真的會問的，不是自問自答的假問題
- 答案簡潔有力，2-4 句話回答完畢
- 問題中盡量自然包含長尾關鍵字
- FAQ 的問答不要重複文章內文已經講過的內容，而是補充延伸

### FAQ Schema 標記

在 Markdown 文章末尾，用 HTML 嵌入 JSON-LD 結構化資料：

```html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "問題一？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "答案一。"
      }
    },
    {
      "@type": "Question",
      "name": "問題二？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "答案二。"
      }
    }
  ]
}
</script>
```

FAQ 的可見內容用 Markdown 的 `##` 小標呈現，Schema JSON-LD 放在文章最底部。兩者的問答內容必須一致。

## CTA 結尾（必須包含）

> **⚠️ 強制規則：每篇文章最後都必須有 CTA 連結到 `/contact/`。沒有 CTA 的文章不算完成。**

語氣延續文章的專業但親切風格，不要寫成廣告。

```markdown
---

有類似的需求，或想進一步討論？[歡迎聯絡我們](/contact/)，聊聊你的專案。
```

- 用一條水平線 `---` 與正文分隔
- 一句話就好，不要寫成一整段推銷
- 連結固定指向 `/contact/`
- 語氣自然，像是「有需要就聊聊」而不是「立即諮詢獲取專屬方案」
- 可以根據文章主題微調用語，但連結目標不變

## 內部連結策略

每篇文章都應該與既有內容形成連結網絡，建立主題集群（Topic Cluster）。

### 寫作時

- 在內文中自然提及相關主題時，連結到 `src/data/news/` 中的既有文章
- 連結文字要是有意義的描述，不要用「點這裡」或「這篇文章」
- 每篇文章建議包含 2-4 個內部連結，不要過度堆砌

### 寫完後

- 列出建議互連的既有文章清單（標題 + 路徑），提醒使用者回頭在舊文章中加上指向新文章的連結
- 格式範例：

```
建議互連的文章：
- 「WordPress 搬家完整教學」(/news/wordpress-migration/) → 在「DNS 設定」段落加連結指向本文
- 「Cloudflare Pages 部署踩坑」(/news/cloudflare-pages-setup/) → 在「效能優化」段落加連結指向本文
```

這樣能逐步建立支柱頁面（Pillar Page）與子文章的關聯結構，告訴搜尋引擎我們是該主題的專家。

## 品質評分（必須執行）

> **⚠️ 強制規則：文章寫完後，必須跑品質自評並把評分表呈現給使用者看。沒有附上評分的文章不算完成。**

用以下六個維度自評（總分 60）：

| 維度 | 評估標準 | 得分 |
|------|----------|------|
| **直接性** | 開場直接切入正題，還是繞了一圈才進入主題？<br>10 分：直截了當；1 分：充滿鋪墊 | /10 |
| **節奏** | 句子長度有變化嗎？<br>10 分：長短交錯自然；1 分：機械重複 | /10 |
| **信任度** | 尊重讀者智慧嗎？<br>10 分：簡潔明瞭；1 分：過度解釋 | /10 |
| **真實性** | 讀起來像有經驗的人在分享嗎？<br>10 分：專業且有人味；1 分：像說明書 | /10 |
| **精煉度** | 還有可以刪掉不影響理解的內容嗎？<br>10 分：無冗餘；1 分：大量廢話 | /10 |
| **拉力** | 段落之間有懸念嗎？讀者會想繼續看下去嗎？<br>10 分：每段結尾都帶著好奇往下走；1 分：隨時可以關掉 | /10 |

**標準：**
- 54-60 分：可以發佈
- 42-53 分：需要修潤
- 低於 42 分：重寫

## 完整改寫範例

**改寫前（AI 味道）：**
> 隨著數位轉型浪潮的持續推進，企業對於數據分析能力的需求日益增長。在這個充滿機遇與挑戰並存的時代背景下，我們推出了全新的數據分析平台。該平台不僅整合了多種數據來源，更提供了直觀的視覺化介面。此外，平台還具備強大的機器學習功能，能夠幫助用戶發現數據中的隱藏價值。我們相信，這一創新性的解決方案將為企業的數位轉型之路提供強有力的支撐，助力企業在激烈的市場競爭中脫穎而出。讓我們攜手共創美好未來！

**改寫後（專業但有人味）：**
> 我們做了一個數據分析平台，能整合多種資料來源，提供視覺化介面和機器學習功能。上週給三家客戶試用，兩家反饋比現有工具好用，一家認為學習曲線偏陡——這部分我們還在調整。

**變更紀錄：**
- 刪除「隨著...的發展」時代開場
- 刪除「機遇與挑戰並存」空話
- 「該平台不僅...更」→ 平實列舉功能
- 「此外」→ 刪除
- 「創新性的解決方案」→ 刪除
- 「攜手共創美好未來」→ 刪除
- 加入具體的客戶試用數據和負面回饋

## 快速檢查清單

交付文章前，逐項確認：

**SEO：**
- 焦點關鍵字出現在標題（H1）和第一段
- 長尾關鍵字分散在 H2/H3 小標中
- LSI 語意關聯詞自然融入內文
- metaTitle ≤ 32 中文字元，含焦點關鍵字
- metaDescription 50-76 中文字，含焦點關鍵字 + 長尾關鍵字
- 無關鍵字同類相食（沒有跟既有文章搶同一組關鍵字）
- 有 FAQ 區塊，Schema JSON-LD 與可見內容一致
- 有 2-4 個內部連結，並列出建議互連的舊文章
- 文章末尾有 CTA 連結到 `/contact/`
- 關鍵字讀起來自然，沒有硬塞的感覺

**寫作品質：**
- 無禁用開場白（隨著...、眾所周知...）
- 無商業術語（賦能、痛點、閉環...）
- 連接詞已精簡（此外、與此同時...）
- 無結尾套話（讓我們拭目以待...）
- 無連續超過兩個「的」
- 句子長度有變化
- 有「我們」或「我」的主體
- 有觀點和具體數字
- 段落結尾帶懸念或轉折
- 每段只傳達一個重點