Sitegeist：检测 coding agents 的视觉设计趋同

Sitegeist：检测 coding agents 的视觉设计趋同

为什么重要

Sitegeist 提出的问题很具体：当多个 coding agent 接收同一批中性网站 brief 时，它们会不会反复生成相同的视觉套路？这对 Agent-Benchmarks 很有价值，因为多数 coding benchmark 只看功能是否通过，很少评估 artifact 的风格多样性、设计惯性和生成边界。对用户的 AI 产品/工程实践来说，coding agent 如果在 UI/产品原型上高度趋同，就会让“自动生成很多方案”看起来丰富、实际却只是模板化重复。

机制 / 一阶原理

Sitegeist 由 100 个模型中性的 website briefs 与 400 个完整静态网站组成，覆盖四组模型集合。每次生成在独立的一站式文件系统里运行，worker 只能看到 work order、私有 brief 和 artifact contract，不能看到 gallery、Git 历史、其他模型结果、自己此前结果、截图或重复报告。提交物必须包含 authored source、无依赖静态 build 和 4:3 gallery poster；评估器拒绝远程资产、运行时网络依赖、符号链接、畸形 artifact、console errors 和移动端横向溢出。

一阶原理是：要测“模型/agent 的设计本能是否趋同”，必须先控制信息泄漏和共享上下文。如果 agent 看过其他结果，重复可能来自污染；如果 artifact contract 不严格，重复检测又会被无效 build、远程资源和布局错误噪声污染。

与现有 wiki 的关系

它补充 SWE-Touch：用户中途干预与共享工作区漂移 benchmark 的真实协作维度，但关注点从 mid-run drift 转到 artifact diversity。它也连接 Context-Engineering：如果 prompt、brief、gallery、history 这些上下文边界不被隔离，benchmark 不能解释“趋同”到底来自模型先验、上下文污染，还是 harness 诱导。

对 Hermes / llm-wiki 的可执行启发

• 对 UI/产品原型任务，不能只验收“能跑”和“无 console error”；还应记录是否重复使用默认 hero/card/gradient/SaaS 模板。
• llm-wiki 的 radar 可以把“artifact diversity / convergence / style collapse”加入 benchmark 关注名单，避免只跟踪 SWE-bench 式功能修复。
• Hermes 若要生成多个设计方案，应使用隔离上下文、不同 brief seed、显式反重复 rubric，而不是在同一长上下文里连续要求“再给一个”。

失败模式 / 边界条件

Sitegeist 不声称给出主观美学排行榜；它更像可审计 artifact corpus。视觉重复的判定仍可能依赖人工或后续视觉/结构分析；网站 brief 的分布也会影响结论。如果 brief 本身集中在同类营销页，趋同并不完全等于模型退化。因此它应被视为 artifact-behavior benchmark，而不是通用设计能力排名。

深度判断

评分：relevance 4/5，novelty 5/5，durability 4/5，actionability 4/5，source-quality 3/5，depth-potential 4/5。值得晋升，因为它把 coding-agent 评测扩展到视觉设计趋同与 artifact 边界控制；但目前主要依据 README 与仓库说明，confidence 保持 medium。

写入记录

• 2026-08-06 09:00 CST：新增 Sitegeist 来源页，聚焦视觉设计趋同、隔离生成边界和 UI artifact benchmark。