帖子
账号 8568537813
Claude Code 这款产品的惊艳之处在于,它是人机交互、产品定义、技术深度的完美结合。 在用到 Claude Code 之前,我一直是一个 Cursor 吹,因为我个人觉得 “Chatbox” 不是最好的人机交互形式:写代码的时候需要人力在浏览器和 IDE 之间搬运 coding context,极大的影响了使用体验,交互成本高且打断思路。 Cursor 把 LLM 放到了 IDE 里面,设计了上下文(文件)引用快捷键和 “进行 FIle Edit 的专用小模型”(如果你用过老版的 Cline 你就知道 Cline 是用你选择的模型 + tool call 进行逐行替换的,但是 Cursor 明显在文件修改上快非常多),从而使得 Coding LLM 与 IDE 进行了深度融合,但是即使是这样也没有让 Cursor 超过 Cline,Roo Code 这样的竞品太多,真正的杀手锏是 Tab-Tab-Tab 上下文感知多行补全功能,Cursor 团队在 Blog 上明确提到他们用用户的数据训练了这个模型,从而使得它的体验无与伦比。 到此为止 Cursor 已经是我心目中最优秀的一批产品了:强调交互,把 LLM 搬进 IDE;用数据驱动产品迭代,训练 Tab Model;再到后来,Cursor 又加入了 Agent 模式,真正使得一句话生成一个完整的代码仓库成为可能。 我本以为这就是 Coding 产品的终极形态,直到我用上了 Claude Code。我认为 Claude Code 的精髓在于回归本质。早期程序员写代码的时候还没有 IDE,那时候所有的操作都在 Terminal 中完成,代码编辑也是用 Vim,到后来,为了让人类更方便的与系统进行交互,才有了 GUI IDE。但是在 LLM 的时代,这样的做法是 “兜了一个大圈子”:GUI 是为人类设计的,如果要让 LLM 直接接入 GUI,那就是 browser-use,但是这件事的难度极高,因此 Anthropic 很聪明的回归了编程的本质:让 LLM 在 Terminal 里运行,这样其实只需要学会一些命令行关键字,以及特殊的 file edit 功能,就可以像早期程序员一样写代码了,这极大的降低了 Coding Agent 系统设计的难度。更妙的是,虽然人类失去了 GUI,但是这并不影响体验,因为 Claude 在 Terminal Coding 任务上进行了额外的训练,所以人类事实上并不需要自己编辑代码,只需要 “vibe coding” 就可以完成很多任务 - 如果实在是需要写代码,开个 Cursor 就行了。回到我开头说的人机交互、产品定义、技术深度,我们一项一项分析: 1)人机交互:Coding Agent 从 Copilot 变成了 Pilot。得益于 Claude 系列模型强大的 Coding 能力,事实上已经不是 LLM 在辅助人类编程,而是人类在监督 Agent 编程,这是一种范式上的转变(在这点上,虽然 Cursor 也有 agent 模式,但是我认为他们没有彻底革新这个交互形式, Anthropic 从训练和提示词上都彻底的将 Claude 融入了 Terminal 环境)。 2)产品定义:Anthropic 没有执着于在 AI IDE 上加入战斗,反而是勇敢的做了减法,依靠自家模型强大的能力,把 GUI 从产品定义中去掉了,这不是什么历史惯性,因为 Anthropic 完全可以把 Claude Code 集成到 Claude Desktop 里,但是他们没有这么做。这样带来了一个额外的好处:Terminal 几乎是无处不在的,因此在 Remote Server 上进行 Coding 不再需要 Remote SSH 插件,只需要 npx 快速安装一个轻量的 Claude Code,就可以开始工作。 3)技术深度:Claude Code 不乏竞品 - Codex,Gemini CLI,Cursor CLI(最近出的),Qwen Code,Crush,OpenCode...,但是他们无一例外都无法企及 Claude Code 的高度,因为 Anthropic 不但定义了一个 Terminal Coding 产品,也在大量的投入资源对模型本身进行改造以适应这个产品,如果你关注了最近的 Opus 4.1 发布,你就会发现 Opus 4.1 相较于 4.0 在 SWE Agentic Coding 上只有 2.0% 的提升,但是在 Terminal Bench 上有整整 4.1% 的提升,说明 Anthropic 真的非常注重 Claude Code 这个产品。对于竞品来说,画虎画皮难画骨,只是把模型放进 Terminal 是没用的,最重要的是持续不断的用真实的用户数据去驱动基座模型能力的提升,庞大的用户技术以及随之而来的数据将会是 Claude Code 最大的壁垒之一。 最后我们再来锐评一些竞品: - Gemini CLI:Gemini 输出表格的时候内容会被隐藏,根本看不到完整的内容;“@” 引用文件的方式竟然不支持模糊检索;在人机交互上做的非常有差距。 - OpenAI Codex:Youtube 上有人专门吐槽过:光是在配置模型这里就令人望而却步了:Model List 里有几十个模型,一望无际,不知道选哪个,而且最搞笑的是有些模型事实上不支持在 Codex 里用,也被放上去了,看起来像是 list-models 拉了一个表先放着,然后手动维护了一个 model list 作为可选,那么为啥不一开始就把可用的 model 放上去呢?令人迷惑。最重要的是,OpenAI 的模型在 Coding 上,特别是 Terminal Coding,远不如 Anthropic。 - Qwen Code:战神起跳,赠送的 token 用完了,战神睡觉。Qwen 显然没有大规模部署 Qwen3 Coder 用于 Coding,低估了 token 消耗,导致最开始那两天大家怨声载道,一下午十几块钱就出去了,堪比 Claude Code。 - Crush / OpenCode:都是开源的 Terminal Coding 产品,能力上属于能用但是不好用,特别批评 Crush,Terminal Coding 不需要花里胡哨的 TUI,还不能调 theme,导致输入框的 placeholder 可见度特别差。 - Cursor CLI:加油啊,把 Claude Code 价格打下去!
夜航星
404
回复 @ · 取消
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