AI UI 的可解释性：为什么要让生成过程透明——从黑盒到白盒的探索
一、引子：AI 为什么把按钮放在右上角而不是左上角？
这个问题没有一个 AI UI 工具能回答。它们生成了界面，但不解释"为什么"。当设计师质疑布局选择时，AI 只能说"基于训练数据的统计模式，这是最可能的排列"——这在设计评审中是不可接受的。
可解释性（Explainability）在 AI UI 生成中是缺失的一环。当 AI 的决策无法被审查时，我们对 AI 生成界面的信任是盲目的。
美院做设计评审（critique）时，每个决策都要经受追问："为什么用这个间距？""为什么标题左对齐而不是居中？""为什么用蓝色不用绿色？"如果你回答不上来，导师会让你重做。AI UI 生成也应该接受同样的审视——不是因为它不专业，而是因为设计决策的"为什么"和"是什么"同等重要。一个无法解释自身决策的 AI，就像一个说不出理由的设计师——也许结果是对的，但你无法信任他下次还能做对。
二、可解释性的三个层次
溯源
每个设计决策应该能回溯到源头——是来自设计 Token？（最可信）来自统计数据？（可信但有偏差风险）还是来自模型的"猜测"？（可信度最低，需要人工确认）
推理
AI 不仅输出"是什么"，还输出"为什么"。推理链让设计师和开发者能够判断 AI 的决策逻辑是否符合设计原则。
对比
AI 展示它考虑过但放弃的备选方案以及放弃原因。这让"AI 有没有认真思考"从黑盒变成了可审查的对话。
三个层次的可信度分级是关键设计。Token 来源的决策（如 spacing-md = 16px）可信度最高，因为它是团队共识的固化——AI 只是执行了规范。统计来源的决策（如"73% 的金融 UI 用蓝色"）可信度中等，因为统计数据可能有时效性和样本偏差。模型推理的决策（如"这个按钮应该在右上角"）可信度最低，因为它依赖于模型的内部权重——这种决策必须在 UI 上标注"需要人工确认"。
三、技术实现
/**
* 可解释的 AI UI 生成
*/
interface ExplainableDesignDecision {
element: string; // 哪个 UI 元素
property: string; // 哪个属性
value: string; // 最终值
level: 'token' | 'statistical' | 'inferred'; // 可信度级别
sources: string[]; // 决策来源
alternatives: { value: string; reasonRejected: string }[]; // 备选方案
}
class ExplainableUIGenerator {
/**
* 生成 UI + 附带可解释性元数据
*/
async generateWithExplanation(
requirement: string
): Promise<{
code: string;
explanations: ExplainableDesignDecision[];
}> {
const code = await this.generate(requirement);
const explanations = await this.extractExplanations(code);
return { code, explanations };
}
/**
* 提取设计决策的解释
*/
private async extractExplanations(
code: string
): Promise<ExplainableDesignDecision[]> {
// 对每个关键设计决策向 AI 请求解释
const decisions = this.extractDesignDecisions(code);
return Promise.all(
decisions.map(async (d) => {
const explanation = await this.llmClient.complete({
prompt: `
解释以下设计决策的理由：
元素: ${d.element}
属性: ${d.property}
当前值: ${d.value}
请提供：
1. 这个值的来源（设计 Token / 统计数据 / 模型推理）
2. 至少 2 个被放弃的备选值和放弃原因
3. 可信度等级（high/medium/low）
`,
});
return { …d, …parseExplanation(explanation) };
})
);
}
}
实现的关键是"生成后解释"模式——先让 AI 正常生成代码，再对代码中的每个关键决策做追溯。这样不会影响生成速度，解释过程可以异步进行。level 字段用于 UI 展示：Token 级别的决策显示绿色标记（可信），统计级别显示黄色（参考），推理级别显示红色（需确认）。设计师可以只审查红色标记的决策，大幅提升评审效率。
在实际使用中，可解释性元数据的产出会增加约 30% 的 API 调用成本——每个设计决策需要一次额外的 LLM 调用来生成解释。但这个成本换来的是设计评审效率的质的提升：设计师不再需要逐行审查 AI 生成的代码，而是通过可视化面板查看"AI 做了哪些决策、每个决策的可信度是什么"。在金融和医疗等强合规领域，可解释性不是"锦上添花"而是"必须项"——审计要求每个 UI 决策都有可追溯的理由。
四、总结
可解释性的终极目标不是"让 AI 证明自己对了"，而是"让人类能参与 AI 的决策过程"。当设计师看到 AI 放弃了"居中布局"并给出"表单过长导致滚动距离大"的理由时，设计师可以判断这个理由是否成立——如果成立，信任增加；如果不成立，设计师可以推翻。这种"可审查、可推翻"的协作模式，才是 AI 辅助设计的健康形态。美院教设计评审时老师说："好的设计不是没有理由的选择，而是有理由且经得起追问的选择。"AI 也应该如此。
资料说明
本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0730 资料来源索引，并在发布前将具体来源贴到对应断言之后。
