引子
平时做个人项目，我的出发点大多比较单纯：要么是出于兴趣想做点东西，要么是想写个顺手的小工具来方便自己的日常工作。
随着近两年开始频繁使用 AI 辅助写代码，我发现过去很多习以为常的选型逻辑发生了一些变化。借着整理手头代码的机会，我花时间梳理了一下，想为自己未来的个人项目确定一套相对固定的技术栈。
关于 Delphi 与 Java 的取舍
Delphi：虽然喜欢，但语料和生态较少
我最早是写 Delphi 起步的。即便到了现在，我依然觉得 Delphi（Object Pascal）是一门设计得很舒服的语言。虽然没有主流语言常用的花括号，但通过 begin...end 组织的代码块读起来很清晰。
不过客观来说，Delphi 现在的用户群体已经很小了。不仅很多现成的库需要自己写，更现实的问题是，大模型的训练集里关于 Delphi 的代码相对较少，AI 写出来的质量和效率并不理想。所以虽然很喜欢，但它确实不太适合作为当下的主力语言了。
Java：适合工作，但在个人项目里偏重
在日常工作中，我写 Java 的时间最长。Java 的生态完整、规范成熟，在企业开发中依然是很好的选择。
但在个人项目里，Java 的缺点就比较明显：
- 前期准备偏多：简单的功能也需要处理相对复杂的项目结构和配置，写起来不够快。
- 资源占用偏高：打包出来的文件偏大，运行时占用的内存也比较多。我平时租用的个人 VPS 配置有限，跑几个 Java 程序负担会比较重。
因此，在个人项目里我尽量不打算继续用 Java。
前端部分：为什么不选用现代前端框架
在 Web 开发上，我选择避开 React、Vue 这类主流的前端框架。
主要原因有两点： 一方面，我过去对前端并不太熟悉。加上现代前端框架和构建工具更新比较频繁，隔段时间不接触就会发现很多概念变了，出于成本考虑，我不太想花太多精力去跟进这些变化。
另一方面，Node 生态的依赖方式会在本地生成体积庞大的 node_modules。个人写的小项目一多，磁盘空间很容易被这些依赖占满，维护起来有些繁琐。
如果只是为了给自己做个日常使用的操作界面，引入这套复杂的工具链对我来说并不划算。
核心选择：C# 与 .NET
在后端和带界面的工具开发上，我把重心放在了 C# 和 .NET 上。
我很喜欢 C# 这门语言的设计，在语言特性的推进上（如 LINQ、模式匹配、Records、空安全等）一直很积极。巧合的是，Delphi 之父和 C# 之父同为 Anders Hejlsberg，在语法和设计理念上确实能感受到某种一致的舒适感。
现在的 .NET 跨平台支持已经比较成熟。在 Linux Mint 和 Windows 下，我用 C# 写过一些小工具，配合 Native AOT 编译后，可以直接生成单个可执行文件，体积在十几兆左右，启动快，内存占用也很低，在配置不高的 VPS 或本地机器上跑起来都很轻松。
在 Web 界面上，我倾向于使用 C# Minimal API + HTMX + Tailwind CSS：
- 业务逻辑和数据接口完全由 C# 处理，直接返回渲染好的 HTML 片段。
- 前端只用原生 HTML，通过 HTMX 的属性实现局部刷新，交互体验基本够用。
- 整个流程不需要配置 Node 环境，也不需要写 TypeScript，省去了不少维护依赖的心思。
场景分类与具体选择
结合我的日常使用场景，我把不同形态的项目做了归类：
1. 命令行与脚本工具：Go
写 CLI 工具、简单的后台常驻程序或数据抓取脚本，Go 是我的第一选择。
- 编译速度快，打出来的单文件分发和运行都很省事。
- 语言本身的语法规则比较统一，AI 生成 Go 代码的准确率很高，即使遇到编译报错，AI 通常看一眼提示也能改对。
2. 桌面端应用：Windows 原生与 Linux 下的权衡
我平时主要使用 Windows 和 Linux Mint 两个系统：
- Windows：首选原生的 C# (WPF 或 WinUI)，开发顺手，和系统的契合度最好。
- Linux Mint：
- 目前主要使用 Electron：虽然我也觉得一个小工具打包出来上百兆有些浪费，但现阶段 Electron 在 Linux 上的兼容性确实最好，遇到桌面环境的问题很容易找到成熟方案，AI 对这套技术也很熟悉。为了保证开发效率，体积方面我暂时接受了妥协。
- 未来的方向是 PyQt：我不太擅长 C++，如果之后想在 Linux 上写更轻量、更原生的界面，PyQt 应该是我最实际的选择。
3. 移动端应用：以 Android 原生为主
移动端我的个人需求较少，加上手里没有 iOS 设备，因此完全不需要考虑跨平台适配。
之前我尝试过 Flutter，也写过几个小型应用，体验是不错的。但考虑到当前的使用场景：
- 首选 Android 原生（Kotlin + Jetpack Compose）：因为有长期的 Java 背景，写 Kotlin 很容易上手。原生应用的权限调用和后台服务支持得最直接，AI 写 Compose 代码也比较熟练。
- 备选：如果未来真有做多端适配的需要，我再考虑用回 Flutter。
AI 协作方面的现实考虑
除了语言本身，日常使用的 AI 工具和模型能力也是影响选型的一个重要因素。
我的使用情况是：
- 公司环境：使用公司付费的 GitHub Copilot，可以使用能力较强的旗舰模型。
- 个人环境：使用 opencode，订阅了 opencode go。
在个人开发中，我使用的是常规额度内的模型。这就要求我所选的技术栈最好具备两个条件：
- 训练语料充分：Go、C#、Kotlin 在主流开源代码中很常见，AI 对它们的编码惯例很熟悉，不容易出现莫名其妙的写法。
- 编译器能提供清晰的反馈：在模型能力有限的情况下，动态语言一旦逻辑出错，排查起来有时比较费周折；而 Go、C# 和 Kotlin 都是强类型编译型语言，编译器给出的报错信息通常很精准，AI 往往能根据报错直接把问题修正。
数据存储与运行方式
在代码之外的配套环境上，我也尽量保持简单：
- 数据存储：使用嵌入式 SQLite 或 DuckDB。数据保存在单个文件里，不需要单独在系统里跑数据库服务，备份也只需要复制对应文件。
- 服务运行：使用 Docker Compose 配合轻量基础镜像运行，部署和清理都比较方便。
- 构建脚本：Linux 下写一个
build.sh，Windows 下写一个build.ps1，把常用的编译和测试命令记录下来即可。
结语
整理下来，目前适合我个人的技术组合大致是：
- 系统工具 / CLI：Go
- Web 业务 / 工具：C# (.NET + HTMX)
- 桌面端：Windows 下用 C# 原生，Linux Mint 下目前用 Electron（后续探索 PyQt）
- 移动端：Android 原生 (Kotlin)
这套选型算不上什么前沿方案，但它既照顾了我对语言风格的喜好，避开了我不熟悉且不想跟进的前端构建体系，也符合我在个人环境下的 AI 工具能力。对我来说，能够以较低的精力消耗把想法做出来，并且在后续不需要花太多心思去维护，就是最合适的状态了。