ARTICLE · 1058599
B端AI设计 | 面向产品团队的 Design Skill,应该怎么设计
马上中秋节了，预祝大家中秋快乐，今天分享一期Skill应用干货~
前段时间，一位朋友来找我聊。他们的产品负责人想直接使用现有的设计 Skill：输入一个业务场景，让 AI 先生成 demo 初稿，再由团队一起讨论。
这让我想起之前写过的几篇 B 端 AI 设计 Skill 文章：
这些文章里的 Skill，主要使用者还是设计师：帮设计师更快出图、更快统一规范、更快复用组件。
但如果再往前走一步呢？
产品经理能不能直接使用 Skill？如果可以，这个 Skill 应该怎么做？
这是两个不同层面的问题。
面向设计师的 Skill，核心是组件和规范的复用；
面向产品团队的 Skill，核心是输入业务场景，生成一个能讲清楚业务的 demo，并继续推动后续工作。
后者需要的不只是组件，还需要业务知识、页面骨架、执行计划和生成规则。
于是，我把之前分享过的 BAUX 设计 Skill 从 v0.3 升级到了 v0.6，
并重新验证了三个问题：
Skill 应该面向谁、里面应该装什么，以及怎么判断它真的能用。
最后，我把它总结成一个公式：
设计资产库 + 业务知识库 + 页面模板库 + 生成规则 = 产品团队可调用的设计 Skill
下面完整梳理这次实践~
01
面向产品团队的 Skill，目标不一样
之前的 BAUX Skill v0.3，服务的是“AI 如何生成一个好的 B 端界面”。
但产品团队的工作不会在“生成一个页面”之后结束。一个更完整的产品工作流通常是：
用 AI 生成原型，快速看见方案；
团队讨论并确认原型方向；
从确认后的原型反向生成 PRD，交付开发。
在这条链路里，“生成页面”只是第一项产出。
如果 Skill 只负责页面怎么组织，产品经理仍然要自己定义字段、梳理状态机、划分权限矩阵、判断哪些操作需要二次确认，再从头写一份 PRD。
看起来 AI 已经“生成”了，实际上并没有真正参与产品工作。
所以 v0.5 的目标很明确：
Skill 要从“约束 AI 的生成质量”，升级为“驱动 AI 完成一段产品工作流”。
它面向的不再只是 AI 设计工具，而是使用 AI 工具的产品团队。
02
Skill 里面应该装什么
在这次升级里，我把 Skill 的内容分成了四类。
第一类：设计规则
这是 Skill 的基本盘，主要包括：
patterns/ 告诉AI 页面怎么组织principles/ 告诉AI 什么能做什么不能做components/ 告诉 AI 每个组件怎么用
例如：客户列表页由哪六个区域组成、AI Trust 的三条原则、四种空状态分别适用于什么场景。
这些规则能让 AI 生成的不只是“能运行的页面”，而是一个在结构、交互和视觉上都更像真实产品的页面。
第二类：流程工具
这是 v0.4 新增的能力：
prompts/generate-prd.md是一份反向生成 PRD 的指令templates/prd-template.md是 PRD 的固定结构模板
有了这两个文件，AI 在生成原型后，可以继续输出一份 PRD 初稿，并使用 [来自 Skill] 和 [待补填] 标注信息来源。
但实测后出现了一个明显问题：
字段定义、状态枚举、权限矩阵等业务级内容，几乎全部是 [待补填]。
原因：AI 知道页面怎么画，却不知道采购订单有哪些字段、审批状态如何流转，也不知道哪些操作不可逆。
这就引出了第三类内容。
第三类：业务域知识
这是 v0.5 新增的核心能力。
例如，domains/procurement.md 是采购域的完整知识库，包含：
字段字典：16 个字段，以及每个字段的类型、校验规则和显示格式；
状态枚举：草稿、待审批、已完成、已驳回，以及完整的状态流转规则；
角色权限矩阵：4 个角色、13 项操作的授权关系；
Human Review 分级：每项操作属于 Reversible 还是 Irreversible；
AI 能力边界：AI 可以做什么，以及绝对不能做什么。
有了业务域文件，AI 在生成采购类页面时，不仅知道“页面怎么组织”，还知道“页面里应该填什么”。
反向生成 PRD 时，字段定义、状态枚举、权限矩阵和高风险操作也可以直接引用域知识，做到“零推断生成”。
第四类：执行规划
这次补充的另一项关键能力，是让 Skill 强制执行“先规划，再生成”。
这条规则直接写进 SKILL.md：
AI 每次拿到需求后，不能马上开始画页面，而要先识别业务域、任务类型和预期交付物，再生成一份简短的行动计划。
例如，一个采购订单列表页的行动计划可能是：
判断任务属于采购业务域；
读取
domains/procurement.md；匹配列表页对应的
patterns/；按需读取组件和设计原则；
生成页面，并检查字段、状态、权限和高风险操作；
输出原型及待确认项。
为什么要增加这一步？
因为“文件放在 Skill 里”，不等于“AI 一定会完整使用”。先规划，相当于在执行前增加一道检查：这次要读什么、按什么顺序做、最终交付什么，都先明确下来。
四类内容的关系可以概括为：
设计规则告诉 AI“怎么做”，
业务域知识告诉 AI“填什么”，
流程工具告诉 AI“做完后怎么交付”，
执行规划保证 AI“按正确顺序完成”。
03
案例实践：一次采购订单的完整测试
下面用采购订单管理页，看看 BAUX Skill 从 v0.3 到 v0.5 的变化。
v0.3：页面像产品，但业务内容是猜的
v0.3 已经可以生成一个像样的采购列表页：页面标题栏、搜索筛选区、数据表格、分页、批量操作条、AI Copilot Sidebar，六个区域完整，布局和视觉也比较专业。
但仔细看表格，就会发现字段名称、状态值和金额格式，都是 AI 根据常识猜出来的，而不是采购业务里的真实定义。
v0.4：反向生成 PRD，问题被进一步放大
使用 prompts/generate-prd.md 反向生成 PRD 后，“字段定义”“状态枚举”“权限与隔离”“高风险操作”等章节全部显示为 [待补填]。
这不是 PRD 模板的问题，而是 Skill 里没有业务知识。
AI 知道采购订单页面应该有表格，却不知道：
采购订单编号的格式是 PO-YYYYMM-NNNN；状态如何从草稿流转到待审批、已完成或已驳回；采购专员只能查看自己的订单，采购主管可以查看部门全量；哪些操作可以撤销，哪些操作必须弹出二次确认。
v0.5：把采购业务装进 domains/
于是，我创建了 domains/procurement.md，把采购域知识系统化地装进 Skill。
这个文件共 10 个章节，核心内容包括：
字段字典,共 16 个字段，每个字段都有类型、校验规则和显示格式。
例如：po_number使用 PO-YYYYMM-NNNN格式；amount使用千分位并保留两位小数；category包含 8 个固定枚举值。
状态枚举
定义草稿、待审批、已完成、已驳回四种状态，以及完整的流转规则和颜色编码：草稿为灰色、待审批为橙色、已完成为绿色、已驳回为红色。
角色权限矩阵
覆盖采购专员、采购主管、财务管理员和系统管理员四类角色，以及 13 项操作的完整授权关系。
Human Review 分级
明确每项操作属于 Reversible 还是 Irreversible：
可逆操作使用 Toast 反馈；
不可逆操作必须使用 Confirm Dialog，并提供对应弹窗模板。
AI 能力边界
定义 5 项 AI 可以执行的能力，并要求提供 Confidence 和 Citation；同时明确 6 项禁止事项，例如 AI 不能代替用户审批、不能修改核心字段、不能直接发送外部通知。
补齐这些内容之后，再重新执行“规划—生成—确认—交付”的完整流程，看看结果是否真正可用。
04
怎么应用这个skill
整个流程可以分为四步：先规划、再生成、团队确认、反向生成 PRD。
Step 1：生成行动计划
把需求交给 AI 后，Skill 不会立刻开始画页面，而是先输出本次任务的行动计划。
AI 会先判断：
这是什么业务场景，是否存在对应的 domains/文件；要生成什么页面，应该匹配哪个 patterns/；需要调用哪些组件和设计原则；页面涉及哪些字段、状态、角色权限和高风险操作；本次需要交付原型、PRD，还是两者都要；哪些信息已经有明确依据，哪些信息仍需产品经理确认。
计划明确后，AI 才按照顺序读取相关文件并开始执行。
Step 2：生成原型
把 Skill 文件夹加载到 Cursor、Claude Code、v0 等 AI 工具中，然后输入要解决的业务问题。
AI 会根据行动计划读取 SKILL.md、对应的业务域文件、页面 Pattern，以及需要的组件和设计原则，最后生成页面。
Step 3：团队确认原型
这一步由人完成。
团队一起查看 AI 生成的原型，确认页面布局、业务字段、状态展示和交互方向是否合理。这个阶段不需要先写完整代码，重点是借助可视化原型快速暴露分歧并达成共识。
Step 4：反向生成 PRD
原型确认后，告诉 AI：“根据这个原型生成 PRD。”
AI 会加载 prompts/generate-prd.md 和 templates/prd-template.md，从确认后的原型与业务域知识中提取内容，输出带来源标注的 PRD 初稿。
如果已经存在对应的 domains/ 文件，字段定义、状态枚举、权限矩阵和高风险操作等章节会被直接填充，并标注为 [来自 Skill]；缺少明确依据的部分则标注为 [待补填]，交给产品经理确认和补充。
四步走下来，产品经理得到的不只是“一个页面”，而是一份可检查的行动计划、一个经过团队确认的原型，以及一份有业务依据的 PRD 初稿。
05
复盘与分享
从 v0.3 到 v0.5，表面上是在 Skill 里增加了业务域文件和行动计划，实际验证的是一件事：
一个 Skill 怎样才能从“生成工具”变成产品团队真正可用的工作方式？
完整跑完采购订单案例后，整理复盘如下：
一：Skill 的价值不在“能生成”，而在“生成得对”
没有 Skill，AI 一样可以生成采购列表页，而且第一眼看上去可能还不错：页面完整、组件齐全、视觉也像一个 B 端产品。
但继续往下看，问题就会暴露出来：字段是猜的、状态是泛化的、权限没有定义，高风险操作也没有对应的确认机制。
所以，判断一个 Skill 是否有效，不能只看它有没有产出，而要看产出是否符合团队已有的设计规范和业务规则。
从“能跑”到“能用”，中间差的不是生成能力，而是正确性。
二：业务域知识决定了 Skill 能不能真正落地
设计规则解决的是“页面怎么组织”，这部分相对通用；业务域知识解决的是“页面里应该填什么”，这部分无法靠通用规则代替。
采购有采购的字段、状态和权限，CRM 有 CRM 的客户阶段和跟进规则，进销存与人力资源也有各自的业务对象和操作边界。
如果缺少这一层，AI 可以生成一个形式完整的页面，却无法保证页面承载的业务是正确的；它也可以生成一份结构完整的 PRD，但其中最关键的业务章节仍然只能留给产品经理从头补写。
因此，domains/ 不是 Skill 的补充材料，而是它从设计辅助工具走向产品工作流的最后一公里。
三：先规划、再执行，Skill 才能稳定发挥作用
知识放进 Skill，只代表 AI“可以读取”，并不代表它每次都会读，也不代表它会按正确的顺序使用。
行动计划的作用，是让 AI 在动手之前先回答几个问题：这是什么业务域？需要读取哪些规则？最终要交付什么？有哪些内容需要重点检查？
这样做有两个直接价值：一是减少漏读业务知识和设计规则；二是让产品经理在生成开始前，就能发现 AI 是否理解错了任务。
所以，规划不是额外增加的一道形式，而是把 Skill 从“一个知识文件夹”变成“一套可执行、可检查的工作流程”。
四：“零推断”不是不要人，而是让人专注于判断
产品团队真正担心的，不只是 PRD 里出现大量 [待补填]，还有 AI 在缺少依据时自行补全，并把推测写得像确定事实。
更可靠的方式是：有明确依据的内容直接生成，并标注来源；没有依据的内容明确暴露出来，交给产品经理补充和确认。
这里说的“零推断”，并不是要求 AI 什么都不做，也不是要把人移出流程，而是让 AI 不替团队编造业务规则。
人的角色也因此发生变化：不再从空白文档开始整理信息，而是把精力放在检查、确认和关键决策上。
五：AI Trust 必须进入业务规则，而不是停留在原则层
“重要操作需要人工确认”“AI 不能越权执行”，这些原则本身没有问题。但如果只写在通用原则文件里，它们很难真正影响具体页面。
在 procurement.md 中，我把 Human Review 分级和 AI 能力边界落实到了每一项业务操作。例如，审批通过属于不可逆操作，必须使用 Confirm Dialog；AI 可以给出建议，但不能代替用户完成审批。
到了这一层，AI Trust 才不再是一句抽象口号，而是可以直接决定按钮权限、交互反馈和操作流程的业务规则。
原则只有和业务对象、角色权限及具体操作绑定，才能真正进入产品。
写在最后
BAUX Skill 的核心叙事一直没有变：
shadcn 让 AI 能生成界面，BAUX Skill 让 AI 生成“正确”的界面。
到了 v0.6，“正确”又多了一层含义：不仅是布局正确、交互正确，还要做到业务正确、过程可检查、结果可追溯。
它不会替代产品经理和设计师的判断，但会让 AI 的输出更接近团队真正需要的结果，也让人的精力从重复整理信息，转移到确认方向和做关键决策上。
更完整的流程可能是这样：
后续版本还会继续加入详情页 Pattern、Agent 工作台、Chat Workspace 全屏形态，以及更多业务域的 domain 文件。
如果你的团队也在用 AI 做 B 端产品设计，欢迎交流～