Obsidian 有了（不太精致的）命令行界面
@PlatyHsu：2 月 10 日，Obsidian 宣布新增对命令行界面（CLI）的支持。
由于 Obsidian 用户里的技术人群占比颇高，CLI 也算是一项呼吁很久的功能，之前甚至有不止一个等不及的用户自行 DIY 了「民间版」。之所以官方此时下场，恐怕主要还是为了跟上最近被 Claude Cowork 和 Openclaw 再次带起的 AI agents 风口：图形界面（GUI）是为了人的视觉和物理操作设计的，AI 识别和操作起来效率很低；而 CLI 是纯文本的，确定性强且结构化，方便模型直接编写命令、阅读输出，相较编程 API 又更加简洁，是 AI 自动化的高效选择。
要使用 Obsidian CLI，需要先升级到 1.12 版，并在 Options > General 中启用 Command line interface，按提示调整终端配置后，就可以在终端使用 obsidian 命令操作笔记库了。（目前处于早期测试阶段，需要购买 25 美元的 Catalyst 许可证才能启用。）
obsidian 命令有两种交互模式。第一种是传统的单行命令模式，也就是直接在终端输入带有具体参数的命令，从终端输出获取返回结果，格式形如：
obsidian [command] [parameter=value]... [flag]... [--copy]例如：
# 在今日日志（daily note）中追加内容
obsidian daily:append content="- [ ] Buy groceries"输出类似于:
Added to: journal/D.2026-02-26.md又如：
# 列出所有未完成待办
obsidian tasks todo输出类似于：
- [ ] Buy groceries
. . .由于 Obsidian 支持多个笔记库，可以通过 vault=<name> 参数来指定操作的库，如果省略，则默认使用终端当前工作目录对应的，或当前处于激活状态的笔记库。而在定位具体文件时，可以通过 file=<name> 指定文件名（支持模糊匹配，无需完整路径或后缀），也支持通过 path=<path> 指定（相对于笔记库根目录的）绝对路径。
Obsidian CLI 支持的功能非常可观，从日常笔记的增删查改（create、read、append、prepend、delete、move、rename 等），知识图谱查询（backlinks、links、orphans、deadends、unresolved、tags 等），文件版本管理（diff、history 等），再到插件和主题管理（plugin、theme 等），一应俱全，可以说图形界面绝大多数的功能都能实现（后面会解释为什么）。具体可以参阅 Obsidian CLI 的网页文档和 obsidian help 的输出，这里就不一一列举了。
第二种、也是更实用的模式是交互模式，通过在终端中仅输入 obsidian 进入（如开头截图所展示）。这个模式不算一个全功能的终端用户界面（TUI），更像是一个带命令提示和自动补全的命令构建工具，你可以根据界面上的提示，搜索和选择需要的命令和操作对象。由于 obsidian 有 100 多个二级命令、200 多个参数，用交互模式边搜索边输入可能是比硬记命令更方便的使用方法。
但应当指出，按照传统 CLI 交互的标准，Obsidian CLI 在许多方面都是「不伦不类」的。首先，Obsidian CLI 只在主程序 GUI 运行的情况下才能使用，否则会先自动打开主程序。这不仅在性能上不经济，也断绝了在无桌面环境服务器使用的可能。此外，Obsidian CLI 的命令语法也很古怪。例如，嵌套的子命令使用 daily:append、sync:restore、dev:dom 这样的 namespece 风格命名，而不是更常见的纯空格（形如 git remote add）。此外，所有接受值的参数都采用 parameter=value 的语法，而不是传统的 --parameter value。如果你凭借对 UNIX/Linux 常见命令语法的经验，不看文档就上手 Obsidian CLI，肯定是很容易踩坑的。
之所以会如此，是因为 Obsidian CLI 的设计其实非常「偷懒」。在实现层面，它并不是一个专门为终端环境编写的界面，而只是简单地在 Obsidian 的内部 API 上包装了一层，将终端输入参数解析为 API 格式，然后交给 Obsidian 主程序（一个基于 Electron 的 web 应用）来执行，因此当然要以后者本身已经启动为前提。至于 parameter=value 的语法也完全是为了解析起来方便，因为这样直接从 = 切开就得到了调用 API 的键和值。这也间接解释了 Obsidian CLI 为什么第一版的功能就这么全——将终端命令映射到现成的 API 几乎是没有边际成本的。
（你可以——以 macOS 版为例——从 ~/Library/Application Support/obsidian/ 中找到 obsidian-*.asar 文件，用 npx asar extract 命令将其解包，在其中的 main.js 和 app.js 内搜索 argv 这类典型的终端命令处理关键字，就能看到相关代码。
当然，提及这些并不是要否认 Obsidian 适配 CLI 的努力，只是想说明它显然可以做得更好。
最后，我也简单测试了用 AI agent 操作 Obsidian CLI 的效果。我将 Obsidian CLI 的网页文档和 obsidian help 的输出作为素材发给 Claude Opus 4.6，让它据此生成了一个 SKILL.md 技能文件（全文），放到 Claude Code 的技能路径 ~/.claude/skills/obsidian-cli 下。这样，Claude Code 就能操作 Obsidian 笔记库了。
不过，目前观察操作的效率还是偏低的，即使是 Sonnet 模型，从冷启动到写入一条笔记，至少要花费四五十秒。因此，最好还是将这个技能配合较复杂的场景使用，否则就没有必要浪费这个 token 了。
Android 17 Beta：真的在「战未来」了
@克莱德：因为看得见摸得着的地方确实没什么变化，所以我们就不给 Android 17 的首个 Beta 版本安排首页「具透」了（笑）。但如果你好奇 Google 是不是真的只是在刷版本号，这里还有一些相对枯燥一点、但绝对值得你额外了解的底层更新。
首先是大屏适配。
去年的「三折叠」产品不少，相信你多少也听各位数码区 UP 主吐槽过 Android 软件生态在大屏设备在上的适配情况。折叠屏发展日新月异，但大屏应用体验依然像抽奖，比如不少应用开发者为了省事，可以通过强制设定应用旋转方向这样的方式来避免被厂商的「大屏优化」——所以你会看到有的应用在折叠屏展开之后，用户只能旋转内屏方向、把它当小屏交互的「旋转放大版」来使用。
在厂商间最为主流的 Android 16 版本中，大屏设备会默认忽略应用的方向锁定和尺寸限制，但开发者可以手动写个退出声明让 app「豁免」。但到了 Android 17，大部分类似的奇技淫巧都会被强制拿掉，没有退出机制、没有向下兼容，目标 API 等级为 Android 17（targetSdk 37）的应用都将忽略原有的窗口旋转和尺寸限制，拥有在大屏设备上随意拉伸、放大、变形的「自由」——这肯定会带来一些问题，比如要是真有开发者头铁不搞大屏自适应优化，那轻则应用界面机械缩放变形，重则应用内相机方向混乱、设备使用形态转换（比如外屏到内屏）时应用重载当前界面丢失……另外涉及到目标 API 等级自然就绕不过 Google Play 商店那道经典的计算题，等到 2027 年 8 月 31 日，至少在 Play 商店上架的应用应该都算是大屏友好了。
说到时间，其实大屏适配这部分内容也可以看作是 Google 在为 Android 的未来铺路。早些时候 Google 在 Chromium Bug 追踪页面中意外泄露过 Aluminum OS（ALOS）的桌面截图，后续曝光的内部文件则显示相关合并计划至少要等到 2028 年，而非原定的 2026 年。时间上至少是对得上的。
与之高度相关的，Android 的系统级接力 API（Handoff）也在 Android 17 的更新内容当中。尽管类似的体验在 Apple 和华为鸿蒙生态已经并不新鲜，大量的 Android 厂商确实需要一个平台层面的支持来打破 Android 手机和大屏设备之间的屏障（三星和小米可能也有一部分吧，但笔者并非主力用户记不太清了）。
在返回手势那篇文章中我们提到，Android 应用中大部分看得见、摸得着的交互，都是由活动（activity）来承载的。这种架构方式也让 Android 17 的跨设备接力在实现方式上变得相对简洁直观了一点：开发者只需要给想要接力的活动窗口标注上 setHandoffEnabled(true)，然后就能在另一设备点击同一应用图标时触发 onHandoffActivityRequested() 回调和当前进度的 HandoffActivityData 数据打包，当前视频播放到了几分几秒、文档滚动到了哪一行、或者是购物车里勾选了哪几样商品，都能通过这个数据包传递到另一设备上、调用同一应用的对应活动窗口打开。
虽然看上去比大屏优化还要新，但接力 API 可以说已经具备了一套非常完善的实现机制。Google 目前也考虑到了一些比较特殊的使用情况，比如两端如果都装了同一 App，接收端可以直接通过 Deep Link 启动实现快速恢复，如果接收端没装 App 系统则会拉起浏览器，打开开发者在 HandoffActivityData 里设好的 URL，实现「无缝降级」；另外还有仅传递 URL 链接的 URL Handoff，感觉就适合跨设备书签同步、新闻阅读等场景了。
最后嘛，不知道大家有没有看今天凌晨的三星发布会。Google 真正的「亲儿子」Galaxy S 系列机型这一次又抢先 Pixel 吃上了 Gemini 的新功能。借助与 MCP 协议类似、但完全在本地执行的 AppFunctions 协议，Gemini 可以直接从用户意图中获取对应的应用功能和执行路径，此外 Google 还将在三星 Galaxy S26 和 Pixel 系列机型上开放 UI 自动化操作功能的测试体验。就像年前短时间刷过屏的「豆包手机」那样。
