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，這是一個專為技術部落格設計的自動化優化系統，並已全面升級為支援新一代的 agy CLI 環境。

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

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

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

二、放置規範與 Context Engineering 設計美學

隨著 Google CLI 的升級，本站已全面將工作區自訂機制遷移至 Antigravity 平台的全新標準。結構如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

hexo-blog/
├── .agents/               # AI 代理專用隱藏目錄 (agy / Antigravity 標準)
│   ├── AGENTS.md         # 全域專案規則檔
│   └── skills/           # 存放所有本地定義的 Skills
│       └── hexo-seo-aio/ # 本次開發的 Skill 主體
│           ├── SKILL.md  # 核心入口、工作流與 Gotchas
│           ├── examples/ # Few-shot 範例文章 (供 AI 學習優化風格)
│           │   ├── before_opt.md
│           │   └── after_opt.md
│           ├── references/ # 靜態規範、評分標準與知識庫
│           │   ├── seo_standards.md
│           │   └── seo_scoring.md
│           └── scripts/   # 決定性的自動化腳本
│               └── tag_cleanup.py

每個檔案的設計目的與用途

1. SKILL.md (核心大腦與避坑指南)：
   • 目的：作為 Skill 的唯一入口點，內含 YAML Front-matter 提供系統註冊感知。
   • 用途：定義工作流步驟（Audit ➡️ Optimize ➡️ Verify），並集中放置最高權重的限制條件（Gotchas）。
2. examples/ (優化前後的 Few-shot 實體)：
   • 目的：提供機器學習中最強大的「小樣本學習（Few-shot Learning）」。
   • 用途：存放實際優化前、優化後的文章對比。AI 通過比對這兩個檔案，能瞬間體會什麼叫「適度的中英空格」與「非廢話流的前言」，比寫一萬字規則更有用。
3. references/ (靜態標準與量化機制)：
   • 目的：充當 AI 的「外掛字典」，存放不需要隨時塞在 Context 裡的長篇參考資料。
   • 用途：放置具體的 SEO 技術規範及評分量表。AI 只有在需要進行「審查評分」或「檢索規則」時，才會主動讀取此目錄，保持主記憶體的輕量。
4. scripts/ (確定性自動化腳本)：
   • 目的：使用確定性（Deterministic）的程式碼，取代 LLM 不確定性（Probabilistic）的語意猜測。
   • 用途：執行像標籤清洗、正則間距修正等邏輯。AI 遇到繁瑣規則時，可以直接調用這些腳本執行，既省 Token 又能達到 100% 的準確度。

這套目錄結構如何拯救你的「上下文工程 (Context Engineering)」？

在與現代 AI 代理（如 agy）協作時，上下文工程 (Context Engineering) 是決定 AI 是「神助手」還是「Token 碎紙機」的關鍵。這套目錄結構在上下文控制上具備四大優勢：

1. 漸進式披露 (Progressive Disclosure) 避免「Lost in the Middle」：
   如果把標題規範、評分表、Few-shot 範例與自動化腳本全部寫進一個長達 5000 字的 System Prompt，AI 在推理時會產生「注意力發散（Lost in the Middle）」，容易忽略中段的關鍵約束。透過將靜態文件拆分至 references/ 與 examples/，AI 在啟動時只需載入輕量的 SKILL.md，當執行到「Audit 稽核」步驟時，才會調用工具去讀取 seo_scoring.md。這種「按需讀取」極大提升了 AI 的指令遵循率。

2. 透過 Tool-use 節省 Token 複利：
   如果每一次對話都把所有規則發給 AI，你的 Prompt Token 消耗會隨著對話輪數呈線性暴漲。將規範放在專案目錄中，AI 透過工具（如 view_file）在本地讀取。這意謂著在多輪對話中，只有在必要時才會有少量的 Token 開銷，這在大規模開發或頻繁優化時，能幫你省下 80% 以上的 API Token 成本。

3. 「確定性腳本」與「語意推理」的分離：
   利用 AI 去修正 100 處中英文空格，既浪費 Token，又極易在程式碼塊中產生格式損壞。在 Context Engineering 的最佳實踐中，「能用程式碼解決的，絕不交給 LLM 推理」。將 tag_cleanup.py 等腳本封裝在 scripts/ 中，讓 AI 作為「操作者」去執行腳本，而非讓 AI 用大腦去硬啃繁瑣的正則清洗，這保證了極致的執行穩定性。

4. 版本控制與團隊 Context 共享：
   把 Skill 寫在本地的 .agents/skills 資料夾中，代表 Prompt 不再是某個開發者電腦裡的「魔法」，而是可以隨著 Git 進行版本控制、分支開發、代碼審查（Code Review）的軟體資產。這解決了團隊協作中「AI 輸出風格不一致」的難題，讓團隊共享同一個高品質的上下文邊界。

Agent 運行時的檔案協同機制 (Runtime Orchestration)

當你在 agy 終端機中下達優化指令時，Agent 並非一次性讀取所有檔案，而是如同軟體程式般進行有順序的協同調用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

sequenceDiagram
    participant User as 開發者
    participant Agent as agy AI 代理
    participant Skill as SKILL.md (大腦)
    participant Ref as references/ (外掛知識庫)
    participant Ex as examples/ (風格範例)
    participant Script as scripts/ (執行工具)

    User->>Agent: 啟動優化任務
    Agent->>Skill: 1. 載入工作流 & 避坑指南 Gotchas
    Agent->>Ref: 2. 按需調用讀取評分與技術標準 (view_file)
    Agent->>Ex: 3. 對比 Few-shot 範例學習寫作風格 (view_file)
    Agent->>Script: 4. 靜默執行確定性腳本清洗數據 (run_command)
    Agent->>User: 5. 輸出符合所有約束的優化成果

1. 感知與載入 (Perception)：
   啟動 agy 時，Agent 讀取 SKILL.md 的 YAML 元數據進行自我註冊。當接收到「優化」任務時，Agent 會將 SKILL.md 中的 Gotchas 寫入主記憶體作為「最高防線」。
2. 分析與檢索 (Information Retrieval)：
   Agent 讀取要優化的文章後，使用工具讀取 references/seo_standards.md。透過語意比對，找出文章中不符規範之處（如標題過長、缺少 excerpt 等）。
3. 學習與模仿 (Few-shot Alignment)：
   為了讓改寫風格自然，Agent 會讀取 examples/before_opt.md 與 examples/after_opt.md，理解什麼是「適當的間距」與「資訊高密度前言」的具體寫法，完成對寫作風格的對齊。
4. 混合執行與驗收 (Hybrid Execution)：
   在執行修改時，Agent 會先調用命令列工具執行 scripts/tag_cleanup.py 處理底層的確定性清理。隨後，Agent 會依據對齊後的風格進行語意修復，最後對照 references/seo_scoring.md 重新跑一遍評分。只有當自我評分達標後，Agent 才會提交修改結果。

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

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

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

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

四、全生命週期自動觸發：如何自動觸發 Skill 優化？

在實際開發中，我們不希望每次優化都手動呼叫命令。建立全流程自動觸發機制，是將 AI 融入研發生命週期的核心實踐。 我們將整個寫作流程拆解為三階段自動化：

1. 撰寫階段：IDE / 本地工作區自動加載

在本地開發時，只要你在根目錄啟動 agy，AI 代理會立即讀取 .agents/AGENTS.md 並感知 .agents/skills/hexo-seo-aio/SKILL.md。此時你對 agy 發出的任何寫作指令，都會在背景預設套用中英間距與標題字數規範。

2. 提交階段：Git Hooks 本地自動防線

透過配置 husky，我們在本地 git commit 前設定了自動觸發機制：

• 觸發 Python 檢測腳本（如 check_links.py 檢查內鏈是否破損）。
• 呼叫 headless agy CLI 對暫存區 (Staged) 的 Markdown 進行自動化評分，若評分低於 90 分，則拒絕提交並主動產出優化建議。

3. 部署階段：CI/CD 雲端流水線驗證

本站將自動防線延伸至 CircleCI。在 .circleci/config.yml 的部署流程中，我們在執行 npm run generate 前插入了一道自動稽核指令：

1
2
3
4
5

- run:
    name: Run SEO and Link Verification
    command: |
      python check_links.py
      # 這裡可進一步整合自動化評分腳本，確保所有發布內容 100% 符合規範

任何未達 90 分或包含破損連結的文章，都會直接使 CI 流程失敗，防止不符合 SEO 規範的文章流向正式環境。

五、量化評分與 superpower 整合

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

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

當我們整合了 obra/superpowers 框架後，Agent 具備了更強大的「自我驗證」能力。superpowers 強制 AI 在進行優化前，先建立一個「優化 Plan」，接著在 Plan 指引下調用 hexo-seo-aio 的規則。

Agent 會先進行「初始評分」，若未達 90 分，它會根據 seo_suggestions 自行啟動「遞歸修復」循環，直到分數達標才向人類回報。這種量化機制將 Agent 從「被動執行者」轉化為「具備目標意識的自我迭代者」。

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

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

1. 草稿生成：快速記錄技術要點。
2. 呼叫 Skill：在終端機輸入 agy "幫我優化這篇文章的 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 可能需要花費你一個下午的時間，但它產生的 複利效應 是巨大的。當你不再需要為標點符號或關鍵字佈局煩惱時，你才能真正專注於解決下一個技術難題。

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

• ← 上一篇
• 下一篇 →