AI Agent Skill 實戰 打造自動化 SEO/AIO 系統

如何透過 AI Agent Skill 自動化你的 SEO 工作流？

Hexo SEO 自動化 的實踐關鍵在於建構一個具備「專業邊界」的 AI Agent Skill。

以本站開發的 hexo-seo-aio 為例，自動化稽核路徑包含：1. 規範定義：透過 seo_standards.md 定義標題字數與禁用詞；2. 量化評分：利用 seo_scoring.md 建立 0-100 分的評估體系；3. 手術刀式優化：透過 replace 指令進行精準修改而非全量覆寫，確保內容安全性；4. 知識累積：將過往踩坑案例寫入 Gotchas (避坑指南)，防止 AI 產生幻覺。這套系統將開發者的 SEO 經驗轉化為可重複執行的數位資產，讓內容生產進入「工業化組裝」時代。

如果你跟我一樣，對「手動調整中英間距」或「反覆確認標題是否過長」感到厭煩，那麼你真正需要的不是更多的 Checklists，而是一個具備專業邏輯的 AI Agent Skill。

在上一篇 AI Agent Skill 開發指南 中我們提過，Skill 是整合了指令、腳本與資源的「數位資產」。今天我將分享如何從零到一打造 hexo-seo-aio，這是一個專為技術部落格設計的自動化優化系統。

一、核心架構：讓 AI 具備「架構覺知」

一個好用的 Skill 不能只有 Prompt，它必須包含結構化的參考資料。我們的 hexo-seo-aio 由三個核心檔案組成：

這種「分離式設計」的好處在於：你可以隨時更新 seo_standards.md 而無需更動核心邏輯，實現真正的 AI-ready Architecture。

二、放置規範：為什麼是 .gemini/skills？

在開發與部署 Skill 時，目錄結構的設計決定了它的「可維護性」與「共享性」。在我們的專案中，結構如下：

1
2
3
4
5
6
7
8

hexo-blog/
├── .gemini/               # AI 代理專用隱藏目錄
│   └── skills/           # 存放所有本地定義的 Skills
│       └── hexo-seo-aio/ # 本次開發的 Skill 主體
│           ├── SKILL.md  # 核心邏輯與 Gotchas
│           ├── examples/ # 優化前後的範例文章 (供 AI 學習風格)
│           ├── references/ # 靜態規範與評分表
│           └── scripts/   # 自動化處理腳本 (如 Tag 清洗)

為什麼要這樣設計？

1. 環境隔離：將 AI 相關的邏輯放在 .gemini 中，可以清楚區分「業務代碼」與「AI 增強邏輯」，不干擾 Hexo 的編譯流程。
2. Git 同步 (Team Sharing)：相較於將 Prompt 存在個人的 AI 工具帳號中，放在 Git 追蹤的目錄下能確保團隊所有成員（以及不同設備上的你）都能使用同一套優化標準。
3. Local Context 優先：Gemini CLI 等現代 AI 工具會優先讀取專案目錄下的 .gemini 配置，這讓 AI 具備了「專案覺知」，能根據當前專案的 GEMINI.md 或 Skill 進行精準決策。

三、避坑指南 (Gotchas)：Skill 最值錢的護城河

為什麼 AI 優化文章常常越改越糟？因為它不知道你的「審美邊界」。在 hexo-seo-aio 中，我們定義了以下最高優先級規範：

• 拒絕廢話開頭：禁止使用「在現今數位化的浪潮下…」等虛詞。
• 禁用詞彙：嚴禁在標題使用「掌握」或「解析」，改用「實踐」或「指南」。
• 中英間距：中英文字與數字之間必須保留「精確的一個半形空格」。
• 手術刀式更新：嚴禁使用 write_file 覆寫全圖，必須使用 replace 進行精準修改。

當這些規則被寫入 Skill，AI 就不再是一個隨機生成的機器人，而是一個遵循你設計風格的「資深編輯」。

四、量化評分：讓 Agent 具備自我修復的「獎勵函數」

在實踐 AI SEO 自動化工作流 時，我們需要一個標準來衡量成果。我們建立的 seo_scoring.md 將文章拆解為七大維度：

1. 標題 (20%)：長度是否在 25-35 字？是否包含主關鍵字？
2. 描述 (15%)：是否有 excerpt？前 150 字是否直接回答問題？
3. 關鍵字策略 (20%)：是否符合「1 主 + 4 次 + 2 問題型」的配比？
4. AIO 結構 (15%)：是否有 FAQ 區塊？是否有條列式整理？

這不僅是給人類看的，更是 Agent 的自我修復邏輯。 傳統協作中，人類需要反覆確認 Agent 的產出。但在 hexo-seo-aio 中，Agent 會先進行「初始評分」，若未達 90 分，它會根據 seo_suggestions 自行啟動「遞歸修復」循環，直到分數達標才向人類回報。這種量化機制將 Agent 從「被動執行者」轉化為「具備目標意識的自我迭代者」。

五、實戰成果：拒絕「Yes 工程師」，擁抱自動化產線

當這套 Skill 佈署完成後，我的寫作流程變成了這樣：

1. 草稿生成：快速記錄技術要點。
2. 呼叫 Skill：gemini "幫我優化這篇文章的 SEO，參考 hexo-seo-aio"。
3. 自動稽核與修復：Agent 不會問我「這段這樣寫可以嗎？」，而是自動補強內外部連結、修正間距、補全 FAQ，並執行 check_links.py 確保連結有效。
4. 評分驗證：只有在 Agent 自我驗證分數達標後，才會呈現最終結果。

這就是 Vibe Coding 的核心——人類定義「意圖」，Agent 負責「實現」與「驗證」。我們不再是那個只會按 Yes 的點頭工程師，而是負責設計驗收系統的產線架構師。

這種「靜默執行、自動驗收」的邏輯，正是 韁繩工程 (Harness Engineering) 的實踐。透過建立穩定的執行系統，我們不再是被 AI 追著跑的勞動者，而是主導產線的指揮官，真正實現「把時間買回來」。

附錄：hexo-seo-aio 的 SKILL.md 範例

以下是本專案中 SKILL.md 的核心內容，你可以將其作為模板，修改為符合你專案需求的規範：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---
name: hexo-seo-aio
description: Professional SEO and AI Optimization (AIO) for Hexo blog posts.
---

# Hexo SEO & AIO Optimizer

## ⚠️ Gotchas: 避坑指南 (最高優先級)
- **NO Filler Intros**: Skip "In today's digital age...". Start with the core value.
- **Title Quality**: Title + Subtitle should ideally be 20-35 Chinese characters.
- **Terminology Consistency**: Use industry-standard English terms (e.g., ESM, SSR).
- **EXACTLY ONE SPACE** between Chinese and English/Numbers.

### 1. Title & Subtitle Constraints
- **Forbidden Words**: NEVER use "掌握" (Master) or "解析" (Analyze). Use "實踐" (Practice) or "指南" (Guide).
- **Subtitle Rules**: Must NOT repeat Title keywords and must NOT end with particles (的、之、與、及).

### 2. SEO/AIO Audit & Scoring
When asked to analyze or check a post:
1. **Research**: Read the post content and Front-matter.
2. **Score**: Use [seo_scoring.md](references/seo_scoring.md) to calculate a score from 0 to 100.

### 3. SEO/AIO Post Optimization
When asked to optimize a post:
1. **Audit First**: Perform the "Audit & Scoring" workflow.
2. **Execute (Surgical)**: Update internal links with utm parameters, fix spacing, and append FAQ.

FAQ：關於 hexo-seo-aio 的常見問題

Q1：為什麼標題長度要限制在 25-35 個中文字？

A：這是為了兼顧搜尋引擎展示（避免被截斷）與 AI 摘要抓取的資訊密度。過短則關鍵字權重不足，過長則語意發散。

Q2：內外部連結為什麼要強制加上 utm 參數？

A：這是為了在 Google Analytics 中精準追蹤流量來源。透過 utm_source=link&utm_medium=article&utm_campaign=internal_link，我們可以分析哪些技術文章最能引導讀者進行深度閱讀。

Q3：這個 Skill 可以處理非技術類的文章嗎？

A：可以，但 seo_standards.md 的規則（如術語一致性）可能需要微調。這正是 Skill 「資料與邏輯分離」架構的優勢。

結語：投資你的自動化產線

開發一個 Skill 可能需要花費你一個下午的時間，但它產生的 複利效應 是巨大的。當你不再需要為標點符號或關鍵字佈局煩惱時，你才能真正專注於解決下一個技術難題。

這不是技術問題，而是關於你如何定義自己的「數位生產力」。

• ← 上一篇
• 下一篇 →