Just E!

sd-forge 用 Krea 2 Pixel Art 生成 sprite 的注意事項與陷阱

2026-10-04T20:31:40.000+08:00

sd-forge 用 Krea 2 Pixel Art 生成 sprite 的注意事項與陷阱

在 sd-forge 用 Krea 2 Pixel Art 製作 sprite 時，最容易被忽略的設定是生成尺寸。生成結果不理想的原因很多：像素格不對、邊緣發糊、細節雜亂，甚至無法生成預期的角色精靈（sprite）風格、角色比例不符合設定。直覺上會先去改提示詞，或判定這組 LoRA 不夠完善。

本文把生成尺寸當作優先排查的除錯方向，而不是斷定它是正確答案或唯一答案。

Model Info

欄位	值
模型標題	Krea 2 Pixel Art
標誌性名稱（檔名）	`k2-pixel32` / `k2-pixel64` / `k2-pixel128`（`.safetensors`）
來源	Civitai
Civitai model id	`2942217`
Civitai model version id	`3331221`（32x32）/ `3331476`（64x64）/ `3331592`（128x128）
網址	civitai.red/models/2942217/krea-2-pixel-art
類型	LoRA
Base Model	Krea 2
作者	`_Envy_`
檔案格式	bf16 SafeTensor，約 70.96 MB / 個

生成尺寸設定

生成 sprite 或 icon 時，寬高固定 320×320。

操作	結果
固定 `320×320`	✅ 正常
1:1 等比放大	❌ 破壞生成效果
1:1 等比縮小	❌ 破壞生成效果
改變比例（例：減少寬度、高度不變）	✅ 可接受

關鍵在於等比縮放這個動作本身，而不是最終畫面是否為正方形。需要微調構圖比例時，只動單一邊（寬或高），不要等比縮放。

沒有用 LoRA 時：門檻是 768

若不掛這組 LoRA，改以紅潮或黑獸系列模型生成像素風格，規則完全不同：尺寸不可小於 768，否則會出現明顯的劣化與噪點，而且尺寸越小越嚴重（512、320 逐漸加劇）。

比例同樣可以調整，只要不低於 768，例如 512×768。

情境	尺寸	結果
掛 `k2-pixel` LoRA 生成 sprite / icon	`320×320`	✅
不掛 LoRA（紅潮 / 黑獸）生成像素風	≥ `768`，例 `512×768`	✅
不掛 LoRA 且小於 `768`	`512`、`320`	❌ 劣化與噪點，越小越明顯

兩套數字不同，先確認當下有沒有掛 LoRA，再決定生成尺寸。

這些症狀容易誤導排查方向

尺寸不對造成的偏差，外觀上和「提示詞寫得不夠準」或「LoRA 品質不足」幾乎一樣，甚至會被誤認為這組 LoRA 本來就畫不出該風格。固定 320×320 重測一次，就能把尺寸這個變因分離掉，再回頭判斷提示詞。

這是除錯方向，不是唯一答案

固定 320×320 只是成本最低、最容易先排除的一項。若尺寸正確後結果仍不理想，問題多半在其他環節，依序檢查：

提示詞是否具體（構圖、風格、角色比例的描述）
是否加上對應版本的觸發詞（如 sprite、icon）
LoRA 版本（32 / 64 / 128）與權重
采樣與 CFG 等生成參數

尺寸不對不是唯一會造成偏差的原因，固定尺寸也不保證問題就此解決。

官方說明的環境不同

Civitai 模型頁寫的是 intended to be run at exactly 1024x1024，那是 ComfyUI 加上作者後處理節點的工作流（生成後再降採樣、量化調色盤）。sd-forge 直出 sprite 的基準則是 320×320，兩者環境不同，數值不可直接套用。

ROG Zephyrus Duo 16 (2022) GX650RX 副螢幕觸控感應異常修復

2026-05-23T18:11:04.363+08:00

✨ ROG Zephyrus Duo 16 (2022) GX650RX 副螢幕觸控感應異常修復

本文由 gemma:e4b 協助潤色與結構優化與 Gemini 提供選項解釋。

【適用情境】
當您在使用 ROG Zephyrus Duo 16 時，副螢幕的觸控功能出現不穩定或誤判現象（例如：觸控目標誤判，導致原本應作用於副螢幕的指令，卻誤觸到了主螢幕），請依照本深度修復指南進行故障排除。

【⚠️ 修復重要提醒】
本流程為針對觸控感應異常的深度系統修復。為確保修復成功，請您務必：

保持耐心，完整依照步驟順序操作。
嚴格且完整地執行所有「重新啟動 (Restart)」步驟，這是修復成功的關鍵環節。

✅ 準備工作：下載必要工具

請先下載並執行以下兩個工具包，以確保系統能進行完整的層面驅動調整：

1. [ROG ScreenPad Optimizer]

驅動下載來源： https://rog.asus.com/laptops/rog-zephyrus/rog-zephyrus-duo-16-2022-series/helpdesk_download/_
_下載連結： ROG ScreenPad Optimizer
(備註：執行後會生成一個資料夾，路徑範例：C:\DRIVERS\ROGScreenPadOptimizer_ASUS_Z_V1.6.0_15989_20260523165641)

2. [ASUS Control Panel Toolkit]

下載連結： ASUS Control Panel Toolkit

🔧 步驟一：執行 ROG ScreenPad Optimizer 最佳化 (關鍵兩階段流程)

請進入 ROG ScreenPad Optimizer 建立的資料夾，並執行 AgniDriverTool.exe。

A. 模式一：Optimus 模式校正 (自動切換模式)

【原理說明】 NVIDIA Optimus 是一種顯卡技術，旨在實現最佳的電力與效能平衡。系統會自動根據任務需求，在低功耗的整合式內顯與高性能的獨立顯示卡之間切換輸出。
【操作步驟】

在工具介面中，若當前模式為 Optimus，點擊 <Optimize> 按鈕，完成第一階段的校正。
2. ✅ 關鍵動作：完成此步驟後，請立即重新啟動電腦 (Restart)。

B. 模式二：Discrete GPU 模式校正 (獨立顯卡直連模式)

【原理說明】 此模式會強制系統完全停用內顯，讓螢幕畫面直接由 NVIDIA 獨立顯示卡進行輸出。此模式能提供最佳的效能表現和最低的延遲，但會提高系統功耗。
【操作步驟】

重新啟動後，再次打開工具，系統應已自動切換至獨立顯卡模式。
點擊下方的 <Optimize> 按鈕，完成第二階段的修正。
3. ✅ 關鍵動作：再次重新啟動電腦 (Restart)。

💡 總結流程重點： 務必完整完成「Optimus 最佳化 → 重新啟動」和「Discrete GPU 最佳化 → 重新啟動」這兩個連續的流程，才能確保驅動層面的調整達到最佳狀態。

🔧 步驟二：執行 ASUS Control Panel Toolkit 最佳化

請下載並執行 ASUS Control Panel Toolkit，對系統進行最終層級的系統調整和校準。

🔍 驗證與測試

完成所有步驟並重新啟動系統後，請在副螢幕上進行多點觸控操作，進行驗證。

✅ 成功判斷標準： 觸控目標判斷必須且只能作用於副螢幕，不會發生誤觸或影響主螢幕的指令。

corepack upgrade pnpm

2026-05-21T15:36:57.622+08:00

你想要更新 Corepack 內建的 pnpm 版本，但又不想用 corepack use pnpm@latest（因為它會在 package.json 裡面加上 packageManager 欄位）。這個需求可以透過直接更新 Corepack 的「shim」來達成，而不影響你的專案設定。

方法一：直接安裝新版 pnpm

npm install -g pnpm@latest

這樣會在全域安裝最新的 pnpm，Corepack 也會自動偵測到新版，不需要透過 corepack use。

方法二：更新 Corepack 的 pnpm shim

Corepack 其實有自己的管理方式，你可以用以下指令更新它的 pnpm 版本，而不會寫入 package.json：

corepack prepare pnpm@latest --activate

prepare 會下載並安裝指定版本的 pnpm。
--activate 會更新 Corepack 的 shim 指向這個版本。
不會修改專案的 package.json。

方法三：指定版本而非 latest

如果你想要固定某個版本（避免 latest 帶來不一致），可以直接指定：

corepack prepare pnpm@9.1.0 --activate

✅ 總結：

不要用 corepack use，因為它會修改 package.json。
用 corepack prepare ... --activate 或 直接全域安裝 pnpm，就能更新 Corepack 的 pnpm 版本而不影響專案設定。

要不要我幫你整理一個 對比表，清楚列出 corepack use、corepack prepare、npm install -g pnpm 三種方式的差異？

方法一：直接安裝新版 pnpm

npm install -g pnpm@latest

這樣會在全域安裝最新的 pnpm，Corepack 也會自動偵測到新版，不需要透過 corepack use。

方法二：更新 Corepack 的 pnpm shim

Corepack 其實有自己的管理方式，你可以用以下指令更新它的 pnpm 版本，而不會寫入 package.json：

corepack prepare pnpm@latest --activate

prepare 會下載並安裝指定版本的 pnpm。
--activate 會更新 Corepack 的 shim 指向這個版本。
不會修改專案的 package.json。

方法三：指定版本而非 latest

如果你想要固定某個版本（避免 latest 帶來不一致），可以直接指定：

corepack prepare pnpm@9.1.0 --activate

✅ 總結：

不要用 corepack use，因為它會修改 package.json。
用 corepack prepare ... --activate 或 直接全域安裝 pnpm，就能更新 Corepack 的 pnpm 版本而不影響專案設定。

這裡幫你整理一個 對比表，清楚比較三種方式更新 Corepack 的 pnpm 版本：

方法	指令範例	是否修改 `package.json`	更新範圍	適合情境
corepack use pnpm@latest	`corepack use pnpm@latest`	✅ 會加上 `packageManager` 欄位	專案層級 (影響當前專案)	適合想要專案明確指定 pnpm 版本的人
corepack prepare pnpm@latest --activate	`corepack prepare pnpm@latest --activate`	❌ 不會修改 `package.json`	Corepack shim (全域)	適合只想更新 Corepack 內建 pnpm，不影響專案設定
npm install -g pnpm@latest	`npm install -g pnpm@latest`	❌ 不會修改 `package.json`	全域安裝 (繞過 Corepack)	適合不想用 Corepack，直接用全域 pnpm

🔑 重點建議

如果你只是要更新 Corepack 的 pnpm 版本，但不想污染 package.json → 用 corepack prepare ... --activate。
如果你完全不想透過 Corepack → 用 全域安裝。

台大醫院門診掛號攻略：如何搶到名額？

2026-05-21T04:51:01.000+08:00

本文由 gemma:e4b 撰寫

🏥 台大醫院門診掛號攻略：如何搶到名額？

【前言】
許多人應該都會遇到台大醫院的門診掛號名額總是「額滿」。這篇攻略將整理出幾個經過實測的掛號黃金時間點與週期性搶票技巧，幫助你提高成功掛到的機率。

🕐 關鍵掛號黃金時間點 (最佳嘗試時機)

當網路掛號系統開放或釋出名額時，建議您鎖定以下兩個時間點進行嘗試：

當天前一晚 18:00 (下午六點)
當天午夜 00:00 (半夜十二點)

💡 實戰建議： 請將目標醫生或診別設定好，並在上述時間點前後持續刷新頁面。

🗓️ 掌握「週期性釋出」的掛號邏輯

掛號名額的釋出並非隨機的，而是遵循「週期的特性」。當你掛不到當日名額時，重點應放在捕捉「週期性釋出的新名額」。

✅ 核心原理： 追蹤醫生看診日之間的「間隙日」，並在這些間隙日嘗試掛號。

✨ 範例說明：

假設： 某位醫生固定只在週三和週五看診。
錯過時機： ❌ 嘗試在週三/週五的掛號時段。
建議嘗試時機： ⭕ 嘗試在 週二/週四 晚上六點後，或在 週三/週五 的凌晨零點後進行掛號。

透過鎖定看診日之間的間隙日，你更有機會掛到系統最新釋出的、兩週後的「新掛號週期」名額。

🔗 實用連結 (重要)

台大醫院網路掛號主頁： https://reg.ntuh.gov.tw/WebReg/WebReg/Index
門診科別資訊查詢： https://reg.ntuh.gov.tw/WebReg/WebReg/RegDeptInfo?vHospCode=T0&showBlock=A

📝 總結行動清單 (Checklist)

[ ] 鎖定時間： 隔天晚上 18:00 或當天 00:00。
[ ] 鎖定週期： 追蹤看診日之間的「間隙日」。
[ ] 策略： 耐心嘗試，名額是週期性釋出，而非固定時段開放。

obsidian-blogger mcp 發佈組合技

2026-05-21T02:32:35.125+08:00

Obsidian × MCP × Blogger — 無頭發佈組合技實錄

本文由 AI（Shadow Monarch）協助撰寫，內容基於實際程式碼修改與端到端測試結果。

當 Obsidian 插件不跟你對話時，那就自己開一條 MCP 專屬通道。

如果你需要在 Obsidian 外（透過 AI Agent 或自動化腳本）觸發插件功能，很可能會撞到一個尷尬的牆：Obsidian 的指令執行 API 只傳 commandId，不帶任何參數，也無法處理對話框（dialog）。

這篇文章記錄了我們如何繞過這個限制，實作一套從 MCP → REST API → Obsidian 插件 → Blogger 的完整發佈管線。

背景

obsidian-blogger 是一個能將 Obsidian 筆記直接發佈到 Google Blogger 的插件。它原本的發佈指令 google-blogger2:defaultPublish 是這樣註冊的：

// 原始實作 — 使用 editorCallback
this.addCommand({
  id: 'defaultPublish',
  name: 'Publish current note to Blogger',
  editorCallback: (_editor, _view) => {
    doClientPublish(this);
  },
});

當你在 Obsidian 內按快捷鍵或點指令面板時，這完全沒問題。但當我們想透過 MCP（Model Context Protocol） 來觸發它時，問題出現了。

問題：`command_execute` 的先天限制

Obsidian Local REST API 提供了一個 command_execute 工具，可以透過程式執行任何 Obsidian 指令。但它的簽章長這樣：

command_execute({ commandId: string })

只有 commandId，沒有第二個參數。

這意味著：

無法傳遞資料 — 不能指定要發佈哪個檔案，插件只能自己抓 active file
無法處理對話框 — 如果指令彈出 modal 或 prompt，Agent 無法回應
無法處理 checkCallback — 需要條件判斷才能執行的指令會直接失敗

實測結果

測試 google-blogger2:defaultPublish 時，雖然 API 回傳了 { "message": "OK" }，但實際上什麼都沒發生。沒有發佈，沒有錯誤訊息，什麼都沒有。

偵查：到底差在哪裡？

比對 Obsidian 的 addCommand API 文件後，發現 editorCallback 和 callback 在執行上有微妙的差異：

回呼類型	何時可用	簽章	適用場景
`callback`	任何時候	`() => void`	不需編輯器也可執行
`editorCallback`	僅有 Markdown 編輯器焦點時	`(editor: Editor, view: MarkdownView) => void`	需要操作編輯器內容
`checkCallback`	條件滿足時	`(checking: boolean) => boolean`	需要動態判斷是否可用

關鍵洞察：command_execute 在觸發指令時，並不會自動給予編輯器焦點。因此使用 editorCallback 註冊的指令，在透過 REST API 執行時，Obsidian 內部可能無法正確將它視為「可執行」狀態。

解法很簡單：新增一個專門給 MCP 用的指令，改用 callback 註冊。

解法：開一條 MCP 專屬通道

在 src/main.ts 中加入一個新的指令：

this.addCommand({
  id: 'mcpPublish',
  name: 'Publish via MCP (no dialogs)',
  callback: () => {
    doClientPublish(this);
  },
});

關鍵差異只有一行：callback: () => { ... } 取代了 editorCallback: (_editor, _view) => { ... }。

由於 doClientPublish 內部已經是透過 plugin.app.workspace.getActiveFile() 取得當前檔案，而不是靠 editorCallback 的參數，所以兩者的執行邏輯完全一樣 — 差別只在 Obsidian 願不願意讓它在無編輯器焦點的狀態下執行。

重構後生效

重新建置外掛：

pnpm run build

然後在 Obsidian 中重新載入插件。新的指令 google-blogger2:mcpPublish 就會出現在指令清單中。

組合技：端到端流程

AI Agent / MCP Client
    │
    ├─ command_execute("google-blogger2:mcpPublish")
    │
    ▼
Obsidian Local REST API (HTTP port 27123)
    │
    ├─ 接收 commandId
    │
    ▼
Obsidian 插件系統
    │
    ├─ 找到 blogger plugin 的 mcpPublish 指令
    │
    ▼
callback() → doClientPublish(plugin)
    │
    ├─ getActiveFile() → 取得目前開啟的檔案
    │
    ▼
publishPost(file)
    │
    ├─ 解析 frontmatter、轉換 Markdown
    │
    ▼
Blogger API (Google)
    │
    ├─ POST /blogger/v3/blogs/{blogId}/posts
    │
    ▼
結果回寫至 frontmatter
    ├─ postId, url, blogger.published/updated
    ├─ tags: [obsidian-blogger/post, obsidian-blogger/draft]
    │
    ▼
✅ 發佈完成

實測驗證

執行 command_execute("google-blogger2:mcpPublish") 後，檔案的 frontmatter 自動更新為：

profileName: Just E!
postId: "7373519934638137794"
url: https://elf-here-us.blogspot.com/
blogger:
  published: 2026-05-21T02:25:41+08:00
  updated: 2026-05-21T02:25:41+08:00
tags:
  - obsidian-blogger/post
  - obsidian-blogger/draft

所有欄位都正確寫入，表示發佈流程完全成功。

這個組合技的適用範圍

這套「加一條 MCP 專屬指令」的模式，不只適用於 obsidian-blogger。任何 Obsidian 插件只要遇到以下情境，都可以套用：

情境	說明
指令需要對話框	插件彈出 modal 要求使用者輸入 → 拆成兩個指令：一個是原本的 UI 版，另一個是 MCP 版跳過對話框，使用預設值或 active file 的內容
指令使用 `editorCallback`	如同本文案例，改成 `callback` 讓 REST API 能正常觸發
指令有 `checkCallback`	檢查條件無法滿足 → 新增無條件執行的 `callback` 版本
需要傳遞資料	command_execute 無法帶參數 → 改用 `vault_patch` 先在 frontmatter 寫入設定，再觸發指令讀取

重要原則

保留原始指令 — 不要刪除原本的 defaultPublish，因為使用者在 Obsidian UI 內還是需要它
命名清楚 — 新的 MCP 指令名稱要標明用途，例如 mcpPublish、mcpPublishLive 等
跳過對話框 — MCP 版的指令不應彈出任何 UI，所有的決策應該基於 frontmatter 或預設值

已知限制

一次只能發佈一個檔案 — 因為依賴 getActiveFile()，無法批次發佈
無法選擇目標 Blogger 部落格 — 使用上次設定的 profile，無法臨時切換
如果沒有開啟任何檔案 — getActiveFile() 回傳 null，會拋出錯誤

這些限制在一般使用場景下問題不大，但如果需要更進階的批次發佈或動態設定，就需要更深入的改造了。

總結

這次探索的核心收穫其實很簡單：

command_execute 不能帶參數、不能處理對話框、也不能保證編輯器焦點。但我們可以用一條 callback 指令，繞過所有這些限制。

如果你正在開發 Obsidian 插件，想要讓它可以被外部工具（AI Agent、自動化腳本、快捷鍵啟動器）呼叫，只要在 onload 裡面多註冊一個 callback 版本的指令就好 — 不需要動到原本的架構，也不需要引入額外的相依套件。

這就是 Obsidian × MCP 組合技的精髓：看懂 API 的限制，找到最小的繞道路徑。

obsidian mcp 三種工具比較

2026-05-21T02:28:28.106+08:00

Obsidian MCP 三種工具實戰比較

本文由 AI（@bluelovers/opencode-arise / Shadow Monarch）協助撰寫，內容基於實際工具測試結果。建議讀者在使用前自行驗證最新版本的功能變化。

從外掛到純本地，三種串接 Obsidian 與 MCP 的方式各有什麼優劣？

如果你正在研究如何讓 AI Agent 讀寫 Obsidian 筆記，可能會發現市面上至少有三種不同的 MCP 工具。它們名字很像，底層技術也相似，但實際用起來卻各有取捨。

這篇文章會從實際測試的角度，帶你快速看懂這三個工具的定位、能力與限制。

三個工具一句話版

工具	一句話
obsidian-local-rest-api	裝在 Obsidian 裡的外掛，開啟 REST API + MCP 兩種通道
mcp-obsidian	包裝上面那個外掛的 MCP 介面，定位是 MCP-only
mcpvault	反其道而行 — 不靠外掛，直接指定本機路徑讀寫 vault

1. obsidian-local-rest-api — 最完整的 API 通道

GitHub：https://github.com/coddingtonbear/obsidian-local-rest-api
本質：Obsidian 外掛，安裝後在 Obsidian 內啟動一個 HTTP 伺服器
支援：REST API + MCP 兩種模式
通訊：支援 HTTP 與 HTTPS（但 HTTPS 自簽憑證在某些環境下會有問題）

實測心得

這是我測試過功能最完整的選項。因為它直接暴露 Obsidian 的底層 API，所以能做的事情最多：

讀寫任何檔案類型（.md、.json、圖片等）
精確定位編輯（heading / block reference / frontmatter 三種 target）
可編輯 heading 行本身（targetScope: marker）
可執行 Obsidian 內部指令
可取得當前開啟的檔案
可在 UI 中開啟檔案
可搜尋全文（支援 JsonLogic 結構化查詢）

但也有一些麻煩的地方：

需要 Obsidian 在背景執行 — 如果 Obsidian 沒開，工具就直接斷線
需要安裝外掛 — 對某些管控嚴格的環境可能不便
HTTPS 自簽憑證問題 — 像我的環境就遇到 SSE error: self signed certificate，最後只能切 HTTP 模式使用

小結

如果你想找一個功能最強、操作最靈活的方案，這就是你要的。代價是你必須讓 Obsidian 一直開著，而且得接受那個自簽憑證的小麻煩。

2. mcp-obsidian — 純 MCP 包裝層

GitHub：https://github.com/MarkusPfundstein/mcp-obsidian
本質：MCP 伺服器，底層依賴 obsidian-local-rest-api 外掛
定位：純 MCP 介面，無 REST API

這個工具本質上就是第一項的 MCP-only 版本。它做的事情就是幫你把 obsidian-local-rest-api 的 REST 端點包裝成 MCP 工具。

在我們測試的環境中，已經被新的 mcp-obsidian-local-rest-api 工具集取代 — 新版的工具數量更多、功能更完整，而且直接對應到 REST API 的所有能力。

如果你是新使用者，直接使用新版工具即可，不需要回頭用這個舊版包裝。

3. mcpvault — 不裝外掛的另類選擇

GitHub：https://github.com/bitbonsai/mcpvault
本質：獨立 MCP 伺服器，直接指定本機 vault 路徑
特色：不需要安裝任何 Obsidian 外掛

這是最讓我驚喜的一個選項。它的設計哲學完全不同：

它是怎麼運作的？

一般的 MCP 工具需要透過 HTTP 跟某個服務溝通，但 mcpvault 直接讀取你硬碟上的 Obsidian vault 資料夾。你在 MCP 設定檔裡面給它一個路徑，它就自己去處理剩下的。

優點

不需要 Obsidian 執行中 — 即使 Obsidian 關著，工具照樣能讀寫
不需要安裝外掛 — 對某些不允許安裝社群外掛的環境特別有用
有移動/重新命名功能 — 這是前兩個工具完全做不到的
有標籤管理功能 — 可直接 add/remove/list 標籤，還有全 vault 標籤統計
批次讀取 — 一次最多讀取 10 個筆記
操作安全機制 — 刪除和移動檔案需要二次確認

缺點

僅支援 .md 檔案 — 想讀 .json、圖片？不行
沒有精確編輯 — 只能做字串取代，無法定位到特定 heading 或 block
沒有 UI 互動 — 不能在 Obsidian 中開啟檔案、不能執行指令
限本機 — 無法裝在遠端伺服器上（因為需要直接存取檔案系統）

小結

如果你只是想要批次整理筆記、管理標籤、搬動檔案，而且不想要 Obsidian 一直開著，mcpvault 是很棒的輕量選擇。但如果你需要精確編輯內容或與 Obsidian UI 互動，它就不太夠用了。

功能對照總表

面向	local-rest-api	mcpvault
需 Obsidian 運行	✅ 必須	❌ 不需要
需安裝外掛	✅ 必須	❌ 不需要
可裝在遠端	✅ 可以	❌ 限本機
建立/覆寫檔案	✅ vault_write	✅ write_note
附加/插入內容	✅ vault_append	✅ write_note 三種 mode
精確 section 編輯	✅ vault_patch	❌ 僅字串取代
編輯 heading 行	✅ targetScope:marker	❌ 無法
批次讀取	❌ 無	✅ read_multiple_notes
移動/重新命名	❌ 無	✅ move_note + move_file
Frontmatter 獨立更新	❌ 需 patch	✅ update_frontmatter
標籤管理	❌ 無	✅ manage_tags + list_all_tags
Vault 統計	❌ 無	✅ get_vault_stats
檔案結構探索	✅ document_map	❌ 無
執行 Obsidian 指令	✅ command_execute	❌ 無
UI 開啟檔案	✅ open_file	❌ 無
取得當前檔案	✅ active_file_path	❌ 無
週期筆記	✅ periodic_note	❌ 無
非 `.md` 檔案	✅ 可以	❌ 僅限 `.md`
操作安全確認	❌ 無	✅ 二次確認機制

註：mcp-obsidian（舊版）已被新版 mcp-obsidian-local-rest-api 取代，功能上完全被新工具覆蓋，故不特別列入比較。

所以該選哪一個？

這其實不是選擇題。這兩個工具是互補關係，而不是競爭關係：

你需要做的事                 → 推薦工具
──────────────────────────────────────────
精確編輯筆記內容              → local-rest-api
搜尋與讀取筆記                → 兩者皆可
批次搬移/重新命名大量筆記      → mcpvault
管理筆記標籤                  → mcpvault
與 Obsidian UI 互動           → local-rest-api
操作 JSON 或其他非 md 檔案    → local-rest-api
不開 Obsidian 也能讀寫        → mcpvault
需要遠端存取 vault            → local-rest-api

如果你只能選一個，我會建議先以 local-rest-api 為主 — 因為它的功能涵蓋面最廣，精確編輯的能力是 mcpvault 無法取代的。等真的遇到需要搬檔案或整理標籤的情境時，再把 mcpvault 補上就好。

附錄：關於 HTTPS 自簽憑證

如果你跟我一樣遇到 SSE error: self signed certificate，這裡有幾個解法：

切換 HTTP 模式（最簡單） — 在 MCP 設定中把 protocol 改為 http，port 改為 27123
將自簽憑證加入信任（較安全） — 匯出 obsidian-local-rest-api 產生的憑證，加入系統信任清單
使用環境變數跳過驗證（不建議） — NODE_TLS_REJECT_UNAUTHORIZED=0，僅限開發環境

參考連結

obsidian-local-rest-api — Obsidian 外掛，提供 REST + MCP
mcp-obsidian — MCP 包裝層（已被新版取代）
mcpvault — 獨立 MCP 伺服器，直接讀寫本機 vault

windows 環境下載 PHP 與 XDebug , PHPUnit

2026-05-20T07:39:00.000+08:00

可以由 https://xdebug.org/download/historical 去查詢歷史版本所對應的 PHP 版本。

可以下載 XDebug 官方網站沒有提供的編譯版本（例如 nts 版）：
https://downloads.php.net/~windows/pecl/releases/xdebug/

PHP 5.6.32

PHPUnit: PHPUnit 5
Download PHPUnit 5: phpunit-5.phar
XDebug: xdebug-2.2.7

PHP 7.3 or PHP 7.4

PHPUnit: PHPUnit 9
Download PHPUnit 9: phpunit-9.phar
XDebug: xdebug-3.1.6

在這裡可以下載 PHP 的編譯版本：
https://downloads.php.net/~windows/releases/archives/

PHP	XDebug	PHPUnit
`php-5.6.32-nts-Win32-VC11-x64`	`php_xdebug-2.2.7-5.6-nts-vc11-x64`	`phpunit-5.7.27`
`php-7.4.33-nts-Win32-vc15-x64`	`php_xdebug-3.1.6-8.1-nts-vs16-x64`	`phpunit-9.6.34`

chrome devtool mcp 相關的一些奇怪狀況

2026-05-19T12:46:41.086+08:00

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome

如果 RemoteDebuggingAllowed 存在

則 chrome://inspect/#remote-debugging 內可能會無法打勾設定

檢查方法：

打開你平常用的 Chrome。
在網址列輸入 chrome://policy 。
在頁面中搜尋 DeveloperToolsAvailability 或任何帶有 RemoteDebugging 關鍵字的政策。
如果看到它的值被設定為 2 或 false（代表強制停用），那就找到真兇了！這會導致所有 DevTools 和 Port 監聽直接失效，且 chrome://inspect 的勾選框會被灰色鎖定。

VSCode 設定自定義終端的注意事項

2026-05-12T06:33:58.824+08:00

VSCode 設定自定義終端的注意事項

情境說明

當 Git Bash 沒有被 VSCode 自動偵測到時，可以透過手動新增設定檔來解決。但需要注意兩個關鍵細節，否則自訂設定會失效。

注意事項

1. 設定檔名稱不可為 `Git Bash`

VSCode 已內建名為 Git Bash 的終端設定檔，若自訂設定使用相同名稱，會導致衝突。建議使用其他名稱，例如 Git Bash (local)。

2. 必須移除 `source` 欄位

若有 source 欄位存在，VSCode 會優先使用內建定義來覆蓋自訂設定，導致自訂路徑無法被正確偵測。因此手動設定時必須刪除 source 欄位。

正確設定範例

將以下配置加入 VSCode 的 settings.json 中：

"terminal.integrated.profiles.windows": {
    "PowerShell": {
        "source": "PowerShell",
        "icon": "terminal-powershell"
    },
    "Command Prompt": {
        "path": [
            "${env:windir}\\Sysnative\\cmd.exe",
            "${env:windir}\\System32\\cmd.exe"
        ],
        "args": [],
        "icon": "terminal-cmd"
    },
    "Git Bash (local)": {
        "icon": "terminal-git-bash",
        "path": [
            "D:/msys64/bin/bash.exe",
            "C:/Program Files/Git/bin/bash.exe"
        ]
    }
}

常見問題

問題	原因	解決方式
自訂 Git Bash 無效	設定檔名稱使用了 `Git Bash`	改用其他名稱（如 `Git Bash (local)`）
路徑設定未生效	遺留了 `source` 欄位	移除 `source` 欄位，僅保留 `path` 與 `icon`

[node] 詭異的 Error: EBADF: bad file descriptor, uv_pipe_open

2020-02-20T21:51:00.000+08:00

在使用 now dev 時出現這個錯誤訊息

Error: EBADF: bad file descriptor, uv_pipe_open

解法非常的詭異
那就是不要用 yarn 來執行這段指令
改用 npm

[git] git 無法推送大量檔案的解決方法

2019-04-18T10:47:00.002+08:00

加上此設定

[http]
postBuffer = 524288000

[IntelliJ IDEA] 的疑難雜症詭異現象與隱藏設定

2019-04-07T18:13:00.001+08:00

如何進入隱藏設定選項 (Help - Find Action - Registry)

如此一來就能看見隱藏設定

---

讓編輯器禁用從右到左的語言

雖然編輯器可以設定語言是左到右還是右到左
但如果遇上了同時有兩種書寫方向語言時
就會發生錯亂

這個會況會發生在選取或者搜尋時

最簡單的例子就是把阿拉伯文字與中文混排放在同一個檔案內就能看出狀況

這時候可以將 editor.disable.rtl 打勾來解決這個問題

---

不明原因導致 git 無法驗證例如 push / fetch 失敗

但如果透過直接下指令又能夠正常推送

這時候可以將 git.reset.credential.helper 取消打勾

---

projectView.hide.dot.idea 讓專案介面可以顯示 .idea 資料夾

---

vmoption

-Dfile.encoding=UTF-8
-Djava.io.tmpdir=T:/Temp/

-Didea.initially.ask.config=true <=== 新版 2020 會在啟動時忽略匯入設定的確認畫面使用這個選項可以讓他復活

內部開發模式
https://www.jetbrains.org/intellij/sdk/docs/reference_guide/internal_actions/enabling_internal.html

idea.is.internal=true
-Didea.is.internal=true

---

以停用非內建插件的模式來啟動 IDE

https://youtrack.jetbrains.com/issue/IDEA-240053#focus=streamItem-27-4125008.0-0

idea disableNonBundledPlugins

windows 10 解鎖被隱藏的音效選項

2019-04-06T17:06:00.000+08:00

在 windows 10 會發現在音效設定內有些消失了

例如登入登出關機聲音之類

開啟以下機碼

HKEY_CURRENT_USER\AppEvents\EventLabels

找到以下項目

SystemExit
WindowsLogoff
WindowsUnlock

將 ExcludeFromCPL 改成 0 即可解除隱藏

之後在進入音效設定內就能設定喜歡的音樂

至於開機音效的話

下載

https://winaero.com/blog/change-startup-sound-windows-10/

直接透過這個工具去設定比較簡單

[android] 今年重買一隻 note 4 後刷 TWRP 的詭異現象

2019-03-06T15:58:00.000+08:00

不管怎麼用 ODIN 刷入 TWRP 之後進入的模式都是原生

後來找了好久在網路上終於發現一篇很不明顯的提到解法

那就是刷入時在 OIN 上取消掉自動重開機

改成刷入後自己去手動關機

這樣做之後 TWRP 就莫名其妙刷進去了 = =

[NativeScript] 初次接觸時遇到的白癡狀況

2017-12-06T05:15:00.002+08:00

明明就下載了 Android SDK 甚至 Android Studio
結果依然無法正常啟動 NativeScript

經過以下步驟之後才正常使用

ANDROID_HOME=(Android SDK 路徑)\Sdk
ANDROID_SDK_HOME=(HOME路徑底下要能放 .android 資料夾)
ANDROID_AVD_HOME=%ANDROID_SDK_HOME%\.android\avd
JAVA_HOME=%JDK_HOME% <=== 因為 NativeScript 只認 JAVA_HOME
JDK_HOME=(JDK 路徑)

在專案路徑下建立以下檔案

run-adb.cmd

"%ANDROID_HOME%\platform-tools\adb.exe" %*

run-avd.cmd

"%ANDROID_HOME%\emulator\emulator" %*

在 package.json 內加入以下項目

"scripts": {
    "start-adb": "cmd /c run-adb.cmd -L tcp:5037 fork-server server --reply-fd 704",
    "start-avd": "cmd /c run-avd.cmd @Nexus_5X_API_23",
    "run": "npx tns run android"N
},

然後想要執行的時候

先執行一次 npm run start-adb <== 此步驟只需要一次
然後在執行 npm run start-avd <== 此步驟會開啟模擬器

接著就可以執行 npm run run 或者 npx tns run android
看見你的 APP 出現在模擬器裡面

[Portable] Twitch Desktop App Portable

2017-10-10T20:17:00.002+08:00

Download Twitch Desktop App Portable

[windows 10] 一些關於 windows 服務的筆記

2017-08-16T12:35:00.001+08:00

停用後會導致開始功能表無法正常使用的狀況

WpnUserService_ - Windows 推播通知使用者服務
會導致無法開啟
Microsoft.Windows.Cortana
強制停用後會導致雖然可以開功能表但是卻無法進行任何操作

[OCR] Capture2Text 螢幕文字辨識

2017-08-02T10:18:00.002+08:00

Capture2Text
http://capture2text.sourceforge.net/

下載點 Download
https://sourceforge.net/projects/capture2text/files/latest/download?source=files

語言包 Dictionaries

https://sourceforge.net/projects/capture2text/files/Dictionaries/
https://github.com/tesseract-ocr/tessdata <== download this one

推薦使用第二個連結內的語言辨識包
第二個連結為 Capture2Text 所使用的 OCR 引擎 tesseract 官方所提供的語言辨識包

執行 Capture2Text 時如果加上 --portable 這個參數就可以變成免安裝版
(差別也只是影響設定檔儲存的位置與讀取方式而已

主要的快捷鍵

WIn + Q 自訂選取區域
Win + E 文字行模式(可以自動判斷直航或橫行)
WIn + S 自動判斷文字範圍

Win + R 重新判斷最後一次辨識的區域(適合當辨識不理想的時候再來一次)

[Firefox] 載入頁面時與伺服器的連線被重設

2017-07-31T23:06:00.001+08:00

解決方法 1

嘗試修改 firefox 的 proxy 設定

選項 > 進階 > 網路 > 設定

試著改成自動 / 不使用 / 系統

解決方法 2 (不建議但當上述方法無效時有效)

在 about:config 中試著將以下項目改成 false

security.ssl3.rsa_des_ede3_sha
security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha

https://forum.moztw.org/viewtopic.php?f=2&t=42156

Bash on Ubuntu on Windows

2017-07-12T16:23:00.004+08:00

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

bash

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs

https://msdn.microsoft.com/en-us/commandline/wsl/install_guide

https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions

[NodeJS][Babel][ES6] module.exports = require('module-name') 的奇怪解法

2017-07-12T04:15:00.001+08:00

當我們想用 es6 特性的 import/export 來寫出以下這段 nodejs 代碼時

module.exports = require('module-name')

以 MDN 的範例來說會寫成

import mod from "mod";
export default mod;

但是這段代碼在我的環境內卻是 undefined

改寫成以下這段代碼後
卻可以正常符合期待的運作

import * as mod from './src';
export default mod;

[Msys2] Perl CPAN install 安裝錯誤的詭異解法

2017-07-10T14:56:00.003+08:00

在 msys2 內輸入以下指令後

cpan install Switch
cpan install UNIVERSAL::isa

卻沒有正確安裝完成

這時候在 C:\msys64\usr\share\perl5 底下建立一個 site_perl 資料夾

並且到 C:\Users\USER\.cpan\build 底下找到這次打算安裝的模組

例如 Switch 就在 C:\Users\USER\.cpan\build\Switch-2.17-3tYKvF 底下的 Switch.pm
UNIVERSAL::isa 就在 C:\Users\USER\.cpan\build\UNIVERSAL-isa-1.20150614-_RCQTf 底下的 lib 資料夾內

將這些檔案與資料夾複製到 C:\msys64\usr\share\perl5\site_perl 就可以解決

[MSYS2] 錯誤：GPGME error: 無效的密碼法引擎 (PGP 簽章)

2017-07-08T05:18:00.000+08:00

最近在重灌系統後安裝 Msys2

試圖安裝更新或組件時都會出現類似以下錯誤

錯誤訊息

錯誤：GPGME error: 無效的密碼法引擎
錯誤：GPGME error: 無效的密碼法引擎
錯誤：GPGME error: 無效的密碼法引擎
錯誤：「mingw32」資料庫不正確 (資料庫不正確或損毀 (PGP 簽章))
錯誤：「mingw64」資料庫不正確 (資料庫不正確或損毀 (PGP 簽章))
錯誤：「msys」資料庫不正確 (資料庫不正確或損毀 (PGP 簽章))

解決方法

編輯 C:\msys64\etc\pacman.conf
找到 SigLevel
更改為 SigLevel = Never

就可以解決此詭異問題

internal error 0x0A: Protection initialization failed!

2017-02-27T12:36:00.001+08:00

Comodo

Cheat Engine 搭配 Snes9x 使用金手指的方法

2017-02-03T03:57:00.002+08:00

Cheat Engine
http://cheatengine.org/

Snes9x
http://www.snes9x.com/downloads.php
http://www.s9x-w32.de/dl/

開啟 Snes9x 並且載入遊戲輸入兩組一模一樣的金手指
然後將數值(紅色箭頭) 改成兩個不一樣的數字

然後關閉金手指視窗(重要步驟)

開啟 Cheat Engine 選擇 snes9x 程式

輸入搜尋 99 <=== 金手指所設定的數字

回到 Snes9x 選擇另外一個金手指

回到 Cheat Engine 搜尋 20

再次回到 Snes9x 將啟用數值為 99 的那一組金手指

反覆這個動作到只出現一組結果

將結果保留下來

在結果視窗內選擇

點選位址出現編輯視窗在原本的位址後面加上 -7E2D4D <=== 金手指所設定位址

最後出現的結果就是起點
以後只要輸入起點 + Snes9x金手指位址就會變成 Cheat Engine 位址

-----------------------------------

但是以上方法只要重開 Snes9x
地址就會無效

但是如果你有儲存上一次的 Cheat Engine 檔案

只要在重覆一次上面的動作得到起點之後
將上一次的起點與這一次的起點相減
就會得到偏移值

可以使用 win10 計算機或者直接在 Cheat Engine 內計算

然後將所有之前的項目選起來之後
案右鍵選擇智能位址編輯

然後輸入進去如果這次的位址比上一次的大就直接輸入進去
如果這一次的位址比上一次的小就加上一個減號

最後等待一小段時間讓 Cheat Engine 處理一下(這部分每次都會有點慢)

然後就完成了

Just E!

sd-forge 用 Krea 2 Pixel Art 生成 sprite 的注意事項與陷阱

sd-forge 用 Krea 2 Pixel Art 生成 sprite 的注意事項與陷阱

Model Info

生成尺寸設定

沒有用 LoRA 時：門檻是 768

這些症狀容易誤導排查方向

這是除錯方向，不是唯一答案

官方說明的環境不同

ROG Zephyrus Duo 16 (2022) GX650RX 副螢幕觸控感應異常修復

✨ ROG Zephyrus Duo 16 (2022) GX650RX 副螢幕觸控感應異常修復

✅ 準備工作：下載必要工具

🔧 步驟一：執行 ROG ScreenPad Optimizer 最佳化 (關鍵兩階段流程)

A. 模式一：Optimus 模式校正 (自動切換模式)

B. 模式二：Discrete GPU 模式校正 (獨立顯卡直連模式)

🔧 步驟二：執行 ASUS Control Panel Toolkit 最佳化

🔍 驗證與測試

corepack upgrade pnpm

方法一：直接安裝新版 pnpm

方法二：更新 Corepack 的 pnpm shim

方法三：指定版本而非 latest

方法一：直接安裝新版 pnpm

方法二：更新 Corepack 的 pnpm shim

方法三：指定版本而非 latest

台大醫院門診掛號攻略：如何搶到名額？

🏥 台大醫院門診掛號攻略：如何搶到名額？

🕐 關鍵掛號黃金時間點 (最佳嘗試時機)

🗓️ 掌握「週期性釋出」的掛號邏輯

obsidian-blogger mcp 發佈組合技

Obsidian × MCP × Blogger — 無頭發佈組合技實錄

背景

問題：command_execute 的先天限制

實測結果

偵查：到底差在哪裡？

解法：開一條 MCP 專屬通道

重構後生效

組合技：端到端流程

實測驗證

這個組合技的適用範圍

重要原則

已知限制

總結

相關連結

obsidian mcp 三種工具比較

Obsidian MCP 三種工具實戰比較

三個工具一句話版

1. obsidian-local-rest-api — 最完整的 API 通道

實測心得

小結

2. mcp-obsidian — 純 MCP 包裝層

3. mcpvault — 不裝外掛的另類選擇

它是怎麼運作的？

優點

缺點

小結

功能對照總表

所以該選哪一個？

附錄：關於 HTTPS 自簽憑證

參考連結

windows 環境下載 PHP 與 XDebug , PHPUnit

chrome devtool mcp 相關的一些奇怪狀況

VSCode 設定自定義終端的注意事項

VSCode 設定自定義終端的注意事項

情境說明

注意事項

1. 設定檔名稱不可為 Git Bash

2. 必須移除 source 欄位

正確設定範例

常見問題

[node] 詭異的 Error: EBADF: bad file descriptor, uv_pipe_open

[git] git 無法推送大量檔案的解決方法

[IntelliJ IDEA] 的疑難雜症 詭異現象 與 隱藏設定

讓 編輯器 禁用 從右到左的語言

不明原因導致 git 無法驗證 例如 push / fetch 失敗

windows 10 解鎖被隱藏的音效選項

[android] 今年 重買一隻 note 4 後 刷 TWRP 的詭異現象

[NativeScript] 初次接觸時遇到的白癡狀況

[Portable] Twitch Desktop App Portable

[windows 10] 一些關於 windows 服務的筆記

[OCR] Capture2Text 螢幕文字辨識

問題：`command_execute` 的先天限制

1. 設定檔名稱不可為 `Git Bash`

2. 必須移除 `source` 欄位

[IntelliJ IDEA] 的疑難雜症詭異現象與隱藏設定

讓編輯器禁用從右到左的語言

不明原因導致 git 無法驗證例如 push / fetch 失敗

[android] 今年重買一隻 note 4 後刷 TWRP 的詭異現象