1. 项目概述为什么一个“看板Copilot”的组合能真正解决项目管理的断层问题Obsidian 看板 Copilot 这个组合不是简单把两个热门工具拼在一起凑热度而是直击知识工作者在项目管理中最常踩的三个坑计划写得漂亮、执行时找不到重点、复盘时记不清细节。我带过十几支跨职能团队从硬件研发到内容运营发现90%的人不是不会用工具而是工具链之间存在严重的信息断层——任务在Todo插件里进度在Notion看板上思考过程散落在几十个零散笔记中每日总结又另开一个文档。结果就是早上列计划花20分钟中午找上下文耗40分钟晚上写复盘时对着空白页发呆。这个闭环之所以“完美”是因为它用 Obsidian 的本地优先、双向链接和块引用能力把“计划—执行—回顾”三个动作压缩进同一个知识图谱里再用 Copilot特指 GitHub Copilot 或兼容 OAI 协议的本地/云侧代码补全模型把重复性高、模式固定、但人容易出错的文本操作自动化掉。比如你不用手动复制粘贴每日完成项到周报模板Copilot 能基于你当天笔记里的 ✅ 标记块自动提取、归类、润色成一段可直接发送的进展摘要也不用翻三四个页面去确认某个子任务是否关联了设计稿评审会议看板视图里点一下就能跳转到原始讨论块。关键词“Obsidian”“Copilot”“看板”“项目管理”“每日总结”不是并列标签而是一条工作流的五个关键节点Obsidian 是底座数据主权图谱结构Copilot 是加速器语义理解文本生成看板是仪表盘状态可视化项目管理是目标域WBS拆解依赖追踪每日总结是反馈环PDCA中的Check与Act。它适合三类人独立开发者需要轻量级但可扩展的个人项目中枢小团队技术负责人想甩掉Excel甘特图又不想被SaaS平台绑架以及备考软考中级系统集成项目管理工程师的考生——因为这套流程天然对应教材里“项目整体管理”“监控项目工作”“管理沟通”这几个核心知识域你每天实操就是在做真题演练。这不是教你怎么装插件而是告诉你当你的每日笔记变成项目状态的实时快照当你的看板卡片背后是可追溯的决策链路当 Copilot 不是帮你写代码而是帮你写“为什么这个需求排期要延后三天”的说明时项目管理才真正从纸面落进肌肉记忆。2. 整体架构设计为什么必须用 Obsidian 原生能力打底而非嫁接外部看板2.1 核心逻辑看板不是UI组件而是数据关系的投影很多人一看到“Obsidian 看板”第一反应是装 Kanban 插件、拖拽卡片、配颜色标签。这完全走偏了。真正的设计起点是你如何定义“一个项目”在 Obsidian 里的数据结构。我试过至少7种方案最终锁定为“三元组模型”项目主笔记Project Note 任务原子块Task Block 状态标记Status Tag。项目主笔记是唯一真相源它不存具体任务内容只存项目目标、关键里程碑、干系人列表和链接到所有相关任务块任务原子块必须是嵌入在每日笔记或会议纪要里的独立段落用 [!task]Callout 包裹包含明确的due:: 2025-04-12、assignee:: zhangsan、priority:: P1等 Frontmatter 字段状态标记则统一用#status/todo、#status/in-progress、#status/done这类纯文本标签而非插件自建的状态字段。为什么因为只有这样看板视图才能成为“查询结果”而非“数据容器”。当你在 Kanban 插件里新建一张看板它的本质是一条 Dataview 查询语句TABLE file.name AS 任务, due AS 截止日, assignee AS 负责人 FROM #status/in-progress WHERE !contains(file.name, 模板) SORT due ASC。这张表里显示的每张卡片点击后直接跳转到原始任务块所在的上下文页面——可能是昨天的站会记录也可能是上周的需求评审草稿。这种设计彻底规避了传统看板的最大缺陷信息孤岛。你在 Jira 里改了状态Confluence 里的文档不会自动更新你在 Notion 看板里拖动卡片会议纪要里的待办清单还是静态的。而在这里状态变更只需改一个标签所有关联视图看板、周报、风险清单实时重算。Copilot 的介入点就在此它不生成新数据而是理解这条查询语句背后的语义帮你把#status/done的任务块自动聚合到今日总结的“已完成”区块并补全一句符合职场语境的描述比如把“✅ 完成登录页UI适配”扩写成“完成用户登录页在iOS 18及Android 14系统的UI适配已通过QA基础用例验证”。2.2 工具链选型为什么拒绝“Copilot for Obsidian”类插件网络热词里频繁出现的“obsidian copilot”“obsidian claude”背后是大量用户在寻找“一键接入大模型”的捷径。我必须明确说现阶段所有标榜‘Obsidian 原生 Copilot’的插件都是伪需求解决方案。原因有三第一安全边界失控。这些插件要求你输入 API Key 并允许其读取整个 Vault意味着你的项目敏感信息客户名称、未发布功能、内部成本数据可能经由第三方中转第二上下文精度灾难。Obsidian 的核心价值在于块级引用Block Reference而插件只能把整篇笔记喂给模型导致 Copilot 经常忽略你当前光标所在的具体任务块反而去分析笔记顶部的无关会议纪要第三响应不可控。当 Copilot 需要调用外部 API 时网络抖动会让“生成周报摘要”这种操作卡顿30秒以上彻底破坏工作流节奏。我的方案是“物理隔离语义桥接”Copilot 运行在 VS Code 或 Cursor 这类 IDE 中Obsidian 仅作为数据源和展示层。具体操作是——每天下班前我在 Obsidian 里打开当日笔记选中所有带#status/done的任务块右键“Copy Block Link”然后切到 VS Code新建一个临时.md文件粘贴链接再按快捷键触发 Copilot。Copilot 会自动识别这是 Obsidian 块引用并从本地 Vault 中精准加载该块内容需提前配置好 Obsidian 的vaultPath和blockId解析规则。这种设计下Copilot 永远只看到你主动选择的、最小粒度的数据单元且全程离线处理若使用本地模型API Key 只存在于 IDE 的安全存储中。那些搜索“copilot学生认证”“copilot cli”“vscode copilot安装别的模型”的用户其实真正需要的不是更多接入方式而是更清晰的数据权限控制逻辑。2.3 数据流向闭环从每日笔记到项目健康度仪表盘整个闭环的血液是“每日笔记”Daily Note。它不是流水账而是项目状态的传感器节点。我的每日笔记模板强制包含四个区块## 今日聚焦当天必须推进的3个P0任务、## ✅ 已完成自动聚合昨日标记为done的任务、## ⚠️ 阻塞项需跨部门协调的问题、## 思考碎片临时涌现的优化点。关键设计在于✅ 已完成区块不手动填写而是由 Dataview 插件动态生成——它扫描所有笔记中#status/done且date:: 今天的任务块并按项目分组显示。Copilot 的作用是把这个机器生成的列表转化成人类可读的汇报语言。例如Dataview 输出- [[2025-04-10]]#^1a2b3c → 完成支付模块风控规则配置 - [[2025-04-10]]#^4d5e6f → 同步用户中心接口文档至SwaggerCopilot 会生成今日交付两项关键进展1支付模块完成风控规则V2.1版配置覆盖盗刷交易拦截率提升至99.2%2用户中心OpenAPI文档已同步至内部Swagger平台前端团队可即时调用测试。两项工作均按计划节点达成。这个过程完成了三次跃迁数据层块标签→ 视图层Dataview表格→ 语义层Copilot润色。而项目健康度仪表盘就是把这些每日语义输出按周/月聚合。我用一个独立的Projects/Health-Dashboard.md笔记通过 Dataview 查询过去7天所有✅ 已完成区块的 Copilot 生成文本再用正则提取其中的“覆盖率”“达成率”“阻塞时长”等数值最后用 Mermaid 语法注此处为说明原理实际博文禁用Mermaid故用文字描述生成趋势图。这个仪表盘不追求炫酷UI但每个数字都能点击溯源到原始任务块——这才是项目管理该有的样子没有黑箱只有可验证的链条。3. 核心实现细节手把手搭建可落地的看板与Copilot协同工作流3.1 Obsidian 环境初始化从零开始的5个必装插件与配置要点搭建这个闭环第一步不是研究 Copilot而是让 Obsidian 的底层数据结构足够健壮。我坚持“少而精”原则只启用以下5个插件且每个都经过生产环境千次以上验证Core Plugin: Daily Notes启用路径设置 → 核心插件 → Daily Notes → 开启关键配置模板路径设为Templates/DailyNote.md日期格式用YYYY-MM-DD避免中文日期导致 Dataview 查询失败提示不要用“今天”“昨日”这类相对日期Dataview 对绝对日期解析更稳定。我见过太多人因模板里写date:: {{date:YYYY-MM-DD}}导致周报查询返回空结果根源是模板变量在每日笔记创建时未正确渲染。Community Plugin: Dataview安装后必须重启 Obsidian关键配置在Settings → Community plugins → Dataview → Settings中勾选 “Enable inline queries” 和 “Enable JavaScript queries”注意JavaScript queries 是实现复杂聚合的必备能力比如计算某项目“阻塞天数”需用dv.current().file.inlinks.where(t t.tags.contains(status/blocked)).length纯 SQL 模式无法实现。Community Plugin: Kanban版本必须 ≥ 1.9.0低版本不支持块级拖拽关键配置在看板设置中关闭 “Auto-sync with tags”改为手动指定查询语句例如FROM #status/in-progress SORT due ASC实测心得开启 Auto-sync 会导致看板卡片与原始任务块状态不同步尤其当你用 Dataview 批量修改标签时。手动查询虽多写一行代码但换来的是100%状态一致性。Community Plugin: Templater用于自动化每日笔记初始化关键模板保存为Templates/DailyNote.md--- date: {{date:YYYY-MM-DD}} --- ## 今日聚焦 - [ ] - [ ] - [ ] ## ✅ 已完成 dataview LIST FROM #status/done WHERE date this.file.name SORT file.mday DESC⚠️ 阻塞项[ ] 思考碎片实操技巧Templater 的{{date:YYYY-MM-DD}}必须用双大括号单括号会失效且模板文件名必须与 Daily Notes 设置的模板路径完全一致包括大小写和空格。Community Plugin: Obsidian Git不是为了代码管理而是为 Copilot 提供可靠的数据快照关键配置设置自动提交间隔为“每30分钟”提交消息固定为auto-commit: daily note sync为什么重要当 Copilot 在 VS Code 中解析块内容时Git 仓库是它获取历史版本的唯一可信源。某次我误删了任务块Copilot 却基于 Git 历史生成了准确的恢复建议“检测到 [[2025-04-08]]#^7g8h9i 在4月9日被删除建议从 commit 3a7b2c 中恢复该块”。这5个插件构成最小可行系统。其他如 “QuickAdd”“Tag Wrangler” 等热门插件我全部禁用——它们会污染数据结构让 Copilot 的语义解析变得不可靠。记住Obsidian 的威力不在插件数量而在数据纯净度。3.2 看板视图构建从静态卡片到可交互的项目作战室Kanban 插件的默认视图只是玩具。要让它成为项目作战室必须深度定制列Column和卡片Card行为。我的实战配置如下列定义ColumnsTo Do列查询#status/todo AND !#status/blockedIn Progress列查询#status/in-progress OR #status/review合并开发中与待评审状态Done列查询#status/done AND file.mday date(today) - dur(7 days)仅显示近7天完成项Blocked列查询#status/blocked单独成列强制视觉聚焦卡片定制Card Template在 Kanban 设置中启用 “Custom card template”填入 [!task]- {{title}} **截止**{{due}} | **负责人**{{assignee}} **来源**[[{{file.name}}#^{{block.id}}]] **详情**{{content}}这个模板的关键在于{{block.id}}——它让每张卡片都携带原始块ID点击“来源”链接即可瞬移回上下文。我曾用此功能快速定位一个线上Bug运维在#status/blocked列看到“订单超时告警未修复”点击来源链接直达3天前的故障复盘笔记直接跳转到#^xyz789块那里详细记录了“Redis连接池耗尽”的根因分析和临时方案。高级交互非界面操作真正的效率提升来自键盘操作。我绑定以下快捷键CtrlShiftT在当前笔记任意位置插入新任务块自动填充 [!task]-和due:: {{date:YYYY-MM-DD}}AltEnter将光标所在行转换为任务块支持批量选中多行CtrlK快速切换任务状态标签todo → in-progress → done → blocked 循环这些快捷键由 Templater 和 Hotkeys 插件组合实现比拖拽卡片快3倍以上。某次紧急上线前我用CtrlK在15秒内将12个任务块状态从todo切换到in-progress而同事还在 Kanban 界面里逐个右键菜单操作。3.3 Copilot 协同协议VS Code 中的语义桥接实战配置Copilot 不是魔法棒它是需要精确“喂食”的精密仪器。以下是我在 VS Code 中建立的完整协同协议确保每次调用都精准命中目标Step 1环境准备安装 VS Code 插件GitHub Copilot官方版、Obsidian Link Helper社区插件在 VS Code 设置中启用github.copilot.enable和obsidian-link-helper.enable将 Obsidian Vault 路径添加到 VS Code 工作区File → Add Folder to WorkspaceStep 2块内容提取脚本核心创建~/scripts/obsidian-block-extractor.js// 此脚本接收 Obsidian 块链接如 [[2025-04-10]]#^1a2b3c返回纯文本内容 const fs require(fs); const path require(path); function extractBlock(vaultPath, link) { const match link.match(/\[\[(.*?)\]\]#^([a-zA-Z0-9])/); if (!match) return Invalid block link; const [_, fileName, blockId] match; const filePath path.join(vaultPath, ${fileName}.md); try { const content fs.readFileSync(filePath, utf8); // 正则匹配块ID^1a2b3c 后的内容直到下一个 ^ 或文件结尾 const blockRegex new RegExp(\\^${blockId}([^\\^]*), s); const blockMatch content.match(blockRegex); return blockMatch ? blockMatch[1].trim() : Block ${blockId} not found in ${fileName}; } catch (e) { return File ${fileName} not found; } } // 示例调用 console.log(extractBlock(/Users/me/ObsidianVault, [[2025-04-10]]#^1a2b3c));这个脚本解决了 Copilot 最大痛点它不知道 Obsidian 块链接指向哪里。运行脚本后Copilot 看到的不再是晦涩链接而是真实任务内容“ [!task]- 完成支付风控规则配置\n\ndue:: 2025-04-10\nassignee:: dev-team\npriority:: P0”。Step 3Copilot 提示词工程Prompt Engineering在 VS Code 中我为不同场景预设了3套提示词模板通过快捷键一键调用CtrlAltDDaily Summary你是一名资深项目经理请基于以下已完成任务块生成一段专业、简洁、含量化结果的今日工作总结。要求1. 用中文2. 每项任务用分号分隔3. 必须包含具体成果指标如覆盖率、响应时间、完成率4. 不超过100字。任务块CtrlAltWWeekly Report请将以下7天内的任务完成记录按项目分组汇总为周报。每组包含项目名称、本周完成数/总数、关键成果最多3条、主要阻塞如有。格式为Markdown表格。CtrlAltRRetrospective基于以下阻塞项和思考碎片分析根本原因并提出1条可执行改进措施。要求原因分析用‘因为...所以...’句式措施必须包含具体动作、负责人、时间节点。实操心得Copilot 的输出质量80%取决于提示词。我测试过“生成周报”和“按项目分组汇总为周报”产生的结果差异巨大——前者得到泛泛而谈的段落后者输出结构化表格。提示词必须像写SQL一样精确告诉模型“你要做什么、输入是什么、输出格式是什么、约束条件是什么”。Step 4一键执行工作流最终我把上述步骤封装为 VS Code 任务tasks.json{ version: 2.0.0, tasks: [ { label: Generate Daily Summary, type: shell, command: node ~/scripts/obsidian-block-extractor.js copilot --prompt CtrlAltD, group: build } ] }现在我只需在 Obsidian 中复制任务块链接切到 VS Code 按CtrlShiftP输入 “Tasks: Run Task”选择 “Generate Daily Summary”10秒内就得到可直接粘贴到企业微信的总结文案。这个闭环里Obsidian 负责数据真实性和关系完整性Copilot 负责语义表达和格式转换两者各司其职毫无冗余。4. 实操全流程演示以“上线新用户积分系统”项目为例4.1 项目启动从白板到可执行任务树的72小时假设我要启动“上线新用户积分系统”项目。传统做法是开需求评审会、写PRD、建Jira Epic。在我的 Obsidian 工作流中启动过程被压缩为3个连续动作Day 0立项当天创建项目主笔记Projects/2025-Q2/积分系统上线.md内容如下--- project-id: PTS-2025-001 start-date: 2025-04-01 end-date: 2025-04-30 owner: product-lead status: planning --- ## 目标 上线新用户积分系统支撑Q2拉新目标50万首月用户活跃度提升15%。 ## 关键里程碑 - 4月10日完成技术方案评审 - 4月20日UAT环境部署完成 - 4月28日灰度发布10%流量 ## 关联文档 - [[2025-04-01]]#^abc123需求脑图 - [[2025-04-01]]#^def456技术方案初稿在2025-04-01每日笔记中用 Templater 快捷键CtrlShiftT创建首个任务块 [!task]- 召开积分系统需求评审会\ndue:: 2025-04-02\nassignee:: product-lead\npriority:: P0保存后Kanban 看板To Do列自动出现该卡片点击“来源”直达今日笔记。Day 1需求评审后会议结束我在2025-04-02笔记中记录结论并为每个子任务创建原子块 [!task]- 输出积分规则V1.0文档\ndue:: 2025-04-05\nassignee:: pm\npriority:: P1 [!task]- 评审风控对接方案\ndue:: 2025-04-06\nassignee:: tech-arch\npriority:: P1同时在项目主笔记PTS-2025-001.md的## 关联文档下追加- [[2025-04-02]]#^ghi789评审结论此时Dataview 查询FROM #status/todo WHERE contains(file.name, PTS-2025-001)已能生成该项目的完整待办清单无需任何额外维护。Day 2技术方案确认技术负责人在2025-04-03笔记中提交方案我用CtrlK将 [!task]- 评审风控对接方案状态切换为in-progress。Kanban 看板自动将该卡片移至In Progress列且卡片底部显示“来源[[2025-04-03]]#^jkl012”点击即见方案全文。我用 VS Code 的CtrlAltD快捷键将今日所有#status/in-progress任务块喂给 Copilot生成日报“积分系统项目进入技术攻坚阶段风控对接方案已启动评审预计4月6日完成积分规则文档编写进度达60%。当前无阻塞项。”这个72小时流程没有新建任何外部文档所有信息都在 Obsidian 图谱中自然生长。项目主笔记是目录每日笔记是日记任务块是细胞看板是显微镜Copilot 是翻译官——它们共同构成一个活的项目生命体。4.2 执行监控如何用看板视图一眼识别项目健康度看板不是装饰品而是诊断仪表盘。我每天花3分钟扫视 Kanban 视图就能判断项目是否脱轨。关键看三个信号信号1列宽异常Column Width Anomaly正常情况To Do列宽度 ≈In Progress列宽度 × 1.5因任务分解后子任务数增加危险信号In Progress列异常宽大且多数卡片“来源”链接指向同一份笔记如都来自2025-04-05会议纪要根本原因任务未有效拆解多个责任人挤在同一个模糊任务下。应对立即在2025-04-05笔记中用AltEnter将“完成风控对接”拆为3个原子块“① 输出风控接口契约文档”、“② 编写风控Mock服务”、“③ 设计风控降级策略”并分配不同负责人。信号2阻塞项聚集Blocked Cluster正常情况Blocked列每月出现1-2次每次1-2张卡片危险信号Blocked列连续3天新增卡片且“负责人”字段均为external-vendor根本原因对外依赖管理失效未设置缓冲期或备选方案。应对在项目主笔记中新增## ⚠️ 外部依赖区块列出所有供应商SLA并用 Dataview 查询FROM #status/blocked WHERE assignee external-vendor自动生成风险预警表。信号3完成项断层Done Gap正常情况Done列每日有3-5张卡片均匀分布于不同项目危险信号Done列连续2天为空或某天突然涌入10卡片根本原因前者是进度滞后后者是“虚假繁荣”集中补录而非真实交付应对用 Dataview 查询LIST FROM #status/done WHERE file.mday date(today) - dur(1 day)若结果为空则触发 Copilot 生成预警“检测到昨日无完成项建议检查① 任务状态标签是否遗漏② 是否存在未标记的隐性工作③ 项目计划是否过于激进”。这些信号全部基于原始数据自动计算无需人工统计。某次我通过Blocked列聚集发现70%阻塞源于法务合同审核于是推动法务部将标准合同模板放入 Obsidian 公共库后续同类项目阻塞时长从平均5天降至0.5天。4.3 每日总结自动化Copilot 如何把10分钟手工活压缩到15秒每日总结最耗时的不是写内容而是“找内容”。传统方式要翻看聊天记录、会议纪要、代码提交再手动摘录。我的 Copilot 协同协议让这个过程全自动Step 1数据准备Obsidian 端每天下班前我在2025-04-10笔记中将所有完成任务块打上#status/done标签并确保due::字段准确。Dataview 插件实时生成## ✅ 已完成区块内容为- [[2025-04-09]]#^mno345 → 完成风控接口契约文档初稿 - [[2025-04-10]]#^pqr678 → 评审积分规则V1.0文档 - [[2025-04-10]]#^stu901 → 部署UAT环境基础镜像Step 2Copilot 调用VS Code 端全选上述3行右键 “Copy as Plain Text”切到 VS Code新建临时文件粘贴内容按CtrlAltDCopilot 在2秒内输出“今日聚焦积分系统上线① 风控接口契约文档V1.0初稿完成已邮件同步技术团队② 积分规则V1.0文档通过产品与运营联合评审共识率达100%③ UAT环境基础镜像部署成功CI/CD流水线已打通。三项工作均按计划节点达成。”Step 3结果校验与发布我快速核对三点① 数值是否准确Copilot 未虚构“共识率100%”该数据来自会议纪要中的投票记录② 时间是否匹配所有任务确为今日完成非昨日补录③ 术语是否专业用“CI/CD流水线”而非“自动部署工具”确认无误后复制整段文字粘贴至企业微信项目群。全程15秒。注意事项Copilot 可能产生“幻觉”比如将“评审文档”扩写为“评审并通过文档”。我的应对策略是——永远不信任 Copilot 的动词时态。在提示词中强制要求“若原文为‘评审’输出必须用‘评审’若原文为‘完成’输出必须用‘完成’”。同时所有关键数据如“共识率100%”必须源自 Obsidian 中已存在的量化记录Copilot 只负责串联不负责创造。这套流程让我从“总结撰写者”转变为“总结审核者”精力真正聚焦在决策判断上而非文字搬运。5. 常见问题与避坑指南那些只有踩过才知道的硬核经验5.1 看板类问题为什么我的卡片总不显示90%的根源在这3个地方问题1卡片显示“No results”但数据明明存在表象Kanban 看板列标题正常但下方空白根本原因Dataview 查询语句中的FROM路径错误。常见错误包括用了FROM Projects带引号而非FROM Projects不带引号路径大小写不匹配Obsidian 在 macOS/Linux 区分大小写projects≠Projects查询中用了WHERE file.tags #status/done错误正确应为WHERE #status/doneDataview 的 tag 查询语法是空格分隔非等号解决方案在 Obsidian 命令面板CtrlP输入 “Dataview: Open Query Console”粘贴你的查询语句实时查看错误提示。90%的此类问题控制台会明确指出“Unknown field ‘file.tags’”。问题2拖拽卡片后原始任务块状态未更新表象在 Kanban 看板中把卡片从To Do拖到Done但原始笔记里的任务块仍是#status/todo根本原因Kanban 插件的 “Auto-sync with tags” 功能未正确配置或你使用了自定义卡片模板但未包含状态更新逻辑。解决方案关闭 Auto-sync改用快捷键CtrlK切换状态。这是唯一100%可靠的方案。Kanban 的拖拽本质是UI交互而 Obsidian 的数据权威在笔记本身强行让UI驱动数据更新必然导致竞态条件。问题3看板列排序混乱任务不按截止日排列表象In Progress列中4月30日截止的任务排在4月10日截止的任务前面根本原因查询语句中SORT due ASC未生效因为due字段不是 Frontmatter而是普通文本。Dataview 只能对 Frontmatter 字段排序。解决方案在任务块中必须用标准 Frontmatter 语法 [!task]- 完成风控对接 due:: 2025-04-10 assignee:: tech-arch而非 [!task]- 完成风控对接截止2025-04-10后者 Dataview 无法解析due字段排序自然失效。5.2 Copilot 类问题为什么 Copilot 总是“一本正经地胡说八道”问题1Copilot 生成的内容与原始任务完全无关表象输入[[2025-04-10]]#^pqr678Copilot 却输出关于“用户增长策略”的长篇大论根本原因VS Code 未正确加载 Obsidian Vault或obsidian-block-extractor.js脚本路径错误导致 Copilot 接收到的输入是空字符串或错误提示。解决方案在 VS Code 终端中手动运行node ~/scripts/obsidian-block-extractor.js [[2025-04-10]]#^pqr678
