北极星的博客 - 技术交流
type: channel
link: https://blog.polaris2333.top/index.php/category/%E6%8A%80%E6%9C%AF%E4%BA%A4%E6%B5%81/
items: 两个让Obsidian更顺手的辅助skill
items: 自动化将Obsidian的笔记同步到typecho的方案开发
items: 三款 Obsidian-Typecho 同步插件横向对比分析
items: 3D角色移动与跳跃的实现
items: 个人博客建站记录

两个让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、整理视频笔记这些事情，交给一个稳定的规则去做，比每次自己临时想一遍要轻松得多。如果你也有类似的烦恼，也许可以试试看。不是照搬我的做法，而是想想自己笔记流程里有哪些步骤是重复、机械、却又不得不做的，把它们固化成规则，后面会省很多事。

自动化将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)❌❌…

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…

个人博客建站记录
type: item
date: 2025-03-11T03:02:00+00:00
description: 引言对于网站相关的技术，我并不算了解。大学期间就学过一个 webapp 的制作课程项目，基本上仅限于了解。所以所有的搭建都是基于可视化，低代码的形式实现的。搭建过程在搭建博客时考虑了几种选择，主要为现在最常见的一些选择：WordPress，Halo，Solo，hexo，typecho，poezite主要参考的教程博客Poezit号称最美博客，确实很好看，但是推荐的服务器性能需求在 1H1G最后考虑到我的学习成本，时间成本都不富裕，选择性能较好，搭建方便，有后端的typecho整体搭建非常方便：使用宝塔面板安装常规环境 Nginx1.21 + PHP7.4 + Mysql5.7再直接部署typecho系统+butterfly主题最后进行简单的设置就部署完成辣头像设置引用博客主题头像需要设置两处：显示在首页的左侧边栏中：主题外观设置——初级设置——头像设置，填写图片地址，请确保这个图片地址是没有防盗链的，最简单方式就是在文章编辑页面右侧附件上传图片可以获得图片地址显示在时光机、评论、右上角顶部的头像处：gravatar（全球通用头像），打开后台——控制台——个人设置，点击左侧的头像，去该网站使用你在个人设置里填写的电子邮箱地址注册账号，并上传头像，typecho的头像会自动更新或者打开var/Typecho/Common.php，找到下面的代码，大概在939行，使用本地图片进行替换博客图片来源要想搭建出好看的博客，合适的文章头图是不可缺少的。个人倾向于使用一些acg相关的动画图片，于是选择去各个图库网址寻找个人使用的二次元图库来源：比较精选，类别也不少https://wallpaper.ur1.fun高清精选，可能质量会过高https://www.someacg.top/各种插画，质量还行https://anime-pictures.net/偏向二游相关，质量挺高的，但是预览有水印次元小镇 – 动漫爱好者分享社区ヽ(✿゜▽゜)ノ二次搭建过程此前的服务器到期了，有段时间没有把网站搭上耽误了一段时间，总算是又把网站搭上了新的服务器和域名因为都放在国内，所有还得走备案流程，只能说备案还是比较麻烦的，没什么经营需求的，其实完全可以放在国外服务器上二次搭建使用1panel面板，php8.1恢复备份的时候出了点问题，数据上似乎有点不兼容，相关的附件文件啥的也全都丢失了应该是因为使用1.3版本的typecho，和之前使用的差了一个版本的原因以后恢复备份的时候最好还是保证使用的环境一样比较好，或者干脆进行整个服务器的备份迁移，单独备份博客的数据再恢复还是比较折腾的