帖子
账号 9590777263
我从去年开始使用 cursor,一直到今年 5 月份左右,我都在高强度的使用,但是我从来没有用过 auto 模式,我会认真的研究每一个新发布的模型的 SWE-bench 分数,然后在 cursor 上线的时候第一时间开始使用 后来 cursor 引入了不太透明的计费机制,MAX mode,老实说这让我有点不舒服,并且在高峰时期,热门模型的回复非常缓慢。当时正值 claude code 和 codex 开始逐渐发力,正好我也开始订阅 Anthropic 和 openai 的 pro 计划,因此我转向了 claude code 和 codex 我个人挺喜欢 terminal coding agent,因为他们事实上是承诺了一种 “不需要打开 IDE/直接编辑代码的编程体验”,我可以聚焦于高层次的意图和设计,而不用关心细枝末节的东西,但是随着编程的深入,我发现“不求甚解” 的编程在一开始可能确实很爽快,但是编码的过程会引入大量潜在的问题,从而使得后续的拓展和维护非常困难 正好这周我用光了 codex 和 claude code 的限额,而我始终保留着 cursor 的订阅,因此我久违的打开了 cursor,并在 tab completion 的帮助下开始编码,并且时不时的用 auto mode 解决一些问题 我开始觉得事情有点不对劲,auto mode 的表现比我预想的好太多了,它在这些情况下表现良好: A:我只是想要关于某端代码的 quick answer。比如:“这个 forward compatible 的配置是否可以安全的移除”,auto mode 能快速精准的给出答案 B:稍微复杂一点的问题。比如我最近正在开发一个比较底层的音频处理流水线,我需要在流水线级别实现一个控制信号,这涉及对非常多的代码逻辑的阅读,以确保引入新的信号不会带来意料之外的副作用,auto mode 表现的很好,它看起来在调用 reasoning model,并准确的沿着 pipe 阅读了相关的代码逻辑,并且提供了非常完整的解决方案和风险预警 C:编码工作。当我定位了问题,有了一个解决方案,并且规划好了 commits,auto mode 能够快速精准的按照我的需求实现代码,并且没有做多余的事情,这一点非常重要,因为我经常在 claude code 中发出 “i didn’t ask you to do that” 这样的感叹,即使我已经很明确的提供了 prompt 我承认一开始我觉得 auto mode 只是一个降低成本的把戏,但是后来我在使用 claude code 和 codex 的时候开始意识到,agentic coding 的用户 token 用量具有极大的方差和不可预测性,因此即使是 claude code MAX plan 这样 200$ 的订阅方案也不得不引入周限流,成本控制对于这类公司来说是一个非常大的挑战 现在,基于我自己的亲身体验,我想为 cursor 团队点赞,auto mode 是一个了不起的产品设计,我对此曾经有误解,但是我越来越意识到在 cost-efficiency-performance 这个不可能的三角中取得平衡是很困难的事情,但是 cursor 团队一直在不断的优化 auto mode 的体验,而这样的体验是 SWE-bench 无法衡量的 更重要的是,我认为这是一个很好的 AI 产品公司商业化模式的探索,我们所看到的情况是 Codex 和 Claude Code 由于 token usage 压力而不同程度的引入了限流措施,最近 reddit 上 claude code 的 sub 也在大量的反馈自己订阅的 plan 所对应的 rate limit 完全不及预期。而 cursor auto model 可能是一条可行的路径,它可以根据任务难度选择合适的模型,跟 GPT-5-Chat 的方向是一致的,长期来看也是更加可持续的 模型发展到现在,各家后训练逐渐成熟,产品的取向也日渐清晰,比如: - GPT:最强的思考,可观的上下文 - Claude:放弃最强智能(怀念老版本的 Opus),All in Agent(terminal、tool calling、coding) - GLM:开始尝试在 agent 和 terminal coding 上挑战 claude - Gemini:超长上下文,Flash 模型速度快成本低 - Qwen:每一项都不差 我自己日常工作里也会搭配这些模型,在不降低效果的情况下获得较低的成本,至少比全部都用 GPT-5 要低很多 我相信没有模型能够在所有的任务上都做到最好,那么这是否意味着 model routing 不但可以缓解成本压力,甚至有可能让路由的结果超过单一的最强模型?结合最近 cursor blog 曝出的 tab completion 通过 online RL 实现了 28% 的采纳率提升,也许 cursor 同样在 auto model 上使用了类似的基于用户反馈的训练机制?如果 cursor 团队真的探索出了一条通过数据反馈提升 model routing 效能的方式,那么我觉得这是非常了不起的 说一个题外话,claude code 在前端时间承认偷偷更新了模型并且导致了不同程度的 “降智” 现象,我原先认为 auto mode 是一种不透明,但现在回过头来看,至少你可以在 cursor 里明确的选择 “我要最好的模型” 还是 “我希望获得一个平衡的体验”,而不是对底层发生的事情一无所知
小满不加班
505
回复 @ · 取消
0 条评论
青柚测评1· 2026-10-28
已经推出那么久了还是这么垃圾,要不是为了我的旅游抽奖,真的是看都不想看!!! 作为美团的第一款屎逝级创新产品,看得出来美团想做的是一款AI助理,帮助用户完成日常的一些琐事包括订餐、规划行程,在绝大多数时候都是以幻觉提供“稳定”输出的产品,目前存在"功能不完善、技术不可靠、体验不友好"三大核心问题,虽然定位为"小而美的AI生活小秘书",但实际表现更像是"大而不当的半成品",整体感觉更像是实习生的练手项目仓促上线?如果真是这样不如早点关掉,别让用户笑出声 0. 入口有问题,这样一个本应深度嵌入美团APP的服务,却独立成一个单独入口。事实上,美团APP内也早已存在一个名为“小团”的AI搜索助手,虽然无法代替用户下单,但是体验更为成熟(至少是能够准确理解用户意图并返回相关推荐),小美与主业务系统割裂严重,既然已有能力整合进搜索链路,为何还要另起炉灶呢?不得不引起人的深思hhh,真的有种同一个公司,两种智商的荒诞感 1. 习惯性遗忘上下文,在提出第一个需求后对于不符合推荐的商品提出新的需求后会习惯性遗忘我第一句话说了什么,注意力机制需要人来激活 2. 图1,明明有卖的东西他说没有,但是意外的是居然还知道要凑单 3. 图2不支持指定时间预约下单,在要求提供一日三餐的时间、预算以及希望每一餐吃什么以后,他只是告诉我在明天早上八点半提醒我下单,且不说第二天没提醒,只告诉我预算分配算什么?另…
305
北岸的猫1· 2026-10-28
我作为一个保安(真保安),其实不会写代码(只会一点基础的html),折腾这些纯粹是个人爱好,话说AI写代码确实极大的提高了写代码的简易方便程度,我其实25号就已经更新了国内版本,并拿到了solo资格,26日晚上顺手做了一个美团外卖的商户后台(单纯想试试国内版本的solo模式还有国内大模型的能力),和国际版相比,缺少了重要的 solo builder模式,默认就是solo coder模式,可能是国内产品觉得coder模式更符合国内使用习惯?从大模型的代码方式来看,个人感觉有点像kimi的k2组合了豆包1.6!输出速度很快,代码风格也很像k2的风格,还有那个plan模式,我使用的感觉是没什么效果?上下文部分184K,就我来说比较够用了,因为我多数时间是用在做文案,在聊天窗口这里可以@自己编写的智能体来实现需要的智能体组合调用,这块还是很心水的,至于关键的生成页面的速度,我个人感觉吐代码的速度是挺快的但是,生成最终结果还是慢过国际版!在后端逻辑这部分卡了很久,思考的时间也是最长的,看了下代码风格感觉就是k2呢,国内大模型还需要更加努力呢!在后端生成这块速度明显要慢很多了,而且很多地方有明显的错误,本来是已经生成了,实际上它一直在自我修正中,最终没有完成这个项目的成功,报错了。我还尝试了下用solo模式写文案,怎么说呢,这部分也算是有点意思的内容,先通过智能体做一个小红书的文案专家,在生成…
905
慢半拍1· 2026-10-28
Refly 标榜自己是和“Vibe Workflow”,这个降低技术门槛、试图用 Agent 节点重构自动化流程的愿景我是非常买单的,官网呈现出的极简克制感也确实在第一眼拉高了期待值。但深入体验后,我感觉目前 V1.0 版本最大的问题在于场景落地的“水土不服”以及自动化 ROI 的倒挂。 首先是模版库(Templates)的选品策略让我很困惑:既然团队源自国内且强调普惠小白,但预设案例里清一色的 X (Twitter)、Ins、LinkedIn 和 RSS 抓取,明显是针对海外生态的生长土壤。对于我们这种想做国内资讯去噪、或者只是想做一个简单的“新闻日报”的用户来说,几乎没有直接可复用的抓手,场景割裂感极强。 其次,在核心体验上,我实测了官方推荐的“新闻抓取+邮件摘要”,发现整个链路的运行 Latency(延迟)偏高。对于这种轻量级的信息获取任务,如果工具的执行效率跑不赢我手动操作,那自动化的爽感和价值就被完全稀释了。 最后,所谓的“自然语言一句话创建”目前还没能很好地解决用户的冷启动焦虑——这就好比给了我一把万能钥匙,但我却找不到锁在哪。我甚至尝试结合外部 AI 的建议去生成一些特定的流,但落地效果依然不理想,感觉工具对意图的理解力和最终的执行力之间还存在不小的 Gap。 总的来说,现阶段的 Refly 更像是一个有着漂亮概念外壳的 MVP,对于真正想上手解决具体痛点的用…
404
青柚测评1· 2026-10-28
ShellAgent 2.0 初体验:想法很好,但产品还需打磨 首先,非常感谢降临派提供的邀请码,让我有机会提前体验到 ShellAgent 2.0。 说实话,最近对各种 Agent 都有点审美疲劳了。Github 上开源的框架一个接一个,轮子满天飞,但对普通人来说,门槛还是挺高的,不是要配一堆复杂的参数,就是做好了也不方便分享给朋友用。 所以 ShellAgent 喊出“三句话生成 App”的时候,我一下就来劲了。这不就是我想要的那个“零代码版的 Coze”嘛!把那些烦人的技术环节都包圆了,直接对话就能搞定,期待值直接拉满。 但实际上手折腾了几个场景,感觉就和想的不太一样了。 首先是稳定性和端到端体验的问题。 我尝试了几个在其他平台上相对成熟的场景,但在 ShellAgent 2.0 中都遇到了阻碍。例如,在测试“小红书笔记搜索”功能时,应用返回了一些看似存在但实则为 Mock 的数据;而在尝试“文生图”功能时,无论如何调整,系统都反复报错,无法成功生成图片。我理解,这些基础能力在 Coze 等平台的能力边界内是完全可以实现的,这让我感觉 ShellAgent 2.0 在核心功能的稳定性和流程的端到端打通上,还有一段路要走。对于 ToC 产品而言,用户的第一次体验至关重要,如果无法顺利跑通一个基本流程,很容易造成用户的流失。当然,我也相信这只是早期内测阶段的问题,期待官…
702