raid5 坏两块，基本可以宣判死刑了。

AIO ，RAID5 ，你这个 debuff 叠满了啊。

既要还要不现实，而且变化太快了，花点钱吧。

买 GLM 、M2 、K2 的 Coding Plan 啊，基本上所有工具都能接。你这个问法太奇怪了，看标题以为是工具比较，一进来居然只是在比价格。

不如直接 grafana

你要更安全一点，那就是 VPN ，SS 代理，这种要转一层回去的

还有 frp 真的水管太小了，有条件还是 ipv6 吧

你只要暴露公网，就不安全，真要黑你，防不住的。不是你用什么姿势的问题，是如果你的软件本身就有漏洞，那你怎么防搞他都有漏洞。

但是不要因噎废食，第一全网的扫描不会做很复杂的操作，又不是定向爆破，不要怕，第二，大部分出名的软件都经过市场检验的，而且大家都在用修复的也快，你看像 dify 这种，一爆出漏洞马上光速修复了。

你要做的是就是重要做好备份，敏感数据做好加密，就行了

为什么我第一反应是说 makefile ，是因为我觉得 makefile 是最语言无关的了，不管写什么的，肯定都能理解。而如果有多语言的项目，也会选择 makefile （而且实际上 win 也能用 makefile ）

> 在这种情况下 make 和 shell 就是项目依赖了，我用非 unix 的环境打开这样的项目就要先去配 make 和 bash 这些，也是一种心智负担。

并不需要配，如果你的脚本本身就是跨系统兼容的的，比如 `go` `git` `protoc` 那你用 makefile 写还是用 cmake 还是其他，都是一样的。如果本身不兼容，那 gradle ，cmake 也不是银弹。

shell 的话，如果你有 win 开发环境，那你同样要写 bat 。一定有场景必须写脚本。

> 比如说如果我的项目需要先生成 protobuf 的文件，那么我会把编译.proto 的步骤放到 gradle 、build.rs 、cmake 自定义 target 里面，除非迫不得已是不会写 shell 和 makefile 的，这样 IDE 和 LSP 可以无痛启动项目，生产环境编译的时候也可以直接出成品。

protoc 生成放到自定义 target 本质上就是脚本，是一样的。我希望你不要纠结 makefile ，makefile 只是我举的例子。我如果写 node 我就会放到 package.json 用 npm run gen ，写 go 就会放到注释用 go generate ./...，写 python 就会放到 uv.lock 用 uv run gen 。

@Tyanboot 我理解你的意思了。我觉得我们的理念是一致的。

我们的目标就是要保证 90% 的代码都能开箱即用，和保证代码能在 90% 的环境开箱即用，以及编译产物 100% 一致，这个其实是不同的事情。

为了保证 90% 的代码开箱即用，我们要使用 IDE （无论是使用 Vim 、还是 VsCode ，还是 Jetbrain ，他们本质上都是 IDE ，只要按照规范编写代码，那么他们都能自动帮你完成配置，不过通常 Jetbrain 配置起来会更省心一点）

为了保证代码在 90% 的环境开箱即用，就要按照规范写好 java 的 gradle ，maven ； Clang 的 cmake ； golang 的 go.mod ，GOENV ； python 的 requirements, uv.lock 等；这样 IDE 才能自动的帮你配置好环境。这些就是工程化的一部分了。

而为了保证编译产物的 100% 一致，我们可能还需要进一步的工程化，比如编写 docker 交叉编译脚本（ build.sh, build.bat ），或者编写好 Gitlab CI ，Github Actions 等。

以上这些应该都是我们共识的。

-------

而我想说的就是，我们应该尽可能按照规范开发。这就是我一开说的 “与 IDE 无关”。我不是说所有东西都要用脚本配置啊。我也就写个 `make init` 罢了。

而且你想想嘛，我也不可能只用 makefile 不写 go.mod 不写 requirements 吧，那脚本得写的有多复杂，我既然写了这些，IDE 肯定开箱即用了呀，怎么可能是唯一启动方式呢。

--------

至于我后面说的 “不要依赖 IDE”，我的核心是要表达是：我们开发最重要的就是效率，这个效率不是说我今天以最快速度 run 起来了就是效率了。

1. 一个项目会有很多开发人员的，每个开发人员的环境都会有不一致，所以我们这些包管理要写好，环境配置要写好，或者至少要写好 CONTRIBUITE.md

2. 有些开发者是跨语言的，他可能也不熟悉你这个语言的开发习惯。我也不可能每个人教过去，我就说你 make init 一下他会自动识别你的系统来安装依赖的，除非你的系统真的太偏门了，不然大概率你等进度条走完，你的环境就是正确且与实际环境隔离的了。

3. 你的开发机器也可能在变化，你可能会需要换电脑，换硬盘，你的软件、工具都可能发生变化。IDE 不会帮自动就帮你做所有的事情，有些事情，你必须自己完成。

@Tyanboot

我可没有说过不要使用 IDE ，不要曲解我的话啊。不管做什么 Quick Start 永远是优先的。但是你不能把 IDE 当做你的项目依赖吧。

另外，编译讲究 “不可变”，我不知道你们是不是真的在核心生产系统不做工程化，纯用 IDE 配置，用 IDE 编译。

你今天编译出来的软件包和明天编译出来的会是同一个东西吗？你编译出来的和别人编译出来的，是同一个东西吗？

我已经听过无数次的 “我本地运行都好好的啊” 这种话了。

请务必拥抱 IDE ，但不要成为 IDE 的奴隶。

@guyeu 你说的没有问题啊。关键是我们的现状就是团队内不是所有人都用同一套 IDE ，但是一定所有人都有 shell 。

工程化没做的项目直接 IDE 打开就能用肯定是最好的，比如我要接别人的项目，他没做工程化，但我就改两行代码，我肯定优先 IDE 打开，而不是去装环境。

但是我自己的项目，我肯定是要优先工程化做好的，这样别人接手才不会有那么多心智负担。甚至我们都有 CI ，上来就改两行代码的化，用 WebIDE 都行，甚至都不用等 IDE 初始化环境。

不是因为降本增效吗？

我的观点就是：我们可以批评 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 分钟内没有通讯，服务将关闭并且不会自动重启。