guyeu

@SSang #6 你这个有点滑坡了，shell 、makefile 是用来管理环境的工具，IDE 也可以是呀，集成开发环境的本意就是把一堆复杂的配置集中化管理，减轻程序员的心智负担，shell script 和 makefile 其实也都是我们集成环境的一部分。

我认可环境配置应该与个体无关，任何开发者有权根据自己的偏好选择自己的开发工具，项目本身不应该阻止开发者发挥自己的创造力，但作为团队无疑是要在集体的取舍和个人的偏好之间取得一个最大公约数，在这个过程中，IDE 并不构成障碍（无论是 IDEA 还是 GoLand ，都会解析被广泛使用的构建工具链的配置文件 pom.xml/build.gradle/go.mod ），在这个层面 IDE 的差异就已经被抹平了。

我自己摸索下来的经验，是 Java 作为一个被最广泛使用的编程语言，涉及了无数领域，每种领域都有自己的特异性，而 Java 同时作为一个发展良好的编程语言，每一天都有新的工具出现，每六个月就会推出一批新的语法，要广泛覆盖所有的需求，并适配工具的发展，目前而言没有人比 JetBrains 这家商业公司做得好，eclipse 基金会不行，为爱发电的 Emacs/Vim 的扩展的开发者们也不行。实际上，我也用过 VSCode 的 Java 扩展包，VSCode 的开发者们无疑为它付出了很多的努力，在足够主流或者比较初级的用户需求上面，VSCode 已经超出了我的预料。

作为开发者，如果你对自由软件的喜爱超出了对效率的追求，那么花费一些精力去创造自己的开发环境，甚至反哺社区，我觉得是很好的一件事。如果只是浅尝辄止，那么不管是某款知名编辑器，还是免费或者社区版的 IDE ，我觉得应对偶尔的开发需求都够用。作为商业软件的开发者，我觉得没有理由在雇主愿意支付 IDEA 的费用的前提下，给自己找麻烦（其实大多数情况下社区版是完全够用的，现在社区版和商业版也已经合流了）。

把你的系统规范标准灌输给 AI ，它不能直接生成符合你要求的组件吗？

我花了一天时间配置 Emacs 来编辑我的 Java 项目（ Emacs 的 lsp-java 后端是和 VSCode 一样的 jdtls ），遇到了茫茫多问题，这套工具依赖 eclipse 基金会一串项目，大多数问题都需要这一串项目都做对应的修改，较古老的 issue 可以追溯到 16 年。

于是我明白了一件事：没有人不用 IDE 开发 Java 。

咋等于的？

devcontainer ？很难评。

刚需就买吧 当消费品买 不要考虑增值（不要当作投资去考量）

——刚需都是相对的，有时候想开了需求也就没那么刚了。

相模原创 001

一直再用 github copilot ，MCP/Agent 的操作就在命令行用 LLM 调其他的大模型，目前没有啥痛点。

我是迷你主机（ Intel NUC ）+硬盘盒+Unraid ，上面就跑了个 HA 、几个影片刮削服务，plex 和旁路由（ OpenWrt ），功耗很低，也比较稳定。