我想验证"会议纪要整理"这个想法值不值得做，但不想一上来就搭工程、写 ArkTS——万一想法本身就不成立呢。正好平台有 VibeCoding：用自然语言描述需求，AI 帮你把 Skill 生成出来。这一篇就走这条路。

一、为什么我先试 VibeCoding

理由很实际：它是成本最低的验证方式。传统手写 Skill 要掌握 ArkTS 和鸿蒙智能体框架，周期以天计；VibeCoding 靠自然语言描述，周期以分钟计。想法还没被验证之前，投入几天写代码是不划算的——你可能在为一个没人要的能力写工程。

当然它也有边界——涉及极复杂的定制逻辑，官方也说明仍需传统开发方式补足。这个我们下一篇处理。

二、十步逐走

下面是我在平台上实际走的顺序（按官方文档整理）：

第 1 步，进入创建页：登录小艺开放平台 → Skill → 新建 Skill → 选择 Vibe Coding。

第 2 步，填基本信息：在对话框里填 Skill 名称、描述、触发意图。触发意图决定后续能不能被精准匹配，是这十步里最该花心思的一步——别急着往下点。

第 3 步，选拓展能力：点对话框下方的【@】按钮，添加需要的插件或拓展能力。我要整理纪要得读写文件，所以在这步加了文件相关的能力。

第 4 步，开始生成：点对话框下方的蓝色箭头按钮，AI 开始解析你的需求。

第 5 步，选定生成范本（可选）：如果选了 Skill 检索，可以指定某个已有 Skill 当作生成范本，让它照着那个风格生成。这步可以跳过。

第 6 步，需求澄清与规划：生成过程中它会提几个问题，用来澄清生成计划。别一路回车——这里的回答直接决定生成质量，我在这一步花的时间比写描述还多。

第 7 步，生成中：按 Todos 列表的进度往下走，你能看到它正在做什么，不用干等。

第 8 步，测试与评测：平台会自动校验 SKILL.md 文件的合规性。你也可以选择进入评测——平台自动生成测试用例、执行工具调用、输出 Canvas 报告。跳过测评也能继续，但我建议第一次别跳，那份报告能告诉你它在哪些话术上会误触发。

第 9 步，填 Skill 描述：生成完要填描述，供 Agent 通过语义理解精准匹配你的 Skill。这步别敷衍，它就是第 5 篇讲的"被发现"的命门。

第 10 步，自动打包：平台整合代码、封装权限、校验合规，生成可上线的 Skill 包。

三、触发意图怎么写才准

第 2 步那个触发意图，我按第 5 篇的方法写：正向话术列三种说法（“整理成会议纪要”“把这段讨论的要点理出来”“帮我总结刚才的会”），反向排除列三种容易混淆的（订会议室、查日程、发纪要给别人）。

写的时候有个小技巧：把相邻意图全想一遍。用户可能说的、跟你的能力沾边但其实不是你的活，都写进"不调用"里。这活儿花十分钟，能省掉后面一堆误触发的麻烦——而误触发这个东西，上线之后用户不会告诉你，他们只会弃用。

四、"会议纪要整理"跑通

我填完信息，用【@】加了文件读写类的拓展能力，然后在澄清环节被问了两个关键问题：输出格式要 Markdown 还是结构化数据？要不要单独提取待办事项？

这两个问题我一开始没想过，但它问出来我才意识到——用户拿纪要是要发群的（那就 Markdown），而且最在意的是"谁负责什么"（所以要待办提取）。这两个需求是它问出来的，不是我一开始就想到的，这是澄清环节真正的价值。

澄清完生成，校验通过，打包出来。生成完我做的第一件事，是把它写的 SKILL.md 从头读一遍。那是它递给小艺的"简历"，机器看的就是这份文件，我不能不看就发出去——尤其是它自动写的触发场景，经常会比我想要的宽。

五、什么时候该用 VibeCoding，什么时候还得手写

我的判断标准很简单：

用 VibeCoding——标准能力外化、快速原型、验证想法。我要在几分钟内知道这事能不能成，成不了就换，沉没成本几乎为零。

必须手写——逻辑复杂到它生成不稳、要深度调端侧能力、要复用公司已有的业务代码和权限体系。这三条命中任何一条，生成出来的东西你都不敢直接用。

官方也给了同样的对比：VibeCoding 要求的是"自然语言描述能力"，传统开发要求的是 ArkTS 和框架掌握程度；前者分钟级，后者以天计。两条路不是谁替代谁，是分工——先用快的那条约出需求，再用稳的那条做实现。

下一篇，我们走第二条路：手写一个 Skill，讲清 SKILL.md 的结构、工程目录、ArkTS 入口脚本的定位，以及随应用包发布时要过的那些关。