没有编辑器， CLI 纯聊天写代码的方式有点儿难适应

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

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

一下改那么多文件你来得及看吗

用 vscode 的 codex 插件不就好了?

@Features 最推荐的还是用 Cli 做宏观的调整，编辑器打磨细节！

vscode 插件就行

你的感觉是对的，使用 ide 更符合你的心智模型
因为你依然对模型抱有疑虑，你的场景应该也是不能 100%依赖模型的
所以你更适合在 ide 中使用 agent ，事实上 vscode 相关都很好的集成了 codex 、cc 、opencode 之类的插件了，codex 我觉得是这里面最友好的，能直接 review ，cc 还要依赖 git diff

cli 的基本上都是 vibe 为主了，并不适合你的场景。

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

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

@KidsMk 为什么宠观要在 cli 搞，有啥优势吗？

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

这样用不就好了，而且装了插件直接光标点哪里 cli 都知道。

是这样的，我刚开始也有这种感觉，慢慢习惯就好了。

现在想通了，其实我根本不需要“对自己的代码了如指掌”，屎山又如何。

也许宏观上的架构设计，受限于上下文，现阶段 AI 不一定比得过人，但是改屎山，AI 可太在行了，越是屎山，越是只有 AI 能改。

我看与不看，之后都是交给 AI 来处理的，我的掌握毫无意义。

老板也不关心我写的是啥，我也不关心，人和代码有一个能跑就行了。

@ooooo00000ooooo 这是个什么插件？

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

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

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

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

@jedeft #14 用 claude code 就装 vscode 的 claude code 插件就好了， 它知道你在哪。

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