那天我正在写 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 客户端 UI；Docker 继续解决环境隔离。项目正在补齐内部验证 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 看起来像老乡，为什么聊几句以后，口音会越来越重。