开发工具

Hallmark 怎么安装：让 Codex 和 Claude Code 生成不像 AI 模板的网页

介绍 Hallmark Skill 的安装、audit、redesign 和 study 用法，帮助 Codex、Claude Code 与 Cursor 减少千篇一律的 AI 网页设计。

让 AI 写网页并不难，难的是避免所有页面都长成同一种“紫色渐变、三张卡片、大圆角”的模板。Hallmark 是一个面向 Codex、Claude Code 和 Cursor 的设计 Skill，会在生成前选择页面结构和主题，并用规则检查常见的 AI 设计套路。

项目地址：Nutlope/hallmark

快速答案

安装 Hallmark 最简单的方法是：

1

npx skills add nutlope/hallmark

安装后可以让 Agent 新建界面，也可以审计、重做现有页面，或者从截图和 URL 中提取设计语言。它不是组件库，不会替你决定业务信息架构；需求写得越具体，结果越稳定。

Hallmark 能做什么

Hallmark 提供四类常用任务：

  • 默认模式：根据需求新建 UI；
  • hallmark audit <target>：只审计现有代码并给出问题清单，不修改文件；
  • hallmark redesign <target>：保留文案、信息架构和品牌元素，重新设计页面结构；
  • hallmark study <screenshot | URL>：分析参考设计的结构、字体搭配和颜色锚点，可输出 design.md。

其中 audit 最适合已有项目。先让它找问题，再决定哪些地方需要改，可以避免 Agent 一上来重写整个页面。

在 Codex 和 Claude Code 中安装

如果不使用 npx skills add，也可以手动复制仓库中的 SKILL.md 和 references/：

  • Codex 个人级目录：~/.codex/skills/hallmark/
  • Codex 项目级目录：.codex/skills/hallmark/
  • Claude Code：~/.claude/skills/hallmark/
  • Cursor：把 SKILL.md 正文放入 .cursor/rules/hallmark.mdc

项目级安装更适合团队，因为规则可以跟随仓库版本控制。个人级安装适合多个项目共享，但更新后可能影响所有项目的输出风格。

推荐工作流

先让 Agent 读取现有设计系统，再执行审计：

1

使用 Hallmark 审计当前首页。保留品牌色、字体和现有组件，只列出最像 AI 模板的 10 个问题，不要修改文件。

确认清单后再要求小范围重做：

1

根据审计结果重做首页首屏和功能区。不要改变路由、文案和组件 API，完成后检查移动端与键盘导航。

四种模式应该怎样选

新项目先用默认 Build

新建落地页时，不要只说“做一个高级页面”。至少提供产品对象、页面目标、必须出现的内容、品牌限制和技术栈：

1
2
3
4
5

使用 Hallmark 为一个本地 AI API 网关制作产品首页。
目标用户是同时使用 OpenAI、Claude 和 Gemini API 的开发者。
首屏必须包含一句价值说明、安装命令和 GitHub 链接。
技术栈是 React + Tailwind，不新增 UI 组件库。
不要使用紫色渐变、悬浮玻璃卡片和无意义数据指标。

Hallmark 会选择宏观结构和主题，但不会自动补齐真实产品信息。没有给价格、截图和客户案例时，应使用明确占位说明，不要让 Agent 编造公司数字。

旧项目先用 Audit

audit 适合已经上线的页面。它只返回问题清单，不直接改文件，便于区分“审美建议”和“必须修复的问题”。审计时可要求按优先级输出：

1
2
3
4

hallmark audit src/pages/Home.tsx

按阻碍理解、模板感、可访问性、响应式问题四组输出。
每条标明文件位置和修改风险，不要编辑代码。

拿到清单后，优先处理重复卡片、信息层级不清和移动端溢出，不必为了追求差异化把所有组件全部推翻。

Redesign 适合结构已经失效的页面

当页面文案还能用，但布局经过多次叠加已经难以维护时，再用 redesign。任务中明确哪些内容必须保留：

  • 标题与产品名称；
  • SEO 需要的正文；
  • 表单字段和提交逻辑；
  • 埋点属性与测试选择器；
  • 已有品牌色、Logo 和字体授权。

若这些约束没有写清楚，Agent 可能在“重新设计”时删除对业务重要但视觉上不起眼的元素。

Study 用来提取语言，不是照抄

给 study 一个截图或 URL 后，重点查看它输出的宏观结构、字体组合、颜色锚点与留白规律。推荐让它生成 design.md，再交给其他 Agent 使用：

1
2
3
4
5

hallmark study https://example.com

分析页面的结构、字体层级、颜色锚点和密度。
不要复制文案、插图、Logo、独特图形或付费模板。
输出可以交给其他编程 Agent 使用的 design.md。

如何接入现有设计系统

Hallmark 不应覆盖项目已有的 Token。运行前让 Agent 读取以下文件中实际存在的部分：

  • tailwind.config.* 或 CSS 变量；
  • Storybook 与组件文档；
  • src/components/ui/；
  • 字体加载和图标配置；
  • ESLint、Stylelint 与可访问性测试；
  • 截图回归测试。

随后声明优先级：业务约束和现有组件 API 最高，品牌 Token 其次，Hallmark 的主题建议最后。这样可以保留差异化结构，又不产生一套与项目冲突的新颜色和间距体系。

生成后怎样验收

第一轮：代码范围

先查看 Git 变更，确认 Agent 没有顺手升级依赖、替换路由或删除测试。Hallmark 是设计 Skill，不应默认获得重构业务代码的权限。

第二轮：响应式

至少检查 360px 手机、768px 平板和常用桌面宽度。重点关注超长标题、按钮换行、横向滚动、固定高度和绝对定位。

第三轮：可访问性

检查键盘焦点、表单标签、颜色对比度、语义标题、图片替代文本和 prefers-reduced-motion。视觉上“不像 AI”不等于可访问性自动合格。

第四轮：真实内容

用最长产品名、真实错误消息、空数据、加载状态和多语言文本替换演示内容。很多页面只在短英文占位符下显得整齐。

Hallmark 与其他前端 Skill 的区别

工具类型 主要解决问题 适合阶段
Hallmark 页面结构雷同、AI 模板感 设计与重设计
UI Skills 按任务加载具体 UI 规则 实现与审查
组件库 统一交互和组件 API 长期工程维护
截图回归 发现视觉变化 测试与发布前

它们可以组合，但不要让多个 Skill 在同一步对整体风格拥有同等优先级。一个负责结构，一个负责实现规则，组件库负责最终落地，冲突会少很多。

排错清单

现象 可能原因 处理方法
Agent 没有调用 Hallmark Skill 未被发现或未明确指定 检查安装目录，在任务中点名使用
输出仍像默认模板 Brief 太空泛 补充用户、内容、品牌和禁用模式
改动范围过大 直接使用 redesign 且未写边界 先 audit，再限制文件和保留项
新颜色与项目冲突 没有读取 Token 明确现有设计系统优先
页面好看但不可用 缺少功能验收 检查表单、路由、状态和可访问性

常见问题

Hallmark 会自动复制参考网站吗？

不会。study 的目标是提取宏观结构、字体搭配和色彩逻辑，并明确拒绝像素级克隆和付费模板复制。

为什么安装后看不出变化？

先确认当前 Agent 能发现该 Skill，再在任务中明确写出“使用 Hallmark”。如果项目已有强约束设计系统，Hallmark 应服从现有组件和品牌规范。

能代替人工设计验收吗？

不能。它能减少常见模板感，但内容层级、可访问性、真实设备显示和业务转化仍需要人工检查。

更新 Hallmark 会改变旧页面吗？

不会自动修改已经生成的代码，但再次运行同一任务时，新规则可能给出不同结果。需要可复现输出的团队应锁定安装版本，并把最终设计规范保存在仓库中。

Hallmark 适合后台管理系统吗？

可以，但后台系统通常更重视信息密度、表格操作和一致性，不应为了视觉差异牺牲效率。可以只用 audit 找模板化问题，不必应用高表现力主题。

团队使用时怎样保持可复现

Hallmark 会更新主题、规则和反模板检查，同一个 Brief 在不同版本下可能产生不同结构。团队需要把“生成工具”和“最终规范”分开管理：

  1. 在任务记录中写明 Hallmark 版本；
  2. 把采用的颜色、字体、网格和组件选择保存到项目文档；
  3. 生成后由人工确认，再让视觉回归测试保护结果；
  4. 更新 Hallmark 时先运行 audit，不要自动重做已上线页面；
  5. 对重要页面保存桌面和移动端参考截图。

这样即使 Skill 更新，已上线页面也不会在下一次小改动时突然换一套设计语言。

一个完整的首页验收示例

假设 Hallmark 重做了 SaaS 首页，至少检查以下内容：

  • 首屏是否在不滚动时说明产品、用户和下一步动作；
  • 安装命令能否直接复制，是否是真实命令；
  • CTA 是否链接到正确路由；
  • 导航在手机上能打开、关闭并保持焦点；
  • 图片加载失败时页面仍能理解；
  • FAQ 能否被键盘操作；
  • 页面没有因字体加载产生明显布局跳动；
  • 关闭 JavaScript 后关键 SEO 文本是否仍存在；
  • Lighthouse 或现有性能测试没有明显倒退；
  • 埋点和测试选择器没有因结构变化丢失。

若设计效果和这些工程要求冲突，应优先修复功能与可访问性，再讨论视觉取舍。

什么时候不值得使用 Hallmark

纯内部 CRUD 页面、已有成熟设计系统且只改一个字段、需要严格像素复刻的项目，未必需要 Hallmark。此时直接使用现有组件和设计稿更稳定。Hallmark 更适合缺少明确页面结构、需要摆脱通用 AI 模板，或希望系统审计现有视觉问题的任务。

总结

Hallmark 适合已经在用 Codex、Claude Code 或 Cursor 生成前端，但对“所有网页看起来都一样”不满意的团队。最佳用法不是直接全站重做，而是先 audit、再选择局部 redesign，最后用真实内容和移动端完成验收。