那天我正在写 CRUD电脑突然死机了。没有报错没有蓝屏也没有给我一个能复制到搜索框里的错误码。它就是安静地躺在那里半天没动静。我当时的第一反应不是排查问题而是累。防汛管理系统、微服务框架、低代码平台……这些年做过的项目并不完全相同但用户、角色、菜单、权限、表单、报表总会以不同组合回来返场。这次写的又是熟悉的 CRUD电脑偏偏在这个时候死机了。“第 101 个管理系统”不是准确计数也不是嘲笑 CRUD。真实业务离不开增删改查我过去的工程经验也来自这些项目。只是那次死机把一个问题放大了如果下一个项目仍然只训练我已经熟悉的东西那么即使换一套 UI、加几个微服务成长也可能只剩提交记录在增长。后来我一度用一句很绝对的话概括这种疲惫传统开发已死。这句话当然不严谨。AI 应用一样离不开数据库、接口、事务、权限和部署。真正不够用的是只重复自己熟悉的开发流程却不再训练 RAG检索增强生成、Agent能调用工具完成受控任务的智能体等新问题的解决能力。于是我想做一个不能只靠“接口返回 200”证明完成的项目。2026 年 5 月为了参赛出发7 月开始面对商业化Nameo 最开始是 2026 年 5 月的 HarmonyOS 创新赛项目。参赛、学习、做个人产品不是分开的三件事先用比赛期限把产品做出来再继续处理上架和商业化问题。截至 2026 年 7 月项目重心已经从比赛提交转向商业化准备。我个人判断 HarmonyOS 仍然有很大的机会官方对开发者的支持也比较积极。我长期参与鸿蒙开发者生态对我来说它不是临时找来的标题关键词而是一条愿意继续投入的技术路线。但“有机会”还不够。技术必须能解释产品问题。我自己反复遇到的情况是会议听过转头忘了资料收藏过真正要用时不知道塞在哪照片拍过最后和菜单截图、快递单一起在相册里养老。Nameo 就从这些场景出发。在产品设计里我希望把采集、整理、追问、行动和设备流转连起来。后来我把它归纳成四个字记、理、问、做。“记”是把语音、图片、分享和文件先收进来。“理”是形成摘要、要点、标签、行动项和关系。“问”是基于个人知识库继续追问而不是让模型凭印象自由发挥。“做”是把结果承接成待办、提醒或下一步动作。“记、理、问、做”是我对产品链路的总结不是项目原有的官方架构名。图 1 的重点不是把四个字画得好看而是说明信息必须从采集继续走到证据问答和受控行动。各节点的实现与验证程度并不相同。图 2 把技术选择重新放回问题里HarmonyOS 解决原生采集与设备形态RAG 解决基于资料回答Agent 或确定性工作流负责把结果推进到行动后端与门禁则负责让产品长期运行。为什么不能只是另一个 Web 后台如果这个产品换成浏览器页面后毫无损失我就没有必要为了技术标签强行做 HarmonyOS 原生应用。可它首先要解决的是采集。以语音为例点击录音以后还要处理权限、分段识别、锁屏后台和异常恢复等工程边界图片、系统分享与文件也各有输入限制。这些是产品规范和工程覆盖范围各入口的真机验收程度并不相同。在产品设计中手机偏即时采集与查询平板适合整理和深度阅读PC/2in1 承担更重的工作区手表负责速览、提醒和轻量补记。这些是设备职责设计不代表全部跨设备链路已经验证。让手表编辑五千字会议纪要不叫“一次开发多端部署”更像是对手腕实施加班。当前工程把手机和平板放在同一个 phone HAP由模块构建产生的 HarmonyOS 应用安装包内适配PC/2in1 与 wearable 使用独立产品模块。哪些模型和服务可以共享哪些交互必须留在设备层这些才是 HarmonyOS 对项目产生的真实约束。Java、Vue 和 Docker 没过期只是不能再站 C 位转向 HarmonyOS AI并不意味着过去的技术栈要统一送去“历史遗留系统”专区。Java 经验仍然影响我怎么理解分层、数据模型、事务、权限和服务治理Vue 适合承担运营数据看板但不是 HarmonyOS 客户端 UIDocker 继续解决环境隔离。项目正在补齐内部验证 Harness自动执行检查并沉淀证据的验证框架和长期门禁不能直接说成标准云 CI 已经建成。项目当前真实后端是 Node.js、Fastify 和 TypeScript不是 Java。后续会用 Java 工程师熟悉的分层和服务治理做对照但不会把 TypeScript 项目改口成 Java 项目。即使一个普通接口已经满足返回值、权限、事务和幂等等确定性验收RAG 仍然多出一组问题检索到了什么证据是否足够多个文档之间的关系怎么处理答案能不能追溯。这个差别我是在准备提审时被教育的。准备提审时几个关联文件把 RAG 问住了2026 年 6 月项目已经准备进入提审阶段。我自己导入了几个存在关联的文件然后提出一个需要结合这些文件才能回答的问题。RAG 没答对。这次不是单独询问某一份文件而是需要结合几份关联材料才能得出答案。系统没有正确回答暴露出跨文件组合问答和多跳设计的缺口。具体文件名与内容暂不公开返工后的实现和评测也会放到 RAG 专项篇不在这里假装已经完成。图 3 右侧只是返工方向不是已经完成的效果证明。真正验收时还要检查问题拆解、每一跳命中的证据、最终引用和失败样本。这次返工不是简单换一个 Embedding把文本转换为向量表示模型。查询是否要拆解、候选证据怎么保留、允许走几跳、上下文预算怎么分、最终引用如何核对都是接下来必须重新回答的问题它们不代表当时已经全部实现。这次失败让我意识到聊天框出现回答只是起点。检索证据、跨文件关系、执行权限、状态恢复和评测需要分别验收不能用一次成功演示一起带过。多跳问题也不必一律交给 Agent能用确定性检索编排解决的部分优先保留可解释的流程。Agent 分支已经完成知识问答主链路的真机验证我另外做过约 50 轮人工问答回归当前基础问答流程基本跑通但这不代表 50 题全部通过。仓库中可审计的是 34 条检索评测、6 条回答级评测和三端 15/15 运行场景它们验证的是不同层级不能相加成一个“全部正确率”。多轮指代、PC 端确认、真实会议工具和报告保存等能力仍在继续验证。当前项目状态可以简单分成三层状态当前口径已有证据比赛版提交、知识问答主链路、部分真机与离线评测证据正在验证Agent 多轮与工具闭环、多端运行、商业化质量尚未完整闭环IAP应用内支付验单与恢复购买、跨设备备份恢复、长期 Harness 门禁等我现在用五个问题判断实战项目值不值得做这次经历让我形成了一张很朴素的选题检查表。你不一定要做 HarmonyOS也不一定要做知识助手但可以拿它检查自己的下一个项目。问题要检查的不是口号而是它是否来自真实、反复出现的问题没有某项新技术这个问题是否仍然存在它是否真的需要平台或系统能力去掉原生能力后产品价值会不会明显下降它能否形成端、云、AI 和数据闭环输入最终有没有变成用户可以使用的结果它会不会暴露失败、成本和安全问题是否定义失败样本badcase、评测集、反馈和发布门禁而不只准备成功路径Happy Path它有没有机会走到真实交付是否愿意继续处理认证、支付、部署、指标和售后如果五个答案都是“以后再说”项目大概率还是一份换了技术名词的功能清单。这套专栏想解决的不只是“会调用 Agent”在我接触到的转型交流里有些开发者已经能跑 Agent Demo却很难继续解释技术选型、RAG 失败、工具权限和发布证据。我希望这套内容帮读者少走的正是这段弯路。后续会依次进入 HarmonyOS AI 产品底座、企业 RAG/Agent 和商业化交付。多跳专题会给出脱敏失败样本、检索轨迹trace、引用检查和评测方法Agent 专题会讲工具确认、失败恢复和发布门禁。项目事实与演进方案会明确分开。这套专栏不能承诺谁学完一定转行或拿到 Offer。但读完以后至少不该只剩一句“我会调用大模型 API”而应该能拿出架构判断、失败复盘、验证方法和交付边界。下一篇从 Java/Vue 开发者最容易产生熟悉感的地方开始ArkTS 看起来像老乡为什么聊几句以后口音会越来越重。