【免费下载链接】openpencilThe worlds first open-source AI-native vector design tool and the first to feature concurrent Agent Teams. Design-as-Code. Turn prompts into UI directly on the live canvas. A modern alternative to Pencil.项目地址https://gitcode.com/gh_mirrors/op/openpencil点击查看免费下载导读本文围绕 OpenPencil AI 技能引擎中的vision-feedback技能crates/op-ai-skills/skills/phases/validation/vision-feedback.md展开它是 validation 阶段唯一的核心技能负责驱动截图 节点树交叉比对的 AI 设计 QA 循环。读完本文你将完整掌握vision-feedback 的 frontmatter 契约与触发机制、12 类视觉缺陷的判别标准、可修复属性的白名单与取值约束、结构级修复addChild/removeNode的正确姿势以及它在 orchestrator 后生成校验循环中如何被解析、防护与落地执行。一、什么是 vision-feedback一个设计 QA 校验官角色在 OpenPencil 的 AI 技能体系中技能skill是一段带 frontmatter 元数据、可在特定阶段注入 LLM 提示词的 Markdown 指令。vision-feedback位于 skills/phases/validation/ 目录下是 validation校验阶段的核心技能。它的任务定义非常明确你是一名设计 QA 校验官。你将收到一张 UI 设计截图以及它的节点树结构node tree structure。请将你在截图中看到的视觉问题与树中的节点 ID 交叉核对。也就是说vision-feedback 把 LLM 定位成看得见截图的 QA 工程师截图是现实节点树是代码两者交叉引用后输出结构化的修复指令再由引擎自动执行。这正是 OpenPencilDesign-as-Code理念在质量闭环上的体现——AI 不只负责生成设计还要负责自检、自修。该技能在整个仓库中的调用链路非常清晰技能解析与装载vision-feedback.md的 frontmatter 由 frontmatter.rs 解析正文由 loader.rs 在编译期通过include_dir!嵌入 crate见 lib.rs 中的pub static SKILLS运行时零文件 IOwasm32 同样可用按阶段解析resolve_skills(Phase::Validation, ...)经阶段过滤 → 意图匹配 → 预算裁剪后输出技能集见 resolve.rs拼装 system promptvalidation_providers.rs 中的validation_system_prompt()把 validation 阶段解析出的技能正文拼成视觉 LLM 的 system prompt进入校验循环validation.rs 的run_post_generation_validation执行最多 3 轮的截图 → 校验 → 应用修复循环。1.1 frontmatter 契约base 类技能 3000 token 预算vision-feedback.md的 YAML 头frontmatter如下--- name: vision-feedback description: Vision-based design QA validation with screenshot analysis phase: [validation] trigger: null priority: 0 budget: 3000 category: base ---各字段含义与 frontmatter.rs 的解析逻辑一一对应字段值解析行为源码依据namevision-feedback技能唯一标识get_skill_by_name以此查找重复名称会被 loader.rs 的测试拦截descriptionVision-based design QA validation...技能用途描述phase[validation]技能挂载在 validation 阶段仅在该阶段解析时被选中triggernull解析为SkillTrigger::Always即无条件启用对应 types.rs 中trigger: null→Always的语义priority0最低优先级数字filter_by_intent按 priority 升序排序见 resolver.rsbudget3000单技能 token 上限trim_by_budget_pinned第一步对超出部分截断见 budget.rscategorybaseBase 类技能永远保留预算裁剪时不受阶段总预算挤压见 budget.rs 的Step 2这里有两个值得注意的工程细节budget: 3000恰好等于 validation 阶段的默认总预算。在 types.rs 中Phase::Validation.default_budget()返回3000与DEFAULT_BUDGETS常量表一致。作为 Base 技能vision-feedback 被强制保留的同时仍计入预算统计因此设计上必须把自身内容控制在 3000 token 以内——budget.rs 中专门有一条回归测试no_skill_silently_exceeds_its_own_budget防止技能正文膨胀后尾部被静默截断validation 阶段不注入设计记忆。resolve.rs 中if phase ! Phase::Validation { memory.document_context ... }即校验阶段刻意不携带上下文记忆保证校验视角中立客观。二、12 类视觉缺陷判别清单从截图到节点 ID 的映射vision-feedback 的核心检查清单包含 12 类问题。这是技能正文中信息密度最高的部分务必逐条理解因为每一条都直接决定了修复指令的形态#缺陷类别判别要点修复方向1宽度不一致WIDTH INCONSISTENCY互为兄弟节点的表单输入、按钮、非滚动卡片宽度不同统一为widthfill_container匹配父容器刻意横向滚动容器内的卡片豁免保持固定宽度2元素过窄ELEMENT TOO NARROW按钮或输入框远窄于父容器widthfill_container3间距SPACING内边距不均、元素贴近边缘、兄弟间隙不一致调整 padding / gap4溢出OVERFLOW文本或元素被视觉裁剪或超出容器结合 textGrowth / 容器尺寸修复5对齐ALIGNMENT应对齐的元素未对齐如表单字段未左对齐调整 alignItems / textAlign6文本居中TEXT CENTERING应在容器内水平居中的文本偏左/偏右标题、按钮、分割线文案 or continue with、页脚文本常见父容器alignItemscenter或文本节点widthfill_container7图标缺失MISSING ICONSpath 节点渲染为空白/不可见矩形重建/修复 path 节点8颜色问题COLOR ISSUES文本与背景对比度差、背景色错误、同类元素颜色不一致fillColor/strokeColor9排版TYPOGRAPHY同类元素字号不一致、标题与正文字重错误fontSize/fontWeight10边框缺失MISSING BORDERS输入框/卡片/容器缺少可见边框、融入父背景strokeColorstrokeWidth图表柱、柱轨道等数据标记豁免11结构不一致STRUCTURAL INCONSISTENCY兄弟元素模式不同一个输入框有前置图标而另一个没有、列表项缺少应有子元素用 addChild 补齐缺失子节点12元素缺失MISSING ELEMENTS提供了参考设计reference design时参考中可见的重要 UI 元素在当前设计中缺失以 addChild 补入合适父节点下2.1 参考设计对比第 12 类的源码印证第 12 类问题在引擎层有直接对应run_post_generation_validation中的build_vision_requestvalidation.rs会在传入reference_screenshot时追加参考对比指令A REFERENCE DESIGN screenshot was also provided. Compare the current design against the reference and fix any significant deviations in layout, spacing, proportions, or missing elements. ... If elements visible in the reference are missing in the current design, use structuralFixes with addChild to add them.同时参考截图存在时单轮超时翻倍VALIDATION_TIMEOUT_MS * 2因为对比任务更重。从源码注释看reference_screenshot参数当前在 C2 主路径恒为None参考图由 D1 的 host 侧接线透传——这属于仓库中从代码结构可推断的后续能力当前默认路径不启用。三、图片审查边界IMAGE REVIEW SCOPE只查渲染完整性不评内容vision-feedback 对截图里的图片划定了严格的审查边界这是它区别于普通审美评委的关键设计也是避免 AI 陷入主观偏好争论的护栏允许检查渲染完整性 only预期的图片槽位image slot恰好渲染出一张图片图片具有有效边界bounds、裁剪/适配crop/fit、裁剪clipping、圆角radius与叠放顺序overlay order没有破损/空白占位符。明确禁止检查图片主体相关性、美学、感知质量、分辨率、色调、图库素材选择、搜索词质量、生成质量不得因换一张图可能更好看而请求替换/移除/降级图片也不得修改qualityScore。一张正确显示的图片无论内容如何都应通过校验。—— 这是该技能正文的核心红线之一。这条边界不止写在技能里还以权威系统提示的形式固化在 lib.rs 的IMAGE_SELF_CHECK_SCOPE常量中并通过append_image_self_check_scope追加到任意设计 Agent 提示词末尾去重后置。同时在 validation_providers.rs 的内置兜底 rubric 与build_vision_request的用户消息模板中反复出现并有专门的测试validation_prompt_limits_image_review_to_rendering_integrity锁定该语义。四、输出契约严格 JSON 四字段结构技能要求模型只输出一个 JSON 对象不得附带解释不得使用 markdown 代码围栏{qualityScore:8,issues:[description1,description2],fixes:[{nodeId:actual-node-id,property:width,value:fill_container}],structuralFixes:[]}四个字段的职责字段类型说明qualityScore1–10 整数整体设计质量分issuesstring[]自然语言描述的视觉问题fixes对象数组对既有节点的属性修复structuralFixes对象数组结构级修复addChild / removeNode慎用4.1 qualityScore 评分标尺9–10生产就绪production-ready打磨完成的设计7–8良好设计存在轻微问题5–6可接受但需要改进1–4存在重大问题。引擎端对分值的处理非常严谨validation.rs 的try_parse_jsonqualityScore接受数字或数字字符串取整后钳制到 [1, 10]解析失败/未设置时归 0。0 分且 issues 为空 解析失败循环直接中断。4.2 无问题时返回满分通过模板If the design looks correct, return: {qualityScore:9,issues:[],fixes:[],structuralFixes:[]}注意无问题的标准分值是9而非 10——10 分保留给确实无可挑剔的场景默认通过模板定在 9与引擎VALIDATION_QUALITY_THRESHOLD 8的提前退出阈值配合避免无谓的多轮调用。五、属性修复白名单17 个可修复属性与取值约束vision-feedback 列出了允许修改既有节点的全部属性。这些属性不是随意的——它们与引擎端的SAFE_FIX_PROPERTIES白名单逐字对应validation_fixes.rs任何不在白名单内的属性都会被parse_validation_response过滤丢弃绝无例外属性允许取值引擎端取值校验ValueKindwidth数字 |fill_container|fit_contentSizing有限数字或两个关键词之一height数字 |fill_container|fit_contentSizingpadding数字 |[top,right,bottom,left]四元数组NumberOrArraygap数字NumberfontSize数字NumberfontWeight数字300–900FontWeight白名单为 {100,200,…,900} 九档letterSpacing数字NumberlineHeight数字NumbercornerRadius数字Numberopacity数字NumberfillColor#hex节点背景/填充色Color#RGB/#RGBA/#RRGGBB/#RRGGBBAAstrokeColor#hex边框/描边色ColorstrokeWidth数字NumbertextAlignleft|center|rightEnumTextAligntextGrowthauto|fixed-width|fixed-width-heightfixed-width 换行且高度自适应EnumTextGrowthalignItemsstart|center|endEnumAlignjustifyContentstart|center|end|space_betweenEnumJustify引擎白名单还多一个space_around5.1 取值校验的源码实现引擎端的校验逻辑在 validation_fixes.rs 的is_valid_fix_value中逐属性执行fontWeight必须是 {100,200,300,400,500,600,700,800,900} 之一技能文档中标注 300–900 是常用区间引擎白名单则覆盖全档位颜色必须匹配/^#(?:[0-9a-fA-F]{3,4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$/尺寸关键词仅接受fill_container与fit_content两个字符串。也就是说模型输出的任何属性修复都要先过白名单 取值校验这两道闸门才可能被应用。这从机制上保证了 AI 不能乱改节点。5.2 属性修复如何落地为编辑命令通过校验的修复在 validation_fixes_apply.rs 中被翻译成具体的EditorCommandfillColor→SetNodeFillHexstrokeColor→SetNodeStrokeHexstrokeWidth→SetNodeStrokeWidthcornerRadius→SetNodeCornerRadiusfontSize→SetNodeFontSizefontWeight→SetNodeFontWeightwidth/height为数字 →UpdateNode取整为像素为关键词 →SetNodeLayoutPropLayoutPropValue::Keywordpadding→SetNodeLayoutPropNumber 或 NumberArray 四元组alignItems/justifyContent/textAlign/textGrowth→SetNodeLayoutPropKeywordgap/letterSpacing/lineHeight→SetNodeLayoutPropNumberopacity→SetNodeLayoutPropNumber。六、文本裁剪检测TEXT CLIPPING DETECTION一套专门的诊断规则文本是 UI 视觉问题的高发区vision-feedback 为此单列了一套诊断逻辑文本节点几乎永远不该有显式像素高度。若一个文本节点带显式高度如h22、h30且内容出现视觉裁剪或与兄弟节点重叠修复方式是设置textGrowthfixed-width且heightfit_content让引擎自动计算正确高度节点树会显示textGrowth与lineHeight值用它们诊断文本问题而不是凭感觉猜。这正是 validation_dump.rs 的build_node_tree_dump提供的——它把每个节点的id、type、name、w、h、layout、clip、gap、pad、justify、align、cr、opacity、fill、stroke/strokeW、fontSize、fontWeight、lineHeight、textGrowth、textAlign、text前 30 字符逐行 dump 成缩进树作为用户消息注入按钮底部文字被裁剪优先检查父 frame 的 padding 是否为文本高度fontSize × lineHeight留足空间修父容器的 padding/height而不是改文本的 fontSize。七、两道护栏横向滚动容器与图表数据标记7.1 刻意横向滚动器INTENTIONAL HORIZONTAL SCROLLERSlayouthorizontal cliptrue的节点是刻意横向滚动容器右边缘露出一半的下一张卡片是滚动暗示scroll affordance不是溢出缺陷。规则如下保留卡片的固定宽度与作者设定的边缘处理方式不得修改滚动器、其后代或祖先的width、height、padding、gap、alignItems、justifyContent来强行让所有条目在截图中放得下不得仅为了看起来内缩而加右侧 padding——视口与屏幕边缘齐平、仅保留左侧 padding 是合法设计。引擎侧对此有双保险should_skip_scroller_layout_fix与is_protected_scroller_regionvalidation_scroll_guard.rs会在应用阶段再次拦截——凡是落在刻意横向滚动区域内的布局类修复width/height/padding/gap/alignItems/justifyContent以及 addChild/removeNode 结构修复一律跳过并记录原因。技能文档负责说服模型scroller guard 负责物理拦截两层防护保证作者的手势不被 AI 误改。7.2 图表数据标记CHART MARKS图表柱、柱轨道、列等数据标记不是卡片表面当它们刻意与图表背景同色时不要加边框或描边带圆角彩色填充的弱化轨道muted track是正常的图表处理即使其填充与周围绘图区融合也应保留。引擎侧同样有validation_chart_guard.rs的should_skip_chart_stroke_fix做应用期拦截validation_fixes_apply.rs 中调用。两个 guard 均有对应的独立测试文件validation_fixes_scroller_guard_tests.rs、validation_fixes_chart_guard_tests.rs。八、结构级修复structuralFixesaddChild 与 removeNode 的正确用法结构修复用于增删节点技能明确标注慎用仅用于清晰的结构问题。8.1 addChild添加子节点模板{action:addChild,parentId:real-parent-id,index:0,node:{type:path,name:KeyIcon,width:18,height:18}} {action:addChild,parentId:real-parent-id,node:{type:text,name:Label,content:text,fontSize:14,fillColor:#hex}} {action:addChild,parentId:real-parent-id,node:{type:frame,name:Divider,width:fill_container,height:1,fillColor:#hex}}参数规则type仅限frame | text | path | rectangle | ellipse与引擎 validation_fixes.rs 的VALID_NODE_TYPES完全一致path/图标节点name填图标名如KeyIcon、LockIcon、EyeIcon系统自动解析图标路径Rust 端当前使用 stub icon resolver见 validation_fixes_b3.rs 的说明未来由IconResolvertrait 补齐index可选默认 0即第一个子节点控制插入位置width、height、fillColor按需指定其余属性可选引擎校验parentId必须是非空字符串且真实存在node.type必须合法构建节点由 validation_fixes_b3.rs 的build_node_from_spec完成。8.2 removeNode移除节点{action:removeNode,nodeId:real-node-id}引擎在应用时还有两条额外保护validation_fixes_apply.rs目标节点位于刻意横向滚动区域 → 拒绝移除目标节点是预注入的 chrome如 iPhone 状态栏rolestatus-bar→永不删除。8.3 两条 CRITICAL 铁律addChild 必须附带父节点配套属性修复若父节点justifyContentspace_between新增子节点可能破坏间距此时要同时给出属性修复改justifyContent和/或补gap并且对照同模式兄弟节点的布局属性来匹配父节点。引擎侧对应auto_fix_parent_layout_after_add_childvalidation_fixes_apply.rs 末尾它会在插入后快照父节点布局并自动校正严禁把带自动布局auto-layout的 frame 从fit_content改成固定像素宽高——这会产生空白。若容器看起来不可见应修 opacity、填充色或边框而不是改高度。引擎侧在 validation_fixes_apply.rs 中有对应的fit_content → 固定像素守卫当目标节点是fit_content且有 layout 且子节点数 1 时直接拒绝该数值型宽高修复。九、使用总则最小干预、真实 ID、聚焦高影响力问题技能正文以IMPORTANT收尾凝练了使用准则使用节点树中真实的节点 ID绝不猜测或编造 ID引擎端parse_validation_response也会丢弃空 nodeId 的修复表单一致性问题要修齐所有不一致的兄弟节点而不是只修一个修复保持最小化——只修明确的视觉 bug不修风格偏好优先处理影响力最大的问题structuralFixes 只添加一致性/完整性明确需要的元素除非参考设计中有装饰元素否则不加装饰。十、从技能到管线vision-feedback 在 OpenPencil 中的完整落地10.1 校验循环的四段流水线run_post_generation_validationvalidation.rs把 vision-feedback 的技能正文当作视觉 LLM 的 system prompt驱动如下循环预校验纯代码、无 LLMpre_validator.run_pre_validation_fixes先跑启发式规则geometry/text 修复不消耗视觉 API30 节点门槛活动页节点数 VALIDATION_NODE_COUNT_THRESHOLD(30)则跳过视觉校验省 30–90 秒与 API token最多 3 轮视觉循环MAX_VALIDATION_ROUNDS每轮截图 → dump 节点树 → 调视觉 LLM → 解析 JSON → 应用修复提前退出qualityScore VALIDATION_QUALITY_THRESHOLD(8)即达标退出连续出现过的修复会被去重同一nodeId:property出现 ≥2 次即过滤。配置常量集中定义在 validation_config.rs阈值 30、最多 3 轮、质量达标线 8、单轮超时 180 秒有参考图翻倍为 360 秒。10.2 响应解析的容错设计视觉 LLM 的返回文本并非总是干净 JSONparse_validation_responsevalidation.rs做了三层容错先剥离tool_use.../tool_useAgent 工具块尝试直接解析清洗后的文本失败则贪婪提取首个{...}最外层花括号块再解析全部失败返回全零默认值qualityScore0循环判定为解析失败并中断。10.3 视觉 provider 的宿主接线在 host 侧validation_providers.rsvalidation_system_prompt()用resolve_skills(Phase::Validation, , ...)解析技能并拼接为 system prompt若解析为空则回退到内置的简洁 rubric同样约束 JSON 四字段输出RealScreenshotProvider::capture_root_frame通过op_pen_loader把活动页渲染成 base64 PNG渲染失败返回None循环跳过该轮而非报错ChatVisionLlmClient把截图作为 PNG 附件随文本一起发送给多模态 provider真实视觉校验由环境变量OPENPENCIL_VISION_VALIDATION1开启默认关闭。10.4 关键测试证据仓库为这条视觉校验链路提供了完整测试覆盖可直接作为行为契约阅读validation_providers.rs 内置测试验证校验 prompt 必须保留横向滚动语义、不得给图表标记加边框、图片审查限于渲染完整性validation_tests_c1.rs 覆盖单轮校验请求构建与响应解析validation_tests_c2.rs 覆盖完整多轮循环的退出条件、去重与修复应用validation_fixes_scroller_guard_tests.rs 与 validation_fixes_chart_guard_tests.rs 分别锁定两道应用期护栏budget.rs 的no_skill_silently_exceeds_its_own_budget保证vision-feedback自身内容永不超出 3000 token 预算而被静默截尾。结语vision-feedback 远不止是一份给 AI 的检查清单它是 OpenPencil 设计质量闭环的契约中枢技能文本定义看什么、修什么、怎么修引擎白名单定义哪些修复可落地scroller/chart guard 定义哪些区域不可动多轮循环与质量阈值定义何时算达标。理解这份技能文档就等于同时理解了 OpenPencil AI 设计自检系统从提示词到执行的每一道闸门。赞分享【免费下载链接】openpencilThe worlds first open-source AI-native vector design tool and the first to feature concurrent Agent Teams. Design-as-Code. Turn prompts into UI directly on the live canvas. A modern alternative to Pencil.项目地址https://gitcode.com/gh_mirrors/op/openpencil点击查看免费下载相关推荐深入理解Rizz架构为什么这个轻量级游戏框架如此强大深入理解Rizz架构为什么这个轻量级游戏框架如此强大 Rizzریز是一个极小、跨平台的C语言游戏开发框架专为追求性能和控制力的开发者设计。这款轻量级游为什么这个开源工具能让2012年后的Mac重获新生为什么这个开源工具能让2012年后的Mac重获新生 当你的MacBook Pro 2015在系统更新页面看到此更新不适用于您的Mac时那种被技术抛弃的无操作系统固件驱动开发Fantastic-admin 的 fa-feedback 技能基于反复修改检测的 AI 反馈闭环实践Fantastic admin 的 fa feedback 技能基于反复修改检测的 AI 反馈闭环实践 当 AI 助手在 Fantastic admin 框架前端AI 技能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考