post-claude-code-astro-install 開發紀錄

Base directory for this skill: ***/codotx-blog

# 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 = (月搜尋量 × 意圖權重) / 難度分數`***/ 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
```***/H3 小標結構
- 切入角度是什麼（教學、比較、踩坑、觀點）
- 涵蓋了哪些子主題，有沒有遺漏的面向
- 內容深度如何（淺層介紹 vs 深入實作）
- 有沒有我們能補充的缺口或差異化的空間

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

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

`keyword_overview` 回傳的資料已包含 `search_intent`***/H3 小標讓 AI 容易理解內容架構
- FAQ Schema 的問答要精準對應這類搜尋問句

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

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

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

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

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

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

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

```***/ 交易型]（來自 keyword_overview 的 search_intent 欄位）
競品差異化角度：[一句話描述我們的切入點跟前 5 名有什麼不同]
```***/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 標題，兩者可以不同但都必須包含焦點關鍵字。

### 檔案命名

`英文-slug.md`，放在 `src/data/news/` 底下。slug 用小寫英文加連字號，不帶日期前綴。日期只寫在 frontmatter 的 `pubDate` 欄位。

## 文章結構

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

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

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

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

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

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

```
起因：什麼事情觸發了這個想法
經歷：發生了什麼事，時間線敘事
轉折：出乎意料的發展
反思：學到了什麼
```***/ 入門文章** | 非技術背景讀者 | 用比喻和日常情境解釋技術概念，避免未經解釋的術語。像寫給朋友的推薦信 |

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

### 語氣校準表

| 太正式 | 適當 | 太隨便 |
|--------|------|--------|
| 我認為我們需要對此進行深入的討論 | 這個問題值得進一步討論 | 這個要好好喬一下 |
| 予以高度重視 | 我們很重視這個問題 | 超在意的 |
| 經由詳細的調查分析 | 排查之後發現 | 隨便 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/` 底下：

```***/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 結構化資料：

```***/script>
```

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

## CTA 結尾（必須包含）

> **⚠️ 強制規則：每篇文章最後都必須有 CTA，包含聯絡頁連結和 LINE 官方帳號連結。沒有 CTA 的文章不算完成。**

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

```***/vrf7844t)聊聊你的專案。
```

- 用一條水平線 `---` 與正文分隔
- 一到兩句話就好，不要寫成一整段推銷
- 聯絡頁連結固定指向 `/contact/`
- LINE 官方帳號連結固定指向 `https://page.line.me/vrf7844t`
- 兩個連結都必須出現
- 語氣自然，像是「有需要就聊聊」而不是「立即諮詢獲取專屬方案」
- 可以根據文章主題微調用語，但連結目標不變

## 內部連結策略

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

### 寫作時

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

### 寫完後

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

```***/) → 在「效能優化」段落加連結指向本文
```***/H3 小標中
- LSI 語意關聯詞自然融入內文
- metaTitle ≤ 32 中文字元，含焦點關鍵字
- metaDescription 50-76 中文字，含焦點關鍵字 + 長尾關鍵字
- 無關鍵字同類相食（沒有跟既有文章搶同一組關鍵字）
- 有 FAQ 區塊，Schema JSON-LD 與可見內容一致
- 有 2-4 個內部連結，並列出建議互連的舊文章
- 文章末尾有 CTA，包含 `/contact/` 和 LINE 官方帳號連結
- 關鍵字讀起來自然，沒有硬塞的感覺

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


ARGUMENTS: 根據第一篇文章 ***/claude-code-blog-setup-concepts.md 的風格與系列脈絡，撰寫第二篇文章，主題是簡單介紹 Astro 的結構與特色以及安裝方法，對象是非技術人員

請幫我從 Claude Code 的角度切入 要延續上一篇文章的內容

可以

加入修改網站名稱、選單、新增文章的說明

新增了第一篇文章 這階段請加入之前寫過的 skill 產文文章

讓 Claude Code 建立 Astro 專案
準備好了，打開終端機，啟動 Claude Code。然後跟它說：
幫我用 Astro 建立一個部落格專案，放在桌面上，專案名稱叫 my-blog 這邊的順序改成：

1. 自己先在桌面建立一個 MyBug 的資料夾
2. 開啟終端機，使用 cd 空格
3. 把這個資料夾拖曳進去
4. 輸入 .claude 進入 .claude 的互動環境

my-blog，然後終端機幫我用 warp，我之前的文章有寫過

Node.js 是讓 Astro 能在你電腦上運作的底層引擎。你不需要知道它的細節，只需要確認有裝就好。打開終端機，輸入： 這邊也要調整成用 Warp

在終端機裡輸入 cd （cd 後面加一個空格），然後把桌面上的 my-blog 資料夾用滑鼠拖曳到終端機視窗裡。終端機會自動填入資料夾的完整路徑，按下 Enter 就進去了。這在 window 上也能這樣做嗎？

[Image]

這張圖會很大嗎？

size 呢？

檔案尺寸呢？

[Image]

[Image]

[Image]

[Image]

[Image]

[Image]

[Image]