适合谁看

• 正在做内容型或 IP 型应用的人

• 想让代码仓库容纳内容资产的人

• 不想把内容完全外包给表格和即时文档的人

• 正在做鸿蒙内容型或 AI 型应用的人

问题背景

很多项目仓库默认只有：

• 源码

• 配置

• 构建脚本

但内容型应用不一样。
它还会长期依赖：

• 菜品资料

• 视觉图

• 发布素材

• 法务页面

• 运营内容

如果这些东西不纳入工程视角，团队后面会越来越难协作。

而在鸿蒙内容型项目里，问题还会继续放大。
因为除了页面本身，你还可能需要让这些内容继续进入：

• 桌面卡片

• 系统直达入口

• AI 助手推荐

• 语音播报和内容消费场景

项目中的真实场景

食界探味当前比较能体现“内容驱动型架构”的目录包括：

• app/

• docs/content/

• visual/

• videos/

• html/

• renders/

而和鸿蒙平台层直接相关的目录还有：

• app/ohos/

• app/ohos/entry/src/main/ets/formability/

• app/ohos/entry/src/main/ets/entryability/

这说明仓库不只是代码容器，也是内容和素材容器。

核心实现

如果这篇只讲“代码、内容、素材可以放一起”，还是不够像鸿蒙教程。
更值得讲的是：

• 为什么内容层必须足够稳定，才能支撑 HarmonyOS 入口和卡片

• 为什么代码层和素材层在鸿蒙内容型项目里会发生更紧的协作

一、代码层负责交付应用体验，但鸿蒙项目里的代码层不只是 Flutter 页面

app/ 负责的是：

• 页面

• 交互

• 路由

• 平台能力

这仍然是项目的主体。

但放到当前项目里，app/ 又可以继续拆成两层：

• app/lib/ 负责 Flutter 页面、状态、模型和 AI 交互

• app/ohos/ 负责 HarmonyOS 壳工程、系统入口、卡片和原生插件

所以对鸿蒙内容型 App 来说，代码层天然就不只是一个前端目录。

二、内容层负责定义“应用里有什么”，这层稳定性会直接影响鸿蒙入口和卡片

docs/content/ 里不是普通说明文档，而是：

• 食材资料

• 菜品内容

• 图片模板

这类内容本身就接近产品数据源。

这在鸿蒙项目里会更明显。
因为像：

• 每日推荐卡片

• 系统直达入口承接的内容页

• AI 助手推荐时要展示和讲解的内容

背后都要求内容层至少有稳定的对象语义和素材来源。
否则你很难把这些东西安全地接进 app/ohos/ 那一层。

三、素材层负责表达和传播，而这会反过来影响鸿蒙侧展示能力

像：

• visual/

• videos/

• renders/

这些目录说明项目不仅要运行，还要被展示、讲解和传播。

在鸿蒙内容型项目里，素材层不只是“发宣传图”。
它还会反过来影响：

• 卡片里的图片资源怎么准备

• 首页、详情页、推荐位的视觉表达是否统一

• 比赛演示和对外展示是否能和应用能力说同一种语言

四、法务和对外页面也是工程的一部分，鸿蒙分发场景里尤其不能缺

html/food_voyage_privacy.html、html/food_voyage_terms.html 这类文件说明：

• 隐私政策

• 服务条款

也被纳入了仓库维护。
这对上线和对外分发同样重要。

如果你要把这个项目真正作为鸿蒙应用发布、展示或参加活动，法务和对外页面都不应该游离在仓库之外。

五、为什么鸿蒙内容型项目更需要“代码、内容、素材”一起看

如果把当前项目的几条链放在一起看，会更容易理解这个结论：

• Flutter 页面消费内容对象和素材

• AI 助手围绕内容对象做推荐和播报

• HarmonyOS 系统入口围绕稳定语义把用户送到对应内容页

• 卡片层又要求内容和图片能被稳定组织出来

也就是说，在鸿蒙内容型项目里：

• 内容不是页面的附属品

• 素材不是传播层的附属品

• 它们都在反过来约束代码架构

关键代码位置

• app/

• docs/content/

• visual/

• videos/

• html/

• renders/

• app/ohos/

• app/ohos/entry/src/main/ets/formability/

• app/ohos/entry/src/main/ets/entryability/

鸿蒙侧实现

鸿蒙侧本身不直接决定内容架构，但像：

• 卡片推荐

• 系统入口展示

都会反过来要求内容层足够稳定，能被平台入口消费。

当前项目里最明显的几个落点就是：

• DailyRecommendFormAbility.ets 需要稳定的推荐内容与图片

• InsightIntentExecutorImpl.ets 需要稳定的内容语义入口

• IntentNavigationPlugin 和 Flutter 路由层需要稳定的内容对象承接

Flutter 侧实现

Flutter 侧的页面和模型，最终都要消费这些内容资产。
所以鸿蒙内容型 App 的 Flutter 架构，不能只围绕 UI 组件理解，还要考虑：

• 内容从哪里来

• 素材怎么被组织

• 哪些内容最终会进入 HarmonyOS 系统入口和卡片能力

常见坑

• 仓库只管理代码，内容散落在外部表格和聊天记录里

• 素材、法务、演示资产完全脱离工程管理

• 页面结构很清楚，但内容结构混乱

• 内容型应用却仍然按工具型 App 的思路组织仓库

• 写鸿蒙入口和卡片时才发现内容没有稳定语义，只能临时拼字段

• Flutter 页面、鸿蒙卡片、AI 推荐各自消费不同一套内容表达，最后内容层越来越碎

可复用模板

app/          -> 应用交互与能力
docs/content/ -> 内容资料与文案源
visual/       -> 视觉素材
videos/       -> 演示与传播资产
html/         -> 法务与静态对外页面

内容对象稳定
-> Flutter 页面能消费
-> AI 能推荐
-> HarmonyOS 入口能直达
-> 卡片能展示

本篇总结

• 鸿蒙内容驱动型 App 的仓库，不应该只容纳代码

• 代码、内容、素材和对外资产一起被管理，才能同时支撑 Flutter 页面、AI 能力和 HarmonyOS 系统入口

• 食界探味当前的目录结构，正好体现了这种工程特征，也更适合写成鸿蒙 Flutter 教程