让模型模拟一次 Python 随机：gpt-taste 的 `<design_plan>` 预检

2026-08-09

本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。

taste-skill 仓库里有个很短的 skill：文件夹叫 gpt-tasteskill，install name 是 gpt-taste，整份 SKILL.md 只有 74 行。它最值得单独拿出来讲的不是那些设计规则，而是一条流程约束——写任何 React/UI 代码之前，模型必须先输出一个 <design_plan> 块，并在里面「模拟执行」一段 Python 随机脚本。

一、这条规则原文在要求什么

gpt-taste 的 §1 标题就是「Python 驱动的真随机（打破循环）」。它的立论写得很直接：LLM 天生偷懒、总选第一个布局选项。为了防止这一点，原文的要求是——写任何 UI 代码前必须在 <design_plan> 块里模拟一次 Python 脚本执行。

模拟的方式，原文说的是用一个确定性种子（例如拿用户 prompt 的字符数做取模运算），去模拟 random.choice()，严格选出四类结果：

1 个 Hero 架构（来自该 skill 的 §3）
1 套排版栈（Satoshi、Cabinet Grotesk、Outfit 或 Geist。NEVER Inter）
3 个独特组件架构（来自 §6）
2 个高级 GSAP 范式（来自 §5）

然后是那句最硬的话：禁止两次默认到同一个 UI，必须遵循模拟随机的确切输出。

这里有个词要抠住：模拟。原文要求的动作是在 <design_plan> 块里模拟一次脚本执行，不是去调用解释器真跑一段代码。skills/ 下的这些 SKILL.md 都是写给模型看的提示词约束，不是 lint、不是 CI、不是运行时。所以「模拟 Python 随机」的实际形态，是模型自己写出一段看起来像 Python 输出的文本，然后再按自己写的那段文本去布局。这是一条指令，不是「照做之后每次都会换一个布局」的结果——它会不会兑现，取决于模型有没有照着执行。

二、被抽的四类结果，各自绑着哪些硬约束

抽签本身不是重点，抽出来之后要遵守的东西才是。四类结果分别指向该 skill 的三个小节。

**Hero 架构（§3）**给了三个选项：Cinematic Center（文字完美居中、超大宽度，下方恰好两个高对比 CTA，再往下或所有元素之后是出血背景图配深色径向压暗）、Artistic Asymmetry（文字左偏，一张艺术化浮动图片从右下方压过文字）、Editorial Split（文字左、图片右，但带巨大负空间）。原文注明这三个是「由 Python 随机分配」的。

配套的是 §3 的两行铁律：H1 绝不能超过 2 到 3 行，4、5、6 行被原文称为灾难性失败；修法是给 H1 用超宽容器（max-w-5xl、max-w-6xl、w-full）让词横向流动，同时把字号压成 clamp(3rem, 5vw, 5.5rem)。另外 hero 里不许在文字上放浮动的印章/徽章图标，hero 下面不许挂胶囊标签，hero 里不许塞原始数据统计；按钮是深底白字、浅底深字，看不见的文字直接算失败。

排版栈那句 NEVER Inter 后面还要单独说，先记住它是全大写写在原文里的。

**组件架构（§6）**是个小武器库：Inline Typography Images（把小的胶囊形图片直接嵌进巨型标题内部，原文给了示例 I shape <span className="inline-block w-24 h-10 rounded-full align-middle bg-cover bg-center mx-2" style={{backgroundImage: 'url(...)'}}></span> digital spaces.）、Horizontal Accordions、Infinite Marquee、Feedback/Testimonial Carousel。抽三个出来用。

**GSAP 范式（§5）**里可选的有 Hover Physics（overflow-hidden 容器内 group-hover:scale-105 transition-transform duration-700 ease-out）、Scroll Pinning（左侧标题 ScrollTrigger pin: true，右侧图集上滚）、Image Scale & Fade Scroll（图片从 scale: 0.8 长到 1.0，滚出视口时淡到 opacity: 0.2）、Scrubbing Text Reveals（段落词不透明度从 0.1 随滚动 scrub 到 1.0）、Card Stacking。抽两个。§5 开头明写静态界面被严格禁止，要写真的 GSAP（@gsap/react、ScrollTrigger）。

三、`<design_plan>` 的五项预检，逐项看它在管什么

§8 是这份 skill 的落点。原文要求写任何 React/UI 代码前必须输出一个 <design_plan> 块，里面含五项：

预检项	要求做的事	它在替哪一节把关
1. Python RNG Execution	写一段 3 行的模拟 Python 输出，展示基于 prompt 字符数确定性选出的 Hero 布局、组件武器库、GSAP 动画和字体	§1 的抽签
2. AIDA Check	确认页面含 Navigation、Attention (Hero)、Interest (Bento)、Desire (GSAP)、Action (Footer)	§2 的页面结构
3. Hero Math Verification	显式说明给 H1 施加的 `max-w` 类以保证它横向流动为 2-3 行；确认无印章图标或垃圾标签	§3 的两行铁律
4. Bento Density Verification	数学上证明网格行列不留空隙且已应用 `grid-flow-dense`	§4 的无缝网格
5. Label Sweep & Button Check	确认无廉价元标签、按钮文字对比完美	§7 的封杀清单

对着这张表能看出一件事：这五项不是同一个可核查等级。

第 3、4、5 项落到了具体的类名和具体的字符串上。H1 上到底有没有 max-w-5xl，你打开代码搜一下就知道；Bento Grid 上有没有 grid-flow-dense，同理；§7 封杀的那批元标签——“SECTION 01”、“SECTION 04”、“QUESTION 05”、“ABOUT US”——是可以直接 grep 的字符串，原文的处置是完全删掉，理由写的是它们看起来廉价、不专业。这三项属于说了什么就能验什么：模型在 <design_plan> 里声称做了，你事后能对上。

第 2 项介于中间。五个区块在不在，肉眼扫一遍页面结构就知道；但「Interest 区块是不是真的高密度」这种就没有判定标准了。

第 1 项则基本只能靠自述。模型写出来的那 3 行「Python 输出」，没有第二份东西可以跟它对账——既没有真跑过的脚本，也没有种子的可复现记录。它更像是把选择过程显式写下来，让后面四项有个可以对照的声明。

顺带说一处两节之间的粒度差异：§1 列的是四类共七个结果（1 个 Hero、1 套排版栈、3 个组件、2 个 GSAP 范式），而 §8 第 1 项要求把 Hero 布局、组件武器库、GSAP 动画和字体压进 3 行输出。两处写法不同，以仓库当前状态为准，我们不推断原因。

四、确定性种子这件事，按字面读会得到什么

原文举的种子例子是「用户 prompt 的字符数取模运算」。这是一个纯确定性的东西：同一段 prompt，字符数不变，取模结果不变，按字面照做抽出来的就是同一套配置。

而 §1 同时写着「禁止两次默认到同一个 UI」。

这两条各自都在原文里，我们只把它们并列摆出来，不替作者解释怎么调和。对你有用的是判断依据：如果你希望两次生成不一样，那么输入必须不一样——这一点由种子的定义直接决定，不需要额外假设。反过来，如果你要的恰恰是「同样的需求，重跑一次得到同样的版式」，那按字面照做的结果正好是可复现的——注意这仍然只是按种子定义推出来的字面结论，不是我们跑出来的观察。

五、`NEVER Inter` 和仓库里另外两处口径

gpt-taste 的排版栈把话说死了：Satoshi、Cabinet Grotesk、Outfit 或 Geist，NEVER Inter。

但同一个仓库里，brutalist-skill（install name industrial-brutalist-ui，skills/llms.txt 里标着 Beta）的 §3.1 讲宏观排版最佳网页字体时，列的是 Neue Haas Grotesk (Black)、Inter (Extra Bold/Black)、Archivo Black、Roboto Flex (Heavy)、Monument Extended。

而默认 skill taste-skill（install name design-taste-frontend，当前自标 v2 experimental）的 §4.1 是第三种口径：Inter「不建议作默认」，但留了 override 路径——用户明确要中性 / Linear 风格时，或者是公共部门、无障碍优先的站点时，可以接受。

三处口径不同，这是可核实的客观事实。哪一处「更对」、为什么没统一，我们不推断，也不拿它去评价项目质量。

不过对使用者来说，这三行摆在一起恰好给出了判断依据：字体禁令的适用范围是跟着风格走的，不是全局真理。你在做一个 editorial 感的营销落地页，gpt-taste 的禁令是对着这个场景写的；你在做一个政务或强无障碍要求的站点，默认 skill 的 §4.1 已经明写了这是可以走 override 的情形。搞不清自己属于哪一档时，与其纠结禁令本身，不如回到这三处各自写明的适用范围：gpt-taste 的那句写在它 §1 的排版栈选项里，管的是这一个 skill 抽签抽出来的字体；brutalist-skill 的清单挂在 §3.1「宏观排版（结构性标题）」名下，管的是重无衬线的结构性大标题；默认 skill 的 override 则明写了两种情形——用户明确要中性 / Linear 风格，以及公共部门、无障碍优先的站点。三处都限定了自己在管什么，脱离这些语境去照搬其中任一条，都不再有原文依据。

关于十三个 skill 之间怎么挑、v1 与 v2 的完整差异，我们另有专门的篇目在讲，这里不铺开。

六、这套预检值不值得抄进自己的工作流

先说不能指望的部分。<design_plan> 是一段要求模型自我声明的流程，它没有任何执行力：模型可以照写五项、代码却不照做，也可以干脆不输出这个块。原文里那些全大写的 MUST 和 NEVER，性质是指令，不是结果。所以「装上 gpt-taste 就不会再出现居中撞脸的落地页」这种话，本文不会写。

再说可以拿走的部分。这五项预检里，第 3、4、5 项本质上是把审美要求翻译成了可 grep 的检查点：H1 有没有宽容器、网格有没有 grid-flow-dense、页面里有没有 “SECTION 01” 这类字符串。这类东西不依赖模型听不听话——它写完之后你自己搜一遍就能判。如果你需要的是确定性保障，正确的做法是把这几条挪进自己的构建链或 review 清单里，让 skill 只承担前置的倾向调节。

还有一条容易被忽略的：gpt-taste 的核心指令开篇明确要求代码、注释、输出里都不许用 emoji，§2 的 SPACING RULE 要求主区块之间给巨大纵向内边距（例 py-32 md:py-48），§4 要求 Bento 卡片克制在 3 到 5 张、并且必须用 grid-flow-dense 数学验证不留空洞，§7 要求整页包在 <main className="overflow-x-hidden w-full max-w-full"> 里防横向滚动条。这几条全是二值判断，抄进你自己的 checklist 成本极低。

至于「模拟一次 Python 随机」这个动作本身——它是这份 74 行文件里最有辨识度的一笔，也是最难验证的一笔。要不要照搬，取决于你能不能接受一条事后无从对账、只能靠模型自己执行的约定。

本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、 skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。 skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。