把组件禁用条件写进 Skill：让 Agent 先解释违反了哪条设计规则

原创于 2026-10-29 22:24:28 发布 · 22 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

界面动效与视觉编程

本文提出将组件禁用等状态规则编码为可执行、可解释的Agent Skill，强调在违反设计规则时优先输出违规编号、定位、原因及人工可选方案，而非自动修正。Skill基于YAML frontmatter定义，聚焦规则解释能力，不授权自动修改；验证覆盖组件状态、Design Token依据与规则语境，明确区分“未发现”与“已通过”，并要求保留业务动因（如加载态与禁用态差异）。当前为教学级实现，尚未部署于真实Agent环境。

封面：组件规则书与带解释的禁用按钮

“这个按钮为什么不能用红色？”如果 Agent 只把它改成蓝色，设计规则仍然没有被理解。下次生成加载态，它可能再次放入同样的冲突。比自动修正更有用的是：指出违反哪条规则，展示原因，再给用户一个可选方案。

10 月 22 日 Anthropic 宣布将 Agent Skills 捐赠给 AAIF。治理变化是背景，组件规则本身仍要写清。当前规范的最小 Skill 是带有 YAML frontmatter 的 SKILL.md；文件格式不会自动赋予规则执行能力，也不会证明某个平台一定遵守它。

把规则写成能解释的工作步骤

下面是一份教学 Skill 内容，可保存为 review-component-rules/SKILL.md。它要求先读组件状态与 Token 依据，再输出规则编号、定位、解释和建议。它没有授权安装工具、联网改设计文件或自动提交修复。

---
name: review-component-rules
description: 审阅组件的禁用、加载、错误状态与设计 Token 使用，输出规则解释和人工确认选项。
---
读取组件描述与项目规则表，缺少依据时标记 unknown。
R1：加载期间不提供重复提交入口，保留可理解的加载说明。
R2：禁用必须有明确原因；不能仅降低透明度表达。
R3：错误信息说明问题与可行动作，不把“出现错误态”直接判为违规。
R4：颜色使用项目允许的语义 Token；例外须单列理由。
每条发现输出：规则 ID、组件 ID、状态、依据、解释、替代选项。
先展示建议；用户确认前不修改组件。

import assert from 'node:assert/strict';
function review(c) {
  const issues=[];
  const add=(rule,reason,alternative)=>issues.push({rule,component:c.id,reason,alternative});
  if(c.loading && c.repeatActionEnabled)
    add('R1','加载中仍可重复提交','保留状态说明并关闭重复提交入口');
  if(c.disabled && !c.disabledReason?.trim())
    add('R2','缺少禁用原因','补充可见原因及恢复条件');
  if(c.colorToken && !['action.primary','action.danger'].includes(c.colorToken))
    add('R4','Token 不在此教学规则表中','选择允许项或提交例外说明');
  return issues;
}
const issues=review({id:'save',loading:true,repeatActionEnabled:true,
  disabled:true,disabledReason:'',colorToken:'pink.500'});
assert.deepEqual(issues.map(x=>x.rule),['R1','R2','R4']);
assert.equal(review({id:'save',error:'保存失败，请重试',
  loading:false,disabled:false,colorToken:'action.primary'}).length,0);
console.log('rules explain violations; error state itself is not a violation');