【2026 最新】Hallmark 是什麼？用 Claude Code／Codex 擺脫 AI 味：Build、Audit、Redesign、Study 實戰

最後更新：2026年7月26日 · Terry Chen

Hallmark 是什麼：Claude Code 與 Codex 的 Build、Audit、Redesign、Study 網站設計實戰

Hallmark 是什麼？一句話：它不是會自動把網站「變漂亮」的 App，也不是另一個前端框架；它是一套裝進 Claude Code、Codex 等 AI coding agent 的設計 Skill，把版面結構、字體、色彩、互動、響應式與交稿前檢查寫成 Agent 能重複執行的規則。

這個問題會紅，不難理解。2026 年 7 月，一則 Reddit 討論直接抱怨預設 frontend-design Skill 做出來的網站總是相似；7 月 26 日的未登入頁面先後顯示約 16～18 points、十多則留言。幾天後也有 Ask HN 使用者詢問怎麼改善 LLM 的前端成果，但只有 2 points、1 則留言，屬於需求旁證，不是大規模調查。同一週，Hallmark 在 GitHub Trending 顯示 4,881 stars this week，skills.sh 頁面則顯示約 27.9K installs。這些數字證明它很受注意，不能證明它做得比較好。

所以這篇不只翻譯官方 README。我用同一份 landing page brief、同一個 Codex 環境，分別跑了「沒有 Hallmark」與「載入 Hallmark」兩版，再把桌機與手機截圖匿名交給兩位盲評者。結果很誠實：沒用 Hallmark 的版本反而以 53／60 小勝 Hallmark 的 51／60。Hallmark 的價值不是保證勝出，而是把「品味」拆成能討論、能稽核、能迭代的設計決策。

Hallmark ＝ Brief（要解決什麼）＋ Macrostructure（頁面的骨架）＋ Theme／Custom（表面語言）＋ 58 道自評 gates（交稿前煞車）

Hallmark 運作原理：從 brief、macrostructure、theme 或 custom 到 58 道 slop gates 與可測試網站 — Hallmark 不是一個濾鏡；它先決定骨架，再決定視覺語言，最後用規則自我挑錯

Table of Contents

Hallmark 是什麼？先拆掉三個誤會

Hallmark 的 GitHub repo 把自己描述為「拒絕看起來像 AI 生成」的 design skill；目前 repo 內宣告版本為 1.1.0，授權是 MIT。它的主體是 SKILL.md 與一組 Markdown references，沒有 runtime dependency、沒有可執行的 bin，也不會像 ESLint 一樣真的掃過 DOM 後吐出客觀分數。

它不是 npm 前端套件：不要執行 npm install hallmark；npm 上同名套件是另一個 Markdown linter，與本文工具無關。
它不是保證器：所謂 58／58 是 Agent 依文字規則做的自我檢查，不是瀏覽器、axe、Lighthouse 或真人 usability test 的替代品。
它不是固定模板：Hallmark 會從 21 種 macrostructures 選頁面骨架，再套 20 個 themes 或走 Custom；但模型仍可能偏好某些熟悉手法，所以跨專案要看實際輸出，而不是只信數量。

如果你已讀過 AlphaLab 的AI Agent Harness 白話解釋，可以把 Hallmark 想成「專門管 UI 品味的 harness」。一般 prompt 只說終點，例如「做一個有質感的 landing page」；Hallmark 還規定 Agent 在途中要先查現有 design system、選一種結構、避開常見 AI 套路、保留可存取性，再留下下一輪可以接手的設計脈絡。

真正核心：Macrostructure 不是 Theme

很多 AI 網站看起來同一個模子，不只是因為都用紫色漸層，而是「骨架」沒變：置中 hero、三張功能卡、logo wall、testimonial、pricing、FAQ。換色、換字體，仍是同一棟房子重新油漆。

Macrostructure 是整頁的組織形狀。Hallmark 目前列出 21 種，包括 Long Document、Bento Grid、Workbench、Manifesto、Catalogue、Letter、Index-First、Map／Diagram、Component Playground 等。Theme 則是表面語言，目前列出 20 個，例如 Newsprint、Terminal、Garden、Riso、Cobalt、Lumen。白話比喻：macrostructure 是房子的格局，theme 是材質、燈光與家具。

當現有 catalog 不適合 brief，Hallmark 會進入 Custom。官方再分兩層：tuned custom 主要自訂 OKLCH 色盤與免費字體，仍沿用既有結構；bespoke custom 連結構也重新設計。這個分層很重要，因為「把品牌色塞進同一個 landing page 模板」不算真正的品牌設計。

Build、Audit、Redesign、Study 四種模式怎麼選？

Hallmark 四種模式比較：Build 建新頁、Audit 唯讀找問題、Redesign 保留產品邏輯換骨架、Study 分析參考設計 — 選模式先看「輸入是 brief、現有程式碼，還是參考設計」，不要一律叫它重做

1. Build：從 brief 做一個新頁面

適合：新 landing page、新功能頁、作品集。Agent 會先 preflight：找現有 design.md、字體、色票、spacing、motion 與框架，再判斷受眾、用途與語氣，選 macrostructure 和 theme，最後實作與自評。這是預設行為，不一定要在 prompt 裡再寫 build。

2. Audit：唯讀找出 AI 味與設計債

適合：你已經有網站，但不知道問題在哪。Audit 的輸出應該是 Tell／Where／Severity／Fix：看見什麼、出現在哪、嚴重度、怎麼修；預設不改檔。官方現行規則沒有定義可信的 0～100 總分，所以不要要求 Agent 製造一個看似科學的 87 分。

3. Redesign：保留產品，換掉設計骨架

適合：資訊與功能已對，但整體像模板。Redesign 預設保留文案意圖、事實、IA、品牌、主要 action、路由與 component ownership，也保留資料流、auth、forms、analytics 等產品邏輯；它應先盤點多頁，再提出新的 design.md 方向，確認後才動手。這不是「順便重寫整個 App」的授權。

4. Study：學設計 DNA，不做像素複製

適合：你有一張 screenshot 或公開 URL，想理解它為什麼有效。第一輪應先診斷 macrostructure、字體角色、色彩 anchor、密度與互動節奏，不急著出 code。只靠 screenshot 不能準確知道字體名稱或 motion；讀 URL 也可能遇到登入牆、SPA 空殼與跨網域 CSS。好的 Study 是萃取原理，必要時再用 lock the DNA 寫入 design.md，不是抄第三方頁面。

Hallmark 安裝教學：Claude Code 與 Codex 路徑不同

最簡單的安裝入口是 Hallmark README 提供的 Skills CLI：

npx skills add nutlope/hallmark

互動式安裝會讓你選 Agent 與範圍。若要在專案裡固定、可重現地安裝，可用：

# Codex：專案 Skill 會進入 .agents/skills/hallmark
npx -y skills@latest add nutlope/hallmark \
  --agent codex --skill hallmark --copy -y

# Claude Code：專案 Skill 會進入 .claude/skills/hallmark
npx -y skills@latest add nutlope/hallmark \
  --agent claude-code --skill hallmark --copy -y

截至 2026 年 7 月 26 日，Codex 官方 Skills 文件把專案路徑寫成 .agents/skills、個人路徑寫成 $HOME/.agents/skills；Claude Code 官方文件則使用專案 .claude/skills、個人 ~/.claude/skills。Hallmark README 仍把 Codex 寫成舊的 .codex/skills，所以本文以目前的 Codex 官方文件與安裝器實測為準。

安裝指令在 shell 跑，使用指令在 Agent 對話框打。Claude Code 可輸入 /hallmark audit ./src；Codex 可輸入 $hallmark audit ./src。它們不是 terminal 裡的 hallmark executable。

Hallmark 安裝與品牌客製流程：Claude Code 放入 .claude/skills，Codex 放入 .agents/skills，再以 design.md 鎖定品牌系統 — Skill 管通用方法，design.md 管你自己的品牌；兩者不要混成一份永遠複製的模板

同一份 brief 實測：Hallmark 沒有自動獲勝

為了避免「挑兩張自己喜歡的圖」當證據，我在 2026 年 7 月 26 日做了一個小型 pilot。環境是 Codex CLI 0.145.0；Hallmark 固定在 Git commit aeb42fb。兩個乾淨 git repo 使用同一份英文 brief：替里斯本的 phone-free coworking club「Quiet Hours」做 vanilla HTML／CSS／JS landing page，受眾是 freelance designers 與 writers；所有日期、地址、價格、取消規則、FAQ 與 responsive widths 都相同，也禁止外部 assets、假數據、假評論、假 logo 與假成功狀態。

A 版：prompt 前加 $hallmark，Agent 選擇 Long Document＋Newsprint＋typography-only。
B 版：不載入 Hallmark，只給原始 brief。
匿名盲評：兩位評分者只看到 A／B 的 1440px 桌機與 375px 手機截圖，不知道哪版使用 Hallmark。
技術檢查：實際用 Chrome 測 320、375、414、768、1280px，檢查水平溢位、off-screen 文字、FAQ、表單與 console；兩版 JavaScript 也都通過語法檢查。

Quiet Hours 同一 brief 盲測畫面：A 為 Hallmark Newsprint 長文件，B 為未使用 Hallmark 的大字與圓形時段主視覺 — 先看圖再揭曉：A 是 Hallmark；B 是未載入 Hallmark。兩版都不是刻意做壞的稻草人

結果不是「Hallmark 輾壓」。兩位盲評者都給出同一總分：A 51／60、B 53／60，B 小幅勝出。B 的 headline 與黑色 Reserve 按鈕讓行動更直接，手機首屏的轉換路徑也更成熟；A 的報紙感、細線底紋與資訊表格更有策展感，時間、地址、價格、席次又放得更明確，但主要 CTA 太像文字連結。

Hallmark pilot 盲測結果：A Hallmark 51 分、B 無 Hallmark 53 分，Hallmark 勝在品牌與具體性、敗在 CTA 與 mobile — 單次 pilot 的正確讀法：Hallmark 改變了取捨，沒有消滅取捨

技術面則幾乎平手：兩版在五個寬度都沒有水平 overflow 或 off-screen 文字，六題 FAQ 都能開合，也都有 skip link 與 reduced-motion CSS。Hallmark 版額外做了自訂 inline validation，並把 reservation form 接到不存在的 /api/reservations，失敗時誠實顯示錯誤；未使用 Hallmark 的版本用原生 required validation，成功畫面也明說「尚未真的保留席位」。

還有成本：這次 Codex CLI 回報的總 token 使用量，Hallmark 版約為 baseline 的兩倍。這不是精確價格比較，因為 token 類型、cache 與模型計價會變；但多讀一整套 Skill、逐項自評、再修正，確實不是免費。想控制 coding agent 的 context 與成本，可搭配 AlphaLab 的Claude 省 Token 方法與Claude Code vs Codex 比較一起看。

57 還是 58 道 slop gates？官方文件自己也有 drift

Hallmark 首頁與 README 仍宣傳 57 道 gates；但固定在本次實測 commit 後，slop-test.md 實際列出編號 1～57，另外還有 38a，合計 58 個離散檢查。現行 SKILL.md 與輸出預覽也要求 58／58。除此之外，交稿前還有 P／H／E／S／R／V 六軸各 1～5 的 pre-emit critique；這六軸是另一層自評，不應再混進 58。

規則涵蓋的範圍很廣：避免預設 Inter、紫藍漸層、三欄等高卡片、膠囊按鈕泛濫、假 dashboard、過量 glassmorphism；也包含 hover／focus、鍵盤路徑、mobile 順序、reduced motion、表單誠實狀態與文字可選取等。它的價值是讓 Agent 在交稿前被迫問 58 次「我是不是又走回平均值？」

但文件 drift 也提醒你：Skill 本身需要版本管理。官方 docs/recipes.md 文字說有 8 個 recipes，實際列了 00～08 共 9 個，還使用目前 catalog 已移除的 Linen、Salon、Plain 等舊 theme 名稱。實務上應以固定 commit 的 SKILL.md 與 dedicated references 為優先，不要把 README 的行銷數字當規格。

完整實戰：四個可以直接改的 prompt

Build：先給品味邊界，不要只說「有質感」

$hallmark
Build the landing page in ./src.
Audience: independent financial researchers in Taiwan.
Primary action: start a 14-day trial.
Tone: sober, evidence-first, editorial — not luxury.
Preserve the existing copy, routes, analytics, and form behavior.
Use the current brand tokens. If they conflict, stop and list the conflict.
Verify at 320, 375, 768, and 1280px. Do not invent metrics or testimonials.

痛點：「有質感」沒有可驗收定義。解法：補上受眾、唯一主要 action、語氣、不可改內容、禁止造假的 proof 與 viewport。效果：Agent 可以判斷結構與品牌是否服務任務，而不是只追求漂亮截圖。

Audit：要求證據位置與修法，不要先改

/hallmark audit ./src
Read-only. Do not edit files.
For each finding return:
Tell / exact file or component / severity / why it hurts the user / smallest fix.
Separate brand inconsistency, responsive defects, accessibility risk,
and generic AI-pattern risk. Do not invent a total score.

Redesign：先鎖住產品不變量

$hallmark redesign ./app
Preserve copy intent, factual claims, routes, data flow, auth,
form submission, analytics events, and component ownership.
First inventory all affected pages and propose a design.md.
Do not edit until I approve the macrostructure and token direction.
Then redesign one representative page before propagating the system.

Study：先萃取 DNA，再決定要不要鎖定

/hallmark study https://example.com/reference
First turn: diagnosis only, no code.
Separate what is directly observable from what is inferred.
Explain macrostructure, type roles, color anchors, density,
navigation behavior, and responsive unknowns.
Do not copy assets, copy, or paid-template structure.
If useful, propose a brand-safe design.md for approval.

Claude Code 與 Codex 的 prompt 內容可以相同，只需把明確呼叫方式換成 /hallmark 或 $hallmark。如果你還不熟兩者的角色與工作方式，先看Claude、Claude Code、Cowork 差異，再用AI Agent Harness 實作教學理解為什麼「規則＋工具＋驗證」比一條超長 prompt 更容易維護。

怎麼加入自家品牌規範，又不退化成另一套模板？

最穩的做法不是直接把 Hallmark 的 58 條改成你喜歡的畫面，而是分三層：

把不變量寫進 design.md：品牌定位、字體角色、色彩 token、spacing rhythm、icon 原則、motion 上限、content density、禁止事項與真實 component examples。
保留 Hallmark 的通用 gates：focus、keyboard、reduced motion、mobile order、誠實狀態、避免假 proof 等，不要因品牌風格而刪掉基本品質。
每個專案仍重新選 macrostructure：同一品牌可以有產品頁、文件頁、活動頁；品牌一致不等於每頁同骨架。先做一頁、真人 review、再說 lock the system，讓 Agent 把被批准的選擇回寫。

一個好 design.md 寫的是「為什麼與何時」，不是一張固定 wireframe。例如：「主色只用在可操作元素；長篇研究內容採 68～76 字元欄寬；數字證據要靠近原始來源；pricing page 可用強 CTA，但研究文章不放浮動 CTA。」這些規則能跨頁保持品牌，又留給 Agent 結構選擇。

Hallmark 的 7 個坑：別把 anti-slop 變成新 slop

自評不是外部驗證。我們的 A 版宣告 58／58，但盲評仍指出 CTA 太弱。用瀏覽器、axe／Lighthouse、真機與真人 task test 補上外部證據。
Hallmark 也可能長出自己的慣性。GitHub issue #30 甚至用「它們都有 brows」吐槽重複 eyebrow。這是案例訊號，不是統計結論；最好的防法是追蹤多次輸出的骨架與 motif 重複率。
官方 showcase 也有待修問題。issue #41 討論連結語意，#43 討論 reduced motion，對應 PR 在本次截稿時仍可見。這只能證明 showcase 需要 QA，不能推論所有 Hallmark 網站都有同一缺陷。
文件與 Skill 可能不同步。固定 commit，讀 SKILL.md 與 references；更新後先看 diff，再讓它改正式專案。
更多規則會增加 context 與時間。小按鈕、小 bug 不一定值得載入整套設計系統；把 Hallmark 留給頁面級工作、audit 或真正的 redesign。我們另一組 Stillform smoke run 已完成檔案與語法檢查，卻持續留在自我 review 迴圈，最後在 127,921 tokens 手動中止；因為它沒有正常結束，本文沒有把那組拿來算視覺輸贏，也不把這個倍數泛化。
Custom 不等於品牌正確。沒有受眾、語氣、真實 proof 與現有 token，模型只會更自由地猜。自由度越高，review 越不能省。
別讓設計 Skill 越權改產品。Redesign prompt 要明寫 routes、auth、forms、analytics、copy facts 與 data flow 不變；修改商業邏輯應另開任務與測試。

AlphaLab verdict：誰該用 Hallmark？

適合：你常用 Claude Code／Codex 從 brief 生成整頁 UI、團隊缺少專職設計師、已有品牌 token 卻經常被 Agent 忽略，或你需要一套共同語言來做 design audit。Hallmark 尤其適合「baseline 已經能做出東西，但每次 review 都只能說哪裡怪」的團隊。

不適合：你只改一個 component、已有成熟 design system＋Storybook＋視覺 regression tests，或期待一個 Skill 取代設計師、使用者研究與 accessibility audit。這時 Hallmark 最多當第二意見，不該接管整個系統。

我的結論是：Hallmark 值得裝，但不值得迷信。它最有用的地方不是「生成更漂亮」，而是強迫 Agent 把骨架、theme、品牌限制與 anti-pattern 說出來，讓你能逐項反駁。這次 baseline 小勝也正好說明：好 brief、本來就強的模型與人工 review，仍比任何 Skill 名字更重要。若想系統化學習 AI 工作流，可延伸看 AlphaLab 的AI 與投資實戰課程與AI 專題。

Hallmark 是什麼？常見問題 FAQ

Q1：Hallmark 是免費的嗎？

Skill 原始碼採 MIT 授權，可以免費取得。但你使用 Claude Code、Codex 或其他模型產生與修改網站時，仍可能產生方案或 API 費用。

Q2：Hallmark 支援 Claude Code 和 Codex 嗎？

支援以 Agent Skill 方式載入。Claude Code 專案通常放 .claude/skills/hallmark，Codex 專案依目前官方文件放 .agents/skills/hallmark；明確呼叫分別使用 /hallmark 與 $hallmark。

Q3：我應該用 `npm install hallmark` 嗎？

不要。本文的 Hallmark 用 npx skills add nutlope/hallmark 安裝；npm registry 的同名 Hallmark 是不同專案。

Q4：官方到底是 57 還是 58 道 gates？

本次固定 commit 的現行檢查是 58 個。README／官網仍寫 57；slop-test.md 有 1～57 加 38a，SKILL.md 也要求 58／58。未來版本可能再變，請以你安裝的 commit 為準。

Q5：Audit 會直接修改網站嗎？

依官方 contract，Audit 預設是唯讀 punch list。仍建議 prompt 再寫一次 read-only, do not edit，並先看 Agent 的權限模式；文字規則本身不是 filesystem sandbox。

Q6：Hallmark 能取代 Figma 或設計師嗎？

不能。它能讓 coding agent 做出更有意圖的初稿與 audit，但不會替你完成品牌策略、使用者研究、轉換實驗、法務審查與真實 accessibility testing。

Q7：已經有 design system 還需要 Hallmark 嗎？

視問題而定。如果 Agent 常繞過既有 token、亂造 component，Hallmark 的 preflight 與 audit 有幫助；若 Storybook、lint、visual regression 與 review 已很成熟，收益可能有限。

Q8：這次盲測能證明 baseline 比 Hallmark 好嗎？

不能。這是同一模型、每組一次生成、兩位盲評者的小型 pilot，只能反駁「用了就一定更好」。真正 benchmark 應跨 Claude／Codex、每組多次生成、固定時間與 token 預算，並加入真實使用者任務、a11y 與轉換測試。

研究來源與更新基準

Hallmark GitHub repo（固定 commit）：README、SKILL、references、授權與網站原始碼。
Hallmark slop-test.md：58 個離散檢查的逐項核對。
Reddit：Searching for better frontend-design skills、Ask HN：How to improve LLM frontend output：需求訊號，互動數為 2026/07/26 快照。
GitHub Trending weekly、skills.sh Hallmark：關注與安裝代理指標，不作為品質證明。
Hallmark issue #30、#41、#43：重複 motif 與 showcase QA 的反方訊號。

⚠️ 免責聲明

本文更新基準為 2026 年 7 月 26 日，不是 Hallmark、Together AI、Anthropic、OpenAI、Skills CLI 或 skills.sh 的贊助內容。GitHub stars、Trending 與 installs 會變動，也不等於活躍使用者、留存或設計品質。文中的盲測是可重現的小型 pilot，不是統計 benchmark；AI 生成的 code 仍可能有功能、安全、無障礙、版權與品牌錯誤，上線前請由人類 review、實際跑測試並確認授權。