前两篇文章我分别聊了VBA插件和Python开发的Skill化交付,有朋友看完问我:"Python不是已经能搞GUI了吗,干嘛还搞.NET?"
这个问题问得好。
Python确实能搞GUI——但说实话,能用和好用,中间差了一整个维度。
举个直观的例子:你用Python的tkinter做一个文件处理工具,界面大概长这样——灰色背景、方方正正的按钮,缩放一下窗口就变形了,发给同事人家还以为是个"内部测试版"。
同样的功能用.NET的WPF来做,圆角窗口、毛玻璃效果、流畅动画、高分屏完美适配——看起来就是一个正经的商业软件。
这就是我想做 .NET Skill 的原因:不只是"能做",而是"做得漂亮"。
聊.NET和Python的对比,大多数人只会说"性能更快"。但真正让我决定给 .NET 也做一套Skill的,是下面这五个真实体感:
Python用户最痛苦的体验之一:pip install 卡半天,然后报一个 timeout。
在国内用Python,你几乎逃不掉配置清华源、阿里源、豆瓣源……有时候换了好几个源还是装不上,版本冲突更是家常便饭。
.NET 完全没这个问题。
NuGet 是微软自家的包管理平台,国内直连下载,速度稳定。不需要配置任何镜像,不需要折腾 pip.conf,不需要对着报错一行行排查。
这意味着——AI帮你装依赖的时候,几乎不会因为网络问题翻车。 对零基础用户来说,这是巨大的体验差异。
Python做桌面界面,主流方案是 tkinter 或 PyQt。
tkinter 的颜值……懂的都懂。PyQt 虽然好一些,但学习曲线陡峭,AI写出来的代码经常在信号槽和线程调度上踩坑。
.NET 直接用 WPF + HandyControl 这套组合:
AI生成出来的界面长什么样?圆角按钮、毛玻璃导航栏、渐变进度条、流畅的窗口缩放——拿出去给客户看,完全不会露怯。
Python是动态语言,解释执行。AI写Python的时候,很多错误要到运行时才会暴露——变量名写错了、类型传错了、参数数量不对,这些Python不会在"写完"的时候告诉你。
.NET是编译型语言。AI写完代码,dotnet build 一跑——语法错误、类型不匹配、空引用风险,全部在编译阶段拦截下来。
用Python写的时候,你永远不敢说"AI写的代码没问题"。用.NET写的时候,只要编译通过,代码质量就已经过了一道硬门槛。
对AI编程来说,编译型语言天然比解释型语言更可靠。
Python打包成exe(用PyInstaller),一个简单的窗口程序动不动就 80-120MB。为什么这么大?因为要把整个Python解释器和所有依赖库都打进去。
.NET 不一样。
Windows 10/11 自带 .NET Runtime。你发布的程序如果不是特别要求"完全独立运行",打包出来可能只有几MB到十几MB。
就算选择"自包含"模式把运行时一起打包,.NET 的运行时也比Python解释器小得多,而且有 ReadyToRun 预编译和 TrimMode 裁剪,能进一步瘦身。
更重要的是——.NET 的第三方包本身就比 Python 小很多。 Python一个 pandas 包就几百MB依赖,而 .NET 做Excel操作用的 ClosedXML,总共才几MB。用量小、依赖少、打包自然轻。
Python跑在虚拟机上,.NET跑在编译后的原生代码上。
同样是处理1000个Excel文件,.NET可能几秒钟跑完,Python要几十秒。同样是启动一个桌面窗口,.NET几乎秒开,Python的GUI冷启动要等好几秒。
这不是"一点点"的差距,而是架构层面的代差。
有了前两套Skill的经验,dotnet-dev 这套Skill在设计上更加成熟。
核心逻辑和Python篇一致:用户完全不需要懂编程,全程由AI充当"需求分析师 + 开发工程师 + 环境管理员 + 测试工程师 + 打包交付人员"。
但针对 .NET 的特点,我做了这些强化设计:
Skill里内置了 WPF + HandyControl + CommunityToolkit.Mvvm 的完整模板。
这意味着AI生成的不是一个"能用就行"的窗口,而是一个遵循MVVM分层架构、带现代化控件、支持主题切换的专业桌面软件。
你不用知道什么是MVVM,不用知道XAML怎么写——AI按照模板填空,出来的效果就是专业级的。
这么专业漂亮的界面,谁不爱?

和Python篇一样,Skill内置了四套已经跑通的蓝图:
每个蓝图都是一套完整的项目骨架,AI只需要往里面填入你的业务逻辑。
所有环境操作由AI代执行。如果电脑上没装.NET SDK,AI自动用 winget 安装,不行就回退到官方安装脚本。你只需要点"允许"。
NuGet包也是AI自己装——而且如前所述,不用配置镜像,直连下载,稳得很。
用这套Skill做东西,体验是这样的:
1. 你说一句:"帮我把所有订单Excel合并,按客户分类生成汇总表,要有窗口界面,最好能看处理进度"
2. AI先问清楚:Excel格式是什么样的?按什么分类?要不要导出PDF?自己用还是给团队用?
3. AI搭环境:检查.NET SDK、建项目、装 ClosedXML 等依赖——全程直连,没有镜像配置
4. AI写代码:按MVVM架构写WPF窗口,圆角界面、进度条、文件选择、日志显示
5. AI跑测试:dotnet build 编译检查,用样例文件跑一遍,验证输出
6. AI打包:生成自包含单文件exe,只有几MB到十几MB,双击即用
7. AI交付:告诉你exe在哪,附带使用说明
全程你不需要:
现在三套Skill都齐了,我整理一下各自的定位:
| VBA | ||
| VBA + xlam | ||
| Python | ||
| Python GUI | ||
| 需要专业级界面的桌面软件 | .NET WPF | |
| 要发给客户/团队的正式工具 | .NET WPF | |
| 高性能数据处理、大规模Excel | .NET | |
| Python |
简单概括:VBA专注Office内部,Python做多面手,.NET做专业桌面交付。
回头看我前两篇反复强调的核心理念——用"约束"来让AI不出错。
.NET 在这方面的优势几乎是天生的:
1. 编译器就是最好的约束:AI写错了,编译阶段直接拦截,不会到运行时才发现
2. 强类型系统天然防错:参数类型写错了?编译不过。返回值用错了?编译不过。Null没处理?编译器给你警告
3. 项目文件结构清晰:.csproj 定义依赖,Program.cs 是入口,Views/ViewModels/Services 分层明确——AI不需要"猜"代码放哪
4. NuGet依赖管理整洁:一个 dotnet add package 搞定,不会出现Python那种"这个包要那个包的3.2版本,但你的另一个包又要3.1版本"的套娃冲突
说白了:Python给了AI最大的灵活度,但也给了AI最大的犯错空间;.NET给了AI足够的约束,反而让AI更稳定地输出可靠代码。
如果你尝试过用Python做桌面软件,但总觉得界面不够专业、打包太大、发给别人不够体面——
这套 .NET Skill 就是帮你从"能做"跨越到"做得好"的那一步。
你不需要学WPF,不需要学MVVM,不需要折腾C#语法——你只需要告诉AI你想做什么,剩下的全部自动完成。
从VBA到Python到.NET,我的 "Skill + 约束 + 模板" 方法论在三个完全不同的技术栈上都跑通了,这让我更加确信:
普通AI + 好Skill,完全可以打败顶级AI裸奔。
如果对这套玩法感兴趣,想了解更多细节,欢迎找我聊聊。
