Harness 實踐：將任何文字編輯成精美的文章
整理版優先睇
用 Harness 方法將文字轉換為精美網頁文章：整合 Reacticle 組件與多階段流程
呢篇文章係由花園老師（ConardLi）寫嘅，佢之前整咗一個可以自動製作知識講解視頻嘅 Skill，收到好多正面反饋，尤其係有人話「呢個唔止一個 Skill，而係一套完整嘅工程方法」。佢想驗證一個觀點：好嘅 Harness 係可以遷移嘅。於是佢用差唔多同一套骨架，做咗一件完全不同嘅事——將任何文字編輯成精美嘅網頁文章。
文章靈感嚟自 Claude 官方一篇叫《The unreasonable effectiveness of HTML》嘅博客，講到 HTML 嘅資訊密度、視覺結構化、可交互同易分享嘅優勢。但花園老師指出，HTML 好強唔代表應該俾 AI 裸寫 HTML，因為咁會導致單文件巨大、效果唔可控、失去文章感。為咗解決呢啲問題，佢開發咗 Beautiful Article Skill，底層用咗一套叫 Reacticle 嘅組件協議，俾 AI 可控地生成長文 HTML。成個流程劃分成 8 個 Phase，中間卡咗 3 個強制人工檢查點，確保質素。
最終結論係：真正值得複用嘅唔係某段提示詞或某個組件，而係一套工作方法——拆階段、文件化記憶、漸進加載上下文、分節點質檢、最小切片修復、自進化。呢套 Harness 可以應用喺週報、播客 Shownotes、課程講義等好多場景，令 Agent 由「做到一次效果」變成「穩定生產一類結果」。
- Harness 可遷移：視頻 Skill 嘅骨架（階段劃分、檢查點、文件記憶）可以直接套用到文章生成，驗證咗方法論嘅通用性。
- 唔好俾 AI 裸寫 HTML：直接用 AI 生成完整 HTML/CSS 會導致維護困難、效果唔穩定，要用組件協議（Reacticle）約束輸出。
- 8 階段流程：從 Intake 到 Delivery，卡 3 個檢查點，先規劃、再定調、再放量，確保每一步都受控。
- Reacticle 組件協議：語義化組件（Article、Section、Table 等）加上 Raw 逃生艙，令 AI 穩定輸出，同時保留自由度。
- 自進化機制：質檢同修復記錄落盤，畀 Agent 回看分析，逐步優化 Skill 規則，越用越好。
Beautiful Article Skill
用嚟將任何文字編輯成精美網頁文章嘅 Skill，包含 Reacticle 組件協議同 8 階段流程，可喺 garden-skills 倉庫下載。
CC Switch
桌面配置工具，可以將 Claude Code、Codex 等 Agent 切換到自定義模型，例如 MiniMax M3。
MiniMax Token Plan
MiniMax M3 模型嘅 Token Plan 訂閲，量大管飽速度快，適合多步驟長任務。
Reacticle 組件庫
專門為 AI 文章生成設計嘅 React 組件協議，提供語義組件同 Raw 逃生艙，支援多種主題。
內容結構
Phase 0 Intake 判斷是否進入本 Skill + 初步文章類型 ▼Phase 1 Source → Markdown URL/PDF/DOCX/MD/文本 → source.md + extraction-notes.md ▼Phase 2 Editorial Planning 一份 plan.md（Brief / Outline / Theme / Assets 四段） ▼Phase 3 Plan Checkpoint ★Checkpoint 1 必須停 ▼Phase 4 First Spread 首屏 + 第一節 + 一個代表性視覺塊 └ ★Checkpoint 2 必須停 ▼Phase 5 Full Article Build 生成完整網頁文章 ▼Phase 6 Final Review 三視角終審 ▼Phase 7 Repair 最小切片修復 ▼Phase 8 Delivery ★Checkpoint 3 必須停 → 交付 article.html從視頻到文章：驗證 Harness 嘅可遷移性
花園老師之前分享咗一個視頻 Skill，可以等 Agent 自動製作知識講解視頻。收到唔少反饋，其中佢最印象深刻嘅係：「呢個唔止一個 Skill，而係一套完整嘅工程方法。」呢句說話點醒咗佢：視頻 Skill 背後嘅 Harness 設計——階段編排、文件記憶、檢查點、質檢、最小切片修復——呢啲係可以遷移嘅。
於是今次佢用差唔多同一套骨架，做一件新嘢：將任何文字編輯成精美嘅網頁文章。目標係證明好嘅 Harness 唔單止適用於一個場景，而係可以重複使用喺唔同嘅複雜任務上。
點解要整 Beautiful Article？避免 AI 裸寫 HTML 嘅問題
靈感嚟自 Claude 官方一篇博客《The unreasonable effectiveness of HTML》。文章指出：Markdown 寫文章簡單，但面對複雜報告、圖表、交互時唔夠用；而 HTML 嘅資訊密度高、視覺結構化、可交互、易分享，隨住 AI 能力增強，呢啲優勢變得好明顯。
不過花園老師提醒：HTML 好強，唔代表應該俾 AI 自由裸寫 HTML。當內容好長、視覺元素豐富時，AI 直接寫 HTML/CSS 會遇到「單文件巨大，後續難改」、「效果唔可控」、「失去文章感」等問題。呢啲痛點同視頻 Skill 嘅痛點一模一樣：模型有能力，但你需要一套系統去駕馭呢個過程。
Beautiful Article Skill：8 個 Phase 與 Reacticle 組件協議
為咗實現可控嘅文章生成，花園老師設計咗一個全新嘅 Skill，叫做 Beautiful Article。佢將整個流程切成 8 個 Phase，中間卡咗 3 個強制人工檢查點：Phase 0 Intake → Phase 1 Source→Markdown → Phase 2 Editorial Planning → Checkpoint 1 → Phase 4 First Spread → Checkpoint 2 → Phase 5 Full Article Build → Phase 6 Final Review → Phase 7 Repair → Checkpoint 3 → Phase 8 Delivery。
底層用咗一套特別嘅組件協議，叫做 Reacticle（React + Article）。一句話定位：Markdown 令人輕鬆寫文章；Reacticle 令 AI 可控地生成長文 HTML。佢提供咗一組語義化嘅組件，例如 Article、Hero、Lead、Section、Subsection、Table、Quote、CodeBlock 等等，AI 只需要組合呢啲組件，結構同排版由庫保證。
同時，Reacticle 提供一個逃生艙叫 Raw，可以塞任意 HTML/SVG/CSS/React，但必須消費主題 token。目前有 11 套編輯級主題，例如 Tufte（數據墨水風格）、Sottsass（顏色碰撞）、Bayer（包豪斯三原色）等。每一套主題同時係 CSS token 包同 Markdown profile，話俾 AI 知呢套主題嘅視覺規則。
環境搭建：Claude Code + MiniMax M3 + CC Switch
花園老師推薦用 Claude Code 做執行 Agent，配 MiniMax M3 模型，因為 M3 喺長上下文理解同複雜指令遵循上有明顯提升，適合多步驟、多檢查點嘅長任務。另外要裝 CC Switch 呢個桌面工具，用嚟切換到自定義模型。
- 1 安裝 Claude Code：curl -fsSL https://claude.ai/install.sh | bash，然後用 claude -v 確認。
- 2 喺 MiniMax Token Plan 訂閲 Max 極速版，生成 API Key。
- 3 下載 CC Switch，配置 MiniMax 供應商，填入 API Key，模型名改為 MiniMax-M3，然後啓用。
- 4 訪問 garden-skills 倉庫下載 beautiful-article Skill，解壓到工作目錄嘅 .claude/skills/ 文件夾。啓動 Claude Code，輸入 /beautiful-article 有提示就代表配置成功。
實戰演示：由投餵素材到精美網頁文章
花園老師用 Claude Code + MiniMax M3 行咗一次完整流程，輸入素材係一篇 Anthropic 嘅技術博客。佢用 claude --dangerously-skip-permissions 起動，然後叫佢讀取文章 URL 並用 /beautiful-article 執行。
首先，Agent 會判斷素材類型，將網頁整理成 source.md 同 source.zh.md（中文版），仲有 extraction-notes.md 記錄抽取風險。然後生成 plan.md，包含 Brief、Outline、Theme、Assets 四段。到 Checkpoint 1，Agent 會問你 5 件事：文章類型、主題、版式寬度、配圖模式。呢個檢查點唔可以跳過，要逐項確認。
確認後進入 Phase 4，用 scaffold.sh 起 Vite + React + TS 工作區，安裝最新 Reacticle。只做封面 + 首屏 + 第一節 + 一個代表性視覺塊。開發完會開一個 First Spread Reviewer SubAgent 質檢，寫入 first-spread-review.md，然後修復。呢個係 Checkpoint 2，要確認首屏氣質同後續開發模式（單 Agent 順序或多 Agent 並行）。
完整生成時如果揀並行模式，會有多個 SubAgent 同時開發唔同嘅 section，每個 section 一個文件。佢哋唔會改同一個文件，最後由主 Agent 合成。寫完後進入 Final Review，開三個 SubAgent 分別做 Editorial、Visual、Technical 審核，檢出問題會用最小切片修復。最後 Checkpoint 3 決定交付 HTML 定係 HTML+PDF。
Harness 嘅核心：階段、檢查點、文件記憶、質檢、修復、自進化
跑完實戰，花園老師回頭對比視頻 Skill 同文章 Skill，發現六個核心部分係相通嘅：上下文管理（每個階段只看該睇嘅嘢）、工具系統（穩定嘅工作區結構）、執行編排（先規劃、再定調、再放量）、狀態與記憶（關鍵決策落盤成文件）、評估與觀測（喺關鍵節點設質檢）、約束與恢復</highlight>（用組件協議約束輸出，最小切片修復）。
特別值得一提嘅係 自進化機制：所有質檢同修復記錄會落到本地文件，例如 review/first-spread-review.md、review/final-review.md、review/repair-log.md。呢啲文件唔止俾人睇，仲會俾 Agent 睇。同類任務跑多咗之後，Agent 可以回看呢啲記錄，分析邊啲環節最容易出問題，然後反過來優化 Skill 嘅規則同檢查清單。
一篇普通嘅文字，變成有排版、有配色、有節奏感嘅精美文章。
唔需要專業設計師，只要畀 Agent 裝一個 Skill 就得。
《Attention Is All You Need》逐層拆解 — 30 分鐘嘅技術長文，Tufte 主題，數據墨水風格。
《深入解析 Codex 智能體循環》— Sottsass 主題，顏色撞到應一應，視覺效果爆曬燈。
《提示詞緩存對 Agent 有幾重要？》— Bayer 主題，包浩斯三原色，好有幾何感覺。
《Skill 係點樣進化嘅？》— Freddie 主題，互動式學習體驗。
大家好，歡迎嚟到 code秘密花園，我係花園老師（ConardLi）。
一、視頻 Skill 嘅回饋
上一篇《Harness 實踐：等 Agent 自動製作知識講解視頻》出咗之後，收到好多回饋。
有同學話效果好驚艷，有同學話流程好清晰，但令我印象最深刻係呢類評論：
"呢個唔止係一個 Skill，呢個係一套完整嘅工程方法。"
講得好啱。
視頻 Skill 之所以可以穩定產出，就係因為佢背後有一套精心設計嘅 Harness：
分階段嘅執行編排、文件化嘅狀態記憶、強制嘅人工檢查點、獨立嘅 Reviewer 質檢、最細切片嘅修復機制。
今次，我想驗證一個更重要嘅觀點：好嘅 Harness 係可以遷移嘅。
今日我哋用幾乎同一套骨架，做一件完全唔同嘅事 — 將任何文字編輯成精美嘅網頁文章。
二、點解今次要整 Beautiful Article
2.1 由 Claude 嘅一篇博客講起
Claude 官方最近出咗篇文章，叫《The unreasonable effectiveness of HTML》。
核心觀點係：Markdown 寫文章好簡單，但面對複雜報告、圖表、交互、視覺結構嘅時候就唔夠用。
由於 AI 能力增強，人哋唔使再理會複雜嘅語法，HTML 嘅優勢就好明顯：
信息密度高 — 表格、SVG、代碼片段、公式可以混合排版；
視覺結構化 — 標題層級、顏色、間距都可以精確控制；
可互動 — 摺疊、Tab、複製按鈕、可調控件；
容易分享 — 一個檔案發出去，對方直接打開，唔需要裝任何嘢。
2.2 不過：HTML 好勁 ≠ 應該畀 AI 裸寫 HTML
問題嚟喇。HTML 好勁，但呢個唔代表應該畀 AI 自由裸寫 HTML。
當內容好長、視覺元素好豐富嘅時候，畀 AI 裸寫 HTML/CSS 可能會遇到好多問題：
單一檔案好大，之後好難改同維護
效果唔可控，好難穩定咁按你要求產出內容
令文字冇咗「文章」嘅感覺，睇落似網頁應用
呢樣同視頻 Skill 嘅痛點係 相同的 — 模型有能力，但你需要一套系統嚟駕馭呢個過程，下面睇下呢套流程係點樣設計
三、Beautiful Article Skill
為咗呢個，我開發咗一個全新嘅 Skill，叫 Beautiful Article。
佢都已經同花園老師之前開源嘅所有其他 Skill 一齊發佈到 Garden Skills 倉庫度：
https://github.com/ConardLi/garden-skills
3.1 執行流程：由素材到文章嘅 8 個 Phase
成個 Skill 將「由任意素材到精美文章」切開 8 個階段，中間插咗 3 個強制人工檢查點。
Phase 0 Intake 判斷是否進入本 Skill + 初步文章類型
▼
Phase 1 Source → Markdown URL/PDF/DOCX/MD/文本 → source.md + extraction-notes.md
▼
Phase 2 Editorial Planning 一份 plan.md（Brief / Outline / Theme / Assets 四段）
▼
Phase 3 Plan Checkpoint ★Checkpoint 1 必須停
▼
Phase 4 First Spread 首屏 + 第一節 + 一個代表性視覺塊
└ ★Checkpoint 2 必須停
▼
Phase 5 Full Article Build 生成完整網頁文章
▼
Phase 6 Final Review 三視角終審
▼
Phase 7 Repair 最小切片修復
▼
Phase 8 Delivery ★Checkpoint 3 必須停 → 交付 article.html
3.2 先認識底層：Reacticle 組件協議
呢度要注意，喺上面嘅開發過程，Agent 寫嘅唔係原始 HTML，而係一套我哋特別訂造嘅底層組件協議，我哋叫佢做：
Reacticle = React + Article。
一句話定位：
Markdown 令 人 輕鬆寫文章；
Reacticle 令 AI 可控咁生成長文 HTML。
佢畀 AI 定義咗一套專用嚟寫文章嘅、被約束嘅、語義化嘅 React 組件契約。
https://github.com/ConardLi/reacticle
三個關鍵設計
語義組件詞彙表
Reacticle 提供咗一組專門用嚟編寫「文章」嘅組件，基本可以平替 Markdown 嘅所有語法：
Article / Hero / Lead / Section / Subsection / Table / Quote / Formula / CodeBlock / Image / TOC / Conclusion …
AI 只負責「組合」呢啲組件，結構同排版由庫保證。
唔需要 AI 去諗「呢度用 div 定 section」、「標題用 h2 定 h3」、「間距設幾多」— 呢啲全部畀組件封裝咗。
結果就係：穩定、唔會崩版。
Raw 自由層（受契約約束）
但係得組件會唔會太死板？有啲視覺效果組件做唔到咁點算？
Reacticle 提供咗一個逃生艙叫 Raw。
任意 HTML/SVG/CSS/React 都可以塞入去 Raw
你想畫一個自訂嘅時序圖、做一個互動式滑塊、放一個 Canvas 動畫，都得。
但有一條硬約束：
Raw 裏面所有樣式一定要用我哋約束好嘅主題 token。
咁樣，我哋畀模型有自由嘅同時，又約束咗各個主題效果嘅穩定性。
Reacticle 目前有 11 套編輯級主題：
每套主題都同時係兩份嘢：
一份 CSS token 包 — 定義顏色、字體、間距、陰影等所有視覺變量；
一份畀 AI 睇嘅 Markdown — 話畀 AI 呢套主題要用咩配圖風格、咩代碼高亮、咩 Raw 慣用法、咩係反模式。
譬如 Tufte 主題嘅 profile 會話畀 AI：
「呢個主題追求數據墨水比，唔好用漸變、唔好用陰影、圖表要極簡、正文係主角。」
譬如 Sottsass 主題嘅 profile 會話畀 AI：
「呢個係 Memphis 風格，可以用撞色、可以用黑描邊、可以有輕微旋轉嘅元素，但唔好太正經。」
Reacticle 同 Skill 嘅關係
Reacticle 係 運行時協議
類似樂高積木，管嘅係「輸出表面穩唔穩」。
佢唔規定你點樣寫作、點樣規劃、點樣審閲。
點樣由素材規劃、生成、審閲、交付 嗰套方法論同 Harness，住喺 beautiful-article Skill 裏面
類似砌積木嘅說明書，管嘅係「成個生產過程穩唔穩」。
呢套流程背後仲有一系列設計原則：
文件化記憶、漸進加載上下文、分節點質檢、最細切片修復……
我哋放喺實戰之後再展開
到時你會發現，佢哋同上一篇視頻 Skill 嘅骨架幾乎一模一樣。
四、環境搭建
下面，我哋嚟實際示範一下呢個 Skill 嘅用法。
對於國內嘅同學，我依然優先推薦 MiniMax + Claude Code 呢套組合。
4.1 Claude Code
首先我哋揀 Claude Code 作為我哋嘅核心執行 Agent。
註：如果你喺本地用 Cursor、Codex 以及其他支援 Skill 嘅 Agent 都得。
安裝指令：
curl -fsSL https://claude.ai/install.sh | bash
裝好之後，喺終端度輸入：
claude -v
可以測試係咪正常安裝成功。
4.2 MiniMax M3
今次我將模型換成最新發佈嘅 M3，當 Harness 已經調教得好好之後，揀一個能力強嘅模型就好關鍵。
MiniMax M3 號稱首個 Coding Agentic 達到 SOTA、1M Context、原生多模態 三項能力兼備嘅模型。
呢幾個能力分開睇都唔新鮮，但放喺實際嘅生產場景度組合埋一齊就好關鍵。
以我個人使用體驗嚟講，相比上一篇教學用嘅 M2.7，M3 喺長上下文理解同複雜指令嘅跟從上有明顯提升。
對於我哋今次呢種多步驟、多檢查點、需要反覆回讀檔案嘅長任務場景，M3 係好適合。
依然推薦大家搭配 Token Plan 嚟用，我自己而家用緊 Max 極速版。
量多管飽速度快、天然配合 Claude Code，亦唔使擔心封號風險，喺某啲場景下好接近原生 Claude Code 嘅體驗。
訂閲完成後，會生成一個 API Key，呢個預先存好之後會用到：
4.3 CC Switch
CC Switch 係一個桌面配置工具，可以令我哋嘅 Agent（Claude Code、Codex、Gemini CLI）切換成任意自訂模型。
喺呢套流程入面，我主要用佢嚟設定 MiniMax 嘅 Token Plan。
直接去佢嘅 Github Release 頁面就可以下載指定系統（例如 MacOS）嘅安裝包：
㩒右上角「+」，揀預設嘅 MiniMax 供應商：
然後填返上一步保存嘅 API Key：
然後將模型名稱全部改為 MiniMax-M3，然後直接㩒保存就可以用：
返到首頁，㩒「啟用」：
下面，我哋打開終端輸入 claude，就可以直接用：
4.4 安裝 Skill
訪問 garden-skills 倉庫：https://github.com/ConardLi/garden-skills/，揾到 beautiful-article Skill，下載安裝包：
下載完成後解壓得到 Skill 具體目錄，然後放進工作目錄嘅 .claude/skills/ 資料夾。
啟動 Claude Code，輸入 /beautiful-article，有智能提示就表示配置成功。
五、實戰：將一篇文章編輯成精美網頁文章
下面用 Claude Code + MiniMax M3 行一次完整流程。
然後，我依然揀一篇 Anthropic 嘅技術博客做輸入素材：
5.1 啟動 Claude Code
進入項目目錄，啟動 Claude Code：
claude --dangerously-skip-permissions
老規矩，--dangerously-skip-permissions 只喺可信目錄用。
5.2 餵素材，啟動 Skill（Phase 0–1）
將文章 URL 掟畀佢，話畀佢用 /beautiful-article：
讀取這篇文章：https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything
按照 /beautiful-article 要求，幫我產出一篇精美的中文文章。
Agent 讀取我哋嘅 Skill 之後，首先開始認輸入係咩、目標語言係咩、任務邊界係咩。
譬如呢度佢判斷素材係一篇 Claude 博客文章，目標係中文文章，預期文章類型比較接近 longform，即係信息保留比較高嘅完整長文。
然後佢拎咗網頁正文之後，開始產生幾個檔案：
任務完成後，我哋見到本地工作目錄多咗幾份檔案：
source.md：原始素材嘅 Markdown 版本。無論輸入係網頁、PDF、文件定係一段文字，都會先被統一整理成呢份檔案，之後所有寫作都以佢做事實來源。
source.zh.md：由於我哋要做中文版，佢會先出一份地道翻譯版
source.zh.md做事實底座，之後基於翻譯版編寫。
extraction-notes.md：抽取記錄。例如邊啲圖片冇拎到、網頁裏面邊啲內容可能缺失、邊啲地方有格式或者語義唔確定，都會記喺呢度，方便之後人工判斷。
5.3 編輯規劃（Phase 2）
跟住佢會生成 plan/plan.md，分四段：
Brief：目標讀者、文章類型、信息保留比例、語氣、主要觀點、閲讀目標。
Outline：Hero / Lead / 各 Section 列表 / 每節保留邊啲信息 / 每節需唔需要 Raw/Table/CodeBlock/Formula。
Theme：推薦邊個主題 + 理由。
Assets：配圖策略同逐圖計劃。
呢份檔案就係之後所有開發嘅邊界 — 文件化工作記憶。
5.4 第一次人工確認 · Plan Checkpoint（Phase 3）
呢個係第一個必須停嘅檢查點。
佢會逐項問你 5 件事（Agent 會根據原文嘅類型推薦最適合嘅選項，但唔會幫你做決定）：
1. 文章類型 + 信息保留比例
Skill 內置咗幾套完全唔同嘅文章類型
完整長文
longform · ~100%：適合原文質素高、值得完整歸檔嘅材料，盡量保留全部論證，只做編輯同排版增強。研究報告
full-report · ~80%：適合調研、技術評估、正式分析，重點係執行摘要、關鍵發現、數據、風險同建議。教學步驟
tutorial · 80-100%：適合「跟住做就可以行得通」嘅內容，步驟、代碼、驗收點唔可以漏。概念解釋
explainer · ~80%：適合將一個機制、系統、算法講清楚，保留關鍵直覺同易錯點，刪走旁枝。對話訪談
dialogue · ~80%：適合播客、訪談、AMA，將口語冗餘刪走，但保留講嘢嘅語氣同觀點。工程審閲
review · 60-80%：適合 PR、方案、事故、架構設計呢類具體產物審閲，重點係發現、證據、影響同行動項。觀點評論
essay · 60-80%：適合評論、評測、敍事同專欄，重點唔係面面俱到，而係一條清晰嘅觀點線。決策摘要
briefing · 40-60%：畀忙人睇嘅，結論行先，只保留關鍵事實、取捨同下一步。互動式解釋
interactive-explainer · ~25% 原文摘錄：唔係簡單刪走 75%，而係將原文重構成可以操作嘅學習頁，用互動示範幫讀者真正玩明白。
呢一步本質上係問：你會想讀者完整讀完、快速判斷、跟住做、理解一個機制，定係由視覺帶住走？答案唔同，之後生成出嚟嘅文章形態會完全唔同，我哋今次揀 100% 保留嘅完整長文風格。
2. 主題
今次我哋唔聽佢講，揀一個有個性啲嘅 Bayer 主題：
3. 版式寬度
選項：narrow / regular / wide / full。我哋揀預設嘅 regular。
4. 配圖模式
選項：none（唔用外部圖片）/ user-assets（你提供）/ placeholders（先用佔位圖）/ ai-generated（AI 生成）。
注意：呢個只決定用唔用外部 Image 組件，HTML 內容嘅繪製唔受影響，我哋揀唔用外部圖片。
確認完呢幾件事，佢會根據我哋嘅決定修訂開發計劃：
然後先進入下一階段。
5.5 封面 + 首章開發（Phase 4）
它先用 scaffold.sh 起一個 Vite + React + TS 嘅工作區，由 npm 裝最新版 Reacticle。
然後只做一小塊：封面 + 首屏 + 第一節 + 一個代表性視覺塊。
呢一步唔會寫曬成篇文章，而係先定調。
開發完成後，佢唔會即刻完成，而係開一個 First Spread Reviewer SubAgent 嚟質檢：
所有質檢嘅過程，佢會寫入 first-spread-review.md 文檔。
然後按 fail 項目逐一修復：
然後，我哋就可以人工驗收，呢一步嘅人工驗收好有必要，首屏同第一節基本上決定咗成篇文章嘅氣質：
5.6 第二次確認（Checkpoint 2）
然後進入 Checkpoint 2，獨立確認 2 件事：
1. 驗收結論
選項：呢一步可以大膽提出你嘅建議，標題方向、信息密度、主題觀感、正文節奏、視覺塊風格，邊一點你覺得唔舒服都可以叫佢先調整好。
如果呢一步已經偏咗，之後寫得越多，返工成本越高。
2. 後續開發模式
A · 單 Agent 順序（最穩、風格最統一）
B · 多 Agent 並行（最快、考驗模型能力）。
5.7 完整生成 · Full Build（Phase 5）
確認後進入完整生成，我哋揀嘅 B 並行模式，會有多個 SubAgent 並行開發：
我哋可以切換每個 SubAgent 睇具體嘅開發詳情：
呢種多 Agent 調度對模型能力要求就好高，M3 喺呢方面表現比較穩定
可以準確理解每個 SubAgent 嘅邊界，唔會出現「兩個 Agent 改同一個檔案」或者「唔記得合併某個 Section」嘅情況。
然後我哋可以見到工作區嘅檔案結構：
一節一檔案係 Skill 嘅 鐵律，呢個係多 Agent 並行嘅前提，亦令之後維護更容易。
5.8 終審 + 修復（Phase 6–7）
所有 Section 寫完後，Skill 會指導開三個獨立嘅 SubAgent 做質檢，維度各唔同：
Editorial Reviewer：文章性、信息取捨、結構
Visual Reviewer：主題、Raw、配圖、移動端
Technical Reviewer：構建、控制枱、代碼/公式、可訪問性
如果呢一步檢出問題，會進入最細切片修復。
所有審核 + 修復嘅記錄，全部會記錄到本地檔案，呢啲檔案唔係畀你睇嘅，而係畀 Agent 睇嘅：
呢啲日誌可以促使後續 Skill 自進化，令佢知道喺之前嘅任務入面，邊啲環節容易出問題。
5.9 交付（Checkpoint 3 + Phase 8）
終審改完後，進入最後一個必須停嘅檢查點。佢會問你最終嘅交付決策：
選項：通過 · 導出 HTML / 通過 · 同時導出 HTML + PDF / 仲有局部修復 / 先停一停。
確認後，佢會幫我哋同時構建出一個 CSS+JS 全內聯嘅單檔案 HTML（斷網可打開、可當檔案分享）：
以及一個更方便分享嘅 PDF 格式，兩者內容效果完全一致。
然後你會發現，原來普通嘅文字，而家係一篇視覺效果精美、結構清晰、可離線閲讀、可直接分享嘅長文。
六、好嘅 Harness 係可以遷移嘅
跑完實戰，我哋返轉頭睇。
喺上一篇視頻教學入面，我哋講過一個成熟嘅 Harness 通常包含六個核心部分：
而家將視頻 Skill 同文章 Skill 放埋一齊對照：
你會發現設計上好相似，下面我哋逐層展開講下：
6.1 上下文管理：每個階段只睇應該睇嘅嘢
上下文管理解決嘅係：模型目前應該見到邊啲信息。
Skill 唔會喺啟動時將所有規範、主題、組件文件一次過塞入去。
Phase 1 只處理素材抽取（
source-to-markdown.md）；Phase 2 先睇文章類型（
article-types.md）、信息密度（plan-template.md）同主題選擇（theme-selection.md）；Phase 4/5 進入開發後，先讀取組件協議（
component-policy.md）、Raw 規範（raw-policy.md）同目前主題 profile。
如果一開始就將所有文件灌入去，模型注意力會被嚴重稀釋。
漸進加載令每個階段只睇應該睇嘅嘢。
長會話入面仲有一個細節：
每寫一節之前，Agent 都要回看當前 Section 嘅任務、組件協議、Raw 規範同主題約束。
靠檔案將自己拉返正軌，減少寫到後面風格同規則會走樣嘅問題。
6.2 工具系統：等 Agent 將檔案系統用穩
工具系統解決嘅係：模型可以調用邊啲能力，以及呢啲能力點樣被組織起嚟。
Skill 主要用嘅都係 Agent 自帶嘅能力：攞資料、讀寫檔案、執行腳本、跑本地構建、打開瀏覽器預覽。
關鍵在於，Skill 將呢啲能力套咗一層穩定嘅工作區結構。
第一步，所有輸入都會先整理成 source.md。
URL、PDF、DOCX、Markdown、純文字，最後都會回落到同一份 source 檔案上。
需要中文寫作時，再生成 source.zh.md；
抽取過程入面嘅風險、缺失同唔確定嘅項目，寫入 extraction-notes.md。
第二步，進入開發階段後，腳手架會建立標準嘅工作區。
source/、plan/、review/、article/sections/、article/raw-blocks/ 都有固定職責，Agent 唔需要臨時發明項目結構。
第三步，係並行安全。
完整文章可能有好多節，如果開多個 Agent 並行寫，每個 Agent 只負責一個 section 文件；
大型 Raw 放喺獨立嘅 raw-blocks/；
Article.tsx 只交畀主 Agent 組裝同排序。
咁樣多 Agent 可以同時工作，又唔會一齊改同一個檔案。
每節內容彼此隔離，最後由主 Agent 合成一篇完整文章。
6.3 執行編排：先規劃，再定調，再放量
執行編排解決嘅係：模型下一步應該做咩。
視頻 Skill 將「文章→視頻」切開 4 階段（內容編寫 → 開發 → 音頻 → 錄屏），卡 2 個人工檢查點（Plan / Audio）。
文章 Skill 將「素材→文章」切開 8 個 Phase，卡 3 個檢查點（Plan / First Spread / Delivery）。
階段數唔同、檢查點位置唔同，但 骨架一樣：
將一個複雜任務拆成線性流程，喺關鍵節點強制停低畀人拍板。
先做一小部分等人工確認基調同問題，再大刀闊斧開發後續章節。
仲有一條鐵律：檢查點禁止幫用戶做主。
每個決策項必須獨立列出、獨立等用戶答覆。
可以推薦（「我推薦 Tufte 主題，因為呢篇數據多」），但唔可以話「已經幫你揀咗 Tufte，唔啱話我知」 — 後者等於偷偷用咗默認值。
6.4 狀態與記憶：關鍵決策一定要落地（寫入檔案）
狀態與記憶解決嘅係：系統點樣跨步驟保持連續性。
長任務入面，Agent 好容易唔記得之前確認過嘅方向。所以 Skill 會將關鍵狀態寫入檔案。
source.md 和 source.zh.md 係事實底座，extraction-notes.md 記錄抽取風險，plan.md 記錄文章類型、目標讀者、信息保留比例、章節結構、主題同配圖策略。
呢啲檔案就係 Agent 嘅工作記憶。
寫到後面嘅章節時，佢唔使憑印象回憶之前點決定，直接回讀檔案就得。
咁樣可以減少長會話最常見嘅問題：前面確認過嘅方向，寫寫嚇又變咗。
6.5 評估與觀測：審核要放喺關鍵節點
評估與觀測解決嘅係：系統點樣知道自己做得啱唔啱。
呢一層好關鍵，Agent 寫完一節，好容易覺得「結構清楚、視覺唔錯、內容完整」，但真實問題可能藏喺細節度：
信息保留比例唔夠、主題氣質走樣、Raw 只係裝飾、移動端迫埋一齊、某節同前後文接唔上……
所以文章 Skill 將幾個關鍵產出都設定咗質檢點：
source.md | |
plan.md | |
為咗平衡效率同質量，執行方式都有區分。
Plan 階段上下文仲暖，由主 Agent 直接對住清單自查；
First Spread 同 Final Review 係關鍵節點，所有檢查都用獨立嘅 SubAgent；
仲有一條硬規則：拎到質檢結論後，先修復，再報告。
唔可以將「發現咗咩問題」當成完成，真正完成係「問題已經被修好」。
6.6 約束與恢復：畀 AI 一個穩定嘅輸出框架
約束與恢復解決嘅係：點樣避免走偏，以及走偏之後點樣修。
文章 Skill 嘅核心約束係 Reacticle 組件協議。
AI 寫文章時，正文用 Article / Section / Table / Quote / CodeBlock 呢類語義組件承載；
複雜視覺放進 Raw，但 Raw 都要消費主題嘅風格約束。
咁樣既有自由度，亦可以守住整體風格。
修復時依然保留咗視頻 Skill 嘅最細切片修復嘅思路。
某節信息太薄，就補嗰一節；某個 Raw 太花，就改嗰個 Raw；首屏氣質唔啱，就改 Hero / Lead / Summary。
呢個可以保護已經正確嘅部分，避免一次局部回饋將成篇文章重新搞壞。
6.7 自進化：等日誌反過來改進 Skill
Skill 嘅自進化係最近嘅熱門話題，我喺設計呢個新 Skill 時都有考慮呢個問題，點樣等 Skill 越用越好呢？
我嘅做法係，所有關鍵點質檢審查同修復記錄會落到本地檔案度
比如 review/first-spread-review.md、review/final-review.md、review/repair-log.md。
呢啲檔案唔只畀人睇，亦畀 Agent 睇。
同類任務跑得多咗之後，Agent 可以回睇呢啲記錄，分析之前邊啲環節最容易出問題：
目錄係咪容易寫錯，Raw 係咪成日過度設計，某類文章類型嘅信息保留比例係咪需要調整。
呢啲問題沉澱落嚟之後，就可以反過來促使 Agent 優化 Skill 嘅規則、檢查清單同預設策略。
所以 Skill 會隨住真實任務繼續進化。
七、最後
7.1 昇華一下
跑完今次實戰，再返轉頭睇呢套文章 Skill，會發現真正值得重用嘅唔係某一段提示詞，亦唔係某一個組件。
真正值得重用嘅係呢套工作方法：
將複雜任務拆成階段；
將關鍵決策變成檢查點；
將上下文寫入檔案；
將輸出表面收納入協議；
將質量問題交畀審核；
將修復限制喺最細切片；
將審核同修復日誌沉澱落嚟，反過來改進下一次流程。
呢個就係 Harness 嘅價值。
佢令 Agent 由「做到一次效果」，變成「可以穩定生產一類結果」。
做 Harness 都唔一定要由零搭一個 Agent。將一個垂直任務用 Skill 做穩、做好，本身就已經係做緊 Harness。
今日呢套流程用嚟將文章做成網頁長文，換一個場景，亦可以係：
週報 — 每週素材 → 結構化週報 HTML
播客 Shownotes — 音頻轉錄 → 精美筆記
課程講義 — 教案 → 可互動講義
技術文檔 — API Spec → 靚嘅開發者文檔
產品發佈頁 — PRD → 單頁展示稿
只要任務夠複雜，需要狀態、流程、檢查點同交付標準，呢套骨架就有遷移價值。
最後留低嘅，唔止一個 article.html。
仲有一條被驗證過嘅生產路徑。
7.2 資源連結
Reacticle：https://github.com/ConardLi/reacticle beautiful-article Skill：https://github.com/ConardLi/garden-skills Showcase / Gallery：https://rearticle.mmh1.top/#/gallery CC Switch：https://github.com/farion1231/cc-switch/issues MiniMax：https://platform.minimaxi.com/subscribe/token-plan Claude Code：https://claude.com/product/claude-code
歡迎攞一篇自己嘅文章試下。
如果今期教學對你有幫助，留低一個免費嘅三連啦！
一篇普通的文字，變成有排版、有配色、有節奏感的精美文章。
不需要專業的設計師，只需要給 Agent 裝上一個 Skill。
《Attention Is All You Need》逐層拆解 — 30 分鐘的技術長文，Tufte 主題，數據墨水風格。
《深⼊解析 Codex 智能體循環》— Sottsass 主題，顏色碰撞，視覺效果拉滿。
《提示詞緩存對 Agent 有多重要？》— Bayer 主題，包豪斯三原色，幾何感很強。
《Skill 是如何進化的？》— Freddie 主題，交互式學習體驗。
大家好，歡迎來到 code秘密花園，我是花園老師（ConardLi）。
一、視頻 Skill 的反饋
上一篇《Harness 實踐：讓 Agent 自動製作知識講解視頻》發出之後，收到很多反饋。
有同學說效果很驚豔，有同學說流程很清晰，但讓我印象最深的是這類評論：
"這不只是一個 Skill，這是一套完整的工程方法。"
說得很對。
視頻 Skill 之所以能穩定產出，就是因為它背後有一套精心設計的 Harness：
分階段的執行編排、文件化的狀態記憶、強制的人工檢查點、獨立的 Reviewer 質檢、最小切片的修復機制。
這次，我想驗證一個更重要的觀點：好的 Harness 是可以遷移的。
今天我們用幾乎同一套骨架，做一件完全不同的事 — 把任何文字編輯成精美的網頁文章。
二、這次為什麼做 Beautiful Article
2.1 從 Claude 的一篇博客說起
Claude 官方最近發了一篇文章，叫《The unreasonable effectiveness of HTML》。
核心觀點是：Markdown 寫文章很簡單，但面對複雜報告、圖表、交互、視覺結構時不夠用。
由於 AI 能力的增強，人們不用再關心複雜的語法時，HTML 的優勢就很明顯了：
信息密度高 — 表格、SVG、代碼片段、公式可以混排；
視覺結構化 — 標題層級、顏色、間距都可以精確控制；
可交互 — 摺疊、Tab、複製按鈕、可調控件；
易分享 — 一個文件發出去，對方直接打開，不需要裝任何東西。
2.2 但是：HTML 很強 ≠ 該讓 AI 裸寫 HTML
問題來了。HTML 很強，但這不意味着應該讓 AI 自由裸寫 HTML。
當內容很長、視覺元素很豐富的時候，讓 AI 裸寫 HTML/CSS 可能會遇到很多問題：
單文件巨大，後續很難做更改和維護
效果不可控，很難穩定按照你的要求產出內容
讓文字失去 “文章” 感，看起來像網頁應用
這和視頻 Skill 的痛點是 相同的 — 模型有能力，但你需要一套系統來駕馭這個過程，下面看看這套流程是怎麼設計的
三、Beautiful Article Skill
為此，我開發了一個全新的 Skill，叫 Beautiful Article 。
它也已經和花園老師之前開源的所有其他 Skill 一起發佈到 Garden Skills 倉庫裏了：
https://github.com/ConardLi/garden-skills
3.1 執行流程：從素材到文章的 8 個 Phase
整個 Skill 把 "從任意素材到精美文章" 切成了 8 個階段，中間卡了 3 個強制人工檢查點。
Phase 0 Intake 判斷是否進入本 Skill + 初步文章類型
▼
Phase 1 Source → Markdown URL/PDF/DOCX/MD/文本 → source.md + extraction-notes.md
▼
Phase 2 Editorial Planning 一份 plan.md（Brief / Outline / Theme / Assets 四段）
▼
Phase 3 Plan Checkpoint ★Checkpoint 1 必須停
▼
Phase 4 First Spread 首屏 + 第一節 + 一個代表性視覺塊
└ ★Checkpoint 2 必須停
▼
Phase 5 Full Article Build 生成完整網頁文章
▼
Phase 6 Final Review 三視角終審
▼
Phase 7 Repair 最小切片修復
▼
Phase 8 Delivery ★Checkpoint 3 必須停 → 交付 article.html
3.2 先認識底層：Reacticle 組件協議
這裏需要注意的是，在上面的開發過程，Agent 編寫的並不是原始的 HTML，而是一套我們特殊定製的底層組件協議，我們給它命名叫：
Reacticle = React + Article。
一句話定位：
Markdown 讓 人 輕鬆寫文章；
Reacticle 讓 AI 可控地生成長文 HTML。
它給 AI 定義了一套專門用來寫文章的、被約束的、語義化的 React 組件契約。
https://github.com/ConardLi/reacticle
三個關鍵設計
語義組件詞彙表
Reacticle 提供了一組專門用於編寫 “文章” 的組件，基本可以平替 Markdown 的所有語法：
Article / Hero / Lead / Section / Subsection / Table / Quote / Formula / CodeBlock / Image / TOC / Conclusion …
AI 只負責 "組合" 這些組件，結構和排版由庫保證。
不需要 AI 去想 "這裏用 div 還是 section"、"標題用 h2 還是 h3"、"間距設多少" — 這些全被組件封裝掉了。
結果就是：穩定、不崩版。
Raw 自由層（受契約約束）
但只有組件會不會太死板？有些視覺效果組件做不了怎麼辦？
Reacticle 提供了一個逃生艙叫 Raw。
任意 HTML/SVG/CSS/React 都能塞進 Raw
你想畫一個自定義的時序圖、做一個交互式的滑塊、放一個 Canvas 動畫，都可以。
但有一條硬約束：
Raw 裏的所有樣式必須消費我們約束好的主題 token。
這樣，我們給模型提供了自由的同時，還約束了各個主題效果的穩定性。
Reacticle 目前有 11 套編輯級主題：
每套主題都同時是兩份東西：
一份 CSS token 包 — 定義顏色、字體、間距、陰影等所有視覺變量；
一份給 AI 讀的 Markdown — 告訴 AI 這套主題該用什麼配圖風格、什麼代碼高亮、什麼 Raw 慣用法、什麼是反模式。
比如 Tufte 主題的 profile 會告訴 AI：
"這個主題追求數據墨水比，不要用漸變、不要用陰影、圖表要極簡、正文是主角。"
比如 Sottsass 主題的 profile 會告訴 AI：
"這是 Memphis 風格，可以用撞色、可以用黑描邊、可以有輕微旋轉的元素、但不要太正經。"
Reacticle 和 Skill 的關係
Reacticle 是 運行時協議
類比樂高積木，管的是 "輸出表面穩不穩"。
它不規定你怎麼寫作、怎麼規劃、怎麼審閲。
怎麼從素材規劃、生成、審閲、交付 那套方法論和 Harness，住在 beautiful-article Skill 裏
類比拼裝積木的說明書，管的是 "整個生產過程穩不穩" 。
這套流程背後還有一系列設計原則：
文件化記憶、漸進加載上下文、分節點質檢、最小切片修復……。
我們放到實戰之後再展開
到時候你會發現，它們和上一篇視頻 Skill 的骨架幾乎一模一樣。
四、環境搭建
下面，我們來實際演示一下這個 Skill 的使用。
對於國內的同學，我依然優先推薦的是 MiniMax + Claude Code 這套組合。
4.1 Claude Code
首先我們選擇 Claude Code 作為我們的核心執行 Agent。
注：如果你本地使用 Cursor、Codex 以及其他支持 Skill 的 Agent 都是可以的。
安裝命令：
curl -fsSL https://claude.ai/install.sh | bash
裝好之後，在終端裏輸入：
claude -v
可以測試是否正常安裝成功。
4.2 MiniMax M3
這次我把模型換成了最新發布的 M3，當 Harnees 已經調教的非常好之後，選擇一個能力強的模型就至關重要了。
MiniMax M3 號稱首個 Coding Agentic 達到 SOTA、1M Context、原生多模態 三項能力兼備的模型。
這幾個能力單獨看都不新鮮，但放在實際的生產場景裏組合起來就很關鍵了。
在我個人使用體驗上，相比上一篇教程裏用的 M2.7，M3 在長上下文理解和複雜指令的遵循上有明顯提升。
對於我們這次這種多步驟、多檢查點、需要反覆回讀文件的長任務場景，M3 是非常適合的。
依然推薦大家搭配 Token Plan 來使用，我自己現在使用的是 Max 極速版。
量大管飽速度快、天然契合 Claude Code，也不用擔心封號風險，在一些場景下非常接近原生 Claude Code 的體驗了。
訂閲完成後，會生成一個 API Key ，這個提前存好後面會用到：
4.3 CC Switch
CC Switch 是一個桌面配置工具，可以讓我們的 Agent（Claude Code、Codex、Gemini CLI）切換為任意的自定義模型。
在這套流程裏，我主要用它來配置 MiniMax 的 Token Plan。
直接到它的 Github Release 頁面就可以下載指定系統（如 MacOS）的安裝包：
點擊右上角 ”+” ，選擇預設的 MiniMax 供應商：
然後填寫上一步保存的 API Key：
然後把模型名稱全部改為 MiniMax-M3，然後直接點擊保存就可以使用了：
回到首頁，點擊 “啓用”：
下面，我們打開終端輸入 claude ，就可以直接使用了：
4.4 安裝 Skill
訪問 garden-skills 倉庫：https://github.com/ConardLi/garden-skills/，找到 beautiful-article Skill，下載安裝包：
下載完成後解壓得到 Skill 具體目錄，然後放進工作目錄的 .claude/skills/ 文件夾。
啓動 Claude Code，輸入 /beautiful-article，能智能提示出來就說明配置成功。
五、實戰：把一篇文章編輯成精美網頁文章
下面用 Claude Code + MiniMax M3 走一遍完整流程。
然後，我還是選一篇 Anthropic 的技術博客作為輸入素材：
5.1 啓動 Claude Code
進入項目目錄，啓動 Claude Code：
claude --dangerously-skip-permissions
老規矩，--dangerously-skip-permissions 只在可信目錄用。
5.2 投餵素材，啓動 Skill（Phase 0–1）
把文章 URL 丟給它，告訴它用 /beautiful-article：
讀取這篇文章：https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything
按照 /beautiful-article 要求，幫我產出一篇精美的中文文章。
Agent 在讀取我們的 Skill 後，首先開始識別輸入是什麼、目標語言是什麼、任務邊界是什麼。
比如這裏它判斷素材是一篇 Claude 博客文章，目標是中文文章，預期文章類型更接近 longform，也就是信息保留比較高的完整長文。
然後它抓到網頁正文後，開始產出幾個文件：
任務完成後，我們看到本地工作目錄多了幾份文件：
source.md：原始素材的 Markdown 版本。無論輸入是網頁、PDF、文檔還是一段文字，都會先被統一整理成這份文件，後面所有寫作都以它為事實來源。
source.zh.md：由於我們要做的是中文版，它會先產出一份地道翻譯版
source.zh.md作為事實底座，後續基於翻譯版編寫。
extraction-notes.md：抽取記錄。比如哪些圖片沒拿到、網頁裏哪些內容可能缺失、哪些地方存在格式或語義不確定性，都會記在這裏，方便後面人工判斷。
5.3 編輯規劃（Phase 2）
接下來它會生成 plan/plan.md，分四段：
Brief：目標讀者、文章類型、信息保留比例、語氣、主要觀點、閲讀目標。
Outline：Hero / Lead / 各 Section 列表 / 每節保留哪些信息 / 每節需不需要 Raw/Table/CodeBlock/Formula。
Theme：推薦哪個主題 + 理由。
Assets：配圖策略與逐圖計劃。
這份文件就是後面所有開發的邊界 — 文件化工作記憶。
5.4 第一次人工確認 · Plan Checkpoint（Phase 3）
這是第一個必須停的檢查點。
它會逐項問你 5 件事（Agent 會根據原文的類型給你推薦最適合的選項， 但不會替你做決定）：
1. 文章類型 + 信息保留比例
Skill 內置了幾套完全不同的文章類型
完整長文
longform · ~100%：適合原文質量高、值得完整歸檔的材料，儘量保留全部論證，只做編輯和排版增強。研究報告
full-report · ~80%：適合調研、技術評估、正式分析，重點是執行摘要、關鍵發現、數據、風險和建議。教學步驟
tutorial · 80-100%：適合“跟着做就能跑通”的內容，步驟、代碼、驗收點不能丟。概念解釋
explainer · ~80%：適合把一個機制、系統、算法講明白，保留關鍵直覺和易錯點，刪掉旁枝。對話訪談
dialogue · ~80%：適合播客、訪談、AMA，把口語冗餘刪掉，但保留說話人的語氣和觀點。工程審閲
review · 60-80%：適合 PR、方案、事故、架構設計這類具體產物審閲，重點是發現、證據、影響和行動項。觀點評論
essay · 60-80%：適合評論、評測、敍事和專欄，重點不是面面俱到，而是一條清晰的觀點線。決策摘要
briefing · 40-60%：給忙人看的，結論先行，只保留關鍵事實、取捨和下一步。交互式解釋
interactive-explainer · ~25% 原文摘錄：不是簡單刪掉 75%，而是把原文重構成可操作的學習頁，用交互演示幫讀者真正玩明白。
這一步本質上是在問：你希望讀者完整讀完、快速判斷、跟着做、理解一個機制，還是被視覺帶着走？答案不同，後面生成出來的文章形態會完全不一樣，我們這次選擇 100% 保留的完整長文風格。
2. 主題
這次我們不聽它的，選擇一個個性點的 Bayer 主題：
3. 版式寬度
選項：narrow / regular / wide / full。我們選擇默認的 regular。
4. 配圖模式
選項：none（不用外部圖片）/ user-assets（你提供）/ placeholders（先用佔位圖）/ ai-generated（AI 生成）。
注意：這隻決定是否使用外部 Image 組件，HTML 內容的繪製不受影響，我們選擇不實用外部圖片。
確認完這幾件事，它會根據我們的決策修訂開發計劃：
然後才會進入下一階段。
5.5 封面 + 首章開發（Phase 4）
它先用 scaffold.sh 起一個 Vite + React + TS 的工作區，從 npm 裝最新版 Reacticle。
然後只做一小塊：封面 + 首屏 + 第一節 + 一個代表性視覺塊。
這一步不會寫完整篇文章，而是先定調。
開發完成後，它不會立刻完成，而是開一個 First Spread Reviewer SubAgent 來質檢：
所有質檢的過程，它會寫入 first-spread-review.md 文檔。
然後按照 fail 項逐一進行修復：
然後，我們就可以人工驗收了，這一步的人工驗收很有必要，首屏和第一節基本決定了整篇文章的氣質：
5.6 第二次確認（Checkpoint 2）
然後進入 Checkpoint 2，獨立確認 2 件事：
1. 驗收結論
選項：這一步可以大膽提出你的建議，標題方向、信息密度、主題觀感、正文節奏、視覺塊風格，哪一點你覺得不舒服都可以讓它先調整好。
如果這一步已經偏了，後面寫得越多，返工成本越高。
2. 後續開發模式
A · 單 Agent 順序（最穩、風格最統一）
B · 多 Agent 並行（最快、考研模型能力）。
5.7 完整生成 · Full Build（Phase 5）
確認後進入完整生成，我們選的 B 並行模式，會有多個 SubAgent 並行開發：
我們可以切換每個 SubAgent 查看具體的開發詳情：
這種多 Agent 調度對模型能力要求就很高了，M3 在這塊的表現比較穩
能準確理解每個 SubAgent 的邊界，不會出現" 兩個 Agent 改同一個文件 "或" 忘了合併某個 Section"的情況。
然後我們可以看到工作區的文件結構：
一節一文件是 Skill 的 鐵律，這是多 Agent 並行的前提，也讓後續維護更容易。
5.8 終審 + 修復（Phase 6–7）
所有 Section 寫完後，Skill 會指導開三個獨立的 SubAgent 進行質檢，維度各不相同：
Editorial Reviewer：文章性、信息取捨、結構
Visual Reviewer：主題、Raw、配圖、移動端
Technical Reviewer：構建、控制枱、代碼/公式、可訪問性
如果這一步檢出問題，會進入最小切片修復。
所有審核 + 修復的記錄，全部都會記錄到本地文件，這些文件不是給你看的，而是給 Agent 看的：
這些日誌可以促使後續 Skill 的自進化，讓它知道在之前的任務中，什麼環節容易出問題。
5.9 交付（Checkpoint 3 + Phase 8）
終審改完後，進入最後一個必須停的檢查點。它會問你最終的交付決策：
選項：通過 · 導出 HTML / 通過 · 同時導出 HTML + PDF / 還有局部修復 / 先停一停。
確認後，它會幫我們同時構建出一個 CSS+JS 全內聯的單文件 HTML（斷網可打開、可當文件分享）：
以及一個更方便分享的 PDF 格式，兩者內容效果完全一致。
然後你會發現，原來普通的文字，現在是一篇視覺效果精美、結構清晰、可離線閲讀、可直接分享的長文。
六、好的 Harness 是可以遷移的
跑完實戰，我們回過頭看。
在上一篇視頻教程裏，我們講過一個成熟的 Harness 通常包含六個核心部分：
現在把視頻 Skill 和文章 Skill 放在一起對照：
你會發現設計上非常相似，下面我們逐層展開說一下：
6.1 上下文管理：每個階段只看該看的東西
上下文管理解決的是：模型當前應該看到哪些信息。
Skill 不會在啓動時把所有規範、主題、組件文檔一次性塞進去。
Phase 1 只處理素材抽取（
source-to-markdown.md）；Phase 2 再看文章類型（
article-types.md）、信息密度（plan-template.md）和主題選擇（theme-selection.md）；Phase 4/5 進入開發後，才讀取組件協議（
component-policy.md）、Raw 規範（raw-policy.md）和當前主題 profile。
如果一開始就把所有文檔灌進去，模型注意力會被嚴重稀釋。
漸進加載讓每個階段只看該看的東西。
長會話裏還有一個細節：
每寫一節前，Agent 都要回看當前 Section 的任務、組件協議、Raw 規範和主題約束。
靠文件把自己拉回正軌，減少寫到後面風格和規則會偏移的問題。
6.2 工具系統：讓 Agent 把文件系統用穩
工具系統解決的是：模型能調用哪些能力，以及這些能力怎麼被組織起來。
Skill 主要用的還是 Agent 自帶的能力：抓取資料、讀寫文件、執行腳本、跑本地構建、打開瀏覽器預覽。
關鍵在於，Skill 給這些能力套了一層穩定的工作區結構。
第一步，所有輸入都會先整理成 source.md。
URL、PDF、DOCX、Markdown、純文本，最後都會回到同一份 source 文件上。
需要中文寫作時，再生成 source.zh.md；
抽取過程中的風險、缺失和不確定項，寫進 extraction-notes.md。
第二步，進入開發階段後，腳手架會創建標準的工作區。
source/、plan/、review/、article/sections/、article/raw-blocks/ 都有固定職責，Agent 不需要臨時發明項目結構。
第三步，是並行安全。
完整文章可能有很多節，如果開多個 Agent 並行寫，每個 Agent 只負責一個 section 文件；
大型 Raw 放到獨立的 raw-blocks/；
Article.tsx 只交給主 Agent 組裝和排序。
這樣多 Agent 可以同時工作，又不會一起改同一個文件。
每節內容彼此隔離，最後由主 Agent 合成一篇完整文章。
6.3 執行編排：先規劃，再定調，再放量
執行編排解決的是：模型下一步該做什麼。
視頻 Skill 把 "文章→視頻" 切成 4 階段（內容編寫 → 開發 → 音頻 → 錄屏），卡 2 個人工檢查點（Plan / Audio）。
文章 Skill 把 "素材→文章" 切成 8 個 Phase，卡 3 個檢查點（Plan / First Spread / Delivery）。
階段數不同、檢查點位置不同，但 骨架一樣：
把一個複雜任務拆成線性流程，在關鍵節點強制停下來讓人拍板。
先做小部分讓人工確認基調和問題，再大刀闊斧的開發後續章節。l
還有一條鐵律：檢查點禁止替用戶做主。
每個決策項必須獨立列出、獨立等用戶答覆。
可以推薦（"我推薦 Tufte 主題，因為這篇數據多"），但不能說"已經替你選了 Tufte，不對告訴我" — 後者等於偷渡默認值。
6.4 狀態與記憶：關鍵決策必須落盤
狀態與記憶解決的是：系統如何跨步驟保持連續性。
長任務裏，Agent 很容易忘掉前面確認過的方向。所以 Skill 會把關鍵狀態寫進文件。
source.md 和 source.zh.md 是事實底座，extraction-notes.md 記錄抽取風險，plan.md 記錄文章類型、目標讀者、信息保留比例、章節結構、主題和配圖策略。
這些文件就是 Agent 的工作記憶。
寫到後面的章節時，它不用憑印象回憶前面怎麼定的，直接回讀文件就行。
這樣可以減少長會話裏最常見的問題：前面確認過的方向，寫着寫着又變了。
6.5 評估與觀測：審核要放在關鍵節點
評估與觀測解決的是：系統怎麼知道自己做得對不對。
這一層很關鍵，Agent 寫完一節，很容易覺得“結構清楚、視覺不錯、內容完整”，但真實問題可能藏在細節裏：
信息保留比例不夠、主題氣質跑偏、Raw 只是裝飾、移動端擠在一起、某節和前後文接不上...
所以文章 Skill 給幾個關鍵產出都設置了質檢點：
source.md | |
plan.md | |
為了平衡效率和質量，執行方式也有區分。
Plan 階段上下文還熱，由主 Agent 直接對照清單自查；
First Spread 和 Final Review 是關鍵節點，所有檢查都使用獨立的 SubAgent；
還有一條硬規則：拿到質檢結論後，先修復，再彙報。
不能把 “發現了什麼問題” 當成完成，真正完成的是 “問題已經被修掉”。
6.6 約束與恢復：給 AI 一個穩定的輸出框架
約束與恢復解決的是：怎麼避免跑偏，以及跑偏後怎麼修。
文章 Skill 的核心約束是 Reacticle 組件協議。
AI 寫文章時，正文用 Article / Section / Table / Quote / CodeBlock 這類語義組件承載；
複雜視覺放進 Raw，但 Raw 也必須消費主題的風格約束。
這樣既有自由度，也能守住整體風格。
修復時依然保留了視頻 Skill 的最小切片修復的思路。
某節信息太薄，就補那一節；某個 Raw 太花，就改那個 Raw；首屏氣質不對，就改 Hero / Lead / Summary。
這能保護已經正確的部分，避免一次局部反饋把整篇文章重新搞壞。
6.7 自進化：讓日誌反過來改進 Skill
Skill 的自進化是最近的熱點話題，我在設計這個新的 Skill 時也考慮了這個問題，怎麼讓 Skill 能越用越好呢？
我的做法是，所有關鍵點質檢審查和修復記錄會落到本地文件裏
比如 review/first-spread-review.md、review/final-review.md、review/repair-log.md。
這些文件不只給人看，也給 Agent 看。
同類任務跑多了以後，Agent 可以回看這些記錄，分析之前哪些環節最容易出問題：
目錄需要是不是容易寫錯，Raw 是否經常過度設計，某類文章類型的信息保留比例是否需要調整。
這些問題沉澱下來以後，就可以反過來促使 Agent 優化 Skill 的規則、檢查清單和默認策略。
所以 Skill 會隨着真實任務繼續進化。
七、最後
7.1 昇華一下
跑完這次實戰，再回頭看這套文章 Skill，會發現真正值得複用的不是某一段提示詞，也不是某一個組件。
真正值得複用的是這套工作方法：
把複雜任務拆成階段；
把關鍵決策變成檢查點；
把上下文寫進文件；
把輸出表面收進協議；
把質量問題交給審核；
把修復限制在最小切片；
把審核和修復日誌沉澱下來，反過來改進下一次流程。
這就是 Harness 的價值。
它讓 Agent 從“能做出一次效果”，變成“能穩定生產一類結果”。
做 Harness 也不一定要從零搭一個 Agent。把一個垂直任務用 Skill 做穩、做好，本身就是在做 Harness。
今天這套流程用來把文章做成網頁長文，換一個場景，也可以是：
週報 — 每週素材 → 結構化週報 HTML
播客 Shownotes — 音頻轉錄 → 精美筆記
課程講義 — 教案 → 可交互講義
技術文檔 — API Spec → 漂亮的開發者文檔
產品發佈頁 — PRD → 單頁展示稿
只要任務足夠複雜，需要狀態、流程、檢查點和交付標準，這套骨架就有遷移價值。
最後留下來的，也不只是一個 article.html。
還有一條被驗證過的生產路徑。
7.2 資源連結
Reacticle：https://github.com/ConardLi/reacticle beautiful-article Skill：https://github.com/ConardLi/garden-skills Showcase / Gallery：https://rearticle.mmh1.top/#/gallery CC Switch：https://github.com/farion1231/cc-switch/issues MiniMax：https://platform.minimaxi.com/subscribe/token-plan Claude Code：https://claude.com/product/claude-code
歡迎拿一篇自己的文章試試。
如果本期教程對你有所幫助，留下一個免費的三連吧！