我是一个主要写 C、Lua、OpenResty 和 Perl 的后端开发者。C#、Swift、WinUI 3、Windows 桌面开发 —— 这些对我来说都是完全陌生的领域。

我想做一个实验：在一个自己完全不熟悉的技术栈里，纯粹依赖 vibe coding，能否交付一个可发布的桌面应用？

这里的关键词是「完全不熟悉」。我不会 C#，不会 Swift（原版代码），不会 XAML，也从来没做过 Windows 桌面开发。我想排除掉自己真正会的领域知识，纯粹体验 AI agent 驱动开发这件事本身。

最终的结果是：24 天，从零到 Windows Store 上架，19 个翻译服务，715 个测试用例。

工具链

全程只用了两个 AI 工具：

• Claude Code — 100% 的编码工作（编码、调研、调试、重构、测试、文档）
• GitHub Copilot Review — PR 级别的代码审查

没用 Cursor，没用 Windsurf，没用 ChatGPT。编辑器就是 VS Code，但几乎不手动编辑代码。

AI 和人的分工大致是 90% AI : 10% 人。我的 10% 主要花在方向决策（选 WinUI 3 还是 Tauri、先做哪个功能）、让 Claude Code 解释代码和方案然后从中挑一个合理的、最终审查、以及当 AI 卡住时提供思路。

最初我是在 WSL 上运行 Claude Code 的。这个阶段体验比较割裂：在 WSL 中让 AI 修改代码，然后同步到 Windows 目录，再用 VS Code 进行编译调试。两个环境来回切换，效率不高。后来我直接在 Windows 上安装了 Claude Code，整个流程立刻丝滑了很多 —— AI 改完代码就能直接编译运行，所见即所得。这也是后来效率能起来的一个重要因素。

起源与方案抉择

Easydict 是一个 macOS 上很好用的翻译词典应用。我想把它移植到 Windows。

最初的想法很简单：保留 Swift 后端代码，只在前端用 Windows 生态写一个 UI。我用 vibe coding 调研了几个方案，最终保留了两个并行开发：WinUI 3（微软官方的 Windows 桌面 UI 框架）和 Tauri（基于 Rust + Web 技术的跨平台框架）。

两个方案并行推进后，很快发现一个共同的问题：后端代码也必须全部移植。保留 Swift 后端的想法行不通，要么依赖链极其复杂，要么在 Windows 上效果很差。

然后 Tauri 方案更先遇到了阻碍：编译环境太复杂，我始终无法跑通一个 POC 样例。而 WinUI 3 那边已经跑出了第一个可运行的 demo。于是放弃 Tauri，全力 WinUI 3。

后端选用 .NET 8（LTS 版本），在 Windows 上体验非常顺滑。整套 C# + WinUI 3 + .NET 8 的组合在 Windows 生态里确实是一等公民。

POC 阶段我直接在 Easydict macOS 版的源码目录中新建了一个子目录进行开发¹，等到 POC 跑通、确认方案可行后，才完全新建出独立项目，脱离原来的源码仓库。

原型与功能堆叠

UI 设计上我几乎是放手让 AI agent 去做的。只提了几个简单要求：尽量复用 Easydict 原版的图标资源、保持简洁干净的界面风格、支持 Dark/Light 主题。效果基本满意，也就是现在大家看到的这个版本。作为一个完全不懂 XAML 的人，这个结果超出了我的预期。

原型跑通后，开始一个功能一个功能地堆。这个阶段的关键策略是：用 Git 逐功能提交。 每完成一个功能就提交一次，防止后面的改动导致前面的功能失效。这是后端开发者的基本直觉，但在 vibe coding 里格外重要 —— AI 有时候会在添加新功能时意外破坏已有的代码。

等有两三个功能可以正常运行后，我就开始补测试用例。2026-01-20 添加了第一批单元测试框架（xUnit + FluentAssertions）。

PR 并行开发

把代码推到 GitHub 后，开始用 PR 工作流来并行堆功能。这时候发现一个意外的好搭配：GitHub Copilot Review + Claude Code 配合得非常好。

我的开发 loop 是这样的：

Claude Code 写代码并提交 PR
    → GitHub Copilot Review 发现问题，提出 review 意见
        → Claude Code 读取 review comments 并 resolve
            → 提交
                → 再次 review
                    → loop 直到通过

代码质量在这个 loop 下基本能保证。而且因为多个 PR 并行推进，在等 Copilot review 或者 Claude Code resolve 的时候，我就切换到下一个功能的 PR，效率很高。

这个过程中能用到的基础知识不多。我完全不会 C#，也不会原版的 Swift 代码。基本是让 Claude Code 解释给我听，我从中挑一个合理的方案。偶尔用通用的软件工程直觉做判断，比如「这个设计耦合度太高了」或者「这里应该加个接口抽象」。

发布历程

v0.1.0 — 首次发布 (Day 5)

项目启动 5 天后，发布了第一个可用版本。同一天建立了 CI/CD（GitHub Actions），合并了第一个 PR (#1)，开始有了基本的自动化构建和测试流水线。这个速度在传统开发模式下是很难想象的 —— 我甚至还不会 C# 的基本语法。

v0.2.0 — 分水岭 (Day 12)

项目启动 12 天后，同时向 Windows Store（MSIX 格式）和 WinGet（Portable ZIP 格式）两个渠道提交了发布版本。

这个版本是一个重要的分水岭。它标志着这个 app 开始走向正轨 —— 最终用户可以通过正常渠道安装使用了，我可以开始收集真实用户的反馈，而不是把它做成一个需要开发者本地编译才能用的硬核工具。

但发布过程远没有想象中顺利。这个版本一共打了 17 个 Release Candidate (RC)，从 rc1 到 rc17，历时 2 天。主要的坑在 MSIX manifest 配置：MinVersion 的设置要求、架构支持配置²、图标资源规格要求、Store 提交的合规性检查。这些问题一个一个冒出来，每次改一点就要重新打包、测试、提交 —— 所以产生了 17 个 RC。

MSIX 图标模糊事件

打包成 MSIX 之后，发现了一个顽固的问题：开始菜单的图标非常模糊。奇怪的是，.zip portable 版本完全没有这个问题，只有 MSIX 安装版才会出现。来回折腾了好多个版本才解决。根本原因是 MSIX 包对图标资源有特殊的尺寸和格式要求，和普通的 .exe 图标处理方式不同。

测试与性能

为了提升稳定性，逐步建立了多层测试体系：单元测试（Day 4）、集成测试（Day 12）、UI 自动化截图（Day 14）、UI 回归测试（Day 15）。有了这些之后，我的本地验证工作解放了很多 —— 直接在 CI 里看自动截图就知道有没有界面衰退，不需要自己手动跑应用去一个个功能点检查。

到了后期开始关注性能。尝试加了 performance 回归测试，用于监控鼠标划词翻译和应用启动等热路径的耗时。不过目前这个测试框架还不能很直观地证明某个改动没有影响性能 —— 性能基准测试的稳定性在 CI 环境下波动较大。这个后面需要更多研究。

AI 超出预期的地方

整个过程中，有两个方面 AI 的表现明显超出了我的预期。

第一个是架构设计。AI 提出的整体项目结构非常合理：Solution 拆分为 Easydict.WinUI（UI 层）、Easydict.TranslationService（业务逻辑层）、Easydict.SidecarClient（IPC 层）；Streaming 翻译架构用了 SSE + IAsyncEnumerable<string>，这是 C# 中处理流式数据的惯用方式³；Translation Service 的继承体系设计得很清晰：ITranslationService → BaseTranslationService → BaseOpenAIService，新增一个 OpenAI 兼容的服务只需要继承 BaseOpenAIService 并提供 Endpoint/ApiKey/Model。这些架构决策如果让我来做，即使我会 C#，可能也需要几次重构才能达到这个设计水平。

第二个是调试能力。当出现 bug 时，AI 能够自己定位问题并修复，成功率相当高。尤其是一些 WinUI 3 特有的坑（比如线程调度、COM 对象生命周期），如果是我自己调试，可能会花大量时间在搜索文档和 Stack Overflow 上。

工具链的坑

除了代码层面，工具链的坑比代码的坑更多。

MSIX 的打包、签名、提交 Store 的整个流程非常复杂。manifest 里的每一个配置项都可能导致打包失败或 Store 审核拒绝。v0.2.0 的 17 个 RC 大部分时间都花在了这里。

GitHub Actions 的 Windows runner 环境和本地开发环境也有很多微妙的差异：Windows App SDK 的版本和安装状态不同、WinUI 测试需要图形界面环境在 headless CI 上大部分会失败、MSIX 打包在 CI 上需要额外的工具链配置。这些问题 AI 可以帮忙解决，但往往需要多次尝试。因为 AI 能给出的方案是基于文档和通用知识的，而实际的 CI 环境是一个黑盒，只能通过 push → 看日志 → 修改 → 再 push 的循环来调试。

总结与建议

Vibe coding 适合什么场景？ 探索陌生的技术领域，快速出原型。这是 vibe coding 目前最大的价值。24 天从零到 Store 上架，如果没有 AI，以我对 C#/WinUI 的零基础，这个时间线至少要翻 5-10 倍。

但基础工程能力仍然不可或缺。即使 90% 的代码是 AI 写的，剩下的 10% 人类干预仍然至关重要。这 10% 不是写代码，而是 Git 工作流（逐功能提交、PR 并行、分支管理）、CI/CD 思维（尽早建立自动化流水线）、测试策略（什么时候该补测试、补什么级别的测试）、发布策略（尽早交付到用户手中获取反馈）、架构判断（从 AI 给出的多个方案中选择更合理的那个）。这些都是通用的软件工程能力，和具体的语言或框架无关。Vibe coding 降低了技术栈的门槛，但没有降低工程素养的门槛。

给想尝试 vibe coding 的开发者几条建议：

1. 选一个你不会但想学的领域 —— vibe coding 最大的价值不是替你写你会的代码，而是帮你做你不会的事
2. 尽早建立 Git + CI + 测试 —— 这是你唯一的安全网，AI 会犯错，而且犯的错往往不容易发现
3. 用 PR review 工具做质量门禁 —— AI 写的代码需要另一个 AI 来 review，人类负责最终裁决
4. 尽早发布 —— 不要等「完美」，先交付一个最小可用版本
5. 保持方向感 —— AI 可以做 90% 的执行工作，但那 10% 的方向决策只有你能做

项目数据

关键指标

各模块代码量

里程碑时间线

2026-01-16  Day 0   项目启动，首次提交
2026-01-20  Day 4   添加单元测试框架 (xUnit + FluentAssertions)
2026-01-21  Day 5   v0.1.0 发布 + CI/CD + 首个 PR (#1)
2026-01-25  Day 9   MSIX 打包 + WinGet 发布工作流
2026-01-26  Day 10  Windows Store 提交工作开始 (17 个 RC 迭代)
2026-01-28  Day 12  v0.2.0 正式发布 — 分水岭（Store + WinGet 双渠道）
2026-01-30  Day 14  UI 自动化测试 + 截图验证
2026-02-01  Day 16  v0.2.2 + UI 回归测试
2026-02-02  Day 17  v0.2.3 + 鼠标划词翻译 + Copilot Review Loop
2026-02-03  Day 18  性能基准测试
2026-02-04  Day 19  v0.3.0 (Inno Setup EXE 安装包 + GitHub Pages 官网)
2026-02-06  Day 21  v0.3.1 / v0.3.2
2026-02-08  Day 23  v0.3.3 / v0.3.4

19 个翻译服务

Google Translate, Google Web, Bing, DeepL, OpenAI, DeepSeek, Gemini, Groq, Zhipu AI, GitHub Models, Doubao, Volcano, Caiyun, NiuTrans, Linguee, Youdao, Ollama, Built-in AI, Custom OpenAI