在使用AI编程的30天里, 我被折磨了30天

AI工具的使用，不只是技术迁移，更是认知重构。当“自动化”遇上“复杂性”，你会发现所谓的“智能编程”其实是一场人与工具之间的博弈。本篇文章将以30天的实践为样本，反思AI编程的真实体验与产品设计的底层逻辑。

如果说科技界有什么比“下一代iPhone”更诱人，那一定是“零代码”的承诺。它像一剂神奇的灵药，许诺要将普罗大众从复杂的代码地狱中拯救出来，让每个人都能像搭乐高一样构建自己的数字世界。

我，一个连“HelloWorld”都无法独立敲出的编程门外汉，带着对这种“数字魔法”的无限憧憬，决定投身这场AI编程的浪潮。我的旅程始于30天前，一个阳光明媚的下午。

但30天后，我坐在电脑前，看着屏幕上空荡荡的代码编辑器，唯一的感觉就是：我被折磨了30天。这场本应是“赋能之旅”，最终沦为一场被精心包装的“数字幻觉”。

低代码的宏大叙事与我的手足无措

国内互联网巨头，从不缺席任何一场技术盛宴。当国外以Cursor为代表的AI编程工具在程序员圈内掀起巨浪时，国内厂商迅速跟进。字节跳动推出了Coze，腾讯紧随其后发布了CodeBuddy，仿佛一夜之间，“低代码/零代码”的旗帜插满了每一个角落。他们的宣传语是如此动人：“人人都是开发者”、“让创意直抵代码”。这不正是为我这种人量身定制的吗？我天真地以为，我不需要从枯燥的变量、函数、循环学起，只要把我的想法告诉AI，它就能帮我实现。

带着朝圣般的心情，我首先下载并安装了这些平台的客户端。我的第一场噩梦从这里开始。

我以为的“零代码”，是像在画板上用画笔涂鸦，所想即所得。但现实是，我首先要面对一个复杂得令人眼花缭乱的IDE（集成开发环境）。它的界面上布满了密密麻麻的菜单、工具栏、文件树和配置窗口。我甚至不知道该从哪里下手。为了解决这个问题，我不得不开始我的第一次“学习之旅”。我打开了官方的教学视频和文档，花了整整两天时间，才勉强理解了什么叫“项目初始化”，什么叫“依赖管理”。文档里充满了各种专业术语，比如“编译环境”、“容器化部署”、“API接口”。我感觉自己像是在听一门高等物理课程，完全云里雾里。每一次遇到一个小问题，比如某个模块无法正常加载，我都要在官方论坛里搜寻半天，然后找到一个看似专业的回答，再照猫画虎地在命令行里输入一串看不懂的命令。

这感觉就像是，你跟一个厨艺大师说：“我想学做饭。”他给了你一个顶级的米其林厨房，里面摆满了各种我连名字都叫不出来的工具，然后指着一个按钮说：“这个是用来处理分子料理的。”而我，只想学会如何煮一碗面。这些平台根本不是为“零基础”用户设计的，它们是为有基础的程序员准备的“省力工具”，却用“赋能小白”的谎言来包装。

过家家式的编程与智商上的碾压

在克服了最初的安装和配置障碍后，我终于迎来了真正的“编程”环节。我兴奋地在对话框里输入我的需求：写一个简单的“贪吃蛇”游戏。AI很快生成了代码，并在IDE里显示了一个小小的黑色窗口。那一刻，我感到一丝胜利的喜悦。但这喜悦并没有持续太久。

我很快发现，这些低代码平台能生成的，大多是这种“过家家”式的项目。它们通常都具有几个共同特点：

简单的物理规则：移动、碰撞、得分，仅此而已。

线性的逻辑：游戏从头到尾只有一个目标，没有分支，没有策略。

弱交互性：玩家的输入只能是几个简单的方向键，无法影响游戏进程。

于是我尝试提出一个稍微复杂一点的需求：“生成一个推箱子游戏。”

这下，麻烦来了。AI生成的代码总是无法正确处理箱子与墙壁的碰撞，或者在玩家走位后无法正确判断胜利条件。我尝试用自然语言修正它：“让箱子不能推入墙壁。”“当所有箱子都在目标点时，游戏胜利。”每一次修正，AI都像一个不听话的孩子，生成出各种匪夷所思的代码，让整个游戏变得一团糟。

我终于意识到，推箱子游戏需要一个复杂的“状态机”和“路径规划”逻辑，它不仅仅是简单的物理碰撞，还涉及到策略和多步思考。而这些，正是低代码平台和AI目前无法真正处理的。它无法像一个人类程序员那样，理解“推箱子”背后所蕴含的复杂逻辑。它能做的，只是把简单的指令翻译成简单的代码。

我再试着挑战了一下“马里奥”游戏，结果更是惨不忍睹。马里奥需要跳跃、重力、碰撞检测、敌人AI、关卡设计……这些都不是简单的“物理规则”。最终，我只能得到一个勉强能左右移动的方块，它甚至不能跳起来，更别提吃蘑菇变大了。

被剥夺的自由与无法逾越的鸿沟

在我的30天旅程中，我发现这些平台不仅没有降低门槛，反而制造了另一种形式的“围墙花园”。它们将我局限在固定的模块和框架内，一旦我的想法超出了预设的范围，整个系统就会崩溃。

例如，当我试图改变游戏界面的颜色时，我发现没有一个直观的“调色板”让我选择。我必须在复杂的配置文件里寻找对应的十六进制代码，然后手动输入。这对我来说，和直接写CSS有什么区别？

更糟糕的是，当我尝试将两个不同的功能模块（比如一个得分系统和一个计时器）组合在一起时，我发现它们根本不兼容。我不得不放弃其中一个，或者重新从头开始。这让我感到被剥夺了自由，仿佛我在一个被严格限制的乐高世界里，只被允许搭建官方指定的模型，而不能进行任何即兴创作。

这些平台所宣称的“赋能”，其实是有限的赋能。它们就像是为程序员准备的半成品套件，让有经验的人可以更快地搭建原型。但对于一个真正的零基础用户，这套工具不仅没有帮助，反而带来了巨大的认知负担和挫败感。它让我感觉自己像一个想要学开车的人，结果被给了一辆没有方向盘、只有两个按钮的遥控汽车，它能往前走，也能往后退，但一旦你想转弯，它就会直接撞墙。

这些平台所提供的，本质上是一个“黑箱”。你不知道代码是如何生成的，也不知道它为什么会崩溃。当你遇到问题时，你无法像一个真正的程序员那样进行调试，只能无助地对着屏幕发呆，或者在社区里寻求帮助。这不仅没有降低门槛，反而制造了另一种更深的焦虑和无力感。

唯一的安慰：Trae的“Solo模式”

在经历了连续两周的挫败后，我几乎要放弃了。直到我偶然在字节跳动的Coze平台内部，发现了一个名叫“Solo模式”的功能。这个模式与整个平台的复杂IDE截然不同，它没有眼花缭乱的工具栏，也没有复杂的项目结构，只有一个简洁的对话框。我只需要用最自然的语言描述我的想法，它就能在代码里给出恰当的建议。

我发现，这个“Solo模式”的强大之处恰恰在于它不需要我做任何额外的操作。它不要求我理解IDE的本质，也不要求我理解安装部署，它只是静静地待在那里，当我需要它时，它会立刻出现。

例如，我只是想写一个简单的网页，我告诉它：“写一个带图片的网页，图片要居中。”它能立刻给我一个包含HTML和CSS的代码块，我只需要复制粘贴就能用。它不会强迫我进入一个复杂的项目结构，也不会要求我配置什么环境。它只专注于一件事：在我需要的时候，提供最直接、最有效的帮助。

这种模式给了我极大的安慰。它让我意识到，真正成功的AI编程工具，不应该是把一个复杂的IDE伪装成一个简单的玩具。它应该是像一个无形的助手，在背后默默地工作，为专业人士提效，也为我们这些小白提供一个真正意义上的“一键解决”方案。它不要求你变成一个程序员，它只希望你保持你的“人类”身份，用人类的语言去沟通。

这就像是，一个真正的助手不会要求你先学会如何使用所有的文件柜和打印机，它只会问你：“你需要什么文件？”然后立刻递给你。

零代码的未来，到底在哪里？

在结束我的30天“折磨之旅”后，我开始反思。我们现在所看到的这些“低代码/零代码”平台，它们真的在为我们这些用户服务吗？

从我的体验来看，它们更像是一种“为程序员而生的低代码”。它们可能对那些有一定基础、希望通过图形化界面快速搭建原型或进行模块化开发的程序员有帮助。但对于我这种真正的“零代码”用户，它们反而成为了一个巨大的负担。它们给我设置了一道又一道的门槛，逼迫我去学习那些本不该由我来学习的知识。

它们宣称“人人都是开发者”，却只交付了“人人都需要学习开发基础”的产品。

最终，我用这30天的时间，没有做出一个像样的应用程序，却深刻理解了一个道理：AI编程的未来，绝不应该是把一个复杂的工具变得稍微简单一点。真正的未来，是让AI完全理解我们的意图，然后自动、无缝地完成所有繁琐的工作。这需要AI从“代码生成器”转变为“意图理解器”，从“工具”转变为“真正的副驾驶”，为我们指引方向，而不是让我们自己去摸索如何驾驶。

如果说贪吃蛇和俄罗斯方块是这些平台的极限，那么马里奥和推箱子就是它们无法逾越的鸿沟。而我，只想让AI帮我跨过这道鸿沟，而不是让我自己去学习如何搭一座桥。

我的30天，是一场被折磨的旅程，但它也让我对AI编程有了更清醒的认识。也许，真正的“零代码”时代，还没有真正到来。