零代码用AI四天做出上架APP：鸿蒙开发实战全记录

一个数码博主的突发奇想

复古相机类App这两年在应用商店里遍地开花，但B站UP主「刚刚」发现了一个空白：市面上几乎没有一款真正能「动起来」的复古DV应用。恰好他从抽屉底翻出一台连开机都靠运气的老DV，那种糊到看不清的画面，反而勾起了强烈的怀旧感。

于是他萌生了一个想法——做一款能一键把手机画面倒回1995年的「时光DV」App。最关键的是：他一行代码都不会写。整个过程历时四天，全程靠AI陪跑，这款App最终真的上架了华为应用商店。

这个案例之所以值得聊，正是因为它展示了vibe coding（AI辅助编程）的真实门槛已经低到什么程度——一个纯门外汉，也能把想法变成可交付的产品。

什么是Vibe Coding？ 这一概念由前特斯拉AI总监、OpenAI联合创始人Andrej Karpathy于2025年提出，描述一种完全依赖AI生成代码、开发者几乎无需理解底层实现逻辑的编程范式。与传统编程不同，vibe coding的核心是用自然语言描述意图，让AI完成所有实现细节，开发者的角色更接近「产品经理」而非「工程师」。这一范式的兴起，标志着软件开发的准入门槛正在经历结构性重塑。值得注意的是，Karpathy在提出这一概念时特别强调，vibe coding并非要取代专业工程师，而是为那些有想法但缺乏编程能力的人开辟了一条「从概念到原型」的快速通道——它降低的是起步门槛，而非消除了工程复杂性本身。

为什么首选鸿蒙平台开发

作者研究了安卓、iOS、鸿蒙各主流开发环境后，得出结论：对新手最友好的平台是华为鸿蒙。

原因很现实——门槛与成本。国内其他安卓商店基本已不接受个人开发者入驻；国外平台一个每年要交700多元，另一个还要先付20多美元。而华为个人开发者身份免费即可入场，几乎全程绿色通道，还额外提供了面向个人开发者的激励计划。

值得一提的是，这里所说的鸿蒙，特指华为自2023年起全面推进的「纯血鸿蒙」——即HarmonyOS NEXT。与过去兼容安卓APK的混合版本不同，纯血鸿蒙在底层架构上做出了根本性的选择：它采用微内核设计，将操作系统的核心服务（如文件系统、驱动管理、网络协议栈）拆分为独立进程运行在用户态，内核本身只保留进程调度和内存管理等最基础的功能。这种设计与Linux宏内核的哲学截然不同，在安全隔离性上具有理论优势，但也意味着华为必须从零构建完整的开发者生态——这正是ArkTS语言和ArkUI框架诞生的根本原因。由于底层内核、运行时环境与框架层均为华为自研，彻底移除了对安卓生态的依赖，开发者无法将现有安卓代码直接移植，必须使用华为专属的技术栈重新构建应用。对于新手而言，这反而是一个相对「干净」的起点——没有历史包袱，官方文档和开发工具链高度统一，不需要在碎片化的安卓生态中做艰难的兼容性选择。

「平台愿意给素人留这样一个口子，这点还是蛮打动人的。」

这也折射出一个趋势：AI大幅拉低编程门槛的同时，平台对个人开发者的开放程度，正成为「普通人能否真正做出产品」的另一关键变量。

三个AI工具如何分工协作

这次开发主要用到三个工具，作者对各自定位划分得很清晰：

• Cursor：主力写代码工具，对接模型更多，适应场景广泛，适合需要自己上手改代码的场景。
• Codex：上手难度更低，擅长UI设计，还能调用自家生图模型，图片质量很高。
• 华为 DevEco Studio：官方开发工具，内置AI对话窗，支持切换大模型，还能自建智能体。

值得一提的是他没选当下很火的 Claude Code——原因「懂的都懂」：封号风险和充值门槛让人却步。相比之下，Cursor 扫支付宝即可使用，省心得多。这代表了很多国内用户在AI工具选择上的现实考量。

从工具定位来看，Cursor本质上是一款深度集成了大语言模型的代码编辑器，它基于VSCode内核构建，支持在编辑器内直接与AI对话、让AI读取整个项目上下文后生成或修改代码。其核心优势在于「项目级上下文感知」——它能够索引整个代码仓库，在多个文件之间追踪函数调用关系、类型依赖和模块边界，因此特别擅长处理需要跨文件协调的复杂逻辑修改。Codex则更接近一个以对话为主界面的AI编程助手，其底层模型对前端UI生成做了专项优化，且与DALL·E等生图模型的打通使它在设计环节具备天然优势——用户可以在同一个对话窗口中描述需求、生成参考图片、再将图片直接转化为可运行的UI代码，无需在多个工具之间切换。两者的核心差异在于「上下文感知深度」与「设计能力」之间的取舍：前者更擅长处理跨文件的复杂代码逻辑，后者在视觉原型生成上体验更流畅，且对完全没有设计背景的用户更加友好。

新手第一课：让AI解决AI之外的障碍

真正上手时，作者结结实实吃了个下马威。第一次打开华为 DevEco Studio，满屏英文加上各种面板直接让他懵掉——AI让他点「设置」，他找了半天没找到入口，一度怀疑自己能不能干成这件事。

后来他「悟了」：为什么要自己找？直接把界面截图丢给AI，让AI告诉他在哪，甚至让AI分析原因。最终AI判断出是版本下错了，换对版本后整个流程就顺畅了。

这个细节很有代表性。AI辅助编程的真正价值，往往不只是「帮你写代码」，更是帮完全没有经验的人跨越那些劝退新手的环境配置障碍。把问题、报错、截图丢给AI，让它充当全程陪跑的助教，是零基础用户最实用的工作方式。

这一工作方式在业内被称为「多模态调试」——将视觉界面截图与文字描述一并输入给支持图文理解的大模型（如GPT-4o、Claude 3.5等），让模型直接「看图说话」定位问题。这背后依赖的是视觉语言模型（Vision-Language Model，VLM）将图像中的视觉元素与语义概念对齐的能力：模型不仅能识别截图中的按钮、菜单栏等UI组件，还能将这些视觉信息与其训练数据中关于特定软件版本的知识关联起来，从而给出具体的操作路径。对于像DevEco Studio这类面板复杂的IDE（集成开发环境），这种方式的效率往往远高于在搜索引擎上翻文档，因为AI能将截图中的视觉元素与特定版本的软件行为直接对应起来，给出具体的操作路径而非泛化的通用建议。这种能力对新手尤其关键——他们往往连「我遇到了什么问题」都难以用专业术语准确描述，而截图让这道沟通障碍几乎消失。

架构思维：先搭引擎，再堆功能

鸿蒙是相对较新的平台，网上现成经验不多。作者的解法是让AI直接扒华为官方文档，整理成笔记再喂给 Cursor，同时讲清楚自己的需求。

Cursor 给出的第一步是先跑通 MVP（最小可用版本），专门验证核心功能。MVP（Minimum Viable Product）是精益创业方法论的核心工具——用最低成本实现一个功能闭环，快速验证核心假设是否成立，避免在未经验证的方向上过度堆砌功能。对于独立开发者而言，MVP思维尤其关键：它迫使你回答「这个产品最不可或缺的一个能力是什么」，而不是陷入无止境的功能列表。这一概念由埃里克·莱斯（Eric Ries）在《精益创业》中系统化提出，最初针对的是初创公司在资源有限情况下如何快速试错——而在AI辅助开发的语境下，它同样适用于个人开发者：AI能快速帮你搭起骨架，但如果一开始就贪多，代码复杂度会指数级上升，AI给出的建议也会因上下文混乱而质量下降。

作者做对了一件关键的事——没有闷头堆功能，而是先把整个应用的核心主体搭好：合成引擎。

「时光DV」要改的是视频合成后的画面，这涉及到移动端视频合成引擎的核心机制。合成引擎本质上是一套基于GPU着色器（Shader）的实时图像处理管线：摄像头输出的每一帧画面都会经过GLSL（OpenGL Shading Language）或类似着色器语言编写的程序处理。GLSL程序在GPU上对数百万个像素并行执行运算，这种大规模并行计算架构是实时视频特效成为可能的根本原因——CPU的串行计算架构根本无法在16.7毫秒内逐像素处理完一帧4K画面，而GPU的数千个计算核心却能轻松胜任。具体到复古特效，着色器程序会对像素执行颜色矩阵变换（模拟色偏）、随机噪点叠加（模拟颗粒感）、边缘模糊（模拟低分辨率镜头）等处理，最终合成输出复古质感的画面。

从技术实现角度看，这条处理管线通常分为三个阶段：首先是输入层，摄像头采集的YUV格式原始数据被转换为GPU可处理的纹理（Texture）；接着是着色器处理层，片元着色器（Fragment Shader）对每个像素并行执行颜色运算，这一步是复古特效的核心所在；最后是输出层，处理后的帧数据被编码为目标格式写入存储。由于这套处理必须在GPU上实时完成（通常需要在16.7毫秒内处理完一帧以达到60fps），且所有后续滤镜效果都要「挂载」在这个管线上，合成引擎的稳定性直接决定了整个App的性能天花板。有了这个地基，后续做UI、加功能就顺畅得多。

有意思的是，这种架构思维并非来自编程经验，而是来自他做视频的本能——自然会想到「把所有素材汇聚到剪辑软件里处理」。领域经验在AI编程时代依然是稀缺的、可迁移的优势。

鸿蒙的「较真老师」体验

对于纯血鸿蒙使用华为自研内核、与安卓底层完全不同这件事，作者一开始心里没底。但结果出乎意料：不光没怎么报错，整体写起来还特别顺畅。

他形容鸿蒙用的这套语言像个「较真的老师」——你刚写错，它当场就圈出来，不会憋到最后来个大爆发。这种即时反馈体验背后，是ArkTS语言的静态类型检查机制在发挥作用。

ArkTS是华为基于TypeScript扩展的强类型开发语言。与JavaScript或Python这类动态类型语言不同，ArkTS要求开发者在声明变量时显式标注数据类型，且禁用了TypeScript中部分「逃生舱口」特性——例如限制any类型的随意使用、强制要求接口声明等，这些约束被华为称为「方舟规范」。要理解这种设计的价值，需要先了解静态类型系统与动态类型系统的本质区别：动态类型语言（如Python、JavaScript）在代码编写时不要求声明变量类型，解释器在运行时才进行类型推断，这带来了书写上的灵活性，但也意味着类型错误只在程序实际运行到出错的那一行时才会暴露——有时这样的Bug要在特定用户操作下才会触发，极难复现和排查。静态类型语言则在编译期完成完整的类型推断和验证，类型错误在代码保存的瞬间就被IDE标红，从根本上消除了这类「定时炸弹」。配合ArkUI声明式UI框架，整套系统能够在编译期（而非运行时）捕获大量类型错误和逻辑漏洞，对新手而言大幅降低了排错的认知负担。更重要的是，这一特性与AI辅助编程的工作流形成了良好的协同：AI生成的代码如果存在类型问题，IDE会立即高亮标注，开发者可以将报错信息直接反馈给AI要求修正，形成「生成-检查-修正」的高效闭环。

UI设计：从「看不下去」到一眼对味

最直观的部分是UI设计。作者先让 Cursor 自动生成一版，结果每换一轮都难看到自己看不下去，生成的图片存在本地，得翻半天文件才能打开。

后来他冲了 Codex 的 Plus 会员，体验立刻不同：第一轮生成的两张图里就有一张特别对味的复古风格，图片在对话窗里直接可见，还能让它根据这张图用代码在网页上画出可交互的UI原型。

这种「图生代码」的工作流在前端设计领域被称为「设计转代码」（Design-to-Code），传统上依赖Figma等专业设计工具与开发工具之间的插件桥接来实现，整个流程需要设计师、前端工程师两个角色协作完成，往往耗时数天。AI的介入让这条链路大幅压缩：用户只需提供一张参考图（无论是AI生成的还是手绘草图），模型便能直接输出对应的HTML/CSS/ArkTS组件代码。这一能力的底层支撑是视觉语言模型对UI组件的语义理解——模型能识别按钮、卡片、导航栏等标准UI元素，并将其映射到对应的代码组件。Codex在这一环节的额外优势在于其与图像生成模型的深度集成：它不仅能理解设计意图，还能在同一对话上下文中保持视觉风格的一致性，确保多轮迭代后生成的界面元素在色调、字体、间距上保持统一，避免「越改越乱」的问题。对于没有设计背景的开发者而言，这意味着「脑海中的画面」和「屏幕上的界面」之间的转化成本被降到了前所未有的低点。

经过这轮对比，他总结出最优分工：写代码、改代码用 Cursor，做设计和生图用 Codex——各有侧重，组合使用效果最佳。

成品体验：把青春一键倒带

以前要拍出老DV的质感，得开专业模式手动压曝光、调白平衡，再拖进剪辑软件一点点加特效。现在只需点击App里的「时光舱」，就能从2020年的口袋机一路倒回1995年的初代DV，连UI上的小图标都是照着当年的样子1:1还原。

作者最得意的细节，是1995年那一档画面「微微发绿」——这不是Bug，而是刻意还原的feature：那个年代的DV白平衡本来就不准，画面天然偏绿。这一特性在技术上对应的是早期CCD传感器的色彩矩阵缺陷。1990年代的消费级DV普遍使用单片CCD（电荷耦合器件）传感器，与现代手机摄像头采用的多传感器融合方案不同，单片CCD依赖拜尔滤镜（Bayer Filter）对色彩进行空间插值——拜尔滤镜是一种覆盖在感光元件上的彩色滤镜阵列，以2×2为一个重复单元，包含1个红色、2个绿色、1个蓝色滤镜（绿色占比更多是因为人眼对绿色亮度最敏感），通过对相邻像素的颜色信息插值来还原完整色彩。这种插值过程本身就存在色彩精度损失，再加上当时的自动白平衡算法受制于处理器性能，计算量严重不足——现代手机白平衡算法每秒可进行数千次色温采样和矩阵运算，而1990年代的DV处理器往往只能做到每秒数次。在室内钨丝灯（色温约2700K）光源下拍摄时，算法无法准确补偿暖色调，经过色彩矩阵运算后反而产生偏绿的色调漂移。这种由硬件局限和算法不成熟共同造就的「不完美」，在数十年后的今天却成为了一代人视觉记忆的情感锚点。为了验证效果，他还专门买了一台真正的老DV做画面对比，那种轻微发红、边缘晃动的颗粒感，让他直呼「青春回来了」。

AI编程走入普通人家，但天花板依然存在

四天折腾下来，作者最大的感受是：AI编程真的以「零门槛」的姿态落入了普通人家里，一个一行代码没写过的门外汉都能做出一个上架的App。

但他也保持了难得的清醒——这个App相当简单，仍有一些Bug是AI也解决不了的，最终方案是让AI去开发者论坛搜索别人的解法。换句话说，关键难题的包袱最终还是落到了真正的专业开发者身上。

「我做的东西最多只能算一个玩具。想要真正构建系统级的工程，还是需要在行业里沉淀过的开发者。」

这句话恰恰点出了当下AI编程的真实边界：它大幅拉低了「从0到1做出个能用的东西」的门槛，让创意得以快速验证；但从「玩具」到「系统级工程」之间，依然横亘着专业经验的鸿沟。

这道鸿沟在很大程度上与当前大语言模型的架构局限直接相关。主流LLM的上下文窗口虽然已扩展至128K乃至200K tokens，但一个中等规模的生产系统代码库往往超过数百万tokens，远超模型一次能「看到」的范围。这意味着AI在处理跨模块的复杂依赖关系时，缺乏人类工程师所具备的「全局视野」，容易给出局部正确但系统性错误的建议。系统级工程需要开发者具备并发安全、内存管理、异常处理、可扩展架构等深层能力——例如，如何设计数据库索引策略以支撑高并发读写、如何处理分布式系统中的网络分区和数据一致性、如何在内存受限的移动端避免因对象引用泄漏导致的OOM（内存溢出）崩溃、如何设计可灰度发布和快速回滚的部署架构。这些问题的答案往往深嵌在具体的业务上下文中，需要工程师在「理解系统全局」的前提下做出有取舍的判断——而这正是当前大语言模型在处理复杂工程问题时最容易产生「幻觉」的地方：它可能给出看似合理但在具体系统约束下根本无法运行的方案，而缺乏经验的开发者往往难以识别这类错误。这些能力是在无数次生产事故和代码审查中沉淀出的工程直觉，目前仍是AI难以完全复现的专业壁垒。

对普通人而言，最好的姿态或许正是这位UP主的态度——大胆去做、享受好玩，同时对复杂工程保持敬畏。

核心要点