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