SuperAPI AI 工具集

domain-expert-configuration

设计与创作

查看项目

更新于 10-15 16:31

技能介绍

用途

领域专家配置界面用于把复杂系统的参数暴露给那些对问题领域非常了解、但不了解系统内部机制的用户。典型系统包括优化算法、规划引擎、仿真等。

核心矛盾在于:系统参数以技术术语定义(权重、阈值、标志、容差),而用户以领域术语思考(等待多久、何时重试、如何分组结果)。界面必须在两套词汇之间做翻译,并且始终偏向用户的语言。

主要能力

领域语言优先于技术语言

每个参数的标签、提示和错误信息都应描述该参数在用户世界中的含义,而不是它在系统内部做什么。例如:

  • max_concurrent_jobs → 同时运行的最大任务数
  • enable_auto_retry → 自动重试失败的任务
  • batch_allocation_threshold → 填充达到多少百分比后开始新批次
  • request_timeout_ms → 每个请求的最大等待时间(秒)
  • enable_fuzzy_matching → 允许近似匹配

如果无法为某个参数写出领域标签,就要质疑是否应该把它暴露给用户。无法用领域术语解释的参数应放在开发者配置文件中,而不是面向用户的界面里。

按领域概念分组

参数应按它们所控制的现实问题方面分组,而不是按技术类别(布尔值放一起、数字放一起),也不是按字母顺序。例如一个处理工具可以这样分组:

  • 处理限制:同时最大任务数、每请求最大等待、内存上限
  • 匹配规则:允许近似匹配、大小写敏感、必填字段
  • 批处理行为:批次填充阈值、最大批次数

每组应有一个简短标题,描述它控制任务的哪个方面,而不是参数的类型。

合理默认值

每个参数都必须有一个对多数情况都正确的默认值。用户应能全部使用默认值就得到合理结果。

  • 显示默认值:字段处于默认值时予以标示;用户改动后应便于重置。
  • 示例:最大等待时间显示为自定义值 30 秒,并提供“重置为默认值(15 秒)”;批次填充阈值显示 70%(默认)。

这一点很重要:领域专家面对不熟悉的参数往往不知道该填什么。如果字段空白且无提示,他们要么跳过(让系统处于未知状态),要么随便填一个值。可见的默认值传达的是“除非你另有说明,系统就按这个假设运行”。

输入类型匹配领域语义

根据参数的含义而非仅仅是数据类型来选择输入控件:

  • 二元规则(开/关):开关,如“自动重试:[开关]”
  • 带明确单位的受限数字:带单位标签的数字输入,如“最大等待:[___] 秒”
  • 命名选项之间的选择:下拉或单选组,如“输出格式:[JSON ▾]”
  • 百分比或比例:滑块加数字输入,如“批次填充阈值:[━●━━] 70%”
  • 自由文本标识符:文本输入,如“任务引用:[___]”

所有数值输入都必须带单位,绝不能显示没有单位的裸数字。单位标签应紧邻输入框(优先作为后缀:[] cm,而不是 cm [])。

渐进式披露

并非所有参数同等重要,应分层暴露:

  • 主设置(始终可见):控制最常调整行为的参数。领域专家仅调整这些就能完成 80% 的任务。
  • 高级设置(默认折叠):用于边缘情况、微调或较少见场景的参数,放在“高级选项 ▾”披露控件之后。需要的人打开,不需要的人看不到。
  • 开发者/系统参数:完全不在面向用户的界面中显示,放在配置文件或环境变量中。

不要把一切都塞进高级区当万能筐。频繁需要的参数应放在主设置中。

已保存配置与会话配置

许多操作型工具区分:

  • 已保存配置:用户持久化的偏好(标准处理设置、标准规则),自动加载。
  • 会话覆盖:针对某次运行的一次性调整,不应改变已保存的默认值。

界面中要明确这一区分。用户为某次运行调整参数时,不应担心破坏已保存的默认值。示例布局中会标注每个字段是“仅本次会话”还是“已保存”,并提供“保存为默认值”和“重置为已保存”操作。

校验与约束反馈

当值无效或与其他设置冲突时,用领域术语告知用户:

  • 技术错误 value out of range [0, 9999] → 领域错误“等待时间必须在 0 到 999 秒之间”
  • 技术错误 constraint conflict: retry=true, fail_fast=true → 领域错误“自动重试和首次失败即停止不能同时启用”
  • 技术错误 threshold must be < 1.0 → 领域错误“批次填充阈值必须小于 100%”

校验应内联显示在受影响字段旁边,不要等用户提交后才报告冲突。对于相互影响的设置,要展示其关系,例如“关闭自动重试时,最大尝试次数设置不起作用”,以免专家浪费时间调整未生效的参数。

来自模型的建议

当模型把自由文本转成配置时,应以相同的表单控件呈现其解读,绝不要用散文。

  • 标记每个由模型推断而非直接读取的值。用户修正该字段后标记清除。
  • 编辑任何控件都会重新运行建议,使修正显示其后果。
  • 代码负责选择、排序和计数,模型只负责措辞。模型组装的列表在某些运行中会遗漏、合并或数错条目。
  • 在帮助文本中说明这一分工。

散文形式要改一个数字就得重新提示,而带标记的字段只需一个操作。

使用方式

该技能以设计规范与审查清单的形式提供,用于指导配置界面的设计与评审。审查清单包括:

  • 每个参数标签是否使用领域语言而非技术语言?
  • 参数是否按所控制的领域概念分组,而非按类型或字母顺序?
  • 每个参数是否有可见的默认值?
  • 是否有针对单个参数的“重置为默认值”操作?
  • 所有数值输入是否在字段旁显示单位?
  • 输入类型是否匹配领域语义(二元用开关、命名选项用下拉)?
  • 高级参数是否默认隐藏在披露控件之后?
  • 已保存配置与会话覆盖的区分是否明确?
  • 校验是否以领域语言内联显示?
  • 参数交互(冲突、依赖)是否在界面中说明?
  • 模型推断的值是否以带标记的可编辑字段呈现,且选择与计数由代码完成?

适用场景

适用于设计设置面板、求解器配置、规划引擎参数、仿真参数等面向非开发者领域专家的配置界面。

限制

资料未提供该技能的具体安装方式、依赖环境、支持的平台或工具集成信息,暂未提供。