这是一个创建于 293 天前的主题，其中的信息可能已经有所发展或是发生改变。
Nothing before Others I have to say
最近一直在使用 AI 来尝试做些小东西，付费了 Coze 、Monica 、v0.dev 。依赖的大模型主要还是 claude sonnet 3.5 、Gpt-4O 、Claude Sonnet V2 。本意是想做一个配合音频播放以及琴谱滚动来打节拍的 web 应用，不过越做越复杂后实现琴谱滚动这个功能一直难以实现，先实现了一个简单的节拍器上线，地址： https://moretea.top/
结论
- 从代码能力上来讲，整体能力 claude 大于 gpt ，gpt 略逊色于 claude sonnet 3.5 ，claude sonnect V2 的能力远胜前两个模型（虽然我付费使用不长久，但是由于两个模型都长期解决不了我写前端的问题，后续是通过这个模型解决的）
- 在实现前端工程上存在几个主要问题，一是缺少训练资料，可能是前端有些库更新太快，AI 给出的代码使用组件的方式永远是错误的，无法进行纠正。二是模型记忆能力还是不够长，这一点 claude sonnect V2 会强一点，其他模型经常犯的一个错误是，当你修改好了无数个点，有可能在某一刻因为某个点的改动而丢失了之前所有的修改。
- 后端工程实现上，几个模型能力都不差，gpt 的推理能力似乎有时候还更好一些，但是 gpt 经常性抽风，而且由于极小的记忆内存管理，时不时回答还会抽风，还经常有网络问题，难用的很。
- V0.dev 是目前我仍保留付费使用的产品，主要有以下几个帮助，在实现产品没有什么想法的时候可以通过对话式直接生成 web 版的原型图（姑且称为原型，毕竟 UI 不算太好看）。写后端代码在实现新需求的时候是最有效的，直接把原型图丢进去，稍微调整细节，从 SQL 到实体、service 直到 controller 代码一次性丢出，基本不需要修改。
- 要依靠 AI 实现根据设计稿直接实现前端工程还是有很大的难度，目前使用下来最优的方法是，尽可能地拆分组件，但也不要拆分地太细，避免每次改动都需要修改好几个组件。将需求自顶向下进行拆分，先划分页面框架区域，每次实现一个区域的界面，再实现该界面的接口联调，当某块区域功能完成之后再实现下一个区域。如果此时组件比较大了，趋于稳定的功能最好是拆分组件，避免因为记忆问题影响模型回复。
 | 1 zsj1029 293 天前 还是 token 的问题看起来，内容太多后，ai 容易失忆和分心 |
 | 2 FlashEcho 293 天前 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 silencil OP @chesha1 确实这是相对 cursor 这类 IDE Code 应用最大的缺点，每次本地修改完需要复制同步到 AI 。不过我个人觉得 V0 有很强的记忆能力，在很久没有被讨论到的内容如果被 cue 到，它还是能回忆起来，其他几个模型这点能力弱一些，如果只使用对话式 AI 编程，要实现一个项目，超长的记忆能力我觉得对我来说比较重要一些。 |
 | 4 tutulyy 290 天前 最大的问题还是在记忆持久化上，一旦碰到逻辑复杂的工程 AI 就不太好介入了。 |
 | 5 MyPassWordis 290 天前 所以这句话啥意思：Nothing before Others I have to say |
Select Language