SSang

买 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 的奴隶。