当我开始做越来越多Ai工具，真正麻烦的事情反而不是写代码

以前我做 Python 小工具，通常有一个很简单的流程：

写一个 .py 文件，运行。

不好用了就改。

再后来工具越来越多，事情开始变得不太一样。

一个目录里可能放着文件处理脚本，另一个目录里放着自动化程序，还有几个小项目带着 Web 界面。为了避免依赖冲突，有的项目用了虚拟环境，有的项目单独指定了 Python 版本。

到了这个阶段，我发现一个很有意思的问题：

Python 写工具已经越来越容易了，但“管理这些工具”却没有变得更容易。

尤其是在 AI 开始参与编程之后，这个问题更加明显。

现在让 AI 帮忙生成一个几十行、几百行的 Python 程序，并不算什么难事。真正麻烦的是，这些程序写完以后放在哪里、怎么启动、怎么区分运行环境，以及一个月以后我还能不能快速找到它。

于是我开始认真考虑一个问题：

如果电脑里有几十个自己做的小工具，它们应该以什么方式存在？

一、脚本和应用，其实是两种东西

我以前很喜欢把所有东西都直接放在项目目录里。

例如：

projects/ ├── rename_files/ ├── image_tool/ ├── excel_helper/ ├── crawler/ ├── local_web/ └── pdf_tools/

对于刚开始开发的人，这种方式完全没问题。

但当项目数量增加以后，“项目目录”并不等于“应用列表”。

因为我真正关心的通常不是：

这个项目的源码放在哪？

而是：

我今天要处理 Excel，应该打开哪个工具？

我要运行上次那个文件整理程序，它叫什么？

这个项目到底使用哪个 Python 环境？

这就是我后来开始把“项目”和“应用”分开考虑的原因。

项目是给开发看的。

应用是给使用看的。

源码目录、虚拟环境、依赖文件这些东西，对于开发过程很重要，但对于每天点击一下就要使用的小工具来说，它们其实都属于实现细节。

一个成熟一点的桌面工作流，应该允许我直接面对“应用”，而不是每次都面对“项目目录”。

二、AI 编程之后，这个问题反而更明显了

AI 编程工具带来的最大变化之一，并不是让程序员少写几行代码。

而是让很多原本“懒得做”的工具，现在值得做了。

以前我可能会想：

“这个事情一个月才做一次，专门写个工具好像没必要。”

现在可能几句话就生成了：

def rename_files(folder, prefix): for index, path in enumerate(folder.iterdir(), start=1): if path.is_file(): new_name = f"{prefix}_{index}{path.suffix}" path.rename(folder / new_name)

代码本身并不复杂。

真正让我头疼的，是它下一步怎么办。

如果只是运行一次，终端里执行一下就结束了。

但如果我准备以后反复使用，那么它实际上已经不是一个临时脚本，而是一个“小应用”。

于是我的工作流开始从：

想需求 → 写代码 → 运行一次

慢慢变成：

想需求 → AI 辅助开发 → 调试 → 变成可重复使用的应用

这时候应用管理就成为开发链路里缺失的一环。

三、我更希望 Python 环境是“应用的属性”，而不是“用户的负担”

Python 有一个非常优秀、同时又很容易让新用户困惑的地方：

环境。

开发者当然知道虚拟环境是什么，也知道为什么不同项目需要隔离。

但如果一个人只是想运行一个自己做的工具，他真正关心的问题通常只有一句：

能不能直接打开？

假设电脑上有三个项目：

Tool A -> requests==2.x Tool B -> requests==3.x Tool C -> pandas + openpyxl

让它们全部共用一个全局 Python，迟早会遇到依赖问题。

所以我做桌面应用管理时，一个比较重要的思路就是：

环境应该跟着应用走。

可以把应用理解成一个简单的数据结构：

app = { "name": "Excel Helper", "entry": "main.py", "runtime": "python", "isolated_env": True, "homepage": https://pybox.site, }

这里最重要的其实不是 homepage。

而是最后那个字段之前的几个属性：

应用叫什么、从哪里启动、使用什么运行方式，以及它自己的环境。

一旦这些信息被统一管理，就可以把“运行一个 Python 项目”变成“启动一个应用”。

这也是我在做 PyBox 时反复思考的一件事情。

四、为什么我没有把它做成另一个 IDE

一开始很容易掉进一个误区：

既然有 AI，那是不是应该重新做一个更强的 IDE？

但我后来觉得，这未必是最值得解决的问题。

现在已经有大量成熟的编辑器和 IDE，也有越来越多 AI 编程工具。

真正缺少的，反而是 IDE 之外的那一层：

代码已经写完以后呢？

所以我更倾向于把开发和运行拆开。

研发阶段，可以让 AI 帮助创建和修改 Python 项目。

例如：

“创建一个批量整理图片的工具， 支持按日期移动文件，并增加撤销功能。”

AI 负责把需求变成代码。

开发者负责判断需求和结果。

项目完成以后，再把它登记成一个应用。

之后使用它，不需要再次打开开发环境。

这是一种很轻量的工作流，但我觉得非常适合个人工具。

五、我现在越来越喜欢“桌面工作台”这个概念

以前我的电脑更像是一个文件仓库：

文件夹里是源码，源码旁边是虚拟环境，桌面上还有几个快捷方式，浏览器收藏夹里又放着几个 Web 工具。

它们分别都能工作。

问题是，它们彼此之间没有统一的入口。

所以后来我开始尝试把这些东西放进一个桌面工作台。

大致可以理解成：

┌──────────────┐ │ 研发中心 │ │ AI + Python │ └──────┬───────┘ │ ▼ ┌──────────────┐ ┌──────────────┐ │ 应用商店 │ ──> │ 我的应用 │ └──────────────┘ └──────┬───────┘ │ ▼ 本地运行环境

研发解决“怎么做”。

应用列表解决“怎么用”。

商店解决“怎么分享”。

这三个部分其实是连续的，而不是三个孤立的功能。

六、网页应用也应该有一个位置

另外一个让我比较纠结的问题，是 Python 桌面工具和网页应用应该怎么共存。

实际上现在很多 AI 生成的小项目，本身就是 Web UI。

例如一个简单的数据处理工具，后端可能是 Python，前端可能是 HTML + JavaScript，最后通过浏览器访问。

如果应用管理器只支持 .exe，显然太局限。

如果只支持 Python，也一样。

所以我现在更倾向于把“应用”理解成一种抽象概念，而不是某一种技术。

一个应用可以是：

Python 项目 自动化脚本 网页应用 本地工具

只要它能够被统一描述，就应该有机会被统一管理。

例如一个非常简单的应用描述：

name: Data Cleaner type: web entry: app.py runtime: python url: http://127.0.0.1:8000

这样一来，用户根本不需要特别关心它到底是 Flask、FastAPI 还是别的东西。

打开应用就行。

七、做着做着，我又加了一块“办公”

这其实是比较自然发生的一件事。

因为很多所谓“办公需求”，本质上就是轻量的软件任务。

整理文本、生成文件、处理表格、批量操作、本地自动化，这些事情以前通常需要：

Excel + Word + 浏览器 + Python + 一堆脚本。

现在 AI 参与以后，很多任务都可以被组合起来。

所以后来在桌面工作台里又加入了办公助手。

它背后的逻辑并不复杂：

AI 不应该只是一个聊天窗口，也可以成为桌面任务的一部分。

这也是我比较认同的一个方向。

未来个人软件可能不会越来越“大”，反而可能越来越碎片化。

一个工具只解决一个问题，但每个人都可以拥有很多这样的工具。

八、真正值得解决的，不是“怎么生成代码”，而是“代码生成以后”

这是我做这类软件以后最大的一个感受。

AI 已经让“从零写一个小程序”这件事越来越低成本。

但开发流程并没有因此结束。

代码生成之后，还有：

创建环境 ↓ 安装依赖 ↓ 调试 ↓ 运行 ↓ 再次运行 ↓ 管理 ↓ 更新 ↓ 分享

如果每个小工具都重复处理这些事情，那么 AI 节省下来的时间，很快又会被管理成本吃掉。

因此我现在更关注的是后半段。

如何让一个 AI 生成的小项目真正成为一个可以长期使用的桌面应用。

这也是为什么我最后做出来的东西并没有停留在“AI 写代码”这一层。

我把它继续往后延伸到了：

开发 → 运行 → 管理 → 分享

整个链路。

九、PyBox 更像一个实验，而不是一个终点

我现在做的这个项目叫 PyBox。

它运行在 Windows 桌面上，核心思路就是把 AI 辅助开发、Python 应用运行、本地应用管理和应用分享放进同一个工作台里。

它当然不是要解决所有软件开发问题。

我更愿意把它看成一种尝试：

当 AI 让创建软件变得越来越容易以后，我们是否需要一种新的方式来管理这些软件？

目前它已经可以管理本地 Python 应用、自动化脚本和网页应用，也可以通过研发中心辅助创建和修改 Python 项目，再登记到应用列表中。

另外还有应用同步、分享、独立运行环境、快捷方式以及部分应用的 EXE 打包能力。

项目本身还在持续调整。

对我来说，比“做出了多少功能”更重要的是验证一个工作流：

需求 ↓ AI 辅助开发 ↓ Python 项目 ↓ 应用登记 ↓ 独立运行 ↓ 长期使用 ↓ 需要时继续修改

如果这个循环能够跑通，那么 AI 生成的软件就不再只是一次性的代码片段，而是真正能够沉淀到个人电脑里的工具。

这可能也是桌面软件在 AI 时代一个挺有意思的方向。

最后

我以前觉得，程序员最重要的能力是把代码写出来。

现在反而觉得，代码只是开始。

当写一个小程序的成本越来越低，我们迟早都会遇到一个新的问题：

电脑里有那么多自己做出来的软件之后，怎么把它们真正用起来？

也许答案不是再打开一个编辑器。

而是给这些代码一个真正属于“应用”的位置。

这也是我现在正在做的事情。

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～