AI编程可能让传统IDE变得过时
ZDNET AI··作者 David Gewirtz
关键信息
作者的项目包括一个用于3D打印机线材追踪的应用和一个使用NFC标签与设备端AI自动提取元数据的缝纫图案管理器——这两个项目都因AI辅助而几乎无需手动编码即可完成。
资讯摘要
文章描述了作者如何仅用语音输入和鼠标构建了两个复杂的苹果应用——一个是用于管理3D打印机线材的工具，另一个是管理实体和数字缝纫图案的应用。传统IDE中的语法高亮、调试和文件导航等功能大多被AI驱动的代码生成所取代。
作者认为开发流程已从‘编辑→构建→测试→调试’转变为‘指令→引导→部署’，使现代IDE变得不那么必要。尽管这些应用结构复杂，但实际编码主要由AI完成，开发者更像是项目经理而非程序员。
资讯正文
我仅用语音和鼠标就开发了两款应用——集成开发环境（IDE）是否已经过时？
跟随ZDNET：在Google上将我们设为首选来源。ZDNET的核心观点：AI编程用“指令与引导”取代了传统的“编辑与调试”。终端加AI取代了传统开发环境，IDE仅剩构建和部署工具的功能。
我的小狗Pixel不喜欢我的键盘。它经常占据我腿上的位置，而我的12岁约克夏犬则认为那是他的领地。在他看来，高质量的依偎绝不能因为我想写点东西或写代码就被牺牲。
昨晚就是这种情况：我那很棒的狗狗爬到我肩膀上，蜷缩起来睡着了。那一刻我意识到，像VS Code和Xcode这样的强大开发环境实际上已经过时了。
我正在做的两个苹果编程项目，都将运行在iPhone、iPad、Mac和Apple Watch上。总共要生成八个二进制文件，最终通过Apple App Store分发。
其中一个项目是线材管理应用，帮助我追踪3D打印机线材卷轴。我有120个线轴，分布在四个存储架上，每个架子有五个层。这些线轴不断在架子之间移动，同时被我的八台3D打印机使用。其中五台打印机可同时使用四个线轴，一台可以使用八个，另外两台只能用一个。
iPhone应用利用NFC标签让追踪线轴移动变得非常简单，并通过内置摄像头拍摄每卷线轴的照片供参考。Watch应用检查并更新位置信息，而Mac应用则提供桌面版的线材库存视图。
第二个项目最初基于线材管理系统，但现在已经扩展得更多：它不仅管理物理缝纫图案，还管理数字图案。很多缝纫爱好者，比如我妻子，会收集数百甚至上千种图案，追踪它们常常是个挑战。
我的代码使用NFC标签和照片来管理物理图案，还加入大量设备端AI，用于解析图案并自动识别名称、类别、供应商和其他相关信息字段。这种方法避免了用户手动输入所有信息的麻烦。
这个缝纫应用在原本的线材管理功能基础上，增加了深度的分类工具和特性。
线材应用已经进展顺利，我已经用了大约三个月，现在准备开始添加各种内购功能。
缝纫图案应用仍处于早期开发阶段。由于图案格式差异大，且不同公司处理方式各不相同，让本地AI稳定工作花费了很多时间。此外，还有许多用户界面元素需要设计并适配四个平台。
新的“氛围编码”流程
永远不要相信有人说你只需说几句话或打个响指就能进行氛围编码。
正如你所见，这些产品即便由AI完成实际编码工作，仍然相当复杂。此外：我仅用12小时就通过Claude Code让AI帮我编写了一个Apple Watch应用，而不是传统方式需要的两个月。
在传统的编程时代，开发流程可以被描述为编辑→构建→测试→调试，然后再回到编辑。所有交互式开发环境（IDE）都是围绕这个循环设计的。IDE界面的大部分结构都围绕文件树和编辑支持工具展开，从语法高亮、命令补全到清晰的垂直标记，用来指出循环的起始和结束位置。IDE还包含一个调试器：你在编辑器中设置断点，逐行执行代码，观察程序一步步运行。
Vibe编程也有类似的循环，但步骤不同。不是编辑，而是“指令”——即向AI发出提示，说明你想要什么；构建环节保持不变，代码必须转化为可运行的程序，这一步通过解释或编译并组装实现；测试环节也一样保留。但调试不再由你亲自完成，而是要引导AI：AI能够发现并修复代码错误，但通常需要指导才能定位问题所在。你不能简单地说‘修复它’，就指望AI能自动搞定。对于相当一部分bug，它仍需有经验的人给予指引。
因此，这个循环变成了：指令→构建→测试→引导，然后回到指令环节。
另外：我仅用两天时间，仅靠语音就完成了一个iOS应用的开发，过程令人振奋。
注意，vibe编程的循环并不真正包含编辑和调试环节。大多数人会根据自身需求定制开发环境，以优化编辑和调试效率，因为过去这些正是耗时最多的部分。但在vibe编程中，大部分时间花在聊天界面，通常只是一个终端窗口。你唯一需要接触开发环境的时候，是启动构建操作。之后运行你正在开发的程序，查看哪些功能有效，再回到聊天或终端界面去指导AI。几乎不需要使用IDE来完成我们以往依赖IDE才能做的事。
单手编程
这让我们回到Pixel的话题。昨晚他依偎在我的左肩上，导致我的左臂和左手都被占用，无法使用物理键盘。但我可以用右手控制鼠标，并用语音与AI交流。我的鼠标上有两个按键分别设置为回车键和启动Wispr Flow语音输入软件（我在Mac上使用的工具）。
我所有的实际编码工作都在iTerm2里完成——这是Mac上的一个免费终端程序，我设置了多个标签页，每个项目对应一个标签页。
昨晚我花了两个小时进行这样的循环：挠狗的背，说些安抚的话；把 iTerm2 窗口置顶；按下鼠标上的 Wispr Flow 按钮，用语音向 AI 下达指令，然后按鼠标回车键；等待 AI 执行任务，或者切换到另一个标签页，对另一个项目做同样的事。当 AI 完成运行后，切换到 Xcode（一个 IDE）执行构建；等待程序编译完成，然后运行它并测试；再回到终端程序，向 AI 报告结果，并给出新的指令。我连续这样做了两个小时，两个项目都取得了明显进展。我在 IDE 中唯一做的操作，就是选择菜单项将测试代码发送给苹果设备。如果我开发的不是苹果应用，甚至可以完全让 AI 来触发构建，根本不需要使用 IDE。我开始觉得 IDE 已经过时了。
今晚我又花了几小时继续完善我的程序。现在 Pixel 躺在我妻子身边，所以我双手都能自由工作。我又投入了几个小时“编码”，但除了把代码发到 TestFlight（苹果的测试通道）外，一次都没用过 Xcode IDE。另外，我用 Claude Code 在 8 小时内生成了一个 Mac 应用，但这过程比魔法更像劳动。
去年，在我真正开始用 AI 编写大型项目之前，我以为自己需要一个具备 AI 功能的 IDE。因此，我把所有代码从我长期使用的 PhpStorm（一款我为 WordPress 插件打造的 IDE）迁移到 VS Code 上。我当时还专门写了一篇文章，强调选择合适的 IDE 对充分利用 AI 功能至关重要。但我没想到这个判断会错得如此离谱。
过去几天里，我一次都没用过编辑器或调试器。只靠一只手和语音输入，我就同时推进了两个完全独立的 Mac 应用。我用的是一个简单的终端程序，里面有两组带颜色区分的窗口，还有一个整合两个应用输出的第三窗口。我不再因为没空腾出手而回避使用 IDE——今晚我根本不用它，因为它已经完全没必要了。
另外：7 个令人意外的 ChatGPT 语音模式实用技巧，来自一位曾经持怀疑态度的人。
终端配合语音输入的过程其实相当轻松，只是偶尔会感到一丝不安，提醒我这种做法有多不寻常，尤其对于一个与 IDE 概念有着数十年深厚情感连接的人来说。
你是否也发现自己花在聊天界面的时间越来越多，反而很少待在 IDE 里？欢迎在评论区告诉我们。你可以在社交媒体上关注我的日常项目更新，记得订阅我的每周通讯，也可以通过 Twitter/X 关注 @DavidGewirtz，Facebook 上搜 Facebook.com/DavidGewirtz，Instagram 上搜 Instagram.com/DavidGewirtz，Bluesky 上搜 @DavidGewirtz.com，YouTube 上搜 YouTube.com/DavidGewirtzTV。
来源与参考
收录于 2026-04-03