北极星的博客 - 北极星
type: channel
link: https://blog.polaris2333.top/index.php/author/1/
description: 北极星
items: 使用Obsidian搭建个人媒体记录库
items: 痴迷
items: 用 Obsidian 搭建个人 OKR 系统
items: 两个让Obsidian更顺手的辅助skill
items: 如果人生注定要分别，那相遇还有什么意义
items: 自动化将Obsidian的笔记同步到typecho的方案开发
items: 三款 Obsidian-Typecho 同步插件横向对比分析
items: 学习笔记：策划方法论
items: 尘白禁区背包系统反策划案
items: 3D角色移动与跳跃的实现

使用Obsidian搭建个人媒体记录库
type: item
date: 2026-07-28T15:34:00+00:00
description: 使用 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 的笔记语法和 Typech…

痴迷
type: item
date: 2026-07-26T18:47:00+00:00
description: 🎬 痴迷状态想看评分⭐ 7.5上映2025-09-05时长110分钟导演库里·巴克主演迈克尔·约翰斯顿, 印达·纳瓦雷特, 库珀·汤姆林森, 梅根·劳利斯, 安迪·里克特, 黑莉·菲茨杰拉德, 达林·图恩德, 安东尼·帕沃内, 贾斯蒂斯, 安东尼·卡萨比安卡, 克洛伊·布林, 马尔科姆·凯尔纳, 特拉维斯·贝克, 凯尔·布卢门撒尔, 马修·杰克逊, 杰夫·巴克国家美国剧情简介平凡却对爱情抱有执念的青年贝尔（迈克尔·约翰斯顿 饰）在偶然得知小镇传说后，折断了一截禁忌的“心愿柳”许愿，如愿俘获暗恋对象妮基（印达·纳瓦雷特 饰）的心。可随着恋情顺遂展开，他逐渐察觉——被召唤来的并非好运，而是一种依附于欲望本身、缓慢蚕食现实的古老存在。想要的爱越圆满，代价越狰狞。 影片改编自民间禁忌传说“心愿柳”框架。观影感想比较震撼的一部片子，总体评价我认为是非常好看，挺值得一看的作为一部恐怖片，不像其他鬼怪类型的恐怖片，本片基本上以心理恐怖为主，并且我认为渲染的非常到位作为一部恐怖片，可以说是我近几年看的最有恐惧感的，看的最带劲的了有几个方面比较想记录讨论下：一是影片中我注意到的一些有意思的细节，二是什么样的爱情是健康的，三是对于剧情设定的一些发散吧下方剧透注意细节主角和女主的演技都很强看过应该都能看出来女主的演技很强，各种情绪转换表达的非常到位但其实主角的演技也不差，包括开始的时候主角对女主的喜欢，然后使用许愿柳成功之后的窃喜，不可置信，些微的挣扎这些都还不错的比较映像深刻的镜头：- 这一块先展示主角的表情变化，然后展现主角看到的东西，处理的非常不错 主角最后还是成功吞下了药物自杀成功了，算是一个不错的结局，整理逻辑都非常合理，然后有一定的反转对爱情的讨论就算抛开电影中的超现实要素不谈，只看显示中的爱情本身，会发现电影算是对现实中某些情况的极端化很多时候，占有欲过度的爱其实是不健康的其底层原因就是，占有的来源是对自己和关系的不自信，是在用占用来填补自己的缺失感，这样的感情，导向的本质其实不是对关系伙伴的爱，而是满足自己影片中也可以看出来，在许愿柳生效的时候，主角是窃喜的，这是因为他的希望女主爱他的愿望实现了。但其实他自己并没有真的爱与关心女主的情况，他关注的只是自己，哪怕他明知道女主的状况是问题的，自己得到的是通过扭曲他人的意志的来的真正的喜爱导向的应该是希望双方都能向着健康和谐幸福的方向前进的当然，这只能算是我自己的一点不成熟的思考吧放到现实中，很多时候其实我们也基本上都是在满足自己，不过也算是借着这个电影，提醒自己一下，不要为了满足自己而扭曲他人的意愿剧情设定感想这个片子里许愿柳的设定还是挺有意思可以通过许愿来改变别人的意识，从片中的表现来看似乎是有一个另外的存在代替了原来的意识同时还可以直接改变现实物理，凭空变出钱虽然有挺多不合理的地方吧，但还是挺有意思的如果放在中国网文的话，可能会出现使用许愿柳改变世界之类的，让我想起有一本就“大明与新罗马与无限神机”的书

用 Obsidian 搭建个人 OKR 系统
type: item
date: 2026-07-09T17:16:00+00:00
description: 像打游戏一样管理人生——用 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仓库去查看。四、核心灵魂：经验值评分系统好了，前面都是"基础设施"…

两个让Obsidian更顺手的辅助skill
type: item
date: 2026-07-08T17:19:00+00:00
description: 前言我记笔记的方式比较懒散：想到什么写什么，写完了再想着整理。但整理这件事本身很费脑子，尤其是两件事让我特别烦。一是我用 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、整理视频笔记这些事情，交给一个稳定的规则去做，比每次自己临时想一遍要轻松得多。如果你也有类似的烦恼，也许可以试试看。不是照搬我的做法，而是想想自己笔记流程里有哪些步骤是重复、机械、却又不得不做的，把它们固化成规则，后面会省很多事。

如果人生注定要分别，那相遇还有什么意义
type: item
date: 2026-07-08T13:18:00+00:00
description: 生命的意义不在于长度，而在于深度与温度；不在于你拥有什么，而在于你成为了怎样的人，以及你如何点亮他人的生活。我是每一个爱过我的人拼成的马赛克，我的每一拍心跳都有它的来处，所以相遇的意义就是被你改变的那部分我代替了你永远陪在我身边。

自动化将Obsidian的笔记同步到typecho的方案开发
type: item
date: 2026-07-08T12:39:00+00:00
description: 从「找到合适的发布插件」到「干脆自己改一个」，记录如何让 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-Typecho 同步插件横向对比分析
type: item
date: 2026-07-05T04:30:00+00:00
description: 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)❌❌…

学习笔记：策划方法论
type: item
date: 2025-06-26T09:17:00+00:00
description: 策划思维与训练思维方式对比玩家思维只能以玩的角度去对待和评判游戏，什么东西好玩不关心开发逻辑，设计成本群体特征沉浸其中：沉浸于游戏，享受快感，但不思考产生原因自我感受为准：以自我感受为判断，很少换位思考主观判断为准：缺乏理性判断，多用感性思维判断总结：基于个人兴趣爱好玩游戏策划思维从游戏设计者角度去看待游戏，加入更多商业考量和用户体验考量群体特征全局视角：站在上帝视角，全局的整体把握游戏。如系统框架，资源关系图，整体分析等用户体验为准：以设计和满足用户需求，提升用户体验为标准，进行换位思考客观判断为主：遵循客观事实，基于数据和市场调研进行判断，需要理性判断总结：基于专业能力和视角分析游戏策划思维详细内容本质上是一种设计思维，策划是设计工作者思维特征1理性思维 > 感性思维设计思维 > 运营思维产品思维 > 市场思维思维特征2系统思维 > 线性思维 > 发散思维抽象思维 > 灵感思维 > 形象思维综合分析 > 案例分析 > 个体分析如何训练策划思维思维行为习惯模型形成循环：思维影响行为，行为影响习惯，习惯塑造思维行为反馈思维：在实践中打破错误固有思维思维训练：通过有意的训练思维来形成好的思维习惯警惕思维惯性和思维陷阱：保持理性思考，独立思考转换思维技术角度：学会用技术的眼光去看游戏换位思考：用策划的方法论与角度去看一款游戏多做练习多进行实践，多做游戏评测，系统拆解，游戏体验报告，竞品分析报告多做多个游戏的横向对比，加强广度和深度多思考思考为什么，不要急于否定别人的行为不理解的多思考别人为什么这么做多学习没人教的情况下多进行自主的学习学习标准的思考方法，学习常用的方法论

尘白禁区背包系统反策划案
type: item
date: 2025-06-18T18:23:00+00:00
description: 导言网文中的图片较多，网页查看可能较慢，推荐下载完整文档查看：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左侧面板 不透明…

3D角色移动与跳跃的实现
type: item
date: 2025-03-13T03:12:00+00:00
description: 引言在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(f…