以前做应用开发，我们经常讨论一个问题：功能已经做出来了，用户为什么还是找不到？

很多时候，问题并不在于功能不够好，而在于入口太深。用户需要先打开应用，再进入某个页面，最后才能找到对应功能。对于使用频率不高的功能，这个过程尤其容易让人放弃。

HarmonyOS 7 的 Skill 能力让我看到了另一种思路：除了让用户主动进入应用，也可以把应用中的特定能力开放出来，由系统智能体根据用户意图进行调用。

我打算用一个简单的学习资料整理功能来说明开发思路。

先明确 Skill 到底提供什么能力

假设我的应用可以整理学习资料。用户希望快速找到某个主题的笔记，那么我需要提供的能力不是“打开笔记页面”，而是“按照关键词检索笔记”。

这两者看似接近，实际上差别很大。前者只是界面跳转，后者才是一项能够独立调用的业务能力。

在设计 Skill 之前，我会先定义输入参数和返回结果：

interface NoteQuery {

keyword: string;

limit: number;

}

interface NoteItem {

id: string;

title: string;

summary: string;

}

这里的接口只是应用内部的数据契约，不是 HarmonyOS 系统 Skill 的声明文件。真正接入时，还需要根据官方 Skill 开发指南编写相应的描述文件和 ArkTS 入口脚本。

业务实现应该尽量独立

我更倾向于让 Skill 调用已有的业务方法，而不是专门再写一套查询逻辑。

async function searchNotes(

query: NoteQuery

): Promise<NoteItem[]> {

const allNotes: NoteItem[] = await loadNotes();

const keyword: string =

query.keyword.trim().toLowerCase();

const result: NoteItem[] = allNotes.filter(

(note: NoteItem) => {

return note.title.toLowerCase()

.includes(keyword) ||

note.summary.toLowerCase()

.includes(keyword);

}

);

return result.slice(

0,

Math.max(1, Math.min(query.limit, 10))

);

}

这里的 loadNotes() 是项目已有的数据读取方法。实际开发时，还需要考虑空关键词、敏感资料权限、搜索结果排序以及数据库查询效率。

描述文件不是随便写几句话就行

HarmonyOS 7 的官方 Skill 开发模式会使用描述文件定义能力的触发场景、入参约束和返回值契约，并通过 ArkTS 入口脚本桥接到应用的业务实现。

因此，描述能力时，我会尽量写清楚三个问题：用户在什么情况下需要它，需要提供什么参数，执行完成后能够得到什么结果。

比如，“搜索用户授权访问的学习笔记，支持关键词和结果数量参数，返回笔记标题与摘要”，就比“帮助用户管理学习资料”更容易对应到具体业务。

需要强调的是，以上描述是设计示例，不是可直接提交的官方 Skill 声明文件。正式接入时，必须按照 API 26 对应的文件结构、配置字段和参数格式完成适配。

还有一个不能忽略的问题：权限

如果应用中有私人笔记、工作资料或付费内容，不能因为用户通过小艺发起请求，就默认允许所有数据被访问。

Skill 入口仍然要遵循应用自身的权限规则。尤其是删除、分享、提交订单等会产生实际影响的操作，更应该设计明确的确认机制。

我的理解是，Skill 并不是给应用增加一个新的聊天页面，而是把原有业务能力整理成一套可描述、可调用的接口。

先把业务能力设计清楚，再通过官方 Skill 机制接入系统智能入口，这样开发出来的功能才更容易维护，也更容易扩展到其他调用场景。