两个仓库
第一个仓库只负责 UI ，技术栈 Vue + Tailwind 这个仓库不管业务逻辑，只做界面和简单交互，数据全部是 mock 的。
第二个仓库是正式产品，UI 跟第一个仓库完全一致 我给每个页面都配了 1:1 的对比测试。自动化脚本会同时对两个仓库截图，只要有 1px 的偏差，测试就挂。
具体做法
所有新功能全放在第一个仓库里先做设计。因为不需要考虑逻辑，AI 可以吃进全部代码，之前的页面风格也能一并理解，改起来特别快。再加上是基于 HTML 的，随手就能部署到手机、电脑上实际操作。新功能的验证迭代都能飞一样地跑通。
第一个仓库的 UI 定稿之后，再让 AI 照着这个仓库把实际功能做进正式产品里。有现成参考兜底，AI 写出来的页面高度精准，不会跑偏。
因为有 1:1 截图测试卡着，后续再怎么迭代也不用担心 AI 手滑改坏之前的 UI 元素。
内容完全由人类构思与实践，文本经过 deepseek 润色。
 |
1
Zhuzhuchenyan 21 小时 43 分钟前
对的，我们现在也是同样的思路，而且我们现有的流程在设计阶段会批量的生成 4 个方向的纯 UI 项目用来头脑风暴，上次定稿前光删这些项目就删了十几个。最后留下来的最终稿再让 Agent 一比一复刻进主线
|
 |
2
lujiaosama 21 小时 42 分钟前
现在 gpt 已经会时不时的停下了询问我要不要做个原型稿，然后让我选择其中一个了。感觉有点类似这个。
|
 |
3
netabare 13 小时 3 分钟前 via iPhone
其实这个就是模块化、抽象和把复杂项目拆成很多小元件的本意。只可惜软件工程讲究的就是个叠床架屋，所以最后设计模式、架构一个比一个复杂搞得云里雾里，封装和抽象全往加 accidental complexity 去了。
op 这个做法算是用 AI 正本清源了。 其实也想到我自己前段时间工作上遇到的一个事情，但并不是 AI ，大概就是做的项目的 runtime 的 hypothesis 很不好控制，同时又要为 library 和框架的后续可扩展性思考，又要满足客户稀奇古怪的运行时要求，又不希望被客户的屎山业务倒灌把项目搞成 day 0 legacy 。 我那时候的思路倒不是拆 project （毕竟还是我自己在做），而是一个 repo 几个模块互相独立做，UI 和渲染都去掉了，直接在 vue 里写 TSX 打出 div 「看着表格假设他是个可视化组件」，响应式对上了再把渲染库插进来，然后立刻断网把缺的数据和实现全 fake 堵上，直接做出一个跟客户 app 对标的最小 app ，做完立刻把客户那坨狗屎接进来然后看看能不能把这个 app 换成「符合客户要求的最小 app 」。 全程我给我自己的要求是：不写任何「整合、修补、migrate 代码，尤其是对接不同的运行时和框架的，如果有一行，说明我写坏了」。然后就让 TS 类型体操来帮我把这一堆模块串起来。 然后就把去年两个团队定义了一大堆架构都搞不下来的任务一次性打通了。 所以我想，如果 op 那边能保持两个仓库之间有很强的隔离性质，其实这个思路还是蛮好，甚至可能都非常适合 AI 的。我这边那时候做那个项目做完整个人都不好了，要是那时候能让 AI 帮忙分担啥就好了（可惜不能）。 |
 |
4
bbao 8 小时 38 分钟前
身为偏后端的研发，要做好前端以及 UI 设计，有哪些比较优秀，大家在工程化和日常使用的 skills 及 ai 框架推荐推荐
|
 |
5
teaguexiao 8 小时 10 分钟前
Vue + Tailwind + shadcn-vue 这套对后端同学最友好，组件拿来就用，AI 补全率也高。Vibe coding 阶段先不管逻辑，让 AI 纯写 UI ，定稿了再接业务，就是 OP 这个思路。
|
Select Language