适合谁看

• 正在找教程母项目的人

• 想做鸿蒙 Flutter 系列连载，但不知道项目要具备哪些条件的人

• 已经有项目在手，想判断它是否适合沉淀为教程的人

问题背景

很多技术文章写不长，不一定是因为作者不会写，而是因为一开始选错了母项目。

有些项目只能支撑两三篇文章，原因通常很直接：

• 功能太少，只能写“如何接一个能力”

• 业务太垂直，读者很难快速理解上下文

• 代码结构过于混乱，不适合拆成方法论

• 文档资产不足，无法把工程、产品和场景连起来

所以，真正需要回答的问题不是：

“这个项目能不能拿来写一篇文章？”

而是：

“这个项目能不能支撑一整套鸿蒙 Flutter 教程体系？”

食界探味之所以值得拆出来讲，不在于它“功能很多”，而在于它同时满足了一组更适合教程化输出的条件。

先说结论：适合写教程的项目，一般要满足什么条件

如果把“教程母项目”当成一个单独标准来看，我觉得至少要满足下面 5 条：

1. 有明确的产品主线：读者需要先理解它在做什么，而不是先理解一堆技术点。

2. 有真实的工程结构：不能只有一个最小页面，也不能只有孤立的能力样例。

3. 有清晰的平台边界：尤其是 Flutter 和 HarmonyOS 原生层之间，最好有明确分工。

4. 有系统能力差异化：否则文章会退化成普通 Flutter 项目讲解。

5. 有持续扩展空间：既能写基础文章，也能继续写架构、能力、调试、比赛和内容工程。

食界探味比较接近这 5 条。

1. 它先是一个产品，再是一个技术样例

对教程作者来说，一个非常关键的点是：

读者能不能在 30 秒内理解这个项目是在做什么。

食界探味在这点上相对清楚。它不是一个抽象平台工具，而是：

以食材为入口，探索全球不同吃法的美食探索 App。

这个定位有几个好处：

• 读者一眼能明白产品方向

• AI、语音、推荐、卡片这些能力都比较容易找到落点

• 文章不容易写成脱离场景的纯 API 说明文

例如：

• 语音识别可以自然落到“说出今晚想吃什么”

• AI 助手可以自然落到“根据食材和口味给建议”

• 卡片可以自然落到“桌面推荐今天适合尝试的菜”

这种产品主线会让后续文章更稳定，因为每个技术点都能回到同一个场景里解释。

2. 它有完整工程结构，而不是单点样例

食界探味不是只包含一个 app/lib/main.dart 的演示工程，而是一个相对完整的仓库。

目前它至少可以拆成四层：

1. Flutter 应用层

主要在：

• app/lib/

• app/lib/features/

• app/lib/core/

• app/lib/data/

这里承担的是用户真正会接触到的业务层：

• 页面结构

• 路由组织

• 数据模型

• 状态管理

• AI 页面交互

2. HarmonyOS 原生层

主要在：

• app/ohos/

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

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

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

这里承担的是系统能力与系统入口相关的内容：

• 语音识别插件

• 文本转语音插件

• 意图跳转插件

• 防窥保护插件

• EntryAbility 与 FormAbility

3. 文档与内容层

主要在：

• docs/content/

• docs/competition/

• docs/prd/

• docs/ue/

这一层会让文章不只是“解释代码”，还可以解释：

• 为什么要这样做

• 产品目标是什么

• 比赛语境下为什么需要这些能力

• 内容型应用如何组织资料

4. 后端与工具层

主要在：

• server/src/routes/

• server/src/services/

• server/src/cli/

• server/src/mastra/

这意味着它不仅能讲前端页面，还能继续延展到：

• 数据接口

• 内容工作流

• CLI 工具

• AI 辅助工具链

对教程作者来说，这种结构很关键。因为它决定了项目能不能从“写一篇”扩展成“写一组”。

3. 它有比较清楚的 Flutter / 鸿蒙边界

如果一个项目要拿来写鸿蒙 Flutter 教程，另一个关键点是：

Flutter 层和鸿蒙原生层的职责，最好不要混成一团。

食界探味在这方面相对容易讲清楚。

Flutter 侧主要做什么

Flutter 侧主要承担：

• 页面 UI

• 路由和导航

• 状态管理

• 数据展示

• AI 会话和业务流

比如在 app/lib/app.dart 里，可以直接看到比较完整的路由结构：

• /explore

• /search

• /ai-assistant

• /wish-box

• /ingredient/:id

• /dish/:id

这说明 Flutter 这里不是外围页面层，而是主要业务入口。

鸿蒙侧主要做什么

鸿蒙侧主要承担：

• 系统能力调用

• 系统入口承接

• 卡片和 Ability 生命周期

例如：

• SpeechRecognitionPlugin.ets

• TextToSpeechPlugin.ets

• IntentNavigationPlugin.ets

• AntiPeepProtectionPlugin.ets

• InsightIntentExecutorImpl.ets

• DailyRecommendFormAbility.ets

这种边界之所以重要，是因为它特别适合写教程：

• 一篇讲 Flutter 侧调用方式

• 一篇讲 ArkTS 侧能力实现

• 再一篇讲两者之间的边界和数据流

如果项目边界不清，这类文章很快就会写散。

4. 它有比较明确的鸿蒙差异化能力

不是所有 Flutter 项目都适合写鸿蒙教程。
如果一个项目只是“在鸿蒙上能跑”，但没有任何系统能力特征，那它更像普通 Flutter 项目移植记录，而不是鸿蒙教程母体。

食界探味目前已经具备几类比较典型的鸿蒙差异化点：

• 语音识别

• 文本转语音

• Intents Kit 页面跳转

• 防窥保护

• Form Kit 卡片

这些能力有一个共同点：

它们不是单独摆着，而是能回到实际产品流程里。

例如：

• 语音识别不是为了展示录音按钮，而是为了输入饮食需求

• TTS 不是为了做朗读样例，而是为了让推荐结果可被播报

• Intents Kit 不是为了注册意图，而是为了让功能页能被系统入口直达

• 卡片不是为了展示卡片 API，而是为了提供推荐触达

这会让教程更容易从“怎么接 SDK”过渡到“怎么把能力做成体验”。

5. 它还有内容工程和比赛语境，能支撑更长的选题链

很多项目能写 3 篇文章，但写不到 30 篇，原因是只有代码，没有别的层次。

食界探味的另一个特点是，它不只有代码，还有比较成型的文档和策划资产。

内容工程层

docs/content/ 里已经有很多按食材组织的内容资料。
这意味着后续不仅能写技术，还能写：

• 内容型应用怎么组织资料

• 图文内容如何工程化管理

• 技术项目如何结合内容生产

比赛语境层

docs/competition/ 里已经沉淀了：

• 比赛方向

• 能力方案

• PRD

• HarmonyOS 能力研究资料

这意味着后续还能继续写：

• 为什么接这些能力

• 怎么把项目改造成比赛版本

• 怎样从产品叙事角度重新组织技术实现

从教程策划角度看，这一点很重要。
因为它决定了选题不会只停留在：

• 插件

• 路由

• 状态管理

还可以继续延展到：

• 产品结构

• 文档体系

• 内容生产

• 比赛包装

6. 它的复杂度处在“够真实，但还可读”的区间

一个项目如果太小，写不出体系；如果太大，也不适合作为教程母体。

食界探味当前比较适合的地方在于，它已经有：

• 明确产品方向

• 完整 Flutter 层

• 明确鸿蒙能力入口

• AI 和后端协作

• 文档资产

但它又还没有复杂到必须先读一周源码才能动笔。

这对教程作者很关键。
因为你需要的是一个：

• 能拆

• 能讲

• 能连载

• 又不会把读者一开始就劝退

的项目。

那么，什么样的项目反而不适合拿来写教程

顺着这个标准，也可以反过来看。

下面几类项目，通常不太适合作为鸿蒙 Flutter 教程母体：

1. 只有壳，没有业务主线

这种项目通常只有：

• 登录页

• 一个列表页

• 一个简单能力演示

它可以写成单篇笔记，但很难长成系列。

2. 业务很强，但没有鸿蒙差异化能力

如果项目里完全没有系统能力、系统入口或鸿蒙生态结合点，那它更适合写普通 Flutter 架构文章，而不是鸿蒙方向的教程。

3. 原生层和业务层混得太严重

如果 Flutter 和 ArkTS 之间没有边界，后续文章会越来越难讲清楚谁负责什么。

4. 没有文档和内容资产

没有文档层时，项目很容易只剩代码分析，文章也很难形成更大的叙事结构。

常见坑

坑 1：把“功能多”误当成“适合写教程”

教程母项目最重要的不是功能数量，而是结构是否清楚、能力是否成体系。

坑 2：只看代码，不看项目有没有持续扩写空间

如果一个项目只能写插件接入，那它就不是完整的教程母体。

坑 3：把比赛项目等同于宣传项目

比赛语境本身并不是问题，关键是项目能不能把能力、场景和实现落下来。

坑 4：忽略文档层

没有文档层的项目，通常更难把技术点组织成长期连载。

可复用模板

如果你也想判断一个项目能不能作为鸿蒙 Flutter 教程母体，可以先用这 6 个问题筛一遍：

1. 它有没有一句话能讲清楚的产品主线

2. 它有没有完整工程结构，而不是单页 Demo

3. Flutter 和鸿蒙原生层的边界清不清楚

4. 它有没有真正的鸿蒙差异化能力

5. 它能不能支撑架构、能力、调试、文档等多个方向的选题

6. 它的复杂度是不是还处在可读范围内

只要这 6 个问题里，大部分答案是“有”，这个项目就比较有可能支撑起长期教程。

本篇总结

食界探味之所以适合拿来写鸿蒙 Flutter 教程，并不是因为它只是一个“能跑在鸿蒙上的 Flutter 项目”，而是因为它同时具备：

• 清楚的产品主线

• 相对完整的工程结构

• 明确的 Flutter / ArkTS 边界

• 可解释的鸿蒙差异化能力

• 文档、内容与比赛语境

• 足够长的选题延展空间

对于教程作者来说，这类项目的价值不只是“能写一篇”，而是“能持续写下去，而且每篇之间还能互相连接”。