@lavard #3 shadcn/ui 写一些简单应用还行，但是组件毕竟不如 mui ，antd 丰富，感觉还是不太好用。看上去给了本地的源代码可以编辑，但是真的缺什么功能的话，如果依赖的底层组件没有直接给相关接口，自己写很麻烦

v0.dev 我也订阅了，用多了就后悔了，主要有以下痛点：
- 很笨，写写简单应用还好，稍微复杂点就能感觉出来远不如 claude 3.5 sonnet ，唯一的优势就是自动上下文，但是如果你愿意花时间手动给 sonnet 上下文，v0 就不太行了
- 用需要在本地直接提供组件文件的组件库（比如 shadncn/ui ），就很容易报错，还改不好，感觉用 mui 这种全都 import 的会表现更好
- 如果 v0 不能解决问题，你自己在本地改好了，是很难把你的更改同步到 v0 这里的
- 不返回项目依赖文件，比如 tailwind 相关的配置，之前 11.20 号那次的 update ，好像是升级到 nextjs 15 了，结果老项目直接无法启动报错，我看不到它依赖的配置文件，直接让它改也改不好，这个是使用过程中最无语的是事，这种乱加 breaking change 的策略说明 v0.dev 团队现在还是玩具心态在做产品，我后来还是回去人肉用 sonnet 了

看工作相关的技术文章，做做自己的项目，刷算法题算不算摸鱼？

如果算大概工作:摸鱼=3:1 ，不算大概 10:1

加了区块链功能，还挺有特点的

@14c0r3y #28 不好意思开 F12 看了一下，icon 应该是对齐的，但是在屏幕处于某些宽度下，文本会被挤成 2 行如下图显得不太好看

https://virworks-my.sharepoint.com/:i:/g/personal/chesha1_virworks_onmicrosoft_com/EQ_QAXFNOFBPrMkdl29fC9gBJmGKdbM7EfsEIZl8DP_4WA?e=HjhY1e

@14c0r3y #25 文本和 icon 都是

左边两个元素（ stars, commits ）是不是和右边 4 个不太对齐，是否考虑调整一下间距或者文本让六个元素对齐比较好

@N0vermber11 #2 因为这个帖子的重点在推广 cursor ，而不在 PodRedit

关于 PodRedit
1. 在 op 的主页中 creations 找不到 PodRedit 这个产品，它根本就不受重视 https://www.cellinlab.com/creations
2. 而且几个月前 op 还感慨 PodRedit 的功能有别人做了，自己遗憾或者庆幸没做 https://x.com/cellinlab/status/1816456919755980903
3. V2EX 向来有很多人推广自己的产品，不存在什么喷不喷推广的

所以这个帖子的重点到底是 PodRedit 还是 cursor 已经很明显了

@qz964408614 #7 据说系统规划与管理师最容易，但是对于普通的写 curd 的后端开发来说，系统分析师和系统架构设计师应该是最熟悉的，但是难度可能会稍微高一点。

你可以在别的地方看看攻略，因为我也没接触过系统规划与管理师的内容，所以不好评价

@ddonano #2 私企没用，国企有用，评职称的硬性要求

@lmfx89 #1 从视频里看不出来是哪位老师，不过闲鱼的商品信息页面写的是文老师

@RangerWolf #6 有一个 bgm 经常作为朝鲜视频的配乐，有一句歌词听起来很想“想吃广东菜”，你可以去 b 站搜关键词“想吃广东菜”

没有建议，单纯分享下经历：

我也是用 c++技术栈面的后端，多学了点网络，把 webserver （ io_uring 版）写完就深入看了点 DPDK ，不得不说资料是真的少，比较长的就一个零声教育的

不过面试写这种其实不是特别讨好，因为做业务的面试官不懂这个，不会多问，懂的面试官又很容易非常懂，会用刁钻的角度拷打你，除非你确实是在大厂的鸡架组实习过，自学这些偏底层的技术还是太难了

47 45 45 ，刚好及格飘过，爽了

cursor 简单体验过，看论坛吹成这样还以为有很明显的进步，但是体验和 v0.dev 这种低代码工具也差不多，也没有胜过自己手动把上下文给 gpt-4o/claude-3.5-sonnet

可能比较依赖使用方法和 prompt ，我的体验是让他改一个普通的 nextjs 项目都改不好，还不如我手动把上下文直接复制给 poe ，这能一个月 20 刀我只能说有点不太理解了

还有相关的 TS ，P2300 也挺不错的，值得一看

rebase 之后 git 历史看上去更线性一点，更好看，你不 rebase 的话，唯一的好处就是多保留一点点从哪分叉出来的历史记录，但是这个历史记录也没啥用，而且 git 记录会很丑

而且 200 多个 commit 也太吓人了，建议还是先 squash 一下，不然你解决冲突要一个个解决，会更不好处理冲突