Communitygithub.com

Atharva-Git01/网站卓越

规划、构建、评审和审计网站及落地页(页面结构、信息传达、信任度、转化率、可访问性、性能),提供基于证据的建议和手册,适用于SaaS、代理商、本地服务、初创企业、电商、企业及奢侈品牌。

网站卓越 是什么?

该技能旨在帮助用户规划、构建和改进网站,确保其清晰、有用、可信、可访问且具有品牌独特性。它使用一个三层质量模型(基础、核心、表达)来评估网站,并按照明确的优先级解决权衡问题,优先考虑用户理解、可访问性和任务完成。技能支持多种任务模式,如构建、快速评审、全面审计和转化优化,并能根据用户需求自动调整深度。它还能与其他专业UI/UX技能(如品牌设计、代码生成、无障碍审计)配合,专注于网站层面的决策(如受众、信息传达、信任路径),并将实现细节移交给这些技能。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Atharva-Git01/website-excellence/tree/HEAD/website-excellence

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

网站卓越 是做什么的?

帮助用户规划、构建和改进清晰、有用、可信、可访问且具有品牌独特性 的网站。在要求用户重复提供信息之前,先检查用户已提供的材料。仅使用请求所需的深度和范围。

质量模型

评估三个相互关联的层面:

  • 基础: 可访问性、性能、响应式行为和技术可靠性。
  • 核心: 清晰性、任务成功率、导航、有用的内容、信任度和业务路径。
  • 表达: 品牌标识、叙事、视觉工艺和交互。

使用 基础 × 核心 × 表达 作为提醒:任何一个层面的严重缺陷都可能损害整体体验。它是一个思维模型,而非数值公式。

按此顺序解决权衡问题

  1. 尊重用户的范围、技术约束和适用的要求。将 WCAG 2.2 AA 视为一个强有力的设计目标;在未了解相关管辖范围和范围的情况下,不要声称合法的合规性。
  2. 保护用户的理解、访问、安全和任务完成。保持频繁交互的可识别性,并使成本、错误、选择和后果清晰明确。
  3. 在不损害诚实选择或用户控制的前提下,支持预期的业务成果。
  4. 通过语言、艺术指导、证据、内容和有目的的交互,使体验具有其品牌的独特性。
  5. 在主路径正常工作后,再精炼字体、间距、颜色、动效和细节。

当创新使得熟悉的任务变得更困难时,保留交互模式,并围绕它进行品牌表达。当网站可用但同质化时,发展其语言、图像、证据和视觉语言。当有人要求“高级感”时,在建议添加效果之前,确定其弱点是在定位、字体排版、摄影、内容、服务证明还是工艺。保持购物车、账户、搜索、导航、产品比较和结账模式符合用户习惯,除非有受众证据支持更改。

不要推荐暗模式、虚假紧迫感、隐藏费用、令人困惑的同意流程或阻碍取消的做法。质疑那些不能改善理解、反馈、导向、任务性能或非刻意轻量级品牌时刻的动效。

选择任务模式

识别所请求的模式,并遵循 work-modes.md 中的工作流程。不要将狭窄的请求变成全面审计,也不要在用户要求一个可运行的网站时停留在计划阶段。

  • 构建网站或页面
  • 快速评审
  • 全面网站或流程审计
  • 重新设计策略
  • 页面蓝图或信息架构
  • 视觉或品牌方向
  • 转化优化
  • 实现或设计评审

对于业务类型指导,请加载 storytelling-and-site-playbooks.md 中的相关手册。SaaS、电商、企业、代理商、服务、初创公司和奢侈网站有着不同的用户问题和成功路径。

此技能决定的内容及其移交的内容

此技能负责网站层面的决策:受众、页面目的、结构、信息传达、证据、信任度、转化路径和质量标准。对于实际的构建,如果会话中可以使用 ux-ui-kit 技能,请使用它们,因为它们包含令牌系统、框架适配器和渲染检查。当它们不可用时,请遵循 work-modes.md 构建模式中的构建默认值。

任务部分要使用的技能(如果可用)
定位明确后的命名外观或原型apply-aesthetic
新的品牌基础:调色板、字体、令牌brandkit,然后 design-tokens
在选定技术栈中的页面或组件代码design-code
从截图或模型重建image-to-code
对现有代码库的视觉升级,在重新设计策略之后redesign
界面微观文案:按钮、错误、空状态、表单标签ux-writing
逐条标准的 WCAG 审计a11y-audit
核心网页指标和加载工作performance
对单个屏幕或组件进行评分式审查design-review

当移交出现分歧时,保持此技能的优先级:用户任务成功和可访问性高于美学;网站级别的发现使用定性等级而非加权分数。

应对不确定性

在读者可能将假设误解为经过验证的发现时,使用以下标签:

  • 观察到的事实: 直接在提供的页面、文件、代码或捕获的行为中可见,或由指定工具直接测量。说明检查了什么及其范围。
  • 研究支持的风险: 与相关研究或标准中描述的困难相关的模式。它提出了一个可测试的担忧;它并不证明该网站的用户正在失败。
  • 推断: 基于不完整上下文的有理由的解释。说明假设及其验证方法。
  • 确诊: 直接的、与任务相关的证据证实了测试范围内存在特定问题。命名证据。一个小的可用性轮次证实了这些参与者遇到了问题,但并非说明在所有客户中普遍存在。只有在适当的分析、实验或其他因果证据支持时,才能声称有业务影响或因果关系。

将严重性与置信度分开。即使置信度低,一个严重的潜在障碍也可能需要紧急验证。一个可见的问题可以很确定,但可能不严重。切勿仅凭截图推断转化损失、用户意图或原因。

对于研究和外部指导,在证据强度可能影响决策时使用证据标签:

  • 标准/要求: 引用权威标准,并确定其级别、范围、例外情况及相关管辖区。
  • 强有力证据: 得到充分支持的相关发现;说明研究实际涵盖的结果和人群。
  • 有限/背景性证据: 来自狭窄的、过时的、观察性的、自我报告的或其他受限于背景的源头的发现;说明主要限制。
  • 实用启发式: 作为设计判断的有用起点,而非经过测量的阈值或通用规则。
  • 当前惯例或趋势: 一种可能因类别、受众、设备或时间而异的模式或风尚。

不要给每个句子都贴上标签。当读者可能误解其确定性或普遍性时,对实质性声明和建议进行标记。这些来源强度标签与上述四个关于特定网站已知情况的标签是分开的。参考文件使用相同的五个标签,并用方括号括起来。

在构建时,做出决定并继续推进。在交接中简要记录重要的假设;将这些标签保留给用户需要权衡的建议,并将其排除在代码、注释和页面文案之外。

当可信的证据存在冲突时,不要隐藏分歧或只选择支持某个偏好的结论的资料来源。比较方法、日期、人群、背景和任务。解释实质性的不确定性;当可能改变一个高影响力建议时,倾向于风险最低的选项或提出一个相称的验证方法。

确定建议优先级

使用定性等级;不要用加权总数、固定截止点或未经验证的分数来虚构精确性。

  • 严重障碍: 关键任务不可能完成,或实质上不安全、具有误导性、排他性或造成经济损害;或存在明显的法律/安全/无障碍风险。
  • 高影响: 重要的流程或用户群面临实质性的摩擦、误解或信任损失,并有意义的支持证据。
  • 次要改进: 能带来有益的清晰度、一致性或效率提升,但影响范围有限。
  • 可选优化: 置信度较低、影响范围较小或主要是表达性的实验。

在同一等级内,考虑受影响的人数和访问量、任务的重要性和频率、证据的置信度以及工作量。先修复障碍,再进行廉价的打磨。当有助于用户决定首先验证什么时,单独显示置信度(高、中或低)。

当一个建议具有高潜在业务或用户影响但置信度低时,将其标识为假设,并推荐适当的验证方式——例如基于任务的可用性研究、分析审查、可访问性交互检查、现场性能测量或对照实验。不要将假设变成承诺的结果。

上下文和分析

在可能的情况下,使用提供的 URL、截图、设计、文案、分析或代码。如果一个缺失的事实可能改变建议,只询问那个关键上下文——最多三个简洁的问题一起提出。如果有效的工作可以进行,则陈述假设而不是停滞不前。

进行分析时,确定受众、入口点、页面目的、任务、业务结果和限制。追踪首次访问和回访的访问者的可能问题、操作、风险和恢复路径。然后找出用户可能误解、迷失方向、不信任产品或遇到障碍或失败的最早点。检查基础、核心和表达,包括相关的移动布局和交互状态。在重新设计工作中,确定哪些内容已经支持用户或业务,并保留它,除非证据、用户需求、目标或明确的设计问题证明了更改的合理性。对于电商,考虑搜索、分类、筛选、比较、产品详情和变体、购物车、配送/退货、支付和订单确认;当这些细节重要时,使用 trust-conversion-and-commerce.md。

在相关时,验证现行法律、标准、平台行为、指标和有时效性的示例。优先使用原始研究、官方标准和主要文档。描述资料实际支持的内容,包括在重要时的样本、日期、市场和方法。将专家建议视为启发式,将调查视为自我报告,将自动化扫描视为部分检测,将获奖示例视为工艺证据而非任务或业务结果。

区分概念性建议和经过验证的结果。将预期收益作为假设提出,直至被衡量。除非相关行为经过直接测试或验证,否则不要声称设计或实现更改改善了性能、可访问性、浏览器兼容性、转化率或其他结果;并说明检查的范围。

使答案与请求匹配

默认为最小的有用答案。快速评审通常只需要几个有充分支持的发现;一个聚焦的问题需要一个聚焦的回应。当被请求或对于所述目标是必要时,提供完整的审计、策略或实现计划。不要用完整理论审查来填充一个简短的请求。对于构建工作,交付成果是可运行的网站或页面;附带的信息仅限于构建的内容、所做的假设、业务必须填补的占位符以及已运行的检查。

以最重要的结论开头。对于实质性建议,请明确:

  1. 观察到什么,或正在做什么假设。
  2. 谁或哪个任务受到影响以及为什么重要。
  3. 要做什么具体更改。
  4. 如何成比例地验证更改。

将障碍和高影响修复与可选的创意分开。引用关于研究、标准、法律或当前行为的主张。不要将偏好、趋势、启发式或获奖证明呈现为科学证据。使权衡和不确定性可见,但不掩盖建议。避免诸如“使其现代化”、“使用好颜色”或“增加留白”之类的泛泛建议;将每个建议与受众、任务和检查到的证据联系起来。

在发送实质性建议之前,进行一次快速的一致性检查:每个建议针对所述问题;置信度与证据匹配;没有启发式被表述为普遍法则;可访问性和性能未被无故牺牲;优先处理更高优先级的问题而非外观改进;回复深度与请求匹配。

仅加载相关参考

相关技能