从一句话需求到可交互草图，我用 AI 设计了一个团队组件共享平台

记录一次 AI 辅助产品设计和原型搭建的过程。从一句模糊需求，到能点起来的草图，我基本都在和 Qoder AI 来回协作。

背景

我们团队有个老问题，一直没彻底解决：组件会被重复造。

A 同学写了一个还不错的表格，B 同学没看到，又自己写了一份。C 同学想找个富文本组件，翻了半天仓库，最后还是从头开干。类似的事不是偶尔发生，是经常发生。

Element Plus、Ant Design Vue 这些开源库当然很好用，但它们解决不了团队内部那批业务组件的问题。很多组件其实是跟公司业务绑在一起的，离开上下文就没意义，也不适合往外开源。

所以我动了一个念头：做一个 npx uikit 工具链，让团队内部的组件也能像 npm 包一样被发现、安装、复用。

这篇文章写的不是最终实现，而是前面的产品设计阶段。我想记录一下，AI 在这一步里到底帮了我什么，哪些地方真省时间，哪些地方还是得自己来。

先看效果

第一轮：先把脑子里的东西说清楚

我一开始给 AI 的需求，其实挺糊的：

"我这个项目计划开发一个 npx uikit 的工具链，作用是用户上传组件，或者下载组件，在一个团队内部好使用，技术栈明确 Vue 3 和 Vite，你帮我整理下思路"

我原本以为它会直接开始写命令或者搭目录，结果没有。它先做的是把这个东西拆开，整理成一套我能继续判断的结构。

它先给了一个三层架构：

text 复制代码

┌─────────────────────────────────────────┐
│           CLI 层 (npx uikit)            │
│  init / add / publish / search / list   │
├─────────────────────────────────────────┤
│         服务端 (Registry API)           │
│  组件存储 / 版本管理 / 团队鉴权 / 搜索   │
├─────────────────────────────────────────┤
│              存储层                     │
│         组件包文件 + 元数据             │
└─────────────────────────────────────────┘

这个结构不算惊艳，但很有用。因为我脑子里原本是一团东西，AI 至少先帮我把问题切开了：CLI 做什么，服务端做什么，底层存什么。

除了这个，它还顺手补了一些我当时没展开的东西：

一套比较完整的 CLI 命令表
组件目录规范，比如 __preview__.vue
几种存储方案的对比
Monorepo 的 package 拆分建议
一个三阶段开发路线

说实话，这一步最有价值的不是"答案有多高级"，而是我不用从白纸开始整理了。它先给了一个能讨论的版本。

第二轮：我只补了一句"还有组件预览"

接下来我补了一句：

"还有组件预览"

我当时只是想把这个功能加进去，没想太多。结果 AI 倒是把这件事看得挺重，它直接把"预览"当成了平台体验里最关键的一环。

它给了三个预览场景：

场景	命令	说明
本地开发预览	`npx uikit dev`	开发时实时热更新
选择下载预览	`npx uikit preview <name>`	下载前先看效果
已安装组件预览	`npx uikit preview`	查看本地已有组件

然后继续往下延伸到技术实现：

每个组件约定 __preview__.vue 作为 Demo 入口
CLI 动态生成 Vite 入口
用 Vite 插件注入虚拟模块
用 vue-compiler-sfc 解析 defineProps
远程预览时把组件拉到临时目录，渲染完再清理

这一轮让我印象挺深的。因为我只是补了四个字，它却把一整套预览机制顺着补出来了。后来我回头看，这部分确实是对的。如果一个团队组件平台连预览都做不好，那基本很难用起来。

它还顺手建议我拆一个 packages/preview/，专门处理预览应用。这个点我当时没有想到，但接受起来也很自然。

第三轮：让 AI 主动补功能

接着我问了它一句：

"你觉得还有其他功能要扩展吗？"

这次我主要想看它会不会提到一些我没想到、但团队里真会用到的东西。

结果还不错。它给了一份按实用价值排序的功能清单。

我比较认同的几项是：

npx uikit create 给新人一个标准组件模板，省得每个人起手都不一样。
npx uikit lint 发布前先检查结构、类型、预览文件这些基础项，少一点低级问题。
npx uikit update 组件升级时至少知道有哪些版本变化，不然组件装进项目后就跟失联一样。
Design Tokens 共享这个其实很关键。很多团队组件看起来像"功能重复"，本质是样式体系没统一。

另外还有两个我觉得挺实在的：

使用统计
废弃标记

尤其是"使用统计"这个点，我之前真没想到。但它对应的是个很现实的问题：一个组件如果长期没人用，到底能不能删？如果没有数据，最后通常谁都不敢动。

最后整理出来的命令表，大概是这样：

bash 复制代码

npx uikit init        # 初始化配置
npx uikit create      # 创建组件模板
npx uikit dev         # 本地开发预览
npx uikit preview     # 远程组件预览
npx uikit lint        # 规范校验
npx uikit publish     # 上传组件
npx uikit add         # 下载组件
npx uikit list        # 列出组件
npx uikit search      # 搜索组件
npx uikit outdated    # 检查过时组件
npx uikit update      # 更新组件
npx uikit stats       # 使用统计
npx uikit deprecate   # 废弃标记
npx uikit remove      # 移除组件

到这里为止，事情还停留在"一个像样的 CLI 工具"。

但后面我自己把方向改了。

第四轮：从 CLI 转到可视化平台

我后面跟 AI 说：

"我想做成可视化操作的"

这句话其实等于把前面的设定推翻了一半。

因为一旦从纯 CLI 转成 Web 平台为主，很多设计都要重来。CLI 不再是主角，它更像一个本地执行器，或者说一个桥。

AI 这次的反应倒挺快，马上把结构重新整理成了"Web 为主，CLI 辅助"的模式。里面我最喜欢的设计，是这个 Web 和 CLI 的配合方式：

text 复制代码

浏览器（Web 平台）  ←→  WebSocket  ←→  CLI（本地后台）
    点击"安装"                              写入本地文件

这个思路一下就把很多体验问题解决了。

开发者在项目目录里跑一个 npx uikit link，让 CLI 进入监听状态。之后浏览器里看到某个组件，点"安装到项目"，本地就直接完成写文件、装依赖、回传结果。这样既保留了 Web 的可视化操作，又没有失去 CLI 对本地工程的控制能力。

我觉得这一步算是整个设计过程里真正"拐弯"的地方。因为它不只是多了个页面，而是把平台的使用方式彻底改了。

项目结构也跟着扩了一轮：

text 复制代码

pm-uikit/
├── packages/
│   ├── cli/              # CLI 工具，负责 link / ws-server
│   ├── web/              # Web 平台
│   │   ├── pages/        # 组件市场 / 详情 / 上传 / 管理 / 个人中心
│   │   └── components/   # LivePreview / PropsPanel / EventsPanel
│   ├── server/           # Registry API
│   ├── preview-renderer/ # 在线预览沙箱
│   └── shared/           # 共享类型

这个时候我已经不太把它当成"命令行工具"了，更像一个完整的团队组件平台。

第五轮：直接让它先出草图

再往后，我就不想只聊结构了。

我直接说：

"你先生成一个草图，我瞄下"

这是最直观的一轮。前面那些讨论再完整，脑子里终究还是抽象的。只要一出图，很多事马上就有感觉了。

AI 先给了一套视觉方向：

深色系
紫色主色
界面字体用 Inter
代码区用 JetBrains Mono
带一点渐变、阴影和毛玻璃

这套风格不算特别新，但放在开发者工具产品里是成立的。至少不会跑偏。

然后它用 React + Vite + Tailwind CSS 生成了一版原型，里面有四个主要页面。

1. 组件市场首页

首页做得比较完整，有这些元素：

顶部横幅
四张统计卡片
左侧分类栏
组件卡片网格

卡片里放了预览区、版本号、标签、作者、下载量和安装按钮。老实说，这一页看完我就大概知道产品会长什么样了。很多想法放在脑子里时觉得挺对，真摆到页面上就未必。首页帮我过滤掉了一部分空想。

2. 组件详情页

这个页面应该会是平台里最常用的页面，所以我看得比较仔细。

它给了四个 Tab：

预览
源码
API
更新日志

右侧还放了一个 Props 调试台，可以切 type、切 size，控制 disabled 和 loading，下面实时生成用法代码。

这一块我觉得挺对路。团队里很多人并不是不想复用组件，而是不想读文档。你如果能让他在页面上点两下，把参数调出来，再顺手复制一段可用代码，复用率会高很多。

3. 上传组件

上传页被做成了三步：

拖拽上传文件
填组件信息
发布成功

这种流程没什么惊喜，但够用。重点是把规范检查结果也放进去了，这一点挺重要。因为平台越往后走，真正麻烦的不是"传不上来"，而是"传上来的东西都不统一"。

4. 个人中心

个人中心放了发布数、下载量、收藏这些统计，还做了已发布、已收藏、使用统计几个 Tab。

这部分我一开始其实没太在意，但后来想想也合理。团队平台如果完全没有"作者视角"，组件维护这件事会很抽象。至少得让发布者知道自己的组件有没有被用，有没有继续维护的价值。

这次协作里，AI 到底帮了什么

写到这里，我反而更想说点没那么"标准答案"的感受。

AI 在这次设计里，最有帮助的地方，不是它有多懂产品，而是它能持续把一个模糊想法往前推。

有几件事它确实做得不错。

1. 它很适合接住模糊需求

我一开始给的东西真的很散。

如果让我自己从零整理，可能得先列文档、画结构、再补命令表，前后要磨挺久。

AI 的好处是，它先给你一个并不完美、但足够能讨论的版本。这个动作很省时间。

2. 它会顺着一个点往下补

我只说了"还有组件预览"，它就把预览场景、Demo 入口、技术实现、目录调整都补出来了。

这不是说它一定全对，而是它会帮你把一个点展开。产品设计前期，这种能力很有用，因为你最怕的是思路断掉。

3. 它能暴露你没想到的功能

像使用统计、废弃标记这些，不算特别高级，但很接地气。

如果没有人提醒，很多时候前期真想不到。等平台做起来了才发现缺，那就晚了。

4. 它出草图很快

这一点不用多说。以前从"脑子里有个轮廓"到"眼前有个可点的东西"，中间要过原型图、设计稿、前端搭壳这些环节。现在你可以先把草图拉出来，哪怕它不是最终设计，也足够拿来判断方向。

但有些事，AI 还是替不了

当然也别把它想得太万能。

这次我能明显感觉到，下面这些事还是得自己判断。

1. 它不知道你团队的真实约束

比如：

公司现在用的是什么 Git 流程
能不能上私有 npm
是否允许额外跑一个服务端
团队到底有几个人会长期维护这套东西

这些信息不告诉它，它就只能按常见方案回答。常见方案不一定错，但不一定适合你。

2. 草图离产品还很远

草图解决的是"看起来像不像那么回事"，不是"这个东西能不能真跑起来"。

CLI 的跨平台兼容、WebSocket 的稳定性、在线预览沙箱的安全隔离，这些都还是实打实的工程问题，不会因为页面长得好看就自动解决。

3. 最终拍板还是得靠人

是走 Git 仓库模式，还是私有 npm？

要不要先上服务端？

第一版到底是给 5 个人用，还是给整个前端组用？

这些决定，AI 最多给选项，拍板的人还是你。

接下来我准备怎么做

草图出来之后，方向基本算是立住了。后面就不是继续聊想法，而是开始做真正的工程。

我现在给自己拆了三步。

Phase 1：先做 CLI + 本地预览的 MVP

用 Citty 起一个 CLI 骨架
做 create 命令生成组件模板
做 dev 命令跑本地 Vite 预览
先基于 Git 仓库完成 publish 和 add

这一阶段我想先验证最核心的一件事：

团队里的人到底愿不愿意把组件按一套规范发布出来。

Phase 2：补 Web 平台

Vue 3 + Vite 搭前端
H3 提供 Registry API
做 iframe 沙箱预览
接上 WebSocket CLI 联动

如果第一阶段没人用，那第二阶段其实也不用急着做太满。

Phase 3：补完整治理能力

Design Tokens
使用统计
废弃管理
团队权限

这部分更像"平台化"能力，不是第一天就必须有，但迟早得补。

最后

这次做下来，我最大的感受不是"AI 替我设计了一个产品"，而是它把很多原本卡在脑子里的东西，快速推成了一个能讨论、能修改、能看见的版本。

以前从一个念头走到一版草图，中间会有很多空转时间。想一会儿，停一会儿，查一会儿，改一会儿。现在这个过程短了很多。你可以先把东西堆出来，再慢慢筛。

但真要说最值钱的，还是后面那一步：拿着这版东西去找真实的人聊，看他们到底想不想用、愿不愿意迁移、在哪一步会嫌麻烦。

前往主页下载源码