小白能不能只靠AI设计一个程序?我用一个鸿蒙应用从0到上架,告诉你真实答案
小白能不能只靠AI设计一个程序?我用一个鸿蒙应用从0到上架,告诉你真实答案
一个真实项目的过程记录。
这两年AI发展得很快,经常能看到一种说法:以后不用学编程了,AI能帮你写代码。甚至有人说,只要你会说话,就能让AI帮你做个App。
做为鸿蒙的小白,我用AI把一个之前做的安卓版六屏计算器迁移到鸿蒙,从开发到提交上架,完整走了一遍。
结果可能会让你意外:结论既不是“能”,也不是“不能”。
我的情况
先说说我的背景,严格来说我也并非“纯小白”。
我计算机专业毕业,但毕业后十几年没做开发。后来因为一些个人原因重新捡起编程,用Python做过数据分析,用AI写过安卓计算器,也开发过一些小工具。算是有基础,但鸿蒙是第一次碰——在鸿蒙面前,我跟小白没什么区别。
刚开始用AI的时候,是DeepSeek横空出世的时候。当时感觉这个东西太神奇了,问它什么它都知道,而且它对于知识的总结和归纳让我很受用。正因为此我才会觉得重新捡起编程不再是一个遥不可及的事情。
当时身边有人说的最多的就是:“AI都能写代码了,你还学它干嘛?这不49年入国军吗?”
项目是什么
项目其实并没有多复杂,当时为了解决我媳妇使用计算器的一个小痛点。用AI协助写了一个能同时显示多行计算结果的安卓计算器(详情见:https://blog.csdn.net/yy4033/article/details/154490264?fromshare=blogdetail&sharetype=blogdetail&sharerId=154490264&sharerefer=PC&sharesource=yy4033&sharefrom=from_link)。
这次是把这个项目迁移到鸿蒙,并走完包括提交上架的全流程。
用了哪些AI工具
前前后后用了三种AI工具。
通用AI用来讨论方案、搭框架、理解概念,但在鸿蒙具体的API上,它给的答案偶尔会不准。
CodeGenie是华为官方的IDE插件,主要是代码补全和生成。写代码的时候,它在旁边帮你补全、生成片段,但在需要定位复杂问题、执行完整修改的时候,能力不太够用。
DevEco Code是后期才换上的。它是一个独立的编程智能体,能帮你定位问题、调取鸿蒙知识库、修改代码。它自带鸿蒙的知识库,给出的方案更精准,修改建议也更贴合鸿蒙的设计思路。
总体感觉,各有其优劣吧,主要还是看个人需求和场景。
项目迁移过程
开始的想法很简单,直接把之前的安卓代码放到项目目录里,让 DevEcoGenie 分析,并根据分析结果,给我出一份重构方案文档。再让它根据文档,重构代码。想法清澈且透漏着不谙世事的呆萌。
不得不说,快且无脑。在这个过程中我甚至把HarmonyOS介绍和ArkTS语法介绍给看了一遍。
然后,噩梦开始了。
调整界面,调整布局,调整样式,调整功能。过程很无助,唯一能做的事就是把运行结果以及我的需求详细描述给他,然后等。结果是,各种问题层出不穷,修好这个,又出那个,修好那个,又出这个。
是工具的问题吗?这个问题作为一个白嫖党不太好意思问。怎么办?只能归因于用工具的人的问题了。
于是我开始看它的方案,问他为什么这样做依据是什么。
过程痛苦且充实,媳妇再也不用担心我写代码的时候无聊看擦边了。
在这个过程中,了解了很多,了解的多了就会发现一些问题。比如:有些问题一行代码就能解决,有些问题是初始路径就没有选对。
下面举一个具体的例子,也是我觉得与ai协作中最能反应出问题的例子。
光标跳到末尾的问题
光标问题是整个项目里卡得最久的,差不多一个多星期。
在处理光标的问题的时候我已经在有意识的问AI:“为什么会这样?”了。
过程很单调:我把光标跳转的现象描述给AI,AI给出修改方案,我照着改,再跑一遍,再把新的现象描述回去。每改一轮,我都会追问一句:“为什么会这样?”AI会解释背后的机制。我不是一下子全搞懂的,是每一次追问之后,拼图就多一点,慢慢地,我开始理解这个问题的全貌。
转折点是一个直觉:“安卓上能做到的事情,鸿蒙不应该这么复杂。”我当时觉得,鸿蒙作为一个成熟平台,应该有一条比我现在正在修修补补的方案更直接的路径。
我当时没有直接问“有没有某个具体的方法”。我的思路是让AI跳出当前框架,先去把关于光标控制的可行方案都列出来——传统方案是什么、官方推荐的方案是什么、有没有其他替代路径。拿到这些方案之后,我再逐一研究,看哪个更适合我的场景。
AI去查了知识库,返回了几个方案。我在研究这些方案的过程中,发现TextInputController.addText()这个方法。我查了文档确认可用,然后按这个方向重构,光标问题就解决了。
回头来看,整个过程其实绕了一个大弯。最直接的方式,本该是知道TextInputController有哪些方法,然后直接选addText。但当时我不知道,甚至不知道有这条路径存在,所以才需要让AI去查方案、列选项。如果我对鸿蒙的知识框架有更系统的理解,光标问题可能根本不会卡一周——可能半天就解决了。
所以那个“先查全、再判断”的做法,本质上是一个“知识不足时的补救步骤”——它能让你往前走,但它消耗的时间远大于有知识储备时直接判断。光标问题的解决过程,就是我知识框架从缺失到补全的过程。
但正是这个过程让我确认了一件事:AI最有效的用法,不是替你做判断,而是帮你补上你不知道自己不知道的那部分信息。补完之后,判断还是自己的事。
核心矛盾:AI不会帮你校准方向
光标问题让我想通了一件事。
AI有一个特性贯穿始终:它会沿着你给定的方向,把这个方向做到极致。但它不会主动问你:“你确定这个方向是对的吗?”
我定了“声明式更新”的方向,AI就一直在帮我优化声明式的方案。我让它加key,它就加key;我让它加setTimeout,它就加setTimeout。它不会说:“我们能不能换个思路?”
但我真正需要的,不是“在当前方向上做得更精细”,而是“换个方向试试”。
这件事,AI不会替我做。AI的匹配机制决定了它是“执行者”,不是“校准者”。它会把你的想法合理化、深化、极端化,但它不会帮你判断你的想法本身对不对。
校准方向——这件事最终还是得自己来。
效率差距
安卓版我用AI做了两天,没卡过。鸿蒙版做了半个月,光标就卡了一周。
同一个项目,换了平台,效率差了一个数量级。原因只有一个:我对安卓的理解比鸿蒙深。AI没有变,变的是我自己对平台的理解程度。
上架怎么样了
已经提交了华为应用市场,走完了第一轮审核。
反馈了三个问题:应用图标不合规、应用描述和平台现有应用相似、底部导航条留空不足。都已修改完,复议已提交,正在等第二轮结果。
回到开头那个问题
回到最初的那个问题:“小白能不能只靠AI做一个项目?”
我的答案是:可以,但有前提。
前提是:你在和AI对话的过程中,一直在追问“为什么”。你在积累知识,积累判断力,然后才能给AI更精准的指令。如果只是“问一句、抄一段”,你得到的是一个“能跑”的东西,但你不理解它。
不理解,下次遇到类似问题,你还是得从头问AI。
所以“小白能不能靠AI做项目”这个问题,真正的答案取决于你愿不愿意在这个过程中去学。愿意学,就能。不愿意学,AI只能帮你做出一个“看起来像”的东西。
附:技术踩坑速查
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 光标跳行 | ForEach的key含动态属性 | key只放id |
| 光标跳末尾 | 声明式更新整体替换字符串 | 改用addText/deleteText |
| 备注弹不出键盘 | focusControl时序问题 | 备注始终可编辑 |
| 签名密码报错 | 不能用明文密码 | DevEco Studio自动加密 |
| 资源名含中文/空格 | 构建失败 | 只用[a-zA-Z0-9_] |
| 截图尺寸不符 | 非9:16比例 | 转换到1080×1920 |
| 底部留空不足 | 未适配安全区域 | 增加底部padding |
更多推荐


所有评论(0)