小白能不能只靠AI设计一个程序？我用一个鸿蒙应用从0到上架，告诉你真实答案

我用一个鸿蒙计算器从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%EF%BC%89%E3%80%82

这次是把这个项目迁移到鸿蒙，并走完包括提交上架的全流程。

用了哪些AI工具

前前后后用了三种AI工具。

通用AI用来讨论方案、搭框架、理解概念，但在鸿蒙具体的API上，它给的答案偶尔会不准。

CodeGenie是华为官方的IDE插件，主要是代码补全和生成。写代码的时候，它在旁边帮你补全、生成片段，但在需要定位复杂问题、执行完整修改的时候，能力不太够用。

DevEco Code是后期才换上的。它是一个独立的编程智能体，能帮你定位问题、调取鸿蒙知识库、修改代码。它自带鸿蒙的知识库，给出的方案更精准，修改建议也更贴合鸿蒙的设计思路。

通用AI帮你理解概念，CodeGenie帮你写代码，DevEco Code帮你定位问题。但没有一个能替你判断方向。

项目迁移过程

开始的想法很简单，直接把之前的安卓代码放到项目目录里，让 DevEcoGenie 分析，并根据分析结果，给我出一份重构方案文档。再让它根据文档，重构代码。想法清澈且透漏着不谙世事的呆萌。

不得不说，快且无脑。在这个过程中我甚至把HarmonyOS介绍和ArkTS语法介绍给看了一遍。

然后，噩梦开始了。

调整界面，调整布局，调整样式，调整功能。过程很无助，唯一能做的事就是把运行结果以及我的需求详细描述给他，然后等。结果是，各种问题层出不穷，修好这个，又出那个，修好那个，又出这个。

是工具的问题吗？这个问题作为一个白嫖党不太好意思问。怎么办？只能归因于用工具的人的问题了。

直到有一天我意识到，等AI修和等别人修没有本质区别——你不知道它修的是什么，修完对不对你也判断不了。

于是我开始看它的方案，问他为什么这样做依据是什么。

过程痛苦且充实，媳妇再也不用担心我写代码的时候无聊看擦边了。

在这个过程中，了解了很多，了解的多了就会发现一些问题。比如：有些问题一行代码就能解决，有些问题是初始路径就没有选对。

下面举一个具体的例子，也是我觉得与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只能帮你做出一个"看起来像"的东西。

所以，不是49年入国军。是学了一种新的打仗方式。

附：技术踩坑速查

问题	原因	解决方案
光标跳行/跳末尾	声明式更新整体替换字符串，触发TextInput重建	改用addText/deleteText命令式API
备注弹不出键盘	focusControl时序问题	备注始终可编辑
签名密码报错	不能用明文密码	DevEco Studio自动加密
资源名含中文/空格	构建失败	只用[a-zA-Z0-9_]
截图尺寸不符	非9:16比例	转换到1080×1920
底部留空不足	未适配安全区域	增加底部padding