SSang

不是因为降本增效吗？

我的观点就是：我们可以批评 Vibe Coding ，但不要把所有的错都怪在 Vibe Coding ，如果你认为他不正确，那不用就好了。

以及，AI Coding != Vibe Coding

我认同你的部分说法，但并不完全认同，因为并非所有问题都是一致的，你说的我觉得更多对于解决特定问题是正确的思路，但对于业务开发来说，这并不一定适用：

> 对程序员而言，长期过度依赖自然语言来表达和解决问题，可能会削弱原有的编程思维。

我不认同。我认为大部分程序员最欠缺的就是表达能力（我不特指自然语言表达能力，因为我也不认可 prompt 要用自然语言表达）。对于解决特定的问题，我认可 “Talk is cheap, show me your code”，但对于需求（特别是产品层面的需求），我从来都不认可 Framework First 或者 Coding First （除非要解决的是工程化问题）。一个业务功能，我从来都是要求设计优先，甚至是配置优先（先写你要怎么配置 —— 我会说 `Design is cheap, show me your config`）。

我认为 AI 的出现就是一个契机，那些连需求都表达不清楚的人，他们连 AI 都用不好。最终一定会被淘汰。

> 面对问题时的第一反应不再是 “先敲一段代码试试深浅”，而是 “先写一段 prompt 问问 AI”。

我认为，对于 **业务开发** 的程序员：

首先不应该有 “先敲一段代码试试深浅” 的这个想法
也不应该有 “先写一段 prompt 问问 AI” 这种想法
你的第一件事情应该是 “先理解自己的需求”

AI 的出现正在迫使部分人员准确的描述（理解）需求，我认为这是好事。

> 指望 AI 直接生成解决方案，或者更多时候是在这个基础上 review 。

归根结底极力推崇 AI ，但我一点也不喜欢 Vibe Coding 这个概念（或者是狭义的 Vibe Coding ）。
这个狭义的理解正在 **纵容** 人们把 AI 当成神话一样的存在，纵容人们对 AI 的不切实际幻想。

一个标准的生产流程（无论是在哪个行业哪个岗位）都应该是类似：调研、（分析）、设计、验证、实施、迭代。（ Vibe Coding ）
而狭义的 Vibe Coding 理解正在引导人们将这些步骤简化为：提出问题，生成答案。

而我认为，正在践行这种理念的人，即使没有 Vibe Coding ，他原本的习惯也一定不是很好。

@guyeu 但作为一个 gopher （我接触 Java 项目的机会不多），我确实不太用 IDE 开发 Java （虽然我用的是很多插件的 vim ，但工程化我一般都是用 shell makefile 之类的解决的，Vim 主要还是用来语法高亮和补全）。

环境配置，本就应该与 IDE 无关，这样团队内才能一致。

你要学会抓包，不然哪天一更新，加了一个 url ，那你不又要来问一次。

你用 ssh 的话，需要 terminal 支持 control master （连接复用最主流的应该就是这个了），我不确定 windterm 是否支持，或者也许他还有其他复用连接的方案。

应该理论上和堡垒机无关？因为是连接复用（我猜的）

https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/ics-not-work-after-computer-or-service-restart#symptoms

Generally, if there is no traffic on ICS for 4 minutes, the service shuts down and does not restart automatically.

通常，如果 ICS 在 4 分钟内没有通讯，服务将关闭并且不会自动重启。

几年前我也遇到过，不知道和你是不是同一个问题：

参考一下当时写的： https://www.zhihu.com/question/29477333/answer/3045489415

你可以尝试一下我的方案（后台长 ping 网关）能否解决，如果能解决，大概率是同样的问题。

看看 ggml 的模型： https://huggingface.co/collections/ggml-org

ggml-org/Qwen3-0.6B-GGUF
ggml-org/Qwen2.5-Coder-0.5B-Q8_0-GGUF
ggml-org/gemma-3-270m-GGUF