【共创季稿事节】从毕业设计到鸿蒙开发者：我把求职焦虑做成了一张技能成长地图

CSDN黎燃

346人浏览 · 2026-07-18 00:12:29

CSDN黎燃 · 2026-07-18 00:12:29 发布

【共创季稿事节】从毕业设计到鸿蒙开发者：我把求职焦虑做成了一张技能成长地图

【共创季稿事节】方向三：毕业季 · 鸿蒙同行

毕业季最让人焦虑的，不一定是“我不会什么”，而是“我会的东西很散，不知道下一步该补什么，也不知道如何把它们讲给面试官听”。

于是我用 HarmonyOS 6.1 做了一个面向毕业生的应用——技能成长地图 Skill Path。它把 ArkTS、ArkUI、AI 应用、多端协同等能力，从一串模糊的关键词变成可视化星图、可完成任务、可执行的 7 日计划和可沉淀的作品轨迹。

本文完整复盘项目的产品思考、ArkTS/ArkUI 实现、声明式状态管理、沉浸式界面、AI 规划边界，以及为什么我认为毕业生学习鸿蒙时，最重要的不是“刷完多少课”，而是建立自己的能力证据链。

图 1：Skill Path 首页，以成长能量、学习连续性与能力进度呈现毕业生的学习状态

图 1：首页不是普通待办清单，而是把“本周我成长了什么”变成可见、可积累的成长仪表盘。

一、毕业季的真实问题：知识很多，路线很少

对很多应届毕业生来说，求职准备会陷入一种非常熟悉的循环：收藏了大量学习路线，下载了很多课程，做过几个 Demo，简历上也写了“熟悉 ArkTS、ArkUI、AI 应用开发”，但真正投递时，却很难回答三个问题：

我距离目标岗位还差什么？
接下来一周应该做什么，才能产生真正有价值的进步？
这些学习和项目，怎么变成能被面试官理解的作品证据？

这不是学生不努力，而是学习过程缺少一条从“知识点”到“能力”再到“作品”的闭环。

以 HarmonyOS 应用开发为例，ArkTS、ArkUI、Ability、网络、存储、响应式状态、多端适配、AI 服务接入、构建调试，任何一个词都可以学很久。但岗位并不只考察“是否看过概念”，而是更关心：

能否用 ArkTS 写出类型清晰、可维护的业务代码；
能否用 ArkUI 做出状态驱动、尺寸自适应的体验；
能否完成一个有真实数据流、异常处理和完整交互的应用；
能否说明技术选择、踩坑与迭代过程；
能否把 AI 或全场景能力落进具体用户问题。

因此，Skill Path 不把毕业生当成需要“打卡”的用户，而把他当成正在构建职业能力的开发者。项目的核心命题是：将碎片化学习转译为可验证、可回顾、可行动的成长路径。

在这里插入图片描述

二、产品设计：把“我要找工作”拆成三层可执行系统

整个应用只保留三个页面：首页、星图、计划。表面上功能不多，但这三个页面分别对应毕业生成长中的三个问题。

页面	回答的问题	核心内容
首页	我今天做什么	成长能量、连续学习、今日冲刺、继续学习
星图	我现在会什么、缺什么	鸿蒙能力模块、进度、状态、下一目标
计划	我如何朝岗位推进	目标岗位、AI 冲刺建议、7 日行动轨迹

这不是为了凑三个 Tab，而是刻意把信息层级拆开：

当下行动（Today）
        ↓
能力画像（Skill Graph）
        ↓
职业方向（Career Plan）

如果首页直接堆满能力卡、岗位要求、课程、任务和项目，用户会重新回到“信息很多，不知道先做什么”的状态。Skill Path 的策略是：首页给动作，星图给诊断，计划给方向。

图 2：今日冲刺以短时、可完成、可积累的任务降低毕业生开始学习的门槛

图 2：每项任务都包含时间成本、任务性质和 XP 回报，避免“学习鸿蒙”这种无法执行的大目标。

三、为什么选择“成长能量”而不是简单的完成率

学习类应用很容易把用户变成进度条的奴隶：完成率、排名、连续天数、徽章越来越多，真正的能力却没有增加。Skill Path 中的 XP 也可能被误解为游戏化装饰，因此设计时必须先定义它代表什么。

项目把成长能量视为能力证据的轻量反馈，而不是学习时长的代称。一个任务能够增加 XP，需要至少满足其中一个条件：

产出了可以运行的代码；
解决了一个明确错误；
完成了一次可复盘的技术练习；
为作品集补充了可展示的项目材料；
形成了可解释的设计选择或技术总结。

例如“完成 ArkUI 自适应布局练习”比“观看 20 分钟课程”更适合作为任务，因为前者会留下页面、断点策略或复盘记录；“复盘一次 ArkTS 编译错误”则鼓励开发者把踩坑变成知识资产。

this.MissionRow('完成 ArkUI 自适应布局练习', '20 分钟 · 推荐任务', '＋80 XP', ...)
this.MissionRow('为作品集补一段项目介绍', '15 分钟 · 求职加分', '＋50 XP', ...)
this.MissionRow('复盘一次 ArkTS 编译错误', '10 分钟 · 查漏补缺', '＋30 XP', ...)

从毕业生视角看，这种任务设计有两个现实意义：第一，它把“求职焦虑”转换成今天能完成的一件小事；第二，它让学习成果天然能够沉淀到简历、作品集和面试表达中。

四、HarmonyOS 6.1 工程结构：先控制复杂度，再扩展能力

项目当前是一个轻量但完整的 HarmonyOS 应用，核心页面集中在 IndexPage.ets，同时保持清晰的数据类型和组件边界：

skill-path-demo/
├── AppScope/                         应用级配置与资源
├── entry/src/main/
│   ├── ets/
│   │   ├── entryability/EntryAbility.ets
│   │   └── pages/IndexPage.ets
│   ├── resources/
│   └── module.json5
├── build-profile.json5
└── hvigorfile.ts

为什么没有一开始拆成十几个文件？因为当前版本的重点是验证三件事：成长任务是否可理解、星图是否能呈现能力差异、AI 计划是否真正有行动价值。过早拆分会增加样板代码和状态同步成本。

但“先集中”不等于“无边界”。页面内部仍然按功能使用 @Builder 分区：

HomeContent      首页容器
HeroCard         成长能量与总进度
DailyMissions    今日任务
MapContent       技能星图
Constellation    星图可视化
SkillList        能力轨迹
PlanContent      职业计划
AiPlanCard       AI 冲刺计划
BottomBar        固定底部导航

这让后续演进很直接：当接入真实数据时，可以把 SkillNode、TaskItem、PlanService 分别抽到 model/ 和 service/；当页面变复杂时，再把 HomeContent、MapContent、PlanContent 提取为独立组件。先用清晰边界验证产品，再根据复杂度拆分工程，是毕业生做项目时非常实用的节奏。

五、ArkTS 类型设计：能力地图先是一份数据契约

星图页面的核心不是画几个发光圆点，而是让“能力”拥有可被 UI、任务、AI 计划共同理解的结构。

interface SkillNode {
  icon: string;
  name: string;
  subtitle: string;
  progress: number;
  color: string;
  glow: string;
  status: string;
}

其中最值得注意的是 progress、status 和视觉字段：

progress 用于进度条与总体完成度计算；
status 用于把数字翻译成“进阶中”“突破点”“下一目标”；
color 与 glow 不是硬编码在组件里，而是能力领域模型的一部分。

const SKILLS: SkillNode[] = [
  { icon: '⌘', name: 'ArkTS', subtitle: '类型与工程基础',
    progress: 82, color: '#A98BFF', glow: '#D5C7FF', status: '进阶中' },
  { icon: '✦', name: 'ArkUI', subtitle: '声明式界面与动效',
    progress: 68, color: '#FF8DBB', glow: '#FFC6DD', status: '持续成长' },
  { icon: '◈', name: 'AI 应用', subtitle: '结构化输出与服务接入',
    progress: 54, color: '#58DBD0', glow: '#B5FFF7', status: '突破点' },
  { icon: '↗', name: '多端协同', subtitle: '响应式布局与任务流',
    progress: 39, color: '#79A8FF', glow: '#C7DAFF', status: '下一目标' }
];

对毕业生而言，这张表实际上也是一份自我评估模板。它不是要求每个人都具备完全相同的能力，而是提醒大家把“我会鸿蒙”拆成可解释的维度：语言与工程基础、UI 与交互、AI 应用能力、全场景协同能力。面试时也更容易围绕这些模块讲清自己的作品和成长过程。

六、声明式 UI：状态不应该藏在组件内部

ArkUI 的优势在于状态驱动 UI。Skill Path 的三栏切换、选中能力、任务完成、AI 生成中与计划展示，都由 @State 明确描述：

@State currentTab: number = 0;
@State selectedSkill: number = 0;
@State aiLoading: boolean = false;
@State aiPlanVisible: boolean = false;
@State streak: number = 12;
@State completedTasks: number = 2;

这段代码表达了一个很重要的开发原则：UI 是状态的函数，不要让 UI 自己偷偷保存业务真相。

例如任务完成时，不需要手动寻找某一行文字然后改颜色；只需更新 completedTasks 与 streak，任务行、统计文案和成长指标会根据状态重新计算：

.onClick(() => {
  if (!completed) {
    this.completedTasks++;
    this.streak++;
    promptAction.showToast({
      message: '任务完成，成长能量已增加！',
      duration: 1200
    });
  }
})

对应的 UI 判断也保持简单：

Text(completed ? '✓' : (index + 1).toString())
  .backgroundColor(completed ? '#B9F6D8' : '#503474')

Text(`${this.completedTasks}/3 已完成`)

当前 Demo 的任务数据是预置的。若扩展为真实应用，建议把任务列表改为 @State tasks: TaskItem[]，完成任务时通过不可变更新数组，再用 Preferences 做本地持久化。此时关键不是“能否点击”，而是让任务状态可恢复、可计算、可被 AI 规划服务读取。

七、三栏导航与全屏沉浸：让学习流不被页面结构打断

Skill Path 的导航采用 Stack + BottomBar，内容在上，固定底栏叠在最下方：

Stack({ alignContent: Alignment.Bottom }) {
  if (this.currentTab === 0) {
    this.HomeContent()
  } else if (this.currentTab === 1) {
    this.MapContent()
  } else {
    this.PlanContent()
  }
  this.BottomBar()
}

三个内容区各自是 Scroll，并预留了底部空间：

.padding({ left: 18, right: 18, bottom: 105 })

这是移动端布局常见但很重要的细节。因为底栏实际高度为 78px，如果滚动内容不留出额外安全距离，最后一项行动轨迹会被导航遮挡。很多初学者把这类问题误认为“底部留白”，实际是叠层布局缺少内容安全区。

窗口层面，应用支持 phone、tablet、2in1：

"deviceTypes": ["phone", "tablet", "2in1"]

并通过沉浸式窗口让系统栏与深色页面保持视觉连续：

mainWindow.setWindowLayoutFullScreen(true);
mainWindow.setWindowSystemBarEnable(['status', 'navigation']);
mainWindow.setWindowSystemBarProperties({
  statusBarColor: '#07131F',
  navigationBarColor: '#07131F',
  statusBarContentColor: '#FFFFFF',
  navigationBarContentColor: '#FFFFFF'
});

这里没有粗暴隐藏系统栏。学习、求职类工具不需要抢占用户的系统操作；更合理的体验是保留系统栏，同时让背景颜色连为一体。对毕业生项目而言，这也是一个值得写进复盘的细节：好的全屏，不是“看起来酷”，而是兼顾视觉、可用性和设备兼容性。

图 3：课程续学卡片以进度、章节和主题连接碎片学习与能力沉淀

图 3：把课程放进成长路径中，而不是把课程完成率当成能力本身。

八、能力星图：把抽象技能变成可被看见的关系

“技能树”并不是新概念，但毕业生常见的技能树只有一串标签：Java、Python、ArkTS、数据库、AI。它看起来丰富，却无法说明掌握深度、关联关系与下一步方向。

Skill Path 采用星图隐喻：每项能力是一颗星，星与星之间通过虚线构成路径；颜色区分能力领域，进度与状态说明当前阶段。

图 4：鸿蒙能力星图，将 ArkTS、ArkUI、AI 应用与多端协同组织成成长路径

图 4：星图不是装饰，而是让毕业生看见“我已经点亮什么、下一颗星在哪里”。

实现上，星图没有引入复杂图形库，而是用 ArkUI 的 Stack 做相对定位：

Stack() {
  Text('✦').fontSize(108).fontColor('#49326F').margin({ left: 22, top: 35 })
  Text('·  ·  ·  ·  ·').fontSize(26).fontColor('#8064AB')
  this.StarNode('⌘', 'ArkTS', '#A98BFF', 28, 22)
  this.StarNode('✦', 'ArkUI', '#FF8DBB', 204, 58)
  this.StarNode('◈', 'AI', '#58DBD0', 104, 145)
  this.StarNode('↗', '协同', '#79A8FF', 237, 166)
}

这是一种非常适合毕业生项目的取舍：先用原生组件实现完整视觉和交互，再在确有必要时引入 Canvas 或图形引擎。对于只有少量固定节点的场景，Stack 结构更容易调试、适配和维护。

而在能力轨迹列表中，点击卡片会更新 selectedSkill，选中项通过背景和边框突出：

.backgroundColor(this.selectedSkill === index ? '#34204B' : '#211532')
.border({ width: 1,
  color: this.selectedSkill === index ? skill.color : '#49305E' })
.onClick(() => { this.selectedSkill = index; })

这段交互很小，却传递出一个产品态度：能力不是一个静态评分，而是可以被关注、被展开、被持续投入的对象。

图 5：能力轨迹用进度、状态与色彩强调当前优势和下一突破点

图 5：ArkTS 82%、ArkUI 68%、AI 应用 54%、多端协同 39%，数字的意义在于帮助决定优先级，而不是制造排名焦虑。

九、为什么把“作品”放进能力体系，而不是只放在简历末尾

毕业生最容易低估的一项能力是：把做过的项目说清楚。

很多同学的简历有项目名称，但项目介绍只写“使用 ArkTS 和 ArkUI 实现了一个应用”。这不足以证明能力。一个项目应该能够反向映射到技能节点：

AI 智能菜谱
  ├─ ArkTS：接口模型、JSON 解析、异常处理
  ├─ ArkUI：食材输入、结果卡片、详情页面
  ├─ AI 应用：结构化提示词、服务端安全边界
  └─ 工程能力：构建、模拟器验证、状态管理

跨屏演讲台
  ├─ ArkUI：手机遥控器与大屏展示
  ├─ 多端协同：共享演讲状态、任务角色拆分
  └─ 产品设计：不同设备各司其职

这样，作品集不再是一堆截图，而是一组能力证据。Skill Path 首页中的“3 个作品沉淀”就是这个思路的入口：未来可为每个技能节点关联项目、代码片段、技术文章、构建记录和复盘笔记。

这也是“毕业生的鸿蒙特点”之一：不只是学习 API，而是在毕业设计、创新赛、社团项目、实习任务中，把技术能力做成真实可运行的应用，再通过文章和作品集将过程讲出来。

十、AI 成长教练：AI 不是替毕业生规划人生，而是帮助收敛下一步

计划页是项目中最容易被误解为“AI 万能规划”的部分。实际上，AI 成长教练的目标非常克制：它不替用户决定职业，不生成空泛鸡汤，而是根据已知的能力缺口、目标岗位、已有作品，给出一周内可执行的建议。

图 6：目标岗位卡将泛泛的“找工作”收敛为 HarmonyOS AI 应用开发工程师的具体能力方向

图 6：目标岗位不是一句标题，而是后续技能筛选、任务排序和作品打磨的依据。

页面当前包含三个关键输入：

目标岗位：HarmonyOS AI 应用开发工程师；
已有能力：ArkTS、ArkUI、AI 应用；
当前短板：多端协同等进度更低的模块。

点击生成后，应用显示一个 900ms 的分析状态，再呈现建议。当前是端侧本地模拟，目的是完成 UI 和交互验证：

private generatePlan(): void {
  if (this.aiLoading) return;
  this.aiLoading = true;
  setTimeout(() => {
    this.aiLoading = false;
    this.aiPlanVisible = true;
    promptAction.showToast({
      message: '你的 7 天冲刺计划已生成',
      duration: 1400
    });
  }, 900);
}

生成结果强调具体行动：补强多端协同、把 AI 菜谱项目整理成作品集案例、用模拟面试检验表达。它比“建议继续学习鸿蒙”更有用，因为每一条都有明确产出。

图 7：AI 冲刺计划把能力缺口、已有作品和面试准备收敛为可执行的下一周策略

图 7：AI 的价值不是给更多信息，而是帮助毕业生从多个待办中找到优先级。

10.1 真实大模型接入应该如何设计

要把本地模拟替换为真实大模型，不能直接在客户端放入密钥。推荐链路是：

HarmonyOS App
    ↓ HTTPS（目标岗位、技能状态、作品摘要）
业务服务端
    ├─ 身份校验与限流
    ├─ 维护提示词模板与版本
    ├─ 调用模型服务
    ├─ 校验结构化响应
    └─ 返回 7 日计划 JSON

请求可定义为：

{
  "targetRole": "HarmonyOS AI 应用开发工程师",
  "skills": [
    { "name": "ArkTS", "progress": 82 },
    { "name": "ArkUI", "progress": 68 },
    { "name": "AI 应用", "progress": 54 },
    { "name": "多端协同", "progress": 39 }
  ],
  "projects": ["AI 智能菜谱", "跨屏演讲台"],
  "availableMinutesPerDay": 60
}

模型响应不要返回长篇散文，应返回端侧可消费的契约：

{
  "summary": "本周优先补强多端协同，并完成一个可展示的作品迭代。",
  "focusSkill": "多端协同",
  "days": [
    { "day": 1, "title": "拆解跨设备状态", "minutes": 40, "output": "状态流图" },
    { "day": 2, "title": "实现响应式布局", "minutes": 60, "output": "可运行页面" }
  ],
  "portfolioAction": "为 AI 智能菜谱补充结构化输出和异常兜底说明"
}

端侧根据 JSON 渲染行动轨迹；服务端控制模型、密钥和内容策略；AI 负责基于输入提出候选计划。这是 AI 应用最稳妥的分工：模型给建议，系统保证结构，用户保留决定权。

十一、7 日行动轨迹：让计划必须落到产出

任何计划如果没有时间维度和输出定义，最后都只是“看起来很努力”。因此，Skill Path 的计划页将一周拆成按日推进的轨迹：

this.TrackRow('DAY 01', 'ArkUI 自适应布局', '已完成', true)
this.TrackRow('DAY 02', '作品集项目提炼', '已完成', true)
this.TrackRow('DAY 03', '多端状态同步练习', '今天', false)
this.TrackRow('DAY 04', 'AI 接口异常兜底', '明天', false)
this.TrackRow('DAY 05', '模拟面试与复盘', '待解锁', false)

图 8：7 日行动轨迹将学习、作品完善、工程异常处理和模拟面试串成连续闭环

图 8：一条合格的成长计划必须同时包含学习、动手、沉淀和表达。

这条轨迹刻意没有把七天都塞满课程，而是覆盖四种不同性质的任务：

学习：理解 ArkUI 自适应布局；
动手：实现多端状态同步练习；
工程化：处理 AI 接口异常兜底；
表达：模拟面试、复盘项目讲法。

对于毕业生来说，最后一项尤其容易被忽略。很多项目直到答辩或面试前才想起来准备讲解，结果无法在有限时间内说清问题、方案、技术难点和结果。把表达纳入技能地图，不是包装，而是开发能力的一部分。

十二、视觉系统：为什么选择“紫粉霓虹”而不是常规教育蓝

成长地图的视觉没有采用传统课程平台常见的蓝白色。原因不是为了“花里胡哨”，而是希望把学习从严肃、被动的任务，转化为更有个人归属感的成长空间。

视觉系统包含几组稳定关系：

角色	颜色	含义
页面基底	`#10091F`	深夜学习、专注和沉浸感
成长主卡	`#332052`	能量、阶段感、个人成就
ArkTS	`#A98BFF`	工程与语言基础
ArkUI	`#FF8DBB`	创意、界面、表达
AI 应用	`#58DBD0`	智能化、连接与未来感
多端协同	`#79A8FF`	设备连接、空间延展

这些颜色不是随机散落在页面中的装饰，而是绑定在 SkillNode 数据中。这样能力卡、星图节点、进度条和选中边框能够使用同一套视觉语义。

同时，深色界面对文字对比度提出更高要求：标题使用接近白色的 #FFF8FF，说明文字使用低饱和浅紫，辅助信息再降一级。毕业生项目常见的视觉问题是“颜色很多，信息层级却不清楚”。解决它的关键不是继续加特效，而是先保证标题、正文、辅助说明、禁用状态之间有稳定的明度差。

十三、从模拟器到构建：一名毕业生如何证明项目“真的能跑”

作品展示不应该停留在设计图或代码截图。Skill Path 已通过 HarmonyOS 工程构建，并安装到模拟器验证交互。构建时使用 DevEco Studio 提供的 SDK、JDK 与 Hvigor：

cd skill-path-demo
unset NODE_OPTIONS
export DEVECO_SDK_HOME="/Applications/DevEco-Studio.app/Contents/sdk"
export JAVA_HOME="/Applications/DevEco-Studio.app/Contents/jbr/Contents/Home"

/Applications/DevEco-Studio.app/Contents/tools/node/bin/node \
  /Applications/DevEco-Studio.app/Contents/tools/hvigor/bin/hvigorw.js \
  --mode module -p module=entry@default -p product=default \
  -p requiredDeviceType=phone assembleHap

产物位置为：

skill-path-demo/entry/build/default/outputs/default/entry-default-unsigned.hap

实际开发中遇到过一个很典型的 API 差异问题：尝试为 Progress 组件链式调用 .strokeWidth() 时，当前 SDK 的 ProgressAttribute 不支持这个属性，ArkTS 编译器会明确报错。最终移除不支持的链式属性，保留 color 与 backgroundColor 完成视觉表达。

这个案例很适合写入毕业生作品复盘：不是为了展示“我没出错”，而是说明我知道如何根据编译错误定位 API 约束、进行最小修改并重新构建验证。真正的工程能力，经常就体现在这些看似普通的细节中。