UI Forge

要解决什么问题

让大模型做 UI 时，常见失控是：把未确认的候选当成定稿、跳过需求直接出稿、视觉没过关就交付，或一轮对话里常驻拦截所有非设计任务。UI Forge 定位为 UI 设计 controller：与 polanyi-design 分层——后者负责高级审美与 gestalt 判断，本技能负责把判断放进固定阶段与提问预算（L1–L4），产出可验收的页面方案、组件边界、REQUIREMENTS.md 以及 design-output/ 下的 HTML/CSS/SVG。

如何工作

• 入口与模式：uif- 标准路由；uif-fast 做小调整；uif-a 仅自动补齐低风险视觉默认值；uif-iter 做已完成项目的版本化迭代。
• 硬门禁流程：读取上下文 → 路由模式/预算 → 需求收口 → Design Task Brief 用户确认 → UI 设计 → 视觉审查（6 维评分）→ 用户确认 → 交付 → 验证 → 结束；未完成完整性检查清单不得宣称完成。
• 交付结构：用户可见物在 design-output/（含 index.html 画廊、tokens.json、icons/、DESIGN-GUIDE.md、REQUIREMENTS.md）；项目级规则在 .ui-forge/projects/.design_card.yaml；过程记忆在 .design-doc/，不当作对外展示。
• 降级路径：图片不可用时走 SVG Visual Fallback（高质感 SVG，禁止廉价灰块占位）；无法读截图时走 Visual Understanding Fallback，视觉结论须标注证据来源。
• 多页面（3+）：自动锁定 tokens、抽取组件库、输出 routing.json 与 consistency-report.md。

适用边界

• 一轮任务完成即退出；只有用户说「继续这个页面/设计系统」才恢复 session，不常驻、不拦截非设计任务。
• 存在两种及以上合理结构方向且影响布局/流程时，必须停下确认；L3/L4 不得跨页面或跨里程碑偷跑。
• 需求阶段不调用 polanyi；有草案后再做 gestalt 诊断，交付时把结论翻译成 tokens 与布局约束。