不就是 byd 的事么，搞的跟地下工作一样

是的，同样吃过亏，能放心不看那你是真的心大

他这个最大的迷思是：

AI 编程的准确度和训练的代码量正相关
他号称 AI 编程友好
但是没有人用它 build 东西，所以代码量少
代码量少，AI 训练少，AI 生成准确度差

AI 编程越友好，AI 生成准确度越差 https://i.imgur.com/agAJ0Rd.png

可以，不过 jules 排队可以排死，太多人在用了

@aarontian 按官方和论坛上说法是会的，你可以看这里 https://docs.cursor.com/models#auto-select, auto-select 用的是 premium model, 一条$0.04 ，不过 cursor 的计费一直都不是很稳定，所以也可能你遇到 bug 了

@wink #18 你用的越多越慢，最后大概会去到 3-4 分钟一个请求，另外用 auto 你就亏了，auto 默认给你 3.5 ，但还是一条算一个 request

那个 thinking 模式(0.5 之后变成选 thinking 模型了)，开了还不如不开，开了以后 3.7 很喜欢自作主张改代码，以前老版本还能 @ file 来避开他乱改，然后你不开 max 模式的话上下文 120k ，过了上下文就要用各种 trick 来让他遵循指令，包括但不限于 memory bank 之类的方法，但 trick 终究只是 trick ，有用但还是不适合大项目

q4km....你连 mac 的专属格式 mlx 都不肯跑在这里抱怨速度慢？ mlx 好歹 r1 你速度能接近 18t/s, v3 能接近 20t/s
而且我也有理由相信你没解内存锁

@KaoDiGua33 roo code 主力，augment 我没买会员，拿他做文档和问答

为啥不是 cursor + augemnt + roo code ，我反正这仨装一起

我觉得像你现在这个思路好像连线和脚本也并不矛盾吧，完全可以同时支持用户拖拽连线完生成脚本，或者反过来脚本生成连线的拖拽

前面有人说的挺对的，非要拿视觉检测就多摄像头，然后接一个图像识别模型比如 gemini 或者 qwen vl 之类的，定时检查喂一张截图/检测到图像变动就喂变动 n-1,n,n+1 几帧，然后三个里两个为真就是漏水

fork: cline or fork: roo code

mcp 组了一套自己看文档，自己查数据库，自己写码，自己 api 测试的丐版 agent

你说 ai 出来之前还能说功能和 ui 有个轻重缓急，先搞功能再搞 ui, 现在这年头拿个 cursor+claude 之类的重构一下你的主页和 ui (只改 ui)能要的了你两小时? 不比你自己在这里随便糊一个 ui 上去强？
虽然比不上设计师给你出原型仔细设计，但至少到了一定的阈值之后对于用户来说就不是缺点了

之前那个 cto 两边发同样的帖子，在本站被群嘲，隔壁水归水好歹是就事论事的讨论，也没有人身攻击，我不好说谁更好

依然是 langgraph 最靠谱，特别是你的 agent 不是一个 helloword 的那种，很多 agent 框架看上去几行代码搞出来一个 agent ，真到解决实际问题你就会发现，你要有 workflow 组织能力（特别是结构化输出+workflow 配合），你要有可视化 workflow 能力，你要能够很方便控制节点具体输出，你要很方便控制记忆/消息（比如某个节点只输入部分的消息），你要很容易接入 pre-build 的 tool 和插件（以及这个框架已经有大量别人做好的 tool ），你要有一个很自由的组织 prompt 的能力，你要有 observe 能力, 你要有控制 guard rail 的能力，你要有组织 muti-agent 能力，最后你可以把市面上的 agent 框架列一列，真能几乎全部满足这些条件的只有 langgraph

@wzw #12 cursor 的 gemini 2.5 pro 基本一刀砍废，最开始的时候一轮对话就能完成功能，现在对话个三四轮都不行，还乱搞代码，roocode 那边就简单粗暴了，直接所有代码都在 context 里，自然效果比 cursor 好得多 （当然也因为这样钱烧的飞起），如果 cursor 那边都要按量付费了(max 模型)，我还不如用自己手头上有的 key 就好了，另外 cursor 那边 500 fast requests 用完 claude 一个请求等 3-4 分钟