不是因为降本增效吗？

我的观点就是：我们可以批评 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

如果一定要本地的话，可以看看 ggml 的 0.5B 模型，我感觉这个是真有点东西，我本地补全用的 qwen2.5-coder:0.5B ，i3-14100 的 CPU ，占用 30% 左右，也能做到 1s 左右的响应时间。

qwen2.5:3b 都跑不动的话，其他模型应该也不太行了，不然试试 qwen2.5:0.5b ？不然还是调用 API 吧，API 调用的话 qwen2.5-7B 基本上能做到秒级的翻译了。我视频字幕实时翻译和网页翻译现在用的就是 qwen2.5-7B （调用 siliconflow 的 API ）

@dyexlzc 你问大模型，他只会回答你一堆“可能”

qwen 回答说：Q4_K_XL 使用了更智能的权重分组方式，能够用更少的参数达到相同的精度
claude 回答说：在 GGUF 中，K 系列的 XL 实际上可能指"eXtra Low precision"

这让我怎么敢相信。我需要的是准确的回答。

另外你的回复也不是我问的问题。

Niz66 有 35g 的胶腕。
但他不是 HHKB 配列，我是：

1. ESC 改到 CapLock （因为 Niz66 还有保留 Ctrl ）
2. Backspace 换 2U ，需要拆机剪胶腕

关灯续航应该达不到 1200h ，我工作用，好像是一个月一充吧，对我来说感知很小，所以也没啥印象多久充一次

键帽问题，我是买那种按斤卖的无刻键帽垃圾包，从里面单独找两个按键，因为根本不可能有 1.75U 的 ESC ，我单独找了一个 1.75U 的黄色的无刻 R2 来当 ESC 。单独一两个键帽还是好找的。剩下的买套件。

或者可以试试 3D 打印单独的几个键帽。

换个语言（手动狗头）

先用默认的呀，哪个你觉得不满意再去调整他

其实你这些话直接在面试时候说就好了，如果他不认同，那两边理念不符合，那就直接走。

@cookii 别急，我还没说完呢。喊 “微服务已死” 的那波人，大多都是小公司，小团队，我想说的是，微服务是不会死的，死的是那些用着微服务的小团队。

微服务设计本身并没有优劣之分，只有适合和不适合。团队有三四个人时，或服务规模扩张时，大单体可以拆成小单体，避免代码的互相腐蚀。再随着规模扩大，小单体可以拆的更小，就变成了微服务。

微服务更多的是反应的团队协作问题，而在架构设计上，微服务理念并不一定是直接体现在服务拆分上的。

事实上，你可以看看主流的架构，无论哪个架构，都在提倡 “高内聚、低耦合”，所以，微服务的 “思想” 并不是一个专利，你仍然可以在单体服务上贯彻微服务理念。“解耦本身就是优秀”

至于你说的独立库，更多的是管理上的东西，你看 K8S ，也在使用巨型仓库，但他们有优秀的上下游管理自动化脚本。所以不是说你独立了仓库就一定是最好的，工程化不是一套公式就能打完的。

而你说的分布式、可扩展，这更多的是服务拓扑，你总不能说大单体就不能分布式，就不具备扩展性，很多设计优秀的大单体，他的扩展性能远超微服务。

康威定律说：organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. — M. Conway （一个组织的系统通常被设计成这个组织通信结构的副本）

微服务起源与大型团队多人协作，你先看看你的团队有几个人。如果就两个开发有什么可微的呢？

我相信，b 站，京东，阿里，一定还用着微服务架构，因为这能解决他们的问题，但对于你的团队呢？能解决什么问题？你不知道怎样的微服务才算优秀，那你有没有考虑过你们团队，你们的项目根本不适合使用微服务呢？