没有编辑器， 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 ，能跑就行了

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

提供上下文给 ai 时，没办法精确关联到文件第几行

----

我同时开着 vscode 用来 diff review. 改旧项目不可能纯 cli 的, 上下文一多, 把你角落里的看起来不相关的代码就删了.

同时还装着个插件, 可以把多行的代码同时发给 cc, cc 自带的 vscode 插件好像只能带上连续的区域选中, 不能跨行跨文件

src/background/service_worker.ts:252-252
```
chrome.runtime.onInstalled.addListener(async () => {
```

src/background/service_worker.ts:260-260
```
chrome.runtime.onStartup.addListener(async () => {
```

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

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

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

核心问题不是你“看不到代码”，而是你“看不完代码”。

cli 形式的代码 agent 就是为了极高速度地产出，就是干碎人眼干碎人脑的。

这种产品不是给你“人”写代码的。人家就是为了取代你来写代码的。

所以从设计上人家根本不 care 你能不能看代码，怎么看代码，“爱咋看咋看，llm 不在乎”。

可以关联到行啊 你看看说明, 比如 @filename (lines 50-60)

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

@yoshiyuki 同理，我们也不再做任何的 code review ，用 e2e 测试证据替代

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

@ooooo00000ooooo 请问主题用的是哪个

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

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

直接 git diff 不就完了吗？