2026-09-26 08:00:00
六月看的书，拖了三个月才把这篇写完。严格来说不是笔记也不能算正经书评，还有相当多的个人发散，不过还是放在 notes 这个分类下好了。
因为豆瓣友邻的「想读」而点进详情看了眼，感觉被简介点名──we are highly social species but we often choose to be unsocial。
We know that social connection enriches our lives—so why do we hesitate to connect?
There is a paradox at the core of human life. We are a highly social species uniquely equipped to connect with other people and doing so is better for us. Yet we so often choose to be unsocial. We avoid talking to the stranger who sits next to us. We struggle to move beyond small talk with an acquaintance. We are reluctant to express our gratitude to people we appreciate. Every day, we avoid opportunities to connect with strangers, neighbors, colleagues, friends, and family.
我确实有些时刻想和人发生关联，可时常消息在对话框都打完最终也没有发出。这种犹豫偶尔会让我困扰，也让我想探究，哪怕大概率知道这本书不会收获很多还是读了，Libby 上借的 audiobook，倍速听完，注定漏掉了非常多细节。
三星。不算存在什么新知，还有北美非虚构一向的毛病：案例堆砌。
作者核心论点：
总结：你不需要多么外向，但是你的实际社交需求通常大于你现在的社交行动，所以你只需要比原来多社交一点，就能比现在更开心、更幸福。
看，已经把内容概括完了。
那为什么有声书能抻到八小时呢？当然就是北美非虚构的典型套路了，作者观点──案例，无限循环。谁谁谁听从作者劝告，在 XX 情境下做出以往不会做的社交行动，最后收获正面社交反馈。甚至还有人对作者说 your advice has changed my life。
问题是，愿意参与作者实验和给作者反馈的，是否本就是相对有社交渴望和更容易做出社交行动的人？作者的样本分布又究竟如何，年龄、种族、性别、社会阶层、学历/职业背景，这些会不会也会对结果产生影响？这些我都没有在有声书里听到。而且书里提及的所有案例，无一负面反馈。这种呈现会不会也是筛选的结果？
另外我无法忽视书里轻描淡写略过的一段叙述。某位女性说尽管在通勤路上和男性交谈可能会被误认为「flirting」而招致不愉快感受，但总体收获是正面的。作者援引这个案例意在说明，即使女性承受了被异性骚扰的风险（和不快），女性仍然更愿意主动 social，并且愉快的反馈更多──所以，‘A little more social’ 依然是 positive 的。
是这样吗？社交体验能这样做简单算数吗？正面反馈比负面反馈多，总数就是正的吗？负面体验就可以被简单地抵消吗？可事实上是，一次被骚扰被侵犯的负面感受，就足以放大到覆盖掉十倍甚至百倍的积极感受。在作者本人都承认了女性可能承担的风险的情况下，为什么不展开讨论如何规避这种风险和可能招致的负面影响，而只是说，哦，总体是愉快的？
至于海量堆叠的案例有没有用处？有两个确实让我有所触动。
一是，作者在某次旅途中，有位陌生男人要为他提供帮助，而他连声拒绝（thanks but no），对方坚持，他再次拒绝（no no no）。对方这时说，“Can you not accept a blessing when it’s offered to you?"。
作者说，他一下子愣住了，“felt like being punched in the face”。在他无数次对别人宣讲「你应该如何对待他人」后，他自己却忘了如何接收善意。是啊，付出和接受同样重要。说起来很空泛，可我突然意识到，愿意展露需求和愿意接受帮助，这对关系的加深一样有所帮助。
二是，作者一个学生说决定给所有他欣赏的创作者们留言/发邮件表达赞赏，无论是否会收到回复（且没有期望会得到回复）。然而，无一例外，所有人都回复和表达了「你的支持对我来说非常重要和非常鼓舞」。
我在意的不是收到回应，而是直白地体会到这种单向的支持原来对作者们也如此重要。这让我觉得或许日后我可以更没有负担地去表达欣赏。
另外去找了下书里给的 small talk 和 deep questions 的表格用作参考。
只是我不觉得我会对其他人提出这些问题，尤其是陌生人，而我也大概率不会回答这样的问题──不过这就是我自己的功课了。
| Typical Topics | Deeper Topics |
|---|---|
| Where are you from? | What do you want people to remember you for? |
| What brings you here today? | Where do you see yourself in twenty years? |
| How do you like this park? | What is something you’re really grateful for? |
| What do you do for a living? | Are you happy with where you are in your life? |
| How are you today? | What is your biggest regret in life? |
| What do you like to do? | What brings you joy? |
| How do you like the weather today? | What was the best day of your life? |
| How long have you lived here? | What is something that you want to accomplish? |
| Do you have children? | What are you passionate about? |
关于书的部分说完了，下面聊聊由此引发的一些个人实践。
2026-07-05 08:00:00
终于解决了长久以来在 Obsidian 里的一个摩擦点──说大不大，但每次都让我禁不住地想：过程能再无痕、再顺滑一点就好了。
前提：
我的 Obsidian vault 和 Hugo site 共用一套 markdown 文件。
需求：
站内文章互相引用时，可通过文章标题而非 MD 文件名为关键词插入链接，并且链接显示文字也为标题，同时在两个系统内都可被识别并准确跳转。
以本文为例：
title： 一个更顺滑的 Obsidian 内链插入流程filename： obsidian-link-workflow.md
如果用 Obsidian 双链（[[]]）实现快速插入，必须用文件名中的关键词检索：
由于我关闭了 Obsidian 设置中的 wiki link，因此完成插入动作后 Obsidian 会自动将其转换成标准 MD 链接，输出结果就是：[obsidian-link-workflow](obsidian-link-workflow.md)。还得回头再编辑文本内容。
而理想状态是，键入对人脑记忆更友好的标题名（而非为了 slug 标准只使用字母、数字、下划线或连字符的文件 basename）来快速插入，同时输出结果也是易读的标题，即：[一个更顺滑的 Obsidian 内链插入流程](obsidian-link-workflow.md)。
用 QuickAdd 插件结合自定义脚本实现。
在 Obsidian vault 中新建 insert-title-link.js 文件，内容如下：
module.exports = async ({ quickAddApi, app }) => {
const files = app.vault
.getMarkdownFiles()
.sort((a, b) => b.stat.mtime - a.stat.mtime);
const choices = files.map(file => {
const title =
app.metadataCache
.getFileCache(file)
?.frontmatter
?.title;
return {
title: title ? String(title) : "",
basename: file.basename,
file
};
});
const selected = await quickAddApi.suggester(
item => item.title || item.basename,
choices,
"Search notes..."
);
if (!selected) return;
const displayTitle = selected.title || selected.basename;
app.workspace.activeEditor?.editor?.replaceSelection(
`[${displayTitle}](${selected.file.name})`
);
};
安装 QuickAdd 插件，在 QuickAdd 设置中创建 Insert Link（可随意命名）
Macro
，为其绑定上面的 insert-title-link.js 并激活，具体步骤见
官方指引
，我懒得打字儿。
Insert Link，为其绑定一个不冲突的快捷键（我用的是 Alt + X）。按下 Alt + X 后，光标处会弹出以标题显示最近打开的文件列表，或是在搜索框内键入标题关键字查询对应文件，选定后即可快速插入。
这样既保留了稳定的文件名作为链接目标，又避免了每次插入链接后再手动修改显示文字。Hugo 会在渲染阶段统一处理这些站内链接──依靠自定义 render hook 实现（layouts/_default/_markup/render-link.html 文件）。
2026-06-17 08:00:00
没想到这个系列居然还能继续。其实从外观看不出什么变化，不过我的「装修」一向是能不动 CSS 就不动 CSS，基本不会从视觉效果层面去做装饰。
这次的主要折腾就是它了，分开讲。
新增了一个 property abstract，目前的 markdown 文件 front matter 控制可见度的是如下属性：
---
rss_ignore: false
abstract: false
hide: false
---
分别对应的是：是否输出 RSS，是否输出 RSS 全文，是否在站点内隐藏（首页，archives，taxonomy 等集成页面）。
显示最近五篇 hide 与 rss_ignore 都不为 true 的文章。
通常首页对应的是 layouts/index.html，在里面加上下面的过滤条件。
{{ range first 5 (sort (where (where site.RegularPages "Params.rss_ignore" "ne" true) "Params.hide" "ne" true)"Date" "desc") }}
{{ end }}
在 archives.html 里：
移除 tag 集中展示，改为显示网站开启的 taxonomy 类别，即， Categories ， Tags 和 Series 。
<div>
<p>
{{ range $key, $value := .Site.Taxonomies }}
{{ if gt (len $value) 0 }}
<span class="inline-block ml-2">
<a href="/{{ $key | urlize }}/">{{ $key | title }}</a>
</span>
{{ end }}
{{ end }}
</p>
</div>
显示所有 hide 不为 true 的文章。
<div>
{{ range (where site.RegularPages "Params.hide" "ne" true).GroupByDate "2006" -}}
{{ end }}
</div>
我用的这个主题过于简陋，根本没有给 Hugo 的 taxonomy 写模版，像 domain/categories/ 或是 domain/tags/ 都没有相应页面，导致访问时它们会变成遵守站点默认 list.html 规则，显示了整站所有文章。
新建 layouts/_default/terms.html 文件。
{{ define "main" }}
<div id="reading-progress-bar" role="presentation" class="fixed z-10 top-0 left-0 h-1 bg-gray-700"></div>
<article class="article">
<h1 class="artitle_title">{{ .Title }}</h1>
<div class="mt-8 text-xl leading-relaxed text-gray-700">
{{ range .Data.Terms.ByCount }}
<span class="inline-block mr-2"> · <a href="{{ .Page.RelPermalink }}" class="hover:underline">{{ .Page.Title }}</a><sup class="text-gray-500 ml-0.5">{{ .Count }}</sup>
</span>
{{ end }}
</div>
</article>
{{ end }}
作用是为已开启的 Hugo 各 taxonomy 生成包含下属所有标签文章计数的聚合列表页。（怎么感觉这么不像人话呢，看截图吧。）
然后再分别新建 layouts/taxonomy/tag.html，layouts/taxonomy/category.html，layouts/taxonomy/series.html。
这是为各具体标签生成列表集成页，比如 domain/tags/toolbox。我的重点其实就是这一行语法，把属性是 hide 的文章筛出去，保证它们在任何一个聚合页面都不会出现。
{{ $filteredPages := where .Pages "Params.hide" "ne" true }}
上面都是给人看的页面，改完之后不管在站内任意聚合页都不会有 hide 属性的文章被收录。这里改的就是给机器看的页面了。
不放代码了，反正都是 AI 写的。
RSS 的过滤逻辑是，输出 rss_ignore 不为 true 的最近十篇文章，若文章 abstract 为 true 则显示摘要，否，则显示全文。这里为什么不过滤 hide 呢，因为秉持状态设计的 single responsibility principle 和 orthogonality 原则（？，我前阵子估计是看编程黑话走火入魔），hide 当然也可以输出到 RSS 嘛。这种类型的文章就是，仅能通过直链访问，而无法直接在站内找到。
然后是 sitemap 。这个东西通常是 Hugo 默认生成，包含站点内所有可访问链接，一般是给搜索引擎、各网络爬虫看的。那么，如果不想让历史文章尤其这些设置了 hide 的文章被挖坟，自然也要自定义了。改动的是 layouts/sitemap.xml 文件（没有就新建一个）。
我的设置是，仅收录一年内发布、且 rss_ignore 和 hide 都不为 true 的单篇文章。为什么这么搞，实在是最近被各个爬虫爬得快疯掉了。有些犄角旮旯的文章和链接一看就知道不可能是人翻出来的必然是爬虫直接从 sitemap 里挨个走了一遍。也幸好这是静态站，动态站的话流量账单全付给爬虫了。我虽然不用付账单，但限制之后至少访问统计里爬虫的数量能少点。
关于 Hugo 的页面生成规则有更多可讲的，这次把 Hugo 的官方文档相关内容从头到尾看了遍总算弄清楚了逻辑，下次或许可以写篇更详细的总结（或者让 AI 写）。
其实我也并没有那么真的在乎历史文章被爬虫或者是真人挖坟，但就是好奇对于静态站我能够控制到哪一个层面，所以忍不住一层层地研究下去了。
在每篇文章下加了个“请我喝咖啡”的链接。
好久之前和朋友互相打趣就会说快点在你的博客放上「请我喝咖啡」打赏链接走上网络 KOL 之路！其实我对这个没有排斥，凭劳动赚钱又不丢人！只是当时我严肃调研了各个平台，方便提现同时不暴露实名的方式实在太少。最后绕了一圈选择了 Patreon 的虚拟商品链接。至于它家主打的会员模式，感觉不大可能有人来订阅我这个互联网尾部博客吧……
给早期只有书名、没有书籍链接的月度阅读记录都补上了 NeoDB 卡片（幸好这活儿现在有 AI 干，让我手动我会疯掉）。
最后，最近突然勤快的原因：
补了近百本书籍 NeoDB 卡片后，站点 footer 里的字数统计突然飙升十万字，我这才意识到 shortcode 生成的文本内容也被计了进去。既然字数不准，并且想想挂在网站上其实也没什么意思，就索性移除了。
但我还是想知道到底写了多少，就在 Obsidian 里用 dataview 列了个统计，请看：
草稿 13 万，博客文章 31 万，可真有我的（拖延王者简直）。
所以，接下来的目标是，不要继续囤积草稿，该发的发，该删的删。