之前习惯的编程工具是 cursor ，本质还是在 vscode 的基础上内置了聊天对话方式调用 agent 来变成或进行任意授权的操作，一直习惯边改还能边看看代码，不管是 review 具体代码还是看看生成了什么文件，就觉得很方便
最近 claude code 越来越火，也了解到有很多人可以多开或者使用 agent teams 来同时使用多个 agent 来干活，想尝试一下，然后就试了。但有发现纯 cli 编码的话任务开始后不就不能东看西看（指看看代码之类的）了，编码完成之后在 claude code 里看代码/review 貌似也不是很方便，用了之后突然感觉有点无所适从了，完成一个需求后还得打开 cursor 看看改动了什么然后再提交。
请教一下各位佬，我这使用姿势是不是不太对？
 |
1
zw2019 Mar 28  7
为啥你发的主题的字体和我的不一样 0.0
|
 |
2
wdv2ly Mar 28 via Android
用 cc 不需要看代码，就像你给手下分配工作也不会盯着看，一个道理🐶
|
 |
3
milkleeeeee Mar 28 1
我是 claude code 写代码，写完了 /review 一下，然后基本很少看代码了，但还是同时开着 vscode ，因为偶尔还是要自己编辑下代码的。
感觉你是想只开个 claude code 就完成所有工作，但 claude code 压根就不打算做看代码这功能，所以它一般是以代码编辑器的插件的形式来提供的 |
 |
4
kurthumburgmtz97 Mar 28
使用 cc 之前有个前置技能：git, 可以用来查看变化
但你也可以直接在 cursor 打开 cc 然后下达命令 |
 |
5
ZZITE Mar 28 1
claude code 就是更倾向于完全 vide coding 的，他就不打算让你好好 review
|
 |
6
nealzhuqian OP @zw2019 我手机上看一样啊(˶‾᷄ ⁻̫ ‾᷅˵)
|
|
7
nealzhuqian OP @wdv2ly 果然是这样嘛
|
 |
8
nilaoda Mar 28 1
现在趋势就是 vibe coding ，你只管下发需求就行了，至于代码怎么写的不用太在意（
|
|
9
nealzhuqian OP @milkleeeeee /review 有效果吗？我发现有时可能他自己带想法做多/偏了( ･᷄ὢ･᷅ )
|
|
10
nealzhuqian OP @kurthumburgmtz97 所以我可以考虑分屏，一半是 cc 一半是 git🤔
|
 |
11
helonsy Mar 28 3
vscode 里装 cc 插件解决所有问题
|
 |
12
huaweii Mar 28 via Android 2
你要明白一件事：cursor 作为一个 AI 开发工具来说，从来都是第一梯队的。
纯后端或者没有做过高保真需求的伪全栈才会鼓吹 cc 一把梭😁 cc 插件+vscode 是一种相对更平衡使用方式。 |
 |
13
sakuraT1 Mar 28
装 cc 插件不就得了，体验不会差太多
|
 |
14
cairnechen Mar 28
所以我一直用 vscode 插件 还有 seletced lines 这个附加功能 目前暂时没遇到什么 CLI 能做，插件做不了的事
|
 |
15
swaylq Mar 28
说实话 cc 的 CLI 才是它的杀手锏，插件反而是阉割版。我现在的工作流是 cc 纯 CLI 跑任务，同时 VSCode 开着同一个项目看实时改动，配合 git diff 随时 review 。关键是 cc 可以用 worktree 开多个分支同时跑不同任务，这是 cursor 做不到的。你提到的 agent teams 多开才是 cc 真正拉开差距的地方——cursor 再怎么整也只能单线程干活。习惯了之后回不去 cursor 了，就是刚上手会有一段不适期。
|
 |
16
soulflysimple123 Mar 28
cursor 里面开个终端用 claude code
|
 |
17
rogerer Mar 28
claude 通过 claude code 可以把数据飞轮跑起来，用的人越多，claude 模型越强，然后用的人就更多了
|
 |
18
8888888888 Mar 28
我觉得#5 #12 的说法是合理的，只有纯 vibe coding 的才适合这种，正常公司业务开发都是存量项目迭代，没办法不看代码完全 vibe coding
|
 |
19
xyooyx Mar 28 1
以前我们写汇编，照着指令改，后来高级语言出现了，我们只专注高级语言的语法不再去纠结汇编指令。 [汇编和高级语言] 类比 [高级语言和自然语言]
|
 |
20
fds Mar 28 1
你用 terminal 分个屏开个编辑器就能看呀，系统又不是单线程的。我目前用 Ghostty ⌘⇧D 下分屏，然后进行各种操作，完事了 ⌘W 关掉。claude code 里面也可以输入 ! 然后立即执行 shell 命令，比如 ! zed . 开编辑器。
|
 |
21
jeremaihloo Mar 28
@swaylq cursor 也有 worktree 功能，多个任务并行跑完全没问题的，不存在只能单线程干活的情况
|
 |
23
andforce Mar 28 via iPhone
|
 |
24
BerniLin Mar 28
跟我一样，离不开编辑器
|
 |
25
Cbdy Mar 28 1
Curcor, Vibe Coding, 结对编程
Claude Code, Agentic Coding, AI 自主编程 |
 |
26
evamayy Mar 28
插件挺好用的
|
|
27
nealzhuqian OP @swaylq (｡ì _ í｡)我再试试哈，过渡一下
|
|
28
nealzhuqian OP @8888888888 嗯有道理，结合一下先
|
 |
30
winnerczwx Mar 28
我刚开始用 codex 的时候也很不习惯, 我就奇怪为什么我看代码还要跳转到 vs code 去?
最近高强度用 codex + cladue code cli 以后, 我感觉他们这么设计真没毛病, 看代码的时间真的大大减少了, 平时检查代码里某些细节都是直接让 ai 去干了, 现在几乎很少用到代码文本编辑区域了 |
|
31
nealzhuqian OP @BerniLin ¯\_(ツ)_/¯ 兜兜转转未来谁知道呢是吧
|
|
32
nealzhuqian OP @winnerczwx 👌🏻看来我得继续适应一下
|
 |
33
nc Mar 28
左边 GitHub Desktop 右边终端运行 Claude Code
|
 |
34
imycc Mar 28
我自己还没适应纯 vibe coding ，所以我是 Trae/Antigravity + Claude Code 混合用。一些简单的函数补全，小修小补还是喜欢编辑器的自动补全。Trae 之类的可以通过 GUI 来查看代码变化历史，尽管 Claude code 的编程效果更好，但是从交互层面我还是更喜欢这种有客户端的。
|
 |
35
ixcode Mar 28 1
你用 C 语言编码的时候会看编译出来的汇编吗？你把自然语言当成编程语言，是不是就好接受一些。
|
 |
36
scegg Mar 28
先让 cc 写设计文件。你来审查。
之后直接生成代码和测试脚本，然后让 IDE 或者 CICD 来跑自动化测试。 |
 |
37
xiebow Mar 28 1
我是在 ide 里的终端开 claude 或者 codex ，这样两者（ claude 输出和代码）就可以同时看了
|
 |
38
BeautifulSoap Mar 28 1
claude code 的很多设计的目的就是纯粹在逼着你不 review 代码改动，让你放弃对代码细节的掌控，这也是 anthropic 对 ai 编写代码的想法，也是现在很多 vibe coder 所鼓吹的“正确的 AI 时代的编码方式”
所以我现在根本懒得用 claude code ，因为你根本没法 review 和它每轮对话后的代码，最终生成的代码你根本无法立刻掌控并且及时人工干预 我现在很爱 codex ，至少 codex 结合 vscode 插件每次对话后会给你这次对话的 diff ，而不是让你在失去对代码的掌控这买上一路狂奔 |
 |
39
badboy200600 Mar 28
我也是 cursor 用习惯了, 感觉 codex 的 vscode 插件用起来好不舒服
|
 |
40
jonty Mar 28
/ide 可以同步改动到编辑器上查看 不影响
|
 |
42
lod Mar 28 2
@ixcode 且不说自然语言本身就不如编程语言精确，llm 作为“概率模型”实际上每次都在抽卡，相比图片/视频生成，代码作为“中间产物”的优势在于可以审查和低成本修改，纯靠“vibe coding”就等于放弃这种优势
|
 |
43
lucifer9 Mar 28
neovim 开个 terminal 跑 Claude Code 不就结了？
|
 |
44
erwin985211 Mar 28 1
跟我之前一样，总想着看它该总想看他改了哪些代码，甚至都不让他直接改代码，让他把代码发出来，我自己粘。后来我同事跟我说：“你管他写什么，你直接用不就行了，只要没 bug 就行。”我一下子释怀了，vibe coding 就是这样。
|
 |
45
akira Mar 28 1
是的，开发范式转移了。 你需要把你的 思路 ，想法， 形成规范 和 需求 ，让 AI 能明白你想怎么做。
|
 |
46
lneoi Mar 28
看结果别看代码了，模型跑的代码量太大，人工一个个慢慢审核搞不定。看大结构大方向，重点复杂的地方。我一般会一边开着 vscode 辅助看看，一边用大模型跑
|
|
47
nealzhuqian OP @jonty 哟，回去试试，每日小技巧 get+1 😀
|
 |
48
xiangran0028 Mar 28
之前也无法理解为什么用 CLI 这个设计，但是高强度使用之后，发现我确实不怎么看代码。
|
 |
49
zisen Mar 28
我个人这几个月收敛下来是 vscode 写需求文档，codex/claudecode 看需求文档解决需求，然后 codex 自己跑一遍 review ，然后人工在 vscode 里 review ，最后让 codex 总结并提交
|
 |
50
Bad0Guy Mar 28 1
我是让 codex 审查了 cc 写的 plan 跟 prompt 之后再下手，以及每次改完后让 cc 显示改动后的代码，这些全都写进 prompt 里，然后全部都在终端里完成。bug 以及 cc 自行乱生产的代码会少很多，现在偶尔打开 cursor ，一个月就那么一两次，以前基本天天都要开着
|
 |
51
lerry Mar 28
搭配 git 工具和 vscode 使用
|
|
53
nealzhuqian OP @zed1018 我猜可能是 cc 生成完就生效了，没跟 vscode 做联动。cc 可以按两次 esc 主动撤回，所以必须依赖 git 才好区分改动，同时不能有多个改动一次 commit 的坏习惯了
|
 |
54
runtime0 Mar 28
一样，离不开 GUI ，并且 AI 写完代码我基本都会扫一眼。。。
|
 |
55
ksc010 Mar 28
新项目：不涉及数据修改的（不可逆操作）我敢让 cursor 写，基本可以不看代码（但是部分情况下，必须指定 把 xxx 修改成什么样 才行， 不然 cursor 一直修改不好。
老项目： 正在线上运行的， 涉及线上业务的， 我是一点不敢不做 review 。因为业务太复杂了， 我自己语言描述都不是一两句能描述清楚的，所以也也不认为 AI 能通过已有的代码理解业务上下文关系 |
 |
56
junas7 Mar 28
我的感觉是 git 要多提交，提交完再对 CC 提下一个改动，这样每次才能方便找代码
|
 |
57
nuo7mi7 Mar 29
都 vibe coding 了，还去看什么代码，这才是未来的大方向，你想去检查那就让另一个模型再去检查代码就行了，人就应该解放自己，大势所趋
|
 |
59
jaoyina Mar 29 via Android
很简单，在 vs code,里用 claude code 不就行了。
|
 |
60
HHHans Mar 29
个人比较悲观的看法是任何 IDE （包括 cursor ）都快被扫进历史垃圾堆了，从今年初开始就是这个趋势，下一代模型能力进步就应该实现了，vibe coding 、vibe design 需要演进的方向是可视化监控整体架构，而非具体实现
|
 |
61
QS0x01 Mar 29 1
还看个鬼的代码，现在还看代码的只能说公司内 ai 改革的风还不够热，迭代的速度不够快。
ai 花一个小时写完半天的需求，代码量你自己 review 一整天都未必看的完。 初期你可能还会看看大致的架构方向有没有出问题，后期你会发现反正真正关键的细节你也没那么容易找到，不如直接换个模型把上下文清了让 ta review 和 test |
 |
62
sjdhome Mar 29 1
我同时开三个终端，分别跑 LazyGit + 调试环境 + Claude Code 。Claude Code 写完了就去 LazyGit 看改动，没什么问题就去调试环境看效果，测试完就让 Claude Code 给我 commit 。
|
 |
63
codesnowjava1 Mar 29
@sjdhome 这个 6
|
|
64
ixcode Mar 29
@lod 你说的对，但是放弃了这个优势，可以带来其他优势，比如可以不用写重复性的代码，更快去验证一些功能，更高效的去对比一些实现方案，更快的去做技术栈的迁移，更完善的文档和 commit message 。还有就是可以让更多的人都具备编写软件的可能，这对哪些不会编程语言的人是另一种优势。
|
 |
66
cutchop Mar 29
习惯就好，我现在很少检查代码了，也就很少打开 cursor 了
|
 |
67
goodspb Mar 29
所以我是：vs code + cc
|
 |
68
Sundayz Mar 30
纯 vibe coding 的，自己单干没啥问题，但在公司生产环境，这么搞真不怕背锅吗？
|
 |
69
zzz2021zzz Mar 30
反重力的两种模式就是这两个方式的代表（传统 ide+插件形式的 vs 完全 vibe coding 不看代码）的，交叉使用，目前还是比较适应前一种模式，完全不看代码着实还是不放心
|
Select Language