OpenClaw普通人入门指南：本地AI分身搭建与成本安全实践

1. 这不是玩具，是普通人能亲手养活的“数字分身”

OpenClaw 这个名字最近在技术圈里被反复提起，但很多人点开文档第一眼就皱眉：又是 Agent、又是 Workflow、又要写 YAML 配置、还要对接 API 密钥……好像离“普通人”三个字十万八千里。我完全理解这种感受——去年冬天我第一次在 GitHub 上看到 OpenClaw 的 README 时，也下意识关掉了页面，心想：“这玩意儿怕不是给大厂 SRE 或 AI 工程师写的”。

但三个月后，我把它装进了自己那台用了四年的 Mac Mini（M1 芯片），每天早上七点自动拉起一个 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/千Token，2.4亿就是 ¥2400/7天，年化超 ¥12.4万。而套餐价 ¥1608，相当于打了1.3% 的折扣。这不是优惠，是生存必需。

再看本地模型路线。我用的是 Mac Studio（M2 Ultra），部署了 Qwen3.5 系列四个尺寸模型：27B（主干推理）、9B（中等任务）、4B（快速响应）、2B（纯文本过滤）。硬件成本是沉没成本，但电费和显存占用是真金白银：

• 27B 模型在 MLX 框架下，满载推理功耗约 42W，按每天运行 18 小时计算，月均电费 ≈ ¥12.6（按工业电价 ¥0.85/kWh 计）；
• 9B 模型功耗约 18W，同理月均 ≈ ¥5.5；
• 4B/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)	MLX	1.8s	4.2GB	52℃（风扇静音）	待机 12W / 负载 48W
Windows 笔记本 (i7-11800H + RTX3060)	Ollama + CUDA	4.3s	6.8GB	89℃（风扇狂转）	待机 28W / 负载 112W
Linux 服务器 (AMD EPYC 7742)	vLLM	2.1s	5.1GB	67℃	待机 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"

这个配置背后，是一次真实的惊魂时刻。某天我测试一个“自动清理临时文件夹”的 Workflow，Prompt 里写了“请删除 /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.ownerAllowFrom：

channels: 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: "[e-mail]"

这意味着：即使有人在群里 @ 虾哥说“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"), (r"sk-[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(encoding='utf-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(f'telegram-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 方案：

1. 在 Telegram 里创建一个专用频道@MyArticleInbox；
2. 当你在微信/知乎看到好文章，直接长按分享→“复制链接”→粘贴到该频道；
3. OpenClaw 监听该频道，自动抓取网页内容、提取标题/作者/正文/发布时间；
4. 生成标准 Markdown 文件，按日期归档到 Obsidian 的Articles/2024/06/目录下，并自动添加 Dataview 查询所需的 YAML Frontmatter。

核心配置（workflows/article_inbox.yaml）：

name: "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（原始链接） - summary（200 字以内摘要，突出核心观点） 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 方案：

1. 使用 GitHub REST API 获取所有仓库的最新状态；
2. 本地运行 Python 脚本解析数据，生成结构化报告；
3. 用 GLM5 大模型对关键问题（如失败的 CI、高危 Dependabot PR）生成中文解读；
4. 每天早上 7:30，将报告推送到 Telegram 私聊。

核心配置（workflows/github_daily.yaml）：

name: "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 方案：

1. 会议软件（Zoom/腾讯会议）设置自动保存录音到指定文件夹；
2. OpenClaw 监听该文件夹，检测到新.m4a文件即触发；
3. 用 Whisper.cpp 本地转写（不传云端，保隐私）；
4. 用 GLM5 对转写文本做摘要、提取 Action Items、标记关键决策点；
5. 生成 Markdown 报告，自动存入 Obsidian 的Meetings/2024/06/目录。

核心配置（workflows/meeting_transcribe.yaml）：

name: "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%，且推理速度更快。模型文件只有 380MB，Mac 上跑得飞快。

4.4 场景四：Obsidian 笔记自动标签与关联（让知识库真正“活”起来）

痛点：Obsidian 里笔记越来越多，但彼此孤立。想查“大模型推理优化”，得手动翻找十几篇相关笔记，无法自动聚类。

OpenClaw 方案：

1. 每天凌晨 3 点扫描新增的 Markdown 文件；
2. 用本地 Qwen3.5-9B 提取每篇笔记的 3-5 个核心关键词；
3. 用 GLM5 分析关键词之间的语义关系，自动生成[[ ]]双链；
4. 更新笔记 Frontmatter 中的tags和related字段。

核心配置（workflows/obsidian_enhance.yaml）：

name: "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瞬间聚合所有相关内容；
• 双链关系自动建立，点击一个关键词，就能顺着关系网跳转到所有相关笔记；
• 避坑心得：最初用大模型一次性处理所有新笔记，