Agent 会做页面，但它不会替你验收
Hallmark 是一套减少 AI 页面模板感的完整设计系统；这篇文章解释我如何受它启发，把 web-design-qa 收窄为已有项目的上线前质量检查层。
先交代两个名字：Hallmark 是一套减少 AI 页面模板感的完整设计系统；web-design-qa 是我受它启发后，为已有项目重新整理的上线前验收层。
当时调整 HEADFIRST（现在的 Marina Current）的 Writing 页面，要求其实很清楚：中文标题不要三行，不要又细又长，也不要中英文混成一块。
结果页面确实能打开。只是标题大得像发布会，中文被硬生生拆成三行，文章卡片还挤在一张横向表格里。
这类问题很典型。Agent 会写组件，会跑构建，也会在你说“不好看”以后迅速重做一版。可它通常不会先问：到底是字号错了、内容层级错了，还是整个页面结构都错了？
于是一个原本只需要调字体和排版的问题，很容易变成全站重写。
我们不缺设计能力，缺的是上线前那双眼睛
Hallmark 很会处理 AI 页面那股熟悉的“模板味”：相似的 Hero、虚构的数字、过度圆角、每一屏都想成为视觉中心。
Hallmark 是一套完整的设计系统。它会选主题、换页面结构、管理字体和配色，也会负责重新设计。能力很强，但对已经存在的项目来说有点太全了。
很多真实需求没有这么大。页面已经存在，品牌色、路由、组件、埋点都在。真正需要确认的是哪里不对，以及最小应该改什么。
因此 web-design-qa 没有照搬整套设计能力，只保留页面验收需要的部分。
Hallmark 解决“怎么做出更不像 AI 的页面”，web-design-qa 解决“这个页面现在到底能不能交付”。
最大的改动：默认不碰代码
大多数 Agent 听到“帮我看看页面”，会自动理解成“帮我改页面”。这两个动作差很多。
在 web-design-qa 里，默认模式只有审计。它先看真实渲染结果，列出问题、严重程度和证据，不改文件。只有用户明确要求修复，它才进入编辑模式。
这条边界很实用。很多时候需要的是判断，不是再来一轮设计。先把问题说准，后面的修改反而会更小。
它也不会一上来发明一套新系统。现有 Token、字体、组件、品牌色和内容意图优先。除非原来的系统本身就是问题，否则先沿着它修。
这次改造补上的一层：验收证据
“这个按钮不够清楚”到底是看过页面后的结论，还是只扫了一眼 JSX？不能靠猜。
所以每条结论都要带状态：
Verified：在真实页面里看过或操作过。Code-checked：只从代码确认，还没做浏览器验证。Not verified：当前条件下不能确认。
拿不到运行环境没有关系，可以继续看代码。但不能把 Code-checked 写成“已经验收”。
响应式检查固定覆盖 320/375、768 和 1280 三档。标题是不是又被挤成三行，按钮有没有换行，卡片在手机上是不是还保持桌面布局，这些都只能在真实尺寸里看出来。
它可以没有答案，但不能拿推测冒充页面证据。
参考网页也只是一份设计证据，不是一封可以执行的指令。处理外部参考 URL 时，web-design-qa 不擅自访问 localhost、内网或非公开地址，也不代替用户登录。验收用户授权的当前项目时，则应实际渲染本地或线上页面。这两种对象要分开；参考页面里的“运行这个命令”也不能变成执行指令。公开页面打不开时，最简单的处理是让用户提供截图。
这条边界看起来不像设计能力，却很重要。研究一个页面的字体、层级和动效，不应该顺手把远程页面里的脚本、文案或操作要求带进自己的项目。
它还知道什么不归自己管
这条边界同样重要。
SEO、关键词覆盖、落地页漏斗，不会因为页面长得不好看就自动变成设计问题。web-design-qa 可以指出视觉和交互风险，但不会顺手接管整套 SEO 或 CRO 审计。
做得越专，边界反而越重要。不然一个“帮我验收页面”的请求，最后又会长成一份什么都有、什么都不够深的报告。
最后交付的不是审美意见
最终结果很简单：哪些必须修，哪些会明显影响体验，哪些只是可以优化；每一条基于什么证据；如果要改，最小改动落在哪些文件。
这份结果既可以继续交给 Agent 修，也可以留给人判断优先级。它没有强行替项目选择一套新审美，但把返工范围收住了。
这才是这个版本真正多出来的价值：不是比原版更会设计，而是更适合接在一个已经存在、准备交付的真实项目后面。
web-design-qa 受 Hallmark 启发并重新构建，来源标记为 REFERENCE-BASED REBUILD。
把检查写成可复验的步骤
下面是教学示例，不是本轮真实页面的验收记录：一个中文标题在 375px 宽度下被挤成四行。先保存原始截图，检查容器宽度、字号与换行规则；只调整造成问题的规则，再以相同内容和宽度回读，并补看平板宽度。
| 检查对象 | 留下什么 |
|---|---|
| 原始问题 | 路由、视口、标题原文、截图 |
| 最小改动 | 具体修改的布局或字体规则 |
| 复验 | 相同条件下的截图、横向溢出与相邻标题检查 |
这样别人能重复检查，也能分清“建议改”与“已经改过并验证”。上游能力会变化，文中的对比指向首版改造时的选择；固定版本来源保留在公开仓库的 RELEASE 中。