网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

引言

很多团队把鸿蒙应用做成 PC 形态后，都会经历一个看似成功、却隐隐不安的阶段：

• 多窗口已经稳定
• 任务系统已经建立
• 状态与生命周期也趋于统一

从技术指标看，一切都很好。

但从用户真实使用方式看，却总有一种说不出的割裂感：

• 用户频繁在窗口之间来回切换
• 同一件事被拆散在多个任务里
• 操作路径很长，却没有“主线”
• 做完事情后，很难回到刚才的上下文

这时你才会慢慢意识到：

系统已经能“运行任务”， 但还不能真正“承载工作”。

而 PC 软件真正的终点，从来不是任务系统。

而是：

工作流系统。

第一层误解：以为“任务稳定”就是终点

当任务系统刚建立时，团队往往会有一种强烈的完成感：

taskManager.start('editor')
taskManager.start('download')
taskManager.start('chat')

系统确实已经变得：

• 可控
• 可恢复
• 可观测

但很快新的问题会出现，而且不是技术层面的：

用户不知道接下来该做什么。

例如一个真实场景：

1. 打开文件
2. 修改内容
3. 查询资料
4. 与同事讨论
5. 导出结果

在系统里却变成：

• editor 任务
• browser 任务
• chat 任务
• export 任务

每个任务都正确，但整体过程是断裂的。

这说明：

任务解决的是“系统怎么运行”， 而工作流解决的是“用户怎么完成一件事”。

第二层本质：PC 软件真正的运行单位不是任务

移动端的最小单位是：

页面

而传统 App 架构升级后变成：

任务

但在真正的 PC 生产力软件里，最核心的单位其实是：

一条持续推进的工作流。

它有几个关键特征：

• 跨多个任务存在
• 持续很长时间
• 包含上下文记忆
• 可以被中断再恢复

换句话说：

任务是系统视角， 工作流是用户视角。

当两者没有对齐时，就会产生熟悉的感觉：

功能很强，但用起来很累。

第三层断点：为什么没有工作流就无法成为 PC 软件

因为缺少工作流时，系统会出现三个典型症状。

操作路径越来越长

打开窗口 → 找到任务 → 执行一步 → 再切窗口 → 再找状态

用户在做的不是工作，而是在管理系统结构。

上下文不断丢失

• 切个窗口就忘了刚才看到哪
• 过一会儿回来不知道进度
• 多任务并行却没有整体视图

本质原因只有一个：

上下文绑定在任务里，而不是绑定在“这件事”里。

系统无法真正“长期运行”

没有工作流时：

• 任务结束 = 一切结束
• 没有阶段推进
• 没有整体记录

这意味着：

系统只能执行动作，却不能沉淀过程。

第四层跃迁：什么才叫“工作流系统”

工作流不是简单的步骤列表，而是系统对“长期行为”的最小抽象。

工作流身份

type WorkflowId = string

它回答的是：

用户现在在推进哪一件事？

工作流上下文

interface WorkflowContext {
  currentStep: string
  data: object
  updatedAt: number
}

关键变化在于：

上下文从“任务级”上升到“事情级”。

工作流与任务的关系

interface Workflow {
  id: WorkflowId
  tasks: string[]
}

含义非常重要：

任务成为工作流的执行单元，而不再是系统的最高层。

这一步完成后，系统结构发生根本变化：

UI < Task < Workflow

真正的顶层第一次出现。

第五层体验变化：为什么这是终点级能力

当工作流建立后，很多长期困扰 PC 应用的问题会自然消失。

用户不再频繁找窗口

因为系统可以直接回到：

“刚才那件事”

而不是：

“刚才那个窗口”。

多任务开始真正协作

workflow.attach(taskId)

任务之间第一次通过同一目标连接，而不是彼此独立存在。

系统开始具备“记忆感”

工作流天然支持：

• 历史阶段
• 进度恢复
• 长期追踪

这正是所有成熟 PC 生产力软件的共同特征。

第六层现实：为什么大多数项目到不了这里

因为工作流系统有一个非常残酷的门槛：

它不解决任何短期需求。

你很难在需求评审会上说：

“这周我们先做工作流抽象。”

但没有这一层，系统最终一定会进入：

• 功能越多越乱
• 用户越重度越痛苦
• 架构越稳定越难演进

这就是很多“能跑十年”的系统，却始终成不了真正 PC 软件的原因。

总结

任务系统是鸿蒙 PC 架构的起点， 而工作流系统，才是它的终点。

当这一层真正建立时，你跨过的已经不只是技术边界，而是一条更深的分界线：

从“应用软件”，走向“生产力系统”。