一键开通华为云码道 CodeArts 代码智能体https://developer.huaweicloud.com/codeartsco.html?sourcedmzntgwatomgit1sourceaddmzntgwatomgithd摘要我们最初的需求很小做一个能跑起来的轻量游戏功能。但能跑起来这四个字放在鸿蒙工程里一点都不轻——Stage 模型、module.json5的资源引用、hvigor 构建脚本、oh-package 依赖清单、ArkTS 声明式 UI缺一个环节工程就打不开。为了看清楚 AI 编程智能体到底做了哪些事我把一次完整的鸿蒙应用生成过程全部截图留档从需求澄清、环境自检、子代理调度到 43 个文件、2481 行 ArkTS 的工程落地再到 git 初始化与远程仓库推送。本文按时间顺序还原这条链路并与新手从零手写的做法逐项对比文中附环境检测结果表、交付物统计表、操作链路流程图和九项能力对照表。一、先说说这次要做的小东西关键词HarmonyOS · ArkTS · ArkUI Stage 模型 · AtomGit · 华为云码道 · AI 编程智能体 · 需求澄清 · 子代理调度背景很朴素我们需要一个能跑起来的简单游戏功能。截图左侧的会话列表里就躺着那句原始需求——“帮我开发一个坦克大战的游戏”。这类需求的典型特征是功能边界清楚、体量不大、但要真正跑起来得有一套完整的工程外壳撑着。写游戏和写商城在鸿蒙这套体系里遇到的拦路虎是同一批。ArkTS 的页面得挂在pages清单里应用图标得能从$media:icon解析到实体文件模块的module.json5得声明清楚 ability 和入口构建脚本hvigorfile.ts与oh-package.json5一个都不能少。新手在这里摔的跟头基本都不是算法问题而是配置没对齐、资源找不到、依赖没同步这类工程性问题。所以我做了一个更划算的选择把同一套操作链路放在一个界面元素更丰富的样本上完整跑一遍并把每一步都截图留存。这个样本就是图片里那个仿京东商城的鸿蒙应用。下面所有分析都来自这批截图没有补拍也没有事后美化——包括中途那次模型配额不足的报错。二、它没有先写代码而是先开了一场三轮需求会我在 AtomGit 网页端的 Agent 对话里选了华为云码道然后输入了一句话帮我开发一个鸿蒙app商城的页面可以仿一下京东APP图 1AtomGit 网页端 Agent 对话界面左侧会话列表里还留着那句帮我开发一个坦克大战的游戏。本轮需求只有一行字。按新手的惯性接下来应该是新建工程 → 拖组件 → 报错再说。但这次发生的事把这个顺序反过来演了一遍它一个字都没急着写先连着问了我三个问题。三张截图的选项是逐轮递进的只有答完上一轮下一轮才会出现。轮次它问的问题给出的选项我的选择它真正想确定的事1/3你希望这次交付的商城页面范围是完整 4 个 Tab 页面推荐只做首页首页详情页完整 4 个 Tab工作量边界是一个页面还是一个应用2/3数据来源如何处理本地模拟数据推荐预留接口对接本地 Mock 数据能不能开箱即用是否需要后端与网络3/3工程交付形式完整 HarmonyOS 工程推荐仅 Page 代码完整工程交付物是否可编译拷贝即用地直接运行图 2第一轮提问页面范围选项里完整 4 个 Tab 页面被标注为推荐。图 3第二轮提问数据来源它明确写出因为没有后端所以推荐本地 Mock 数据。图 4第三轮提问工程交付形式完整 HarmonyOS 工程对应的是标准 DevEco Studio 工程结构与 entry 模块。有意思的是它自己的思考过程。截图里它写得很直白仿京东商城通常至少应包含首页、分类、购物车、我的四个 Tab页面后面可以使用本地模拟数据因为没有后端接着又说考虑到整个任务比较大我先问用户几个关键问题然后再调用子代理。也就是说这三次提问不是走流程而是它先把任务在心里估了一遍工作量判断出这是一项鸿蒙应用开发任务才决定停下来对齐需求。这四个技术判断值得单独拎出来看页面范围决定的是工程骨架而不是页面数量。选完整 4 个 Tab意味着要建底部导航容器、要做页面路由、要让四个页面共享一份状态选只做首页则只需要一个Index.ets。这个选择直接决定了后面是生成 8 个文件还是 43 个文件。数据来源决定的是能不能立刻验证。本地 Mock 数据的好处是零外部依赖——不用后端、不用配域名、不用声明网络权限就能跑出效果而预留接口对接虽然更接近生产形态却会把一次验收拆成前端调通和后端联调两段。工程形式决定的是交付物形态。这一条最容易被新手忽略。仅 Page 代码听起来轻但拿回本地后还得自己补到现有工程里资源、路由、模块声明全要手工对齐完整工程重但它保证了Open 目录 → 等 ohpm 同步 → Run这条路径是通的。把澄清放在写码之前省的是返工的钱。三个问题问完不到一分钟但换来的是一条不会再改的技术路线。反过来说新手常见的写完首页才发现用户要的是完整应用损失的时间远不止一分钟。三、开工前先做环境自检一个连 hvigor 都没有的沙箱问答结束它做的第一件事不是写代码而是查环境。截图里三条命令依次是看工作目录、探 Node.js、找鸿蒙工具链。第一条ls -la /workspace输出只有一行drwxr-xr-x .codeartsdoer——空目录确认要从零开始搭。图 5需求对齐之后并没有立刻写码它先用 Read 看目录、用 Bash 列目录两条命令的原始输出都留在对话里。第二条探到的是 Node.jsnode v22.11.0路径在/opt/cloud-devTools/nodejs/v22/bin/node。这条结果说明运行时是齐的。第三条是全链路搜索它把hvigor、ohpm一次性都找了whichhvigor hvigor ohpmnodenpm2/dev/null;echo---;node--version2/dev/nullls/opt/cloud-devTools/2/dev/nullfind/-maxdepth6-typed-name*hvigor*2/dev/null|head-20结果是java / maven / nodejs / python四个目录没有鸿蒙 SDK没有 hvigor也没有 ohpm。它据此得出的结论写得很克制环境中没有 Node.js也没有安装 hvigor 或 ohpm这时候可能无法完整编译鸿蒙OS 工程但紧接着补了一句关键判断——可以生成完整可用的 HarmonyOS 工程代码ArkTS ArkUI用户可以在自己的 DevEco Studio 中打开编译运行。图 6环境探测的输出node v22.11.0可用但 hvigor 与 ohpm 全线缺失。图 7find / -maxdepth 6 -type d -name *hvigor*全盘搜索只翻出 java、maven、nodejs、python 四个目录鸿蒙工具链确实不存在。检测项探测命令实际结果对交付的影响工作目录ls -la /workspace仅.codeartsdoer/一个目录空沙箱工程需从零搭建Node.jsnode --versionv22.11.0可用能跑辅助脚本hvigor 构建器which hvigor未找到沙箱内无法执行构建ohpm 依赖管理which ohpm未找到无法同步三方依赖鸿蒙 SDKls /opt/cloud-devTools/仅 javamavennodejspython无 DevEco 工具链无法本地编译这张表是整篇文章里我最想推荐给新手的部分。它的价值不在于AI 会检测环境而在于它把做不到的事提前说了出来。新手在同样的沙箱里通常要写完几十个文件、执行一次构建、看到一屏看不懂的报错才能意识到这里根本编不了。而这里是在动手之前就给出了结论并且把失败模式转换成了另一个可交付的方案生成完整工程 交给用户在本地 DevEco 里跑。顺带一提这一步也解释了后面为什么它没有伪造编译通过的结论。截图里的交付总结写的是运行方式而不是构建结果这是诚实的。四、把大任务交给子代理从 Task 调度到工程树落地需求对齐了、环境探明了它才开始真正动工而且是分两步走的。图 8三轮问答结束后工具返回User has answered your questions三条约束被逐字记录下来随后才进入子代理调用。第一步是加载对应的专家能力。截图里的原话是这是鸿蒙开发任务应该使用 harmonyos-plugin鸿蒙全生命周期开发助手或者 harmony-developer鸿蒙开发专家支持写码编译测试修复。它还提到会先尝试搜索hmos-atomic-dev相关的 skill 与子代理。第二步是用 Task 工具下发完整任务。截图里的调用参数很具体把/workspace/JDShop作为工程根目录把完整 4 Tab Mock 数据 标准 Stage 工程这几个约束一次性交代清楚。它自己的规划是六步确认目录 → 创建结构 → 写配置文件 → 写 ArkTS 代码 → 请检查 → 汇总。关于工程结构它给出的目标树是标准的 Stage 模型布局。这套结构值得抄下来因为它就是 DevEco Studio 新建工程的默认骨架图 9Task 下发前的思考工程树先以文本形式列了一遍AppScope、entry、resources三层关系一目了然。图 10正式调用 Task 工具参数里写明了目标目录/workspace/JDShop与完整 4 Tab Mock 数据的约束。JDShop/ ├── AppScope/ │ ├── app.json5 # 应用级配置包名、版本、图标 │ └── resources/base/ │ ├── element/string.json # 应用名称等字符串资源 │ └── media/ # 应用级图标 ├── entry/ # 主 HAP 模块 │ ├── build-profile.json5 │ ├── oh-package.json5 # 模块依赖清单 │ ├── hvigorfile.ts # 模块构建脚本 │ └── src/main/ │ ├── module.json5 # 模块声明ability、入口页、权限 │ ├── ets/ │ │ ├── entryability/EntryAbility.ets │ │ ├── pages/Index.ets # 唯一入口页 底部 Tab 容器 │ │ ├── model/ # Goods / Category / CartItem / Type │ │ ├── mockdata/MockData.ets # 本地模拟数据 │ │ ├── store/AppState.ets # 跨页面状态 │ │ ├── components/ # GoodsCard、SearchBar、FontView │ │ └── view/ # BannerSwiper、RecommentMaterial、SeckillSection │ └── resources/base/ │ ├── element/ # color / string / float │ ├── media/ # 图标与占位图 │ └── profile/main_pages.json # 页面清单 ├── hvigor/hvigor-config.json5 ├── build-profile.json5 ├── oh-package.json5 └── .gitignore这套目录一铺开model放数据模型、mockdata放模拟数据、store放状态、components放可复用组件、view放页面级区块——职责是分开的。这一点跟新手常见的做法差别很大新手往往把所有东西塞进Index.ets做到第三个页面才发现文件 800 行、改一处崩两处。图 11结构树的展开细节components/GoodsCard.ets、view目录下的各个板块、resources/base/element与profile/main_pages.json都在规划之内。五、真正的功夫在细节图标、占位图和 Provider文章写到这里前四节都还比较顺但截图中有一段思考过程我认为最有含金量它讨论的是一个特别不起眼的东西——图标文件。它的推理链条是module.json5会引用$media:icon如果media目录下没有实体文件编译就会报资源缺失所以在生成工程之前必须先把这个文件造出来。接着它比较了几种做法用bash生成纯色 PNG、用python的 PIL 库生成、或者直接写一个 base64 的最小 PNG。最后它选定了最小可行方案——写一个 1×1 的纯色 PNG# 一个 1x1 红色 PNG 的 base64直接解码落盘即可iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8z8BQDwAEhQGAhKmMIQAAAABJRU5ErkJggg图 12关于图标与占位图的完整推演过程从$media:icon的引用关系到用 python 还是 base64的方案取舍再到ohos.permission.INTERNET权限的提醒。同一段思考里它还处理了另外两个坑。一个是网络图片ArkUI 的Image组件虽然支持 URL但加载网络图需要ohos.permission.INTERNET权限且沙箱里不一定连得通所以商品图改用占位图服务或者本地图标兜底。另一个是启动页图标startWindowIcon同样需要media资源一并补上。这几处细节恰好是新手最容易翻车的地方。新手的排查路径通常是构建报错 → 搜报错关键字 → 找半天 → 才反应过来是图片没放而这里的顺序是预判引用 → 提前造资源 → 规避报错。六、Git 与远程仓库从 init 到 push 的完整链路工程写完后我补了一句指令“帮我初始化到仓库中并且写好readme文件”。图 13git init之后的一连串默认分支提示以及页面上方那条[错误: 当前模型配额不足 [APIError]]——这条报错就夹在两次初始化到仓库的指令之间。随后是标准的 Git 链路但每一步的细节都留了痕cd/workspace/JDShopgitinitgitstatuscd/workspace/JDShopgitadd-Agitstatuscd/workspace/JDShopgitcommit-mfeat: 仿京东商城鸿蒙应用 JDShop完整4 Tab Mock数据git status的暂存列表在截图里是清清楚楚的mockdata/MockData.ets、model/CartItem.ets、view/RecommendMaterial.ets、components/SearchBar.ets、pages/Index.ets……最后一行总结是42 files are staged紧接着提交输出是43 files changed, 2481 insertions()。43 与 42 的差值是多出来的那一份README.md——它是在git add之后、commit之前写进去的。这种先暂存再补文件的操作能一次提交成功靠的是git add -A的二次执行而不是运气。图 14git add -A之后的暂存清单mockdata、model、view、components各个目录逐条列出末尾统计是 42 个文件。图 15提交输出43 files changed, 2481 insertions()紧跟着是交付总结——工程位置、分支、提交号、README 的六项内容与运行方式。提交完成后是远程仓库。这一段的截图信息量最大环节执行内容结果本地初始化git init git statusmaster 分支初始提交4b39864暂存与提交git add -A→git commit -m feat: ...43 个文件、2481 行新增工具链检查which ag/ag --version存在 AtomGit CLI认证状态检查ag auth status未登录主动停下来问我要 Token 还是浏览器授权添加远程git remote add origin https://atomgit.com/...origin 指向 AtomGit 仓库凭据检查git config --global credential.helper确认凭据助手已配置避免推送时卡住推送git push -u origin master成功仓库公开可见结果验证ag repo view guowei88/JDShop仓库已创建分支 master提交4b39864图 16ag auth status返回未登录后它没有反复重试而是弹出一个选择框把提供 Token和本地浏览器授权两条路摆出来让我选。图 17添加远程地址、检查credential.helper、执行git push -u origin master最后用ag repo view反向验证仓库确实存在。这里面有两个动作特别值得学。第一它先查了登录状态。发现ag auth status未登录后它没有硬着头皮重试而是弹出一个选择框给我 Token或者我去本地终端跑一次浏览器授权。第二它在推送前查了凭据助手。git push走 HTTPS 时会读credential.helper这个配置没做好推送就会卡在密码交互上——提前检查一次比推失败再排查便宜得多。整条链路里还有一次中断值得一提截图里出现过一条[错误: 当前模型配额不足 [APIError]]。这个报错之后我换了个模型继续帮我初始化到仓库中并且写好readme文件这句话照常被执行完了。也就是说这一环失败并没有导致前面的工程成果作废——因为工程文件已经落盘在 Git 工作区里模型只是执行者不是仓库的所有者。这一点恰恰是把工作成果沉淀在文件系统而不是对话上下文里的价值。七、交付结果长什么样最终仓库返回的总结是这样几行位置/workspace/JDShop分支master初始提交4b3986443 个文件、2481 行代码耗时 1 分 11 秒首次生成缓存命中 100%。交付指标数值工程路径/workspace/JDShop文件总数43代码行数2481默认分支master初始提交4b39864语言占比ArkTS 99.65% TypeScript 0.35%运行要求DevEco Studio 5.0API 12无需签名、无需后端、无需联网远端地址https://atomgit.com/guowei88/JDShop仓库首页的 README 也不是一句占位说明而是按功能特性、工程结构树、设计规范京东红#E9383D、运行环境与运行方式、技术要点ArkTS V2 响应式架构、购物车跨页面联动、图片失败回退、MIT License 分了六块。首页、分类、购物车、我的四个 Tab 的功能点都有对应描述。图 18AtomGit 仓库首页master 分支、43 个文件全部就位语言占比 ArkTS 99.65%README 的预览一节甚至用表格列出了四个 Tab 各自负责什么。八、操作链路全景一张图看清它做了什么把前面六节串起来这条链路的形状是清楚的——先对齐、再探路、后施工最后交付并验证。无 SDK 无 hvigor可用用户一句话需求帮我开发一个鸿蒙app商城的页面深度思考判定为鸿蒙开发任务三轮需求澄清页面范围 / 数据来源 / 工程形式环境自检ls 工作目录 → node → hvigor/ohpm工具链是否可用调整交付策略生成完整工程交本地 DevEco 编译本地构建验证加载专家能力harmonyos-plugin / harmony-developerTask 下发子代理目标目录 4Tab Mock Stage 工程创建标准工程树AppScope / entry / hvigor / resources资源兜底1x1 PNG 图标、占位图、INTERNET 权限git init → add -A → commit43 文件 2481 行ag auth status未登录 → 询问认证方式git remote add → push仓库创建成功README 六段式功能/结构/规范/运行/技术要点/License九、新手手写 vs AI 生成把同一条链路拆成两列接下来是本文的核心对比。我不打算讲AI 更快这种没有信息量的话而是按具体环节逐项对照。环节新手手写AI 智能体生成差距的本质需求澄清需求散在脑子里边写边改三轮 question锁定范围数据形态返工成本是否被前置技术选型容易卡在版本与配置组合上直接落到 ArkTS ArkUI Stage 模型 API 12经验密度工程骨架目录随手建做到第三页才重构一次性铺出标准 Stage 工程树有没有先定结构的意识环境问题遇到编译报错再回头查动手前先探 hvigorohpmSDK并如实说明局限失败模式是否被提前规避资源缺失图标缺失导致编译失败反复试预判$media:icon与startWindowIcon生成占位 PNG对隐式引用的掌握程度编码产出四个 Tab 通常要跨天完成43 个文件 / 2481 行单次会话产出产量不是一个量级版本管理手动 initaddcommit容易漏.gitignore全流程自动执行并在推送前检查凭据流程规范度文档常被省略或只写一句启动方式自动产出六段式 README含契约与边界交付完整性异常中断报错即卡住进度停摆遇到配额错误、未登录仍能换方案续做恢复能力最终验收靠肉眼点一遍同样需要人工打开页面核对这一段谁都不省这张表里有两列我想单独说明。第一列是环境问题和资源缺失。这两项是新手和 AI 差距最大的地方但差距不在AI 懂得多而在于它把排查从事后救火改成了事前设防。新手是在构建失败之后才认识 hvigor 的而它是在动手之前就确认了 hvigor 不存在并且据此改了交付策略。这个习惯是可以学的动工前花三十秒把工具链和隐式资源依赖过一徧。第二列是最后一项最终验收。上一节开头那份 README 写得再全也挡不住页面在真机上跑起来是歪的。43 个文件和 2481 行代码是产出量不是可用度。沙箱里既没有 hvigor 也没有设备图片失败回退、购物车跨页联动、四个 Tab 的滚动惯性这些事只有把工程拉到 DevEco Studio 里打开、运行才知道成不成。这一点上AI 没有任何优势它只是把该你验的部分给你留得更清楚了。十、写在最后如果把我这次记录压缩成三句话大概是这样的。第一AI 生成的起点不是代码是问题。三张截图里的三轮提问看起来只是几句选择实际上决定了后面生成 43 个文件还是 8 个文件。对新手来说最该先学的不是写 ArkTS而是动手前把范围问清楚。第二它最可靠的能力是把工程骨架和配置引用一次对齐。从 Stage 模型目录到$media:icon的占位处理这些是纯经验活新手要摔几次才能记住而它一次就能做对。这部分的收益是实打实的。第三它替代不了你打开页面那一眼。沙箱没有工具链、没有设备编译不了也跑不起来。真正决定这个应用能不能用的还是把工程拷到本地 DevEco 里运行的那一刻。回到最初那个简单的游戏功能需求上。如果现在让我重做一次我会把这套流程照搬一遍先用三轮问题把范围、数据、交付形态钉死让它铺出标准工程骨架和占位资源拿到一套能编译的起点然后自己接管核心玩法逻辑——因为游戏的手感、节奏、反馈这些东西从来不是配置问题也不是脚手架能替你决定的。
一键开通华为云码道 CodeArts 代码智能体https://developer.huaweicloud.com/codeartsco.html?sourcedmzntgwatomgit1sourceaddmzntgwatomgithd摘要我们最初的需求很小做一个能跑起来的轻量游戏功能。但能跑起来这四个字放在鸿蒙工程里一点都不轻——Stage 模型、module.json5的资源引用、hvigor 构建脚本、oh-package 依赖清单、ArkTS 声明式 UI缺一个环节工程就打不开。为了看清楚 AI 编程智能体到底做了哪些事我把一次完整的鸿蒙应用生成过程全部截图留档从需求澄清、环境自检、子代理调度到 43 个文件、2481 行 ArkTS 的工程落地再到 git 初始化与远程仓库推送。本文按时间顺序还原这条链路并与新手从零手写的做法逐项对比文中附环境检测结果表、交付物统计表、操作链路流程图和九项能力对照表。一、先说说这次要做的小东西关键词HarmonyOS · ArkTS · ArkUI Stage 模型 · AtomGit · 华为云码道 · AI 编程智能体 · 需求澄清 · 子代理调度背景很朴素我们需要一个能跑起来的简单游戏功能。截图左侧的会话列表里就躺着那句原始需求——“帮我开发一个坦克大战的游戏”。这类需求的典型特征是功能边界清楚、体量不大、但要真正跑起来得有一套完整的工程外壳撑着。写游戏和写商城在鸿蒙这套体系里遇到的拦路虎是同一批。ArkTS 的页面得挂在pages清单里应用图标得能从$media:icon解析到实体文件模块的module.json5得声明清楚 ability 和入口构建脚本hvigorfile.ts与oh-package.json5一个都不能少。新手在这里摔的跟头基本都不是算法问题而是配置没对齐、资源找不到、依赖没同步这类工程性问题。所以我做了一个更划算的选择把同一套操作链路放在一个界面元素更丰富的样本上完整跑一遍并把每一步都截图留存。这个样本就是图片里那个仿京东商城的鸿蒙应用。下面所有分析都来自这批截图没有补拍也没有事后美化——包括中途那次模型配额不足的报错。二、它没有先写代码而是先开了一场三轮需求会我在 AtomGit 网页端的 Agent 对话里选了华为云码道然后输入了一句话帮我开发一个鸿蒙app商城的页面可以仿一下京东APP图 1AtomGit 网页端 Agent 对话界面左侧会话列表里还留着那句帮我开发一个坦克大战的游戏。本轮需求只有一行字。按新手的惯性接下来应该是新建工程 → 拖组件 → 报错再说。但这次发生的事把这个顺序反过来演了一遍它一个字都没急着写先连着问了我三个问题。三张截图的选项是逐轮递进的只有答完上一轮下一轮才会出现。轮次它问的问题给出的选项我的选择它真正想确定的事1/3你希望这次交付的商城页面范围是完整 4 个 Tab 页面推荐只做首页首页详情页完整 4 个 Tab工作量边界是一个页面还是一个应用2/3数据来源如何处理本地模拟数据推荐预留接口对接本地 Mock 数据能不能开箱即用是否需要后端与网络3/3工程交付形式完整 HarmonyOS 工程推荐仅 Page 代码完整工程交付物是否可编译拷贝即用地直接运行图 2第一轮提问页面范围选项里完整 4 个 Tab 页面被标注为推荐。图 3第二轮提问数据来源它明确写出因为没有后端所以推荐本地 Mock 数据。图 4第三轮提问工程交付形式完整 HarmonyOS 工程对应的是标准 DevEco Studio 工程结构与 entry 模块。有意思的是它自己的思考过程。截图里它写得很直白仿京东商城通常至少应包含首页、分类、购物车、我的四个 Tab页面后面可以使用本地模拟数据因为没有后端接着又说考虑到整个任务比较大我先问用户几个关键问题然后再调用子代理。也就是说这三次提问不是走流程而是它先把任务在心里估了一遍工作量判断出这是一项鸿蒙应用开发任务才决定停下来对齐需求。这四个技术判断值得单独拎出来看页面范围决定的是工程骨架而不是页面数量。选完整 4 个 Tab意味着要建底部导航容器、要做页面路由、要让四个页面共享一份状态选只做首页则只需要一个Index.ets。这个选择直接决定了后面是生成 8 个文件还是 43 个文件。数据来源决定的是能不能立刻验证。本地 Mock 数据的好处是零外部依赖——不用后端、不用配域名、不用声明网络权限就能跑出效果而预留接口对接虽然更接近生产形态却会把一次验收拆成前端调通和后端联调两段。工程形式决定的是交付物形态。这一条最容易被新手忽略。仅 Page 代码听起来轻但拿回本地后还得自己补到现有工程里资源、路由、模块声明全要手工对齐完整工程重但它保证了Open 目录 → 等 ohpm 同步 → Run这条路径是通的。把澄清放在写码之前省的是返工的钱。三个问题问完不到一分钟但换来的是一条不会再改的技术路线。反过来说新手常见的写完首页才发现用户要的是完整应用损失的时间远不止一分钟。三、开工前先做环境自检一个连 hvigor 都没有的沙箱问答结束它做的第一件事不是写代码而是查环境。截图里三条命令依次是看工作目录、探 Node.js、找鸿蒙工具链。第一条ls -la /workspace输出只有一行drwxr-xr-x .codeartsdoer——空目录确认要从零开始搭。图 5需求对齐之后并没有立刻写码它先用 Read 看目录、用 Bash 列目录两条命令的原始输出都留在对话里。第二条探到的是 Node.jsnode v22.11.0路径在/opt/cloud-devTools/nodejs/v22/bin/node。这条结果说明运行时是齐的。第三条是全链路搜索它把hvigor、ohpm一次性都找了whichhvigor hvigor ohpmnodenpm2/dev/null;echo---;node--version2/dev/nullls/opt/cloud-devTools/2/dev/nullfind/-maxdepth6-typed-name*hvigor*2/dev/null|head-20结果是java / maven / nodejs / python四个目录没有鸿蒙 SDK没有 hvigor也没有 ohpm。它据此得出的结论写得很克制环境中没有 Node.js也没有安装 hvigor 或 ohpm这时候可能无法完整编译鸿蒙OS 工程但紧接着补了一句关键判断——可以生成完整可用的 HarmonyOS 工程代码ArkTS ArkUI用户可以在自己的 DevEco Studio 中打开编译运行。图 6环境探测的输出node v22.11.0可用但 hvigor 与 ohpm 全线缺失。图 7find / -maxdepth 6 -type d -name *hvigor*全盘搜索只翻出 java、maven、nodejs、python 四个目录鸿蒙工具链确实不存在。检测项探测命令实际结果对交付的影响工作目录ls -la /workspace仅.codeartsdoer/一个目录空沙箱工程需从零搭建Node.jsnode --versionv22.11.0可用能跑辅助脚本hvigor 构建器which hvigor未找到沙箱内无法执行构建ohpm 依赖管理which ohpm未找到无法同步三方依赖鸿蒙 SDKls /opt/cloud-devTools/仅 javamavennodejspython无 DevEco 工具链无法本地编译这张表是整篇文章里我最想推荐给新手的部分。它的价值不在于AI 会检测环境而在于它把做不到的事提前说了出来。新手在同样的沙箱里通常要写完几十个文件、执行一次构建、看到一屏看不懂的报错才能意识到这里根本编不了。而这里是在动手之前就给出了结论并且把失败模式转换成了另一个可交付的方案生成完整工程 交给用户在本地 DevEco 里跑。顺带一提这一步也解释了后面为什么它没有伪造编译通过的结论。截图里的交付总结写的是运行方式而不是构建结果这是诚实的。四、把大任务交给子代理从 Task 调度到工程树落地需求对齐了、环境探明了它才开始真正动工而且是分两步走的。图 8三轮问答结束后工具返回User has answered your questions三条约束被逐字记录下来随后才进入子代理调用。第一步是加载对应的专家能力。截图里的原话是这是鸿蒙开发任务应该使用 harmonyos-plugin鸿蒙全生命周期开发助手或者 harmony-developer鸿蒙开发专家支持写码编译测试修复。它还提到会先尝试搜索hmos-atomic-dev相关的 skill 与子代理。第二步是用 Task 工具下发完整任务。截图里的调用参数很具体把/workspace/JDShop作为工程根目录把完整 4 Tab Mock 数据 标准 Stage 工程这几个约束一次性交代清楚。它自己的规划是六步确认目录 → 创建结构 → 写配置文件 → 写 ArkTS 代码 → 请检查 → 汇总。关于工程结构它给出的目标树是标准的 Stage 模型布局。这套结构值得抄下来因为它就是 DevEco Studio 新建工程的默认骨架图 9Task 下发前的思考工程树先以文本形式列了一遍AppScope、entry、resources三层关系一目了然。图 10正式调用 Task 工具参数里写明了目标目录/workspace/JDShop与完整 4 Tab Mock 数据的约束。JDShop/ ├── AppScope/ │ ├── app.json5 # 应用级配置包名、版本、图标 │ └── resources/base/ │ ├── element/string.json # 应用名称等字符串资源 │ └── media/ # 应用级图标 ├── entry/ # 主 HAP 模块 │ ├── build-profile.json5 │ ├── oh-package.json5 # 模块依赖清单 │ ├── hvigorfile.ts # 模块构建脚本 │ └── src/main/ │ ├── module.json5 # 模块声明ability、入口页、权限 │ ├── ets/ │ │ ├── entryability/EntryAbility.ets │ │ ├── pages/Index.ets # 唯一入口页 底部 Tab 容器 │ │ ├── model/ # Goods / Category / CartItem / Type │ │ ├── mockdata/MockData.ets # 本地模拟数据 │ │ ├── store/AppState.ets # 跨页面状态 │ │ ├── components/ # GoodsCard、SearchBar、FontView │ │ └── view/ # BannerSwiper、RecommentMaterial、SeckillSection │ └── resources/base/ │ ├── element/ # color / string / float │ ├── media/ # 图标与占位图 │ └── profile/main_pages.json # 页面清单 ├── hvigor/hvigor-config.json5 ├── build-profile.json5 ├── oh-package.json5 └── .gitignore这套目录一铺开model放数据模型、mockdata放模拟数据、store放状态、components放可复用组件、view放页面级区块——职责是分开的。这一点跟新手常见的做法差别很大新手往往把所有东西塞进Index.ets做到第三个页面才发现文件 800 行、改一处崩两处。图 11结构树的展开细节components/GoodsCard.ets、view目录下的各个板块、resources/base/element与profile/main_pages.json都在规划之内。五、真正的功夫在细节图标、占位图和 Provider文章写到这里前四节都还比较顺但截图中有一段思考过程我认为最有含金量它讨论的是一个特别不起眼的东西——图标文件。它的推理链条是module.json5会引用$media:icon如果media目录下没有实体文件编译就会报资源缺失所以在生成工程之前必须先把这个文件造出来。接着它比较了几种做法用bash生成纯色 PNG、用python的 PIL 库生成、或者直接写一个 base64 的最小 PNG。最后它选定了最小可行方案——写一个 1×1 的纯色 PNG# 一个 1x1 红色 PNG 的 base64直接解码落盘即可iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8z8BQDwAEhQGAhKmMIQAAAABJRU5ErkJggg图 12关于图标与占位图的完整推演过程从$media:icon的引用关系到用 python 还是 base64的方案取舍再到ohos.permission.INTERNET权限的提醒。同一段思考里它还处理了另外两个坑。一个是网络图片ArkUI 的Image组件虽然支持 URL但加载网络图需要ohos.permission.INTERNET权限且沙箱里不一定连得通所以商品图改用占位图服务或者本地图标兜底。另一个是启动页图标startWindowIcon同样需要media资源一并补上。这几处细节恰好是新手最容易翻车的地方。新手的排查路径通常是构建报错 → 搜报错关键字 → 找半天 → 才反应过来是图片没放而这里的顺序是预判引用 → 提前造资源 → 规避报错。六、Git 与远程仓库从 init 到 push 的完整链路工程写完后我补了一句指令“帮我初始化到仓库中并且写好readme文件”。图 13git init之后的一连串默认分支提示以及页面上方那条[错误: 当前模型配额不足 [APIError]]——这条报错就夹在两次初始化到仓库的指令之间。随后是标准的 Git 链路但每一步的细节都留了痕cd/workspace/JDShopgitinitgitstatuscd/workspace/JDShopgitadd-Agitstatuscd/workspace/JDShopgitcommit-mfeat: 仿京东商城鸿蒙应用 JDShop完整4 Tab Mock数据git status的暂存列表在截图里是清清楚楚的mockdata/MockData.ets、model/CartItem.ets、view/RecommendMaterial.ets、components/SearchBar.ets、pages/Index.ets……最后一行总结是42 files are staged紧接着提交输出是43 files changed, 2481 insertions()。43 与 42 的差值是多出来的那一份README.md——它是在git add之后、commit之前写进去的。这种先暂存再补文件的操作能一次提交成功靠的是git add -A的二次执行而不是运气。图 14git add -A之后的暂存清单mockdata、model、view、components各个目录逐条列出末尾统计是 42 个文件。图 15提交输出43 files changed, 2481 insertions()紧跟着是交付总结——工程位置、分支、提交号、README 的六项内容与运行方式。提交完成后是远程仓库。这一段的截图信息量最大环节执行内容结果本地初始化git init git statusmaster 分支初始提交4b39864暂存与提交git add -A→git commit -m feat: ...43 个文件、2481 行新增工具链检查which ag/ag --version存在 AtomGit CLI认证状态检查ag auth status未登录主动停下来问我要 Token 还是浏览器授权添加远程git remote add origin https://atomgit.com/...origin 指向 AtomGit 仓库凭据检查git config --global credential.helper确认凭据助手已配置避免推送时卡住推送git push -u origin master成功仓库公开可见结果验证ag repo view guowei88/JDShop仓库已创建分支 master提交4b39864图 16ag auth status返回未登录后它没有反复重试而是弹出一个选择框把提供 Token和本地浏览器授权两条路摆出来让我选。图 17添加远程地址、检查credential.helper、执行git push -u origin master最后用ag repo view反向验证仓库确实存在。这里面有两个动作特别值得学。第一它先查了登录状态。发现ag auth status未登录后它没有硬着头皮重试而是弹出一个选择框给我 Token或者我去本地终端跑一次浏览器授权。第二它在推送前查了凭据助手。git push走 HTTPS 时会读credential.helper这个配置没做好推送就会卡在密码交互上——提前检查一次比推失败再排查便宜得多。整条链路里还有一次中断值得一提截图里出现过一条[错误: 当前模型配额不足 [APIError]]。这个报错之后我换了个模型继续帮我初始化到仓库中并且写好readme文件这句话照常被执行完了。也就是说这一环失败并没有导致前面的工程成果作废——因为工程文件已经落盘在 Git 工作区里模型只是执行者不是仓库的所有者。这一点恰恰是把工作成果沉淀在文件系统而不是对话上下文里的价值。七、交付结果长什么样最终仓库返回的总结是这样几行位置/workspace/JDShop分支master初始提交4b3986443 个文件、2481 行代码耗时 1 分 11 秒首次生成缓存命中 100%。交付指标数值工程路径/workspace/JDShop文件总数43代码行数2481默认分支master初始提交4b39864语言占比ArkTS 99.65% TypeScript 0.35%运行要求DevEco Studio 5.0API 12无需签名、无需后端、无需联网远端地址https://atomgit.com/guowei88/JDShop仓库首页的 README 也不是一句占位说明而是按功能特性、工程结构树、设计规范京东红#E9383D、运行环境与运行方式、技术要点ArkTS V2 响应式架构、购物车跨页面联动、图片失败回退、MIT License 分了六块。首页、分类、购物车、我的四个 Tab 的功能点都有对应描述。图 18AtomGit 仓库首页master 分支、43 个文件全部就位语言占比 ArkTS 99.65%README 的预览一节甚至用表格列出了四个 Tab 各自负责什么。八、操作链路全景一张图看清它做了什么把前面六节串起来这条链路的形状是清楚的——先对齐、再探路、后施工最后交付并验证。无 SDK 无 hvigor可用用户一句话需求帮我开发一个鸿蒙app商城的页面深度思考判定为鸿蒙开发任务三轮需求澄清页面范围 / 数据来源 / 工程形式环境自检ls 工作目录 → node → hvigor/ohpm工具链是否可用调整交付策略生成完整工程交本地 DevEco 编译本地构建验证加载专家能力harmonyos-plugin / harmony-developerTask 下发子代理目标目录 4Tab Mock Stage 工程创建标准工程树AppScope / entry / hvigor / resources资源兜底1x1 PNG 图标、占位图、INTERNET 权限git init → add -A → commit43 文件 2481 行ag auth status未登录 → 询问认证方式git remote add → push仓库创建成功README 六段式功能/结构/规范/运行/技术要点/License九、新手手写 vs AI 生成把同一条链路拆成两列接下来是本文的核心对比。我不打算讲AI 更快这种没有信息量的话而是按具体环节逐项对照。环节新手手写AI 智能体生成差距的本质需求澄清需求散在脑子里边写边改三轮 question锁定范围数据形态返工成本是否被前置技术选型容易卡在版本与配置组合上直接落到 ArkTS ArkUI Stage 模型 API 12经验密度工程骨架目录随手建做到第三页才重构一次性铺出标准 Stage 工程树有没有先定结构的意识环境问题遇到编译报错再回头查动手前先探 hvigorohpmSDK并如实说明局限失败模式是否被提前规避资源缺失图标缺失导致编译失败反复试预判$media:icon与startWindowIcon生成占位 PNG对隐式引用的掌握程度编码产出四个 Tab 通常要跨天完成43 个文件 / 2481 行单次会话产出产量不是一个量级版本管理手动 initaddcommit容易漏.gitignore全流程自动执行并在推送前检查凭据流程规范度文档常被省略或只写一句启动方式自动产出六段式 README含契约与边界交付完整性异常中断报错即卡住进度停摆遇到配额错误、未登录仍能换方案续做恢复能力最终验收靠肉眼点一遍同样需要人工打开页面核对这一段谁都不省这张表里有两列我想单独说明。第一列是环境问题和资源缺失。这两项是新手和 AI 差距最大的地方但差距不在AI 懂得多而在于它把排查从事后救火改成了事前设防。新手是在构建失败之后才认识 hvigor 的而它是在动手之前就确认了 hvigor 不存在并且据此改了交付策略。这个习惯是可以学的动工前花三十秒把工具链和隐式资源依赖过一徧。第二列是最后一项最终验收。上一节开头那份 README 写得再全也挡不住页面在真机上跑起来是歪的。43 个文件和 2481 行代码是产出量不是可用度。沙箱里既没有 hvigor 也没有设备图片失败回退、购物车跨页联动、四个 Tab 的滚动惯性这些事只有把工程拉到 DevEco Studio 里打开、运行才知道成不成。这一点上AI 没有任何优势它只是把该你验的部分给你留得更清楚了。十、写在最后如果把我这次记录压缩成三句话大概是这样的。第一AI 生成的起点不是代码是问题。三张截图里的三轮提问看起来只是几句选择实际上决定了后面生成 43 个文件还是 8 个文件。对新手来说最该先学的不是写 ArkTS而是动手前把范围问清楚。第二它最可靠的能力是把工程骨架和配置引用一次对齐。从 Stage 模型目录到$media:icon的占位处理这些是纯经验活新手要摔几次才能记住而它一次就能做对。这部分的收益是实打实的。第三它替代不了你打开页面那一眼。沙箱没有工具链、没有设备编译不了也跑不起来。真正决定这个应用能不能用的还是把工程拷到本地 DevEco 里运行的那一刻。回到最初那个简单的游戏功能需求上。如果现在让我重做一次我会把这套流程照搬一遍先用三轮问题把范围、数据、交付形态钉死让它铺出标准工程骨架和占位资源拿到一套能编译的起点然后自己接管核心玩法逻辑——因为游戏的手感、节奏、反馈这些东西从来不是配置问题也不是脚手架能替你决定的。
