网罗开发 （小红书、快手、视频号同名）
大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。
📣 公众号"Swift社区"，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友"fzhanfei"，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！
文章目录
-
- 引言
- 第一层误解：以为"任务稳定"就是终点
- [第二层本质：PC 软件真正的运行单位不是任务](#第二层本质：PC 软件真正的运行单位不是任务)
- [第三层断点：为什么没有工作流就无法成为 PC 软件](#第三层断点：为什么没有工作流就无法成为 PC 软件)
- 第四层跃迁：什么才叫"工作流系统"
- 第五层体验变化：为什么这是终点级能力
- 第六层现实：为什么大多数项目到不了这里
- 总结
引言
很多团队把鸿蒙应用做成 PC 形态后，都会经历一个看似成功、却隐隐不安的阶段：
- 多窗口已经稳定
- 任务系统已经建立
- 状态与生命周期也趋于统一
从技术指标看，一切都很好。
但从用户真实使用方式看，却总有一种说不出的割裂感：
- 用户频繁在窗口之间来回切换
- 同一件事被拆散在多个任务里
- 操作路径很长，却没有"主线"
- 做完事情后，很难回到刚才的上下文
这时你才会慢慢意识到：
系统已经能"运行任务"， 但还不能真正"承载工作"。
而 PC 软件真正的终点，从来不是任务系统。
而是：
工作流系统。
第一层误解：以为"任务稳定"就是终点
当任务系统刚建立时，团队往往会有一种强烈的完成感：
ts
taskManager.start('editor')
taskManager.start('download')
taskManager.start('chat')系统确实已经变得：
- 可控
- 可恢复
- 可观测
但很快新的问题会出现，而且不是技术层面的：
用户不知道接下来该做什么。
例如一个真实场景：
- 打开文件
- 修改内容
- 查询资料
- 与同事讨论
- 导出结果
在系统里却变成：
- editor 任务
- browser 任务
- chat 任务
- export 任务
每个任务都正确，但整体过程是断裂的。
这说明：
任务解决的是"系统怎么运行"， 而工作流解决的是"用户怎么完成一件事"。
第二层本质：PC 软件真正的运行单位不是任务
移动端的最小单位是：
页面
而传统 App 架构升级后变成：
任务
但在真正的 PC 生产力软件里，最核心的单位其实是：
一条持续推进的工作流。
它有几个关键特征：
- 跨多个任务存在
- 持续很长时间
- 包含上下文记忆
- 可以被中断再恢复
换句话说：
任务是系统视角， 工作流是用户视角。
当两者没有对齐时，就会产生熟悉的感觉：
功能很强，但用起来很累。
第三层断点：为什么没有工作流就无法成为 PC 软件
因为缺少工作流时，系统会出现三个典型症状。
操作路径越来越长
text
打开窗口 → 找到任务 → 执行一步 → 再切窗口 → 再找状态用户在做的不是工作，而是在管理系统结构。
上下文不断丢失
- 切个窗口就忘了刚才看到哪
- 过一会儿回来不知道进度
- 多任务并行却没有整体视图
本质原因只有一个：
上下文绑定在任务里，而不是绑定在"这件事"里。
系统无法真正"长期运行"
没有工作流时：
- 任务结束 = 一切结束
- 没有阶段推进
- 没有整体记录
这意味着：
系统只能执行动作，却不能沉淀过程。
第四层跃迁：什么才叫"工作流系统"
工作流不是简单的步骤列表，而是系统对"长期行为"的最小抽象。
工作流身份
ts
type WorkflowId = string它回答的是：
用户现在在推进哪一件事？
工作流上下文
ts
interface WorkflowContext {
currentStep: string
data: object
updatedAt: number
}关键变化在于：
上下文从"任务级"上升到"事情级"。
工作流与任务的关系
ts
interface Workflow {
id: WorkflowId
tasks: string[]
}含义非常重要：
任务成为工作流的执行单元，而不再是系统的最高层。
这一步完成后，系统结构发生根本变化：
text
UI < Task < Workflow真正的顶层第一次出现。
第五层体验变化：为什么这是终点级能力
当工作流建立后，很多长期困扰 PC 应用的问题会自然消失。
用户不再频繁找窗口
因为系统可以直接回到：
"刚才那件事"
而不是：
"刚才那个窗口"。
多任务开始真正协作
ts
workflow.attach(taskId)任务之间第一次通过同一目标连接，而不是彼此独立存在。
系统开始具备"记忆感"
工作流天然支持：
- 历史阶段
- 进度恢复
- 长期追踪
这正是所有成熟 PC 生产力软件的共同特征。
第六层现实：为什么大多数项目到不了这里
因为工作流系统有一个非常残酷的门槛：
它不解决任何短期需求。
你很难在需求评审会上说：
"这周我们先做工作流抽象。"
但没有这一层，系统最终一定会进入：
- 功能越多越乱
- 用户越重度越痛苦
- 架构越稳定越难演进
这就是很多"能跑十年"的系统，却始终成不了真正 PC 软件的原因。
总结
任务系统是鸿蒙 PC 架构的起点， 而工作流系统，才是它的终点。
当这一层真正建立时，你跨过的已经不只是技术边界，而是一条更深的分界线：
从"应用软件"，走向"生产力系统"。