近几年，AI进化非常迅速且强大，尤其在编程领域，身边的朋友包括我自己，现在也基本上不会手写代码了，从最开始与AI进行问答对话解决具体问题，到使用AI IDE如Cursor、Trae进行辅助式编程，再到现在使用Trae SOLO、Claude code全程通过对话构建项目。

这种使用自然语言完成编程项目的能力，也使得其从程序员圈子火到了行外，各种vibe coding的视频分享和零门槛创建产品的课程漫天飞，似乎普通人真的可以零门槛、快速地创建生产级产品。最近自己使用AI原生的方式做了几个小项目，而且都是非常简单的偏工具类的项目，真正实践下来，发现其中似乎存在不少大家共识性沉默的隐性问题。

项目简介

HancicSite，一个个人博客网站，使用极致个性化定义的模板定制，用于发布和管理个人博客。
报安者，一个微信小程序，面向独居青年和老人，提供语音打卡、提醒和一键救援功能。
AlphaReport，一个股票分析助手，主要是为了在选股进行辅助决策，通过预设分析模板，调用LLM模型API生成对应的个股分析报告。
AssertTracker，一个数字资产管理工具，用来追踪订阅类（如周/月/年卡、房租、物业费）和储值类（如理发店）资产，生成日/月均费用、分类统计信息等报表。
CoachHelper，一个自由游泳教练的辅助工具，管理学员报名、排课和课堂总结。

其中只有2是小程序，发布上线后就没有在维护了，其余几个项目都是纯网站，没有小程序和app版本，后续都有持续维护。从真实的使用上，1和3的使用频率最高，4和5偶尔使用。

问题反思

低门槛绝不是零门槛

很多自媒体在推销课程时，为了扩大自己的用户群体，通常大肆宣传“零门槛AI开发原生app”，然而这显然刻意回避了AI开发背后所需要的隐性知识。

一个对编程完全一窍不通的人，大概率连什么是前后端、数据库、服务器、网络域名之类都没概念，固然AI原生开发使得使用者无需关心这些复杂的基础原理，但是若对一个完整应用包含的模块都不清楚，就很难建立起有效的生产流程，而不用谈后续的迭代和维护了。以上这些基础概念，或许可以通过几个简单的教程视频建立起初步的框架，并按照别人总结的流程和工具跑起来，并产出第一个简单的演示级别的应用。

然而，这仅仅只是“做出来”，并不一定能“跑起来”，大部分AI只会帮你把代码写出来，并不会涵盖部署的步骤，也就意味着你需要了解CI/CD的知识，清楚自己是要容器化部署还是服务器部署上，域名和ssl证书如何申请，服务器代理如何配置，网络拓扑结构怎么设计。

在迈过这一级门槛之后，网站应用只是走到了“跑起来”的阶段，还不一定真正可用。在没有显式声明的情况，AI并不会进行合理的技术选型，而通常使用自己所擅长的解决方案。不同的前端框架在实现服务可用性方面或许没有太多区别，但不同的后端框架和数据库却往往对服务的可用性、扩展性有着显著的影响，后端服务究竟是使用python还是rust的框架，使用flask还是fastapi，数据库使用sqlite，还是mysql，postgresql还是mongodb，这些问题AI都不会主动暴露，即便暴露出来，对于没有工程经验的人来说，无异于对牛弹琴。

60分只是漫长旅程的起点

当我们将迸发灵感创意用自然语言的方式说给AI，它用了不到几分钟就做出了一个60分的东西，视觉效果还不错，想要的功能都有，看起来非常振奋人心，似乎我们很快就可以将它做成一个至少90分的产品。然而，真正走进去才发现，在迈出万里长征的第一步之后，接下来走的每一步都是举步维艰。

60分给出的只是毛坯，只有视觉和功能框架，从60分到70分，开始只是调整调整样式、布局和文案，修复一些小的bug，本以为只需要一两句话就可以完成，但实际过程中发现，一个简单的样式调整可能需要好几轮对话，尤其是使用模型不够聪明的时候。当你说添加一个按钮的时候，AI不会考虑按钮的大小、样式与整体网站的一致性，也不会思考按钮会不会影响其他控件的布局，不会考虑跨终端设备时响应式的呈现问题，不会想到是否需要添加确认对话框，这些问题需要设计者本身对自己要实现的功能有很细节的思考，并在提示词里尽可能详细且准确地表述，明确样式、布局、行为、影响，并避免其对已有稳定功能的恶意破坏，这一阶段往往是对AI强大能力祛魅最快的时候。

60分的时候我们只关注主要功能，但一个完整可用的产品往往需要很多不可或缺的辅助功能，很少有人能在初步阶段，就将功能细节考虑得很全面，从70分到80分，就是对其功能细节进行打磨完善甚至推倒重来，这一部分也相当磨人，这意味着你需要更加深度地思考整个产品细节。

比如在做AlphaReport时，第一版就实现了调用LLM生成分析报告，但后来发现需要实现一系列辅助配置来完成一个相对完善的应用，LLM需要支持适配和切换多个大模型接口，哪些模型可以得到有效的结果，哪些模型质量不行，如何针对不同的模型提供不同的提示词，同时要保证输出的一致性和稳定性；我们还需要一个搜索框来选择要分析的股票名称和代码，也就意味着需要有一个股票列表，这个股票列表需要及时同步，以保证包含新上市公司、排除未上市公司，股票列表包含哪些市场呢，沪市、深市、北交所还是其他的，股票列表的数据源选择哪个来保证稳定性，测试数据源的可用性，减少网络抖动、接口请求限制等问题的影响；是否开放用户注册，账号和密码的规则如何设计，用户注册后如何管理，是否需要监控用户登录日志，用户角色和权限如何设计，不同角色登录后界面和行为有哪些不一样的行为，诸如此类的功能设计不胜枚举，这还仅仅只是对于这么简单的产品。

即便熬过这一阶段，勉强将产品打磨成了功能完备可用的程度，并将其部署上线，但从80分的功能性产品到90分的生产级应用，这里面依然有着难以逾越的技术鸿沟。

构建生产级应用并不容易

作为本地demo应用，你悄悄地忽略了太多需要解决的生产级别问题。本地运行时，你不需要面对弱网络的环境，不需要考虑多用户并发，看不到激增的数据量所带来的严重性能问题，不会去考虑如果系统出现故障如何应对，很少去想如何进行服务和数据的迁移，用户量和数据量激增所带来的成本如何控制，如何避免数据安全风险，如何进行日志监控、运维告警、版本迭代、灰度发布……这些生产工程层面的能力，AI 不会主动构建，零基础入局者更容易完全忽略。很多人止步于 80 分 Demo 级可用，却永远跨不进生产级落地的门槛。

即便我们可以通过各种skill来进行优化提效，比如使用前端skill来生成美观的UI，或者其他一些常见功能封装skill来实现快速实现权限管理、用户管理、日志管理、通知接入等通用功能，但依然要面对那些生产环境的问题，更加重要的是因为项目交给了AI全包，我们对于具体的项目实现逻辑通常一知半解，甚至是一无所知，很少会有人耐心地读完并理解AI输出的冗长的文档和复杂的项目代码。在线上出现问题的时候，会变得手足无措，不知从何下手，有人说可以将线上问题的处理也全权交给AI，但至少在目前，我并不觉得这是一个可以落地的方向，AI可以作为线上问题排查的辅助手段，但绝对不能代替工程师，对生产环境的任何操作（不止是操作，有时候即便只是观察）都可能引发蝴蝶效应，进而造成惨重的损失，AI并不能对此负责。

成本很难得到有效控制

很多新手在VibeCoding初期沉浸在自己拥有产品的幻觉和自嗨中，有意识地忽略了这背后的成本，尤其是算力token的消耗。尽管当前各大模型厂商在初期都有一些免费的token额度，但真正做项目时会发现完全不够用，随后便付费订阅很多CodingPlan，然而由于对AI的驾驭能力有限，套餐内的token也无法满足需求，于是便不得不额外购买一些套餐外的资源包，最后发现原本预想的“一句话构建应用”是一句鬼话，花了几十或上百刀做出了一个完全无法产生任何经济收益的花瓶。更重要的是，即便你在做完第一个项目后，认识到了这个问题，你依然无法有效地估算下一个项目会有多少算力消耗。这种成本上的不可控，让很多满怀热情的尝试最终变成了昂贵的“学费”。

简单来说，AI只是降低了编码门槛，但认知门槛、运维门槛、工程选型门槛，一个都没消失。

好的方面

但是从另一方面来说，对于编码门槛儿的降低，已经能为普通人带来很多有价值的事情。

其中一个我觉得非常有趣的事情就是，我们不再需要很多付费的Saas服务，以往每年几十或几百的工具类应用，现在可以很快地实现出来，并轻松解锁其中的高级付费功能，同时因为这些应用并不需要面对大量的用户和数据量，可以完全规避掉大量复杂工程类的问题，甚至你不需要发布到服务器，不需要上架AppStore，仅仅只需要一个在本地的浏览器或者应用快捷方式，更重要的是因为它只服务于自己，所以可以高度定制化，且数据完全自主可控。

另一个方向就是我这种对于已经具备工程经验，有一定技术广度，但缺乏多项技术深度的工程师，构建一些应用变得比以往更加轻松，可以快速地聚焦于产品功能和创意。以个人博客为例，很久以前就有这种想法，也尝试做过一些，但当时自己对前端不熟，为了实现它，将大部分精力花在了学习前端上，经常为了一些布局样式不生效、多设备响应不合理等这些简单问题而浪费大量的时间，慢慢地消磨了最初的兴趣，最终半途而废，而在HancicSite这个项目里，我只花了半天就完成项目的高度定制和上线部署。