鸿蒙electron跨端框架PC想法卡片实战:把零散灵感做成能继续展开的卡片流
前言
欢迎加入鸿蒙PC开发者社区,共同打造开发者工具生态:鸿蒙PC开发者社区 :https://harmonypc.csdn.net/
项目开源地址:https://AtomGit.com/lqjmac/ele-xiangfakapian
写 想法卡片 时,我没有把它当成简单换皮,而是先回到用户动作本身。
很多想法还没到完整文章或完整需求的程度,先用卡片收住,后续再判断是否值得展开。
它面向的是经常积累标题、观察、金句、选题和内容线索的人。
想法卡片不适合写得像任务管理工具。
它更像一张暂存台:先把一句话、一个标题、一个观察放住,等它有价值时再继续展开。
一、先接受灵感是不完整的
1.1 想法卡片真正要解决什么
很多想法还没到完整文章或完整需求的程度,先用卡片收住,后续再判断是否值得展开。
灵感最麻烦的地方在于它不完整,如果界面一上来就要求标题、分类、截止时间,反而会让用户懒得记录。
所以第一版我让它保持轻一点:
- 卡片能先记下钩子,不要求马上写成长文
- 用情绪、板块、下一步动作帮助二次判断
- 复制和导出只是辅助,不打断收集节奏
1.2 为什么不做成大而全
灵感类工具特别容易做成“内容中台”,标签、看板、AI 改写、日历提醒全都想加。
但这个项目先不做重流程,因为灵感真正需要的是低阻力入口。
| 设计取舍 | 当前处理 | 原因 |
|---|---|---|
| 卡片钩子 | 保留为第一字段 | 一句话就能建立记忆点 |
| 完整正文 | 不强制填写 | 很多想法一开始没有正文 |
| 下一步 | 单独留字段 | 方便后面判断是否展开 |
| 复杂看板 | 暂时克制 | 第一版避免变成项目管理 |
这样它更像创意收集器,而不是另一套任务系统。
二、文件分工围绕卡片流
2.1 主要文件职责
| 文件 | 职责 | 这篇关注点 |
|---|---|---|
| Home.vue | 安排卡片工作台 | 控制卡堆、编辑区和洞察栏的关系 |
| NoteSidebar.vue | 管卡片入口 | 快速筛选不同板块的灵感 |
| NoteEditor.vue | 写钩子和补充说明 | 让未成形的想法也能被保存 |
| NoteToolbar.vue | 处理卡片动作 | 新建、复制、导出、归档 |
| useNotes.ts | 维护卡片集合 | 本地保存、筛选、当前选中项 |
| useNativeBridge.ts | 衔接剪贴板 | 把卡片快速带到文章或聊天窗口 |
这里的组件边界要轻,卡片工具不适合让用户感觉自己在填复杂表单。
三、整体结构服务再次看见
3.1 页面结构图
想法卡片结构图展示了灵感卡堆、卡片流和右侧洞察信息。
3.2 布局为什么这样分
想法卡片采用的是灵感卡堆 + 卡片流 + 洞察侧栏。
左边像抽屉,中间像桌面,右边像提醒自己“这张卡下一步能做什么”。
| 区域 | 承担的任务 | 设计注意点 |
|---|---|---|
| 灵感卡堆 | 按板块找回卡片 | 标题要短,状态要轻 |
| 卡片流 | 浏览和编辑当前想法 | 留出卡片之间的呼吸感 |
| 洞察侧栏 | 放来源、情绪、下一步 | 只提醒,不催促 |
| 顶部动作 | 新建、复制、导出 | 动作少一点,保持随手记录感 |
它不追求密度,而是让零散想法重新被看见。
四、字段设计要包含来源和阶段
4.1 想法卡片的核心字段
字段越重,灵感越难留下来。
所以这里的字段都围绕“先收住,再判断”。
| 字段 | 含义 | 页面位置 |
|---|---|---|
| id | 卡片标识 | 状态层 |
| hook | 最先抓住人的那句话 | 列表/卡片 |
| mood | 记录当时的感受或语气 | 编辑区 |
| board | 属于哪个创作板块 | 筛选/编辑区 |
| note | 补充背景和线索 | 编辑区 |
| nextAction | 下一步怎么处理这张卡 | 侧栏/导出 |
4.2 TypeScript 类型
exportinterfaceAppItem{id:string;hook:string;mood:string;board:number|string;note:string;nextAction:string;}exporttypeAppFilter='all'|'active'|'archived';类型保持简单,是为了给卡片留出模糊空间。
灵感不完整,数据结构也不要装得太满。
五、默认卡片要像真实选题
5.1 为什么要写种子数据
默认卡片要像真的选题线索。
如果默认内容只写字段名,用户就看不出 hook、mood、nextAction 之间的关系。
我更愿意让种子卡片满足这三点:
- hook 有画面
- note 能解释来源
- nextAction 能指向下一步创作
5.2 示例数据
exportconstseedAppItems:AppItem[]=[{id:'xiangfa_kapian-001',hook:'把白屏排查写成一次工程复盘',mood:'清醒',board:'内容线索整理',note:'从日志里的 so 加载错误切入,讲清楚前端白屏和 native 库问题的区别。',nextAction:'整理成技术文章开头',},];一张真实卡片能同时测试卡片高度、换行、侧栏提示和导出效果。
六、状态层处理收集和推进
6.1 composable 的职责
useNotes.ts这层我更愿意把它理解成“当前工具的数据服务”。
页面不应该直接处理太多 localStorage、排序和导出拼接。
constSTORAGE_KEY='xiangfa-kapian';constitems=ref<AppItem[]>(loadItems());constactiveId=ref(items.value[0]?.id??'');functionpersist(){localStorage.setItem(STORAGE_KEY,JSON.stringify(items.value));}functionloadItems(){constraw=localStorage.getItem(STORAGE_KEY);returnraw?JSON.parse(raw):seedAppItems;}6.2 本地存储 key 一定要独立
这里的 key 我会明确写成xiangfa-kapian。
这样做可以避免不同工具之间互相读到旧数据。
本地数据一旦串了,页面看起来像小问题,实际会让调试和截图都变得很难判断。
七、筛选排序让可展开内容浮上来
7.1 computed 更适合承接派生视图
筛选、搜索、排序这些逻辑如果直接写在模板里,很快会让页面变得难读。
我更倾向于让状态层先准备好可展示列表。
constkeyword=ref('');constfilter=ref<'all'|'hook'>('all');constvisibleItems=computed(()=>{consttext=keyword.value.trim().toLowerCase();returnitems.value.filter(item=>JSON.stringify(item).toLowerCase().includes(text)).sort((a,b)=>String(b.id).localeCompare(String(a.id)));});7.2 排序服务于场景
灵感卡片整理工具里,排序不是“哪个字段容易写就按哪个排”。
它应该服务用户打开应用时最想看到的那批内容。
- 未处理内容优先出现
- 置顶或高优先级内容靠前
- 最近更新内容不要沉底
八、Vue 页面保持卡片节奏
8.1 Home.vue 只做编排
我不希望Home.vue变成所有逻辑的大杂烩。
它更适合负责页面骨架和组件之间的数据传递。
<template> <main class="xiangfa_kapian-page"> <NoteToolbar @create="createItem" @copy="copyCurrent" @export="exportCurrent" /> <section class="workspace"> <NoteSidebar :items="visibleItems" @select="selectItem" /> <NoteEditor :item="currentItem" @update="updateItem" /> </section> </main> </template>8.2 组件之间的边界
| 组件 | 应该知道什么 | 不应该知道什么 |
|---|---|---|
| NoteToolbar | 当前能触发哪些动作 | 具体字段如何存储 |
| NoteSidebar | 列表、筛选、选中项 | 导出 Markdown 细节 |
| NoteEditor | 当前对象字段 | 全局搜索逻辑 |
边界清楚以后,后续改样式和改字段都会轻很多。
九、编辑器要支持补充线索
9.1 不要只留下标题和正文
想法卡片如果只保留标题和正文,就会退回普通记事本。
所以编辑器必须把核心字段摆出来。
<script setup lang="ts"> defineProps<{ item: AppItem | null }>(); const emit = defineEmits<{ update: [item: AppItem] }>(); </script> <template> <form v-if="item" class="editor-form"> <input v-model="item.hook" /> <textarea v-model="item.note" /> </form> </template>9.2 表单不是越多越好
我会优先放能影响用户判断的字段。
辅助字段可以放到右侧信息区,或者只在导出时使用。
十、工具栏围绕复制和整理
10.1 工具栏放哪些按钮
工具栏最容易变成按钮仓库。
想法卡片里我只保留和主流程强相关的动作。
- 新建卡片
- 标记气质
- 归入板块
- 补充观察
- 复制核心句
- 导出卡片
10.2 复制摘要
functionbuildAppSummary(item:AppItem){return['# 想法卡片摘要','- hook: '+item.hook,'- mood: '+item.mood,'- board: '+item.board,'- note: '+item.note,].join('\n');}复制摘要的好处是很实际的。
用户不一定每次都要导出文件,有时只是想把当前内容发到聊天窗口或文档里。
十一、桥接层收住桌面动作
11.1 桥接层只暴露稳定动作
页面不应该知道底层是 Electron clipboard,还是 OpenHarmony 侧的能力。
它只需要知道“复制”“导出”“通知”这些动作。
exportfunctionuseNativeBridge(){constapi=window.ohosBridge??window.electronAPI;asyncfunctioncopyText(text:string){if(api?.copyText)returnapi.copyText(text);returnnavigator.clipboard.writeText(text);}asyncfunctionnotify(message:string){if(api?.notify)returnapi.notify(message);}return{copyText,notify};}11.2 为什么要有浏览器兜底
开发阶段经常会直接跑 Vite。
如果没有浏览器兜底,页面调试会被原生环境绑得太死。
十二、导出 Markdown 保留灵感上下文
12.1 导出内容要能独立阅读
导出的 Markdown 不能只是把字段拼起来。
它最好离开应用以后也能被看懂。
functionexportAppMarkdown(item:AppItem){return['# 想法卡片','','> 由 想法卡片 导出。','## hook',String(item.hook??''),'## mood',String(item.mood??''),'## board',String(item.board??''),'## note',String(item.note??''),'## nextAction',String(item.nextAction??''),].join('\n');}12.2 导出动作和通知联动
asyncfunctionexportCurrent(){if(!currentItem.value)return;constmarkdown=exportAppMarkdown(currentItem.value);awaitbridge.copyText(markdown);awaitbridge.notify('想法卡片内容已复制为 Markdown');}这样用户完成导出以后能马上得到反馈。
十三、主进程加载保证随手打开
13.1 开发环境和生产环境分开
桌面应用最常见的白屏问题之一,是生产环境还在访问开发服务器。
所以主进程里一定要把加载逻辑分清楚。
constpath=require('path');functionresolveRendererUrl(){if(process.env.VITE_DEV_SERVER_URL){returnprocess.env.VITE_DEV_SERVER_URL;}return`file://${path.join(__dirname,'../dist/index.html')}`;}mainWindow.loadURL(resolveRendererUrl());13.2 preload 只注入必要接口
const{contextBridge,ipcRenderer}=require('electron');contextBridge.exposeInMainWorld('electronAPI',{copyText:text=>ipcRenderer.invoke('copy-text',text),notify:message=>ipcRenderer.invoke('notify',message),});接口少一点,维护起来更安心。
十四、卡片样式要有呼吸感
14.1 视觉气质服务使用场景
想法卡片的视觉方向是:暖纸面、轻卡片、保留一点未完成感。
这个判断会影响间距、字号、卡片密度和按钮重量。
.xiangfa_kapian-page{min-height:100vh;display:flex;flex-direction:column;background:#f7f8fb;color:#1f2937;}.workspace{display:grid;grid-template-columns:280pxminmax(0,1fr);gap:16px;min-height:0;}14.2 滚动区要提前处理
桌面应用窗口经常被用户缩小。
如果滚动区没有处理好,内容一多就会挤成一团。
- 左侧列表要能独立滚动
- 编辑区不能把工具栏挤出屏幕
- 右侧信息区要允许内容截断和换行
十五、构建后检查灵感主题
15.1 先确认前端产物能生成
写文章之前,我会先跑一次构建。
这一步很朴素,但能挡住不少低级问题。
cd../../electron_for_harmony/electron-openharmony-vue3-14/ohos_hap/web_engine/src/main/resources/resfile/resources/app/vue-appnpminstallnpmrun build15.2 再确认关键文件没有串主题
rg"xiangfa-kapian|/idea-cards|想法卡片"src package.json rg"TODO|旧标题|测试数据"src构建通过不代表体验完美,但至少说明当前页面和依赖关系是站得住的。
十六、这版灵卡工具的经验
16.1 先换问题,再换界面
想法卡片最重要的不是页面长什么样,而是它先回答了一个明确问题:很多想法还没到完整文章或完整需求的程度,先用卡片收住,后续再判断是否值得展开。
问题清楚以后,字段、布局和按钮才知道往哪里收。
16.2 哪些东西可以复用
- 清晰的页面、状态层、桥接层分工
- 状态层和本地存储节奏
- 复制、导出、通知这组桌面动作
- 开发环境与生产环境分开的加载逻辑
16.3 哪些东西不要硬套
- 旧的数据字段
- 旧的默认文案
- 旧的视觉重心
- 旧的排序规则
十七、后续可以补的创作能力
想法卡片目前已经能承担随手收集和再次展开的基本动作。
真要继续加功能,我会优先从这些方向补:
- 增加灵感来源字段,区分阅读、项目、聊天、观察
- 支持卡片合并,把几个线索拼成选题
- 增加“本周再看”提醒
- 支持把卡片一键转成文章提纲
- 给板块增加颜色和轻量排序
这些扩展应该继续保持轻,别把灵感收集变成负担。
十八、发布前做一次卡片检查
发布前我会按下面这张表再扫一遍,尤其确认主题一致性和可发布性。
| 检查项 | 结果 | 说明 |
|---|---|---|
| 标题和主题一致 | 通过 | 想法卡片实战:把零散灵感做成能继续展开的卡片流 |
| 图片存在 | 通过 | 保留项目结构图或运行效果图 |
| 代码块数量 | 通过 | 覆盖类型、状态、组件、桥接、导出、构建 |
| 资源链接 | 通过 | 保留社区和官方文档入口 |
总结
想法卡片这一版不要求每个想法一开始就成熟。它先把线索放到可回看的卡片里,再让用户判断是否继续展开,这种松弛感很适合选题和创意积累。
这篇我最想保留的是轻盈感。
想法还不成熟时,工具不应该急着把它变成任务;先让它被看见,被保存,再决定是否展开。
如果这篇文章对你有帮助,欢迎点赞👍、收藏⭐、关注🔔,你的支持是我持续创作的动力!
相关资源:
- 鸿蒙PC开发者社区:https://harmonypc.csdn.net/
- OpenHarmony 官网:https://www.openharmony.cn/
