尧图网页设计 
gstack 设计教义UX 原则 doctrine 如何约束 /design-html 的每一个设计决策【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack本文围绕 gstack 仓库中 design-html/sections/doctrine.md 这一份 UX 设计教义展开。它在/design-htmlPretext 原生 HTML 引擎技能中扮演设计决策的宪法角色任何布局、视觉、排版决定在做出之前都必须先完整执行这份 doctrine而不是凭记忆发挥。读完本文你将掌握这套源于 Krug 可用性与 HCI 研究的用户行为模型——三大可用性法则、扫描/满意即止/凑合走通的行为真相、广告牌设计法、导航指路与好感储量理论——并理解它在 gstack 仓库中如何被实现、注入并被流程强制执行。doctrine 在 gstack 中的角色与生成机制一份自动生成、按需读取的运行时章节在 gstack 中每个技能skill都被设计为决策树骨架 按需加载的章节。doctrine.md正是/design-html技能的一节强制阅读材料。文件头部注释说明了它的来源!-- AUTO-GENERATED from doctrine.md.tmpl — do not edit directly -- !-- Regenerate: bun run gen:skill-docs --也就是说仓库中实际维护的源文件是 design-html/sections/doctrine.md.tmpl其正文仅含一行占位符{{UX_PRINCIPLES}}由bun run gen:skill-docs对应 scripts/gen-skill-docs.ts渲染成最终可读的doctrine.md。这也解释了为什么同一份教义内容会出现在多个技能目录下如design-review、design-shotgun、plan-design-review——它们是同一份模板变量的不同载体。教义的源码级实现位置模板解析器维护了一个模板变量 → 生成函数的注册表见 scripts/resolvers/index.tsUX_PRINCIPLES: generateUXPrinciples,真正生成这段教义文本的函数是 scripts/resolvers/design.ts 中的generateUXPrinciples其代码注释点明了理论出处// ─── UX Behavioral Foundations (Krug HCI research) ───。换句话说你读到 doctrine 中的每一句话最终都来自这一函数返回的模板字符串再经gen:skill-docs写入各个章节文件。章节注册表与触发条件design-html/sections/manifest.json 是一个被动注册表PASSIVE registry只登记章节 ID、文件路径、人类可读标题和触发文本不包含机器判定逻辑。它这样描述 doctrine 的使用时机id: doctrinetitle: UX principles doctrine (how users actually behave)trigger: analyzing the design or making any layout/visual decision (Step 1 onward) — the UX-principles doctrine governs every design choice也就是说从 /design-html 的 Step 1 开始凡是涉及分析设计、做任何布局/视觉决定都必须先读这一节。STOP 闸门教义高于记忆/design-html 技能的入口文件 design-html/SKILL.md 在 DESIGN SETUP 步骤末尾设置了显式 STOP 闸门STOP.Before analyzing the design or making any layout/visual decision (Step 1 onward) — the UX-principles doctrine governs every design choice, Read.../design-html/sections/doctrine.mdand execute it in full. Do not work from memory — that section is the source of truth for this step.不要凭记忆工作Do not work from memory是 gstack 技能体系的一条硬性纪律教义必须是每次设计决策当下重新读取的活文本而不是模型训练后沉淀的模糊印象。这正是该文件被称为doctrine教义的原因——它被设计成需要反复执行的规范而不是只读一次的参考。三大可用性法则设计自证其明doctrine 开篇即给出统摄全篇的三条法则并强调它们是被观察到的行为而非偏好observed behavior, not preferences因此在每个设计决策之前、之中、之后都要适用别让我思考Dont make me think。每一页都应当不言自明。如果用户停下来想我该点哪里这是什么意思设计就已经失败了。优先级排序是自明self-evident 需要解释但很快懂self-explanatory 需要讲解requires explanation。点击次数不重要思考才重要Clicks dont matter, thinking does。三次不动脑、方向明确的点击胜过一次需要思考的点击。每一步都应当像动物、植物还是矿物一样是显而易见的二选一而不是一道谜题。这条法则直接否定了减少点击更好的粗糙直觉——真正的成本是认知负荷不是手指移动距离。删然后接着删Omit, then omit again。先把每页文字删掉一半再把剩下的一半再删一半。自夸式文案happy talk必须消失操作说明必须消失——如果需要用户阅读说明设计就失败了。在 gstack 的工程语境里第三条法则有非常具体的落地形式。/design-html 的 HTML 生成规则见 design-html/SKILL.md要求只使用真实内容绝不使用 Lorem ipsum 或占位符并将Get Started / Learn More 式通用 CTA装饰性渐变/波浪/几何图案通用 testimonial 区块等列入 AI slop 黑名单——这些规则在精神上正是happy talk must die与删了再删的工程化表达。用户真实行为模型四条你必须接受的事实教义强调以下不是理想化假设而是真实人类的操作方式设计必须迁就它们用户是扫读不是阅读Users scan, they dont read。要为扫读而设计视觉层级越重要越突出、边界清晰的区域、标题与项目符号、高亮关键术语。教义给出了一个著名的比喻我们设计的是时速 60 英里下路过的广告牌而不是人们会细细研读的产品手册。用户满意即止Users satisfice。他们选择第一个看起来合理的选项而不是最优选项。因此设计者的责任是让正确选项成为最显眼的选项Make the right choice the most visible choice。用户凑合走通Users muddle through。他们不去搞清楚系统应该怎么运作而是边做边蒙。即使偶然达成了目标他们也不会回头寻找正确路径一旦找到某个能用的方式无论多蹩脚就会一直用下去。这意味着设计不能假设用户会走你规划的理想流程而要为歪打正着的路径兜底。用户不读说明Users dont read instructions。他们直接上手。因此引导必须简短、及时、不可避免否则根本不会被看见。这些行为模型在 gstack 的生成器代码中有直接对应。比如 scripts/resolvers/design.ts 中generateUXPrinciples返回的正是上述四条而同一文件早前部分generateDesignHardRules一带把扫读、满意即止转化为评审硬性指标若设计在 trunk test 上失败会被判定为 HIGH-impact finding无论视觉多精致。广告牌设计法把界面当高速路广告牌来设计承接60 mph 广告牌的比喻doctrine 给出五条界面设计法则使用惯例Use conventions。Logo 在左上角导航在顶部或左侧搜索就是放大镜图标。不要为了显得聪明而在导航上搞创新只有当你确信自己确实有更好的方案时才去创新否则永远跟随惯例。惯例的威力在于跨语言、跨文化——用户凭借 Web 通用惯例就能识别出 logo、导航、搜索和主内容区域。视觉层级就是一切Visual hierarchy is everything。相关的事物在视觉上成组嵌套的事物在视觉上被包含越重要的越突出。如果所有元素都在喊叫那等于什么都没说。默认假设一切都是视觉噪音在被证明无辜之前都是有罪的guilty until proven innocent。让可点击的东西明显可点击Make clickable things obviously clickable。不能依赖 hover 状态来做可发现性——尤其是在移动端根本不存在 hover。形状、位置和格式颜色、下划线必须在不发生任何交互的情况下就传达出这是可以点的。消除噪音Eliminate noise。噪音只有三个来源太多东西抢注意力喊叫、东西没有按逻辑组织混乱、东西太多拥挤。修噪音靠的是做减法而不是做加法。清晰优先于一致Clarity trumps consistency。如果让某处显著更清晰需要付出轻微不一致的代价每次都选择清晰。导航即指路Navigation as WayfindingWeb 上的用户没有尺度感、方向感和位置感。因此导航必须时刻回答六个问题这是什么网站我在哪一页有哪些主要版块在这个层级我有哪些选项我在哪里我如何搜索相应的工程要求是每个页面都要有持续可见的导航persistent navigation深层级结构要使用面包屑breadcrumbs当前所在版块要在视觉上被明确标示。doctrine 还给出了著名的trunk test主干测试把页面上除了导航以外的所有内容都遮住如果此时你仍然能说出这是什么网站、我在哪一页、主要版块有哪些导航就合格了反之导航就是失败的。gstack 的代码证实了 trunk test 不只是纸上谈兵scripts/resolvers/design.ts 明确写道A FAIL on the trunk test is a HIGH-impact finding regardless of how polished the visual design is.——即无论视觉设计多精致trunk test 失败都属于高影响发现并直接映射到评审流程的严重级别。这说明同一份 doctrine 同时服务于设计生成方/design-html和设计评审方/plan-design-review 等生成方用它约束产出评审方用它判定缺陷等级。Goodwill Reservoir好感储量理论用户与你的产品初次接触时自带一个好感储量池。每遇到一处摩擦储量就被消耗一点。doctrine 把消耗与补充的动作分别列出加速消耗Deplete faster的行为隐藏用户想要的信息价格、联系方式、运费因为用户没有按你的方式做事而惩罚他们例如对电话号码做格式强制索取不必要的信息把花哨的东西挡在用户路上开屏页、强制导览、插页广告不专业或邋遢的外观。补充储量Replenish的行为知道用户想做什么并让它显而易见把用户想知道的信息提前告诉他们尽可能帮用户省步骤让用户容易从错误中恢复拿不准的时候道歉When in doubt, apologize。好感储量理论在 gstack 的评审生成器中被进一步量化成了可追踪的指标。同一源文件 scripts/resolvers/design.ts 在评审输出模板中提供了### Goodwill Reservoir (track across the flow)段落并给出可视化刻度例如Goodwill: 70 ████████████████████░░░░░░░░░░——把一个心理学概念转成了评审时可以逐屏标注、逐流程追踪的工程度量。移动端同样的规则更高的赌注移动端并不是另一套规则而是所有规则都放大执行的场景屏幕空间稀缺但永远不要为了省空间牺牲可用性功能可见性affordances必须可见没有光标就没有hover 发现这回事触摸目标必须足够大最小 44px扁平化设计会剥掉那些标示可交互的有效视觉信息要警惕优先级要残酷紧急需要的东西放在手边其余东西隔几次点击可达并且要有清晰的路径通向那里。44px 这条硬指标在 gstack 的代码里反复出现例如 scripts/resolvers/design.ts 的硬性规则Touch targets 44px on all interactive elements以及评审清单中的44px touch targets?。此外/design-html 的实际流程也贯彻了移动优先的验证生成 finalized HTML 后会用 browse 二进制在 375px手机、768px平板、1440px桌面三个视口宽度下分别截图核验文本溢出、布局坍塌与响应式破损见 design-html/SKILL.md。375px 正是 doctrine 所强调的没有 hover、空间稀缺的手机场景教义由此落到了可自动执行的验证步骤上。把 doctrine 用起来一条可执行的落地路径要在实际项目中应用这套教义可以遵循 gstack 已经固化的流程把它当作每次设计决策前的必读项凡是分析设计、做布局或视觉决定先完整重读 design-html/sections/doctrine.md不要凭记忆工作。生成环节服从教义由/design-html产出 Pretext 原生 HTML 时让每一条法则落到具体产出物上——用真实内容替换占位符对应删了再删与真实内容规则、避免 AI slop 黑名单里的模板化组件、确保可点击元素不依赖 hover、保证 44px 触摸目标。评审环节用教义打分设计评审技能把 trunk test 失败判为高影响发现、把好感储量做成逐屏跟踪的刻度条、把 44px 与可访问性列入硬性检查——教义由此从建议变成门禁。如需更新教义不要直接编辑自动生成的doctrine.md而是修改模板占位符的来源{{UX_PRINCIPLES}}对应 scripts/resolvers/design.ts 中的generateUXPrinciples再运行bun run gen:skill-docs重新渲染。一句话总结gstack 把用户如何真实地使用界面这一观察性事实沉淀为一份跨技能共享的 doctrine——它既是 /design-html 生成 HTML 前的必读闸门又是设计评审判定缺陷严重度的评分标准从别让我思考到 44px 触摸目标每一个设计决策都被同一套教义约束。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gstack 设计教义：UX 原则 doctrine 如何约束 /design-html 的每一个设计决策
gstack 设计教义UX 原则 doctrine 如何约束 /design-html 的每一个设计决策【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack本文围绕 gstack 仓库中 design-html/sections/doctrine.md 这一份 UX 设计教义展开。它在/design-htmlPretext 原生 HTML 引擎技能中扮演设计决策的宪法角色任何布局、视觉、排版决定在做出之前都必须先完整执行这份 doctrine而不是凭记忆发挥。读完本文你将掌握这套源于 Krug 可用性与 HCI 研究的用户行为模型——三大可用性法则、扫描/满意即止/凑合走通的行为真相、广告牌设计法、导航指路与好感储量理论——并理解它在 gstack 仓库中如何被实现、注入并被流程强制执行。doctrine 在 gstack 中的角色与生成机制一份自动生成、按需读取的运行时章节在 gstack 中每个技能skill都被设计为决策树骨架 按需加载的章节。doctrine.md正是/design-html技能的一节强制阅读材料。文件头部注释说明了它的来源!-- AUTO-GENERATED from doctrine.md.tmpl — do not edit directly -- !-- Regenerate: bun run gen:skill-docs --也就是说仓库中实际维护的源文件是 design-html/sections/doctrine.md.tmpl其正文仅含一行占位符{{UX_PRINCIPLES}}由bun run gen:skill-docs对应 scripts/gen-skill-docs.ts渲染成最终可读的doctrine.md。这也解释了为什么同一份教义内容会出现在多个技能目录下如design-review、design-shotgun、plan-design-review——它们是同一份模板变量的不同载体。教义的源码级实现位置模板解析器维护了一个模板变量 → 生成函数的注册表见 scripts/resolvers/index.tsUX_PRINCIPLES: generateUXPrinciples,真正生成这段教义文本的函数是 scripts/resolvers/design.ts 中的generateUXPrinciples其代码注释点明了理论出处// ─── UX Behavioral Foundations (Krug HCI research) ───。换句话说你读到 doctrine 中的每一句话最终都来自这一函数返回的模板字符串再经gen:skill-docs写入各个章节文件。章节注册表与触发条件design-html/sections/manifest.json 是一个被动注册表PASSIVE registry只登记章节 ID、文件路径、人类可读标题和触发文本不包含机器判定逻辑。它这样描述 doctrine 的使用时机id: doctrinetitle: UX principles doctrine (how users actually behave)trigger: analyzing the design or making any layout/visual decision (Step 1 onward) — the UX-principles doctrine governs every design choice也就是说从 /design-html 的 Step 1 开始凡是涉及分析设计、做任何布局/视觉决定都必须先读这一节。STOP 闸门教义高于记忆/design-html 技能的入口文件 design-html/SKILL.md 在 DESIGN SETUP 步骤末尾设置了显式 STOP 闸门STOP.Before analyzing the design or making any layout/visual decision (Step 1 onward) — the UX-principles doctrine governs every design choice, Read.../design-html/sections/doctrine.mdand execute it in full. Do not work from memory — that section is the source of truth for this step.不要凭记忆工作Do not work from memory是 gstack 技能体系的一条硬性纪律教义必须是每次设计决策当下重新读取的活文本而不是模型训练后沉淀的模糊印象。这正是该文件被称为doctrine教义的原因——它被设计成需要反复执行的规范而不是只读一次的参考。三大可用性法则设计自证其明doctrine 开篇即给出统摄全篇的三条法则并强调它们是被观察到的行为而非偏好observed behavior, not preferences因此在每个设计决策之前、之中、之后都要适用别让我思考Dont make me think。每一页都应当不言自明。如果用户停下来想我该点哪里这是什么意思设计就已经失败了。优先级排序是自明self-evident 需要解释但很快懂self-explanatory 需要讲解requires explanation。点击次数不重要思考才重要Clicks dont matter, thinking does。三次不动脑、方向明确的点击胜过一次需要思考的点击。每一步都应当像动物、植物还是矿物一样是显而易见的二选一而不是一道谜题。这条法则直接否定了减少点击更好的粗糙直觉——真正的成本是认知负荷不是手指移动距离。删然后接着删Omit, then omit again。先把每页文字删掉一半再把剩下的一半再删一半。自夸式文案happy talk必须消失操作说明必须消失——如果需要用户阅读说明设计就失败了。在 gstack 的工程语境里第三条法则有非常具体的落地形式。/design-html 的 HTML 生成规则见 design-html/SKILL.md要求只使用真实内容绝不使用 Lorem ipsum 或占位符并将Get Started / Learn More 式通用 CTA装饰性渐变/波浪/几何图案通用 testimonial 区块等列入 AI slop 黑名单——这些规则在精神上正是happy talk must die与删了再删的工程化表达。用户真实行为模型四条你必须接受的事实教义强调以下不是理想化假设而是真实人类的操作方式设计必须迁就它们用户是扫读不是阅读Users scan, they dont read。要为扫读而设计视觉层级越重要越突出、边界清晰的区域、标题与项目符号、高亮关键术语。教义给出了一个著名的比喻我们设计的是时速 60 英里下路过的广告牌而不是人们会细细研读的产品手册。用户满意即止Users satisfice。他们选择第一个看起来合理的选项而不是最优选项。因此设计者的责任是让正确选项成为最显眼的选项Make the right choice the most visible choice。用户凑合走通Users muddle through。他们不去搞清楚系统应该怎么运作而是边做边蒙。即使偶然达成了目标他们也不会回头寻找正确路径一旦找到某个能用的方式无论多蹩脚就会一直用下去。这意味着设计不能假设用户会走你规划的理想流程而要为歪打正着的路径兜底。用户不读说明Users dont read instructions。他们直接上手。因此引导必须简短、及时、不可避免否则根本不会被看见。这些行为模型在 gstack 的生成器代码中有直接对应。比如 scripts/resolvers/design.ts 中generateUXPrinciples返回的正是上述四条而同一文件早前部分generateDesignHardRules一带把扫读、满意即止转化为评审硬性指标若设计在 trunk test 上失败会被判定为 HIGH-impact finding无论视觉多精致。广告牌设计法把界面当高速路广告牌来设计承接60 mph 广告牌的比喻doctrine 给出五条界面设计法则使用惯例Use conventions。Logo 在左上角导航在顶部或左侧搜索就是放大镜图标。不要为了显得聪明而在导航上搞创新只有当你确信自己确实有更好的方案时才去创新否则永远跟随惯例。惯例的威力在于跨语言、跨文化——用户凭借 Web 通用惯例就能识别出 logo、导航、搜索和主内容区域。视觉层级就是一切Visual hierarchy is everything。相关的事物在视觉上成组嵌套的事物在视觉上被包含越重要的越突出。如果所有元素都在喊叫那等于什么都没说。默认假设一切都是视觉噪音在被证明无辜之前都是有罪的guilty until proven innocent。让可点击的东西明显可点击Make clickable things obviously clickable。不能依赖 hover 状态来做可发现性——尤其是在移动端根本不存在 hover。形状、位置和格式颜色、下划线必须在不发生任何交互的情况下就传达出这是可以点的。消除噪音Eliminate noise。噪音只有三个来源太多东西抢注意力喊叫、东西没有按逻辑组织混乱、东西太多拥挤。修噪音靠的是做减法而不是做加法。清晰优先于一致Clarity trumps consistency。如果让某处显著更清晰需要付出轻微不一致的代价每次都选择清晰。导航即指路Navigation as WayfindingWeb 上的用户没有尺度感、方向感和位置感。因此导航必须时刻回答六个问题这是什么网站我在哪一页有哪些主要版块在这个层级我有哪些选项我在哪里我如何搜索相应的工程要求是每个页面都要有持续可见的导航persistent navigation深层级结构要使用面包屑breadcrumbs当前所在版块要在视觉上被明确标示。doctrine 还给出了著名的trunk test主干测试把页面上除了导航以外的所有内容都遮住如果此时你仍然能说出这是什么网站、我在哪一页、主要版块有哪些导航就合格了反之导航就是失败的。gstack 的代码证实了 trunk test 不只是纸上谈兵scripts/resolvers/design.ts 明确写道A FAIL on the trunk test is a HIGH-impact finding regardless of how polished the visual design is.——即无论视觉设计多精致trunk test 失败都属于高影响发现并直接映射到评审流程的严重级别。这说明同一份 doctrine 同时服务于设计生成方/design-html和设计评审方/plan-design-review 等生成方用它约束产出评审方用它判定缺陷等级。Goodwill Reservoir好感储量理论用户与你的产品初次接触时自带一个好感储量池。每遇到一处摩擦储量就被消耗一点。doctrine 把消耗与补充的动作分别列出加速消耗Deplete faster的行为隐藏用户想要的信息价格、联系方式、运费因为用户没有按你的方式做事而惩罚他们例如对电话号码做格式强制索取不必要的信息把花哨的东西挡在用户路上开屏页、强制导览、插页广告不专业或邋遢的外观。补充储量Replenish的行为知道用户想做什么并让它显而易见把用户想知道的信息提前告诉他们尽可能帮用户省步骤让用户容易从错误中恢复拿不准的时候道歉When in doubt, apologize。好感储量理论在 gstack 的评审生成器中被进一步量化成了可追踪的指标。同一源文件 scripts/resolvers/design.ts 在评审输出模板中提供了### Goodwill Reservoir (track across the flow)段落并给出可视化刻度例如Goodwill: 70 ████████████████████░░░░░░░░░░——把一个心理学概念转成了评审时可以逐屏标注、逐流程追踪的工程度量。移动端同样的规则更高的赌注移动端并不是另一套规则而是所有规则都放大执行的场景屏幕空间稀缺但永远不要为了省空间牺牲可用性功能可见性affordances必须可见没有光标就没有hover 发现这回事触摸目标必须足够大最小 44px扁平化设计会剥掉那些标示可交互的有效视觉信息要警惕优先级要残酷紧急需要的东西放在手边其余东西隔几次点击可达并且要有清晰的路径通向那里。44px 这条硬指标在 gstack 的代码里反复出现例如 scripts/resolvers/design.ts 的硬性规则Touch targets 44px on all interactive elements以及评审清单中的44px touch targets?。此外/design-html 的实际流程也贯彻了移动优先的验证生成 finalized HTML 后会用 browse 二进制在 375px手机、768px平板、1440px桌面三个视口宽度下分别截图核验文本溢出、布局坍塌与响应式破损见 design-html/SKILL.md。375px 正是 doctrine 所强调的没有 hover、空间稀缺的手机场景教义由此落到了可自动执行的验证步骤上。把 doctrine 用起来一条可执行的落地路径要在实际项目中应用这套教义可以遵循 gstack 已经固化的流程把它当作每次设计决策前的必读项凡是分析设计、做布局或视觉决定先完整重读 design-html/sections/doctrine.md不要凭记忆工作。生成环节服从教义由/design-html产出 Pretext 原生 HTML 时让每一条法则落到具体产出物上——用真实内容替换占位符对应删了再删与真实内容规则、避免 AI slop 黑名单里的模板化组件、确保可点击元素不依赖 hover、保证 44px 触摸目标。评审环节用教义打分设计评审技能把 trunk test 失败判为高影响发现、把好感储量做成逐屏跟踪的刻度条、把 44px 与可访问性列入硬性检查——教义由此从建议变成门禁。如需更新教义不要直接编辑自动生成的doctrine.md而是修改模板占位符的来源{{UX_PRINCIPLES}}对应 scripts/resolvers/design.ts 中的generateUXPrinciples再运行bun run gen:skill-docs重新渲染。一句话总结gstack 把用户如何真实地使用界面这一观察性事实沉淀为一份跨技能共享的 doctrine——它既是 /design-html 生成 HTML 前的必读闸门又是设计评审判定缺陷严重度的评分标准从别让我思考到 44px 触摸目标每一个设计决策都被同一套教义约束。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考