多年不写代码的我，决定用 AI 从零做一款鸿蒙应用

摘要：多年不写代码的我，用 AI 从零开发了一款鸿蒙 Markdown 编辑器 MarkPin。本文记录了我的工具链选择（从 DevEco Code 切换到 Claude Code + GLM 5.3）、与 AI 的协作流程、AI 已搞定与翻车的部分，以及三条实战心得——纯 AI 开发鸿蒙目前可行，但前提是把需求掰碎、搭好底层规范，并找到适合自己的工具链组合。

我本科学的是计算机，但毕业之后做了解决方案工程师——聊需求、写方案、做交付，代码基本不碰。完整做一个应用这件事，说实话，已经很多年没干过了。

前阵子我开始用鸿蒙电脑，体验挺新鲜，但有一个很明显的感受：应用还是太少了。很多我想找个顺手工具的时刻，应用市场里翻不到。而这两年，AI 编程又刚好热得发烫——DevEco Code、Claude Code，一个比一个会说"你描述，我来写"。

于是我想：不如自己上手试一次。用 AI，从零做一款鸿蒙应用。不是写教程，是做实验——用一个真实项目验证，"纯 AI 开发"在鸿蒙上到底能走多远。

产品我起了个名字，叫 MarkPin，一个所见即所得的 Markdown 编辑器。为什么是它？我从小就喜欢用 Markdown 记笔记，工作后也一直没断过——做一个自己天天用的东西，需求最真实；而且编辑器功能边界清晰，适合当验证对象。

我的工具链，以及一次关键的切换

一开始用的是 DevEco Code，鸿蒙官方的 AI 编程工具，内置免费的 GLM 5.1 模型。官方工具对鸿蒙工程的支持是原生的：工程初始化、基础代码生成、和 DevEco Studio 的配合都很顺，作为起步的第一选择毫无问题。

但开发往深处走，我慢慢发现它和我的协作方式有些错位：一些复杂的改动意图，反复沟通还是理解不到位。几个回合下来，我尝试了另一种组合——用 Claude Code 自己接入大模型（GLM 5.3）继续。这里要说明白：两种工具各有所长，官方工具胜在鸿蒙集成度和开箱即用，我的切换更多是个人工作流的偏好，不是谁好谁坏的问题。

不过这次切换确实改变了项目的节奏。往下看。

我和 AI 是怎么协作的

很多人想象的 AI 编程是"一句话需求，AI 直接出成品"。我的实际流程朴素得多：

1. 先对齐方案。我把想做的产品、要对标的成熟产品能力讲给它，让它分析、给建议——UI 结构用什么、Markdown 渲染用什么。这一步，AI 是顾问。
2. 再搭骨架。方案定了，让它把整体工程结构搭出来。
3. 然后是漫长的迭代：一点一点改功能、加功能。

真正决定成败的是第三步。骨架谁都能搭，日常的拉锯才是常态——坑也全在这。

目前为止，AI 搞定了什么

写这篇的时候，MarkPin 已经基本完善，只剩边角功能。AI 完成的部分：

• 整体 UI 结构
• 文件树、大纲树
• 基础 Markdown 语法与渲染
• 临时文件沙箱机制

最超预期的一次，是图片插入。

鸿蒙的文件访问机制和 Windows、macOS 完全不同。"粘贴进来的图片怎么进文档"这个问题，我自己一开始也没有成形的答案。我把它丢给 Claude Code（接 GLM 5.3），它给了一套完整方案：临时文件先暂存在应用沙箱，本地文件自动存入专门的图片资产文件夹，命名格式统一。

这个方案和我脑子里的预期基本一致，我自己用起来也觉得顺。那一刻我第一次真切地觉得：这事可能真能成。

翻车现场，也得说说

先交代清楚：下面两个坑，都发生在我项目早期的时候，我当时觉得是工具的锅。但现在回头看，锅不能全甩给工具——模型当时的能力、我的表达方式、任务拆分不到位，都有份。

坑一：一次修改，改崩两处。

有一次我让它修改文件树和大纲的逻辑。改完之后，应用表面看着正常，实际两个致命问题：编辑器没法编辑了，打开本地文件也显示不出内容。一次"小修改"，直接把两个核心功能改崩。

坑二：越改越错的循环。

还是那个阶段，我几次陷入循环：让它修一个问题，带出两个新问题；再修，又多两个。复盘下来，原因有一部分在我——一次喂的内容太多，表达也不够清楚，AI 没法完全理解我的意图。

破局的办法很土，但有效：把问题拆开，一个一个喂。大需求切成小改动，逐个交付、逐个验证，成功率肉眼可见地回来了。

目前还有一个没解决的硬骨头：复制粘贴的格式问题——部分内容粘贴进来，原来的格式效果丢了。这个问题我打算接下来死磕，解决了单独写一篇。

阶段结论：我的 AI 能力边界表

事项	AI 表现	我的结论
工程搭建 / 页面框架	稳定	具体样式还得优化，最好先有 UI 原型图
常规 UI 与布局	基本稳定	不能凭空一句话要样式，得给出具体方向
编辑器核心逻辑	稳定	目前没什么问题
报错排查	稳定	基本可靠，但依赖底层模型能力和工具能力
鸿蒙特有 API / 能力	稳定	能按需求分析，方案符合鸿蒙场景

注意：这张表是我当前工具链组合下的状态。早期用另一套组合时，体验要打个折扣——同一个项目、不同的工具链和模型搭配，顺畅度差异很明显。所以"纯 AI 开发可行"这个结论有个前提：找到适合自己场景的工具链组合，本身就是开发工作的一部分。

三条心得，收尾

1. 纯 AI 开发鸿蒙，目前可行——但前提是把自己的想法掰碎了、一步一步喂给 AI，只丢一个概念是不行的。
2. 先把底层 CLI 和 SKILL 搭好：项目规范、规则文件这些"地基"配置好，AI 有上下文，输出质量是另一个档次。
3. 工具链和模型没有绝对的好坏，只有合不合适。官方工具有集成度的优势，第三方组合有灵活的空间——多试、找到自己的节奏，这个选择本身就是生产力的一部分。

这是第一篇，MarkPin 还在开发中，这个系列会跟到它上架为止——如果中途做不下去了，我也会写最后一篇告诉你为什么。

如果你也在试 AI 开发鸿蒙，或者想看后续，关注专栏，所有踩坑都会持续更新。