我是崔树雄，长期从事HarmonyOS应用开发，也做过不少三方工具库和工具类应用。过去几年，我更多是在底层能力、开发者工具和三方库方向做积累。今年开始，我把很多想法集中到一款新的应用里，它就是Nameo。

Nameo最初并不是想做一款普通笔记，也不是单纯做一个AI知识库。它的定位更宽一些：我希望它成为HarmonyOS上的全场景智能知识助手。

这个想法最早来自一个很具体的需求。我有一个朋友每天都在开会，会议结束后，领导会分配很多事情。他需要把会议内容整理成纪要，把任务提取出来，再按优先级区分哪些今天要做、哪些可以之后处理。这个需求很典型：信息每天都在产生，但真正困难的不是“记录下来”，而是能不能被整理、被搜索、被提醒，并且在需要的时候主动出现。

再加上我自己一直想转向AI Agent工程方向，也注意到企业级RAG已经很多，但端侧RAG、个人知识库和HarmonyOS全场景结合的产品还不多。于是我开始做Nameo。

AI笔记、知识库、收藏工具很多，为什么要做Nameo？

市面上AI笔记、知识库、收藏工具已经不少。既然如此，我首先思考的就是，Nameo凭什么让用户使用？

我给Nameo设计了三个差异点。

第一是采集方式要足够低门槛。用户不应该为了整理资料专门打开一个App，再去上传文件、复制文本、选择分类。我的思路是：只要用户在微信、浏览器、企业微信、系统文件、相册或其他三方App里看到有价值的内容，就可以通过系统分享、文件打开、图片采集、跨设备拖拽等方式直接丢给Nameo。剩下的事情，Nameo自己处理。

第二是信息进来之后，不能只是被动等待用户搜索。很多资料之所以被遗忘，不是因为用户不会收藏，而是收藏之后没有再被使用。Nameo要做的是主动提取摘要、标签、重点和待办。比如A文档里说明天要交材料，B会议里提到下个月前要完成报价，Nameo应该把这些信息提取成待办，而不是等用户以后再想起来搜索。

                                Nameo实现主动提取摘要、标签、重点和待办

第三是主动推送和多端提醒。知识库不应该只在用户提问时才有价值。对学生来说，它可以把课程资料、截图、讲义变成复习卡和待办；对职场人来说，它可以把会议、客户资料、项目文档变成行动项；对普通用户来说，它甚至可以像一个AI记账本或生活事务助手，把每天说过的话、拍下来的图、收到的文件变成可追问、可提醒的个人记录。

所以Nameo不是“把资料存起来”的工具，而是把语音、图片、文件、网页、会议和系统分享里的碎片信息，整理成可搜索、可复习、可追问、可行动的个人知识库。

Nameo信息处理链路、隐私、端侧AI能力分享

Nameo当前支持文字、图片、语音和会议等多种信息形态。以图片和文档为例，一次完整处理大致分为几个步骤。用户从前台应用把内容分享到Nameo后，文件首先会落地到Nameo应用沙箱目录。然后系统会根据内容类型走不同解析流程：例如图片使用Core Vision Kit做OCR；Word、Excel、PDF、PPT分别走对应解析逻辑；语音场景则使用Core Speech Kit。会议场景还会结合长录音后台处理、会议摘要和行动项提取，沉淀成纪要、重点和待办。所有内容形成统一标准格式后，进行摘要、标签、切片、检索和问答。

当内容清洗后，Nameo在端侧进行向量化和本地检索处理。通过使用MindSpore Lite Kit加载端侧模型，并完成语义检索与重排。模型需要先转换成HarmonyOS可用的格式，原始模型精度是F32，大小大约90MB；压缩到INT8后，模型体积降到约24MB。对于一个面向普通用户的App来说，这一步非常关键，因为模型太大，会直接影响安装包体积和运行资源占用。

用户发起提问时，有两个入口。一个是全局知识库提问，另一个是单张知识卡提问。这里有一个重要设计：Nameo支持隐私模式。默认情况下，应用会开启回答增强，把检索出来的最小必要片段发给云端大模型进行组织和总结，而不是把用户完整文件上传云端；但如果用户当前场景要求内容不能上云，也可以关闭增强模式。关闭后，Nameo仍然能够依靠端侧检索给出结果，只是回答会相对碎片化，可能不如云端总结那么完整。这是隐私、安全和体验之间的平衡：我不能替用户决定所有数据都必须上云，也不能因为追求绝对端侧而牺牲所有可用性，所以把选择权交给用户。

很多产品都会说自己重视隐私，但真正做端侧AI时，问题会非常具体。模型怎么加载？包体多大？低端设备能不能跑？知识卡越来越多后，检索会不会变慢？本地索引如何更新？用户有几千个文件时，体验还能不能接受？Nameo后续会根据真实用户数据来动态调整策略。

这背后还有一个更大的规划：Agent能力。现在Nameo的问答本质上还是带有多跳能力的传统RAG。未来接入Agent后，变化会更明显。Agent不只是检索后回答，而是会围绕用户目标进行任务拆解、多步检索、工具调用、生成草稿，并在涉及写入用户数据时让用户确认。在HarmonyOS 7进一步开放Agent、A2A和Skill等能力后，小艺会生成会议纪要草稿，再提示用户是否保存到Nameo。进入Nameo之后，App内Agent Pro可以基于这份会议纪要继续生成待办、项目周报或后续复盘。一句话概括就是：小艺负责低门槛唤起，Nameo负责长期沉淀和深度处理。当然这里我依然会坚持权限和边界：私有知识不会默认暴露给小艺或外部入口。用户的长期知识资产必须是可控的。

Nameo关键全场景入口：闪控球、精准分享

如果只选两个最能体现Nameo全场景特点的能力，我会选闪控球和精准分享。

闪控球解决的是跨应用快速采集的问题。用户不一定总是在Nameo里面工作，他可能正在浏览网页、看微信文件、读一篇文章，或者查看一张截图。这个时候，如果还要求他复制内容、切回Nameo、粘贴、保存，整个知识收集链路就太长了。

在Nameo里，闪控球需要用户在App内手动开启。开启后，用户可以把闪控球拖到合适位置。当用户需要采集当前内容时，我做了最小化获取：只截取用户当前看到的最上层窗口，把这一张图片放进Nameo沙箱，再进行OCR、标签生成和卡片创建。处理完成后，Nameo会自动拉起知识卡片详情页，AI标签、摘要等结果会直接展示出来，用户可以继续提问。这个设计的核心不是“截屏”，而是把系统级入口、内容采集、OCR、知识卡生成和AI问答连成一条最短路径。用户看到有价值的信息，不需要思考太多操作，交给Nameo就可以。

精准分享则更适合跨设备场景。比如PC端正在处理文件或资料，用户可以通过精准分享、跨设备拖拽、文件打开等方式，把资料直接交给Nameo。文件在哪台设备上出现，就从哪台设备进入知识库。之后用户可以在PC上整理，在手机上继续追问，在Pad上阅读复盘。

                          Nameo桌面卡片萌宠（HarmonyOS 7版本将增加桌面萌宠互动）

我还做了一个比较轻量的设计：桌面卡片可以用萌宠状态表达待办紧急程度。普通事项是平静提醒，临近截止是专注提醒，已经紧急的事项会用更明显的状态提示用户处理。这样用户不打开App，也能知道今天是否有重要事项。

这也是我理解的HarmonyOS全场景价值：不是简单“多个设备都能打开同一个App”，而是不同设备承担不同角色，围绕同一条知识工作流协同。

Nameo 多端协同流转演示：手表+手机

此外，Nameo还接入了很多HarmonyOS系统能力。例如Share Kit用于碰一碰、抓一抓分享以及PC/2in1接收链路；UDMF和UnifiedDataChannel用于系统分享和文件接收；Camera Kit和MediaLibrary Kit用于拍照、相册选择和图片采集；Background Tasks Kit用于会议长录音和后台解析收尾；Notification Kit和ReminderAgent用于解析进度、待办提醒和手表本地周期提醒。

Nameo从开发到上架，用了半年多时间。目前Nameo已经覆盖手机端、手表端、平板端和PC端，四端前端代码量加起来已经超过15万行。对于想做HarmonyOS AI应用的开发者，我的建议是一定要先想清楚规划，再开始做。不要看到一个技术热点就马上写Demo，也不要只因为AI能帮你生成代码就贸然做产品。要先调研清楚用户需求、系统能力、数据边界和长期维护成本。

我从早期就参与HarmonyOS开发，也能明显感觉到生态在变化。我之前一直做三方库，今年才开始做Nameo，也是因为积累到一定阶段后，我对产品、技术和生态的判断更成熟了。Nameo并不是只做一个AI笔记，而是想把我过去几年对HarmonyOS能力、全场景入口、端侧AI和Agent趋势的理解，集中到一个长期项目里。

通过Nameo的开发，能看到AI时代的应用已经不再是一个界面加几个模型接口，真正有价值的应用，需要理解用户的长期场景，也要理解系统能把能力放到哪些设备和入口中。对Nameo来说，我希望它最终不只是帮用户记住内容，而是理解用户长期积累的学习、工作、会议、项目、客户和创作上下文，在合适设备、合适时刻帮助用户复习、复盘、生成、提醒和执行下一步。

这才是我理解的个人知识行动Agent，也是Nameo接下来要持续演进的方向。