前言
欢迎加入鸿蒙PC开发者社区，共同打造开发者工具生态：鸿蒙PC开发者社区 ：https://harmonypc.csdn.net/
项目开源地址：https://AtomGit.com/lqjmac/ele-dushuzhaji
读书札记这个小工具看起来轻，但真正落地时要先把主路径想清楚。
读书笔记不能只留下书名和几句摘抄，还要留下关键词、观点、进度和后续动作。
它面向的是读完书以后希望还能回看、复用和整理观点的人。
这一篇我想把它写成一次“读完以后怎么留下东西”的小实验。
读书札记不是摘抄仓库，真正有用的是把原文、自己的理解和下一步行动放到一起。
一、先区分摘抄和真正读记
1.1 读书札记真正要解决什么
读书笔记不能只留下书名和几句摘抄，还要留下关键词、观点、进度和后续动作。
很多读书笔记后来没用，不是因为写得少，而是只留下摘抄，没有留下当时为什么摘、以后怎么用。
所以这版读记只抓三件事：
- 书籍信息和阅读进度要能回看
- 摘抄必须配观点，不做单纯搬运
- 导出内容要像一张可以复用的读书卡
1.2 为什么不做成大而全
阅读工具很容易走向复杂书架、统计图和社交分享。
我先把它压回个人读记，因为这才是桌面端最容易长期使用的部分。
| 读记部分 | 当前处理 | 原因 |
|---|---|---|
| 书籍和作者 | 保留 | 读记必须能回到出处 |
| 进度 | 保留 | 方便区分读中、读完和回看 |
| 摘抄与洞察 | 放在同一条记录里 | 避免观点和原文分离 |
| 社交分享 | 不做 | 第一版不把私人阅读变成动态流 |
边界收住以后，这个工具更像个人知识沉淀，而不是读书平台。
二、文件分工对应阅读链路
2.1 主要文件职责
| 文件 | 职责 | 这篇关注点 |
|---|---|---|
| Home.vue | 组织读记工作台 | 把书架、笔记和摘抄预览组合起来 |
| NoteSidebar.vue | 管书目和记录入口 | 快速找回某本书的笔记 |
| NoteEditor.vue | 写摘抄、关键词和洞察 | 承接读书札记最核心的内容 |
| NoteToolbar.vue | 处理读记动作 | 新建、复制读书卡、导出 |
| useNotes.ts | 维护阅读记录 | 本地保存、筛选、当前条目 |
| useNativeBridge.ts | 衔接桌面能力 | 把读书卡复制到文档或聊天窗口 |
组件名可以统一，但读记场景里的职责要讲清楚。
否则读者看不到摘抄、观点、行动之间的关系。
三、整体结构围绕书籍和观点
3.1 页面结构图
读书札记结构图展示了书架、笔记工作区和摘抄预览侧栏。
3.2 布局为什么这样分
读书札记采用的是书架筛选 + 阅读笔记工作区 + 摘抄和关键词侧栏。
它的顺序很像真实阅读回看：先找到书，再看笔记，最后看摘抄和关键词。
| 区域 | 承担的任务 | 设计注意点 |
|---|---|---|
| 书架筛选 | 找到书或主题 | 书名、作者、进度要够清楚 |
| 笔记工作区 | 写摘抄和洞察 | 输入区要适合长句子 |
| 侧栏 | 回看关键词和原文片段 | 不要塞成第二个正文区 |
| 顶部动作 | 复制、导出读书卡 | 方便把观点带到其他写作场景 |
读书笔记需要耐看，不适合太躁的布局。
右侧信息可以丰富，但不能抢走中间的观点输入。
四、字段设计要包含进度和行动
4.1 读书札记的核心字段
字段要让一条读记离开应用以后也能成立。
只摘一句话不够，还要知道它来自哪里、我当时怎么理解。
| 字段 | 含义 | 页面位置 |
|---|---|---|
| id | 读记标识 | 状态层 |
| book | 书名 | 列表/编辑区 |
| author | 作者 | 编辑区 |
| progress | 阅读进度或章节位置 | 列表/侧栏 |
| keywords | 关键词 | 筛选/编辑区 |
| quote | 原文摘抄 | 编辑区/导出 |
| insight | 自己的理解或行动 | 编辑区/导出 |
4.2 TypeScript 类型
exportinterfaceAppItem{id:string;book:string;author:string;progress:number|string;keywords:string;quote:string;insight:number|string;}exporttypeAppFilter='all'|'active'|'archived';这段类型把“原文”和“我的观点”拆开。
这比单纯保存一段 note 更适合后续复用。
五、默认读记要像真实阅读现场
5.1 为什么要写种子数据
读书札记的默认数据要像真实阅读现场。
只写“书名示例”没有意义，最好能看出摘抄和观点如何互相支撑。
我给默认读记定了三个要求：
- 书名和作者真实可读
- 关键词能帮助以后检索
- insight 不是复述原文，而是自己的判断
5.2 示例数据
exportconstseedAppItems:AppItem[]=[{id:'dushu_zhaji-001',book:'系统之美',author:'德内拉·梅多斯',progress:'阅读沉淀',keywords:'反馈回路, 延迟, 系统边界',quote:'系统行为往往来自结构，而不是单个事件。',insight:'做产品复盘时先看结构性原因，再看单次操作失误。',},];真实一点的读记可以更早发现长摘抄换行、关键词展示和导出层级的问题。
六、状态层处理保存和回看
6.1 composable 的职责
useNotes.ts这层我更愿意把它理解成“当前工具的数据服务”。
页面不应该直接处理太多 localStorage、排序和导出拼接。
constSTORAGE_KEY='dushu-zhaji';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 我会明确写成dushu-zhaji。
这样做可以避免不同工具之间互相读到旧数据。
本地数据一旦串了，页面看起来像小问题，实际会让调试和截图都变得很难判断。
七、筛选排序服务观点复用
7.1 computed 更适合承接派生视图
筛选、搜索、排序这些逻辑如果直接写在模板里，很快会让页面变得难读。
我更倾向于让状态层先准备好可展示列表。
constkeyword=ref('');constfilter=ref<'all'|'book'>('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="dushu_zhaji-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.book" /> <textarea v-model="item.keywords" /> </form> </template>9.2 表单不是越多越好
我会优先放能影响用户判断的字段。
辅助字段可以放到右侧信息区，或者只在导出时使用。
十、工具栏围绕复制和导出
10.1 工具栏放哪些按钮
工具栏最容易变成按钮仓库。
读书札记里我只保留和主流程强相关的动作。
- 新增书目
- 记录进度
- 保存摘抄
- 提炼观点
- 复制读书摘要
- 导出阅读笔记
10.2 复制摘要
functionbuildAppSummary(item:AppItem){return['# 读书札记摘要','- book: '+item.book,'- author: '+item.author,'- progress: '+item.progress,'- keywords: '+item.keywords,].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['# 读书札记','','> 由 读书札记 导出。','## book',String(item.book??''),'## author',String(item.author??''),'## progress',String(item.progress??''),'## keywords',String(item.keywords??''),'## quote',String(item.quote??''),'## insight',String(item.insight??''),].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 视觉气质服务使用场景
读书札记的视觉方向是：安静、阅读感、低干扰。
这个判断会影响间距、字号、卡片密度和按钮重量。
.dushu_zhaji-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-15/ohos_hap/web_engine/src/main/resources/resfile/resources/app/vue-appnpminstallnpmrun build15.2 再确认关键文件没有串主题
rg"dushu-zhaji|/reading-notes|读书札记"src package.json rg"TODO|旧标题|测试数据"src构建通过不代表体验完美，但至少说明当前页面和依赖关系是站得住的。
十六、这版读记工具的经验
16.1 先换问题，再换界面
读书札记最重要的不是页面长什么样，而是它先回答了一个明确问题：读书笔记不能只留下书名和几句摘抄，还要留下关键词、观点、进度和后续动作。
问题清楚以后，字段、布局和按钮才知道往哪里收。
16.2 哪些东西可以复用
- 清晰的页面、状态层、桥接层分工
- 状态层和本地存储节奏
- 复制、导出、通知这组桌面动作
- 开发环境与生产环境分开的加载逻辑
16.3 哪些东西不要硬套
- 旧的数据字段
- 旧的默认文案
- 旧的视觉重心
- 旧的排序规则
十七、后续可以补的阅读能力
读书札记现在已经能把摘抄、关键词和个人观点放到同一条记录里。
真要继续加功能，我会优先从这些方向补：
- 增加按书籍、作者、关键词聚合
- 支持摘抄和观点的双栏导出
- 给读完的书增加回看提醒
- 增加观点卡片，方便写文章时复用
- 支持把一组读记整理成阅读报告
读书札记后续不该追求热闹，而要帮助观点慢慢沉下来。
十八、发布前做一次读记检查
发布前我会按下面这张表再扫一遍，尤其确认主题一致性和可发布性。
| 检查项 | 结果 | 说明 |
|---|---|---|
| 标题和主题一致 | 通过 | 读书札记实战：摘抄、观点和行动要能一起留下来 |
| 图片存在 | 通过 | 保留项目结构图或运行效果图 |
| 代码块数量 | 通过 | 覆盖类型、状态、组件、桥接、导出、构建 |
| 资源链接 | 通过 | 保留社区和官方文档入口 |
总结
读书札记这一版把摘抄、观点和行动放在一起。读书笔记不只证明“读过”，还要能在未来某个问题出现时，重新帮人把思路接起来。
读书札记最值得留下的是“摘抄之后我怎么想”。
当原文、关键词和 insight 能一起被保存，读书笔记才不只是读过的证明，而是后续写作和思考的材料。
如果这篇文章对你有帮助，欢迎点赞👍、收藏⭐、关注🔔，你的支持是我持续创作的动力！
相关资源：
- 鸿蒙PC开发者社区：https://harmonypc.csdn.net/
- OpenHarmony 官网：https://www.openharmony.cn/
