需求像 Fluent 就装 Fluent：§2 的十二行映射表与诚实规则

2026-08-09

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

让模型写一个「Microsoft 风格」的企业后台，它可以手搓一堆 CSS 去模仿 Fluent 的观感，也可以直接装 @fluentui/react-components。taste-skill 默认 skill 的 §2 就是冲着这个岔路口写的一张十二行映射表，加上两条不给回旋余地的硬规则。

一、§2 到底在管什么

先把这份文件的性质摆清楚。我们说的是 skills/taste-skill/SKILL.md（1206 行，install name design-taste-frontend）里的 §2，标题是 BRIEF → DESIGN SYSTEM MAP。

它的立场原文只有一句话的分量：有官方包的东西不要自己手写 CSS，也不要把审美潮流冒充成官方体系。

这句话拆开是两件事。前半句针对「Fluent / Material / Carbon 这些真的有 npm 包的体系」，后半句针对「Bento、Brutalism、Glassmorphism 这些只是审美方向、根本没有官方包的东西」。§2.A 管前者，§2.B 管后者。本文讲 §2.A 这张表；§2.B 那条「审美不是体系」的分界线，我们另有一篇专门讲。

二、十二行映射表

§2.A 的表长这样，左列是「需求读起来像……」，右列是该用的包，最后一列是 skill 自己给的理由：

需求读起来像…	用	原因（原文）
Microsoft / 企业 SaaS / 仪表盘	`@fluentui/react-components` 或 `@fluentui/web-components`	官方 Fluent UI，微软 token，无障碍已做好
Google 味 UI、Material 风产品	`@material/web` + Material 3 tokens	官方，可通过 Material Theming 定制
IBM 风 B2B / 企业分析	`@carbon/react` + `@carbon/styles`	官方 Carbon，成熟的高数据密度模式
Shopify 应用界面	`polaris.js` web components / Polaris React	Shopify admin UI 必需
Atlassian / Jira 风产品	`@atlaskit/*` + `@atlaskit/tokens`	官方 Atlassian DS
GitHub 风开发者工具 / 社区页	`@primer/css` 或 `@primer/react-brand`	官方 Primer，Brand 变体用于营销页
英国公共部门服务	`govuk-frontend`	法规层面被期待
美国公共部门 / 信任优先	`uswds`	同上
快速本地商户 / agency MVP	Bootstrap 5.3	无聊、快、能用
现代可访问的 React 基座	`@radix-ui/themes`	原语 + 打磨过的主题
现代 SaaS 且要自己拥有组件	shadcn/ui（`npx shadcn@latest add ...`）	代码归你，好改；绝不能原样出默认态
Tailwind 系现代 SaaS / AI 营销页	Tailwind v4 utilities + `dark:` 变体	独立开发者与小团队的默认

十二行，从上往下大致是「厂商官方体系 → 公共部门 → 通用基座 → 自持组件 → 纯 utility」。

三、这张表的关键在左列，不在右列

右列的包名没什么好讲的，装就是了。真正难的是左列那句「读起来像」。

注意它写的不是「客户点名要 Fluent」。skill 的整体流程是 §0 先出一句 Design Read，然后 §2 才接手。也就是说，触发这张表的是推断出来的设计方向，不是用户嘴里说出来的包名。用户说的可能是「我们做的是给企业 IT 管理员用的后台，风格要像微软那套」，模型要做的是把这句话映射到第一行。

这带来一个很实际的判断问题：推断错了怎么办。表的左列本身是有歧义的，「企业 SaaS / 仪表盘」和「IBM 风 B2B / 企业分析」在很多真实需求里是同一句话的两种说法。skill 对这种情况给的路子在 §0.C：需求含糊时只问一个澄清问题，不要一次甩一串，且只在设计读数真的会分叉时才问；能自信推断就别问，直接声明读数继续走。

所以你在用这份 skill 的时候，判断依据是这样的：如果你的需求里包含已经确定的组织归属（我们是 Shopify 应用、我们要上 GOV.UK 的服务清单），那这张表基本没有推断空间，直接照做；如果只是「看起来专业一点的 B2B」，那它落到哪一行是可争的，值得你在 brief 里自己先钉死，而不是让模型替你选。

顺带说一句，公共部门那两行（govuk-frontend / uswds）和 skill 别处的口径是连着的：§0.A 把「公共部门、受监管行业、无障碍优先受众」列为 quiet constraints，原文说这些约束凌驾于审美偏好之上；§1.B 的用例预设表里 Public-sector service 那行给的旋钮是 3 / 2 / 5，是全表 DESIGN_VARIANCE 与 MOTION_INTENSITY 取值最低的一行。三处指向同一件事，不是孤立的一行推荐。

四、两条硬规则才是这一节的骨头

表下面挂着两条规则，比表本身更值得读。

Honesty rule。 原文的要求是：需求命中上表，就安装并使用官方包，不许手抄它的 CSS，不许引了 token 又覆盖掉 90%。

后半句是真正的杀招。「装了 Carbon 然后把它的 token 覆盖到面目全非」这个做法，在结果上和手抄 CSS 没区别，但过程上更有欺骗性——package.json 里确实有 @carbon/styles，看起来像是按官方来的。这条规则堵的就是这个口子。

One system per project。 不许在同一棵树里混 Fluent React 和 Carbon，不许把 shadcn/ui 组件塞进 Material 3 应用。

这条在多人协作或者多轮对话生成的项目里最容易破防：第一轮定了 Material 3，第三轮你说「这里加个好看的卡片」，模型顺手 npx shadcn@latest add card，从此两套 token 体系并存。规则写在这里，是要求模型每次加组件前回头确认当前项目已经选了哪一套。

五、表里两行需要单独拎出来说

shadcn/ui 那行的原因列自带一句加粗禁令：代码归你、好改，但绝不能原样出默认态。这一条在 §9.E 里还有一次呼应，措辞是允许定制、绝不用默认态，圆角、颜色、阴影、版式都要按项目审美改。同一件事在表里和 §9.E 里各写了一次。

Bootstrap 5.3 那行的原因写的是「无聊、快、能用」。这是整张表里唯一一处不带褒义的推荐语。它的位置也很明确：快速本地商户、agency MVP。你要是在给一家本地餐馆做官网，这行就是给你的；你要是在做一个要卖给设计师看的作品集，它不在候选里。

至于最后一行的 Tailwind v4，它其实是这张表的兜底。§3.A 规定：当 §2.A 没命中任何真实设计系统时，默认样式方案就是 Tailwind v4，v3 仅在既有项目要求时用。也就是说，这张表在实际运行时更像一个「先看看有没有官方体系可用，没有再走默认栈」的分流器。

六、这些规则的性质，必须说在前面

这一点比前面所有内容都重要：§2 是写给模型看的提示词约束，不是工程保障。

我们实读这个仓库的顶层结构：没有 src/，没有 npm 包，没有构建产物，scripts/ 下那几个 .mjs 处理的是 README 的图片资源，与 skill 功能无关。它是一个纯 Markdown 规则仓库，核心资产就是 skills/*/SKILL.md。所以没有任何东西会在你的项目里执行「命中 Fluent 就必须装 Fluent」这条判断。它是一条写给模型的指令，不是一个会在 CI 里拦你的检查。默认 skill 开篇那两行引文说得更直白：原文写的是每一条规则都是 contextual，没有一条会自动触发（“None of it fires automatically”），要先读 brief 再挑适用的。

这也意味着，如果你的团队真的需要「不许混用两套设计系统」这个保障，该做的是在自己的 lint 或依赖审查里加规则，skill 只能当前置的倾向调节。

配套地，skill 在 Appendix A 里给了各设计系统的安装命令，原文自称是给 agent 的「现实锚点」，用来避免凭训练数据虚构包名。与本篇直接相关的几条：

npm install @fluentui/react-components                     # Fluent UI React (v9)
npm install @carbon/react @carbon/styles                   # IBM Carbon
npm install govuk-frontend                                 # GOV.UK Frontend

Shopify Polaris Web Components 那一项不是 npm 安装，附录给的是往 app HTML head 里加 <meta name="shopify-api-key" ...> 和一个指向 Shopify CDN 的 <script>。附录里这一项给出的落地方式和上面那几条 npm install 不是一类，用之前先按附录的写法核对一遍。

另外 §3.F 有一条强制要求配套：引入任何第三方库之前先查 package.json，包不存在就先输出安装命令，原文是 Never assume a library exists。这条和 §2.A 是一对——表告诉模型该用哪个包，§3.F 负责让它别假装那个包已经在了。

七、一处可核实的落差

§12.D 给了一条命名约定：依赖 §2.A 某个设计系统的 block，文件要放在 blocks/<category>/<name>--<system>.md，例子是 feature/bento-grid--material.md。也就是说 §2.A 的设计系统选择在 block 层还有一层延伸。

我们实读仓库，skills/taste-skill/ 目录下目前只有 SKILL.md 一个文件，§12.A 描述的那棵 blocks/ 目录树在当前仓库里并不存在。§12 自己写的状态是 “schema defined here. Blocks will be added iteratively.”。两处放在一起看就是这个状态：命名约定已经写下，目录尚未出现。以仓库当前状态为准。

八、什么时候不该照这张表走

最后给一组反向判断，这些场景下这张表对你没用，甚至有害：

你的项目已经有设计系统了。 这张表解决的是「从零起一个页面时选什么」，不是「把现有项目迁走」。One system per project 这条反过来也成立。
你不能新增依赖。 内网、受限构建环境、包体积有硬预算的场景，Honesty rule 那句「就安装并使用官方包」直接执行不了。这时候诚实的做法是在需求里写清约束，而不是让模型偷偷手抄 CSS 还声称用了 Fluent。
你要的只是「像」而不是「是」。 比如做一个介绍页，想要 GitHub 那种视觉调性但完全不需要 Primer 的组件行为。skill 对这种情况的分类其实在 §2.B——那是审美，不是体系，走的是另一条诚实标注的路子。
默认 skill 的适用范围本来就是窄的。 开篇引文原文写明：landing page、portfolio、redesign，不是仪表盘、不是数据表、不是多步产品 UI。而表的第一行和第三行恰恰点名了「仪表盘」「企业分析」。这里的口径需要你自己在具体需求上做取舍，skill 没有给出更细的裁决规则。

表里各个官方包有各自的许可与使用条款，请以各自官方文档与 LICENSE 原文为准，本文不解读。

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