使用 Obsidian 搭建个人媒体记录库实际效果：我的媒体库 - 北极星的博客我有个需求挺简单的：看过的动画、电影、书、玩过的游戏，能有个地方统一记下来，最好有个画廊视图能翻看，筛选一下"哪些还没看""哪些评分高"。如果还能自动同步到博客上，就更省事了。于是我在 Obsidian 里搭了一套媒体库系统，顺手写了个同步插件，用下来感觉还不错。这篇聊聊怎么搞的。本地媒体库本身的搭建，主要是参考了这个博主的视频和代码来的：Obsidian如何打造智能图书影视库管理系统，兼顾颜值和实用功能！_哔哩哔哩_bilibili整体思路分两块：Obsidian 本地 — 每种媒体类型一个文件夹，每条记录一个 .md 文件，配合 DataviewJS 写一个画廊概览页，支持筛选、排序、搜索、改状态。同步到博客 — 一个 Obsidian 插件，把本地媒体笔记转成 Typecho 兼容格式，上传图片，推到博客。同时生成一个和本地画廊功能一致的云端画廊页面。架构大概长这样：Obsidian 媒体库 (.md + frontmatter) │ ├─ 本地画廊（DataviewJS，可交互） │ └─ 同步插件 → REST API → Typecho 博客 ├─ 文章（每条媒体一篇） └─ 画廊页（独立页面，纯前端渲染）本地部分：在 Obsidian 里建媒体库文件组织目录结构很简单，按类型分文件夹：媒体库/ ├─ 媒体库概览.md ← 画廊页面 ├─ anime/ ← 动画 ├─ book/ ← 书籍 ├─ movie/ ← 电影 ├─ teleplay/ ← 剧集 ├─ game/ ← 游戏 └─ music/ ← 音乐每条记录是一个 markdown 文件，用 frontmatter 存元数据。以一部动画为例：--- title: 葬送的芙莉莲 type: anime score: 8.8 genre: - 奇幻 - 冒险 tags: - 治愈 - 公路片 datePublished: 2023-09-29 观看状态: 看过✅ 集数: "28" ---不同来源的笔记字段名可能不一样——比如 Douban 插件用 title，Bangumi 插件用 中文名 和 原名。画廊页的脚本做了兼容，会自动映射。画廊概览页这是整个媒体库的门面，基于 DataviewJS 写的。核心功能：筛选栏 — 顶部一排下拉菜单，可以按类型、状态、标签、评分、上映时间、季度、创建时间来筛。所有筛选条件实时生效，状态自动保存到 localStorage，下次打开还在。搜索 — 右上角的搜索框支持多关键词，会在标题、创作者、标签、描述等字段里加权匹配，还能高亮结果。排序 — 按评分、标题、日期升降序，最后一个下拉菜单搞定。卡片网格 — 每条媒体一张卡片，包含：封面图（自动从本地附件或网络 URL 加载）左上角类型图标（🎬🎮📚✨ 一眼分辨）右上角状态标签，点击可以切换（想看 → 在看 → 看过 → 搁置 → 抛弃），自动更新文件 frontmatter左下角发布日期，右下角评分标题（点击跳转到详情页）导演/作者/制作方信息anime 和剧集还会显示进度条（已看/总集数）添加新媒体顶部有个"添加媒体"按钮，点了直接调起 Douban 插件的搜索导入——输入名字就能从豆瓣拉取元数据创建笔记，不用手敲。同步部分：一键推到博客本地记着爽，但有时候想分享，或者想在手机上看。我写了个 Obsidian 插件 media-typecho-sync，配合 Typecho 后端的 RESTful 插件，实现一键同步。同步管理面板点击侧边栏的云上传图标，弹出一个管理面板：面板可以：搜索和筛选 — 按名称搜，按类型/观看状态/同步状态/公开状态筛增量同步 — 只同步本地有改动过的文件（按 mtime 判断）强制同步 — 勾选指定条目强制推送，或者全量重推预览变更 — 先看看哪些文件会被同步，确认无误再推逐条设置公开状态 — 每条媒体可以独立设为公开/隐藏/私有删除已选 — 从云端删掉已同步的文章重建画廊 — 只更新画廊页，不动文章同步过程做了什么点击同步后，插件会：测试连接 → 扫描本地媒体库 → 对比缓存，找改动上传新图片（DJB2 内容哈希去重，同一张图不会传两次）转换格式：Wiki 链接 [使用Obsidian搭建个人媒体记录库](https://blog.polaris2333.top/index.php/archives//) → 普通链接、Callout 块 → HTML、DataviewJS → 静态内容通过 REST API 创建/更新文章，附上封面、摘要、标签、分类重建云端画廊页整个过程在面板底部有实时进度，出错了也一目了然。格式转换要点Obsidian 的笔记语法和 Typecho 的 Markdown 解析不太一样，插件在推送前会自动处理：Obsidian 语法转换结果!xxx.jpg![xxx](远程URL)（图片已上传）别名[别名](博客文章链接)> [!info] 标题 ... `= this.score` frontmatter 对应字段的值dataviewjs 代码块静态 HTML（集数列表、描述等）ep-box 集数标记内联样式（紫色=已看，深灰=未看）云端画廊同步后博客上会自动生成一个独立画廊页面，和 Obsidian 里的体验基本一致——筛选、排序、搜索、卡片展示都在，只是不能修改状态（毕竟是静态页面，没 Obsidian API）。一些细节设计差异检测三种模式：正常模式按 mtime 增量同步；强制模式全量重推；白名单模式只同步选中文件——改了一条笔记只想推这一条，没问题。图片去重双层保险：先按路径匹配缓存，再按 DJB2 内容哈希匹配。同一张图在不同笔记里引用多次，只传一次。集数追踪：anime 的集数数据来自 Bangumi 模板的 ep-box，统计 data-status="2"（已看标记）的数量生成进度条。剧集类也是同理。跨插件兼容：画廊脚本同时兼容 Douban 插件和 Bangumi Sync 插件创建的文件，字段名不同也能正常显示。需要准备什么Obsidian 这边：Obsidian ≥ 1.5.0Dataview 插件（画廊页的核心依赖）Douban 插件或 Bangumi Sync（用来导入元数据，可选但推荐）Typecho 这边：RESTful 插件（提供 API）Butterfly 主题（推荐，画廊和自定义字段支持最好）最后这套方案我从自己用着顺手出发，一点点补齐了筛选、进度、同步、管理面板这些功能。用"Obsidian 做本地数据库 + 画廊做可视化 + 插件做发布"的思路，把记录和分享串起来了。插件代码和 RESTful 后端都在 GitHub 上开源了，有兴趣可以看看。有更好的想法也欢迎交流。bluemoon23333/media-typecho-sync: 将obsidian的媒体库页面同步为typecho的一个独立页面的插件
🎬 痴迷状态想看评分⭐ 7.5上映2025-09-05时长110分钟导演库里·巴克主演迈克尔·约翰斯顿, 印达·纳瓦雷特, 库珀·汤姆林森, 梅根·劳利斯, 安迪·里克特, 黑莉·菲茨杰拉德, 达林·图恩德, 安东尼·帕沃内, 贾斯蒂斯, 安东尼·卡萨比安卡, 克洛伊·布林, 马尔科姆·凯尔纳, 特拉维斯·贝克, 凯尔·布卢门撒尔, 马修·杰克逊, 杰夫·巴克国家美国剧情简介平凡却对爱情抱有执念的青年贝尔（迈克尔·约翰斯顿 饰）在偶然得知小镇传说后，折断了一截禁忌的“心愿柳”许愿，如愿俘获暗恋对象妮基（印达·纳瓦雷特 饰）的心。可随着恋情顺遂展开，他逐渐察觉——被召唤来的并非好运，而是一种依附于欲望本身、缓慢蚕食现实的古老存在。想要的爱越圆满，代价越狰狞。 影片改编自民间禁忌传说“心愿柳”框架。观影感想比较震撼的一部片子，总体评价我认为是非常好看，挺值得一看的作为一部恐怖片，不像其他鬼怪类型的恐怖片，本片基本上以心理恐怖为主，并且我认为渲染的非常到位作为一部恐怖片，可以说是我近几年看的最有恐惧感的，看的最带劲的了有几个方面比较想记录讨论下：一是影片中我注意到的一些有意思的细节，二是什么样的爱情是健康的，三是对于剧情设定的一些发散吧下方剧透注意细节主角和女主的演技都很强看过应该都能看出来女主的演技很强，各种情绪转换表达的非常到位但其实主角的演技也不差，包括开始的时候主角对女主的喜欢，然后使用许愿柳成功之后的窃喜，不可置信，些微的挣扎这些都还不错的比较映像深刻的镜头：- 这一块先展示主角的表情变化，然后展现主角看到的东西，处理的非常不错 主角最后还是成功吞下了药物自杀成功了，算是一个不错的结局，整理逻辑都非常合理，然后有一定的反转对爱情的讨论就算抛开电影中的超现实要素不谈，只看显示中的爱情本身，会发现电影算是对现实中某些情况的极端化很多时候，占有欲过度的爱其实是不健康的其底层原因就是，占有的来源是对自己和关系的不自信，是在用占用来填补自己的缺失感，这样的感情，导向的本质其实不是对关系伙伴的爱，而是满足自己影片中也可以看出来，在许愿柳生效的时候，主角是窃喜的，这是因为他的希望女主爱他的愿望实现了。但其实他自己并没有真的爱与关心女主的情况，他关注的只是自己，哪怕他明知道女主的状况是问题的，自己得到的是通过扭曲他人的意志的来的真正的喜爱导向的应该是希望双方都能向着健康和谐幸福的方向前进的当然，这只能算是我自己的一点不成熟的思考吧放到现实中，很多时候其实我们也基本上都是在满足自己，不过也算是借着这个电影，提醒自己一下，不要为了满足自己而扭曲他人的意愿剧情设定感想这个片子里许愿柳的设定还是挺有意思可以通过许愿来改变别人的意识，从片中的表现来看似乎是有一个另外的存在代替了原来的意识同时还可以直接改变现实物理，凭空变出钱虽然有挺多不合理的地方吧，但还是挺有意思的如果放在中国网文的话，可能会出现使用许愿柳改变世界之类的，让我想起有一本就“大明与新罗马与无限神机”的书
像打游戏一样管理人生——用 Obsidian 搭建个人 OKR 系统前言去年某天，我在 B 站刷到了这样一个视频：都2026了，你还不会用 Obsidian？(终极教程)在此之前，我对 Obsidian 的认知仅仅是"一个有点极客的笔记软件"。我也是从这个视频开始正式使用obsidian的。然后最近看到了这个视频：像打游戏一样科研真的可行吗？我在 Obsidian 里搭了一个万年历系统这个视频提出了一个让我瞬间心动的概念：把人生当成一个 RPG 游戏来经营。每年是大章节，每季度是主线任务，每月是项目进度，每周是具体执行，每天是经验获取。于是，我花了几天时间，在 Obsidian 里搭建了一套完整的个人 OKR 系统。这篇文章，就是我这个系统的完整搭建过程的记录。一、整体架构：从年到天的五层金字塔我的 OKR 系统遵循一个自顶向下的层次结构：年度 OKR（目标愿景） ↓ 季度 OKR（阶段性目标） ↓ 月度 OKR（具体项目及进度） ↓ 周度 OKR（具体执行计划） ↓ 每日日记（时间记录 + 经验值获取）每一层都通过 Obsidian 的 Wiki-link 互相串联，形成一个闭环：年度笔记通过 !月度笔记### 核心事项 汇总全年十二个月的核心进展季度笔记引用年度核心目标，并嵌入该季度三个月的回顾月度笔记嵌入四周的周记推进情况和反思周度笔记嵌入七天的每日总结和小确幸每日日记中嵌入本周 OKR 计划板，做到"每日都清楚自己该做什么"这个结构看起来很复杂，但实际上在 Obsidian 中只需要一套模板就能自动生成。下面我们逐步拆解。二、日历基础：插件与模板2.1 推荐的日历插件首先是日历显示，我推荐使用 Chinese Calendar 插件：DevilRoshan/obsidian-lunar-calendar这是一个更符合中国用户习惯的日历插件，支持农历显示和节假日标注，比原生日历好用很多。然后是 Periodic Notes 插件，它可以配合模板，在创建每周/每月/每季度/每年笔记时自动调用对应的 Templater 模板来生成内容。这是整个系统得以运转的基石——你不需要手动写一堆东西，只需要点一下按钮，对应周期的笔记就自动生成了。2.2 热力图：把经验值可视化经验值是一个数字，单独看没什么感觉。但如果能像 GitHub 的 Contribution 图一样，把每天的经验值变成一个色块，那就能直观地看到自己这一年的状态起伏。我用的是这个插件：vran-dev/obsidian-contribution-graph它在笔记中嵌入一个 contributionGraph 代码块，读取所有日记页面中的"经验值"属性，生成热力图。我把它放在了年度、季度、月度、周度四个层级的笔记顶部，从不同粒度来审视自己的状态。热力图的配置大概是这样的（放在年度笔记中）：title: 年度经验值热力图 graphType: default dataSource: type: PAGE value: "#日记" dateField: type: FILE_NAME format: yyyy-MM-DD countField: type: PAGE_PROPERTY value: 经验值 cellStyleRules: - id: Ocean_a color: "#cae7ecff" min: "1" max: "20" text: 😅 - id: Ocean_b color: "#adccecff" min: "20" max: "30" - id: Ocean_c color: "#8ea6c8ff" min: "30" max: "40" - id: Ocean_d color: "#5d81a1ff" min: "40" max: "50" - id: Ocean_e min: "50" max: "70" color: "#21537fff" - id: Ocean_f min: "70" max: "1000" color: "#04234bff" text: 🥳颜色从浅蓝到深蓝，分数越高颜色越深。每天看一眼，就知道自己这段时间每天的一个状态是怎么样的。三、模板系统：用 Templater 实现自动化Obsidian 自带的 Templates 插件功能有限，核心的模板引擎我使用的是 Templater 插件。它能执行 JavaScript 代码，实现日期计算、变量提取、条件判断等高级功能。具体的模板相关的内容，想了下还是不赘述了，都是比较细碎的一些内容。况且这种模板只适合自己使用，就不放出来了，后面可能会考虑上传到github的仓库，有感兴趣的可以到我的github仓库去查看。四、核心灵魂：经验值评分系统好了，前面都是"基础设施"。真正让这套系统从"普通的 OKR 管理"变成"像打游戏一样管理人生"的，是这套经验值评分系统。4.1 设计理念这套评分系统不是为了给每一天"打分"——高分不代表"今天过得很爽"，低分也不代表"今天是糟糕的一天"。它的核心目标是：客观量化今天有没有向前走。你可能会想：我今天刷了 8 小时短视频，但我很开心啊，为什么不能给高分？答案很简单——因为这套系统的评分规则是你自己定义的。如果你想成为一个更健康、更高效的人，那就把"健康作息"和"专注工作"设计成高分项。如果你觉得娱乐也同样重要，那就给娱乐设计一个合理的曲线。规则是活的，但一旦定下来，就严格客观执行，不给自己的偷懒找借口。这其实借鉴了游戏设计中的一个核心概念：经验值不等于快乐值，经验值等于成长值。4.2 评分维度总览总分由六个维度组成：维度标准分核心逻辑睡眠质量20入睡时间 + 睡眠时长的双 sigmoid 曲线积分工作学习60时长 S 曲线：太少低分，适中高分，超量收益递减兴趣爱好15有工作基础后加分，纯娱乐不加分，过度递减时间记录完整度5记录越完整分越高，允许 2 小时琐事不记录自我评估10用户自己对今日事项推进的主观评价习惯打卡~10完成已勾选的习惯累计得分总分约 100 分，但各维度都是"标准分"，实际分数可以超过。4.3 时间记录：柳比歇夫时间记录法在讲评分算法之前，必须先讲数据来源——时间记录。我采用的是柳比歇夫时间记录法，简单来说就是：把一天中每个时间段做了什么，诚实地记录下来。格式如下：09:00-12:00 【工作】 [项目A][重要] 14:00-15:30 【学习】 [课程B] 16:00-17:30 【运动】 23:00-07:00 【睡觉】格式：HH:MM-HH:MM 【事件名称】标签是可选的，用 [标签名] 表示，紧跟在事件下一行跨午夜的事件（如睡眠）会自动处理记录放在每日日记的「今日时间记录」板块下。每天睡前花 5 分钟回顾一天，填入时间记录，然后点击插件的星星按钮，一键计算今天获得了多少经验值。4.4 评分算法详解4.4.1 睡眠评分：你睡对时间了吗？睡眠评分的核心思想是：不仅要睡得够，还要睡在对的时间。我设计了一个双 sigmoid 函数来刻画"最佳睡眠窗口"：$$ \text{sleepCurve}(x) = 1 + \frac{9}{1 + e^{-5.0(x - 0.50)}} - \frac{9}{1 + e^{-6.0(x - 9.75)}} $$其中 $x$ 是当天的时间（以小时计，0-24）。这个函数在凌晨 0:30 到早上 9:30 之间取值最高（约 10），在其它时间段迅速衰减到接近 1。计算方法：从时间记录中筛选出标记为"睡觉"的事件将这些事件的时间区间进行合并（处理白天补觉等碎片化睡眠）对每个睡眠区间，用辛普森积分法（n=2000 子区间）计算 sleepCurve 下的面积除以"标准睡眠区间"（0:30-9:30）的积分面积，得到比例最终得分 = 睡眠标准分 × 比例这意味着：如果你从晚上 11 点睡到早上 7 点（8 小时，但部分时间在曲线高分区外），得分大概在 16-18 分如果你从凌晨 4 点睡到中午 12 点（同样 8 小时，但全在低分区），得分可能只有 5-8 分如果你的睡眠碎片化严重（多次小睡），合并后也无法拿到高分这个设计非常关键：它不是在惩罚"睡得少"，而是在奖励"睡得规律"。4.4.2 工作学习评分：拒绝内卷，也拒绝摸鱼工作学习时长评分采用另一个 S 型曲线：$$ \text{workCurve}(x) = 7 + \frac{3}{1 + e^{-1.95(x - 2.40)}} - \frac{10}{1 + e^{-3.30(x - 8.49)}} $$这个设计明确传达了一个信号：每天高效工作 6 - 7 小时是最优解，再往上拼命，收益微乎其微，不如去好好休息、发展兴趣。4.4.3 兴趣爱好评分：先完成正事，再享受生活兴趣爱好的评分有一个独特的前置条件：必须先满足工作学习的最低标准。曲线函数（经平移后）：$$ \text{hobbyCurve}(x') = 10 + \frac{2}{1 + e^{-7.12(x' - 0.75)}} - \frac{12}{1 + e^{-9.42(x' - 2.49)}} $$其中 $x' = x$（兴趣时长）。关键机制是工作系数：$$\text{coefficient} = \begin{cases} 1, & \text{工作小时} \geq 6 \\ \frac{\text{工作小时}}{6}, & \text{工作小时} < 6 \end{cases}$$最终分数 = 标准分 × 兴趣曲线积分比例 × 工作系数。这个设计背后的逻辑是：兴趣爱好是人生的调味剂，但不是主菜。在完成该做的事情之后去享受爱好，是值得鼓励的；而逃避正事钻进爱好里，就不应该获得高经验值。4.4.4 时间记录完整度：诚实面对自己这个维度很简单但很重要：$$\text{得分} = \text{标准分} \times \frac{\text{已记录小时数}}{24 - \text{允许琐事小时数}}$$默认允许 2 小时的琐事时间（上厕所、吃饭、发呆等）不需要精确记录。如果你记录了 22 小时，就拿到满分。如果只记录了 12 小时，就只能拿到约一半的分。这个设计鼓励你尽可能完整地记录时间。因为诚实是自我管理的第一步——你无法优化你看不见的东西。4.4.5 自我评估：你对自己今天的推进满意吗？这个维度不需要算法，完全由用户自己填写。在日记的 YAML 前置元数据中，有一个 自我评分 字段：自我评分: 8你根据自己的感受，给今天的事项推进情况打一个主观分。这是对客观数据的补充——有时候一天下来没做什么"工作学习"，但你可能完成了一件困扰很久的事情，或者做了一个重要的决定，这些无法被时间记录捕捉的价值，就通过自我评估来体现。4.4.6 习惯打卡：小习惯，大积累每日日记模板中有一个 Callout 块：> [!success] 习惯打卡 > - [ ] 习惯1 🍭3 > - [x] 习惯2 🍭1插件会解析这个 Callout 块：找到所有 - [x]（已勾选）的习惯识别每行中 🍭 后面的数字累加所有已勾选习惯的分数五、自制插件：一键计算经验值上一节讲了评分算法，但它们不可能手动计算。为此，我vibe coding 了一个 Obsidian 插件，专门用来解析日记中的时间记录并自动计算经验值。5.1 插件功能概览插件名为「每日经验值计算」（Daily Exp Score），开源在：bluemoon23333/my-obsidian-plugins核心功能：一键计算：点击 Ribbon 栏的星星图标或执行命令「计算今日经验值」自动解析：从日记中提取时间记录板块，解析时间事件关键词匹配：根据设置中的关键词，将事件分类为睡眠/工作学习/兴趣爱好六维评分：分别计算六个维度的分数，汇总后写入日记的 YAML 前置元数据Notice 展示：以弹窗形式展示各维度得分明细具体的实现逻辑就是依照前面的分数加成的逻辑来的，就不进行赘述，基本上就是直接把需求和完整的逻辑设计都给AI就行了六、段落级标签聚合：让碎片化思考不再沉没这是我在搭建这套系统时解决的一个很实际的痛点。6.1 问题每天写日记时，经常会在某个时刻写下一些有价值的思考或重要的事件记录。比如：今天突然想明白了一个道理：拖延的本质不是懒，而是对失败 的恐惧。与其等待完美的时机，不如先做 5 分钟看看。 #关键思考但是，日记一天接一天地积累，几个月后你已经有了上百篇日记。你根本不可能回头去一篇一篇翻看，那些曾经闪光的思考就这样沉没在了日记的海洋里。6.2 解决方案我的做法是：用一个特定的标签标记重要的段落，然后在月度/年度笔记中用 Dataview 自动聚合。在月度 OKR 模板中，我放置了这样一段 DataviewJS 代码：// ===== 配置区域 ===== const folder = "生活/OKR/日记"; // 日记文件夹 const fileTag = "2026/07"; // 按月份标签筛选 const keyTag = "关键思考"; // 段落中的标签 let pages = dv.pages(); // 按文件夹筛选 if (folder) { pages = pages.where(p => p.file.path.startsWith(folder + "/")); } // 按文件标签筛选 if (fileTag) { const fullTag = "#" + fileTag; pages = pages.where(p => p.file.etags && p.file.etags.some(t => t === fullTag)); } let total = 0; for (const p of pages) { const tfile = app.vault.getAbstractFileByPath(p.file.path); if (!tfile || tfile.extension !== "md") continue; const content = await app.vault.cachedRead(tfile); const lines = content.split("\n"); const matches = lines.filter(line => line.includes(`#${keyTag}`)); if (matches.length > 0) { dv.header(3, p.file.link); for (const line of matches) { const cleaned = line.replace(new RegExp(`#${keyTag}`, "g"), "").trim(); if (cleaned) dv.paragraph(cleaned); } total += matches.length; } } if (total === 0) { dv.paragraph("未找到包含 #" + keyTag + " 的段落。"); }核心思路：限定搜索范围（日记文件夹 + 文件级月份标签如 #2026/07）遍历所有匹配的日记文件逐行扫描，找到包含 #关键思考 的行去掉标签后，将段落内容展示在月度笔记中在月度笔记中，同样的代码复制了三份，分别聚合 #关键思考、#兴趣发展 和 #人际变化 三个维度。这样当你打开月度 OKR 笔记时，当月的所有重要瞬间就自动呈现在眼前了。6.3 为什么不用 Block Reference？你可能会问：Obsidian 不是有 Block Reference 吗？为什么不直接 !日记^block-id 引用？原因是：手动维护 Block ID 太累了。每天写日记时你要记住给重要的段落手动加上 ^block-id，还要确保不重名，时间一长几乎必然放弃。而 #标签 就自然得多——写下思考时顺手敲一个 #关键思考，零额外心智负担。八、写在最后搭建这套系统花了我不少时间，最大的变化不是"效率提高了多少"，而是我对自己的成长有更确切的感知。以前"工作了一整天"可能只是感觉，现在打开热力图一看，那天经验值 25 分——说明其实大部分时间都在摸鱼。以前觉得"这周状态很差"，打开周记一看，其实完成了不少事情，只是最后两天有点松懈而已。相关资源插件源码与说明：bluemoon23333/my-obsidian-pluginsChinese Calendar 插件：DevilRoshan/obsidian-lunar-calendarContribution Graph 插件：vran-dev/obsidian-contribution-graph入睡灵感视频：都2026了，你还不会用 Obsidian？(终极教程)核心灵感视频：像打游戏一样科研真的可行吗？
前言我记笔记的方式比较懒散：想到什么写什么，写完了再想着整理。但整理这件事本身很费脑子，尤其是两件事让我特别烦。一是我用 Obsidian 配合 Typecho 写博客，每篇文章前面都要填 frontmatter：aliases、分类、tags、概述 这些字段。每次发文前我都得自己盯着空字段想：这篇文章该归到哪一类？tags 怎么取才合适？概述一句话怎么说清楚？填一次还好，文章多了之后，每次都要重新动脑，真的很累。二是看视频学习的时候，我习惯把字幕或者逐字稿复制下来，再整理成笔记。但网上常见的提示词模板大多是通用型的，不是偏重知识类就是偏重新闻类，跟我实际看的视频类型对不上。每次都要改提示词、删不需要的模块、调整输出格式，最后整理出来的笔记还是不尽人意。所以我干脆做了两个 Skill：一个叫 fill-frontmatter，一个叫 video-note。fill-frontmatter：让 frontmatter 自己长出来这个 Skill 的想法很简单：我把文章丢给它，它帮我分析全文主题，然后把空的元数据字段填上。它不会乱填。执行的时候，它会先扫描文章的所有小节标题，给每个小节提取几个关键词，再把这些关键词汇总成主题清单。然后根据主题清单去匹配或生成 aliases、分类、tags、概述。如果某个字段本来已经有值，它就不会覆盖。我比较喜欢它的一点是，它会优先参考我已经在 Typecho 里建好的分类和标签，不会每次都给我造一套新的体系。这样我的笔记库和博客站点的分类标签能保持一致，后面找东西也方便。另外，像 banner、slug、保护密码 这种需要人工判断或包含敏感信息的字段，它会主动跳过，不会自作主张。video-note：把视频文案变成能看的笔记video-note 解决的是另一个问题：视频内容太杂，通用提示词不够用。我在设计它的时候，把视频内容分成了五种类型：知识类、资讯类、故事类、技能/教程类、观点/评论类。每种类型对应一套不同的笔记生成策略。比如知识类会梳理概念、补充术语解释；教程类会拆解步骤、标注注意事项；观点类会提炼论点、梳理论据和反方视角。如果视频同时包含几种类型，它也能处理：先判断主类型，再把次要类型里的一两个核心模块融合进来，并在笔记开头标注这是混合类型。输出格式我也固定下来了：最前面是折叠起来的完整原文，后面才是整理好的笔记正文。这样我既能快速看到重点，又保留了原始素材，以后想回看原文也不会丢。怎么使用这两个 Skill 都是围绕我的 Obsidian 工作流来用的，但用法略有不同。fill-frontmatter 需要先运行一个辅助脚本 get-metas.mjs，从 Typecho 站点拉取已有的分类和标签列表。然后在 Obsidian 里打开要发布的文章，调用 Skill，它会把分析结果填充到 frontmatter 里。填完之后我会快速扫一遍，确认分类和 tags 没问题就完事。video-note 更偏提示词。我在 Obsidian 里新建一个笔记，把视频文案贴进去，然后调用对应的提示词。它会先判断视频类型，再按类型输出结构化的笔记，最后直接写回当前文件。两个都不需要我去记复杂的操作流程，核心目标都是一致的：减少重复思考，让我把精力放在内容本身。最后做这两个 Skill 是觉得笔记工作流里有些步骤本来就不该消耗那么多注意力。填 frontmatter、整理视频笔记这些事情，交给一个稳定的规则去做，比每次自己临时想一遍要轻松得多。如果你也有类似的烦恼，也许可以试试看。不是照搬我的做法，而是想想自己笔记流程里有哪些步骤是重复、机械、却又不得不做的，把它们固化成规则，后面会省很多事。
如果人生注定要分别，那相遇还有什么意义
生命的意义不在于长度，而在于深度与温度；不在于你拥有什么，而在于你成为了怎样的人，以及你如何点亮他人的生活。我是每一个爱过我的人拼成的马赛克，我的每一拍心跳都有它的来处，所以相遇的意义就是被你改变的那部分我代替了你永远陪在我身边。
自动化将Obsidian的笔记同步到typecho的方案开发
从「找到合适的发布插件」到「干脆自己改一个」，记录如何让 Obsidian 里的笔记在保存时自动同步到 Typecho 博客，并在这个过程中把通信协议、字段映射、自动推送和图片上传逐一重构。起点：为什么想要一套笔记到博客的同步方案我的笔记和博客长期分属两个系统。Obsidian 负责日常记录、整理和输出，Typecho 负责把成稿发布出去。理想状态下，写完一篇笔记后，应该只需点一下按钮或者保存文件，文章就出现在博客上。如果后续修改，博客上的版本也应该跟着更新，而不需要再登录后台复制粘贴。这个需求听起来并不复杂，但要把体验做得顺畅，涉及几个问题：发布动作要简单、更新要自动、图片等附件要正确上传、Frontmatter 元数据要能控制文章的标题、分类、标签、状态等字段。再加上一些个人偏好，比如用文件名做标题、用中文命令触发、保存后自动推送，现成的方案很难一次性满足。于是我开始在 GitHub 上找相关项目，最终锁定了两个基础仓库作为二次开发的起点。对现有的Obsidian同步到typecho插件的对比可以看这篇文章：三款 Obsidian-Typecho 同步插件横向对比分析两个原项目obsidian-typecho-publisher：已有的 Obsidian 发布插件skyue/obsidian-typecho-publisher 是一个相对成熟的 Obsidian 插件，功能架构很清晰：通过 XML-RPC 协议与 Typecho 通信，支持读取 Frontmatter、上传图片、转换 Wiki-Link、截断内容，并把文章发布或更新到博客上。插件内部有 PublishService、XmlRpcClient、设置面板、i18n 等模块，整体结构对我非常有参考价值。它的核心流程大致如下：flowchart TB A[Obsidian 笔记文件] --> B[解析 Frontmatter] B --> C[图片上传] C --> D[Wiki-Link 转换] D --> E[内容截断] E --> F[剥离 Frontmatter] F --> G[XML-RPC 发布/更新] G --> H[回写 typecho_postid]但在实际测试中，我发现两个关键问题：一是每次更新文章都会新建一篇，无法实现真正的「更新」；这个问题排查了很久，但都找不到为什么，怀疑是 Typecho 服务端 XML-RPC 的实现存在问题。既然服务端肯定要动，那不如把通信协议一并换掉，从 XML-RPC 迁移到 RESTful API。typecho-plugin-Restful：Typecho 的 RESTful 插件Chen2226/typecho-plugin-Restful 提供了一个 Typecho 的 REST API 扩展，包含文章、页面、分类、标签、评论、文件等端点。它正好可以作为新的服务端基础，让我不用再从零写 API 路由和鉴权。不过原版的端点和字段设计比较通用，并没有针对 Obsidian 发布场景做专门优化。例如文章发布接口只支持 title、text、slug、mid 等少量字段，匹配策略是「slug 优先、title 回退」，没有 cid 精确匹配，也没有状态、密码、评论开关、封面图、摘要等字段。因此服务端也需要做比较大的改动，才能配合新的 Obsidian 插件工作。需求梳理与方案取舍在开始写代码之前，我把需求分成三层：必须有的基础功能、希望优化的体验、未来可能做的扩展。基础功能对 Obsidian 中的单篇笔记执行发布，自动推送到 Typecho。保存文件后自动检测变化并同步更新。本地图片和附件上传到博客，博客正文中的相对路径替换为远程 URL。体验优化用文件名作为文章标题，而不是从 Frontmatter 的别名字段读取。评论开关用 Frontmatter 中的布尔值控制。支持封面图、文章摘要、slug 自动回填、公开状态修改、访问密码、分类与标签自动创建等。标题不一致时二次提醒，避免意外覆盖其他文章。扩展想法通过 AI 快速生成标签元数据。（后面打算通过编写一个skill来实现）从头图或图库中自动选择封面图，不用每次手动去复制图片链接。娱乐影音阅读管理类的特殊页面同步。关于附件管理，我一开始想联动自托管的 obsidian-fast-note-sync 服务，让图片由同步服务管理，博客只引用链接。但这两个服务本身没有为这种场景设计，不修改源码很难打通。权衡之后，还是选择最稳妥的方案：图片随文章一起上传到 Typecho 作为附件。二次开发的整体思路最终方案是「保留 obsidian-typecho-publisher 的交互流程和业务逻辑，把底层通信协议从 XML-RPC 换成 RESTful，再补齐两端缺失的字段和能力」。也就是说，Obsidian 端的用户操作、设置面板、发布流程基本沿用原有设计，但 XmlRpcClient 被完全替换为新的 RestfulClient；Typecho 端则在 Restful 插件基础上扩展发布接口、上传接口和后台配置。flowchart LR subgraph Obsidian O1[main.ts] --> O2[PublishService] O2 --> O3[RestfulClient] end subgraph Typecho T1[Plugin.php] --> T2[Action.php] T2 --> T3[postArticle] T2 --> T4[upload] T2 --> T5[fileList] T2 --> T6[deleteFile] end O3 -.->|JSON REST API| T1下面分别记录服务端和客户端的具体改动。服务端改造：typecho-plugin-Restful服务端基于 Chen2226 的 Restful 插件，版本号升级到 1.3.0。最大的改动是 postArticle 接口的重构，其次是上传接口和后台配置面板。文章发布接口的三级匹配策略原版接口用 slug 或 title 匹配文章，在高频修改场景下容易出错。我把它改成三级回退：如果请求里带了 cid 且大于 0，优先按 cid 精确查询并更新。cid 未命中时，按 authorId + slug 查询。都未命中则新建文章。这样只要 Obsidian 端在 Frontmatter 中保留了 cid，后续更新就不会因为标题或 slug 的变化而错改到其他文章。新增和扩展的字段发布接口从只支持少量字段，扩展为支持完整的文章元数据：字段说明cid文章 ID，0 或未匹配到文章时新建；正整数时优先按 cid 匹配，未命中可回退 slug 匹配created自定义发布时间，Unix 时间戳banner封面图 URL，写入自定义字段 thumbdescription文章摘要 / SEO 描述statuspublish / hidden / password / private / waitingpassword访问密码，仅在 status=password 时生效allowComments0 关闭评论，1 允许评论mid分类 / 标签 ID返回值也做了语义化，例如 {"cid": 45, "type": "add", "slug": "my-post"}，让 Obsidian 端能明确知道是新增还是更新，并回写 slug。上传接口的多格式兼容为了让 Obsidian 插件能以不同方式上传图片，上传接口通过新增的 Util.php 支持三种格式：标准的 multipart/form-data 文件上传。JSON 中的 Uint8Array 字节数组，通过 pack('C*', ...$bytes) 还原为文件。Base64 字符串，包括 data:*;base64,xxx 和纯 base64 两种形式。新增文件管理接口除了上传，还增加了 /api/deleteFile 删除附件、/api/fileList 分页获取附件列表，以及 /api/upgrade 插件自更新接口，方便在后台一键检查并拉取最新代码。CORS 与鉴权调整原版 CORS 要求 Origin 在白名单内，否则不返回 Access-Control-Allow-Origin。但 Obsidian 插件作为非浏览器客户端，通常不会携带 Origin 头。我改成：无 Origin 头时自动允许 *，有 Origin 头时再按白名单校验。这样既保留浏览器的安全限制，又让 Obsidian 客户端能直接调用。鉴权方面，高敏接口默认通过 apiToken 校验，并允许关闭登录校验，让纯 Token 认证场景更易用。后台配置面板的小调整服务端插件的配置面板原本已经比较完整，包含 API 状态开关、CORS 域名、字段隐私过滤、设置项白名单、CSRF 盐值、API Token、高敏接口登录校验以及一键升级按钮。每个 API 开关的说明来自代码注释的中文翻译，并会显示对应的端点路径，例如 GET /api/posts。我主要在这个基础上增加了一个 Butterfly 主题检测提示：检测到 Butterfly 时显示绿色提示，未检测到时显示黄色提示并说明摘要会通过 方式实现。这样用户在配置时就能直观知道 description 字段会如何存储。客户端改造：obsidian-typecho-publisherObsidian 端基于 skyue 的插件，版本号升级到 2.0.0。核心变化是通信协议替换、字段映射调整和自动推送机制的增加。通信协议：XML-RPC → RESTful我删除了 xmlrpc-client.ts，新增 restful-client.ts。新的客户端通过 JSON 与 Typecho 通信，主要调用以下端点：端点用途POST /api/postArticle发表或更新文章POST /api/upload上传图片，使用 base64 JSONGET /api/categories获取分类列表GET /api/tags获取标签列表POST /api/addMetas自动创建缺失的分类或标签GET /api/userList获取用户列表，自动填充 authorIdGET /api/post获取文章详情，用于标题比对POST /api/deleteFile删除附件连接配置与字段映射设置面板删除了 xmlrpcUrl、username、password，改为 apiUrl、apiToken、authorId。authorId 旁边加了「获取用户」按钮，可以自动填充。Frontmatter 字段名也做了统一：原版的 typecho_postid 改为 cid，更符合 Typecho 本身的命名习惯。发布成功后，cid 和 slug 会自动回写到 Frontmatter。标题取值与标题不一致提醒新增 useFilenameAsTitle 选项，开启后文章标题直接取文件名，忽略 Frontmatter 中的 title 和正文第一个 # 标题。关闭时则按「Frontmatter → 正文第一个标题 → 文件名」的优先级取值。另一个安全机制是「标题不一致提醒」：当 cid > 0 且手动推送时，插件会先获取云端文章标题与本地比对，如果不一致会弹窗确认，避免 cid 被意外修改后覆盖到别的文章。自动保存推送这是本次改动里最实用的功能之一。文件保存后，插件会在 3 秒防抖后自动推送。为了避免无意义的重复发布，我加了几个保护：基于 DJB2 哈希对比文件内容，内容没有实质变化时跳过。记录 cid 变化，如果发现 Frontmatter 中的 cid 被改成本地不存在的值，停止自动推送并通知用户。用 autoPublishRunning Set 做并发保护，同一文件不会同时被推送多次。因回写 cid/slug 触发的保存会被识别并跳过。图片上传重构图片上传从 XML-RPC 的 newMediaObject 改为 POST /api/upload。缓存策略从「基于 Vault 相对路径」改为「基于文件内容哈希」，相同内容的图片不会重复上传。上传失败时不会阻断整篇文章的发布，而是弹出单张图片的失败通知并继续处理其余图片。同时也保留了 Cloudflare R2 图床的支持，通过 AWS Signature V4 计算签名，适合想把图片放到独立存储的场景。内容截断重写原版内容截断只能匹配 1-3 级标题，且逻辑比较粗糙。我重写了 markdown-utils.ts 中的截断函数，支持 1-6 级所有标题，并只移除匹配标题及其子内容，后续内容保留。这样可以在发布时去掉某些仅在本地使用的章节，而不影响正文其余部分。Wiki-Link 转换与 i18nWiki-Link 转换现在会排除图片链接 !...，只对普通双链 [[...]] 做替换。其实wikilink转换最好是在Obsidian笔记库里面本身完成统一，而不是上传的时候让插件来转换，目前我的笔记库中的所有链接统一使用markdown格式。设置面板、命令面板、右键菜单等处的触发文字统一改为中文「推送到 Typecho」。i18n 字符串表也做了相应更新，移除 XML-RPC 相关文案，增加 RESTful、自动推送、封面图、摘要、状态、密码、评论开关等新文案。摘要与 SEO 描述字段的透传如果 Frontmatter 中填写了 description 字段，插件会把它同时作为文章摘要和 SEO 描述发送给服务端；如果没有填写，则传空值，不会根据正文自动生成摘要。这个功能只是把用户已经写好的描述同步到博客上，而不是替用户生成。服务端会根据是否安装 Butterfly 主题 做不同处理：检测到 Butterfly 时，把 description 写入 summaryContent 和 desc 等独立字段；未检测到时，则把描述包在一个隐藏 div 中，并在正文开头插入 标记，让普通主题也能通过 Typecho 摘要机制展示概述。具体应该会在文章的正文开头显示概述内容，实际效果未经过测试。修复的两个关键 Bug在改造过程中，顺手修复了原版中比较影响体验的问题。标题截断不生效且只支持 1-3 级标题原版的标题取值逻辑和长标题处理在某些 Frontmatter 配置下会异常，导致截断功能失效。新版本通过 useFilenameAsTitle 和更鲁棒的标题解析解决了这个问题，并把截断范围扩展到 1-6 级标题。同步后的文章无法被解析为 Markdown这个问题与服务端有关。Typecho 在保存正文时，如果没有 标记，可能会把 Markdown 当纯文本处理。我在 postArticle 中自动为正文章 prepend 该标记，确保同步后的文章能被正确渲染为 Markdown。原插件这个问题应该是要在typecho的设置中开启对应的XML的解析 markdown 才行，不过我这边反正不走这个就无所谓了目前的效果完成改造后，日常使用流程大致是这样的：在 Obsidian 中写完一篇笔记，点击 Ribbon 按钮或右键选择「推送到 Typecho」，文章就会发布到博客上，并自动在 Frontmatter 中写入 cid 和 slug。之后只要修改笔记并保存，3 秒后博客上的文章会自动更新。flowchart LR A[Obsidian 保存笔记] --> B{已有 cid?} B -->|是| C[自动更新文章] B -->|否| D[弹窗确认新建] D --> E[发布并回写 cid/slug] C --> F[完成] E --> F现在已支持的功能包括：手动推送与保存后自动推送。用文件名作为标题，或按优先级自动提取标题。Frontmatter 控制分类、标签、状态、密码、评论开关、封面图、摘要。本地图片自动上传并替换 URL，支持内容哈希缓存避免重复上传。Wiki-Link 自动转换为博客链接。标题不一致时二次确认，防止误覆盖。Frontmatter 中的 description 同时作为文章摘要与 SEO 描述透传到博客；Butterfly 主题写入独立字段，其他主题通过 实现摘要。尚未完成的主要是娱乐影音阅读管理类的特殊页面同步，这部分需要更独立的界面和模板处理，计划后续单独实现。一些还可以继续做的事这个方案已经能覆盖我 90% 以上的发布需求，但还有一些想法没做进去：发布时自动获取当前笔记的头图链接，或从图库中随机/手动选择封面图，并回写到 Frontmatter。娱乐影音阅读管理页的文章同步，可能需要隐藏首页显示并做成独立入口。这些暂时列在待办里，等实际使用一段时间后再决定优先级。总结这次二次开发本质上是一次「协议替换 + 字段补齐 + 体验优化」的组合改造。obsidian-typecho-publisher 提供了很好的发布流程骨架，typecho-plugin-Restful 提供了 REST API 基础，我把两者对接起来，并针对自己的使用习惯做了一些调整。项目主要使用AI进行的vibe coding，确实好用，主体部分大概只花了一天就开发完成了。两个二开后的仓库地址如下，如果有类似需求可以参考：Obsidian 插件：bluemoon23333/obsidian-typecho-publisherTypecho 服务端插件：bluemoon23333/typecho-plugin-Restful参考链接skyue/obsidian-typecho-publisher — 原版 Obsidian 发布插件Chen2226/typecho-plugin-Restful — 原版 Typecho RESTful 插件bluemoon23333/obsidian-typecho-publisher — 二开后的 Obsidian 插件bluemoon23333/typecho-plugin-Restful — 二开后的 Typecho 服务端插件haierkeys/obsidian-fast-note-sync — 自托管笔记同步服务
AI生成标注此文章由AI生成，不保证正确性，请注意甄别1. 项目概览对比维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher插件 IDtypechotypecho-publishertypecho-xmlrpc-publisher版本0.1.51.0.41.3.0作者ChenSKYueHans J. Han编程语言TypeScriptTypeScriptJavaScript (纯 JS)代码行数~1200+ (9个文件)~1600+ (7个文件)~535 (单文件)文件数量20 (含配置和资源)16 (含配置和资源)2构建工具esbuildesbuild无 (直接分发)运行时依赖i18next无无最低 Obsidian0.15.01.12.01.5.02. 通信协议对比维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher通信协议RESTful API (自定义)XML-RPC (MetaWeblog API)XML-RPC (MetaWeblog + Blogger API)服务端要求需安装配套插件 Typecho Restful仅需 Typecho 原生 XML-RPC仅需 Typecho 原生 XML-RPC鉴权方式Token (Bearer 风格)用户名+密码用户名+密码JSON vs XMLJSON 请求/响应XML 请求/响应XML 请求/响应API 封装层HttpUtils 类 (get/post)XmlRpcClient 类 (call/newPost/editPost/uploadMedia)XmlRpc 静态工具类 (buildCall/parseResponse)开箱即用❌ 需要额外安装服务端插件✅ 原生 XML-RPC 即可✅ 原生 XML-RPC 即可3. 功能特性对比3.1 核心发布功能功能obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher新建文章✅✅✅更新已有文章❌ (每次都是新建)✅ (通过 typecho_postid)✅ (通过 cid)Frontmatter 自动读取❌✅ (9个字段可映射)✅ (7个字段可映射)Frontmatter 回写✅ (slug/title/tags等)✅ (typecho_postid)✅ (cid/slug/dateCreated等)发布时间处理由服务端决定✅ (从 Frontmatter 读取)✅ (可配置偏移 + 当前时间)Slug 回退策略Hash 自动生成✅ 日期格式模板❌ 留空让 Typecho 生成内容预览✅ (文章摘要 HTML)❌❌发布进度弹窗✅ (Notice)✅ (自定义 Modal + 链接)✅ (Notice)3.2 图片与文件处理功能obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher粘贴图片自动上传✅ (核心特色)❌❌图片上传到图床上传到 RESTful API 服务端✅ R2 (AWS SigV4) + Typecho 附件❌图片上传缓存❌✅ (path→URL 缓存)❌文件管理✅ (上传/删除/复制URL/预览)❌❌批量文件上传✅ (进度条+取消)❌❌Wiki-Link 转换❌✅ (双链 → 博客 URL)❌3.3 文章管理功能功能obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher浏览文章列表✅ (分页+筛选)❌✅ (getRecentPosts)删除文章❌❌✅导入文章到 Obsidian✅ (htmlToMarkdown)❌✅ (含 YAML frontmatter)同步发布时间❌❌✅文章预览✅ (HTML 渲染)❌❌分类/标签树形浏览✅ (层级展开)❌❌管理分类/标签✅ (添加)❌❌3.4 高级特性功能obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisherFrontmatter 类型校验❌✅ (严格校验)❌内容截断❌✅ (按标题)❌ 校验❌✅ (可选)❌多种发布状态❌✅ (publish/draft/pending/private/future)✅ (草稿开关)自定义文章类型❌✅ (post/page)❌国际化✅ i18next✅ 内置双语❌ (仅中文)插件图标✅ (自定义 SVG)✅ (send 图标)❌右侧面板集成✅ (ItemView)❌❌4. 代码质量与架构对比维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher类型安全✅ TypeScript✅ TypeScript❌ JavaScript模块化✅ 9个模块文件✅ 7个模块文件❌ 单文件 (内聚但耦合)设计模式基础分层依赖注入 + 策略模式直接过程式可测试性中等高 (依赖注入)低 (全局状态)代码可维护性中等高中低 (单文件但逻辑清晰)ESLint✅❌❌构建复杂度中等 (esbuild + tsc)中等 (esbuild + tsc)无构建PHP 错误处理N/A (RESTful)✅ (自动清理)❌ (未处理)5. 用户体验对比维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher发布触发方式1种 (Ribbon)4种 (Ribbon/Command/FileMenu/EditorMenu)3种 (3个 Command)是否弹窗编辑✅ (界面丰富)❌ (一键发布)✅ (弹窗编辑)新建/编辑确认❌✅ (弹窗确认)❌ (cid 自动判断)发布后反馈Notice 文字Modal (含链接+统计)Notice 文字学习曲线中等 (配置多)较高 (字段映射+图床)低 (配置简单)安装复杂度高 (需服务端插件)低 (原生 XML-RPC)极低 (2个文件)中文文档✅ (README 中英)✅ (README 中英)❌ (仅 manifest 描述)6. 优劣分析6.1 obsidian-typecho — 优势功能最丰富: 不仅支持发布，还有右侧面板、文件管理、图片粘贴上传、文章预览等 IDE 级功能图片粘贴上传: 独有的"粘贴即上传"功能，是内容创作者最需要的工作流优化RESTful API: JSON 格式更现代，调试更友好，可扩展性更强树形分类/标签: 直观的层级结构展示Slug 映射缓存: 自动化 Slug 管理文件管理: 内置文件上传/删除/复制URL/图片预览功能6.2 obsidian-typecho — 劣势需要服务端插件: 最大门槛 — 必须安装额外的 Typecho 插件，限制了用户群体不支持更新: 每次发布都是新建文章，无法更新已有文章版本较低 (0.1.5): 功能可能不够稳定配置项较多: Host + Token + User 三个配置项，相比另两者更复杂不支持 Frontmatter 自动读取: 需要手动在弹窗中填写元数据无发布状态管理: 无法控制草稿/发布/定时等状态6.3 obsidian-typecho-publisher — 优势功能最完善的 XML-RPC 发布器: 一键发布 + 图片处理 + 双链转换 + 内容截断 + 类型校验开箱即用: 无服务端插件依赖，配置 XML-RPC 即可使用严格的类型校验: 确保 Frontmatter 数据类型正确，避免发布失败Cloudflare R2 图床: 支持专业的外部图床，带有 AWS Signature V4 签名和上传缓存Wiki-Link 转换: 独有的 双链 → 博客 URL 功能，连接 Obsidian 知识图谱与博客内容截断: 可以隐藏草稿、变更日志等私密段落依赖注入架构: 代码质量高，易于测试和扩展丰富的发布入口: Ribbon + Command + FileMenu + EditorMenu进度弹窗: 带成功/失败反馈和可点击的文章链接自动新建/编辑: 通过 typecho_postid 自动区分6.4 obsidian-typecho-publisher — 劣势学习曲线较高: 字段映射、URL 模板、截断标题等配置项较多R2 配置复杂: Cloudflare R2 需要 Account ID/Access Key/Secret Key 等多项凭证无文章管理功能: 无法浏览/删除/导入服务器上的文章无文件管理: 不支持文件上传管理6.5 typecho-xmlrpc-publisher — 优势极简部署: 仅 2 个文件，无需构建，即拷即用纯 JavaScript: 不需要 npm/TypeScript 知识即可修改功能最均衡: 同时支持发布、更新、删除、导入、同步发布时间可配置的 Frontmatter 键: 允许用户自定义所有键名时间偏移: 发布和同步两个独立的时区调整文章管理: 支持删除和导入（含完整 YAML frontmatter）版本最高 (1.3.0): 可能迭代次数最多，相对成熟分类必填校验: 防止无分类的"孤儿"文章6.6 typecho-xmlrpc-publisher — 劣势无类型安全: JavaScript 代码存在运行时类型错误风险代码耦合度高: 单文件包含所有逻辑，可维护性相对较低无图片处理: 不支持图床上传或图片处理无国际化: 仅中文界面无内容转换: 不支持 Wiki-Link 转换、内容截断等高级功能XML 解析脆弱性: PHP 8.x 下可能遇到弃用警告打乱 XML7. 技术栈雷达图式对比 obsidian-typecho obsidian-typecho-publisher typecho-xmlrpc-publisher 功能丰富度 ████████████ ██████████ ██████ 开箱即用度 ██ ████████ ██████████ 代码工程质量 ████████ ████████████ ██████ 类型安全 ████████ ████████████ ██ 部署简易度 ████ ██████ ██████████ 图片处理能力 ██████████ ██████████ ██ 文章管理能力 ██████████ ██ ████████ 发布体验 ██████ ██████████ ████████8. 适用场景推荐选择 obsidian-typecho 如果你:愿意安装服务端插件需要图片粘贴自动上传（文字创作者的核心需求）需要在 Obsidian 内管理 Typecho 文件（上传/删除/预览）需要树形分类/标签浏览偏爱 RESTful API 胜过 XML-RPC需要富功能面板体验选择 obsidian-typecho-publisher 如果你:追求一键发布的极致效率使用 Cloudflare R2 作为图床需要 Wiki-Link → 博客链接 转换需要 Frontmatter 类型严格校验需要内容截断隐藏私密段落重视代码质量和可维护性需要多入口发布 (命令/右键/Ribbon)选择 typecho-xmlrpc-publisher 如果你:追求极简部署（2个文件即用）需要发布 + 更新 + 删除 + 导入全套文章管理需要同步发布时间到本地喜欢在发布前弹窗编辑（标题/标签/分类/发布时间）使用纯 JavaScript 项目，不想引入构建工具需要可配置的 Frontmatter 键名9. 综合评分评分维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher功能完整性⭐⭐⭐⭐⭐ (5/5)⭐⭐⭐⭐ (4/5)⭐⭐⭐ (3/5)易用性⭐⭐⭐ (3/5)⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)代码质量⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)⭐⭐⭐ (3/5)部署难度⭐⭐ (2/5)⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)发布体验⭐⭐⭐ (3/5)⭐⭐⭐⭐⭐ (5/5)⭐⭐⭐⭐ (4/5)服务端兼容⭐⭐ (需要插件)⭐⭐⭐⭐⭐ (原生)⭐⭐⭐⭐⭐ (原生)图片处理⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)⭐ (1/5)可扩展性⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)⭐⭐ (2/5)10. 总结这三款插件代表了三种不同的设计哲学：obsidian-typecho 走的是 "平台化" 路线 — 把 Obsidian 变成一个 Typecho 的管理客户端，功能最丰富但代价是需要服务端插件和更多配置。obsidian-typecho-publisher 走的是 "专业发布" 路线 — 专精于发布链路，在图片处理、双链转换、内容截断等方面做到极致，是三个中发布体验最好的。typecho-xmlrpc-publisher 走的是 "极简实用" 路线 — 用最少的代码实现最核心的功能（发布+管理），部署成本最低，学习曲线最平缓。如果只选一个作为长期使用，obsidian-typecho-publisher 是最均衡的选择。它在功能深度和易用性之间取得了最佳平衡，同时代码质量最高，架构最清晰。但如果你的核心需求是"粘贴图片自动上传"或"文章管理面板"，那么 obsidian-typecho 更适合你。
策划思维与训练思维方式对比玩家思维只能以玩的角度去对待和评判游戏，什么东西好玩不关心开发逻辑，设计成本群体特征沉浸其中：沉浸于游戏，享受快感，但不思考产生原因自我感受为准：以自我感受为判断，很少换位思考主观判断为准：缺乏理性判断，多用感性思维判断总结：基于个人兴趣爱好玩游戏策划思维从游戏设计者角度去看待游戏，加入更多商业考量和用户体验考量群体特征全局视角：站在上帝视角，全局的整体把握游戏。如系统框架，资源关系图，整体分析等用户体验为准：以设计和满足用户需求，提升用户体验为标准，进行换位思考客观判断为主：遵循客观事实，基于数据和市场调研进行判断，需要理性判断总结：基于专业能力和视角分析游戏策划思维详细内容本质上是一种设计思维，策划是设计工作者思维特征1理性思维 > 感性思维设计思维 > 运营思维产品思维 > 市场思维思维特征2系统思维 > 线性思维 > 发散思维抽象思维 > 灵感思维 > 形象思维综合分析 > 案例分析 > 个体分析如何训练策划思维思维行为习惯模型形成循环：思维影响行为，行为影响习惯，习惯塑造思维行为反馈思维：在实践中打破错误固有思维思维训练：通过有意的训练思维来形成好的思维习惯警惕思维惯性和思维陷阱：保持理性思考，独立思考转换思维技术角度：学会用技术的眼光去看游戏换位思考：用策划的方法论与角度去看一款游戏多做练习多进行实践，多做游戏评测，系统拆解，游戏体验报告，竞品分析报告多做多个游戏的横向对比，加强广度和深度多思考思考为什么，不要急于否定别人的行为不理解的多思考别人为什么这么做多学习没人教的情况下多进行自主的学习学习标准的思考方法，学习常用的方法论
导言网文中的图片较多，网页查看可能较慢，推荐下载完整文档查看：https://wwbqh.lanzoum.com/i87w93v16ymd 密码:a7j4文档历史（简要记录文档版本信息）版本时间作者内容说明V1.02025/05/05蓝月亮初稿，包括设计说明与系统介绍V1.12025/05/06蓝月亮填充系统交互缺失，优化部分表述V1.22025/05/08蓝月亮删除图表中冗杂的旁支，简化V1.22025/05/09蓝月亮完成系统主界面的详细功能说明V1.32025/05/10蓝月亮完成详细功能设计至第3章第8节V1.42025/05/11蓝月亮完成详细功能设计全部内容V1.52025/05/12蓝月亮添加其他需求，主要程序属性表日志等修改记录（详细描述重要修改记录信息）：1、填补第一次撰写时漏掉的系统交互，更新思维导图2、删除图表中冗杂的信息目录一、设计说明系统定位设计目的用户体验二、系统介绍系统简要介绍系统思维导图用户体验流程图三、详细设计说明系统入口系统主界面详细功能说明3.1 道具分类存储功能3.2 库存展示功能（武器分页下）3.3 分页切换功能3.4 详细信息展示功能（武器分页下）3.5 过期道具提醒规则后勤分页展示功能说明4.1 库存展示功能4.2 详细信息展示功能补给分页展示功能说明5.1 库存展示功能5.2 详细信息展示功能配件分页展示功能说明6.1 库存展示功能6.2 详细信息展示功能道具分页展示功能说明7.1 库存展示功能7.2 详细信息展示功能道具使用功能说明筛选排序功能说明9.1 原型图9.2 程序逻辑图9.3 筛选排序规则出售功能说明分解合成功能说明四、其他需求程序一、设计说明系统定位背包系统是游戏的基础必备辅助系统，用来存储，展示，使用游戏资源，是游戏资源管理中枢。设计目的用来存储并展示玩家的道具，资源支撑玩法系统，让其他系统的产出与消耗可以对接提供资源转换通道，玩家可以分解与合成部分道具用户体验玩家可以方便检视自己拥有的道具，掌握拥有资源种类数量不同类型道具分页存储，玩家可以方便快速定位目标道具可对资源进行筛选，为玩家的资源管理提供便利增强玩家收集物品与资源规划的成就感二、系统介绍系统简要介绍[!abstract] 系统简介背包系统是游戏中用于管理游戏内资源的重要基础系统，支撑其他玩法系统，方便玩家查看管理拥有的道具，核心功能包括：物品分类存储、物品信息展示、物品筛选排序、道具使用、批量操作系统思维导图用户体验流程图三、详细设计说明系统入口进入方式：游戏主界面右下角点击“背包”按钮其他系统中对接进入，如任务系统相应任务点击“前往”条件判断：通过新手教程，解锁背包系统主界面a. 原型图编号名称作用样式表现1界面标题 字号24，颜色黑色2主界面按钮点击返回主界面 3返回按钮点击返回原界面 4分类标签按钮点击标签切换显示对应库存字号24，颜色白色5分类标签面板存放分类标签按钮滑动效果与6一致6库存展示面板存放库存单元所有库存单元只在指示区域内显示超出部分不显示可以使用鼠标滚轮滑动或者鼠标按住拖动的形式上下滑动面板内容鼠标灵敏度：xx拖动惯性：xx拖动到顶后继续拖动释放有回弹效果7武器物品单元显示库存中一个武器简略信息的方格白色背景，不透明度25%被选中时不透明度100%底层叠加表示星级的渐变颜色图再上层显示武器图标排列：根据默认排序id，从左向右，从上到下，每行排5个垂直固定间距28px8装备该武器角色显示装备该武器的角色的头像 9锁定图标表示该武器被锁定 10武器类型图标表示该武器的类型短横数量表示武器可装配件深色表示配件未装配浅色表示该位置配件已装11武器等阶表示武器的等阶 12武器等级信息栏显示武器的等级字号20，颜色白色，居中13筛选排序功能按钮点击跳出筛选排序弹窗 14出售功能按钮点击出现出售物品功能底部栏 b. UI规范无特殊说明，统一使用xx字体详细功能说明3.1 道具分类存储功能a. 功能说明：其他玩法产出道具奖励时，调用该功能接口，根据道具类型放入对应的背包数据库中的合适位置b. 程序逻辑图道具属性表：参照第4章3.2 库存展示功能（武器分页下）a. 功能说明：在主界面6-库存显示区中罗列库存中的道具，根据道具细分类型，道具状态，来决定道具单元的哪些部件显示与显示的信息b. 程序逻辑图3.3 分页切换功能a. 功能说明：在背包主界面左侧点击4-分类标签，切换到对应分页，刷新库存展示与功能按钮，并播放UI动效b. 程序逻辑图c. 其他样式表现：分类标签按钮动效：点击按钮后多个图层从左向右快速覆盖叠加，具体可见原型图库存面板动效：0.5s内，面板从默认位置下30px处移动到默认位置，透明度从0-1003.4 详细信息展示功能（武器分页下）a. 原型图 编号名称作用样式表现1左侧面板 不透明度75%，有对应背景图片2右侧面板 不透明度50%，白色背景3下方面板 不透明度25%，白色背景4锁定状态按钮点击切换锁定状态：两种不同图标样式表示锁定状态 5锁定状态文字栏根据状态显示“已锁定”或“未锁定”字号18，颜色B4B5BC6装备当前武器角色头像显示装备该武器的角色的头像若无角色装备，则不显示7武器图标显示武器图标 8文字：等级 字号20，颜色B4B5BC9等级数字数字表示：当前等级/当前等级上限字号20，斜杠前数字颜色为黑色，斜杠后B4B5BC，右对齐10当前突破次数图标武器每突破一次会多亮起一格 11武器名称显示武器的名称字号40，颜色黑色，粗体12武器类型图标显示武器的类型与主界面的样式不同，中间无竖杠13武器类型名称 字号18，颜色B4B5BC14获取途径按钮点击后在16-详细信息面板处显示该道具的获取途径字号20，颜色B4B5BC15分隔图标 该图标颜色依据武器星级决定16详细信息面板显示该道具的详细信息可以使用鼠标滚轮或按住拖动形式上下滑动详细信息面板超出面板内容不显示拖动到底后继续拖动释放有回弹效果17武器培养按钮点击后跳转到武器培养界面不透明度75%，按钮颜色7372FC点击后按钮变灰，颜色B4B5BC18按钮图标 图标为圆中一个勾19按钮文字表示该按钮点击后的作用字号30，颜色白色b. 功能说明：在背包武器分页下，点击库存中的一个武器道具单元之后，会弹出面板展示该武器的详细信息，并且可以点击切换武器锁定状态c. 其他样式表现：注：下方样式同样适用其他背包界面的弹出面板样式所有面板外：使用高斯模糊制造朦胧效果面板弹出时动效：面板呈现从上往下刷新式的显示d. 详细信息面板原型图 编号名称作用样式表现1小标题说明下方内容字号18，颜色黑色2伤害类型图标 对应图标，同武器系统3伤害类型说明武器造成伤害类型字号24，颜色黑色4武器属性图标 同武器系统5武器属性名称 字号20，颜色5F647C6武器属性数值 字号24，颜色黑色，右对齐数字格式参照武器装备系统7详细信息面板 8武器技能等阶当前技能等阶/等阶上限字号20，斜杠前颜色黑色，斜杠及之后颜色AAAAAA9武器技能名称 字号20，颜色黑色，居中10武器技能详细描述 字号20，颜色黑色该区域高度可变，随描述内容多少改变描述中出现的数值文字使用橙色11配件图标 同武器系统12配件装备状态横杠颜色表示配件装备状态深色表示该配件位已装备浅色表示该位置未装配配件13武器资料信息 同10一致3.5 过期道具提醒规则a. 原型图 编号名称作用样式表现1界面标题 字号50，颜色白色2道具展示面板存放过期道具格子道具格子只在所示区域内显示超出不显示3数量信息栏展示该过期道具数量字号30，颜色白色，居中4过期道具格子展示过期道具的图标与品质排列：按照默认排序id，从左至右排列，只排一行格子间距固定40px左右对称居中排列5提示信息 字号21，颜色F2F2F2b. 功能说明：进入背包时，检测有期限道具是否过期，若过期则自动从背包删除，并弹出提示界面。c. 程序逻辑图其他样式表现面板弹出时UI动效：通用奖励取得特效，略点击道具格显示详细信息逻辑与在道具分页点击显示道具信息功能一致，略后勤分页展示功能说明4.1 库存展示功能a. 原型图注：原型图中没有标号指出的元件，都与主界面原型图中的样式保持一致 编号名称作用样式表现1库存展示面板展示库存与武器分页6一致2后勤道具单元显示库存中一个后勤简略信息的格子与武器分页7-武器道具单元一致3装备该后勤角色显示装备该后勤的角色头像 4锁定图标表示该武器被锁定 5定制后勤图标表示该后勤为定制后勤 6后勤类型图标 7后勤类型名称说明该后勤的类型字号20，颜色黑色8后勤图标 9后勤等级信息栏显示后勤的等级字号20，颜色白色，居中10下方信息栏放置额外信息的面板白色背景，不透明度25%11后勤套装名称说明该后勤所属的套装字号20，颜色黑色b. 功能说明：在1-库存展示面板中罗列库存中的道具，根据道具细分类型，道具状态，来决定道具单元的哪些部件显示与显示的信息c. 程序逻辑图：4.2 详细信息展示功能a. 原型图注：原型图中没有标号指出的元件，都与武器详细信息展示原型图中的样式保持一致 编号名称作用样式表现1后勤图标显示后勤图标 2后勤等级显示后勤的等级字号24，颜色黑色，居中3后勤名称 字号40，颜色黑色，粗体4后勤类型图标 5后勤类型名称 字号18，颜色B4B5BC6按钮文字表示该按钮点击后的作用字号30，颜色白色，左对齐b. 功能说明：在背包后勤分页下，点击库存中的一个后勤道具单元之后，会弹出面板展示该后勤的详细信息，并且可以点击切换后勤锁定状态c. 详细信息面板原型图注：没有标号的元件，都与武器详细信息展示的d原型图的样式保持一致编号名称作用样式表现1小标题 字号18，颜色7979792后勤属性图标 3后勤属性名称描述后勤属性字号20，颜色黑色4后勤属性数值 字号20，颜色黑色，右对齐数值格式参照武器装备系统5列举符号 使用菱形列举符号6特长词条 五星级后勤有三条特长，其余两条样式与4一致7小队技能描述描述小队的套装效果使用固定的格式字号18，颜色黑色8小队身份说明小队套装名称和后勤类型使用固定格式字号18，颜色黑色补给分页展示功能说明5.1 库存展示功能a. 原型图注：原型图中没有标号指出的元件，都与主界面原型图中的样式保持一致编号名称作用样式表现1补给库存单元显示库存中一个补给道具的方格与武器分页中的6库存格子样式一致2过期时限表示有使用期限道具的过期倒计时左侧一个闹钟标志右侧输出倒计时天数字号20，颜色白色，居中3道具图标显示道具的图标 4数量信息栏输出道具的数量固定位置输出，居中字号20，颜色白色b. 功能说明：在库存展示面板中罗列库存中的道具，根据道具细分类型，道具状态，来决定道具单元的哪些部件显示与显示的信息c. 程序逻辑图5.2 详细信息展示功能a. 原型图注：原型图中没有标号指出的元件，都与武器详细信息展示原型图中的样式保持一致编号名称作用样式表现1补给道具图标 2文字：持有 字号20，颜色A7A9B33道具数量说明当前持有该道具的数量与2一致，颜色黑色，居中4倒计时表示有期限道具的过期倒计时左侧闹钟图标右侧文字显示倒计时字号20，颜色白色，居中5道具名称 字号40，颜色黑色，粗体6文字：道具 字号18，颜色A7A9B37道具详细描述显示道具的详细描述信息排版颜色根据内容确定8道具格子面板自选箱类型补给道具，在面板中展示可选择道具的格子 9道具格子放置可选则道具样式通用于主UI10按钮文字表示该按钮点击后的作用字号30，颜色白色b. 功能说明：在背包补给分页下，点击库存中的一个补给道具单元之后，会弹出面板展示该道具的详细信息，并可以点击使用道具。道具使用功能见第8节。c. 道具格子点击：点击后弹窗展示对应分类的详细信息面板配件分页展示功能说明6.1 库存展示功能a. 原型图注：原型图中没有标号指出的元件，都与主界面原型图中的样式保持一致 编号名称作用样式表现1配件道具单元显示库存中一个配件信息的方格与武器分页中的6库存格子样式一致2配件图标显示配件图标 3适配武器类型图标显示该配件可以装配的武器类型图标 b. 功能说明：在库存展示面板中罗列库存中的配件道具，根据道具类型，道具状态，来决定道具单元显示的信息c. 程序逻辑图6.2 详细信息展示功能a. 原型图注：原型图中没有标号指出的元件，都与武器详细信息展示原型图中的样式保持一致编号名称作用样式表现1配件道具图标 2配件名称 字号40，颜色黑色，粗体3适配武器类型图标表示该配件适配的武器类型 4配件属性词条图标 一种类型的属性对应一个图标5配件属性词条 字号20，颜色5F647C6配件属性数值 数字格式通用于武器系统字号20，颜色黑色，右对齐7配件详细资料说明配件的详细资料信息字号18，颜色黑色，左对齐b. 功能说明：在背包配件分页下，点击库存中的一个配件道具单元之后，会弹出面板展示该配件的详细信息。道具分页展示功能说明7.1 库存展示功能a. 原型图注：原型图中没有标号指出的元件，都与主界面原型图中的样式保持一致 编号名称作用样式表现1道具单元展示道具信息的方格与武器分页中的6库存格子样式一致2道具图标 3数量信息栏显示拥有道具的数量字号20，颜色白色，居中4分解合成按钮点击后弹出分解合成界面 b. 功能说明：在库存展示面板中罗列库存中的道具，根据星级显示对应颜色背景，在对应位置显示数量c. 程序逻辑图：逻辑简单，略7.2 详细信息展示功能a. 原型图注：原型图中没有标号指出的元件，都与武器详细信息展示原型图中的样式保持一致 编号名称作用样式表现1道具图标 2道具数量显示道具数量样式与补给分页详细信息展示一致3文字：道具 样式与补给分页详细信息展示一致4道具细分类型 字号20，颜色黑色5道具详细描述 字号18，颜色黑色b. 功能说明：在背包道具分页下，点击库存中的一个道具单元之后，会弹出面板展示该道具的详细信息。道具使用功能说明a. 功能说明：在背包补给分页中，点击道具单元打开详细信息后，点击下方使用按钮。根据道具类型不同，具有不同的使用效果。主要有三种类型：直接使用，体力兑换，自选箱。b. 程序逻辑图c. 获得道具原型图注：获得道具界面元件与道具过期提醒弹窗界面一致，只有标题文字不同，且通用主UI获得道具界面，具体逻辑略。d. 体力道具数量选择原型图编号名称作用样式表现1底层面板至于最底层，作为弹出窗口的面板白色背景，不透明度25%2一级面板覆盖在底层面板上显示内容的面板白色背景，不透明度50%3体力兑换提示提示兑换多少某个体力道具为多少体力X->兑换道具数量道具名称->当前体力道具名称XX->30倍X数量字号50，颜色黑色，居中4体力道具图标 5兑换符号图标 6体力图标 7体力数量信息栏显示将兑换成的体力数量 8数量减少按钮点击后体力道具使用数量-1点击后下沉效果9体力道具兑换数量显示当前要兑换道具的数量字号30，颜色黑色，居中10数量增加按钮点击后体力道具使用数量+1点击后下沉效果11数量最大按钮点击后体力道具使用数量最大化点击后下沉效果字号30，颜色白色12取消按钮点击后取消兑换，关闭面板按钮颜色555555点击后按钮颜色->F2F2F2，0.5s字号30，颜色白色13确定按钮点击后确认兑换，出现获得道具界面按钮颜色7372FC点击后按钮颜色->F2F2F2，0.5s字号30，颜色白色e. 自选箱选择原型图注：原型图中没有标号指出的元件，都与本节中的体力道具数量选择原型图保持一致编号名称作用样式表现1道具名称 字号40，颜色黑色，居中2被选择道具格 覆盖一层不透明度50%灰色遮罩中间有白色勾子图标3道具格 与主UI样式通用4道具数量信息栏 只有当兑换道具数量>1时显示该信息栏字号20，颜色白色，居中5查看详细按钮点击查看道具的详细信息图标呈放大镜样式筛选排序功能说明9.1 原型图注：原型图中没有标号指出的元件，都与道具使用功能的体力道具选择原型图中的样式保持一致 编号名称作用样式表现1排序规则表示下面的标签为排序规则字号30，颜色黑色2选中排序规则表示当前选中该排序规则点击选中的排序规则会切换升序与降序标签背景颜色8A8BF8，不透明度50%右侧图标箭头向下表示降序文字在去除右侧图标后的空间中居中字号26，颜色白色3未选中排序规则表示未选中的一个排序规则，点击可切换成按照该规则排序背景颜色F2F2F2，不透明度50%字号26，颜色黑色4筛选项目1表示可以筛选的第一种项目与1一致5筛选全部标签选中全部表示不应用当前筛选项目中的分类来筛选库存内容选中与2一致未选中与3一致6筛选细分标签选中表示只展示当前细分类型的库存内容与5一致文字内容过长无法完全显示的滚动循环播放9.2 程序逻辑图9.3 筛选排序规则a. 规则说明排序规则同时只能应用一种，选中状态下再次点击同一标签切换升序降序筛选可以同时选择多个项目多个细分类型，显示逻辑与xlsx表格中的筛选一致b. 默认排序规则默认使用稀有度降序的排序规则，稀有度一致时按照道具id降序排序c. 筛选结果为空时当筛选的结果没有满足的内容，结果为空时，在库存区域文字提示：“暂时没有该类道具”，具体样式如下：d. 武器分页筛选排序标签 排序规则 稀有度等级获取时间 筛选-种类 全部冲锋枪狙击枪霰弹枪手枪突击步枪努双枪·冲锋枪弓 筛选-伤害类型 全部动能高热低温电击特异e. 后勤分页筛选排序标签 排序规则 稀有度等级获取时间 筛选-种类 全部情报后勤医疗后勤整备后勤 筛选-特长 全部爆发能量获取率暴击伤害增幅同调指数最大生命攻击力防御力射击暴击率技能急速常规能量回复速度 筛选-小队 全部星夜花楸希德微光闻风新桃泽虹超视射影钢羽掠影清乐星朗金甲沙叶祖灵极光伊莱心园阿玛纳秋津明夷新叶水穗曙光天岩户领航者凯夫曼梵星摩伊拉芬尼亚底比斯达摩达努精灵布里吉"鸦眼"绿灵"诗人"鬼怪阿尔戈"锻造者"梵音"信使""守梦人"梵灵御守堤丰阿尔斯特 配件分页筛选排序标签 排序规则 稀有度 筛选-武器 全部冲锋枪狙击枪霰弹枪手枪突击步枪努双枪·冲锋枪弓 筛选-配件部位 全部枪口/弩臂镜桥供弹/箭筒挂件扳机握把瞄准器稳定器 g. 道具分页筛选排序标签 排序规则 稀有度 筛选-种类 全部提取物队员培养素材武器培养素材后勤培养素材其他出售功能说明原型图编号名称作用样式表现1被装备不可选格子无法选中格子覆盖遮罩，颜色7F7F7F，不透明度50%角色头像不被覆盖2锁定不可选格子无法选中覆盖遮罩，样式与1一致3已选中格子表示该格子被选中白色背景，不透明4选中图标勾表示该格子被选中勾子图标，格子颜色3040E65返回按钮点击后推出出售功能黑色背景，返回图标6选中批量图标表示该批量选择被开启 7文字：批量选择蓝色及以下品质 字号24，颜色黑色、5E6AE78未选中批量图标表示该批量选择未开启只在后勤分页显示9文字：批量选择紫色品质 只在后勤分页显示字号24，颜色黑色、C27DD910文字：批量选择橙色品质 只在后勤分页显示字号24，颜色黑色、F6BA8911分解所得道具格子 从左至右排列，最多排列8个格子展示通用主UI道具格子样式12已选数量信息栏表示当前已选中的出售道具数量背景颜色D7D7D7字号20，颜色黑色，居中13道具出售按钮点击后出售选中道具背景颜色5C54BC左侧垃圾桶图标字号30，颜色白色功能说明：背包中武器与后勤分页，点击出售按钮后，库存自动按稀有度升序排列，弹出下方功能栏，选择道具完成后点击出售，获得出售奖励。程序逻辑图分解合成功能说明分解界面原型图注：原型图中调整数量的元件功能与样式与道具使用功能中一致，不再标注说明编号名称作用样式表现1界面标题 字号40，颜色黑色，粗体2分解标签按钮点击切换为分解功能被选中的标签按钮背景颜色61626C字号30，颜色白色3合成标签按钮点击切换为合成功能未选中的标签按钮背景颜色ADAEB4字号30，颜色白色4当前选中材料被框住表示选择该材料，默认选中第一项不透明度25%线框，框住5拥有材料数量信息栏 背景样式通用字号24，颜色白色，居中6材料图标 7分解材料名称表示当前要分解的材料的名称字号35，颜色黑色，粗体8材料类型显示当前分解材料的类型字号26，颜色黑色9待分解材料格子 10选择数量信息栏当前选择分解数量/材料总数量背景样式通用字号24，颜色白色11分解获得材料格子 12分解按钮点击后将指定数量材料分解背景颜色功能说明：玩家在背包道具分页中，点击分解合成按钮后，弹出分解合成界面，可以选择数量，将特定材料分解与合成，用于解决武器突破素材不平衡问题。程序逻辑图合成界面原型图四、其他需求程序通用物品属性表（脚本表头）物品属性数据类型说明要求物品IDLong唯一标志游戏内物品的ID物品图标IDString用图标ID链接物品显示的图片物品名称String该物品的名字物品主类型Enum物品所属的主类型，主要有：武器\后勤\补给\配件\道具物品稀有度Enum物品的稀有度，使用星星数量与颜色区别：一星<白色>\二星<绿色>\三星<蓝色>\四星<紫色>\五星<橙色>物品描述String对物品的描述武器物品额外属性表武器属性数据类型说明要求武器类型Enum区分武器的类型，主要有：栓动式狙击枪\半自动狙击枪\泵动霰弹枪\双管霰弹枪\左轮手枪\半自动手枪\冲锋枪\突击步枪\弩\双枪·冲锋枪\弓武器等阶Short重复获得武器可提升等阶，共有1-5阶武器突破次数Short升级到等级上限后武器需要突破提升等级上限，共有1-6次武器等级Int1-80级，每次突破等级上限查看武器属性配置表武器属性多种类型包含多种不同属性，所需数据类型不同，具体在武器系统的属性配置表中查看武器技能描述String支持配置描述中不同等阶等级时的具体数值武器配件栏Enum列举武器可以装配哪些种类的配件，由武器类型决定装备配件IDInt列举武器当前装备的配件的ID，应该要符合配件类型是否锁定Bool表明武器是否处于锁定状态装备角色IDLong表明装备该武器的角色，若无则置空获取途径链接Int列举可以获得该武器的游戏系统的ID，根据ID跳转对应界面后勤物品额外属性表后勤属性数据类型说明要求后勤类型Enum区分后勤的类型，主要有：情报后勤\医疗后勤\整备后勤后勤等级Int1-15级，升级属性查看装备系统属性表所属套装IDInt查看装备系统属性表后勤属性多种类型包含多种不同属性，所需数据类型不同，查看具体在装备系统属性配置表后勤特长属性多种类型同上后勤技能描述String支持配置描述中不同等阶等级时的具体数值是否锁定Bool表明武器是否处于锁定状态是否为定制后勤Bool定制后勤不能重修装备角色IDInt表明装备该武器的角色，若无则置空获取途径链接Int列举可以获得该武器的游戏系统的ID，跳转对应界面补给物品额外属性表补给属性数据类型说明要求是否为体力道具Bool标志体力道具，方便选择数量批量使用是否为自选道具Bool标志自选道具，方便判断是否弹窗选择是否为限时道具Bool标志限时道具，输出倒计时过期时间Time非限时道具则置空获得道具IDInt列举使用后获得的道具获得道具数量Int列举使用后获得道具的数量配件物品额外属性表配件属性数据类型说明要求配件类型Enum区分配件的类型，主要有：枪口/弩臂\镜桥\供弹/箭筒\挂件\扳机\握把\瞄准器\稳定器适配武器类型Enum可以装配在哪种类型的武器上，具体查看武器属性表被装配武器IDLong填写该配件被装配在哪把武器上，若无则置空配件属性多种类型包含多种不同属性，所需数据类型不同，查看具体在装备系统属性配置表获取途径链接Int列举可以获得该武器的游戏系统的ID，跳转对应界面道具物品额外属性表道具属性数据类型说明要求道具类型Enum区分道具的类型，主要有：提取物\队员培养材料\武器培养材料\后勤培养材料\其他获取途径链接Int列举可以获得该武器的游戏系统的ID，跳转对应界面背包数据交互日志记录每次玩家与服务器进行道具数量增减时的日志记录出现告警的背包服务器交互，并进行邮件提醒或其他方式提醒普通日志保留7天，重要日志永久保留数据统计功能每周对全服所有玩家的背包数据进行统计包括关键道具全服拥有量资源全服拥有量，全服消耗资源量等更多内容由运营提出相应需求
引言在Unity3D中实现3D角色移动与跳跃有多种实现方式，以下是三种基础的主要实现方式的对比分析和推荐方案：一、组件对比分析1. Transform组件特点：直接修改坐标位置，无物理模拟优点：完全可控的位移，适合简单机制缺点：需要手动处理碰撞，无法与物理系统互动适用场景：2D游戏或不需要物理交互的简单移动2. Rigidbody组件特点：基于物理引擎的刚体模拟优点：自动处理碰撞和重力支持力和速度控制（AddForce）可实现真实的物理效果（如斜坡滑落）缺点：需要调节质量/阻力参数可能出现"滑冰感"适用场景：需要物理交互的3D游戏（如被爆炸冲击波影响）3. Character Controller特点：专为角色设计的非物理移动组件优点：内置斜坡/台阶处理精确控制移动（Move方法）自带碰撞检测（isGrounded）缺点：需要手动处理重力与跳跃逻辑适用场景：平台跳跃类游戏或需要精细控制角色的场景二、推荐方案通常来讲，对于无需玩家操控的物体使用Rigidbody，对于要配合动画进行玩家操作的角色，推荐组合使用 Character Controller1. 移动控制选择// 使用Character Controller示例代码 public class PlayerController : MonoBehaviour { private CharacterController controller; private float verticalVelocity; private bool isJumping; void Start() { controller = GetComponent<CharacterController>(); } void Update() { // 水平移动 Vector3 moveDirection = new Vector3(Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical")); moveDirection = transform.TransformDirection(moveDirection); moveDirection *= moveSpeed; // 跳跃逻辑 if (controller.isGrounded) { verticalVelocity = -1f; // 微小向下的力保证接地检测 if (Input.GetButtonDown("Jump")) { verticalVelocity = jumpForce; isJumping = true; animator.SetTrigger("Jump"); // 触发跳跃动画 } } else { verticalVelocity -= gravity * Time.deltaTime; isJumping = false; } moveDirection.y = verticalVelocity; controller.Move(moveDirection * Time.deltaTime); } }2. 动画系统实现Animator Controller设置：创建状态机包含：Idle/Run/Jump/Fall等状态使用混合树(Blend Tree)处理不同移动速度的动画过渡添加参数：Speed（Float）、IsGrounded（Bool）、Jump（Trigger）动画参数更新：// 在Update中更新动画参数 animator.SetFloat("Speed", controller.velocity.magnitude); animator.SetBool("IsGrounded", controller.isGrounded);3. 扩展性设计模块化设计：将移动、跳跃、动画控制拆分为独立脚本动作扩展：// 后续可添加新动作（如翻滚） public void PlayRollAnimation() { animator.SetTrigger("Roll"); // 添加位移逻辑... }使用动画层：通过Animator Layer实现不同身体部位的独立动画（如上半身持枪，下半身奔跑）三、Rigidbody与Character Controller最好只择其一一、为什么建议「二选一」？底层冲突机制：CharacterController 通过Move()方法直接修改坐标Rigidbody 通过物理引擎计算位置同时使用会导致两套系统争夺控制权（例如角色卡顿、穿墙）典型冲突表现：// 错误用法示例：同时操作两种组件 void Update() { controller.Move(moveDir); // 直接修改坐标 rigidbody.AddForce(force); // 物理引擎修改坐标 }可能出现：角色移动抽搐/碰撞失效/重力异常官方文档建议："CharacterController does not require a Rigidbody. In fact, having both may cause undefined behavior."—— Unity官方文档二、是否完全不能组合使用？在特定需求下可以有限组合，但需要遵循以下原则：方案1：Rigidbody作为物理接收器// 组件配置： - CharacterController (主移动) - Rigidbody (IsKinematic = true) // 关闭物理位置计算 // 脚本示例： void OnCollisionEnter(Collision other) { if (other.gameObject.CompareTag("Explosion")) { Vector3 force = CalculateExplosionForce(); rigidbody.isKinematic = false; // 临时启用物理 rigidbody.AddForce(force, ForceMode.Impulse); StartCoroutine(ResetKinematic()); } } IEnumerator ResetKinematic() { yield return new WaitForSeconds(1f); rigidbody.isKinematic = true; // 恢复控制器主导 }适用场景：需要临时受外力影响的剧情事件方案2：物理驱动为主// 组件配置： - Rigidbody (约束Rotation) - CustomMovementScript // 通过AddForce实现移动 void FixedUpdate() { if (isGrounded) { rigidbody.AddForce(moveDir * acceleration); } rigidbody.velocity = Vector3.ClampMagnitude(rigidbody.velocity, maxSpeed); }优势：可实现真实的物理交互（如被车撞飞）代价：需要处理惯性带来的"滑冰感"三、CharacterController如何实现重力？完全不需要Rigidbody，通过手动计算实现：public class GravityHandler : MonoBehaviour { private float verticalSpeed; private const float GRAVITY = 9.81f; void Update() { if (controller.isGrounded) { verticalSpeed = -0.5f; // 微小向下力维持接地状态 } else { verticalSpeed -= GRAVITY * Time.deltaTime; } Vector3 move = new Vector3(0, verticalSpeed, 0); controller.Move(move * Time.deltaTime); } }关键点：接地检测依赖controller.isGrounded重力加速度需手动模拟（建议值：2倍真实重力）四、方案选型决策树graph TD A[是否需要与物理对象互动?] --> |是| B[是否要求精确控制?] A --> |否| C[使用纯CharacterController] B --> |是| D[CharacterController + 事件触发物理] B --> |否| E[纯Rigidbody方案] D --> F[如爆炸时临时启用Rigidbody] E --> G[处理惯性/摩擦力参数]五、最佳实践建议基础移动架构：CharacterControllerAnimatorCustomMovementScript (无Rigidbody)// 移动逻辑：void Update() { HandleMovement(); // 使用Move() HandleGravity(); // 手动重力 HandleJump(); // 自定义跳跃}物理交互实现技巧：方案A：通过CharacterController.Move()模拟受力// 受击退效果示例 public void ApplyKnockback(Vector3 force) { StartCoroutine(KnockbackRoutine(force)); } IEnumerator KnockbackRoutine(Vector3 force) { float duration = 0.5f; while (duration > 0) { controller.Move(force * Time.deltaTime); force = Vector3.Lerp(force, Vector3.zero, 0.1f); duration -= Time.deltaTime; yield return null; } }方案B：临时切换物理控制器private bool isPhysicsActive; void Update() { if (!isPhysicsActive) { // 正常CharacterController移动 } } void ActivatePhysics(Vector3 force) { isPhysicsActive = true; controller.enabled = false; rigidbody.isKinematic = false; rigidbody.AddForce(force); }动画融合技巧：// 在Animator中混合物理动画 animator.SetFloat("FallSpeed", verticalSpeed); // 使用动画遮罩层实现上半身不受物理影响 animator.SetLayerWeight(1, 1.0f); // 第1层控制上半身六、各方案性能对比|指标|纯CharacterController|纯Rigidbody|混合方案||-|-|-|-||CPU占用|低（无物理计算）|中高|中||内存占用|低|中|中||物理交互复杂度|需手动实现|自动|按需切换||移动精度|高|中|高||适合场景|平台跳跃/ACT|沙盒/物理游戏|动作RPG|总结你的原始脚本不需要Rigidbody：之前的重力实现完全可以通过手动计算完成，添加Rigidbody是画蛇添足物理需求的正确实现路径：90%的基础功能：纯CharacterController10%的特殊物理需求：通过协程/临时启用Rigidbody实现扩展建议：使用State Pattern管理不同移动状态（行走/跳跃/受击），每个状态独立处理物理需求四、开发细节分离输入与物理响应，详细可以查看后面新出的文档物理参数调节：重力建议值：根据需求调整，太小可能会很飘跳跃力建议值：4-8（根据角色尺寸调整）移动速度建议值：2-6 m/s动画衔接优化：在动画状态过渡中设置合理的Exit Time和Transition Duration使用动画事件触发脚步声/跳跃音效碰撞检测增强：// 添加底部射线检测提高接地判断精度 if (Physics.Raycast(transform.position + Vector3.up * 0.1f, Vector3.down, 0.2f)) { // 接地处理... }输入优化：// 使用Input System Package实现多设备输入支持 PlayerInput playerInput = GetComponent<PlayerInput>(); Vector2 input = playerInput.actions["Move"].ReadValue<Vector2>();