鸿蒙electron跨端框架PC想法卡片实战：把零散灵感做成能继续展开的卡片流

欢迎加入鸿蒙PC开发者社区，共同打造开发者工具生态：鸿蒙PC开发者社区：https://harmonypc.csdn.net/项目开源地址：https://AtomGit.com/lqjmac/ele-xiangfakapian写想法卡片时，我没有把它当成简单换皮，而是先回到用户动作本身。很多想法还没到完整文章或完整需求的程度，先用卡片收住，后续再判断是否值得展开。它面向的是经常积累标题、观

淼学派对

30人浏览 · 2026-05-23 16:35:23

淼学派对 · 2026-05-23 16:35:23 发布

前言

欢迎加入鸿蒙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 类型

export interface AppItem {
  id: string;
  hook: string;
  mood: string;
  board: number | string;
  note: string;
  nextAction: string;
}

export type AppFilter = 'all' | 'active' | 'archived';

类型保持简单，是为了给卡片留出模糊空间。
灵感不完整，数据结构也不要装得太满。

五、默认卡片要像真实选题

5.1 为什么要写种子数据

默认卡片要像真的选题线索。
如果默认内容只写字段名，用户就看不出 hook、mood、nextAction 之间的关系。

我更愿意让种子卡片满足这三点：

hook 有画面
note 能解释来源
nextAction 能指向下一步创作

5.2 示例数据

export const seedAppItems: AppItem[] = [
  {
    id: 'xiangfa_kapian-001',
    hook: '把白屏排查写成一次工程复盘',
    mood: '清醒',
    board: '内容线索整理',
    note: '从日志里的 so 加载错误切入，讲清楚前端白屏和 native 库问题的区别。',
    nextAction: '整理成技术文章开头',
  },
];

一张真实卡片能同时测试卡片高度、换行、侧栏提示和导出效果。

六、状态层处理收集和推进

6.1 composable 的职责

useNotes.ts 这层我更愿意把它理解成“当前工具的数据服务”。
页面不应该直接处理太多 localStorage、排序和导出拼接。

const STORAGE_KEY = 'xiangfa-kapian';

const items = ref<AppItem[]>(loadItems());
const activeId = ref(items.value[0]?.id ?? '');

function persist() {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(items.value));
}

function loadItems() {
  const raw = localStorage.getItem(STORAGE_KEY);
  return raw ? JSON.parse(raw) : seedAppItems;
}

6.2 本地存储 key 一定要独立

这里的 key 我会明确写成 xiangfa-kapian。
这样做可以避免不同工具之间互相读到旧数据。

本地数据一旦串了，页面看起来像小问题，实际会让调试和截图都变得很难判断。

七、筛选排序让可展开内容浮上来

7.1 computed 更适合承接派生视图

筛选、搜索、排序这些逻辑如果直接写在模板里，很快会让页面变得难读。
我更倾向于让状态层先准备好可展示列表。

const keyword = ref('');
const filter = ref<'all' | 'hook'>('all');

const visibleItems = computed(() => {
  const text = keyword.value.trim().toLowerCase();
  return items.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 复制摘要

function buildAppSummary(item: AppItem) {
  return [
    '# 想法卡片摘要',
    '- hook: ' + item.hook,
    '- mood: ' + item.mood,
    '- board: ' + item.board,
    '- note: ' + item.note,
  ].join('\n');
}

复制摘要的好处是很实际的。
用户不一定每次都要导出文件，有时只是想把当前内容发到聊天窗口或文档里。

十一、桥接层收住桌面动作

11.1 桥接层只暴露稳定动作

页面不应该知道底层是 Electron clipboard，还是 OpenHarmony 侧的能力。
它只需要知道“复制”“导出”“通知”这些动作。

export function useNativeBridge() {
  const api = window.ohosBridge ?? window.electronAPI;

  async function copyText(text: string) {
    if (api?.copyText) return api.copyText(text);
    return navigator.clipboard.writeText(text);
  }

  async function notify(message: string) {
    if (api?.notify) return api.notify(message);
  }

  return { copyText, notify };
}

11.2 为什么要有浏览器兜底

开发阶段经常会直接跑 Vite。
如果没有浏览器兜底，页面调试会被原生环境绑得太死。

十二、导出 Markdown 保留灵感上下文

12.1 导出内容要能独立阅读

导出的 Markdown 不能只是把字段拼起来。
它最好离开应用以后也能被看懂。

function exportAppMarkdown(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 导出动作和通知联动

async function exportCurrent() {
  if (!currentItem.value) return;
  const markdown = exportAppMarkdown(currentItem.value);
  await bridge.copyText(markdown);
  await bridge.notify('想法卡片内容已复制为 Markdown');
}

这样用户完成导出以后能马上得到反馈。

十三、主进程加载保证随手打开

13.1 开发环境和生产环境分开

桌面应用最常见的白屏问题之一，是生产环境还在访问开发服务器。
所以主进程里一定要把加载逻辑分清楚。

const path = require('path');

function resolveRendererUrl() {
  if (process.env.VITE_DEV_SERVER_URL) {
    return process.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: 280px minmax(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-app
npm install
npm run build

15.2 再确认关键文件没有串主题

rg "xiangfa-kapian|/idea-cards|想法卡片" src package.json
rg "TODO|旧标题|测试数据" src

构建通过不代表体验完美，但至少说明当前页面和依赖关系是站得住的。

十六、这版灵卡工具的经验

16.1 先换问题，再换界面

想法卡片最重要的不是页面长什么样，而是它先回答了一个明确问题：很多想法还没到完整文章或完整需求的程度，先用卡片收住，后续再判断是否值得展开。
问题清楚以后，字段、布局和按钮才知道往哪里收。

16.2 哪些东西可以复用

清晰的页面、状态层、桥接层分工
状态层和本地存储节奏
复制、导出、通知这组桌面动作
开发环境与生产环境分开的加载逻辑

16.3 哪些东西不要硬套

旧的数据字段
旧的默认文案
旧的视觉重心
旧的排序规则

十七、后续可以补的创作能力

想法卡片目前已经能承担随手收集和再次展开的基本动作。
真要继续加功能，我会优先从这些方向补：

增加灵感来源字段，区分阅读、项目、聊天、观察
支持卡片合并，把几个线索拼成选题
增加“本周再看”提醒
支持把卡片一键转成文章提纲
给板块增加颜色和轻量排序

这些扩展应该继续保持轻，别把灵感收集变成负担。

十八、发布前做一次卡片检查

发布前我会按下面这张表再扫一遍，尤其确认 主题一致性 和可发布性。

检查项	结果	说明
标题和主题一致	通过	想法卡片实战：把零散灵感做成能继续展开的卡片流
图片存在	通过	保留项目结构图或运行效果图
代码块数量	通过	覆盖类型、状态、组件、桥接、导出、构建
资源链接	通过	保留社区和官方文档入口