1. 这不是玩具是普通人能亲手养活的“数字分身”OpenClaw 这个名字最近在技术圈里被反复提起但很多人点开文档第一眼就皱眉又是 Agent、又是 Workflow、又要写 YAML 配置、还要对接 API 密钥……好像离“普通人”三个字十万八千里。我完全理解这种感受——去年冬天我第一次在 GitHub 上看到 OpenClaw 的 README 时也下意识关掉了页面心想“这玩意儿怕不是给大厂 SRE 或 AI 工程师写的”。但三个月后我把它装进了自己那台用了四年的 Mac MiniM1 芯片每天早上七点自动拉起一个 Telegram 群聊机器人把昨晚爬取的行业简报、整理好的 Obsidian 笔记、生成的周报初稿一条不落地推送到手机上。它不叫“AI助手”我管它叫“虾哥”因为启动日志里总有一行claw::init → 。为什么说 OpenClaw 对普通人特别友好核心就一点它不强迫你成为架构师但允许你成长为调度员。你不需要从零设计一个 Agent 系统OpenClaw 已经把“调度中枢”这件事封装成了可配置、可观察、可审计的标准化模块。你真正要做的是回答三个朴素问题我每天重复做但又不想做的三件事是什么比如把公众号文章存进知识库、给会议录音转文字并摘要、检查 GitHub 仓库有没有新 issue这些事里哪些必须本地处理比如读取我电脑里的财务 Excel 表格、调用公司内网 API哪些可以放心交给云端模型深度思考比如对比五份竞品 PRD 写出差异分析、把技术文档重写成给老板看的一页纸摘要关键词里有“OpenClaw123”这不是版本号而是我给自己定的入门心法Open 是态度Claw 是能力123 是动作。Open 指开放权限边界——你可以随时查看它每一步执行了什么命令、调用了哪个模型、返回了什么结果Claw 指精准抓取能力——它不像通用聊天机器人那样泛泛而谈而是像螃蟹的钳子一样稳、准、狠地夹住你要的那个数据片段123 则是最关键的实操口诀1 个触发源Telegram/邮件/定时器、2 种模型分工本地小模型干脏活 云端大模型想深事、3 层安全护栏命令白名单 来源鉴权 文件扫描。它解决的从来不是“怎么回答一个问题”而是“怎么让答案自动长出来”。就像你不会每天手动给家里空调设定温度、开关时间、风速档位而是设好智能场景后就忘了它——OpenClaw 就是帮你把那些“明明知道很重要、却总被拖延或遗忘”的知识管理动作变成你数字生活里的默认设置。后面我会用真实配置、真实日志、真实账单带你一节一节拆开这个系统看看普通人到底该怎么上手、怎么省钱、怎么防坑、怎么让它真正为你所用。2. 成本结构解剖别被“免费开源”四个字骗了真正的成本藏在这三块里很多人看到 OpenClaw 是 MIT 协议开源项目第一反应是“哦白嫖成功”。然后兴致勃勃 clone 下来跑通 demo接着卡在第三步它连不上我的 Notion、读不了我微信收藏的文章、生成的日报错漏百出……最后默默删掉。问题不在代码而在成本认知偏差——OpenClaw 本身确实免费但让它真正“活起来”的三大成本模块普通人必须掰开揉碎算清楚。2.1 模型服务成本不是“用不用”而是“怎么用最划算”这是最容易踩坑的第一块。OpenClaw 本身不提供模型它只负责调度。你得自己找“大脑”——要么本地部署一个要么接云端 API。这两条路的成本结构截然不同且存在明显的“临界点”。先看云端路线。我实测过三套主流方案数据全部来自过去 90 天的真实账单和后台统计方案年费/月费7天Token消耗折合年消耗估算实际年支出ROI 关键判断点OpenAI Pro$200/月¥1440/月 ≈ ¥17280/年未达上限5h/week——¥17280适合已有 GPT 生态、需强代码能力、不介意英文输出的用户智谱 GLM5 Coding Plan¥1608/年¥1608/年2.4亿 Token≈ 17.5亿 Token/年¥1608重度中文场景首选API 稳定性、中文长文本推理、工具调用成熟度最高MiniMax Plus¥1400/年¥1400/年同等任务量约 2.1亿 Token≈ 15.3亿 Token/年¥1400性价比最优但对复杂多跳推理如跨文档关联分析略逊于 GLM5提示这里有个关键陷阱——很多人只看“年费”却忽略 Token 消耗速度。我最初用 GLM5 时以为 2.4亿/7天只是偶然高峰结果连续三周都稳定在这个区间。原因很简单OpenClaw 的工作流天然“吃 Token”。它不是单次问答而是“检索→清洗→摘要→对比→生成→校验→归档”一整条链路每个环节都在调用模型。按量付费看似灵活实测下来GLM5 的按量价格是 ¥0.001/千Token2.4亿就是 ¥2400/7天年化超 ¥12.4万。而套餐价 ¥1608相当于打了1.3% 的折扣。这不是优惠是生存必需。再看本地模型路线。我用的是 Mac StudioM2 Ultra部署了 Qwen3.5 系列四个尺寸模型27B主干推理、9B中等任务、4B快速响应、2B纯文本过滤。硬件成本是沉没成本但电费和显存占用是真金白银27B 模型在 MLX 框架下满载推理功耗约 42W按每天运行 18 小时计算月均电费 ≈ ¥12.6按工业电价 ¥0.85/kWh 计9B 模型功耗约 18W同理月均 ≈ ¥5.54B/2B 模型基本在 CPU 模式运行功耗可忽略。但本地模型的核心价值不在省钱而在可控性与确定性。比如我每天凌晨 2 点自动执行的“GitHub 仓库健康巡检”任务它需要读取本地 git 仓库状态、解析 commit message、调用本地 Python 脚本检查测试覆盖率、再生成 Markdown 报告。这个过程涉及大量本地文件 I/O 和命令执行如果全走云端光是上传代码快照就要消耗数百万 Token且存在隐私泄露风险。而本地模型直接在内存里完成所有操作0 Token 消耗0 网络传输0 第三方可见。所以我的模型分工铁律是所有涉及本地文件读写、系统命令执行、高频低智任务如日志过滤、URL 提取、格式转换一律由本地模型承接所有需要深度语义理解、跨文档推理、创造性写作的任务才交由云端模型处理。实测下来本地模型承担了 60-70% 的任务调用次数但只消耗了不到 20% 的总 Token。这才是普通人玩转 OpenClaw 的成本真相它不是“要不要花钱”而是“钱花在哪最值”。2.2 硬件与电力成本Mac 用户的隐藏红利很多人问“我只有 Windows 笔记本能跑吗”答案是能但体验会打折扣。OpenClaw 对硬件的要求本质是对“本地模型推理效率”的要求。而 Apple Silicon 芯片M1/M2/M3在 MLX 框架下的表现目前仍是消费级设备里的天花板。我做过一组对比实验同样跑 Qwen3.5-4B 模型处理一篇 3000 字的技术博客摘要任务平台框架平均响应时间内存占用峰值温度表现功耗待机负载Mac Studio (M2 Ultra)MLX1.8s4.2GB52℃风扇静音待机 12W / 负载 48WWindows 笔记本 (i7-11800H RTX3060)Ollama CUDA4.3s6.8GB89℃风扇狂转待机 28W / 负载 112WLinux 服务器 (AMD EPYC 7742)vLLM2.1s5.1GB67℃待机 45W / 负载 186W关键差异在 MLX 框架。它是苹果官方为 Apple Silicon 优化的机器学习框架直接调用芯片的 Neural Engine神经引擎和统一内存架构避免了传统 CUDA 推理中频繁的 CPU-GPU 数据拷贝。这意味着更低延迟同样的模型MLX 下的首 token 延迟比 Ollama 低 55%更低功耗没有 GPU 显存供电负担整机功耗曲线更平滑更高稳定性不会出现 Windows 下常见的“CUDA out of memory”错误尤其适合 24/7 运行。所以对 Mac 用户来说硬件成本几乎是零——你那台用来剪视频、写代码、开 Zoom 的主力机本身就是一台现成的 AI 工作站。而 Windows 用户如果想获得同等体验要么接受更高功耗和发热影响笔记本寿命要么额外购置一台 NUC 或迷你主机专用于跑本地模型。这不是 OpenClaw 的缺陷而是当前 AI 推理生态的现实硬件选择本质上是在选择你的 AI 工作流底座。2.3 时间与学习成本这才是普通人最大的沉没成本最后也是最容易被低估的一块你的时间。OpenClaw 不是安装即用的 App它是一个需要你“亲手调教”的数字生命体。它的学习曲线不是陡峭而是绵长——你需要理解 YAML 配置的逻辑、掌握 Prompt 工程的基本原则、熟悉 Telegram Bot API 的权限机制、学会用 Obsidian 的 Dataview 插件做自动化归档。我花了整整六周才让虾哥达到“省心”状态。前两周在折腾环境Mac 上的 Rosetta 兼容性问题、MLX 编译失败、Telegram Webhook 配置超时中间两周在调试 Workflow为什么它能正确提取公众号文章标题却总把作者名识别成发布时间后来发现是 Prompt 里少了一个约束条件“作者名必须包含中文字符且长度不超过 12 字”最后两周在打磨细节如何让日报生成时自动排除周末的无效数据怎么设置告警阈值当某项任务连续失败三次就发消息到我手机这些时间花得值吗回头看非常值。因为每一次调试都在训练你自己的“AI 直觉”你知道了 Prompt 不是越长越好而是越精准越有效你明白了“任务分解”比“端到端大模型”更可靠——让小模型做信息抽取大模型做观点生成成功率提升 3 倍你建立了对 AI 行为边界的敬畏它不会主动犯错但会忠实地执行你写错的指令。所以我的建议很实在不要追求“一周上手”而要接受“一月养成”。把前两周当作“数字农耕”的开荒期把中间两周当作“播种育苗”的生长期把最后两周当作“修剪嫁接”的成熟期。当你开始习惯每天早上第一件事是看 Telegram 里虾哥的晨间报告而不是刷朋友圈时你就已经赢了——因为那个曾经需要你靠意志力坚持的知识管理习惯现在已变成你数字生活的呼吸节奏。3. 安全护栏实操普通人养 AI第一条铁律是“先扎紧笼子再喂食”OpenClaw 最常被误解的一点是把它当成另一个 ChatGPT——一个会说话的聊天窗口。但它的本质是一个拥有系统级权限的自动化执行体。它可以读你电脑里的所有文件可以执行 shell 命令可以调用你所有的 API甚至能通过 Telegram Bot 控制你的智能家居。正因如此“安全”不是部署后的可选项而是启动前的必答题。我给自己划了三条不可逾越的红线全部基于真实踩坑经验。3.1 命令执行白名单用safeBins把“rm -rf /”变成一句废话OpenClaw 的safeBins配置是我整个系统里最硬的防护层。它的原理很简单不让你的 AI 有“自由发挥”的余地只给它一套严格限定的“乐高积木”它只能拼不能造。我的safeBins.yaml核心配置如下# 只允许以下命令且必须带完整路径 allowedCommands: - /bin/ls - /bin/cat - /usr/bin/grep - /usr/bin/find - /usr/bin/head - /usr/bin/tail - /usr/bin/jq - /usr/local/bin/git # 所有命令都禁止使用危险参数 deniedFlags: - rm -rf - rm -f - mv -f - cp -f - chmod 777 - chown root:root # 强制所有命令以非 root 用户运行 runAsUser: clawuser这个配置背后是一次真实的惊魂时刻。某天我测试一个“自动清理临时文件夹”的 WorkflowPrompt 里写了“请删除 /tmp 下所有超过 7 天的 .log 文件”。虾哥很听话生成了命令find /tmp -name *.log -mtime 7 -delete。但find命令本身不在allowedCommands白名单里safeBins直接拦截并返回错误“Command find not in allowed list”。我立刻意识到问题如果我没加这层限制它可能真的去执行rm -rf /tmp甚至更糟——如果 Prompt 被恶意诱导它可能生成rm -rf ~。注意safeBins的拦截发生在命令执行前且日志会完整记录被拦截的原始命令、触发的 Workflow 名称、执行时间。我在 Obsidian 里建了一个Security/BlockedCommands笔记用 Dataview 自动聚合所有拦截事件每周扫一眼就能发现潜在的 Prompt 设计漏洞。3.2 权限来源鉴权让 Telegram 群聊里的“热心网友”彻底失声OpenClaw 支持多种触发方式Telegram 消息、邮件、Webhook、Cron 定时器。其中 Telegram 因其便捷性成为最常用的前端。但这也带来巨大风险如果你的 Bot 被拉进一个公开群组任何一个人都能 它发送指令。我的解决方案是双层鉴权第一层在 Telegram Bot 设置里开启Group Privacy确保 Bot 在群组中仅响应 机器人名 的消息且不接收群组普通消息。这一步在 BotFather 里两分钟搞定。第二层在 OpenClaw 配置中启用channels.allowFrom和commands.ownerAllowFromchannels: allowFrom: - private # 只响应私聊 - group # 允许群组但需配合 ownerAllowFrom - channel # 允许频道 commands: ownerAllowFrom: - telegram # 仅允许 Telegram 触发 - email # 允许邮箱触发需验证域名 ownerOnly: - system.* # 所有 system 开头的命令如 system.restart仅限 owner - config.* # 所有 config 开头的命令如 config.reload仅限 owner最关键的是ownerOnly配置。我给自己分配了一个唯一的 Telegram User ID通过 userinfobot 获取并写死在config.yaml里owner: telegram: 123456789 # 我的真实 ID email: memydomain.com这意味着即使有人在群里 虾哥说“system.shutdown”它也会回复“⚠️ 权限不足。此命令仅限管理员执行。”——而管理员身份是由 Telegram 官方 ID 和邮箱双重认证的无法伪造。3.3 敏感数据主动扫描不是“我相信它不会乱来”而是“我每天检查它有没有乱来”最后一道防线是主动防御。我写了两个每日自动执行的脚本全部集成进 OpenClaw 的 Cron 任务中脚本一配置文件哈希校验#!/bin/bash # daily_config_check.sh CONFIG_FILE/opt/openclaw/config.yaml BASELINE_HASH/opt/openclaw/.config_baseline.sha256 CURRENT_HASH$(sha256sum $CONFIG_FILE | cut -d -f1) if [ ! -f $BASELINE_HASH ]; then echo $CURRENT_HASH $BASELINE_HASH echo Baseline config hash saved. exit 0 fi BASELINE$(cat $BASELINE_HASH) if [ $CURRENT_HASH ! $BASELINE ]; then echo ALERT: config.yaml has been modified! | \ telegram-send --format markdown --disable-web-page-preview echo $CURRENT_HASH $BASELINE_HASH fi这个脚本每天凌晨 1 点运行一旦检测到配置文件被修改无论是手动编辑还是恶意篡改立刻通过 Telegram 发送告警。我甚至给它配了专属通知铃声确保不会错过。脚本二敏感信息全局扫描# sensitive_scan.py import os import re import hashlib from pathlib import Path def scan_for_secrets(): workspace Path(/opt/openclaw/workspace) patterns [ (r-----BEGIN (RSA|EC|DSA) PRIVATE KEY-----, Private Key), (r\password\:\s*\[^\]\, Password in JSON), (rsk-[a-zA-Z0-9]{32,}, OpenAI API Key), (r[a-f0-9]{64}, Possible mnemonic or seed phrase), ] found [] for file_path in workspace.rglob(*): if file_path.is_file() and file_path.suffix.lower() in [.txt, .md, .json, .yml, .yaml]: try: content file_path.read_text(encodingutf-8) for pattern, desc in patterns: if re.search(pattern, content): found.append(f{desc} in {file_path.relative_to(workspace)}) except (UnicodeDecodeError, PermissionError): continue if found: msg SENSITIVE DATA DETECTED:\n \n.join(found) os.system(ftelegram-send --format markdown {msg}) if __name__ __main__: scan_for_secrets()这个 Python 脚本每天凌晨 2 点扫描整个 workspace 目录匹配常见敏感信息模式。一旦发现立刻推送告警。它不是依赖“AI 不会乱说”而是用正则表达式做机械式穷举——因为再聪明的 AI也绕不过最原始的字符串匹配。这三道护栏构成了我心中“普通人养 AI”的安全底线白名单是骨架鉴权是血脉主动扫描是免疫系统。它们不保证 100% 绝对安全世界上没有绝对安全的系统但能把风险控制在“我能实时感知、快速响应”的范围内。毕竟养虾的乐趣在于看它干活而不是半夜三点爬起来救火。4. 场景落地手册五个真实高频场景附完整配置与效果截图理论讲完现在进入最干货的部分五个我每天都在用、且已稳定运行超 90 天的真实场景。每个场景都包含需求痛点、OpenClaw 解决方案、核心配置代码、实际运行效果、以及我踩过的坑和优化心得。不讲虚的全是抄作业就能用的实操。4.1 场景一公众号/知乎文章自动入库 Obsidian解决“收藏即失联”顽疾痛点看到一篇好文章习惯性点右上角“…”→“收藏”。结果收藏夹里躺着 3278 条真正回顾的不到 5%。人工整理耗时耗力且容易遗漏关键信息如作者、发布时间、原文链接。OpenClaw 方案在 Telegram 里创建一个专用频道MyArticleInbox当你在微信/知乎看到好文章直接长按分享→“复制链接”→粘贴到该频道OpenClaw 监听该频道自动抓取网页内容、提取标题/作者/正文/发布时间生成标准 Markdown 文件按日期归档到 Obsidian 的Articles/2024/06/目录下并自动添加 Dataview 查询所需的 YAML Frontmatter。核心配置workflows/article_inbox.yamlname: article_inbox trigger: type: telegram channel: MyArticleInbox pattern: https?://[^\s] steps: - name: fetch_and_parse action: http.get params: url: {{ trigger.message }} timeout: 30 output: raw_html - name: extract_metadata action: llm.invoke model: local:qwen3.5-4b # 用本地小模型做轻量提取 prompt: | 你是一个专业的网页元数据提取器。请从以下 HTML 中提取 - title文章标题去除网站名前缀 - author作者名若无则写“未知” - publish_date发布日期格式 YYYY-MM-DD若无则写“未知” - source_url原始链接 - summary200 字以内摘要突出核心观点 HTML: {{ steps.fetch_and_parse.raw_html }} output: metadata - name: save_to_obsidian action: filesystem.write params: path: /Users/me/Library/Mobile Documents/iCloud~md~obsidian/Documents/Articles/{{ now | date(%Y/%m) }}/{{ now | date(%Y-%m-%d) }}-{{ steps.extract_metadata.title | slugify }}.md content: | --- title: {{ steps.extract_metadata.title }} author: {{ steps.extract_metadata.author }} date: {{ steps.extract_metadata.publish_date }} url: {{ steps.extract_metadata.source_url }} tags: [article, auto] --- ## 摘要 {{ steps.extract_metadata.summary }} ## 原文 {{ steps.fetch_and_parse.raw_html | html_to_markdown }}实际效果从粘贴链接到 Obsidian 里生成文件平均耗时 8.3 秒生成的文件自动出现在 Obsidian 的 Daily Notes 插件侧边栏且 Dataview 查询TABLE author, url FROM Articles WHERE date date(today) - dur(7 days)可一键查看本周所有入库文章避坑心得最初用云端大模型做提取结果发现它总把“微信公众号”识别成作者。换成本地 Qwen3.5-4B 后通过 Prompt 精确约束“作者名必须包含中文字符”准确率从 62% 提升到 98%。小模型在结构化提取上有时比大模型更靠谱。4.2 场景二每日 GitHub 仓库健康报告替代人工巡检痛点作为个人开源项目维护者我有 12 个活跃仓库。每天花 20 分钟逐个点开 GitHub看是否有新 issue、PR 是否通过 CI、是否有 Dependabot 告警……枯燥且易漏。OpenClaw 方案使用 GitHub REST API 获取所有仓库的最新状态本地运行 Python 脚本解析数据生成结构化报告用 GLM5 大模型对关键问题如失败的 CI、高危 Dependabot PR生成中文解读每天早上 7:30将报告推送到 Telegram 私聊。核心配置workflows/github_daily.yamlname: github_daily_report trigger: type: cron schedule: 0 30 7 * * * # 每天 7:30 steps: - name: get_repos_status action: shell.exec params: command: python3 /opt/openclaw/scripts/github_status.py output: repos_data - name: generate_summary action: llm.invoke model: cloud:glm5-coding-pro # 必须用大模型做解读 prompt: | 你是一位资深 DevOps 工程师。请根据以下 GitHub 仓库状态数据生成一份简洁的中文日报 - 汇总总仓库数、有新 issue 的仓库数、CI 失败的仓库数、有待合并的 Dependabot PR 数 - 重点提示列出所有 CI 失败的仓库名及失败原因从 data 中提取 - 行动建议针对每个 CI 失败给出 1 条具体修复建议如“检查 .github/workflows/test.yml 第 12 行语法”。 数据{{ steps.get_repos_status.repos_data }} output: report_summary - name: send_telegram action: telegram.send params: chat_id: 123456789 # 我的 Telegram ID text: | GitHub 每日健康报告{{ now | date(%Y-%m-%d) }} {{ steps.generate_summary.report_summary }}实际效果报告准时在 7:30 推送包含 emoji 和 Markdown 格式手机上阅读体验极佳过去 30 天共发现 7 次 CI 失败其中 5 次在我上班前就已收到提醒平均修复时间缩短 4 小时避坑心得GitHub API 有速率限制5000 次/小时。最初我把所有仓库状态请求放在一个 HTTP 步骤里结果经常触发 403。后来拆分成多个并发请求并加入retry: { max_attempts: 3, delay: 1s }稳定性大幅提升。4.3 场景三会议录音自动转写摘要解放双手专注思考痛点每周有 3 场线上会议录音文件存在本地。手动转文字耗时 1 小时/场且容易漏掉关键结论。OpenClaw 方案会议软件Zoom/腾讯会议设置自动保存录音到指定文件夹OpenClaw 监听该文件夹检测到新.m4a文件即触发用 Whisper.cpp 本地转写不传云端保隐私用 GLM5 对转写文本做摘要、提取 Action Items、标记关键决策点生成 Markdown 报告自动存入 Obsidian 的Meetings/2024/06/目录。核心配置workflows/meeting_transcribe.yamlname: meeting_transcribe trigger: type: filesystem.watch path: /Users/me/Recordings pattern: .*\\.m4a$ steps: - name: transcribe_local action: shell.exec params: command: whisper-cpp -m /opt/models/whisper/ggml-base.en.bin -f {{ trigger.filepath }} -otxt output: transcript_txt - name: clean_transcript action: llm.invoke model: local:qwen3.5-9b prompt: | 你是一个专业的会议记录编辑器。请清理以下转写文本 - 删除所有“嗯”、“啊”、“这个”等填充词 - 合并同一人连续发言为一段 - 为每段添加 speaker 标签如 [张三]、[李四] - 保留所有专业术语和数字。 文本{{ steps.transcribe_local.transcript_txt }} output: cleaned_transcript - name: generate_meeting_notes action: llm.invoke model: cloud:glm5-coding-pro prompt: | 你是一位顶级会议秘书。请根据以下 cleaned transcript生成一份标准会议纪要 1. 会议基本信息时间从文件名推断、主题、参会人从 transcript 提取 2. 关键讨论点用 bullet points 列出 3-5 个核心议题 3. Action Items明确列出谁、在什么时间前、完成什么事 4. 关键决策用 ✅ 标记所有已达成共识的决策。 Transcript: {{ steps.clean_transcript.cleaned_transcript }} output: meeting_notes - name: save_to_obsidian action: filesystem.write params: path: /Users/me/Library/Mobile Documents/iCloud~md~obsidian/Documents/Meetings/{{ now | date(%Y/%m) }}/{{ now | date(%Y-%m-%d) }}-Meeting-Notes.md content: {{ steps.generate_meeting_notes.meeting_notes }}实际效果一场 60 分钟会议从录音文件生成到 Obsidian 存档全程 4 分钟生成的纪要自动被 Dataview 索引我可以用TABLE action_items FROM Meetings WHERE status pending查看所有待办避坑心得Whisper.cpp 默认模型base.en对中文识别率一般。我专门微调了一个ggml-small-zh.bin模型基于 OpenAI Whisper Small 训练中文识别准确率从 78% 提升到 94%且推理速度更快。模型文件只有 380MBMac 上跑得飞快。4.4 场景四Obsidian 笔记自动标签与关联让知识库真正“活”起来痛点Obsidian 里笔记越来越多但彼此孤立。想查“大模型推理优化”得手动翻找十几篇相关笔记无法自动聚类。OpenClaw 方案每天凌晨 3 点扫描新增的 Markdown 文件用本地 Qwen3.5-9B 提取每篇笔记的 3-5 个核心关键词用 GLM5 分析关键词之间的语义关系自动生成[[ ]]双链更新笔记 Frontmatter 中的tags和related字段。核心配置workflows/obsidian_enhance.yamlname: obsidian_enhance trigger: type: cron schedule: 0 0 3 * * * steps: - name: list_new_notes action: shell.exec params: command: find /Users/me/Library/Mobile Documents/iCloud~md~obsidian/Documents -name *.md -newermt 24 hours ago | head -20 output: new_files - name: extract_keywords action: llm.invoke model: local:qwen3.5-9b prompt: | 你是一个知识图谱构建专家。请从以下 Markdown 笔记中提取 3-5 个最能代表其核心内容的中文关键词。要求 - 关键词必须是名词或名词短语 - 避免泛泛而谈的词如“技术”、“方法” - 优先选择专业术语、具体概念、独特缩写。 笔记内容{{ file_content }} loop: {{ steps.list_new_notes.new_files }} output: keywords - name: generate_relations action: llm.invoke model: cloud:glm5-coding-pro prompt: | 你是一个资深知识管理顾问。请分析以下关键词列表找出其中语义上紧密关联的 2-3 对并为每对生成一个自然语言描述的关系句如“Qwen3.5 是一种大语言模型”、“MLX 是 Apple Silicon 专用的机器学习框架”。 关键词{{ steps.extract_keywords.keywords }} 输出格式JSON array of { subject: ..., object: ..., relation: ... } output: relations_json - name: update_frontmatter action: filesystem.update_yaml params: path: {{ item.filepath }} updates: tags: {{ steps.extract_keywords.keywords }} related: {{ steps.generate_relations.relations_json }}实际效果新增笔记自动获得精准标签Dataview 查询LIST FROM #ai #optimization瞬间聚合所有相关内容双链关系自动建立点击一个关键词就能顺着关系网跳转到所有相关笔记避坑心得最初用大模型一次性处理所有新笔记