这两年，AI 编程工具发展得很快。
从最早的代码补全，到现在直接根据自然语言生成函数、模块，甚至一个完整的小项目，很多以前需要半天完成的事情，已经可以在几轮对话里得到结果。
但实际用下来，我越来越明显地感觉到一个问题：
代码生成并不是开发工作的终点。
恰恰相反，当"写代码"越来越容易以后，真正让人花时间的东西，反而开始变得更加突出------项目怎么运行？不同项目的 Python 环境怎么管理？做出来的小工具怎么启动？网页应用和本地脚本怎么放在一起？一个 AI 临时帮我生成的小程序，过几天我还能不能找到？
以前这些问题不算什么，因为一个人可能一年也就维护几个项目。
现在不一样了。
AI 让"做一个小工具"这件事的成本大幅下降，随之而来的，是越来越多零散但有价值的小应用。
于是我开始觉得，桌面开发环境缺的可能并不是又一个代码编辑器，而是一个能够把开发、运行和应用管理串起来的工作台。
一、AI 把"写一个工具"的门槛降低了，但也带来了新的混乱
以前做一个 Python 小工具，通常要经历这样的流程：
创建目录、建虚拟环境、安装依赖、写代码、调试、运行。
如果项目多一点，还要考虑不同版本的 Python、不同依赖之间的冲突，以及各种启动脚本。
这个过程其实很合理。
问题在于，当 AI 加入之后，很多人会开始频繁地做一些以前不会做的小项目。
比如：
"帮我写一个批量重命名文件的工具。"
"帮我做一个 CSV 数据清洗脚本。"
"帮我写一个图片处理小工具。"
"帮我做一个简单的网页界面。"
"把刚才这个程序再增加一个导出功能。"
这些事情的共同特点是：项目本身不一定大，但数量会越来越多。
项目一多，管理成本就出现了。
我的一个很直观的感受是：
AI 降低了应用的创建成本，却没有同步解决应用的组织成本。
这也是我后来开始尝试 PyBox 这类桌面工作台的一个原因。
二、把"项目"和"应用"区分开，其实很重要
以前我们经常把"代码"和"软件"混为一谈。
但对于个人开发者来说，这两者其实是两个完全不同的概念。
一个 Python 项目，关注的是代码、依赖、配置和版本。
一个真正拿来使用的应用，关注的却是：
怎么启动？
怎么停止？
在哪里找到？
需要什么运行环境？
能不能创建快捷方式？
以后还能不能继续修改？
当我开始从"管理应用"的角度重新看待自己的项目时，很多事情反而清晰起来。
比如，一个临时写出来的 Python 工具，只要登记到统一的应用列表里，就不需要每次重新找项目目录。
脚本类工具和网页应用，也没必要因为技术实现方式不同，就分别放在完全不同的工作流里。
于是"项目管理"逐渐变成了"应用管理"。
这个变化看起来很小，但真正用起来之后会发现，它解决的是另外一个层面的问题。
三、我比较喜欢的一种工作流：让 AI 负责创建，人负责决定它留下来没有
AI 编程工具一个很有意思的变化，是"开发"越来越像一次对话。
以前我可能会先想清楚目录结构，再开始敲代码。
现在有时候只需要说清楚需求，让 AI 先把第一个版本做出来。
例如：
"做一个读取 Excel，然后按照指定字段分类导出的 Python 工具。"
第一版能不能用，暂且不说。
更重要的是，几个来回之后，一个原本只存在于脑中的想法，已经变成了一个可以实际运行的项目。
这里有一个很大的好处：
试错成本变低了。
以前因为"做起来麻烦"，可能根本不会去做某个小工具。
现在因为 AI 可以快速完成原型，反而有机会把一些重复性的工作变成自己的小应用。
但接下来就出现第二个问题：
做出来以后怎么办？
我的处理方式是，把 AI 生成项目的过程和应用使用过程分开。
在研发阶段，可以让 AI 辅助创建、修改 Python 项目；
项目基本稳定之后，再把它登记成一个可直接运行的应用。
PyBox 的"研发中心"就是围绕这个思路做的：通过对话的方式创建或修改 Python 项目，再把项目放进应用列表里。
它不是要取代传统 IDE，而是更偏向于解决"我已经决定要做一个小工具，现在如何快速把它做出来并长期使用"这个问题。
官网放在这里，感兴趣可以自己看看：
四、另一个容易被忽视的问题：运行环境
Python 项目数量一多，环境问题几乎一定会出现。
A 项目需要某个版本的依赖。
B 项目又需要另外一个版本。
C 项目甚至因为系统环境变化，突然就不能运行了。
对于经常写 Python 的人来说，这些已经属于日常操作。
但如果我们的目标是"做一些马上能用的小应用"，那么每次启动之前都去处理虚拟环境，其实是一种额外负担。
所以我觉得，应用运行环境应该尽可能从用户的日常操作里退到后台。
PyBox 的做法是让应用使用相对独立的 Python 运行环境，把环境管理和应用本身尽量隔离开。
从使用角度来看，我更希望看到的是：
点击应用 → 启动 → 工作。
而不是：
打开终端 → 进入目录 → 激活环境 → 检查依赖 → 再运行。
当然，这并不意味着传统命令行方式不好。
对于开发者来说，终端依然是非常高效的工具。
只是当一个项目已经从"代码"变成"我要每天使用的软件"以后，它值得拥有另外一套更接近桌面应用的使用方式。
五、为什么我觉得"应用商店"这个概念，在 AI 时代可能会重新变得有意思
以前的应用商店，解决的是"软件从哪里下载"。
但 AI 时代的情况有点不同。
很多人现在具备了一个很有意思的能力：
自己制作小软件。
不一定是商业软件，也不一定有成千上万的用户。
可能只是一个帮自己处理照片的工具，一个整理文件的小程序，一个办公室里的自动化脚本，或者一个简单的内部网页应用。
问题是，这些工具通常做完就结束了。
如果能够把它们标准化，然后放到一个统一的应用体系里，就有机会从"我写了一个脚本"进一步变成"我拥有了一个应用"。
这也是我觉得 PyBox 商店比较有意思的地方。
它并不只是一个传统意义上的软件下载区。
一方面可以同步、下载别人分享的应用；另一方面，也可以把自己制作的应用提交进去。
这里其实形成了一个挺有意思的闭环：
AI 帮你降低制作门槛 → 桌面工作台负责运行 → 商店负责分享。
对于个人开发者来说，这种模式可能比单纯写一个 Demo 更有价值。
六、桌面应用和网页应用，为什么不能同时存在？
现在大家都喜欢讲 Web。
确实，网页应用有很多优势。
打开浏览器就能用，不需要复杂安装，更新也方便。
但是桌面应用仍然有自己的位置。
特别是文件处理、自动化任务、本地数据处理这一类场景，程序天然需要访问电脑上的资源。
因此我并不认为未来会变成"网页应用完全取代桌面应用"。
更现实的情况可能是：
不同类型的任务，用不同形态的应用。
本地 Python 工具，可以直接作为桌面应用运行。
自动化脚本，可以作为一个随时启动的任务入口。
需要网页界面的项目，也可以作为网页应用使用。
如果这些东西都能够在同一个桌面工作台里管理，那么用户其实不需要太关心它内部采用的是哪一种技术。
这也是我在设计 PyBox 时比较看重的一点：
技术实现可以不同，但应用的使用入口可以统一。
七、还有一类事情，我以前完全不会想到交给"应用"来做
那就是办公。
以前"写程序"和"办公"是两套完全不同的事情。
但现在 AI 出现以后，两者之间的边界已经越来越模糊。
整理一份资料、生成一个表格、处理文本、批量处理文件、辅助完成一些重复工作，这些事情既可以属于开发，也可以属于办公自动化。
所以 PyBox 里除了应用管理和研发中心之外，还放了一个"办公秘书"。
它的定位不是再做一个聊天机器人，而是尝试把 AI 放进一些更具体的桌面工作流里。
这个思路背后的逻辑其实很简单：
如果 AI 最终要进入日常工作，那么它应该离实际任务更近，而不是永远停留在一个聊天窗口里。
八、我越来越觉得，未来个人电脑上的"软件"可能会发生变化
过去我们安装软件，是因为有人已经替我们把需求做成了产品。
未来可能会出现另一种方式：
我有一个需求 → AI 帮我生成应用 → 应用立即在本机运行 → 我长期使用它 → 需要的时候再继续修改。
这意味着软件的颗粒度可能会越来越小。
以前一个软件要解决几十个问题。
以后一个人完全可能拥有几十个只解决一个问题的小工具。
而当"小工具"的数量开始增加时，真正重要的又会重新变成：
怎么组织这些工具。
所以从这个角度来看，我认为 AI 编程真正推动的，并不只是"程序员写代码更快"。
它可能还会推动一个变化：
越来越多的人，会从软件使用者，慢慢变成自己工作流的构建者。
而这恰好也是我做 PyBox 时最想验证的一件事。
它不是一个纯粹的 IDE，也不是一个单纯的软件启动器，更不是传统意义上的应用商店。
我更愿意把它理解成一个放在 Windows 桌面上的"小型个人工作台"：
开发的时候，可以让 AI 帮忙；
做好的项目，可以直接运行；
日常工具，可以集中管理；
别人做的应用，可以拿来使用；
自己做的应用，也可以分享出去。
这个方向到底有没有必要，其实没有标准答案。
至少对我自己而言，当电脑里那些零散的 Python 项目、自动化脚本和网页工具开始越来越多之后，我确实不太想再回到"每个项目各自躺在某个文件夹里"的状态。
软件越来越容易被创造出来之后，如何把这些软件真正变成生产力，可能才是下一个值得解决的问题。
而这也是我现在继续做 PyBox 的原因。
项目主页：