有点搞不懂 Claude Code 了

[nealzhuqian]

之前习惯的编程工具是 cursor ，本质还是在 vscode 的基础上内置了聊天对话方式调用 agent 来变成或进行任意授权的操作，一直习惯边改还能边看看代码，不管是 review 具体代码还是看看生成了什么文件，就觉得很方便

最近 claude code 越来越火，也了解到有很多人可以多开或者使用 agent teams 来同时使用多个 agent 来干活，想尝试一下，然后就试了。但有发现纯 cli 编码的话任务开始后不就不能东看西看（指看看代码之类的）了，编码完成之后在 claude code 里看代码/review 貌似也不是很方便，用了之后突然感觉有点无所适从了，完成一个需求后还得打开 cursor 看看改动了什么然后再提交。

请教一下各位佬，我这使用姿势是不是不太对？

[zw2019]

为啥你发的主题的字体和我的不一样 0.0

[wdv2ly]

用 cc 不需要看代码，就像你给手下分配工作也不会盯着看，一个道理🐶

[milkleeeeee]

我是 claude code 写代码，写完了 /review 一下，然后基本很少看代码了，但还是同时开着 vscode ，因为偶尔还是要自己编辑下代码的。

感觉你是想只开个 claude code 就完成所有工作，但 claude code 压根就不打算做看代码这功能，所以它一般是以代码编辑器的插件的形式来提供的

[kurthumburgmtz97]

使用 cc 之前有个前置技能：git, 可以用来查看变化
但你也可以直接在 cursor 打开 cc 然后下达命令

[ZZITE]

claude code 就是更倾向于完全 vide coding 的，他就不打算让你好好 review

[nealzhuqian]

@zw2019 我手机上看一样啊(˶‾᷄ ⁻̫ ‾᷅˵)

[nealzhuqian]

@wdv2ly 果然是这样嘛

[nilaoda]

现在趋势就是 vibe coding ，你只管下发需求就行了，至于代码怎么写的不用太在意（

[nealzhuqian]

@milkleeeeee /review 有效果吗？我发现有时可能他自己带想法做多/偏了( ･᷄ὢ･᷅ )

[nealzhuqian]

@kurthumburgmtz97 所以我可以考虑分屏，一半是 cc 一半是 git🤔

[helonsy]

vscode 里装 cc 插件解决所有问题

[huaweii]

你要明白一件事：cursor 作为一个 AI 开发工具来说，从来都是第一梯队的。

纯后端或者没有做过高保真需求的伪全栈才会鼓吹 cc 一把梭😁

cc 插件+vscode 是一种相对更平衡使用方式。

[sakuraT1]

装 cc 插件不就得了，体验不会差太多

[cairnechen]

所以我一直用 vscode 插件 还有 seletced lines 这个附加功能 目前暂时没遇到什么 CLI 能做，插件做不了的事

[swaylq]

说实话 cc 的 CLI 才是它的杀手锏，插件反而是阉割版。我现在的工作流是 cc 纯 CLI 跑任务，同时 VSCode 开着同一个项目看实时改动，配合 git diff 随时 review 。关键是 cc 可以用 worktree 开多个分支同时跑不同任务，这是 cursor 做不到的。你提到的 agent teams 多开才是 cc 真正拉开差距的地方——cursor 再怎么整也只能单线程干活。习惯了之后回不去 cursor 了，就是刚上手会有一段不适期。

[soulflysimple123]

cursor 里面开个终端用 claude code

[rogerer]

claude 通过 claude code 可以把数据飞轮跑起来，用的人越多，claude 模型越强，然后用的人就更多了

[8888888888]

我觉得#5 #12 的说法是合理的，只有纯 vibe coding 的才适合这种，正常公司业务开发都是存量项目迭代，没办法不看代码完全 vibe coding

[xyooyx]

以前我们写汇编，照着指令改，后来高级语言出现了，我们只专注高级语言的语法不再去纠结汇编指令。 [汇编和高级语言] 类比 [高级语言和自然语言]

[fds]

你用 terminal 分个屏开个编辑器就能看呀，系统又不是单线程的。我目前用 Ghostty ⌘⇧D 下分屏，然后进行各种操作，完事了 ⌘W 关掉。claude code 里面也可以输入 ! 然后立即执行 shell 命令，比如 ! zed . 开编辑器。

[jeremaihloo]

@swaylq cursor 也有 worktree 功能，多个任务并行跑完全没问题的，不存在只能单线程干活的情况

[andforce]

@swaylq 你用的是 2023 年的 Cursor 吧，你说的这些 Cursor 2026 年都没有问题啊

[andforce]

https://www.v2ex.com/t/1201276

我写了个聊天工具，可以完全把所有 CLI 拉进群，可视化，同时还有 git change 一键查看

[BerniLin]

跟我一样，离不开编辑器

[Cbdy]

Curcor, Vibe Coding, 结对编程
Claude Code, Agentic Coding, AI 自主编程

[evamayy]

插件挺好用的

[nealzhuqian]

@swaylq (｡ì _ í｡)我再试试哈，过渡一下

[nealzhuqian]

@8888888888 嗯有道理，结合一下先

[aloxaf]

@zw2019 确实，变成衬线体了。看了下 Claude Code 话题下面的帖子好像都是衬线体。

[winnerczwx]

我刚开始用 codex 的时候也很不习惯, 我就奇怪为什么我看代码还要跳转到 vs code 去?

最近高强度用 codex + cladue code cli 以后, 我感觉他们这么设计真没毛病, 看代码的时间真的大大减少了, 平时检查代码里某些细节都是直接让 ai 去干了, 现在几乎很少用到代码文本编辑区域了

[nealzhuqian]

@BerniLin ¯\_(ツ)_/¯ 兜兜转转未来谁知道呢是吧

[nealzhuqian]

@winnerczwx 👌🏻看来我得继续适应一下

[nc]

左边 GitHub Desktop 右边终端运行 Claude Code

[imycc]

我自己还没适应纯 vibe coding ，所以我是 Trae/Antigravity + Claude Code 混合用。一些简单的函数补全，小修小补还是喜欢编辑器的自动补全。Trae 之类的可以通过 GUI 来查看代码变化历史，尽管 Claude code 的编程效果更好，但是从交互层面我还是更喜欢这种有客户端的。

[ixcode]

你用 C 语言编码的时候会看编译出来的汇编吗？你把自然语言当成编程语言，是不是就好接受一些。

[scegg]

先让 cc 写设计文件。你来审查。

之后直接生成代码和测试脚本，然后让 IDE 或者 CICD 来跑自动化测试。

[xiebow]

我是在 ide 里的终端开 claude 或者 codex ，这样两者（ claude 输出和代码）就可以同时看了

[BeautifulSoap]

claude code 的很多设计的目的就是纯粹在逼着你不 review 代码改动，让你放弃对代码细节的掌控，这也是 anthropic 对 ai 编写代码的想法，也是现在很多 vibe coder 所鼓吹的“正确的 AI 时代的编码方式”

所以我现在根本懒得用 claude code ，因为你根本没法 review 和它每轮对话后的代码，最终生成的代码你根本无法立刻掌控并且及时人工干预

我现在很爱 codex ，至少 codex 结合 vscode 插件每次对话后会给你这次对话的 diff ，而不是让你在失去对代码的掌控这买上一路狂奔

[badboy200600]

我也是 cursor 用习惯了, 感觉 codex 的 vscode 插件用起来好不舒服

[jonty]

/ide 可以同步改动到编辑器上查看 不影响

[huaweii]

@swaylq codex ，cursor ，cc 都有 worktree😅

[lod]

@ixcode 且不说自然语言本身就不如编程语言精确，llm 作为“概率模型”实际上每次都在抽卡，相比图片/视频生成，代码作为“中间产物”的优势在于可以审查和低成本修改，纯靠“vibe coding”就等于放弃这种优势

[lucifer9]

neovim 开个 terminal 跑 Claude Code 不就结了？

[erwin985211]

跟我之前一样，总想着看它该总想看他改了哪些代码，甚至都不让他直接改代码，让他把代码发出来，我自己粘。后来我同事跟我说：“你管他写什么，你直接用不就行了，只要没 bug 就行。”我一下子释怀了，vibe coding 就是这样。

[akira]

是的，开发范式转移了。 你需要把你的 思路 ，想法， 形成规范 和 需求 ，让 AI 能明白你想怎么做。

[lneoi]

看结果别看代码了，模型跑的代码量太大，人工一个个慢慢审核搞不定。看大结构大方向，重点复杂的地方。我一般会一边开着 vscode 辅助看看，一边用大模型跑

[nealzhuqian]

@jonty 哟，回去试试，每日小技巧 get+1 😀

[xiangran0028]

之前也无法理解为什么用 CLI 这个设计，但是高强度使用之后，发现我确实不怎么看代码。

[zisen]

我个人这几个月收敛下来是 vscode 写需求文档，codex/claudecode 看需求文档解决需求，然后 codex 自己跑一遍 review ，然后人工在 vscode 里 review ，最后让 codex 总结并提交

[Bad0Guy]

我是让 codex 审查了 cc 写的 plan 跟 prompt 之后再下手，以及每次改完后让 cc 显示改动后的代码，这些全都写进 prompt 里，然后全部都在终端里完成。bug 以及 cc 自行乱生产的代码会少很多，现在偶尔打开 cursor ，一个月就那么一两次，以前基本天天都要开着

[lerry]

搭配 git 工具和 vscode 使用

[zed1018]

@jonty 说起这个，我感觉我只有 vscode 选中文件或行能反馈到 cc 里。但是 cc 的变更没有在 vscode 里有 diff 和批准或驳回变更的操作

[nealzhuqian]

@zed1018 我猜可能是 cc 生成完就生效了，没跟 vscode 做联动。cc 可以按两次 esc 主动撤回，所以必须依赖 git 才好区分改动，同时不能有多个改动一次 commit 的坏习惯了

[runtime0]

一样，离不开 GUI ，并且 AI 写完代码我基本都会扫一眼。。。

[ksc010]

新项目：不涉及数据修改的（不可逆操作）我敢让 cursor 写，基本可以不看代码（但是部分情况下，必须指定 把 xxx 修改成什么样 才行， 不然 cursor 一直修改不好。
老项目： 正在线上运行的， 涉及线上业务的， 我是一点不敢不做 review 。因为业务太复杂了， 我自己语言描述都不是一两句能描述清楚的，所以也也不认为 AI 能通过已有的代码理解业务上下文关系

[junas7]

我的感觉是 git 要多提交，提交完再对 CC 提下一个改动，这样每次才能方便找代码

[nuo7mi7]

都 vibe coding 了，还去看什么代码，这才是未来的大方向，你想去检查那就让另一个模型再去检查代码就行了，人就应该解放自己，大势所趋

[bololobo]

@huaweii #12 你好, 请问什么是高保真需求?

[jaoyina]

很简单，在 vs code,里用 claude code 不就行了。

[HHHans]

个人比较悲观的看法是任何 IDE （包括 cursor ）都快被扫进历史垃圾堆了，从今年初开始就是这个趋势，下一代模型能力进步就应该实现了，vibe coding 、vibe design 需要演进的方向是可视化监控整体架构，而非具体实现

[QS0x01]

还看个鬼的代码，现在还看代码的只能说公司内 ai 改革的风还不够热，迭代的速度不够快。

ai 花一个小时写完半天的需求，代码量你自己 review 一整天都未必看的完。

初期你可能还会看看大致的架构方向有没有出问题，后期你会发现反正真正关键的细节你也没那么容易找到，不如直接换个模型把上下文清了让 ta review 和 test

[sjdhome]

我同时开三个终端，分别跑 LazyGit + 调试环境 + Claude Code 。Claude Code 写完了就去 LazyGit 看改动，没什么问题就去调试环境看效果，测试完就让 Claude Code 给我 commit 。

[codesnowjava1]

@sjdhome 这个 6

[ixcode]

@lod 你说的对，但是放弃了这个优势，可以带来其他优势，比如可以不用写重复性的代码，更快去验证一些功能，更高效的去对比一些实现方案，更快的去做技术栈的迁移，更完善的文档和 commit message 。还有就是可以让更多的人都具备编写软件的可能，这对哪些不会编程语言的人是另一种优势。

[Lemonyi]

@sjdhome 这操作，有点东西

[cutchop]

习惯就好，我现在很少检查代码了，也就很少打开 cursor 了

[goodspb]

所以我是：vs code + cc

[Sundayz]

纯 vibe coding 的，自己单干没啥问题，但在公司生产环境，这么搞真不怕背锅吗？

[zzz2021zzz]

反重力的两种模式就是这两个方式的代表（传统 ide+插件形式的 vs 完全 vibe coding 不看代码）的，交叉使用，目前还是比较适应前一种模式，完全不看代码着实还是不放心