从 appcan-helper 到 appcan-cli：我和 AI 一起迭代 AppCan 开发辅助工具
一、写在前面
我是在 2024 年 HarmonyOS NEXT 开始面向开发者测试时接触鸿蒙应用开发的，紧接着又开始为老东家 AppCan 准备鸿蒙版本的适配工作。
开发过程中遇到的问题越来越多，我也顺手把其中一些设计思路、开发规范和踩坑经验整理成文档。后来 Cursor、Augment、Codex 等 AI Harness 逐渐进入我的日常开发流程，这些文档、知识和与 AI 约定的规则也都派上了用场。
再往后，我把这些内容重新梳理成了 appcan-helper Skill，又把开发流程里重复、机械而且适合固定执行的部分逐步整理成了 appcan-cli。有了这两个辅助工具之后，AI 编写 AppCan 鸿蒙代码确实省事了不少，产出的工程结构和开发流程也比以前更规范。
二、appcan-helper Skill：边开发边积累，知识沉淀终于派上了用场
在现在这个 Skill 之前，我先做过一个同名的 appcan-helper MCP 服务，让 AI 工具可以直接查询 AppCan 官网的开发 API 文档。
AppCan 毕竟不是全球范围内广泛流行的开发框架。它曾经是国内比较有影响力的混合开发平台，但大模型训练数据中相关资料并不充分。接入这个 MCP 服务之后，Agent 查询官方文档的途径清楚了，我当时最直观的感受就是 Augment 写插件时犯错的概率明显降低，API 名称和调用方式方面的问题少了很多。
不过，能够查到 API 文档，只解决了其中一部分问题。鸿蒙开发本身也是新东西，当时大模型掌握的资料同样有限。结合官方文档之后，Agent 已经可以承担不少开发工作，但语法、命名、工程结构和平台差异方面还是经常出错。尤其是在 2025 年中期，Agent 的编码能力还没有现在这么稳定。
那段时间，每当遇到比较典型的问题，我就会自己整理，或者让 AI 在解决问题后补充文档，记录错误现象、排查方法和最后的处理方式。慢慢地，项目里积累了基础开发准则、AppCan 开发规范、鸿蒙开发规范、常见语法错误和各种真实案例。
到了 2025 年底和 2026 年初，我开始认真使用 Skill 机制，发现它很适合整理这些内容。于是我把原来分散的规则文档重新归类、提炼，逐步整理成现在的 appcan-helper Skill。之前那个同名 MCP 服务后来已经被我废弃了，查询官方文档的脚本和开发规则都收进了 Skill，目前只保留这一套入口。
三、重复性机械性工作的定义与执行：appcan-cli
Skill 可以帮助 Agent 理解项目规则和排查方向，但有些工作每次都要重复执行：初始化工作区、创建插件模块、检查目录结构、扫描配置和权限、接入宿主工程、执行内部测试或准备打包。
这些事情如果完全依靠 Agent 临时组织命令，大多数时候也能执行，但路径、参数和执行顺序很容易出现波动。大模型擅长理解需求和处理不确定问题，涉及稳定、重复、结果明确的逻辑时，还是应该尽量交给确定的代码。
于是我把这些稳定逻辑逐步封装成工具，让 Agent 在关键环节直接调用，由程序负责执行固定流程并返回可以检查的结果。appcan-cli 最初只是 AppCan 鸿蒙工程内部的一些维护脚本，后来功能逐渐增加，才被整理成了一个独立的命令行工具。
两者的分工也慢慢清楚了：appcan-helper 负责“应该怎么判断”，appcan-cli 负责“具体怎么执行”，我负责提出需求、做取舍和确认最终结果。它们不是一开始就规划好的完整体系，而是在开发过程中发现重复问题后逐步拆分出来的。
四、随着版本开发与迭代，这套辅助工具得到了进一步完善
最开始，有些插件工作需要手动创建目录、复制配置，再一点点接入宿主工程。后来这类流程重复多了，就把初始化和集成过程整理进 CLI，至少让目录结构和关键配置保持一致。
还有一些问题出在“看起来配置好了，但实际不能用”。比如权限、资源目录、插件依赖和测试页之间经常需要互相配合。于是工具逐渐增加了状态检查、权限扫描、插件集成和打包工程维护等能力，让一些明显问题能够更早暴露出来，而不是等到最后才看到一个模糊的失败结果。
我也逐渐不再把“构建成功”当成任务完成。CLI 的状态报告只能说明工作区当前是什么情况，HAR 或 HAP 构建成功也只能证明工程通过了对应层级的构建。插件能不能被 Entry 正确接入、JS Bridge 能不能调用、Widget 测试页是否可用，最后还得分别检查，真实功能仍然要通过真机验证。
当然，这种方式也有维护成本。AppCan、HarmonyOS、DevEco Studio 和相关工具都会变化，旧规则可能失效，CLI 也需要跟着调整。它更适合我这种会长期维护同一套技术栈的人，不是所有项目都值得专门做一套 Skill 和 CLI。
五、最后的感悟
现在到了 AI 时代，很多人会觉得，AI 都能干活了，程序员是不是也不用干了，过去写代码的方式是不是已经被彻底颠覆了？
但真正把一个功能写好、把一个项目长期维护下去之后，还是会发现开发流程非常重要。模型能力当然有差异，可如果 Harness 能让 AI 按照一套清楚的流程工作，即使模型没有那么聪明，它的表现也会稳定很多。至少在边界明确、结果可以验证的任务里，它会更接近一个按流程工作的程序员。
我在开发中还引入了 Superpowers 这一系列 Skill。它里面包含了不少传统软件工程的思想：先把需求说清楚，再做技术方案设计，接着整理计划、执行开发、完成测试和最终验收。AI 如果能认真走完这些环节，产出的结果通常会比接到一句模糊需求就立刻开始写代码可靠得多。
有时我们觉得 AI 写代码特别笨、特别傻，问题不一定全在模型本身。上下文是否完整、任务边界是否清楚、开发流程是否合理、最后有没有认真验收，都会直接影响结果。
软件工程是人类在几十年计算机发展过程中总结出来的宝贵经验，它不会因为写代码的人换成 AI 就失去价值。我刚开始做开发时也不太重视这些东西，总觉得大学里学的流程没有什么用，需求来了直接干就完了，何必弄那么多步骤。
随着经验逐渐积累，我才发现，恰恰是这些看起来有些麻烦的流程，才能让项目稳步推进，尽量减少环境变化、人员变化和临时判断带来的影响。现在执行者逐渐从人变成了 AI，这套思想依然有效，甚至比以前更重要。