如果你最近在关注AI Coding大概率已经刷到过Superpowers和ui-ux-pro-max。前者试图把“想到哪写到哪”的AI编程拉回到更像工程交付的节奏里后者则想解决另一个老问题AI能把页面写出来但不一定写得像一个成熟产品。这篇文章不准备再用“工具很强、流程很酷、装上就起飞”那种方式来介绍它们。我更想做的是把几个真正重要的问题讲清楚这两个Skill分别解决什么问题、官方文档里到底怎么安装和工作的以及如果把它们放进一个真实项目里具体应该怎样用。为了把过程讲具体后文用一个RBAC用户权限系统作为案例来串起整条链路。本文讨论的是单租户后台管理系统里的RBAC不展开ABAC、行级权限、组织继承、多租户隔离这类更复杂的话题。一、Superpowers与ui-ux-pro-max的核心定位的区别在开始实战之前我们必须先分清这两个工具的定位不然很容易用错场景导致效率不升反降。很多人一开始接触这两个Skill都会误以为它们是“增强AI写代码能力”的插件其实不然它们的核心价值在于“补全AI开发的短板”一个补流程一个补设计。1.1 Superpowers面向工程流程的AI开发工作流很多AI编程体验之所以让人又爱又烦本质上不是模型不会写代码而是它太容易过早进入实现阶段。你刚抛出一个需求它就开始生成文件你话还没说完它已经默认做了三层扩展。最后往往是代码写了一大堆却发现偏离了需求或者结构混乱后续无法维护。Superpowers的核心思路正是把这种“先写再说”的节奏改造成一套更接近工程实践的工作流。它并不是单一Skill而是一套围绕软件开发流程组织起来的技能系统从brainstorm、plan到执行、TDD、review、收尾尽量让代理在每个阶段做该做的事不越界、不超前。简单来说Superpowers解决的是“开发过程是否可控”的问题。它就像一个AI开发教练时刻提醒你“先想清楚再动手”避免AI陷入“盲目写代码”的误区让整个开发过程有章法、可追溯、可验收。1.2 ui-ux-pro-max面向前端产出的设计增强能力很多人第一次用AI生成前端页面时都会有一种熟悉的感觉布局也有按钮也有表格也有生了一堆组件但页面往往停留在“摆上去”的层面缺少真正的设计判断比如配色节奏、版式层级、字号体系、交互一致性。明明是一个后台管理系统却写出了五花八门的按钮样式导航栏对齐混乱不同页面的字体大小不一样完全没有产品感。ui-ux-pro-max官方README对它的定位是一个为多平台AI coding assistant提供design intelligence的Skill。它不是一个UI组件库也不是设计工具而更像一个给模型补设计经验的知识层。当你让AI生成前端页面时它会自动给模型提供设计建议比如配色方案、字体选择、布局规范等让生成的页面更统一、更成熟符合真实产品的设计标准。简单来说ui-ux-pro-max解决的是“前端结果是否足够成熟”的问题它不帮你写页面逻辑只帮你把页面“美化”得更像一个正经产品而不是一个临时拼凑的原型。1.3 两者的互补关系与使用场景划分理解了两者的定位就很容易分清它们的互补关系Superpowers管“过程”确保开发不跑偏ui-ux-pro-max管“结果”确保前端不粗糙。实践中最常见的用法是先用Superpowers把任务拆清楚、推到后端骨架就位再用ui-ux-pro-max进入前端阶段两个工具的切换点非常自然。我们可以更清晰地划分它们的适用场景避免用错地方反而浪费时间。Superpowers适合的场景中大型功能开发一次对话内完成不了的任务任务同时涉及后端建模、接口、前端、测试的多模块联动需要跨session持续推进上下文断了也要能继续推进的任务需要可审计、可复盘的交付结果比如需要向团队展示开发过程和验收标准Superpowers不容易起效的场景修一个很小的bug、一次性脚本、快速验证原型的任务尚在探索方向、需求本身就不收敛的创意型工作ui-ux-pro-max适合的场景页面目标和组件库已经确定你需要的是更统一、更成熟的设计产出技术栈比较主流比如React、Next.js、Tailwind等ui-ux-pro-max不适合的场景尚在探索风格方向、仓库本身设计不统一或项目组件混乱的情况二、工具安装与基础验证避开那些“装了用不了”的坑很多人看完工具介绍立刻就去安装结果发现装完用不了最后归咎于工具不好用。其实大部分问题都出在“没满足前置条件”或“安装步骤错了”。下面我们严格按照官方文档一步步完成安装和基础验证确保后续实战能顺利推进。2.1 Superpowers安装分平台操作别盲目复制命令官方README先强调不同平台的安装方式并不一样。Claude Code和Cursor这类带插件市场的环境装法比较直接Codex、OpenCode这类环境则需要走手动安装说明。我们这里以最常用的Claude Code为例介绍两种最稳定的安装方式大家可以根据自己的情况选择。方式一Claude Code官方Marketplace安装最推荐最稳定/plugininstallsuperpowersclaude-plugins-official方式二通过Superpowers Marketplace安装适用于官方Marketplace找不到的情况/plugin marketplaceaddobra/superpowers-marketplace /plugininstallsuperpowerssuperpowers-marketplace安装完成后输入“/superpowers”如果能看到相关的命令列表比如brainstorm、writing-plans等就说明安装成功了。2.2 ui-ux-pro-max安装必看前置条件ui-ux-pro-max有一个硬性前置条件必须安装Python 3.x因为它的搜索脚本依赖Python运行。很多人跳过这一步导致安装后无法激活浪费了大量时间。第一步检查本地是否已安装Python 3.xpython3--version如果输出Python 3.x.x比如3.8.0及以上就说明满足条件如果没有安装按以下方式安装以macOS为例brewinstallpython3第二步在Claude Code中安装ui-ux-pro-max/plugin marketplaceaddnextlevelbuilder/ui-ux-pro-max-skill /plugininstallui-ux-pro-maxui-ux-pro-max-skill安装完成后输入“/ui-ux-pro-max”如果能看到设计相关的命令提示就说明安装成功了。这里提醒一句这一步最好别省。很多“装了但是不好使”的问题最后往往不是Skill本身的问题而是本地依赖没有满足。三、官方工作流概览摸清AI开发的“节奏”安装完成后我们先别急着上手实战先摸清Superpowers和ui-ux-pro-max的官方工作流知道每个阶段该做什么不该做什么避免在实战中打乱节奏。3.1 Superpowers的核心工作流从 brainstorm到收尾的完整链路按照官方READMESuperpowers的基本工作流如下每一步都有明确的目标和产出不能跳过任何一步否则很容易回到“盲目写代码”的老路子。brainstorming using-git-worktrees writing-plans subagent-driven-development 或 executing-plans test-driven-development requesting-code-review / review 相关环节 finishing-a-development-branch我们把这个流程拆解成四个核心阶段用通俗的话讲清楚每个阶段的作用。3.1.1 需求澄清brainstorming阶段这个阶段不是“礼貌地追问几句”而是把模糊需求转成一个能继续往下推的设计起点。最关键的产物不是聊天记录而是后续会被固化下来的设计判断。比如你说“我要做一个权限系统”AI会追问你“权限粒度到页面、按钮还是接口”“是否需要超级管理员绕过权限”等问题把模糊的需求变得具体、可落地。这个阶段的核心是“问清楚”而不是“写代码”避免后续做无用功。3.1.2 方案收敛与计划拆分writing-plans阶段需求澄清完成后就需要让AI把任务拆成一组可以逐步完成、逐步验收的动作。官方文档里一直强调plan的粒度要小就是为了让长任务不会因为上下文膨胀而失控。比如“实现权限系统”这个大任务要拆成“数据库Schema设计”“后端鉴权模块开发”“前端登录页面开发”等小步骤每个步骤都有明确的交付物和验收标准。这个阶段的核心是“拆清楚”让每个步骤都可执行、可验收。3.1.3 执行阶段的约束机制executing-plans等阶段有了计划就需要严格按照计划执行但AI很容易“放飞自我”写着写着就偏离了计划或者忽略了测试和review。Superpowers想做的是让执行阶段继续受到测试、review和阶段性检查的约束而不是有了计划也照样一口气往前冲。比如在开发后端接口时AI会先写测试用例再写接口代码确保接口符合预期每完成一个步骤都会输出验收方法让你确认无误后再进入下一个步骤。这个阶段的核心是“控节奏”确保执行不跑偏。3.1.4 收尾与交付finishing-a-development-branch阶段很多AI生成代码的问题不在生成时而在收尾时没确认测试结果没做回归也没有明确说明当前分支该如何处置。Superpowers的收尾阶段会引导AI完成测试回归、代码review、分支合并建议等操作确保交付的代码是完整、可复用的。这个阶段的核心是“收干净”避免留下烂摊子。3.2 ui-ux-pro-max的工作方式做AI的“设计顾问”和Superpowers的“流程化”不同ui-ux-pro-max的工作方式更“被动”它不会主动引导你做什么而是在你提出UI/UX相关任务时自动激活并提供帮助。简单来说你提出任何UI/UX相关任务Skill在相关平台上自动激活然后识别任务类型检索对应的风格、配色、字体、布局建议再把这些结果提供给模型。它更像“设计顾问”而不是“页面生成器”不会替你写页面逻辑只会帮你优化页面的设计细节让页面更统一、更成熟。比如你让AI生成一个用户管理页面ui-ux-pro-max会自动提醒模型“用深蓝 #1E40AF 作为主色浅灰作为辅色字体用Inter表格带分页和搜索”确保生成的页面符合SaaS后台的设计规范。四、案例选择为什么选RBAC用户权限系统我们之所以选择RBAC用户权限系统作为实战案例是因为它天然有几层结构正好能把Superpowers的长任务工作流和ui-ux-pro-max的前端辅助能力放进同一个案例里观察非常贴近真实开发场景。RBAC系统的核心结构的后端要建模用户、角色、权限接口层要做Guard和装饰器前端要做登录、列表、权限分配、菜单控制交付阶段还要处理联调、初始化数据和容器化启动。每个环节都需要多模块联动而且任务量足够大需要跨session推进正好能发挥Superpowers的优势同时前端页面繁多需要统一的设计风格也能体现ui-ux-pro-max的价值。这里再次明确范围边界本文讨论的是单租户后台管理系统里的RBAC不涉及ABAC、数据行级权限、组织/部门继承、多租户隔离等更复杂的权限模型避免需求过于复杂导致流程失控。五、实战演练用AI开发RBAC用户权限系统接下来我们按照Superpowers的工作流一步步用AI开发RBAC系统同时在前端阶段引入ui-ux-pro-max完整还原AI工程化开发的全流程。每个阶段都提供具体的Prompt、执行过程和验收标准大家可以直接复制使用避开我们踩过的坑。5.1 需求边界澄清先问清楚再动手权限系统最容易出问题的不是CRUD本身而是边界不清时默认做了太多假设。所以第一步不是写代码而是让AI先把问题问完整把需求边界划清楚。这一步看似浪费时间实则能避免后续大量的返工。我们直接使用Superpowers的brainstorm命令引导AI澄清需求边界。Prompt需求边界澄清/superpowers:brainstorm 我要做一个后台管理系统的RBAC权限模块。 后端使用NestJS Prisma PostgreSQL前端使用Next.js 14 Tailwind shadcn/ui。 请不要直接写代码先帮我把边界条件问清楚包括 - 权限粒度到页面、按钮还是接口 - 是否需要super_admin绕过机制 - refreshToken是否落库 - 是否需要审计日志 - 是否涉及组织/部门/租户维度执行这个Prompt后AI会输出一系列追问比如权限粒度需要控制到按钮级吗比如“删除用户”“编辑用户”是两个不同的权限吗super_admin机制是否需要一个超级管理员角色能够绕过所有权限检查直接操作所有功能refreshTokenrefreshToken需要存储到数据库中以便后续追溯和失效管理吗审计日志是否需要记录用户的关键操作比如“删除角色”“分配权限”等操作的日志组织/部门是否需要按部门划分用户权限是否与部门关联我们根据自己的需求逐一回答这些问题比如权限粒度控制到按钮级每个操作增删改查对应一个独立权限。super_admin机制需要超级管理员可以绕过所有权限检查。refreshToken需要落库方便后续失效管理。审计日志本次暂不做后续迭代再添加。组织/部门本次不涉及只做单租户的用户-角色-权限关联。这一步的意义非常大。你以为自己要的是“后台权限控制”模型可能理解成了“完整企业权限平台”你只想做按钮级控制它可能顺手给你加上了租户维度和审计模型。超出范围的内容局部不一定错但大概率不是你当下真正需要的东西后续修改起来会非常麻烦。5.2 Spec设计说明把核心决策固化下来一旦问题问得差不多了需求边界明确了就需要让AI把核心决策收敛成一份设计说明。这份说明是后续开发的“纲领”必须把关键问题说死避免后续开发中出现歧义。一份合格的Spec设计说明必须包含以下内容后端模块怎么拆比如Auth模块、Users模块、Roles模块、Permissions模块的职责划分。权限命名采用什么规范比如“user:create”“user:delete”“role:update”等。前端如何接入权限判断比如通过Hook获取用户权限控制菜单和按钮的显示/隐藏。哪些内容这次明确不做比如审计日志、部门关联等避免AI过度扩展。如果这些东西不先落下来后面生成的Plan再细也只是把一堆摇摆中的决定拆得更碎而已执行起来还是会跑偏。我们可以让AI生成这份Spec设计说明然后根据自己的需求修改完善最终形成一份固定的文档后续所有开发都围绕这份文档展开。5.3 Plan拆分原则小步快跑逐步验收有了Spec设计说明接下来就需要让AI把任务拆分成可执行的Plan。这里的核心原则是不要用“实现用户模块”这种粗粒度的任务名一步里面包含的决策越多执行时越容易发散。我们使用Superpowers的writing-plans命令生成完整的实施计划。Prompt生成实施计划/superpowers:writing-plans 基于刚才对齐的RBAC权限系统需求生成完整实施计划。 要求 - 后端和前端分开规划 - 每个步骤要有明确的交付物和验收标准 - 数据库Schema设计作为独立步骤 - 鉴权模块和业务模块分开 - 前端页面按功能模块拆分一份可执行的Plan应该是这样的结构大家可以直接参考这个模板Phase 1工程底座1.1 初始化monorepoapps/api apps/web交付物monorepo目录结构、package.json配置、turbo.json配置验收标准目录结构正确依赖安装成功turbo命令可正常运行1.2 配置Prisma PostgreSQL交付物prisma.schema文件、数据库连接配置验收标准Prisma可正常连接数据库生成客户端成功1.3 设计并迁移数据库Schema交付物包含用户、角色、权限、用户角色关联、角色权限关联的schema文件迁移脚本验收标准数据库迁移成功生成对应的表结构Phase 2后端核心2.1 实现Auth模块登录/刷新Token交付物登录接口、刷新Token接口、JWT配置验收标准接口可正常调用返回正确的Token和权限列表2.2 实现Users模块CRUD 状态管理交付物用户增删改查接口、用户状态切换接口验收标准接口可正常调用数据操作符合预期2.3 实现Roles模块交付物角色增删改查接口验收标准接口可正常调用角色可关联权限2.4 实现Permissions模块交付物权限增删改查接口验收标准接口可正常调用权限可按模块分组2.5 实现JwtAuthGuard PermissionsGuard交付物两个Guard的实现代码全局配置验收标准未登录用户无法访问受保护接口无权限用户返回4032.6 实现Permissions()装饰器交付物装饰器实现代码接口权限标注示例验收标准可通过装饰器控制接口权限符合预期Phase 3前端核心3.1 初始化Next.js Tailwind shadcn/ui交付物前端项目目录结构、依赖配置、全局样式验收标准项目可正常启动样式配置生效3.2 实现登录页交付物登录页面组件、登录逻辑、表单验证验收标准可正常输入账号密码登录成功后跳转至首页3.3 实现布局和侧边栏权限驱动菜单交付物布局组件、侧边栏组件、权限判断逻辑验收标准菜单根据用户权限动态显示/隐藏布局美观统一3.4 实现用户、角色、权限管理页交付物三个管理页面的组件、接口请求逻辑、表单和表格组件验收标准页面可正常展示数据可执行增删改查操作Phase 4集成与收尾4.1 前后端联调交付物前端API代理配置、axios封装、错误处理逻辑验收标准前端可正常调用后端接口错误处理符合预期4.2 Docker Compose一键启动交付物docker-compose.yaml配置文件、服务启动脚本验收标准执行docker compose up -d可一键启动所有服务4.3 初始化管理员账号与默认权限交付物数据初始化脚本、默认权限列表验收标准执行脚本后可使用默认管理员账号登录这里提醒一句Plan不是项目目录而是执行顺序。进入下一阶段前务必确认当前阶段验收已通过、git commit已提交避免后续出现问题无法回溯。5.4 后端实现阶段用Superpowers控节奏确保可验收Plan确定后就可以进入执行阶段了。后端实现是整个项目的基础我们使用Superpowers的executing-plan命令引导AI按步骤执行并且每一步都输出验收方法确保代码符合预期。Prompt执行后端阶段/superpowers:executing-plan 执行PLAN.md中Phase 1和Phase 2的所有步骤。 每个步骤执行完后输出对应的验收curl命令。 让AI牛马给我冲啊执行这个Prompt后AI会按照Plan的步骤一步步生成代码每个步骤完成后都会输出对应的验收curl命令。我们以几个关键步骤为例展示执行过程和验收标准。比如完成Phase 2.1 Auth模块开发后AI会输出以下验收curl命令# 登录获取Tokencurl-XPOST http://localhost:3002/api/auth/login\-HContent-Type: application/json\-d{email:admintest.com,password:123456}# 获取用户信息 Token应返回200curl-XGET http://localhost:3002/api/auth/profile\-HAuthorization: Bearer$ACCESS_TOKEN# 无权限的Token应返回403不是401curl-XDELETE http://localhost:3002/users/1\-HAuthorization: Bearer limitedToken# super_admin应能访问所有接口curlhttp://localhost:3002/users\-HAuthorization: Bearer superAdminToken我们可以执行这些curl命令验证接口是否符合预期。后端验收的核心标准如下大家可以参考登录成功返回中包含权限列表的Token有权限接口正常返回200无权限接口返回403不是401super_admin跳过权限检查Token过期后refreshToken自动续签在这个阶段我们需要注意几个坑一是AI可能会生成不符合Prisma语法的代码需要我们手动调整二是JWT配置可能存在安全隐患比如过期时间设置不合理需要我们修改三是Guard的全局配置可能遗漏导致权限控制失效。这些问题都需要我们在验收时仔细检查及时修正。5.5 前端实现阶段用ui-ux-pro-max打磨页面提升产品感等后端骨架差不多了我们就可以进入前端实现阶段了。这时你已经知道自己要做哪些页面需要的不再是“帮我想我要做什么”而是“在页面目标已经明确的前提下把它们做得更像一个成熟后台”。这就是ui-ux-pro-max开始发挥其真正价值的时候。我们使用Superpowers的execute-plan命令同时引入ui-ux-pro-max技能生成前端页面。Prompt执行前端阶段/superpowers:execute-plan 执行PLAN.md中Phase 3的所有步骤使用ui-ux-pro-max技能生成前端页面。 设计要求 - 整体风格SaaS后台管理系统Modern Clean - 配色方案参考SaaS行业调色盘主色深蓝#1E40AF辅色浅灰 - 字体Inter 系统字体栈 - 组件库shadcn/ui不自造轮子 - 侧边栏固定宽240px图标 文字菜单根据权限动态渲染 - 表格带分页、搜索、批量操作 - 表单弹窗Drawer风格从右侧滑入不用居中Modal - 权限分配Checkbox树形结构按module分组 页面清单 1. 登录页/login 2. 用户管理/dashboard/users 3. 角色管理/dashboard/roles 4. 权限列表/dashboard/permissions 5. 个人信息/dashboard/profile执行这个Prompt后AI会在生成前端代码的同时结合ui-ux-pro-max的设计建议确保页面的统一性和成熟度。比如登录页会采用深蓝主色表单布局合理按钮样式统一用户管理页面的表格会带分页和搜索弹窗采用Drawer风格符合SaaS后台的设计习惯。这里给大家展示一个前端权限控制的实现示例方便大家参考// hooks/usePermissions.tsexportfunctionusePermissions(){const{user}useAuth();constcan(permission:string)user?.permissions?.includes(permission)??false;return{can};}// 按钮级权限控制{can(user:delete)(Button variantdestructiveonClick{handleDelete}删除用户/Button)}// 路由守卫exportfunctionPermissionGuard({permission,children}){const{can}usePermissions();if(!can(permission))returnNoPermission/;returnchildren;}前端验收的核心清单如下菜单根据权限动态显示/隐藏没权限的页面不允许进入没权限的按钮不展示权限分配界面能正常保存禁用用户无法登录在这个阶段我们需要注意的是ui-ux-pro-max只能优化设计细节不能替代我们做页面逻辑设计。比如页面的路由结构、表单的验证规则、接口的请求逻辑还是需要我们自己明确AI只是在这个基础上优化设计。如果你的项目本身组件体系混乱ui-ux-pro-max的效果也会大打折扣。5.6 集成与交付阶段把散落的零件拼成完整产品很多教程写到前后端页面都出来了就差不多结束了。但真实项目往往恰恰是在集成阶段开始变难前后端联调出错、Docker配置有问题、初始化脚本无法运行等这些都是常见的坑。我们使用Superpowers的execute-plan命令完成集成阶段的所有步骤。Prompt执行集成阶段/superpowers:execute-plan 执行PLAN.md中Phase 4的集成步骤 1. 前后端联调 - 配置Next.js API代理/api/* - http://localhost:3001 - 封装axios实例自动注入Bearer Token处理401自动刷新 - 统一错误处理403跳转无权限页401跳转登录页 2. Docker Compose - postgres服务数据持久化 - api服务NestJS - web服务Next.js - 支持docker compose up -d一键启动 3. 初始化脚本 - 自动创建super_admin角色和初始管理员账号 - 自动写入所有权限枚举到数据库 完成后输出完整的README包含本地启动步骤。集成阶段的验收清单如下大家可以逐一验证# 一键启动dockercompose up-d# 初始化数据运行一次dockercomposeexecapi npx ts-node src/scripts/seed.ts# 验证协调前端登录后调用后端接口curlhttp://localhost:3001/users\-HAuthorization: Bearer tokenFromFrontend最终验收标准docker compose up -d一键启动服务全部起来初始化脚本正常写入权限和管理员账号前端登录后Token注入正常接口可访问401/403按预期跳转足够易用无需手动修改配置文件在这个阶段我们遇到的最常见的问题是Docker Compose配置错误比如端口冲突、环境变量设置不当导致服务无法启动还有就是前后端接口地址不一致导致前端无法调用后端接口。这些问题都需要我们仔细检查配置文件逐一排查。六、适用场景与现实限制理性看待AI工具的价值通过上面的实战我们已经掌握了Superpowers和ui-ux-pro-max的使用方法但这并不意味着它们适用于所有场景。我们需要理性看待它们的价值明确它们的适用范围和现实限制避免盲目使用。6.1 真正适合它们的场景中大型功能开发不是几个小修小补而是会牵涉模型、接口、页面、测试的完整模块。多模块联动任务前后端、交互、鉴权、配置、联调需要协同推进的任务。需要跨session续做的任务一次对话干不完后面还要继续接着做的长任务。需要复盘与审计的交付你希望知道设计是怎么定的、每一步做到哪了、为什么这样做的任务。6.2 不适合全流程的场景修一个很小的bug比如修改一个接口的返回值用Superpowers反而浪费时间。一次性脚本比如写一个数据导出脚本不需要流程化直接写代码更高效。快速验证想法的原型比如快速做一个页面原型不需要成熟的设计和流程直接生成即可。本来就需要边做边改方向的创意型任务这类任务需求本身就不稳定流程化反而会限制创意。一句话说就是小任务轻流程大任务重流程。AI工具的价值在于提升效率而不是增加负担。6.3 现实限制AI不是万能的我们在实战中也发现了很多AI工具的局限性大家需要有心理预期不要指望AI能替你完成所有工作。Spec/Plan确实会带来前置成本如果任务本来就很小前面花十几分钟对齐、落文档、拆计划可能真的不划算。TDD会让AI显得更慢它的好处是结果更可验证但代价就是执行节奏不会像“直接写一版能跑的代码”那么快。ui-ux-pro-max的效果依赖代码基线如果你的仓库本身组件体系混乱、设计token失控、页面结构脏乱那它的上限也会被拉低。人工决策依旧不可替代Skill能加强执行但不能替你决定哪些复杂度该引入、哪些边界这次先不做、什么时候追求速度还是追求稳定。七、总结AI工程化开发的核心是“可控”与“成熟”Superpowers和ui-ux-pro-max的真正价值不在于它们能把AI变成“全自动高级工程师”而在于它们分别补上了两个最常见的缺口一个补流程一个补设计。前者让任务不那么容易一路失控后者让前端结果不那么容易停留在“有组件但没产品感”的层面。它们不是所有项目都需要的东西也不是装完就一定立刻见效的东西。你还是得判断任务值不值得走完整流程还是得亲自做关键决策还是得面对代码基线、团队习惯和项目复杂度这些很现实的问题。最后别只停留在“看”的层面亲自去试一试。这是一个新的世界尽力去拥抱别被甩开。Superpowers适合把大任务拉回工程轨道ui-ux-pro-max适合把前端结果拉回产品语境。它们真正有用的时候通常不是在“随便试试”的那一刻而是在你开始认真交付一个项目的时候。附跑通这套流程你还需要一个顺手的模型接入层用Superpowers推进大任务、用ui-ux-pro-max打磨前端本质上都是在让模型做更多事。做得越多Token消耗越真实模型选型的代价也越具体。用Claude Code跑完一个RBAC项目的完整流程从brainstorm到集成交付实际花费可能远超你的预期——尤其是在subagent并行、多轮review、TDD来回循环的场景下。这时候你会开始真正关心几个问题这个阶段该用旗舰模型还是可以切小模型缓存命中率到底有多少前缀是否稳定每一步的输入输出Token分别是多少优化前后差多少