以前，程序员开发功能，基本都是自己一行一行写代码。现在，很多时候不用这么干了，而是直接跟 AI 说需求。
比如："帮我做一个日历，要显示农历，还能左右滑动切换月份。""把这份销售数据做成一个深色风格的数据看板。""这个页面手机上看太挤了，帮我重新调整一下布局。"
AI收到这些要求后，就会开始写代码、搭页面、调用接口、修复报错。程序员更多负责提出需求、检查效果，不满意就继续调整，让 AI 接着改。
这种开发方式，现在通常叫 Vibe Coding，简单来说，就是用自然语言和 AI 沟通，让 AI 帮你完成软件开发。
放在以前，一个功能从零开始，开发者要先查文档、找接口、搭框架，再一点点解决各种报错，整个过程既费时间又费精力。现在，这些重复性的工作，很多都可以交给大模型来完成。
当然，AI 能不能做好，很大程度上取决于需求说得够不够清楚。描述越具体，AI 给出的结果通常越符合预期。所以现在开发者最重要的能力，不只是会写代码，更是能把自己想做什么、页面怎么交互、有哪些限制、适合什么场景，清楚地表达给 AI。
这并不是说学编程一下子就没价值了。AI确实能帮你写代码，但生成的内容还是要自己检查。遇到复杂项目，像整体架构怎么设计、数据怎么保证安全、性能怎么优化、后续怎么维护，这些依然离不开有经验的人来把关。
真正发生变化的是，现在把一个想法做成产品，不再只有"先学会写代码"这一条路。就算不会熟练编程，也可以借助大模型快速做出一个原型，甚至开发出真正能用的应用。
不过，很多人还是会问：AI写的代码靠谱吗？是不是只能写点"Hello World"这种简单示例，一做复杂功能就各种报错？它到底能不能支撑一个完整的应用，稳定运行、真正服务用户，甚至拿去参加正式比赛？
今年的 Apple 移动应用创新赛，就给出了一个很有说服力的答案。参赛选手里，80%都不是计算机专业，95%的学生在开发过程中使用了大模型辅助。也就是说，很多参赛者并不是传统意义上的程序员，但借助 AI，他们依然完成了应用的设计和开发。
这些作品并不是那种只能演示几分钟的"小工具"，也不是只有几个页面的概念Demo，而是真正能用的应用。有人做烹饪教学，有人帮助外国游客看懂中国菜单，还有人把孩子画的画变成有声音的绘本。它们都有明确的使用场景，功能也能正常运行，用户拿到手就知道该怎么用。
所以，判断AI写代码到底好不好用，关键不是它一次能写多少行代码，而是它能不能帮开发者把真实问题解决掉，把一个真正能用的产品做出来。
比如微Cook，就是一款烹饪培训应用。它有一个很有意思的功能：菜谱里的配图全部都是AI生成的。开发团队接入了 Apple Intelligence 的 Image Playground 接口，在设备本地根据文字生成图片，同时还结合 Apple Foundation Model，为应用加入了本地AI能力。
对普通用户来说，这些技术细节几乎不用关心。你不用知道什么是 Stable Diffusion，也不用研究本地模型是怎么推理的，更不用了解扩散模型的工作原理。开发者只需要把接口接好，把输入和输出设计清楚，应用就能根据菜谱内容自动生成对应的图片。
比如你想学做宫保鸡丁，应用不会一下子甩给你一大段做法，而是把整个过程拆成一步一步来。做到"热锅凉油，放花椒和干辣椒炒出香味"时，页面会马上显示对应的画面；到了"放入鸡丁，大火快速翻炒到变色"，图片也会变成鸡丁在锅里翻炒的样子；接着"倒入提前调好的酱汁，翻炒均匀"，画面又会跟着更新。这样一边看步骤，一边看图片，比单纯看文字更直观，也更容易照着做。
以前想做出这样的效果，通常要程序员、UI设计师、插画师和内容编辑一起配合，花不少时间才能完成。现在有了AI，很多工作都能交给模型和现成的工具来完成，就算是几个没有计算机专业背景的学生，也能把这样的功能做出来，开发门槛低了很多。
上海交通大学Food Hub团队开发的这款应用，主要是想帮助外国人更轻松地了解中国美食。很多人在国外点餐时，都会遇到菜单翻译不准确的问题。比如有人在日本一家街边小店，面对满满一页片假名，只好用翻译软件拍照，结果翻出来的是"鱼的事情""肉的盒子"这种让人完全看不懂的内容。后来换了豆包等AI工具，才知道原来菜单写的是生鱼片拼盘和炸肉饼。
Food Hub把这种思路用在了在国内点餐的场景里。你对着菜单拍张照，点一下上面的菜名，就能立刻看到这道菜用了什么食材、是怎么做的、口感怎么样，甚至还能了解到它背后的美食文化。里面那些菜品图片，全是用AI"画"出来的。
要是放在五年前，想做这么一款软件，那可真是个大工程。你得找齐写后端的、做前端的、画插画的、做UI设计的、搞运营的和做翻译的一整套人马。但现在完全不一样了，哪怕只是几个学生组的小团队，也能先让AI把代码、界面和内容的大框架一口气搭好，他们后面只需要做些检查和修改就行了。
还有个做声音绘本的软件也挺有意思，界面看着很温馨，用起来也简单。它的作者其实就是一位普通的妈妈。她的做法特别聪明：先把自家小孩画的画拍下来，让AI看懂并写出描述，比如"一个穿着粉色小裙子的女孩，正在花园里追蝴蝶"；接着再让AI根据这句话，生成一套风格统一的精致插画，最后配上声音和版面设计，一本属于孩子的完整绘本就这么做出来了。
孩子随手画的一幅画，不用再只是夹在画册里或者放进抽屉，而是能整理成一本可以翻看、播放、长期保存的小作品。整个过程没有什么复杂的技术，也没有一大堆花里胡哨的功能，它做的就是一件很简单的事：把孩子的画，还有画画时的故事，一起记录下来。
在AI领域，大家经常讨论模型准确率能不能再提高一点，比如从99.2%提升到99.3%；推理速度能不能再快几毫秒；生成图片的评分能不能再高一些。这些技术指标当然很重要，但对于普通用户来说，他们不会因为这些数字变好了，就一直使用一款产品。大家更关心的是，这个工具用起来顺不顺手、稳不稳定、生成的内容准不准确，最关键的是，它到底能不能帮自己解决实际问题。
Vibe Coding带来的变化，正好体现在这一点上。以前，很多人脑子里有想法，也知道自己想做什么，却因为不会写代码，只能停留在想法阶段。现在，只要把自己的需求告诉AI，它就能先生成一个可以运行的基础版本。接下来，你再像聊天一样，不断提出新的需求，让AI修改页面、增加功能、修复问题，慢慢就能把一个想法变成真正可以使用的软件。
"这个表格按时间排序，最新的放最前面。"
"输入手机号的时候，自动过滤掉空格。"
"订单提交成功后，弹个提示，告诉用户已经下单了。"
"网络断开的时候，提醒用户检查网络，然后可以重新试一次。"
"删除之前先让用户确认一下，别一点就直接删掉了。"
别看这些要求说起来都很简单，其实每一句背后都有具体的规则。比如按钮大小涉及使用体验，搜索功能关系到页面交互，未登录不能看个人信息是权限和隐私要求，图片加载失败要提示属于异常处理，本地运行、不上传数据则涉及数据安全。这些需求说得越清楚，AI越容易理解，写出来的代码也越符合预期。
至于AI写的代码到底好不好用，并没有一个统一答案。如果需求说得清楚、范围比较明确、测试也做得充分，AI确实能大大提高开发效率，甚至让没有计算机背景的人也能做出一个完整的应用。但如果需求本身比较复杂、涉及较高风险，又缺少人工检查和测试，AI生成的代码也可能埋下新的问题，仍然需要认真审核和完善。
很多校园里的AI应用比赛已经证明，Vibe Coding不只是拿来做个演示，真的可以做出能用的产品。比如，有学生不会写太多代码，却借助AI开发了一个校园失物招领小程序。用户拍张照片、说一句物品特征，AI就能帮忙整理信息、生成寻物公告，大大降低了找回失物的难度。
这也说明了一件事：代码当然还是很重要，但现在开发产品，比拼的已经不只是敲代码的速度。真正拉开差距的是，谁更清楚用户到底需要什么，谁能把自己的想法准确告诉AI，谁能发现AI生成内容里的问题并不断调整。做到这些的人，更有机会把一个想法变成真正有人愿意使用的产品。