我们是《稚方》APP的开发者王一鸣和刘家瑞，分别来自无锡工艺职业技术学院和深圳大学。

 我们来自不同学校，所学专业也完全不同。我学习的是数字媒体艺术设计（AI），主要负责产品调研、医学资料整理、视觉设计和交互体验；刘家瑞学习的是自动化专业，从大一开始自学HarmonyOS开发，负责应用编程、模型部署和技术方案落地。

 一次偶然的机会，我们在开发者社群中认识了彼此。虽然我们的专业背景不同，但对传统文化、技术创新和产品开发都有同样的热情。交流过程中，我们逐渐形成了一个共同想法：能不能通过HarmonyOS和端侧AI，让沉淀在古籍和家庭经验中的中医知识，以更加现代、智能的方式帮助普通用户？

《稚方》就这样从一个想法开始，逐渐成为了一款面向0—6岁婴幼儿皮肤健康的HarmonyOS应用。

一、我们不做“AI诊断”，而是做建议、记录和就医衔接

《稚方》选择0—6岁婴幼儿皮肤健康作为切入点，最早是因为我姑姑的一次经历。她是新手宝妈，孩子患过尿布疹，但因为家里有一些中医经验，她没有特别慌乱，而是参考太爷爷留下的紫草膏方子进行改良，完成了家庭护理。

但不是所有家长都有这样的知识储备。孩子出现尿布疹、湿疹或其他皮疹时，很多宝妈最难的不是“有没有信息”，而是信息太多、太杂，不知道该信什么；也不知道孩子到底是可以先在家护理，还是必须马上去医院。

我们前期调研后发现，家长面对儿童皮肤问题主要有几个痛点：好的专家一号难求；就医前很难找对专科医生；真正见到医生时，又很难专业描述孩子从发病、家庭护理到就诊前这段时间的变化。医生问诊时，很多信息只能从零开始收集。

所以，《稚方》想解决的并不是单一的“拍照识别”，而是一个完整流程：家长拍摄或上传皮疹照片，APP进行初步分类，给出护理建议，并保存图片、结果和记录。后续如果需要就医，这些记录可以作为医生了解病程的参考。

稚方APP 手机端首页界面

稚方APP pad端首页界面

 这里我们一直强调一点：《稚方》不是诊断工具。建议、记录、匹配医生这些工作，应用可以辅助完成；但确诊和治疗，必须交给医生。孩子如果只是类似尿布疹这类轻微情况，家长可以先获得基础护理建议；如果出现发炎、化脓等更严重情况，APP就应该提醒及时就医，而不是让家长继续依赖AI判断。

二、端侧AI：隐私和成本决定了我们的技术选择

 《稚方》的核心技术链路是：图片进入模型，模型侧完成分类，输出分类结果；应用再根据分类结果给出初步建议，同时保存本次测试图片和结果，用于后续问AI助手或提供给医生参考。

稚方拍照识别与分析结果示意图

 我们选择把模型部署在端侧，首先是出于隐私考虑。儿童皮肤照片和健康记录都比较敏感，如果每次识别都上传云端，用户会天然担心数据安全。端侧推理可以尽量减少原始图片离开设备的可能。

 第二个原因是成本。我们希望《稚方》保留一定公益属性，不希望核心功能依赖高成本的云端推理。我们当时也设想过，如果未来APP上架，最多可能是类似付费终身VIP这样的用户权益设计，用于线上问诊免排队，收入则用于APP迭代维护、医院合作和公益捐款。

 在模型部署上，我们使用昇思推理服务框架，把训练好的模型部署到HarmonyOS设备上进行推理。昇思在这里主要承担的是模型端侧部署和推理运行的角色，让我们能够把模型真正放进HarmonyOS应用内部，并调用更多系统级性能调度能力。

 但对我们来说，真正困难的不是“怎么调用模型”，而是“怎么训练出一个足够可用的小模型”。

 项目起步阶段，我们很难拿到专业医疗数据，只能先找开源数据集，同时整理知网资料、合作对接的授权合规数据、中医药典籍，以及太爷爷留下的古方典籍，作为后续知识库和数据基础。

 训练模型这件事对我们来说非常吃力。我们都不是医学影像或机器学习相关专业，一开始对专业领域缺少足够敬畏。真正做起来才发现，识别会受到很多因素影响。模型能跑起来，并不代表它在真实使用场景中足够可靠。因此，《稚方》的模型准确率还不足以大范围推广。我们不想回避这个问题。赛后，我们开始和一些小模型领域的开发者、专家和机构继续合作，希望进一步优化模型精度。健康类应用和普通工具应用不同，模型输出不能只追求“看起来像”，更要对用户负责。

三、服务卡片：让皮肤记录变成一个自然入口

 除了端侧模型，《稚方》接入的一个重要HarmonyOS能力是服务卡片。

 儿童皮肤问题通常不是看一次就结束，而是需要连续观察。比如今天有没有变红，明天有没有扩散，护理后有没有缓解。如果每次都要求家长主动打开APP，再找到拍照入口，这件事很容易被忘记。

稚方服务卡片示意图

 服务卡片解决的是入口问题。用户可以把《稚方》的卡片放在桌面上，不需要刻意记住“我要打开APP拍皮肤”。当家长看到桌面卡片，就会自然想起要不要给孩子拍一张照片，记录一下变化。

 这也是我觉得HarmonyOS服务卡片对这类应用很有价值的地方。它不是简单把APP功能缩小，而是把一个需要长期坚持、轻量执行的任务，放到用户更容易触达的位置。对儿童护理、健康记录、慢病观察这类场景来说，卡片能力比单纯的APP入口更自然。

四、小艺智能体：让家长看懂模型返回的结果

 模型给出分类结果之后，还有一个问题：用户未必看得懂。

 很多家长看到疾病名称、护理建议或者医生提到的术语时，仍然会困惑。我们不希望《稚方》只是丢给用户一个分类标签，而是希望它能继续解释这个结果，帮助家长理解下一步该做什么。所以，我们接入了小艺智能体，配置了稚方相关知识库，并做了针对性调整。用户遇到不明白的疾病、术语，无论是在和医生连线时，还是拿到模型给出的结果后，都可以询问“稚方小助手”。

 在这个流程里，端侧模型负责图片分类，小艺智能体负责知识解释和理解辅助，服务卡片负责持续触达和提醒。它们组合起来，才更接近我们想做的产品体验：不是一次性识别，而是记录、理解、护理建议和问诊衔接。

 接下来，我们还计划继续完善“稚方圈”。用户可以在稚方圈交流相关情况，也可以通过“抓一抓”“碰一碰”等HarmonyOS能力，实现熟悉宝爸宝妈之间的快速分享帖子。这个方向还在规划中，但我们希望它能让家长之间的信息交流更低门槛。

五、开发经验：AI工具降低开发门槛，但不能替开发者做判断

 严格来说，我们两个人都没有接受过系统的软件工程训练。家瑞主要是通过公开资料、社群交流和一个个项目，从零自学HarmonyOS开发。我的主要职能不在代码，而在资料整理、产品设计和视觉体验。

 在开发过程中，我们使用了DevEco Code等AI代码工具。我们的方式是先提出技术路线，再验证代码结果。代码开发和修正，现在确实有很大一部分可以交给AI辅助完成。

 现在是Vibe Coding时代。AI懂语法，也懂常见架构。如果只是写出一个能跑的软件，门槛确实比过去低了很多。普通学生、非计算机专业学生，也有机会把自己的创意变成一个真实应用。

 但我们也越来越明确地意识到：能跑的软件，和高质量的软件，不是一回事。

 想做出质量高的应用，开发者必须读得懂代码，理解工程结构，也要知道自己接入的HarmonyOS能力到底解决什么问题。不能把所有技术选型全部交给AI。那样就像请了一个外包，项目也许能运行，但开发者自己并没有真正成长。

 模型训练给我们的教训尤其明显。AI可以帮助写代码、修报错，但它不能替我们提供可靠数据，也不能替我们判断模型是否足够适合儿童健康场景。越是专业领域，越不能把判断完全交给AI。

 这次组队也让我感受到，跨专业合作很重要。一个团队不一定要全是技术人员。家瑞以前做的应用更多偏办公和开发场景，和我一起比赛后，他也觉得自己的想法被拓宽了，UI不再那么死板。我的设计、调研和中医资料整理，也需要他的技术能力才能落地。

 我现在最大的感受是：开发者至少要对自己做的事情有热情，愿意花时间主动了解技术和系统特性。不能只是“AI说这样可以”，就照着做。只有把技术、特性和自己的想法真正融合起来，做出来的软件才是自己的，而不是AI的。