AI 还不会替换软件（至少目前还是如此）

2026 年初，软件类股股价大幅下跌，市场开始出现一种声音：AI 会不会替换传统软件？我们也看到大量案例，展示 AI 能以过去难以想像的速度生成软件。

这就是未来吗？每个人都能随时依需求生成自己需要的软件？或者，干脆直接叫 AI 完成原本由软件处理的工作？

AI 写程序带来的兴奋感

我有 25 年的软件开发经验。今年这一波 AI 写程序工具，例如 Claude Code，让我着迷了好一阵子。我喜欢开发软件、创造新东西；对我来说，AI 写程序就像计算机游戏和手机游戏一样让人上瘾。除了 Ragic 的工作之外，我也为了好玩、测试 AI 写程序的能力，开始做了不少个人小专案。我甚至和我 14 岁和 12 岁的两个小孩（都不会写程序）一起用 AI 开发游戏，当作一项有趣的实验。我也想藉此了解，vibe coding 对非开发者而言究竟有多实用。

我们根据一部年代久远的小说，做了一款相当复古、类似《勇者斗恶龙》的网页 RPG（这样就没有版权问题，而且已有完整的故事背景）。我们完全把自己当作不懂程序的人，完全不看 AI 生成的程序代码，只负责测试，然后告诉 AI 想增加哪些功能、哪些地方需要修正。

才过 15 分钟，我们就有了一款包含好几个画面的游戏，可以四处走动、跟 NPC 对话、查看道具，甚至打开宝箱！真的很酷，也让人很兴奋。就像每次 vibe coding 一样，做出这么酷的东西，总会想立刻分享给其他人。

Vibe Coding 过程中浮现的问题

很自然地会想：“15 分钟就能做到这样，那再花个几天，还能做出什么？”于是，我们开始加入更多地图、战斗系统、升级系统、物品栏系统与技能系统。游戏很快就越来越像一款完整的 RPG。

刚开始，我们请 AI 修正某个问题时，通常很快就能完成，而且第一次就能修好。但随着我们加入更多站点、NPC 和不同模块，渐渐发现 AI 修正问题需要的时间越来越长，而且常常没办法一次修对。

我们开始请 AI 创建自动化测试系统，让它能不断周期测试游戏、修正问题，直到确认问题已经解决。但 AI 花在修正问题上的时间越来越长（消耗的 token 也多了很多！），却还是经常修不好。最糟的是，修好了问题 A，问题 B 就冒出来；修好了问题 B，问题 A 和 C 又跑出来！简直像在打地鼠！

检视 AI 生成的程序代码

这实在太挫折了，我决定自己进去看看程序代码，看到底出了什么问题。我发现 ... AI 生成的程序代码有一些重大、结构性的设计问题。举例来说，玩家会透过一连串站点在游戏世界里移动。当玩家从站点 A 的右侧离开，就会出现在下一个站点 B 的左侧；如果再从站点 B 左侧往回走，就应该出现在站点 A 的右侧。这很符合直觉，而且一开始确实运作正常。

不过，随着站点增加，这个机制开始出错；当站点数超过 100 个，要确保每个站点之间的连接都正确，就变得非常困难。查看程序代码后，我发现：每张地图都分别设置了出口的位置，以及各个出口通往哪张地图。但玩家进入新地图后，应该出现在哪个位置，却又是另外独立设置的。这样的设计其实很容易出问题，也很难维护。因为每次新增地图，都必须确保其他相关地图的设置同步更新，才能让整个游戏的逻辑保持一致。

有经验的开发者如果从一开始就掌握系统全貌，就会采取不同的设计方式。他们会让地图的出口，以及玩家进入地图时的出现位置，都能透过程序规则自动判定（例如采用网格系统 grid system），而不是分别设置。

这类问题必须在开发初期就处理好，否则随着系统越来越庞大，就会与其他数百个类似问题相互牵连，变得越来越难解决。等到程序代码规模大到连个别模块都无法完整放进 AI 的上下文窗口（context window）时，即使是 AI，也很难再有效管理整个系统。

我这才恍然大悟：“喔！这就是优秀的软件体系结构师和软件管理员在做的事。”他们了解整体全貌，再据此规划、建构系统，让系统容易管理，并减少重复的程序代码，以避免这类问题。

为什么 AI 还不会替换软件

AI 能做出这样的设计吗？当然可以！但 AI 能不能在与一个完全没有软件开发经验的人合作时，也创建出好的软件体系结构？这才是让我开始存疑的地方。而且看起来，这个问题短期内并不容易解决。

AI 确实能轻松做出很好的设计、遵循最佳实务，但如果盲目照单全收每一条最佳实务，就会做出庞大、过度工程（over-engineered）的软件，反而形成另一个更大的问题。毕竟，盖一栋房子不需要每次都打摩天大楼等级的地基。

真正可行的方向，是某种护栏机制：提供一个平台，让非开发者能反覆描述、调整需求，而不必担心系统“怎么”实作。AI 写程序对有经验的开发者仍然非常好用，但对非开发者来说，如果要创建的不是简单的小专案，而是预计使用、维护多年的系统，这样的护栏就极有帮助。AI 让创建复杂系统变得便宜，但“维护”本身仍然昂贵。

同样的问题在企业信息系统里可能更加严重，因为业务逻辑同样复杂（甚至更复杂），而软件出错的后果也更严重——尤其涉及数据安全、法规遵循以及金流交易时。若一开始没有仔细向 AI 说明系统全貌，先前游戏设计遇到的问题，就会随着应用系统的发展不断浮现。没有专业软件体系结构师参与的 AI 开发，往往会在专案规模成长到某个程度时碰到瓶颈。迟早会撞墙，维护成本也会越来越高。AI 并没有办法神奇地修好庞大的程序代码库。

No-Code 如何成为 AI 的护栏

这正是“No-Code（无程序代码）”应用想要解决的问题。应该让非开发者能只描述“业务逻辑”，完全不需要做任何软件体系结构或技术实作决策——不只不用写程序，也不需要讨论技术细节。No-Code 工具应该针对用户想创建的应用类型来设计，例如 CRM、专案管理系统、ERP 等“数据库应用系统”。

这就是像 Ragic 这样的 No-Code 工具能发挥作用的地方。当企业用户在 Ragic 上描述自己的应用系统应该做什么时，只需要说明销售流程如何运作，或专案如何管理，而不需要解释数据要如何保存、存在哪个数据库里。

在 Ragic 这类 No-Code 工具中，透过 AI 辅助创建系统时，不需要自行假设业务流程在技术上该如何实作。平台会将用户需求直接转换成系统设置，而不需要用户做技术设计决策。No-Code 工具因此成为非开发者与 AI 设计系统时的护栏，不只能确保系统在技术上合理、安全、稳健，也能让 UI/UX 保持一致、清楚——这件事对没有开发背景、靠 vibe coding 创建系统的人来说，往往比想像中更难。

结果就是，即使透过 AI 持续开发、维护系统，系统也不会失控膨胀。同时，它也提供一定程度的透明度，让用户不必阅读或理解程序代码，就能直接查看应用系统的设计。用户可以透过 No-Code 工具完整掌握当前的业务逻辑，并在需要时不用写程序，也能自行修改、维护系统。