马上蜗壳 @walk

让手写笔记在你睡觉时自动整理：我的 Goodnotes × OpenClaw 工作流

2026-08-11T14:55:11+08:00

一套不要求你懂「智能体」的个人知识自动化：白天在 Goodnotes 里写，夜里电脑自动整理，第二天在 Telegram 或飞书收到变化摘要。

很多人使用电子笔记的方式，和使用纸质笔记没有本质区别：写完、合上，然后很少再打开。问题并不是不愿意复习，而是整理笔记需要做一连串琐碎工作：找到昨天改过的文件、导出、识别文字、比较新旧版本、提炼重点，再把真正值得行动的内容挑出来。每一步都不复杂，但组合起来足以让人不断拖延。

我现在使用的方案把这些步骤串成了一条自动流水线：

这套流程已经可以稳定处理普通文本、手写笔记、截图和结构草图。它不是「让 AI 随意管理我的文件」，而是让脚本负责确定性的文件工作，让模型只负责它擅长的理解与总结。

Telegram 或飞书里的摘要，只是第二天早晨的回执。真正留下来的，是输出目录里那批结构统一的 Markdown：按笔记生成镜像、按日期留下 diff 与版本、按同一套标题写中文变更摘要。手写 PDF 对人友好、对模型却昂贵且不稳定；标准化文本反过来——人可以扫一眼，AI 日后可以按主题、按时间、按关键词直接检索。一天一份看似平常；几个月后，量变才会变成「我的生活与工作可被组织起来」的质变，接近 MyLifeOrganized 的核心理念：先稳定捕获，再持续整理。

下面先用普通人的语言解释它，再给出一套可以照着复制的完整配置。文末还会说明如何把同一工作流迁移到 Hermes Agent 和 Codex App。

这篇是《把手写变成行动：我的 Goodnotes → Google Drive → Logseq/Obsidian 待办工作流》的续章，侧重自动化管道的完整实现。

先理解四个词

如果你不熟悉智能体，只需要理解四个概念。

脚本是一段固定程序。给它同样的文件，它会执行同样的步骤，例如找到昨天修改的 PDF、复制文件、生成 Markdown。脚本适合做不能出错的机械工作。

提示词是交给 AI 的工作说明。它告诉模型应该读哪些文件、怎样判断变化、输出什么格式。

Skill 可以理解成一份「标准操作手册」。它把脚本、提示说明和使用条件放在一个目录里，让 AI 知道遇到 Goodnotes 任务时应当遵循哪套流程。

定时任务就是闹钟。每天凌晨 3 点，系统启动一次全新的 AI 会话，执行 Skill，然后把结果发给你。

整套系统最重要的设计原则是：文件扫描、命名、版本保留和差异生成交给脚本；理解手写内容、概括变化和提炼重点交给模型。这样既比「让 AI 自己想办法」稳定，也比纯脚本更能理解非结构化手写内容。

准备工作

这套原始实现面向 macOS，因为转换脚本使用系统自带的 PDFKit。你需要：

一台保持开机的 Mac；
Goodnotes iOS/iPadOS 版本；
Google Drive、Dropbox、OneDrive 或 WebDAV 中的一种；
已安装并配置模型的 OpenClaw；
可选的 Telegram Bot 或飞书机器人，用来接收结果。

Goodnotes 官方把「自动备份」定义为单向上传，而不是双向同步：云端修改不会回写 Goodnotes，删除 Goodnotes 文档也不会自动删除云端副本。设置入口是「资料库右上角菜单 → Cloud & Backup → Automatic Backup」。为了让脚本能读取，请选择 PDF，或者同时选择 PDF 与 Goodnotes Document。Goodnotes 自动备份说明

第一次开启后，应让 Goodnotes 保持前台运行，直到初次上传结束。然后在 Mac 上安装对应云盘客户端，确认 PDF 已经成为本地可访问文件。

假设你的路径是：

1
2

源目录：~/Library/CloudStorage/GoogleDrive-你的账号/我的云端硬盘/GoodNotes
输出目录：~/Documents/Goodnotes-Automation/output

真实路径可能因云盘供应商、语言和账号而不同。先在 Finder 中找到目录，再把它拖进终端获取完整路径。

第一步：建立目录

1
2

mkdir -p ~/Documents/Goodnotes-Automation/output
mkdir -p ~/.openclaw/workspace/prompts

为了避免文章中的路径过长，后文使用两个占位符：

1
2

GOODNOTES_SOURCE="$HOME/Library/CloudStorage/GoogleDrive-你的账号/我的云端硬盘/GoodNotes"
GOODNOTES_OUTPUT="$HOME/Documents/Goodnotes-Automation/output"

把「你的账号」替换为本机真实目录名。不要把包含账号、Bot Token、飞书 App Secret 或聊天 ID 的配置上传到公开仓库。

第二步：从 Skills 仓库安装

完整 Skill 已发布在 walkthewalktoday/skills：goodnotes-daily-export。仓库同时保存 SKILL.md 和 Swift 脚本，不再需要从文章中复制几百行代码。

使用 npx skills 安装到 OpenClaw 的全局 Skill 目录：

npx skills add walkthewalktoday/skills \
  --skill goodnotes-daily-export \
  --agent openclaw \
  --global

安装后目录为 ~/.openclaw/skills/goodnotes-daily-export/。

第三步：确认导出脚本可执行

仓库里的脚本只读取源目录；所有生成和清理都发生在输出目录中。安装后为它增加执行权限：

`1`	`chmod +x ~/.openclaw/skills/goodnotes-daily-export/scripts/export_goodnotes_daily.swift`

以后更新 Skill 时运行同一条安装命令，或使用 npx skills update -g，不必再回到文章手工同步代码。

第四步：先手动测试，不要急着定时

把路径替换为你自己的：

swift ~/.openclaw/skills/goodnotes-daily-export/scripts/export_goodnotes_daily.swift \
  --source "$GOODNOTES_SOURCE" \
  --output "$GOODNOTES_OUTPUT" \
  --date 2026-08-10 \
  --verbose

正常输出类似：

TARGET_DATE 2026-08-10
FOUND 1 PDF(s)
PROCESS .../20260804.pdf
WROTE_PDF_VERSION .../20260804--20260810-103247.pdf
WROTE_MD .../20260804.md
WROTE_ASSET .../assets/20260804/page-001.png

检查三件事：Markdown 是否能打开；Markdown 中的相对图片链接是否正常；修改同一份 Goodnotes 笔记、重新备份并再次运行后，是否生成 .diff。

注意： 这里没有运行传统 OCR。PDFKit 只提取 PDF 本来就包含的文字层；手写内容主要靠渲染图片后交给具备视觉能力的模型理解。

第五步：配置接收渠道（Telegram 或飞书）

摘要可以投到 Telegram，也可以投到飞书（国内 Feishu / 国际版 Lark）。按官方文档把对应渠道配好、完成配对即可，凭据放进配置或环境变量，不要写进 Skill。Telegram · 飞书

第六步：直接使用 Skill 内置提示词

完整提示词已经随 Skill 发布在 assets/goodnotes-daily-summary.md，不再需要从文章复制并另存一份。

OpenClaw 全局安装后，提示词位于：

`1`	`~/.openclaw/skills/goodnotes-daily-export/assets/goodnotes-daily-summary.md`

这份提示词负责限制处理范围、区分“没有变化”和“处理失败”、在文字层不足时检查页面图片，并把笔记内容视为数据。源目录与输出目录属于每台机器自己的参数，不写进公共仓库；创建定时任务时动态追加即可。

以后调整摘要格式或安全边界，只需更新 Skill：

`1`	`npx skills update goodnotes-daily-export --global`

第七步：创建 OpenClaw 定时任务

--channel / --to 换成你实际用的渠道即可：Telegram 填数字聊天 ID；飞书私聊填 ou_xxx，群聊填 oc_xxx。

PROMPT_FILE="$HOME/.openclaw/skills/goodnotes-daily-export/assets/goodnotes-daily-summary.md"
MESSAGE="$(
  cat "$PROMPT_FILE"
  printf '\n\n## 本次参数\n- Goodnotes PDF 源目录：%s\n- 输出目录：%s\n' \
    "$GOODNOTES_SOURCE" "$GOODNOTES_OUTPUT"
)"

openclaw cron add \
  --name "goodnotes-daily-export-summary" \
  --description "每天导出并总结前一天变化的 Goodnotes PDF" \
  --cron "0 3 * * *" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "$MESSAGE" \
  --thinking low \
  --timeout-seconds 300 \
  --announce \
  --channel telegram \
  --to "<你的 Telegram Chat ID>"

在较新的 OpenClaw 文档中，openclaw automations create 是推荐入口；openclaw cron add 是很多现有安装仍提供的兼容命令。先运行 openclaw cron --help 或 openclaw automations --help，采用本机支持的形式即可。OpenClaw 定时任务文档

创建后立刻测试：

1
2
3

openclaw cron list
openclaw cron run goodnotes-daily-export-summary
openclaw cron runs --id goodnotes-daily-export-summary --limit 5

不要等到第二天才发现路径或权限配置错误。

一份好的结果应该长什么样

📝 Goodnotes 每日变更摘要

### 20260810：异步任务设计

- 本次变化：新增一张任务流草图，在队列消费者后增加失败重试与人工兜底分支。
- 关键结论：主流程不应等待长任务完成；提交后立即返回，由后台任务更新状态。
- 可执行事项：补充重试次数上限；确认失败任务的告警渠道。
- 识别不确定："补偿队列"旁边有一个手写缩写无法确认。

重点不是让模型把每一笔都转写出来，而是每天用一分钟知道：我昨天到底记录了什么、改变了什么、有哪些值得继续处理的事情。

常见问题与真实边界

为什么不直接让模型遍历整个云盘

因为文件扫描和版本管理是确定性问题。交给脚本更快、更便宜，也更容易审计。模型只处理本次变化，可以显著减少上下文和误判。

为什么保留两个 PDF 版本

Goodnotes 手写笔记经常没有文字层，文本 diff 无法反映真正变化。两个视觉版本足以让模型比较「上一版」和「这一版」，同时避免无限占用磁盘。

会不会漏掉文件

会。默认逻辑只扫描「昨天修改」的文件。如果电脑连续关机数天、云盘延迟同步，或者定时任务失败，需要通过 --date YYYY-MM-DD 补跑。更可靠的生产版应记录「最后成功处理时间」和文件哈希，而不是只依赖自然日。

同名笔记会怎样

示例脚本把不同子目录中的 PDF 平铺到一个输出目录。如果两个文件同名，它们会发生冲突。笔记库存在重名时，应把相对目录编码进输出路径，或为每个源文件生成稳定 ID。

AI 会不会读错手写字

会。视觉模型不是法庭级转录工具。因此提示词要求标出不确定内容，而不是为了让摘要完整而猜词。重要信息仍应回到原 PDF 核验。

电脑必须一直开着吗

本地 OpenClaw Gateway 必须在任务触发时运行，并且云盘文件已经同步到本机。可以使用系统服务让 Gateway 登录后自动启动，也可以把流程部署到始终在线的 Mac 或服务器；但 macOS PDFKit 版本必须运行在 macOS。

如何迁移到 Hermes Agent

假设 Hermes 已安装并能正常使用。迁移时只需装同一个 Skill，再挂上定时任务。

1. 安装 Skill

npx skills add walkthewalktoday/skills \
  --skill goodnotes-daily-export \
  --agent hermes-agent \
  --global
hermes skills list

Skill 通常装到 ~/.hermes/skills/，新会话中生效。Hermes Skill 指南

2. 创建定时任务

直接读取 Hermes 安装目录中随 Skill 提供的提示词，并动态追加本机参数：

PROMPT_FILE="$HOME/.hermes/skills/goodnotes-daily-export/assets/goodnotes-daily-summary.md"
MESSAGE="$(
  cat "$PROMPT_FILE"
  printf '\n\n## 本次参数\n- Goodnotes PDF 源目录：%s\n- 输出目录：%s\n' \
    "$GOODNOTES_SOURCE" "$GOODNOTES_OUTPUT"
)"

hermes cron create "0 3 * * *" "$MESSAGE" \
  --name "goodnotes-daily-export-summary" \
  --skill goodnotes-daily-export \
  --workdir "$HOME" \
  --deliver telegram

--deliver 按你的接收渠道调整：Telegram 用 telegram，飞书用 feishu 或 feishu:<ou_xxx|oc_xxx>。建议顺便固定模型和供应商，避免以后改聊天默认配置时影响定时任务：

1
2
3

hermes cron edit goodnotes-daily-export-summary \
  --model "<模型名>" \
  --provider "<供应商名>"

然后测试：

1
2
3

hermes cron list
hermes cron run goodnotes-daily-export-summary
hermes cron status

Hermes 的 cron 每次都是新会话，提示词需自包含；稳定步骤放在 Skill 里即可。Hermes cron 文档

如何迁移到 Codex App

假设 Codex App 已可用。结果默认进 Scheduled 页面和应用通知，不必另配聊天机器人。

1. 安装 Skill

npx skills add walkthewalktoday/skills \
  --skill goodnotes-daily-export \
  --agent codex \
  --global

全局安装后，完整提示词资源位于 ~/.codex/skills/goodnotes-daily-export/assets/goodnotes-daily-summary.md。

也可以装到项目的 .agents/skills/，仅对该项目可见。Codex Skill 文档

2. 创建定时任务

在 Codex App 中输入：

请创建一个独立的计划任务，名称为"Goodnotes 每日变更摘要"。

每天 Asia/Shanghai 时区凌晨 3:00 运行。任务在本机本地环境执行，每次运行都从独立上下文开始。明确使用 $goodnotes-daily-export。

读取 $goodnotes-daily-export 自带的 assets/goodnotes-daily-summary.md 作为任务提示词。
在每次任务消息末尾追加“本次参数”，包括 Goodnotes PDF 源目录和输出目录；不要修改公共提示词资产。

每次运行后在 Scheduled 中给出中文摘要；没有变化时只报告"今日无 Goodnotes 变更"；处理失败时报告具体文件与错误。

创建后在侧栏 Scheduled 查看状态和最近运行。本地任务要求电脑开机、App 在跑、项目目录可访问。Scheduled tasks 文档

下一步可以怎样升级

当前版本完成的是「采集—版本化—理解—通知」。如果继续向个人知识系统演进，我会按以下顺序升级：

用文件哈希和成功游标取代「只扫描昨天」，解决漏跑问题。
为同名文件加入相对路径或稳定 ID，避免覆盖。
保存每次运行 manifest，让摘要和本次产物严格绑定。
把明确 TODO 提取到 Logseq、Obsidian 或任务管理工具，但必须保留人工确认。
自动添加主题标签和双向链接，形成长期可检索的知识网络。
为连续失败、云盘未同步和磁盘增长增加告警。
对高隐私笔记使用本地视觉模型，或在进入云端模型前执行排除规则。

这套工作流最有价值的地方，不是「AI 能识别手写字」，而是它改变了笔记的生命周期。

过去，笔记的终点是写完。现在，写完只是入口：文件会自动留下版本、变成可检索的标准 Markdown、被重新阅读、产生摘要，并在第二天回到你的注意力里。通知可以删，镜像文本最好留——它才是日后问 AI「上周架构草图改了什么」「把近一个月的关键结论按项目归类」时真正读得动的材料。

对普通用户来说，不需要先学会复杂的智能体理论。先找一件每天重复、步骤明确、结果可以检查的小事：让脚本负责机械动作，让模型负责理解，再用定时任务把它们接起来；让每一天都留下同一规格的文本。一个真正有用的个人自动化，往往就是这样开始的——My Life Organized，靠的不是某一晚的灵感，而是可累积的结构。

阅读原文：https://walkthewalk.today/posts/goodnotes-openclaw-automation/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

把手写变成行动：我的 Goodnotes → Google Drive → Logseq/Obsidian 待办工作流

2026-08-11T14:55:11+08:00

我喜欢在 iPad 上写字，也习惯在 Logseq 里管理每天要做的事。两种习惯各有优势：Goodnotes 适合捕捉思路、画箭头和圈重点；Logseq 适合跟踪任务状态、回顾未完成事项。真正麻烦的，是每天把手写内容再敲一遍。这套工作流同样适用于 Obsidian——两者在日记文件格式上略有差异，文章后面会分别说明。

我现在的做法是：在 Goodnotes 手写，自动备份 PDF 到 Google Drive；电脑上的 Google Drive 把 PDF 显示为普通文件；Codex Agent 按固定 Skill 识别编号事项，逐条写进对应日期的「今日 TODO」。如果不想每天手动提醒 Agent，还可以安排一个凌晨任务，让 Codex 自动同步前一天的笔记。

这不是让 AI 替我决定做什么，而是把抄写、拆分、去重和归档交给它。我仍然负责思考和确认，Agent 负责接好「写下来」与「做起来」之间的断点。

更重要的一层，往往要过几周才明显：每天落进日记的「今日 TODO」是格式固定的 Markdown。人读起来清楚，AI 日后检索、汇总、复盘时也不用再猜手写 PDF。一天看起来只是几条任务；积累成月、成季，就变成可被反复调用的生活与工作底料——接近 MyLifeOrganized 那种「先结构化捕获，再持续整理」的理念，只是载体换成了本地日记文件。

为什么不直接在笔记软件里记

手写与键盘输入服务于不同的思考状态。开会、阅读或梳理模糊问题时，纸笔式界面允许我随时画关系、挪动注意力，不必提前设计页面结构。Logseq 和 Obsidian 更像行动控制台：它们把任务放进某天的日记，并持续查询尚未完成的事项。

工具	负责什么	不负责什么
Goodnotes	自由手写、捕捉现场思路	长期跟踪任务状态
Google Drive	在设备之间传递 PDF	理解笔记含义
Codex + Skill	识别、拆分、去重、写入	替我决定优先级
Logseq / Obsidian	汇总任务、跟踪完成状态	还原纸笔体验

简单来说：Goodnotes 是纸，Google Drive 是传送带，Skill 是交接规则，Logseq 或 Obsidian 是工作台。

iPad：让 Goodnotes 自动留下 PDF

这里用的是自动备份（Auto Backup），而不是设备间的双向同步。iPad 上的修改会更新云端副本，但在 Google Drive 里修改 PDF，不会反向改动 Goodnotes 原笔记。Goodnotes 自动备份说明

在 Goodnotes 资料库页面中：

打开右上角 Goodnotes 菜单。
进入「云与备份（Cloud & Backup）」。
打开「自动备份（Automatic Backup）」。
选择 Google Drive，并登录要存放笔记的账号。
在备份格式中确保包含 PDF。
保存后观察云朵图标，等待第一次上传完成。

第一次启用时，最好让 Goodnotes 保持在前台，直到资料库上传完成。以后通常只上传有变化的文档。

备份格式务必包含 PDF。 .goodnotes 文件适合恢复和继续编辑，却不是电脑端通用工具最容易读取的格式。Goodnotes 也建议在非 Apple 设备查看时使用 PDF 备份。跨平台访问说明

我在 Goodnotes 中建立「工作随笔」文件夹，每天的文档用八位日期命名：

GoodNotes/
└── 工作随笔/
    ├── 20260810.pdf
    └── 20260811.pdf

日期命名是自动化最重要的约定。只要当天文件叫 YYYYMMDD.pdf，Agent 就不用在「未命名 12」和「最终版 2」之间猜测。

PC / Mac：把云端笔记变成普通文件

安装 Google Drive 桌面版（Drive for desktop） 并登录与 Goodnotes 备份相同的账号，云端文件就会出现在 Windows 文件资源管理器或 macOS Finder 中。Google Drive 桌面版安装指南

Windows

安装后，「我的云端硬盘」通常显示为虚拟磁盘。我的电脑分配的是 G:，所以当天笔记是：

`1`	`G:\我的云端硬盘\GoodNotes\工作随笔\20260811.pdf`

G: 只是个人配置，不是固定答案；Drive 高级设置允许更改 Windows 盘符。Google Drive 高级设置

macOS

Drive 通常出现在 Finder 左侧「位置（Locations）」。如果系统提示启用 Google Drive 或授予「文件与文件夹」权限，需要允许后再继续。Google Drive for macOS 说明

Mac 的实际路径可能随账号和系统版本变化。最稳妥的办法是在 Finder 找到 GoodNotes/工作随笔，复制它的真实路径，再写入 Skill 配置。

流式传输还是镜像

流式传输主要把内容留在云端，节省磁盘；镜像会在电脑保留完整副本，离线也能访问，但占用更多空间。两种方式的官方对比

我的折中方案是继续使用流式传输，只把 GoodNotes/工作随笔 设为「可离线使用」。这样不必镜像整个 Drive，Agent 凌晨读取 PDF 时也不容易遇到临时下载问题。

笔记软件：给每天留一个明确入口

Agent 写入的目标是每天的日记文件，两款软件的格式略有不同。

Logseq 采用大纲结构，TODO 语法是 - TODO，日记文件按 YYYY_MM_DD.md 命名，存放在图谱的 journals/ 目录：

- 今日TODO
  - TODO 整理会议中的三个行动项
  - TODO 确认下周计划的时间边界
- 今日主题
  -

`1`	`D:\github.com\logseq\journals\2026_08_11.md`

Obsidian 使用标准 Markdown，TODO 语法是 - [ ]，日记文件通常按 YYYY-MM-DD.md 命名，位置由「日记（Daily Notes）」插件的设置决定：

1
2
3

## 今日TODO
- [ ] 整理会议中的三个行动项
- [ ] 确认下周计划的时间边界

`1`	`D:\github.com\obsidian\Daily Notes\2026-08-11.md`

路径和文件名格式可以自定义，填写 Skill 配置时以实际路径为准。重要的是 Agent 知道 Goodnotes PDF 与笔记库的准确位置，以及使用哪种 TODO 语法。

用 Skill 固化交接规则

Skill 可以理解为写给 Agent 的标准操作卡。它规定文件位置、编号如何拆分、模糊字迹怎样处理，以及只能修改日记的哪一块。Skill 支持 Logseq 和 Obsidian 两种格式，在配置中指定笔记软件类型即可切换 TODO 语法和日期格式。

这套 Skill 已发布到公开仓库：$goodnotes-to-logseq-todos。可以用一条命令安装到 Codex：

`1`	`npx skills add walkthewalktoday/skills --skill goodnotes-to-logseq-todos --agent codex --global`

安装后，手动调用只需要一句话：

`1`	`使用 $goodnotes-to-logseq-todos，同步 2026-08-11 的笔记。`

Agent 会按日期找到 PDF，把每页渲染为图片，识别编号事项，检查已有 TODO，再写入目标日期。Skill 还规定：

一个手写编号只生成一条 TODO，下面的说明合并进去；
保留原顺序，不擅自调整优先级；
看不清的字标记 [字迹待确认]，不靠猜测补齐；
重复运行时去重；
只修改「今日 TODO」，保留日记里的其他内容；
默认不提交或推送仓库。

Agent 不是无责任的 OCR。 一个字的差异可能改变任务含义。可靠的自动化会暴露不确定性，而不是生成一份工整却错误的清单。

更省心：让 Codex 每天凌晨自动同步

手动调用适合验证流程；稳定后，可以把 Skill 与 Codex 的 Scheduled tasks 结合。官方说明中，计划任务能在后台周期执行，也能明确调用 Skill；桌面端还能在本地项目目录中工作。OpenAI Scheduled tasks 文档

这里有一个容易忽略的日期问题：凌晨 00:30 已经进入新的一天，所以任务不应同步「今天」，而要按 Asia/Shanghai 时区同步昨天。我建议设置为每天 00:30；如果 Goodnotes 经常很晚才上传，可以改为 01:00。

在 Codex 或 ChatGPT 桌面端的聊天里，直接要求创建一个每天运行的独立计划任务，并让它在能够访问笔记库的本地项目中运行。可把下面这段作为任务提示词（Obsidian 用户把 Logseq Journal 替换为 Obsidian Daily Notes，并注明 TODO 使用 - [ ] 格式）：

每天 00:30 运行。使用 $goodnotes-to-logseq-todos。
按 Asia/Shanghai 计算昨天的日期，读取昨天的 Goodnotes 工作随笔 PDF，
把编号事项同步到昨天的 Logseq Journal 的"今日TODO"。
若 PDF 不存在，不创建空任务，只报告"未发现笔记"。
字迹不清时标记 [字迹待确认]；写入前去重，写入后回读验证。
不要提交或推送 Git。

为什么选本地项目： 这项任务必须读取 G: 并写入本地笔记库（Logseq 图谱或 Obsidian Vault）。网页计划任务不能直接访问电脑文件夹；本地文件任务还要求电脑开机、桌面应用保持运行，目标项目在磁盘上可用。Google Drive 也要保持登录，笔记文件夹最好设为离线可用。

如果笔记库是 Git 仓库，我会让任务直接运行在本地项目，而不是隔离 worktree：目标就是让真实日记立即出现 TODO。代价是后台任务能改动正在使用的文件，所以 Skill 必须把范围收窄到「昨天的日记文件」和其中的「今日 TODO」。这也是为什么去重、回读验证和「不自动提交 Git」不可省略。

官方建议先在普通聊天中手动测试提示词，并检查前几次计划运行，再调整时间或规则。每天早晨只需查看 Scheduled 中的运行结果：

显示「未发现笔记」：检查 Goodnotes 是否完成上传、Drive 是否挂载；
出现 [字迹待确认]：对照原笔记修正；
同一天重跑：Skill 会先去重，不应产生双份 TODO；
电脑休眠或桌面应用未运行：本地文件任务无法按时完成，恢复后可手动补跑。

这套方法真正管理的不是文件

知识管理常见的问题，不是资料放在哪里，而是信息在工具之间移动时失去了下一步。手写内容停在 PDF 里仍然只是记录；其中的行动项进入每日任务系统后，才真正参与时间管理。

标准化在这里起决定性作用。同一套章节名、同一套 TODO 语法、同一套日期文件，让「昨天写了什么、上周卡住什么、这个月反复出现什么」变成可查询的问题，而不是翻相册式的回忆。以后问 AI「过去两周关于招聘的待办还剩哪些」「把本月未完成的今日 TODO 按主题归类」，它可以直接读这些 Markdown，而不是重新识别一堆扫描件。

量变才会质变：不是某一天突然变聪明，而是每天都留下一份机器友好、人也能扫一眼的记录。手写负责当下的思考质量，日记负责长期的可组织性——这才是我理解的 My Life Organized。

这条工作流保留了手写的自由，也获得了数字任务的可追踪性。云盘负责搬运，Agent 负责转换，Skill 负责让每次转换遵守同一套边界，而凌晨计划任务负责让交接不再依赖记忆。

让 Goodnotes 负责想，让 Logseq 或 Obsidian 负责做，让 Skill 可靠地交接，让 Codex 在你睡觉时完成搬运；让每天的标准 Markdown，成为日后 AI 检索与人生整理的底盘。

阅读原文：https://walkthewalk.today/posts/goodnotes-logseq-obsidian-workflow/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

少在乎一点，不是摆烂：重读《The Subtle Art of Not Giving a F*ck》

2026-08-11T14:55:11+08:00

书名带着脏话，封面也很冲，所以很多人以为这是一本教你摆烂的书。

其实不是。

Mark Manson 写的《The Subtle Art of Not Giving a F*ck》，核心刚好反过来：你真正能认真在乎的东西，本来就很少。 生活之所以越来越累，往往不是因为你不够努力，而是因为你把有限的「在乎」撒得太开——别人的评价、永远追不上的标准、还没发生的名声、说不清的焦虑。

Four Minute Books 把这本书压成三句话，我觉得很准：只认你能掌控的价值；别对自己太确定；别把一生耗在「留下遗产」上。下面按这个骨架重读一遍，也顺便说说它为什么对当下仍然管用。

问题不在「在乎太少」，而在「在乎错了」

正面鸡汤通常告诉你：多想一点、多爱一点、多积极一点。Manson 的立场更接近斯多葛：生活本来就不顺，痛苦也不会消失；真正的问题是，你选了哪些痛苦来扛。

他有一句很出名的话：

Who you are is defined by what you’re willing to struggle for.

翻译成大白话就是：你是谁，不取决于你想要什么结果，而取决于你愿意为哪件事持续受苦。

健身、写东西、带孩子、把一个项目做完，都会难受。区别在于，有些难受是你愿意反复回去的；有些难受只是被外界推着，硬撑着。

所以「少在乎一点」不是冷漠。它是注意力管理：把大多数事情降级，才能把真正重要的事升级。

1. 只认你能掌控的价值

Four Minute Books 提炼的第一条，也是全书最实用的一条：

你控制不了的价值，不要拿来定义自己。

举个例子。诚实，基本在你手里；守时，大半在你手里；受欢迎，几乎不在你手里。你可以友善、可以表达、可以努力，但别人怎么看你，终究不是你的方向盘。

一旦你把「被认可」「更特别」「看起来很成功」当成核心价值，焦虑会成为日常标配：永远有人比你更亮，永远有评价你接不住，永远有局你进不去。

换成可控一点的价值，事情会松很多：

不追求「受欢迎」，而追求「对身边的人是否善意」
不追求「显得厉害」，而追求「这件事我有没有把关」
不追求「别人都认可我的选择」，而追求「这个选择我能不能长期负责」

这和「品味」其实是同一类能力：在结果还没出来、掌声还没响起之前，你靠什么判断自己站得住。外部反馈可以参考，但不能当操作系统。

2. 太确定，会把成长堵死

第二条更反人性：Certainty hampers growth. 越笃定，越容易原地踏步。

如果你认定「我就是不擅长这个」「我必须一次做对」「我对这件事已经懂了」，大脑会悄悄屏蔽一切与之相悖的信息。你不是在思考，你是在保卫一个旧结论。

Manson 的建议不是把自己搞成虚无主义者，而是保留一点适度的自我质疑：

这个判断的依据，究竟站不站得住？
是否有新的信息，只是尚未留意？
此刻是在维护自尊，还是在靠近事实？

这在工作里尤其常见。方案写完就急着证明自己对；反馈来了先辩解；AI 给了一段流畅的回答，就默认它成立。流畅不等于正确，确定也不等于可靠。

愿意说「我可能错了」，不是软弱。它是给自己留出改正的空间。

3. 别把「留下遗产」活成慢性焦虑

第三条听起来丧，其实很解放：你会死。大家都是。

正因为如此，很多人拼命想留下痕迹——作品、名声、影响力、被记住。问题是，当「遗产」变成主目标，当下很容易被掏空：加班更像在还债，社交更像在铺路，休息也带着愧疚。

Manson 的立场很干脆：先把眼前这件事做成，先让身边的人过得好一点，遗产那部分交给时间。

这不是劝你没有野心。野心可以有，但最好落在你现在能动手的地方：这篇写清楚没有、这个决定负责没有、今天有没有把该做的做完。未来的墓志铭，不会因为你现在更焦虑而写得更好。

怎么用：把「在乎」当成预算

书读完如果只剩一句口号，很快就会散。更实用的用法，是把「在乎」当成有限额度的预算。

可以试这三步：

先列出你最近真正耗神的 10 件事。 开会、回复、比较、刷动态、担心评价、纠结要不要解释……写下来就会发现，大半根本不值得你把精力押在上面。

给每件事打两个标签：可控吗？值得吗？ 两个都否，就降级。可控但不值得，限制投入。值得但不可控，转换成你能实际去做的事——比如你控制不了「被喜欢」，但能控制「有没有把话说清楚」。

每周只重点保护 1–3 个高优先级的在乎。 工作交付、健康、一两个重要关系，通常就够了。其余的，允许自己做得一般，甚至允许自己不做。

你会发现，日子并没有变冷漠，只是清爽多了。

写在最后

书名博人眼球，内容却很温和。不是让你厌世，而是提醒你：

不在乎大多数事，是为了把在乎留给真正重要的那几件。

正面励志告诉你「你可以拥有更多」；Manson 告诉你「你必须放弃更多」。后一种听起来刺耳，但更接近成年人的现实：时间有限，注意力有限，责任感也有限。

少给一点 f*ck，不是摆烂。是把方向盘拿回来。

书：The Subtle Art of Not Giving a F*ck · Mark Manson
参考摘要：Four Minute Books

阅读原文：https://walkthewalk.today/posts/subtle-art-of-not-giving-a-fuck-book-notes/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

AI 把执行力变便宜了，真正稀缺的是这一种能力

2026-08-11T14:55:11+08:00

AI 正在压低「动手做」的成本，这件事本身已经没什么争议了。更值得想的问题是：当执行变便宜，什么反而变贵？

谷歌工程师 Addy Osmani 在一篇文章里用了三个词来描述这件事：领先、过时、品味。放在普通人的工作里，这三个词给了我一个清晰的视角。

技能过时得越来越快

所谓「过时」，指的是那些经过反复练习、人人都能学会的东西。说白了——曾经是护城河，如今只是门槛。

以前学一项本事，可能要花好几年；现在借助 AI，从零到能交差，往往只要几天甚至几小时。这不是说基础能力不重要，而是它贬值的速度变快了：今天让你领先的工具和方法，半年后可能同事都会用。

执行层面越来越难有持久优势。真正的问题是：什么不容易过时？

品味是什么

当人人都能做某件事，选择做什么才更重要。

在还没有明确数据、也没有标准答案的时候，做出靠谱的判断。

Osmani 把这种能力叫做「品味」。

它不是审美偏好，也不是玄乎的感觉。它是一种在结果出来之前就能感知方向的判断力：

做方案时，还没开评审会，就已经觉得哪个方向更站得住
写周报或对外材料时，发出去之前就知道哪一段会让人看下去
选合作对象或项目时，信息还不完整，但已经能感觉到哪里不对劲
面对 AI 给你的一堆选项时，能迅速判断哪个值得继续，哪个该扔掉

这些都是品味在起作用。它不容易被 AI 替代，原因很直接：AI 擅长优化已经有的指标；而品味恰好是在指标还不存在、答案还不清楚的时候起作用。

领先，往往来自品味

领先，指的不是加班更多、工具更新，而是在真正关键的决策上，比别人更早做出正确选择——别人还没动手，或者已经动手但方向偏了。

Osmani 的观察是：领先优势的变化，本质上是品味的变化。那些最早做对判断的人，通常不是信息更多，而是品味更准——他们感知到了市场、组织或用户还没有反映出来的信号。

反过来，旧本事之所以过时，往往是因为足够多的人开始品出不同的东西，老套路逐渐失去吸引力。

这意味着，AI 时代的竞争优势，核心不在于跟上工具的速度（这个差距会越来越小），而在于你对「什么值得做、方向对不对」的判断有多准。

怎么培养品味

Osmani 给过一个实操建议：把品味从直觉带到意识——给它起个名字，在具体例子和批评里练习它，把背后的逻辑说清楚。

几个具体方向：

在没有数据的时候，强迫自己先表态，然后验证。 不要等结果出来再归因。先记下自己的判断，再看结果，再复盘偏差在哪里。

大量接触高质量的作品，建立内心的参照系。 品味是一个内部标准，需要好样本来校正。读好文章、用好产品、观察做得好的同事怎么做决策，都在校正这个标准。

复盘判断，不只是复盘结果。 结果好不等于判断对，结果差不等于判断错。更值得追踪的是：你的判断在哪些地方是对的，在哪些地方一贯地偏了。

AI 可以加快执行，但它没法替你校正这个内心的标准。

技能带来效率，而真正让效率变成信任的，是你能为结果负责。能负责的前提，是你对「什么是对的」有独立判断。AI 时代，这种判断力才是真正的核心竞争力——不是入门的那种，而是拉开差距的那种。

原文：Own the Outer Loop · Addy Osmani，2026-07-15。

阅读原文：https://walkthewalk.today/posts/taste-as-core-competency-in-ai-era/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

Write-Only Code：当代码产量超过人类注意力

2026-08-11T14:55:11+08:00

Heavybit 的 Joseph Ruscio 在 2026 年 2 月写了一篇 Write-Only Code。他的核心观点是：随着 AI 代码生成的普及，企业软件里将有越来越大比例的生产代码不再被人类逐行阅读，不是偶尔跳过，而是系统性地成为常态。

这不是在替「不 Review 代码」辩护，而是在描述一个结构性的现实：代码产量在增长，人的注意力没有。下面整理它的五个主要论点。

1. 核心判断：生产代码跑赢了人类注意力

AI 正在写大量企业软件。Ruscio 认为，更值得关注的变化不是「写得快了一点」，而是人类的审查能力正在跟不上代码产量。

他把这类代码称作 Write-Only Code（只写代码）：由机器生成、上线并运行，却没有人逐行阅读。人的责任并没有消失，但「理解每一行实现」不再是默认前提。

在这个框架下，工程师真正长期存在的工作是在模糊的业务目标与可靠的机器行为之间持续管理风险，而不是亲自编写每一行代码。

2. 历史类比：每去掉一个瓶颈，下一个就会露出来

企业软件交付曾经卡在物理基础设施：买服务器、上架、连网，等几个月才能跑起来。

云计算和持续交付之后，服务器从被精心照顾的「宠物」变成可随时替换的「牲畜」，直接登录生产机反而成了异常信号。

基础设施可编程之后，瓶颈转移到了开发者产能。如今 AI 代码生成正在移除这个限制，整个软件开发生命周期又要被迫重新调整。

写代码变便宜，并不等于软件变可靠。它只是把压力推到下一层：验证、隔离、观测、问责。

3. 从审查到信任：信心需要新的基础设施

当测试、监控和规格都不完善时，人工 Code Review 长期充当最后一道防线。大规模 Write-Only Code 会打破这个假设。

Ruscio 认为，团队需要从以下地方建立信心，而不是只靠「有人读过这次 Diff」：

清晰的接口与边界
不变量与约束（invariants）
自动验证
故障隔离与可控影响范围（blast radius）
可观测性

这些不会一夜到位。更现实的路径是：先从「故障容易被发现、影响容易被隔离」的领域开始，真正关键的系统继续保留人工审查。

4. 工程师的角色：从代码作者到系统管家

Ruscio 认为工程师的角色会继续偏移：

更像系统设计者、约束编写者、权衡管理者
更多时间塑造意图，更少时间打磨具体实现
接口、失败模式、保证条件、责任归属，会变成一等设计对象

这不是取消工程师，而是把工程师放回更高杠杆的位置：决定什么必须被人读，什么可以在无需逐行审查的情况下安全交付。

5. 结论：问题不在纪律，在于机制

Write-Only Code 并不是在主张「没人读代码是好事」。它描述的是软件产量超过人类注意力上限之后的现实。

若把未读代码简单归因为「纪律松懈」，就误判了问题所在。真正需要升级的是保障机制本身：建立更强的信任机制、更好的问责手段和更完善的控制工具，让系统在没有人逐行阅读的情况下依然可靠运行。

原文：Write-Only Code · Joseph Ruscio / Heavybit，2026-02-09。本文为读后整理，版权归原作者所有。

阅读原文：https://walkthewalk.today/posts/write-only-code-when-production-outruns-attention/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

简易破坏行动手册（节选）｜aka “团队低效指南”

2026-08-11T14:55:11+08:00

1944 年，美国战略情报局（OSS）编写了《简易破坏行动手册》，教普通人用日常微小行为拖垮敌方运转。八十多年后重读其中关于组织和生产的段落，最刺眼的不是破坏技巧，而是它们与现代团队低效惊人地相似：一切走流程、事事上会、要求书面命令、用谨慎与完美主义拖延决策。

所以这份节选也可以叫它——「团队低效指南」。不是教你怎么搞破坏，而是借一份历史文本，照见组织里那些熟悉的内耗模式。

本文只保留原手册最常被引用的两节：(11) 对组织和生产的普遍干扰，以及 (12) 降低士气、制造混乱的一般手段。

原作： 美国战略情报局（OSS）· 华盛顿特区 · 1944 年 1 月 17 日
原文 PDF： Alephic 扫描件 · Project Gutenberg 校订文本

(11) 对组织和生产的普遍干扰

(a) 组织和会议

(1) 坚持一切通过“渠道”办事。绝不允许为了加快决策而走捷径。

(2) 发表“演讲”。尽可能频繁且详细地交谈。通过长篇轶事和个人经历的叙述来说明你的“观点”。毫不犹豫地发表一些适当的“爱国”评论。

(3) 如果可能，将所有事项提交委员会，以供“进一步研究和考虑”。尝试让委员会尽可能多——不少于五个。

(4) 尽可能频繁地提出不相关的问题。

(5) 就通讯、会议纪要、决议的精确措辞进行争论。

(6) 回顾上次会议决定的事项，并尝试重新提出该决定是否明智的问题。

(7) 提倡“谨慎”。保持“通情达理”，并敦促其他与会者也“通情达理”，避免仓促行事，以免日后造成尴尬或困难。

(8) 担心任何决定的适当性——提出这样的问题：所设想的行动是否属于该团体的管辖范围，或者是否可能与某些更高层的政策相冲突。

(b) 经理及监事

(1) 要求书面命令。

(2) “误解”命令。就此类订单提出无休止的问题或进行长时间的通信。尽可能地对它们争论不休。

(3) 千方百计延迟订单发货。即使订单的部分内容可能已提前准备好，但在完全准备好之前也不要交付。

(4) 在当前库存几乎耗尽之前，不要订购新的工作材料，因此，订单执行稍有延迟就意味着停工。

(5) 订购稀缺的优质材料。如果你不让他们争论。警告说，劣质材料意味着劣质工作。

(6) 在分配工作时，一定要先签下不重要的工作。确保将重要的工作分配给使用劣质机器的低效工人。

(7) 在相对不重要的产品上坚持尽善尽美；将缺陷最少的部分送回进行修补。批准其他肉眼看不到缺陷的缺陷部件。

(8) 路线错误，导致零件和材料被发送到工厂的错误地点。

(9) 在培训新工人时，给予不完整或误导性的指导。

(10) 降低士气和生产，对效率低下的工人表示友善；给予他们不应得的晋升。歧视高效工人；抱怨他们的工作不公正。

(11) 有比较重要的工作要做时召开会议。

(12) 以合理的方式增加文书工作，启动重复文件。

(13) 增加发出指令、支付支票等所涉及的程序和许可。确保一个人所做的每一件事都必须由三个人批准。

(14) 将所有规定应用于最后一封信。

(c) 办公室职员

(1) 抄单时材料数量错误。混淆相似的名称。使用错误的地址。

(2) 延长与政府部门的通信。

(3) 重要文件提交错误。

(4) 复写时，复印的份数太少，以致要多复印一份。

(5) 告诉重要的来电者老板正忙或正在接其他电话。

(6) 保留邮件直至下次取件。

(7) 散布听起来像是内幕消息的令人不安的谣言。

(d) 雇员

(1) 慢慢地做事。想办法增加工作中所需的动作次数：使用轻锤子而不是重锤子，在需要大扳手时尝试使用小扳手，在需要相当大的力时使用较小的力，等等。

(2) 尽可能多地干扰你的工作：当改变你正在加工的材料时，就像在车床或冲床上那样，花费不必要的时间。如果您正在切割、成型或进行其他测量工作，则测量尺寸的次数应是所需次数的两倍。当你去厕所时，要花比必要的时间更长的时间。忘记工具，这样你就必须回去寻找它们。

(3) 即使您听懂外语，也要假装听不懂外语的说明。

(4) 假装指令难以理解，并要求重复多次。或者假装你特别着急做你的工作，用一些不必要的问题纠缠工头。

(5) 工作做得不好，并将其归咎于不好的工具、机器或设备。抱怨这些事情阻碍了你正确地完成工作。

(6) 切勿将您的技能和经验传授给新的或技能较差的工人。

(7) 千方百计抓紧管理。填写的表格难以辨认，以致必须重新填写；在表格中犯错误或遗漏所要求的信息。

(8) 如果可能，加入或帮助组织一个小组，向管理层提出员工问题。确保所采用的程序尽可能给管理层带来不便，每次演示都会有大量员工在场，每次申诉都需要召开多次会议，提出的问题大多是想象出来的，等等。

(9) 材料误送。

(10) 将好的零件与不能使用的废料和报废零件混合在一起。

(12) 降低士气、制造混乱的一般手段

(a) 在被询问时给出冗长且难以理解的解释。

(b) 向盖世太保或警察举报假想的间谍或危险。

(d) 尽可能地烦躁和争吵，但不要给自己惹上麻烦。

(e) 误解有关配给、运输、交通规则等事项的各种规定。

(f) 对代用材料进行投诉。

(g) 在公共场合冷待轴心国国民或卖国贼。

(h) 当轴心国国民或卖国贼进入咖啡馆时，停止所有谈话。

(i) 每次都会歇斯底里地哭泣和抽泣，尤其是面对政府职员时。

(j) 抵制所有与傀儡当局有任何关系的电影、娱乐节目、音乐会、报纸。

(k) 不参与救助计划。

译文依据 Alephic 扫描 PDF，并以 Project Gutenberg 校订文本交叉校正 OCR。英文原作由美国战略情报局于 1944 年出版；此文为中文阅读版节选，侧重组织行为对照阅读。

阅读原文：https://walkthewalk.today/posts/simple-sabotage-field-manual-zh/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

都在吹“用嘴写代码”颠覆程序员？看完10年前的3D打印狂热我懂了

2026-08-11T14:55:11+08:00

最近科技圈有个词火得一塌糊涂，叫 Vibe Coding（氛围编程）。

啥意思呢？就是你不需要精通 Python、Java 这类编程语言，只需要对着 AI 持续输入提示词，靠着自然语言的“描述”，AI 就能帮你把软件写出来。

网上有不少声音在感叹：

“程序员要失业啦！”
“人人都是开发者的时代来啦！”

说实话，这种技术普及的愿景听着确实让人心潮澎湃。但如果你在科技圈观察得足够久，会发现这个发展轨迹似曾相识。

最近我看到知名技术播客作者 Justin 写的一篇文章，视角非常独特：他把当下火热的 Vibe Coding，和十多年前的“创客运动”（Maker Movement）做了一个深度对比。

看完很受启发。今天咱们就来客观地聊一聊：这波“用嘴写代码”的浪潮里，我们需要冷思考些什么。

1. 同样的“颠覆”剧本，十年前其实上演过

把时间拨回 2010 年代初，那时候的“创客运动”其实和今天的 AI 狂热非常相似。

当时大家也都满怀期待地认为：桌面 3D 打印机和开源硬件，会彻底颠覆全球制造业。

Justin 在文章里一针见血地指出：

“分布式数字制造将使制造业回流，每个城市都拥有微型工厂，3D 打印将使生产彻底去中心化——这个核心承诺压根就没有实现。”

后来的发展大家也有目共睹：期待中的“全民制造”并没有真正成为现实。

大工厂流水线带来的极致效率和超低成本，是几台桌面 3D 打印机很难去替代的。最后，创客运动沉淀成了极客和工程师们用来做早期产品原型的好帮手。

这就引出了一个非常值得深思的问题：今天被寄予厚望的 Vibe Coding，真的能让不懂技术的人彻底颠覆传统的软件开发吗？

2. 值得警惕的隐患：“评估麻木”

文章里提出了一个特别精准的概念，叫 评估麻木（Evaluative Anesthesia）。

以前的创客们玩 3D 打印，经历过一个美好的“新手村”阶段：大家在社区里反复试错，成本和风险都很低。

但 Vibe Coding 的发展速度太快了。很多不了解代码底层架构的新手，拿着 AI 生成的代码，直接就投入到商业项目中去运行。

这就导致了一个很棘手的问题：

“这造成了一种‘评估麻木’，导致项目的构建者面对自己产出的代码时，根本不具备判断其好坏的能力。”

因为代码是 AI “生成”出来的，不是你一行行推敲出来的。当程序能跑通的时候，体验确实很棒；但只要业务稍微上点规模，或者遇到复杂的 Bug，你很难判断这堆代码的架构是否合理、有没有潜在的安全漏洞。

对自己的系统失去了底层的掌控感，这就是“评估麻木”。

3. 软件没有边界，但架构依然重要

当然，我们必须承认：Vibe Coding 面对的环境比 3D 打印具有天然优势。AI 生成的代码哪怕有些冗余，复制运行十亿次的边缘成本也几乎为零。

正如作者在文中所说：

“Vibe Coding 竞争的对象是纯手工写代码，而且在许多应用场景中，它的效率确实有着显著的优越性。”

AI 辅助编程的效率确实远超纯手工敲代码。但工具再强大，也无法完全替代系统性的认知。

“如果使用者对任务目标和系统架构有深刻的理解，工具就只是次要的辅助；但如果本身缺乏专业素养，无论用多先进的工具，最后都会弄出一团糟。”

如果没有扎实的技术底层逻辑作为支撑，当 Vibe Coding 驱动的项目变得越来越复杂，它很容易变成一座难以维护的“代码迷宫”。

4. 总结

AI 无疑极大地降低了软件开发的门槛，这绝对是时代的进步。但我们需要剥离掉那些过度夸大的“颠覆论”。

Vibe Coding 更像是一个强大的放大器：用来成倍放大那些真正懂行、懂架构的人的生产力，而不是让零基础用户直接跳过学习曲线的捷径。

我们应该始终相信：行动力加上对事物底层逻辑的深刻理解，才是穿越技术周期的护城河。

与其焦虑会不会被 AI 替代，不如静下心来，去掌握那些在 AI 时代依然不可或缺的核心认知。

阅读原文：https://walkthewalk.today/posts/vibe-coding-vs-3d-printing-hype/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

别被技术黑话吓退！2026 拆解 Hugging Face 超级 Skills，大模型后训练白话全流程

2026-08-11T14:55:11+08:00

先认识 Hugging Face Skills：一套“可复用的能力包”

在进入本文主题前，先用一句话介绍 Hugging Face Skills：它是一组面向大模型的“即插即用工作流模板”，把训练、评测、数据与资产管理等常见工作串成可复用流程。

在这个仓库里，你会看到以下 skills：

huggingface-gradio：用 Gradio 搭建交互式界面/演示页。
hugging-face-cli：用 hf 命令行完成 Hub 下载/上传/仓库管理等。
hugging-face-datasets：创建与管理 Hugging Face 数据集（模板、查询、加工等）。
hugging-face-evaluation：整理/生成评测结果并写入模型卡（对外展示更规范）。
hugging-face-jobs：把任务提交到 Hugging Face Jobs 云端算力上跑（通用“云端厂房”）。
hugging-face-model-trainer：本文主角，把“训练/微调”做成一条工程流水线（SFT/DPO/GRPO/RM、监控、保存、交付）。
hugging-face-paper-publisher：把论文/报告发布到 Hub，并与模型/数据集关联。
hugging-face-tool-builder：把常用 Hub API 操作封装成可复用脚本工具（便于重复执行）。
hugging-face-trackio：训练过程指标记录与可视化（看板/监控）。

你可以把它们当成一套“工厂配套设施”：有的负责搭展台，有的负责跑机器，有的负责管仓库，有的负责做质检与报表。

接下来我们要讲的主题，就是拆解 hugging-face-model-trainer 这个 skill，看看模型是如何被“学”与“练”出来的。

一、拒绝玄学！把“训练大模型”变成一条防呆流水线

下面不展开代码细节，而是用“工厂流水线”的比喻，把大模型后训练（Post-training）从预算到交付的关键环节讲清楚。

很多人第一次听到“训练大模型”，脑海里浮现的画面是：一群穿着格子衫的极客，在黑框屏幕前敲着神秘代码，宛如在进行某种魔法仪式。

但真落到项目里，“训练”更像一套流程：先算钱、再验数据、再上云端跑；过程能看进度，跑完能把结果存下来并交付。hugging-face-model-trainer 这个 skill，就是把这套流程整理成一套比较固定的做法。

它不是一个干巴巴的框架，而是一套涵盖了**“算账、质检、生产、监控、入库、打包”**的工程能力组合。哪怕你是个纯外行，搞懂了这条流水线，也就搞懂了目前最主流的 AI 落地玩法。

后面会反复出现一堆缩写和术语。为了不被这些字母劝退，我们先用最通俗的比方把它们翻译过来——记住它“负责啥”就行，不用死记硬背：

技术黑话	大白话翻译（工厂版）
SFT（监督微调）	“填鸭式应试教育”。你给 AI 一堆“标准答案/示范话术”，让它学会固定风格的回答。通常是训练的起点。
DPO（偏好对齐）	“错题本与高分范文”。你给 AI 看两个回答，告诉它“这个好、那个烂”，让它的审美向人类靠拢。
Reward Modeling（奖励建模）	“铁面无私的阅卷老师”。专门训练一个“打分员”来给回答打分，作为后续优化的评分标准。
GRPO / PPO	“KPI 考核机制”。AI 生成回答后，系统用规则或阅卷老师打分，AI 为了拿高分会逐步调整表现（在线优化阶段的具体算法）。
RLHF	“把人类偏好变成 KPI”。常见流程是：先 SFT 打基础，再做 RM 造评分标准，最后用 PPO/GRPO 这样的算法追求更高分，同时用约束避免跑偏。
LoRA/PEFT	“省料版改造”。不做全员大改造，只改关键部件，省显存、省钱。
Hugging Face Jobs	“云端共享厂房”。你花钱租别人的高端显卡（GPU）来干活。关键点：按时计费，干完就清场，东西不拿走就会被扔掉。
GGUF	“压缩饼干”。把庞大的模型压缩打包，方便在普通电脑上运行（llama.cpp / Ollama / LM Studio 等生态常见格式）。
Trackio	“监控室大屏”。把训练过程的指标（loss、显存、吞吐等）持续显示出来，方便你判断是否健康推进。

有了这些对照，我们就可以按顺序走进 6 个车间，把“训练”拆成一套能执行、能检查、也能交付的步骤。

二、从 0 到 1：大模型生产流水线的 6 个车间

把 hugging-face-model-trainer 的能力拆开，刚好对应现代工厂的 6 个标准车间。你只要按顺序走，就能把“玄学训练”变成“工程交付”。

第 1 站：财务室（资源与成本预估）

核心任务：算算要花多少钱，多久能干完。

在云端租显卡（也就是用 Hugging Face Jobs 这种“云端共享厂房”），最怕的不是报错，而是：钱花光了、时间到了，模型还没存下来（系统会强制关机/清场）。

所以开工前，先做一个“够用的粗估”（不追求精确，只求避免踩大坑）：

[ T \approx 0.1 \times P \times \frac{N}{1000} \times E \times M_{\text{hw}} ]

(T)：训练时长（小时）
(P)：模型大小（B 参数量）
(N)：样本数
(E)：训练轮数（epochs）
(M_{\text{hw}})：硬件快慢系数（相对倍率）

然后给工期留安全边际：

超时建议 ≈ 1.3 × (T)（留 30% 缓冲，覆盖下载、保存、上传等开销）
费用 ≈ (T) × 每小时单价

把它当成包工头的“预算表”：先知道大概花费与工期，后面才好做决策（先小跑一版？要不要换更强机器？）。

第 2 站：质检科（数据体检）

核心任务：检查原材料（数据）有没有坏果子。

训练失败的头号原因，往往是数据格式不对。你可以理解为：报名表字段没填对，系统就排不了课。

这套技能包里有一个“秒级体检”的思路：不用下载庞大的数据集，就能快速判断——你的数据更像哪种“训练课程”的原材料：

SFT（监督微调）：有标准答案/示范对话（最常见起点）
DPO（偏好对齐）：有成对偏好（更喜欢 A、不喜欢 B）
GRPO（在线强化学习）：有可验证的评分/规则，能给回答打分

体检会告诉你：

能不能直接用？
需不需要重新排版/映射字段？
是否根本不适合这门“训练课程”（比如你想做偏好对齐，但手里没有偏好对）

用几秒钟的体检，换掉几十块钱的显卡冤枉钱，这是最划算的投入。

第 3 站：生产线（训练任务提交到云端厂房）

核心任务：把任务扔进云端厂房开干。

这里有一个非常关键的现实：云端厂房是隔离且一次性的。你本地电脑的文件它看不见，所以最稳妥的做法是把训练“配方表”一起交给它。

这也是为什么技能推荐用“自包含脚本”的方式：把依赖与训练逻辑写清楚，云端拿到后自动：

采购辅料（安装依赖）
调试设备（准备环境）
开动机器（开始训练）

主打一个全自动、可复现：你今天换一台机器、明天换一个时间点，只要给它配方，流程照样一字不落地跑通。

而在正式“开动机器”前，你要想清楚两件事。

第一件事：你打算改多大范围的参数？最直接（也最财大气粗）的做法是全参数微调（full fine-tuning）——模型所有参数都推倒重炼，效果上限可能更高，但显存、算力和成本压力极大。如果你不想走这条“重装路线”，就可以把 LoRA/PEFT 当成“省料开关”：只锁定一小部分关键参数进行调整，显存和成本会立刻变得非常友好。

第二件事：你打算用哪种训练“工艺”？最常见的是先用 SFT 打底；手里有“偏好对比数据”就接 DPO；如果有明确的打分规则（或者专门训练了 RM 这种“阅卷老师”），就可以用 GRPO/PPO 继续打磨（这套追求高分的组合拳常被叫做 RLHF）。不论你选哪种工艺，都可以自由搭配第一步的“全参数”或“省料开关”。

此外，在生产线上还有一个值得一提的“提效外挂”——Unsloth。当你遇到“显存爆了”或“跑得太慢”时，它能让你的训练过程大幅提速，并省下一半的显存占用。它不是新工艺，而是给你的机器装上了底层的“加速引擎”。

第 4 站：监控室（Trackio 可观测）

核心任务：实时看监控表盘。

模型在云端几千公里外跑，你怎么知道它是不是卡住了、是不是在变好？

这就是看板的意义：把 loss、学习率、显存占用、吞吐等“过程指标”持续展示出来。你不需要看懂每个数字，但至少能判断：

健康推进还是异常卡住
是不是明显资源不够（比如显存爆了）

把它当成项目的“周报 + 过程 KPI”，你就知道该不该叫停/调整。

第 5 站：仓库（强制持久化到 Hub）

核心任务：把产品锁进保险柜。

这是成败的分界线：前面说过，云端厂房“干完就清场”。如果你没有把训练产物强制推送到 Hugging Face Hub（云端仓库），那你的时间与金钱就彻底打了水漂。

不仅是最终成品，考虑到训练过程往往漫长，这套技能还会要求你在过程中定期把“半成品”（Checkpoints）存进仓库。万一云端厂房中途被强行清退（比如超时被系统强杀），你也能随时从半成品接着干，不至于一切推倒重来。

因此，在这套流程的工程观里，“训练跑完”不等于“项目完成”。真正的完成标志是：

成品和中间记录（模型权重、配置、检查点等）已经安全入库
以后团队里的任何人，都能随时从仓库把它拉下来复用、评测或部署

第 6 站：包装部（GGUF 转换与本地部署）

核心任务：把庞大的工业品变成家用消费品。

刚训出来的模型往往很大。为了让它能在个人电脑里跑起来，通常会做“量化 + 转格式”，把它变成 GGUF：

更贴近本地工具生态
可以做多档“压缩版本”（体积更小，速度更快）

你可以把它类比为：把工厂大件打包成“压缩饼干”，方便运输与食用。

三、总结：把训练当成流程，事情就好办了

回头看一遍，hugging-face-model-trainer 讲的不是“多高深的算法”，而是把训练这件事拆解成了一套更好执行的流程清单：

先算账：大概多少钱、多久、超时需要给多少缓冲
再质检：数据能不能直接用，不行就提前拦截整理
再开工：把任务交给云端厂房跑，按需开启“省料开关”，或给机器挂上 Unsloth 提效
过程可视：通过监控大屏，随时判断推进是否健康
成品入库：除了终极模型，也把半成品妥善存进 Hub 防丢失
降维打包：按需转成 GGUF，让工业巨兽能轻松塞进个人电脑

最后也想说一句：感谢 Hugging Face 这样把工具、生态和基础设施做得越来越“可用”的开源力量，它们确实在持续降低大模型训练与落地的门槛。很多原本只属于极客团队的“魔法”，正在变成普通人也能用好、管好的标准工程流程。

阅读原文：https://walkthewalk.today/posts/2026-hugging-face-skills-model-trainer-training-pipeline/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

2026：AI 越强，你越容易变笨？真正拉开差距的是这一种能力

2026-08-11T14:55:11+08:00

“遇事不决问 AI。”

这句话越来越像一种默认设置：写周报、做方案、查资料、拟邮件，几秒钟就能拿到一段“看起来很完整”的文本。

但你有没有一种隐隐的担忧：当 AI 越来越像一个全知全能的学霸，我们是不是正在变成只会点头喊“666”的学渣？

微软和多所大学的最新研究告诉我们：这种担忧不是多余的，但结局未必是悲剧。在 AI 时代，一种被称为 “批判性思维” 的古老能力，正在从“选修课”变成更接近“必修课”的基本功。

更具体地说，在高频使用 GenAI 的场景里，知识工作者更容易从“主动建模与推理”，滑向“被动接收与采纳”。这并不必然导向悲观结局，但它确实提醒我们：判断、验证与追问不能外包。

下面尝试从三个角度拆解：为什么 AI 时代更需要批判性思维，以及如何把 AI 变成训练它的工具。

1. 警惕：你的大脑正在“外包”

心理学里有个概念叫 认知卸载（Cognitive Offloading）：当外部工具能替你完成一部分任务，大脑会倾向于把负担转移出去。

过去我们用计算器外包算术；现在我们更容易把“信息整合、论证结构、结论判断”也交给模型来做。问题不在于使用工具，而在于你是否还保留了对过程的控制权。

常见的副作用包括：

流利性错觉（Fluency Illusion）：模型输出往往语气自信、结构顺滑，让人误以为“说得通”等于“是真的”。如果缺少验证与反问，很容易忽略事实错误、偷换概念或论证跳步。
思维同质化：生成模型偏向高概率表达，给出的常是“最大公约数”式答案。若只照单全收，你的观点会更像“平均值”，而不是你自己的判断。

工具可以节省时间，但如果你把判断权也一起外包，就会在不知不觉中丢掉思考的肌肉。

2. 批判性思维 2.0：从“挑错”到“驾驭”

在传统语境里，批判性思维常被理解为“找问题、挑毛病”，通过不断追问“为什么”来识别矛盾与漏洞。

进入 AI 时代，它更像一套“驾驭能力”：你不仅要能识别问题，还要能把问题定义清楚、把推理组织起来、把输出验证落地。很多时候，提示词设计本身就是一场批判性思维训练。

2.1 定义问题（Define）

AI 能生成很多方案，但它很难替你决定“什么值得做”。在目标、约束和风险之间做取舍，仍然是人的责任。

一个实用检验是：如果让你用一句话写下“我真正要解决的是什么”，你能否明确对象、边界与成功标准？做不到时，AI 生成得再多，也只是把模糊放大。

2.2 结构化推理（Structure）

同一个问题，随口一问与结构化提问，会得到完全不同的结果。与其让模型直接给结论，不如要求它把前提、假设与步骤摊开，让你有机会审视其中的跳跃。

例如，你可以要求：

先列出关键假设与不确定点
再给出可验证的数据/证据路径
最后才给建议，并明确适用条件与失败情形

当你这样提问时，你训练的不只是模型输出，更是自己的推理框架。

2.3 作为“看门人”的验证（Stewardship）

越来越多场景里，人类更像输出的“责任主体”：你要对引用的数据、结论的适用范围、隐含偏见与潜在风险负责。

把 AI 当作引擎没问题，但方向盘和刹车仍然需要你来握：该查证的查证、该补证据的补证据、该拒绝的拒绝。

3. 练习方法：把 AI 当作你的“苏格拉底”

与其把 AI 只当搜索引擎，不如把它当成“思维陪练”。下面是三种更利于训练批判性思维的用法，你可以直接复制改写后使用。

3.1 角色互换：让它做反对者

不要只问“我说得对吗”，而是让它从对立面攻击你的论证：

我正在主张：<你的观点>。
请你扮演一个严格的反对者：
1) 列出这段观点中最可能的 3 个逻辑漏洞或未经证明的前提
2) 针对每个漏洞给出反驳
3) 告诉我：如果我要让观点更强，需要补哪些证据（可验证的）

3.2 多视角评估：逼自己跳出单一立场

当你在做决策/写方案时，让不同利益相关方分别挑刺：

这是我的方案摘要：<粘贴方案>。
请分别从以下角色视角给出评价与问题清单：
- 激进的投资者：关注增长与风险偏好
- 保守的财务负责人：关注成本、现金流与可控性
- 挑剔的用户：关注体验、迁移成本与真实痛点
每个角色至少提出 5 个问题，并标注“必须回答/可选回答”。

3.3 故意找茬：把核对与修正当训练

你也可以反过来用 AI 提供“可疑素材”，练习核查与修订：

请写一段关于 <你熟悉领域> 的分析（800 字左右），并故意加入：
1) 2 个似是而非但可被查证的事实点
2) 2 处没把理由讲清楚就先下结论的地方
3) 1 个可能的刻板印象或偏见
写完后不要标注哪里是故意的。

然后你再像做同行评审一样逐条核对：哪些是事实？证据在哪里？哪些是观点？适用条件是什么？哪些是表达造成的误导？这种“拆解—验证—重写”的循环，比单次写作更能锻炼判断力。

结语：把答案当作起点

AI 的能力会继续增强：更快、更会写、更像“合理的表达”。但它并不在乎真相，也不会为你的决策后果负责。

因此，批判性思维不是用来与 AI 对抗，而是用来确保你仍然掌握问题的边界、证据的质量与结论的责任。

AI 可以帮你生成答案，但重要的问题仍然需要你自己提出。

参考资料

Critical Thinking - Wikipedia（Socratic questioning）
Generative AI for Critical Analysis（Cognitive offloading & Mindful engagement）
Guidance for generative AI（Prompt engineering & Hallucinations）
Prompt Engineering for Critical Thinking（Iterative problem-solving）
The Impact of Generative AI on Critical Thinking（Stewardship）
批判性思维在 AI 时代：从质疑到创造的进化

阅读原文：https://walkthewalk.today/posts/2026-critical-thinking-in-the-age-of-ai/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

你的大脑正在被算法算计：2026注意力防身指南（附5步系统重置法）

2026-08-11T14:55:11+08:00

有没有经历过这样的瞬间：

拿起手机本来只想回个微信，半小时后发现自己还在刷短视频；
打开电脑准备写方案，浏览器里密密麻麻几十个标签页，看一眼就心累；
一天下来好像一直在忙，复盘的时候却发现什么正事都没干成。

这不是个人意志力的问题。

畅销书作家 Daniel Pink 在最近一次演讲里说得很直白：

"注意力碎片化问题，现在是有史以来最严重的。我们的环境被科技巨头精心设计过，目的就是劫持注意力。放任下去，工作和生活都会一事无成。"

他自己也承认，如果每15分钟就忍不住看一次手机，7本畅销书一本都写不出来。

下面是他总结的 5 个注意力修复步骤，都有研究支撑。试试看能不能不切屏、不回消息，一口气读完。

1. 测一下专注力底线（Set a baseline）

大多数人不知道自己的注意力已经差到什么程度。

怎么做：

找一本纸质书，掐个表，看看不站起来、不摸手机的情况下能读多久。3分钟也行，别评判，先把数字记下来。

注意力跟肌肉一样，不练就退化。先摸清基准线，再从小目标开始往上加。

2. 斩断注意力吸血鬼（Eliminate attention leeches）

个人意志力拼不过那些花几十亿研究成瘾机制的科技公司。别考验人性，直接改环境。

怎么做：

无手机区 — 做重要事情时把手机扔到另一个房间，眼不见心不烦。
关推送 — 把所有 APP 的非必要通知关掉，一个不留。
清标签页 — 浏览器里那27个标签页，关掉，每天固定时间段集中处理。

3. 给自己一套开工仪式（Practice deep work rituals）

大脑需要一个"切换开关"，类似上课铃响了就自动安静下来的那种条件反射。

怎么做：

设计一个固定的开工动作：点一根香薰蜡烛、戴上耳机放白噪音、泡一杯特定的茶，都行。

做什么不重要，关键是每次都一样。重复几次之后，大脑会自动进入工作状态。

4. 学会主动休息（Leverage breaks and movement）

大脑不适合连续高强度运转，研究表明90分钟差不多是专注的上限。

可以把大脑想象成三岁小孩——不给零食、不让午休，迟早崩溃。硬撑不会变高效，只会变暴躁。

怎么做：

每天留15分钟出去走走，不带手机，吹吹风、伸个懒腰。休息不是偷懒，是维持状态的一部分。

5. 想清楚为什么要做这件事（Reconnect to meaning）

听着像鸡汤，但确实管用。

Daniel 自己写上一本书的时候也卡过壳，天天刷体育视频。后来他停下来问自己："我为什么要写这本书？它能帮到谁？"把答案写下来贴墙上，专注力就回来了。

怎么做：

开始一件难事之前，先花一分钟想清楚它为什么重要。目标清晰的时候，专注不是苦差事，是主动选择。

写在最后

算法很擅长把生活切成15秒的碎片，每一片都刚好够爽，但关掉屏幕只剩焦虑。

不过注意力和别的东西不一样——只要开始拿回来，马上就能感觉到变化。

阅读原文：https://walkthewalk.today/posts/your-brain-is-being-hacked-2026-attention-defense-guide/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

别再复制粘贴了：腾讯文档/XMind ↔ Logseq 一键互转

2026-08-11T14:55:11+08:00

如果你也习惯：

用思维导图快速搭框架（腾讯文档思维导图/XMind等）
用 Logseq 做长期沉淀（可搜索、可引用、可串联）

那你大概率经历过这种“崩溃瞬间”：

导图画完想进 Logseq：一层层复制粘贴，图还要重新拖
Logseq 写了很多结构化内容，想变回导图更直观：只能手动重画
最难受的是：结构丢、图片丢、链接丢、备注丢、标签丢 —— 明明只是“换个载体”，却像在“重做一遍”

这篇我直接给结论 + 可复制的命令。

建议先收藏：下次你在导图和 Logseq 之间来回倒腾时，能省不少时间。

先给结论

我做了一套 XMind ↔ Logseq 双向互转的python小工具：

XMind → Logseq：把导图变成 Logseq 友好的 Markdown（保留层级、图片、链接等信息）
Logseq → XMind：把 Logseq 的结构化 Markdown 还原回导图（并尽量把本地图片打包进 .xmind）

它追求的是：信息尽量不丢、过程可控可复现。

它不是为了追求“样式 100% 一模一样”，而是为了让你不用反复手工重做。

为什么我没继续用 Logseq 里的思维导图插件？

我实际用过、也最接近“能用”的两款 mindmap 插件是：

logseq-mind-mapping-plus
- 优点：上手快、集成感强
- 但问题也很明显：
  - 界面相对简单
  - 不支持展示图片（对很多“图文导图”来说几乎是硬伤）
  - 标称的双向同步偶尔会失灵（结构更新不一定能及时/正确回写）
Logseq Mind Map
- 优点：界面和功能确实很棒，体验更接近“正经导图工具”
- 但更致命的是稳定性：在我这边的使用里，双向同步更不可靠，甚至会出现经常连刷新都失效的情况

插件我依然会用（比如快速浏览/临时发散），但如果你更在意长期可靠，我更推荐走“文件互转”的路子。

1 分钟上手：把导图丢进 Logseq（只要三步）

你需要准备什么

Python 3.6+
一份 .xmind 文件
- 可以来自 XMind
- 也可以来自腾讯文档思维导图的 导出 XMind
两个脚本：xmind2logseq.py、logseq2xmind.py（放在当前目录或加入 PATH）

第一步：XMind → Logseq

`1`	`python3 xmind2logseq.py example.xmind`

默认会：

在同级目录生成同名 .md
把图片提取到同级 assets/

说明：为了更贴合 Logseq 习惯，Markdown 里依然会使用 ../assets/ 的引用格式。你只要保证最终图片在图谱的 assets/ 下即可正常显示。

以腾讯文档的思维导图效果为例(可以导出为example.xmind)：

第二步：放进你的 Logseq 图谱目录

Logseq 常见目录结构：

1
2
3

your-graph/
  pages/
  assets/

你把：

生成的 xxx.md 放到 pages/
生成的图片放到 assets/

导出的logseq文件：

- xmind和logseq打通了 [🔗](https://github.com/walkthewalktoday/xmind2logseq)
	- xmind2logseq [🔗](https://github.com/walkthewalktoday/xmind2logseq/blob/main/xmind2logseq.py) ![xmind2logseq](../assets/xmind和logseq打通了_aa3487b0-5cb4-43ce-793d-c534d1b837f2.png)
		- ![](../assets/xmind和logseq打通了_9addb6c8-ced5-484f-7f0e-d8b03799a379.png)
	- logseq2xmind [🔗](https://github.com/walkthewalktoday/xmind2logseq/blob/main/logseq2xmind.py)
		- ![](../assets/xmind和logseq打通了_6450b196-af8f-4ae2-2a51-7c3068ea1ff7.png)

logseq展示效果：

第三步：打开 Logseq，继续扩写/整理

导图负责“骨架”，Logseq 负责“长内容”和“引用串联”。

反过来：把 Logseq 一键变成 XMind（更适合浏览/展示）

你需要：

一个 Logseq 页面对应的 .md（通常在 pages/ 里）
同一个图谱下的 assets/ 目录

运行：

`1`	`python3 logseq2xmind.py example.md assets/`

会生成：example.xmind（并尽量把用到的本地图片打包进去）。

你可能用得上的小参数（真正的一键）

1）指定输出文件名

`1`	`python3 xmind2logseq.py example.xmind custom_name.md`

`1`	`python3 logseq2xmind.py example.md assets/ output.xmind`

2）指定图片导出目录

可以把md文件和assets文件直接生成到logseq中，省去复制粘贴的麻烦，实现真正的“一键”

`1`	`python3 xmind2logseq.py example.xmind /path/to/my/logseq/pages/custom_name.md /path/to/my/logseq/assets`

（可跳过）格式转换规则

这部分“规则说明”，只在你发现“还原不够准”时再回来对照。

链接：统一放在同一行

标题 + 链接：

`1`	`- 标题文本 [🔗](http://example.com)`

纯链接子节点：

1
2

- 父节点
	- [🔗](http://example.com)

备注 / 引用：用引用块承载

1
2
3

- 一个节点
	- > reference
	- > 这里是一段备注内容

标签：用可识别的文本格式

1
2

- 一个节点
	- **标签:** tag

常见问题（最常踩的坑）

Q1：能做到 100% 还原吗？

很难。

XMind 和 Logseq 的能力模型不同：一个偏“导图展示”，一个偏“块/知识库”
这套工具追求的是：信息尽量不丢，而不是样式像素级复刻

Q2：为什么我更推荐“文件互转”，而不是依赖插件同步？

一句话：可控 + 可复现。

插件同步一旦失灵，你很难判断是“刷新问题”还是“数据写回问题”。我已经不止一次被mindmap插件的数据丢失问题折磨😭。
文件互转至少能做到：每次导入导出的结果一致，出问题也更容易定位

Q3：图片不显示怎么办？

优先检查两点：

图片是否在 Logseq 图谱的 assets/ 目录下
Markdown 里图片引用是否是 ../assets/... 这样的相对路径

阅读原文：https://walkthewalk.today/posts/logseq-xmind-converter/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

ReLU 也能“万能近似”？用「黎曼积分 + 拼积木」把它讲透

2026-08-11T14:55:11+08:00

很多人第一次听到万能近似定理（Universal Approximation Theorem，UAT）时，会下意识把它和 Sigmoid / Tanh 这种 S 型函数绑定在一起，于是就会产生一个疑问：

ReLU 这么“直来直去”的折线激活函数，真的也能逼近任意函数吗？

答案是：能。而且理解它的方式非常朴素——就像用积木拼出任意形状一样。

什么是「万能近似定理」？

维基百科

通俗说法是：

在人工神经网络的数学理论中，万能近似定理指出：神经网络有能力近似任意函数（在一定条件下），并且可以达到任意精度。
但它也明确了一个“坑”：它不告诉你怎么选参数（权重、神经元数量、层数等）才能近似到你想要的目标函数——它更多是一个“存在性证明”。

历史脉络：

1989 年，乔治·西本科（Cybenko）证明：单隐藏层、任意宽度，并使用 S 型函数作为激活函数的前馈网络，具有通用逼近能力。
1991 年，Kurt Hornik 证明：激活函数的选择不是关键，前馈网络的多层结构与多神经元架构，才是其成为通用逼近器的关键之一。

ReLU 为啥也行？

理解 ReLU 的万能近似，你只需要抓住一个关键词：

矩形逼近法（把复杂曲线用很多“小块”拼起来）

可以借用微积分里 **黎曼积分（Riemann Integral）**的直觉来类比：

构建积木：单个神经元（尤其是 ReLU）是简单的“折线块”。把多个 ReLU 经过平移、缩放、翻转后叠加，就能做出像“凸起/方块/梯形”一样的局部结构。
拼凑曲线：任何复杂的连续曲线，都可以看作由无数个足够窄的“矩形”（或局部小块）拼起来。
无限逼近：
- 每一个“小矩形/小块”，对应一组神经元的组合；
- 神经元足够多 ⇒ 小块足够多；
- 调整每个小块的高度和位置（本质就是调 w 和 b）⇒ 就能把目标函数越拼越像，精度任你要。

一句话：只要基础材料足够简单、数量足够多，就能拼出任意复杂形态。

直接上手：用 ReLU 翻转叠加做「梯形函数」和「三角函数」

下面这部分是理解的“爽点”：你会看到 ReLU 怎么像搭积木一样搭出形状。

梯形函数（Trapezoid）

形状示意：

形状:         ___________
             /           \
            /             \
      _____/               \_____
          a    b     c     d

用 ReLU 组合出梯形的一种写法（原文公式）：

公式：

`1`	`f(x) = h/(b-a) × [ReLU(x-a) - ReLU(x-b) - ReLU(x-c) + ReLU(x-d)]`

直觉理解：

ReLU(x-a) 从 a 开始往上爬；
-ReLU(x-b) 让它在 b 之后“别再继续爬”（形成平台/拐点）；
再叠加 -ReLU(x-c) + ReLU(x-d)，让右侧出现对称的下坡并在 d 后归零；
系数 h/(b-a) 控制整体高度比例。

你可以把它当作：用 4 个“折线斜坡”拼出一个梯形凸起。

三角函数（Triangle）

形状示意：

形状:           /\
              /  \
             /    \
      _____/       \_____
          a   b   c

用 ReLU 组合出三角的一种写法（原文公式）：

公式：

`1`	`f(x) = k1×ReLU(x-a) - (k1+k2)×ReLU(x-b) + k2×ReLU(x-c)`

其中：

k1 = h/(b-a)
k2 = h/(c-b)

直觉理解：

a 到 b：由 k1×ReLU(x-a) 主导上升；
b 之后：用 -(k1+k2)×ReLU(x-b) 把“上升趋势”掰回来；
c 之后：用 +k2×ReLU(x-c) 把尾部校正到合适的形态。

代码/Notebook

notebook地址

为什么这就足够解释「万能近似」？

当你能用 ReLU 组合出任意位置、任意高度、任意宽度的“梯形/三角/小凸起”时：

把一条连续曲线切成很多很多小段；
每小段用一个（或一组）小凸起去拟合；
小段越细、凸起越多 ⇒ 误差就越小；
极限意义下，你就得到了“可以任意逼近”的结论。

这甚至比“傅里叶变换里用无数正弦叠加逼近任何连续曲线”更好直观：

本质上殊途同归：只要我有足够多简单的基础材料（波浪或方块），我就能重构出世界上任何复杂的形态。

阅读原文：https://walkthewalk.today/posts/relu-universal-approximation-theorem/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

MIT AI科学家的作息：普通人最该抄的 5 个自律细节

2026-08-11T14:55:11+08:00

在这个被通知、信息和干扰淹没的世界里，我们如何实现真正的专注和高效？

当大多数人都在为保持片刻宁静而挣扎时，有些人似乎已经“破解了密码”。麻省理工学院（MIT）的研究科学家、人工智能专家及播客主理人 Lex Fridman，就是一个在深度工作领域极具代表性的人物。

他不仅产出惊人，其日常生活方式更像是一套为构建精神韧性而设计的整体操作系统（holistic operating system）。下面我会拆解他公开的日常流程，提炼出 5 个最令人惊讶、甚至反直觉的习惯，给你一套更可借鉴的行动视角。

1. 清晨“六步心法”：把每一天编程为一场有预谋的胜利

Lex 的清晨仪式远非简单的例行公事，更像是给意识加载“操作系统”的严谨程序。通过这六个步骤，他为当天设定框架、方向和根基：

设定规则与约束（Rules and Constraints）：在开始新的一天之前，先重申核心纪律，为当天的“游戏”设定规则，比如：
- 社交媒体：只在发布内容时查看，每天 1–3 次，总时长不超过 10 分钟
- 饮食：严格遵循极低碳水的生酮饮食（Keto）
- 锻炼：无论如何每天必须锻炼；即使受伤，也要训练未受伤的部位
感恩与直面死亡（Gratitude）：他会冥想“今天可能是生命最后一天”。这并非为了营造阴郁，而是通过直面生命有限性，创造紧迫感与对“活着”的极致感恩，为一整天注入燃料。
宣告五年目标（5-Year Goals）：大声说出未来五年的宏大目标，让远方的理想每天清晨都清晰可见。
明确短期目标（Near-Term Goals）：列出那些“踮起脚尖才能够到”的年度目标——有挑战，但仍可落地。
可视化当日任务（Visualize the Day）：在脑海中快速预演当天要完成的任务，甚至包括攻克困难任务时的挣扎与最终成功。
坚守核心原则（Live by a Set of Principles）：重温自己追求的一套原则：一面是慈悲、共情、爱；另一面是品格、正直、力量（身体与精神）。

“我会在脑海里可视化并冥想：我可能在今天任何时刻死去。接受‘今天也许是我在地球上的最后一天’这个念头……然后只是呼吸、暂停，去体会：活着这件事太神奇了，生命太美妙了。”

2. 驯服而非戒除：社交媒体的“反向”使用哲学

与“数字排毒”或完全戒断社交媒体的建议相反，Lex 采取了更困难、但也更可能长期受益的策略：严格自控，而不是彻底放弃。

他的规则极其明确：

只在每天发布 1–3 次内容时查看
总时长不超过 10 分钟

他认为，完全戒断是一种“简单化的出路”；真正的挑战，是学会适度使用——甚至可能是“最难做到的事情”。在严格控制下使用社交媒体，“它反而能带来快乐与连接”。他也提到，短暂查看评论时能感受到其中的欢乐与爱，而不是无尽的干扰。

3. 拥抱“可控的痛苦”：主动寻求并战胜不适感

审视 Lex 的日常，会看到一个贯穿始终的主题：他不追求舒适，而是把不适感系统性地融入日常，用来训练精神力量。

令人畏惧的深度工作（Dreaded Deep Work）：他坦言，自己每天都对两个长达 4 小时的深度工作环节感到一丝“畏惧”（dread）。但他不会反复权衡或拖延，而是直接开始并完成。
空腹高强度训练（Fasted Intense Workouts）：他喜欢在空腹 14–16 小时后训练，例如跑至少 6 英里，以及 “nickel and dime” 体能训练：每分钟做 5 个引体向上 + 10 个俯卧撑，循环往复（minute-on-minute）。
一分钟冷水澡（The Cold Shower）：这是他一天中“最畏惧的时刻”。为了撑过最难受的 1 分钟，他会播放一首熟悉的歌，并用歌曲中的某个节点（比如主唱开始唱）作为“1 分钟结束”的信号。

通过主动拥抱这些“可控的痛苦”，他日复一日地建立起精神韧性与毅力（mental toughness / mental fortitude），从而在面对真正的人生挑战时更从容。

4. 深度工作是一种仪式，而非灵感

Lex 生产力的基石，是每天两个雷打不动的 4 小时深度工作模块。他坦言，这是他“一天所围绕的核心”。

他的理念是：高效产出并非来自灵感迸发，而是来自纪律性的“仪式”（ritual）。

在这 4 小时内，他会确保 零干扰。任何突然冒出的新想法，会迅速记下、留待以后处理，然后温和地把注意力带回当前任务。完成后，他通常感觉“筋疲力尽但很快乐”；第二个 4 小时模块则像是“冲向终点的短跑”。

“我非常相信‘仪式的纪律’：就算你不想做，也要坐在那儿；就算进展不明显，也要在那儿磨。有时你坚持几分钟之后，就会迎来突破。”

这一点很朴素，但也很扎实：成功不是来自持续高昂的动力，而是来自在毫无动力时依然“出场”的纪律。很多突破，就发生在你最想放弃的时刻之后。

5. 以原则为始，以感恩为终：为奋斗的人生加上温暖的注脚

感恩与原则不仅是清晨心法的一部分，也是他结束一天前的重要仪式，为高度纪律化的一天形成一个温暖、完整的闭环。

在完成所有工作与阅读任务后，入睡前他会再次停下来，重温早上的感恩环节：“感谢我还活着，又幸存了一天”。

这种心态也延伸到他对世界的看法：他会看着身边的麦克风、摄像机等科技产品，感叹“一切都是奇迹”。这种从平凡中发现不凡的能力，让他对艰苦的奋斗始终保持热情——在不懈努力与对他人的关爱之间，找到平衡。

“我在这个世界上珍视几件事：其中之一是努力工作；另一个（也许我说得太多了）是对他人的爱与慈悲。有这两样，就会是一种非常好的生活。”

结语：你的下一步是什么？

Lex Fridman 的日常并不是一份轻松的待办清单，而是一套关于纪律、精神韧性与人生哲学的综合实践：

拥抱“可控的痛苦”，为深度工作所需的坚韧提供身体与精神基础
早晚重温感恩与原则（爱与慈悲），为高强度运转的人生注入长期燃料

我们不必完全复制他的生活方式，但它提供了一个很好的镜鉴：通过有意识地设计自己的生活系统，专注与产出可以被显著放大。

如果在这 5 个习惯里你只能选一个，从今天开始最想尝试哪一个？欢迎在评论区聊聊。

阅读原文：https://walkthewalk.today/posts/lex-fridman-a-day-in-my-life/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

Claude Code 踩坑指南：无法通过代理登录的解决方案

2026-08-11T14:55:11+08:00

最近 Claude Code 作为一个基于命令行的 AI 辅助编程工具，热度很高。它能直接读取代码库，理解上下文，确实提升了不少开发效率。

但这两天，不少朋友（包括我）在启动 Claude Code 时，突然遇到了一个拦路虎——无法登录，且报错信息让人摸不着头脑。

🚫 遇到的问题：ERR_INVALID_IP_ADDRESS

当你满怀期待地在终端输入 claude 时，迎接你的不是熟悉的对话框，而是下面这一串冷冰冰的错误：

Unable to connect to Anthropic services

Failed to connect to api.anthropic.com: ERR_INVALID_IP_ADDRESS

Please check your internet connection and network settings.

Note: Claude Code might not be available in your country. Check supported countries at https://anthropic.com/supported-countries

第一反应肯定是检查代理。

代理开了吗？开了。
终端代理设置了吗？设置了。
curl 一下谷歌？通的。

这就很尴尬了。明明网络是通的，Claude Code 却坚称 IP 地址无效。

🛠️ 尝试修复：修改配置文件（无效）

在网上搜索了一圈，发现早期有一个临时解决方案：在用户主目录下找到 .claude.json 配置文件，手动添加一个字段：

`1`	`"hasCompletedOnboarding": true`

但我实测后发现，这个方法对当前的报错无效。问题依旧存在，显然这不是简单的配置引导问题。

🔍 追根溯源：官方 GitHub Issues 里的真相

无奈之下，我去翻了 Claude Code 的 GitHub Issues，终于找到了大部队。

原来，这是一个在 v2.0.48 及之后的版本引入的问题，且重灾区是 Linux 系统。

有开发者指出，这可能与 Anthropic 最近的安全策略调整有关（相关新闻）。官方似乎在尝试拦截某些非交互式或特定环境下的 Linux 请求，结果误伤了正常用户。

✅ 最终解决方案：版本降级

既然是新版本引入的 Bug，最直接有效的办法就是——回退到旧版本。

经过社区验证，v2.0.47 是目前最稳定的版本。

操作步骤

请按照以下步骤操作，只需三行命令：

1. 强制安装 v2.0.47 版本：

`1`	`npm install -g @anthropic-ai/claude-code@2.0.47`

2. 清理旧的配置缓存（重要）：

为了防止旧的错误配置干扰，建议清理一下配置文件夹：

`1`	`rm -rf ~/.config/claude-code`

3. 重新登录：

`1`	`claude code auth login`

这时候，你应该能看到熟悉的登录授权链接了。

🛡️ 防止自动升级

为了防止 Claude Code 再次自动升级到有问题的版本，我们需要在配置文件中禁用自动更新。

编辑或创建 ~/.claude/settings.json (或者检查你的配置文件位置)，确保包含以下配置：

{
    "env": { 
        "DISABLE_AUTOUPDATER": "1" 
    }
}

📝 总结

AI 工具迭代速度极快，带来新功能的同时，偶尔也会引入一些令人头疼的 Bug。对于开发者工具来说，稳定往往比追新更重要。

如果你也遇到了这个问题，不妨先降级到 v2.0.47 苟住，静待官方修复。

希望这篇文章能帮你节省折腾的时间。如果你有其他解决思路，欢迎在评论区留言！

阅读原文：https://walkthewalk.today/posts/claudecode-cannot-login-via-proxy/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

写完就上线：用 Logseq 搭建公开知识库（Logseq + GitHub Actions + Vercel 实战）

2026-08-11T14:55:11+08:00

开门见山：这篇文章帮你把 Logseq 里的内容，舒服地变成一个可公开访问的小网站。改造过程不复杂，也尽量不折腾。

这篇文章适合谁

想把知识沉淀“摆到台面上”的个人/小团队。
希望“写在 Logseq，自动上线”的轻量方案。
本文不涉及：评论、全文检索增强、私有访问等高级功能。

开工前准备

GitHub：1 个 graph 仓库（内容仓库）。
Vercel：创建1个项目用于绑定 graph 仓库的 gh-pages 分支，并自动部署网页。
域名：可选，用于绑定 Vercel 项目。

整体怎么跑的

本地写作 → 推送到 GitHub。
GitHub Actions 自动构建（用自定义的 publish-spa -> 调用自定义的 logseq 过滤+构建 SPA -> 提交到 gh-pages 分支）。
Vercel 自动部署（从 gh-pages 分支感知变化拉取产物，部署到 Vercel）。

步骤 1：把“要公开的内容”说清楚

参考仓库：https://github.com/walkthewalktoday/logseq/tree/wiki-0.10.6
规则调整：相比原版，由 public:: true 的过滤条件 → 满足 wiki 且不是 wiki:: self。
为什么：更好控、少出错，也更符合内容分层。一通百通，后期自己可以尝试个性化过滤条件。
参考改动：diff

步骤 2：让构建工具对齐你的改造

参考仓库：https://github.com/walkthewalktoday/publish-spa/tree/main
将内部引用 logseq/logseq 切换到 walkthewalktoday/logseq。
参考改动：diff
小提醒：publish-spa 会把 logseq 和 graph 仓库 clone 到同级目录。
- 请避免重名：graph 仓库名不要和 logseq 一样。

步骤 3：把自动化部署接起来

在 graph 仓库添加 .github/workflows/publish.yml：

on: [push]

permissions:
  contents: write
jobs:
  test:
    runs-on: ubuntu-latest
    name: Publish Logseq graph
    steps:
      - uses: actions/checkout@v4
      - uses: walkthewalktoday/publish-spa@wiki-0.3.1
      - name: Add a nojekyll file # to make sure asset paths are correctly identified
        run: touch $GITHUB_WORKSPACE/www/.nojekyll
      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: www

这段流程做了两件事：

用 publish-spa 把站点构建到 www/。
再把 www/ 发布到 gh-pages 分支。

步骤 4：交给 Vercel，访问更稳

新建 Vercel 项目，直接粘贴 graph 仓库的 GitHub 地址即可快速创建，framework 选择 Other 就行。
记得锁定分支到 gh-pages，避免 main 改动引发重复部署。
免费量大管饱，有域名的话，绑定项目，Vercel 还会自动配置https证书。

最后

从今天起，写在 Logseq 的内容可以更轻松地“走出去”，慢慢变成你的长期资产。

阅读原文：https://walkthewalk.today/posts/logseq-advanced-public-knowledge-base-setup-guide/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

告别iCloud同步噩梦！iPhone上用Git管理Logseq/Obsidian笔记的完美方案

2026-08-11T14:55:11+08:00

你是否也曾被 Logseq 或 Obsidian 在多设备间使用 iCloud 同步时的文件冲突搞得头疼不已？今天，我将为你介绍一种稳定且高效的替代方案，让你可以在 iPhone 上使用 Git 自由地编辑和同步笔记，彻底告别并发编辑冲突的烦恼。

问题的根源: iCloud 同步的痛点

Logseq 和 Obsidian 都是强大的知识管理工具，它们都基于本地 Markdown 文件系统。当我们使用 iCloud 在 iPhone、iPad 和电脑之间同步时，由于 iCloud 的同步机制，很容易出现文件版本冲突，尤其是在网络不佳或多设备同时编辑的情况下，严重时甚至会导致数据丢失。

终极解决方案: Git + Working Copy

为了解决这个问题，我们引入 Git——强大的版本控制工具。通过 Git，我们可以精准地控制文件的每一个版本，有效避免冲突。而在 iPhone 上，实现这一切的核心就是一款名为「Working Copy」的 App。

优点

稳定可靠: Git 的版本控制机制从根本上避免了文件冲突。
版本历史: 你的每一次修改都有记录，可以随时回溯。
掌控力强: 可以精确控制何时拉取（Pull）和推送（Push）更新。

缺点

成本: 需要购买 Working Copy 的 Pro 版本，价格为 199 元。但考虑到它能一劳永逸地解决同步问题，这笔投资是值得的。
上手门槛: 相比 iCloud 的"无感"同步，需要一些初始设置。

手把手教你设置

第一步: 在 Working Copy 中克隆你的笔记仓库

确保你已经将笔记文件夹（Logseq 的 Graph 或 Obsidian 的 Vault）初始化为 Git 仓库，并将其托管在 GitHub、Gitee 或其他 Git 服务平台上。
下载并打开 Working Copy App，购买 Pro 版本。
在 Working Copy 的设置 (Settings -> Hosting Providers) 中，登录你的 GitHub 账号。
返回主界面，点击右上角的 + 号，选择 Clone repository，然后找到并克隆你的笔记仓库。

第二步: 将仓库链接到本地文件夹 (关键步骤)

这是整个流程中最关键的一步，目的是让 Working Copy 管理的 Git 仓库与笔记 App 读取的文件夹建立连接。

在 Working Copy 中点击进入该仓库。
点击左上角的仓库名称，在下拉菜单中选择 Link Repository to...。
在弹出的选项中，选择 Directory (文件夹)。
请务必注意:
- 确保你的存储位置在 我的 iPhone 上，不要选择 iCloud Drive，以避免潜在的同步问题。
- 在笔记 App 默认的文件夹内（Logseq 一般是 我的iPhone->Logseq，Obsidian 一般是 我的iPhone->Obsidian），创建一个新的子文件夹用来存放你的笔记。建议不要使用与 Git 仓库相同的名字。
- 选择好新创建的文件夹后，点击 Done。

第三步: 在笔记 App 中打开新文件夹

打开你的笔记 App（Logseq 或 Obsidian）。
选择打开文件夹/添加图谱（Logseq 选择"添加新图谱"，Obsidian 选择"Manage vaults"），然后选择你在上一步中创建并链接的那个文件夹。
现在，你的笔记 App 就可以读取和编辑由 Working Copy 管理的本地文件了。

第四步: 设置自动化同步

为了让体验更接近“无感同步”，我们可以利用 iOS 的快捷指令（Shortcuts）App 设置自动化。

打开笔记 App 时自动拉取更新 (Pull)

打开“快捷指令” App -> “自动化” -> “创建个人自动化”。
触发条件选择 "App" -> 选择你的笔记 App（Logseq 或 Obsidian）-> 勾选 "打开时"。
添加操作: 创建新快捷指令 -> 搜索并选择 Working Copy 提供的 Pull Repository，在 Repo 字段选择你的笔记仓库。

关闭笔记 App 时自动提交和推送 (Commit & Push)

同样地，创建一个新的个人自动化。
触发条件选择 "App" -> 选择你的笔记 App -> 勾选 "关闭时"。
添加操作:
- 创建新快捷指令
- 搜索并选择 Working Copy 提供的 Commit Repository和Push Repository

最终，你的自动化流程看起来应该像这样:

结语

恭喜你！现在你已经拥有了一个稳定、可靠且强大的移动笔记工作流。无论你使用 Logseq 还是 Obsidian，虽然前期需要一些设置和一些费用，但它换来的是安心的笔记体验和专业级的版本控制。现在，你可以随时随地在 iPhone 上记录灵感，再也不用担心同步冲突了。

提示: 这个方案同样适用于所有基于本地 Markdown 文件的笔记工具。

安卓用户可以参考: 这里

阅读原文：https://walkthewalk.today/posts/how-to-perfectly-sync-logseq-obsidian-notes-with-iphone-and-git/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

2025年，读懂这3个趋势，完成你的自我升级

2026-08-11T14:55:11+08:00

引言

我们正处在一个高速变化的时代，技术、职业和生活方式都在飞速迭代。这既是挑战，也是个人重塑的最佳机遇。

成功的关键，已经从"努力工作"转向了"智慧升级"：

职业升级：从单一的职场角色，进化为多元的"人生投资组合"架构师。
健康升级：用系统化、数据化的思维，解锁巅峰的身心能量。
创造力升级：与人工智能（AI）携手，释放被隐藏的天赋。

准备好安装你的"个人2.0版本"了吗？

职业升级：从"单行线"到"作品集"

传统的线性职业路径，在经济衰退、技术变革的冲击下显得愈发脆弱。企业也更倾向于雇佣灵活的自由职业者和项目制员工。作为应对，"作品集人生"（Portfolio Life）或"斜杠人生"（Slash Career）应运而生。其核心是通过拥有多重职业身份和收入来源，来分散风险、抵御未知。

这种模式的价值远超金钱：

实现个人价值：它为被主业压抑的兴趣和天赋提供了出口，从而带来巨大的成就感和自信。
储备未来技能：投身新领域能让你学习新技能，这在企业裁员或重组时，将成为你不可替代的价值。
抵御职业倦怠：在不同领域间切换，能有效防止 burnout，并将工作的主导权交还给自己，实现真正的身心平衡。

这是一种理性的个人风险管理策略，像管理金融投资组合一样管理职业生涯。主业是"蓝筹股"，提供稳定现金流；斜杠身份则是"潜力股"，蕴含未来可能。

健康升级：成为自己的"身体极客"

在一个信息过载、压力巨大的时代，系统性地管理健康和精力，成为个人表现的关键。"生物黑客"（Biohacking）的核心理念，就是运用科学和数据来主动优化自己的健康。起点很简单：数据追踪。通过智能手表等设备，将睡眠、心率等模糊感觉转化为清晰数据，为决策提供依据。

对于初学者，可以从三个简单高效的方法入手：

间歇性断食：关注"什么时候吃"而非"吃什么"。最易执行的"16:8"模式（8小时内进食）已被证明有助于调节血糖和改善专注力。
优化睡眠：睡眠是身心恢复的支柱。通过追踪睡眠周期、减少睡前蓝光照射、建立固定作息等方式，主动"骇入"并提升睡眠质量。
尝试冷疗法：无论是专业的低温理疗还是简单的冷水澡，都能促进血液循环、减轻炎症，并带来精神上的愉悦感，构建强大的身心韧性。

生物黑客的兴起，标志着人们渴望成为自己健康的"CEO"，通过自我实验和个性化数据，在混乱的健康信息中找到真正适合自己的方案。

创造力升级：AI是你的新合伙人

关于AI的讨论，正从"人类被取代"转向"人类被增强"。AI正在成为我们每个人的创意"副驾驶"（Co-pilot），极大地降低了创造的门槛。

音乐创作：像Suno和Udio这类工具，能根据文字描述生成完整歌曲，让不懂乐理的普通人也能成为音乐人。
视觉艺术：DALL-E、Midjourney等工具能将文字转化为高质量图像，让视觉表达不再有门槛。
内容写作：大语言模型可以高效完成头脑风暴和草稿撰写，让创作者专注于深度思考。

AI成为了跨越"技能鸿沟"的桥梁，让第一部分提到的"斜杠人生"变得触手可及。当AI能海量生成内容时，人类的价值便体现在独特的策划力、审美和情感内核上。AI负责"多"，人类负责"精"。

未来是一个自我导向的工程

有韧性的职业为你提供探索的自由；系统化的健康管理为你提供所需的精力；而充沛的精力让你能拥抱AI这一工具，为你的职业组合增添新的可能。

未来不再是被动接受的宿命，而是我们主动构建的工程。你的下一次升级，正等待启动。

阅读原文：https://walkthewalk.today/posts/2025-year-read-these-3-trends-complete-self-upgrade/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

[翻]RAG讣告：被Agent杀死，被上下文窗口埋葬

2026-08-11T14:55:11+08:00

作者: Nicolas Bustamante
原文: https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents

引言

为什么"检索增强生成"（RAG）无法在"上下文革命"中存活，以及我们所知的切块、嵌入与重排器的终结。

我在 AI 与搜索领域工作了十年。先是创建了 Doctrine，欧洲最大的法律搜索引擎，如今在打造 Fintool，一款面向机构投资者的 AI 金融研究平台，帮助分析公司、筛选股票并做出投资决策。

在花了三年时间构建、优化并扩展基于 RAG 的 LLM 系统之后，我相信我们正目睹 RAG 架构的黄昏。随着上下文窗口的爆炸式增长与基于智能体（agent）的架构成熟，我这个颇具争议的观点是：我们花大量时间打造与优化的现有 RAG 基础设施正在走下坡路。

RAG 的崛起

2022 年末，ChatGPT 席卷全球。人们开始无休止地对话，把关键工作交给它，结果才发现底层模型 GPT-3.5 只能处理 4,096 个 token……大约六页文本！

AI 世界面临一个根本问题：如何让一个智能系统处理比它一次能读的内容大几个数量级的知识库？

答案就是检索增强生成（RAG），这是一种架构范式并在接下来的三年主导了 AI。

早期 LLM 的数学现实

GPT-3.5 能处理 4,096 个 token，下一代 GPT-4 将其翻倍到 8,192 个 token，大约 12 页。这不仅是不便，更是架构层面的灾难。

看一组数字：一份 SEC 10-K 年报大约包含 51,000 个 token（130 多页）。

在 8,192 个 token 下，你最多能看到一份 10-K 的不到 16%。这就像通过钥匙孔读财报！

RAG 架构：技术深潜

RAG 作为一个优雅的解决方案，直接借鉴搜索引擎。就像谷歌会为你的查询展示 10 个相关摘要的蓝色链接，RAG 则检索与你问题最相关的文档片段并喂给 LLM 用于综合。

核心思想很简单：如果你装不下全部上下文，就找最相关的部分来用。它把 LLM 变成了复杂的搜索结果总结器。

本质上，LLM 读不完整本书，却能知道最后谁死了；很方便！

切块的挑战

长文档需要被切成片段，这时问题就开始了。这些可消化的片段通常是 400–1,000 个 token，也就是大约 300–750 个词。

问题在于？并不是每 500 个词切一下就完事。

以一份典型的 SEC 10-K 为例，文档有复杂的层次结构：

项目 1：业务概览（10–15 页）
项目 1A：风险因素（20–30 页）
项目 7：管理层讨论与分析（MD&A，30–40 页）
项目 8：财务报表（40–50 页）

如果你每 500 token 机械切块，关键信息就会被打散：

收入确认政策被分到 3 个块
风险因素解释被切在半句
财务表头与数据被拆开
MD&A 的叙述与其讨论的数字分离

当你搜索"收入增长驱动因素"，可能拿到一个提到增长的块，但错过另一个块里的具体数字，或 MD&A 里第三个块的战略背景！

在 Fintool，我们开发了比简单分割更高级的切块策略：

层级结构保留：从项目 1（业务）到更细的子章节（如地域分部），维护树状表示
表格完整性：财务表决不拆——利润表、资产负债表、现金流量表与其表头及数据保持原子性
跨引用保留：维护叙述部分与相应财务数据之间的链接，保留"参见注释 X"等关系
时序连贯性：同比/多期分析保持为单一块
脚注关联：通过元数据把脚注与其引用项保持连接

每个块在 Fintool 都被大量元数据丰富：

申报类型（10-K、10-Q、8-K）
财报期间与报告日期
章节层级（项目 7 > 流动性 > 现金头寸）
表格标识与类型
跨引用映射
公司标识（CIK、股票代码）
行业分类代码

这能带来更准确的检索，但即便智能切块也无法解决根本问题：我们仍在处理文档碎片，而非完整文档！

一旦有了块，你还需要一种搜索方式。一个方法是对块做嵌入。

嵌入与检索流水线

每个块会被转成一个高维向量（多数嵌入模型是 1,536 维）。这些向量生活在一个空间里，理论上相近概念彼此靠近。

当用户提问时，问题也会被转成向量。系统通过余弦相似度找到最接近问题向量的块。

理论上优雅，实践中则是边角案例的噩梦。

嵌入模型在通用文本上训练，难以处理特定术语。它们能找相似，但分不清"收入确认"（会计政策）和"收入增长"（业务表现）。

例如：查询："公司的诉讼风险敞口是多少？"

RAG 搜索"litigation（诉讼）"并返回 50 个块：

1–10：风险因素的套话里各种“诉讼”提及
11–20：2019 年的历史案件（已结）
21–30：前瞻性“安全港”声明
31–40：不同章节的重复描述
41–50：通用“我们可能面临诉讼”的警告

RAG 报告：诉讼 5 亿美元（来自“法律程序”章节）

而事实是：

法律程序项 5 亿美元（项目 3）
或有事项注释 7 亿美元（“单项不重大”）
后续事项中新发生 10 亿美元集体诉讼
其他章节的 8 亿美元赔偿义务
脚注中 20 亿美元“很可能发生的损失”（关键词是“probable”，不是“litigation”）

实际敞口是 51 亿美元。是 RAG 找到的 10 倍。噢不！到 2023 年底，多数构建者都意识到仅靠向量搜索不够。

混合搜索：复杂但有效

于是有了混合搜索：把语义搜索（嵌入）与传统关键词搜索（BM25）结合起来。这就有意思了。

BM25 是一种擅长精确词项匹配的概率检索模型。不同于嵌入，BM25：

奖励精确匹配：搜“EBITDA”，就给“EBITDA”，不是“operating income”或“earnings”
罕见术语处理更佳：如“CECL”“ASC 606”等财金术语得到合适权重
文档长度归一化：不会惩罚长文档
词频饱和：多次出现“revenue”不会淹没其他重要词

混合搜索的实现

在 Fintool，我们构建了复杂的混合搜索系统：

并行处理：语义与关键词搜索同时运行
动态加权：基于查询特征调整权重：

特定财务指标？BM25 占 70%
概念性问题？嵌入占 60%
混合问题？50/50，并对结果分析

评分归一化：不同评分尺度归一：

BM25 用 min-max
嵌入余弦相似度本就归一
用 Z-score 处理异常值

最终，嵌入与关键词检索的结果通过“倒数名次融合（RRF）”合并。RRF 会让在多个系统中排名靠前的项整体浮到更高，即便没有任何一个系统把它排第 1！

到这就结束了？并没有！

重排瓶颈：RAG 隐秘的痛

没人愿意提的是：在所有检索工作之后，你还没完。你需要再对这些块做一轮重排，才能得到好的检索结果并限制喂给 LLM 的块数，这并不容易。重排器是机器学习模型，会根据你的具体查询对搜索结果重新排序。

LLM 不仅上下文贫，还会在信息过多时表现变差。把送入 LLM 的块数降到最少至关重要。

重排流水线：

嵌入 + 关键词初检得 100–200 个块
重排器挑出 top 10
把这 10 个块喂给 LLM 回答问题

重排的挑战：

延迟飙升：每次查询增加 300–2000ms。疼。
成本倍增：每次查询都有显著额外成本。例如 Cohere Rerank 3.5 每 1,000 搜索单元 2 美元，价格不菲。
上下文限制：重排器通常能处理的块很少（如 Cohere Rerank 仅支持 4096 token），若要重排更多，就得并行多次 API 调用后再合并！
又多一个要管的模型：多一个 API，多一个故障点

重排只是复杂管线中的又一环。

传统 RAG 的基础设施负担

我觉得 RAG 的难点在于所谓"级联失败问题"：

切块会出错（拆表）或过慢（尤其要实时导入与切分 GB 级数据）
嵌入会出错（相似度错配）
BM25 会出错（词项不匹配）
混合融合会出错（权重不佳）
重排会出错（优先级错误）

每个阶段都会放大前一阶段的错误。除了混合搜索本身的复杂性，还有常被忽视的基础设施负担。

在生产中运行 Elasticsearch 并不轻松。若要覆盖全面文档，你需要 TB 级索引数据，至少 128–256GB 内存才有不错性能。真正的噩梦是重建索引。每次模式变更都要全量重建，数据大时需要 48–72 小时。此外还要持续处理集群管理、分片策略、索引优化、缓存调优、备份和灾备，以及版本升级中常见的破坏性变更。

RAG 在复杂文档上的根本限制

一些结构性限制：

1. 上下文碎片化

长文档是相互交织的网络，不是彼此独立的段落
一个问题可能需要 20+ 份文档的信息
切块会永久破坏这些关系

2. 语义搜索在数字上失灵

“$45.2M” 与 “$45,200,000” 的嵌入不同
“收入增加 10%” 与 “收入增长了十分之一” 排名不同
充满数字的表格语义表征很差

3. 缺乏因果理解

RAG 不会沿“参见注释 12 → 注释 12 → 附表 K”去跟踪
不理解“终止经营”会影响“持续经营”
不能追踪一个财务项目如何影响另一个

4. 词汇不匹配

不同公司用不同术语描述相同概念
“调整后 EBITDA” vs “扣除特殊项目前的营业利润”

5. 时间盲

难以可靠区分 2024Q3 与 2023Q3
混淆当期与上期比较
不理解财年边界

这不是小问题，而是检索范式的根本局限。

三个月前，我偶然看到一种检索的创新，令我大开眼界。

智能体式搜索的出现：新的范式

2025 年 5 月，Anthropic 发布了 Claude Code，一个在终端里工作的 AI 编码智能体。起初我对这个形态很惊讶。终端？回到 1980 年？没 UI？

那时我在用 Cursor，这是一款擅长传统 RAG 的产品。我给它访问我的代码库做嵌入，Cursor 在回答前会在代码库里搜索。体验不错。但测试 Claude Code 时，有件事让我印象深刻：

它更好更快，原因不是它的 RAG 更好，而是它根本没有 RAG。

Claude Code 的搜索如何工作

它没有使用复杂的切块、嵌入和搜索管线，而是使用直接的文件系统工具：

1. Grep（更准确说 ripgrep）

闪电般的正则全文搜索
无需索引，直接对实时文件搜索
完整 regex 支持，精准匹配
可按文件类型/通配模式过滤
返回精确匹配及上下文行

2. Glob

通过名称模式直接发现文件
例如 "/*.py" 或 "src//*.ts"
可按修改时间排序（偏向新近）
零开销，仅文件系统遍历

3. 任务智能体

自主的多步探索
处理需要调查的复杂查询
自适应组合多种搜索策略
逐步构建理解
基于发现自我校正

顺带说一句，Grep 发明于 1973 年。如此"原始"。这恰恰是它的妙处。

Claude Code 的调查方法

Claude Code 不做"检索"，而是"调查"：

并行运行多种搜索（Grep + Glob）
先广后窄，基于发现逐步收敛
自然地跟随引用与依赖
无嵌入、无相似度分数、无重排

它很简单，很快，而且基于一个新假设：LLM 正从"上下文贫"迈向"上下文富"。

Claude Code 的优势

Claude Code 证明：当上下文足够、导航智能时，你根本不需要 RAG。智能体可以：

直接加载整个文件或模块
实时跟随交叉引用
理解结构与关系
在调查过程中保持完整上下文

如这项基准所示，一份包含 URL+描述的简单 TXT 文件胜过复杂 RAG。扎心。这是范式转变；LLM 把 RAG 脚手架当早餐吃掉。

这不仅"优于 RAG"，而是完全不同的范式。对代码有效的方法，同样适用于任何非代码的长文档。

上下文革命：从稀缺到富足

上下文窗口的爆炸让 Claude Code 成为可能：

上下文贫时代（2022–2025）

GPT-4：8K tokens（约 12 页）
GPT-4-32k：32K tokens（约 50 页）

上下文革命（2025 及以后）

Claude Sonnet 4：200k tokens（约 700 页）
Gemini 2.5：1M tokens（约 3,000 页）
Grok 4-fast：2M tokens（约 6,000 页）

在 200 万 token 下，你可以装下多数公司一整年的 SEC 申报。

趋势更激进：到 2027 年我们可能迈向 1,000 万+ 的上下文窗口，Sam Altman 甚至暗示未来会有"数十亿"上下文 token。这代表了 AI 系统处理信息方式的根本转变。同样重要的是，注意力机制快速进步——LLM 在巨量上下文中保持连贯与聚焦的能力迅速提升，不再容易被"噪声"搞丢。

Claude Code 的启示：为何上下文改变一切

Claude Code 展示：当上下文足够时，搜索变成“导航”：

当你能加载完整文件，就不必检索碎片
当你能做精确匹配，就不必做相似度
当你能沿逻辑路径前进，就不必重排
当你能直接访问，就不必嵌入

令人震撼。LLM 的智能体行为在快速变强，也就是能把工作组织成若干任务以完成目标。

像 ripgrep 这样的工具给“搜索”带来了：

无需设置：无索引、无开销，指哪搜哪
即时可用：新文档一落盘即可搜索（零索引延迟）
零维护：无集群、无索引优化、无内存配置
极速：对 10 万行代码，Elasticsearch 建索引要几分钟；ripgrep 毫秒级就能搜，且零准备
成本：$0 基础设施 vs Elasticsearch 的不菲成本

回到 SEC 申报的例子。一个智能体可以内在地理解结构：

层级意识：知道项目 1A（风险因素）与项目 7（MD&A）的关系
跟随交叉引用：“参见注释 12”自动追踪
多文档协同：连通 10-K、10-Q、8-K 与委托书
时序分析：系统性比较年度变化当需要跨成千上万家公司或跨数十年申报做搜索时，它也许仍会用混合搜索，但只是作为智能体的工具：
先用混合检索做广泛初筛
智能体加载 top 结果的完整文档
在完整上下文中深入分析
基于发现迭代细化我猜传统 RAG 现在只是诸多搜索工具之一，而智能体会更倾向用 grep 并直接读完整文件，因为它们“上下文富”，还能处理长流程任务。以“我们 65 亿美元的租赁义务”问题为例：步骤 1：在主财务报表中查“lease（租赁）” → 发现“参见注释 12” 步骤 2：跳转注释 12 → 发现“剔除终止经营（注释 23）” 步骤 3：查看注释 23 → 发现额外 20 亿美元义务步骤 4：交叉核对 MD&A → 确认管理层解释与调整步骤 5：搜索“后续事项” → 发现资产负债表日后 5 亿美元租赁终止最终答案：持续经营 50 亿 + 终止经营 20 亿 − 终止 5 亿 = 65 亿

智能体像人类分析师那样沿引用线索前进。无切块、无嵌入、无重排，只有智能导航。

RAG vs 智能体式搜索的本质区别

本质上，RAG 像一个记忆完美却不理解的研究助理：

"这是 50 段提到债务的片段"
却不能告诉你债务是否在上升、为何上升
不能把债务与战略变化关联起来
不能识别隐藏义务
只会"取文本"，不懂"关系"

而智能体式搜索像一位法务会计师：

系统性地"跟钱走"
理解会计关系（资产 = 负债 + 所有者权益）
识别缺失或隐藏内容
跨时段与跨文档串联线索
用数据挑战管理层表述

为何智能体式搜索代表未来

文档复杂度上升

文档更长、更互联
跨引用与外部链接激增
需要同时理解多份相关文档
系统必须能沿复杂信息路径前进

结构化数据融合

越来越多文档结合结构化与非结构化内容
表格、叙述、元数据需要联动理解
关系比孤立事实更重要
语境决定意义

实时性要求

信息需要即时处理
无暇等待重建索引或更新嵌入
动态文档结构需要自适应方法
实时数据要求实时搜索

跨文档理解

现代分析需要连接多种来源：

主文档
支撑材料
历史版本
相关申报

RAG 将每份文档视为独立。智能体式搜索构建累积性理解。

精准胜于相似

精确信息比相似内容更重要
沿引用线索前进胜于找相关文字
结构与层级提供关键上下文
导航胜于检索

证据越来越清晰。RAG 在"上下文贫"时代立下汗马功劳，而智能体式搜索是根本性的进化。其潜在收益包括：

因缺少上下文导致的幻觉被消除
给出完整答案而非碎片
通过并行探索更快获得洞见
通过系统性导航获得更高准确性
大幅降低基础设施成本
零索引维护开销

结论：进入"后检索时代"

关键洞见？复杂文档分析——无论代码、财报或法律合同——并不在于寻找"相似文本"，而在于理解"关系"、跟随"引用"，并保持"精确"。大型上下文窗口与智能导航的结合，带来了检索单独一项永远无法实现的能力。

RAG 是"上下文贫"时代的巧妙权宜之计。它帮助我们在微小窗口与海量文档之间搭桥，但始终只是创可贴。未来不会再是把文档切成碎片、 juggling 嵌入向量；而是让能导航、能推理、能把整个语料装进"工作记忆"的智能体来完成。

我们正进入"后检索时代"。胜者不再是拥有最大向量数据库的人，而是能设计出最聪明的智能体，去穿梭于丰富上下文、在文档之间建立意义连接的人。回头看，RAG 将像辅助轮：有用、必要，但终究是过渡。

下一个十年的 AI 搜索将属于能端到端阅读与推理的系统。检索并未死——它只是被降级了。

阅读原文：https://walkthewalk.today/posts/the-rag-obituary-killed-by-agents-buried-by-context-windows/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

部署n8n到虚拟机cvm并开启https

2026-08-11T14:55:11+08:00

环境

CVM厂商：腾讯云
域名解析：腾讯云DNSPOD
机型：SA2 4C4G
操作系统：Ubuntu 24.04LTS

通过docker composer安装n8n

# 安装docker 和 docker compose
sudo apt install docker.io docker-compose -y

# 下载n8n 
git clone https://github.com/walkthewalktoday/n8n-hosting.git

# 修改配置
cd n8n-hosting/docker-compose/withPostgres
vim docker-compose.yml # WEBHOOK_URL先提前改成准备使用的域名，比如 https://your.domain

# 启动
sudo docker-compose up -d

# 关闭
sudo docker-compose stop

# 如果改动了docker-compose.yml，记得先rm再启动
# rm不会导致数据丢失
sudo docker-compose rm && sudo docker-compose up -d

# 启动之后可以通过 http://yourip:5678 访问了
# 如果无法访问，先检查腾讯云上的CVM网络完全组是否放开5678端口，顺便记得把443端口也打开

在腾讯云上为域名申请免费https证书

在这里申请免费ssl证书，成功后下载nginx类型的证书

把解压出来的your.domain_bundle.crt和your.domain.key文件放置到CVM的/etc/nginx/ssl_cert路径

利用nginx配置反向代理

sudo apt install nginx -y

# 先移除nginx默认配置
cd /etc/nginx
sudo rm sites-enabled/default

# 为域名添加反向代理
# your.domain替换为你自己的域名
sudo apt install nginx -y

# 先移除nginx默认配置
cd /etc/nginx
sudo rm sites-enabled/default

# 为域名添加反向代理
# your.domain替换为你自己的域名
sudo cat > sites-available/your.domain << 'EOF'
server {
        #SSL 默认访问端口号为 443
        listen 443 ssl; 
        #请填写证书文件的相对路径或绝对路径
        ssl_certificate ssl_cert/n8n.richie.wiki_bundle.crt;
        #请填写私钥文件的相对路径或绝对路径
        ssl_certificate_key ssl_cert/n8n.richie.wiki.key;
        ssl_session_timeout 5m;
        #请按照以下协议配置
        ssl_protocols TLSv1.2 TLSv1.3;
        #请按照以下套件配置，配置加密套件，写法遵循 openssl 标准。
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
        ssl_prefer_server_ciphers on;
        server_name n8n.richie.wiki;
        location ~ / {
                proxy_pass http://127.0.0.1:5678;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
                proxy_http_version 1.1; # Required for WebSocket
                proxy_set_header Upgrade $http_upgrade; # Required for WebSocket
                proxy_set_header Connection "upgrade"; # Required for WebSocket
        }
}
EOF

# 在sites-enabled建立一下软链，使配置生效
cd sites-enabled && sudo ln -s ../sites-available/your.domain

# nginx重载最新配置
sudo nginx -s reload

# 这个时候可以使用 https://your.domain 来访问一下试试了

⚠️ 如果已经可以正常访问了，记得把之前在安全组里放开的5678端口删掉

阅读原文：https://walkthewalk.today/posts/deploy-n8n-to-cvm-and-enable-https/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

logseq properties的使用

2026-08-11T14:55:11+08:00

添加

在 block 内添加多行 property 时，先输入一行 property:: value，再按 Shift + Enter 换行
输入 ::，Logseq 会自动提示已使用过的 property 名称
property 名称大小写不敏感，字符 _ 和 - 等价

如何理解

把每个 page/block 看成“数据库的一条记录”
properties 就是这条记录的“字段”
value 用于建立索引，支持引用 page 或 tag
借助 Logseq 的 query 可以按字段检索这些记录

示例

给书籍类 block 都加上分类：
```
category:: Books
```
查询所有书籍：
```
{{query (property category Books)}}
```

参考

官方文档: Properties - Logseq Docs
安全代码: Logseq 使用小结（三）

阅读原文：https://walkthewalk.today/posts/logseq-properties-usage/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！

GTD与思维导图对于工作管理的取舍

2026-08-11T14:55:11+08:00

当前我的任务管理系统（以滴答清单为载体）需要进行一次清晰的定位调整。

起因

滴答清单本身几乎满足了我对一套完整GTD系统的所有功能需求，但在实际使用中，滴答清单+GTD的工作流目前几乎难以运转，主要原因如下：

任务积压：滴答清单中已经堆积了大量因拖延而未完成的事项，导致系统不堪重负，“今日待办”失去了指导作用。
工具割裂：我的核心工作事项已逐渐迁移至腾讯文档的思维导图中进行管理。现实工作中，多项目并行推进是常态，更需要一种能提供大局观和灵活调整能力的工具。

why mindmap?

首先解释一下，（以我自己的使用体验）：

思维导图为何更适合核心项目管理？

经过多次尝试和摸索，我发现思维导图的任意层树状结构更能让我静下心来，踏实逐项击破复杂任务。

灵活适应变化：工作中常需要扮演“救火队员”的角色，突发任务和优先级调整是家常便饭。思维导图允许我将新信息或临时任务快速融入树状结构的合适位置，无需遵循GTD那套相对固定的完整流程（项目 → 任务 → 上下文等），这大大减轻了潜在的精神负担。
直观的项目梳理：思维导图能极其方便地进行项目的可视化拆分、合并和层级调整，枝叶之间关联清晰，非常适合管理需要大局观和灵活调整的项目。这种“任意层树状结构”有助于在项目规划时理清思路，进行系统性思考。
上下文的快速保存与恢复：其树状结构能很好地保存工作上下文，帮助我在任务切换后快速恢复到之前的思维框架中。

why dida/gtd?

接着，需要重新定义滴答清单的核心价值。

随着思维导图承担起核心工作的管理，滴答清单与我的主要工作流出现了割裂。

最近几周，我甚至可能一天都不会打开它。因此，必须明确和简化滴答清单的定位，让它发挥不可替代的作用：

生活与周期提醒：专注于管理日常生活安排和周期性定时提醒事项（如账单、常规事务）。
工作的辅助与收纳：处理零散的、不成系统的工作待办和备忘。同时，每天将思维导图中的高优待办事项（“枝叶”）也放入滴答清单，纳入Today视图。
时间跟踪与评估：利用其番茄钟等功能，严格评估和跟踪任务用时，实践一种弱化版的柳比歇夫时间统计法。
今日待办的纪律：Today视图里只放置那些真正计划在今天完成的任务。如果确实无法完成，则必须对其进行拆分或重新评估优先级，以保持“今日待办”的可靠性和可执行性。
坚持GTD的回顾环节：回顾（Review）是GTD的精髓，也是不能完全放弃滴答清单的关键原因。虽然思维导图能方便地标记状态和时间，但滴答清单提供的按时间线（Timeline）进行的线性每日/每周回顾，能带来更强的时间观念，进行更有规律的自省。这种回顾有助于增强对整个时间管理系统的信任感——这种信任能产生“拨云见雾”的效果，让大脑得以减负，从而专注于当下，暂时忘却其他事务，更放心地快速进入心流状态。

总结

调整后，我的任务管理系统将变为：

以思维导图为核心，进行工作项目的规划、分解和全局监控；
以滴答清单为辅助，处理生活提醒、零散任务、时间跟踪和每日重点执行，并坚守GTD的回顾环节。

二者各司其职，形成互补，以期更高效、无压力地管理任务和时间。

阅读原文：https://walkthewalk.today/posts/gtd-vs-mindmap-for-work-management/
博客公告：博客现已开通邮件订阅，欢迎通过 Substack 订阅支持我的创作！