1

用编辑器敲代码的速度远比不过 AI 吐代码的速度
昨天要准备七个国家翻译，修改估计要十来个文件
AI10 分钟搞定，自己改改估计一个小时也搞不定

2

怎么说呢，用 Cli 就像你被蒙上眼睛下棋，明明知道规则却找不到棋子在哪，才上来那种束手无策的感觉非常不习惯，Cli 本质上就是让你描述系统行为，不是让你去敲代码的，更接近一种工程管理的本质。但是 Cli 有其他方面的好处是编辑器无法触及的，比如重构模块，大型的，几百万甚至上千万行代码的时候，编辑器就跟不上了，也不可能靠"看行号"来工作来编辑和修改代码，这时候 Cli 就登场了，能处理及其复杂的场景，准确率能高到一种令人发指的程度，你可以把 Cli 当作一种"编程副驾驶"，Cli 也更接近未来工程师的本质从执行者到决策者的转换，从代码编写者转为智能体指挥官。当 AI 能处理 80%编码甚至 90%的编码工作时，工程师的核心价值将彻底转变为定义系统行为而非实现具体逻辑！！

4

用 vscode 的 codex 插件不就好了?

7

8

@KidsMk 除非是并发操作很多个 CC 会话，不然 VScode 里的插件还是更好用一些。

9

@MuyuQ 嗯，我也用插件，但是之前遇到大厂的一个陈年项目，代码比较多比较杂，上来用 Cli 直接宏观按最新的需求搞，然后去用插件精修，这是我觉得非常舒服的方法！

11

用 ide 写代码像是程序员角色，要对自己的代码了如指掌
用 cli 写代码像是产品总监，提需求，看效果就行了，不需要自己下场看代码是啥情况。

13

15

cli 权限问题少，在 cli 安排活，写完了 ide 审阅就好了

16

现在开始，慢慢会往 IDE 发展的。

17

@jedeft 用 Cli 写代码，只需要对机器发号施令，不需要自己动手搬砖。这哪是产品总监，这简直是甲方爸爸，不过说真的，对于那种几千行的函数，敢直接宏替换的确实都是狠人。

18

@wsseo 我倒觉得是往 Cli 这种类型的发展。因为 IDE 编辑器是为了“人看代码”设计的，而未来的趋势是“AI 自动写代码，然后人审核”。对于 AI 来说，Cli 的指令交互和对全仓库的上下文掌控能力，比图形界面高效得多。以后可能就是一个终端窗口走天下，IDE 那些可视化功能反而会变得没那么重要。就像 Cursor 虽然现在是 IDE ，但它的核心交互逻辑其实越来越像是一个带界面的 Cli 。

20

@ntdll 太对了，我就是改屎山代码，一个类上万行（ 8912 行），你说这让我怎么改？直接交给 Cli ，能跑就行了

21

@jedeft 目前插件推荐用编辑器就 VsCode 和 Cursor ，你可以试试，里面可以很轻松的配置 Codex 和 ClaudeCode

22

23

很奇怪，难道有谁说用 cli 就不能打开你的编辑器或者 vscode 吗？看得过来你就看 看不过来你就只能闭眼提交呗，为什么非要非此即彼呢

24

我觉得前提你是要用一个好的专用 code 模型，用通用模型会爆炸的，到时候维护不了，ai 又改不到你想要的结果

25

AI 生成代码后，再在 ide 里浏览也差不多吧

26

28

因为代码已经不重要了，我们团队从今年春节后开始，已经完全接受软件代码是纯黑盒，只要表面上能够跑，底层屎不屎的已经不在意

30

我的工作流是 Claude Code CLI 跑任务，旁边开个 VSCode 看 diff ，两个窗口并排，不难适应。CLI 最爽的是可以一边开几个并行任务，IDE 里的插件反而串行多。

32

同样的感觉，试过 CLI 的 AI Agent 不适应还是回到 cursor 了

33

刚开始还要去研究下厨师怎么炒的, 菜从哪里买的, 有没有洗过, 油温对不对, 流程对不对, 有没有洗手
后来每次菜都太好吃了..
然后你就会管他怎么做的..端上来就吃...(就算有一次他端了一盆那啥上来)