涯木说

WorkBuddy 接入 Notion 了！我的一站式工作流闭环

Mon, 06 Jul 2026 00:00:00 GMT

前几天我发现 WorkBuddy 的 Notion 连接器终于开放了，第一时间试了一下。连上之后，WorkBuddy 可以直接读写我的 Notion 页面和数据库——写文章、记笔记、查资料，全在一个对话里搞定，不用来回切换窗口。

这个功能对我这种每天在 Notion 里发文章（我的博客是用 NotionNext 搭的）的人来说简直就是刚需。以前要在 WorkBuddy 和 Notion 之间来回切，先让 AI 写，再复制到 Notion，再排版。现在一句话就能把文章写进数据库。

这篇文章就聊聊怎么用，以及我目前的工作流。

为什么要连 Notion？

如果你用 Notion 当知识库或 CMS，又用 WorkBuddy 写东西，这两个工具之间就是一座桥——只是以前你要自己去走，现在坐车了。

具体场景：

写博客：我的网站是基于 NotionNext，文章存在 Notion 数据库里。WorkBuddy 连上后，直接在我的数据库里创建新文章、填属性、发内容，一条龙。

记笔记：工作讨论中产生的灵感，让 WorkBuddy 直接写到 Notion 对应的项目笔记里。

查资料：WorkBuddy 可以搜索我 Notion 里的所有内容，写作时自动引用之前的笔记，不用靠记忆翻找。

怎么连接？

操作本身很简单，不需要任何代码，但我踩了一个坑，值得单独说一下。

标准步骤

打开 WorkBuddy → 左侧栏的「连接」面板

找到 Notion，点击连接

我遇到的问题

点击连接后，浏览器跳转到 Notion 的授权页面——但如果你电脑上装了 Notion 本地 App，系统会自动把这个链接交给本地 App 打开，而 Notion 的桌面端似乎不支持完成这个 OAuth 授权流程。我试了几次，都在本地 App 里卡住了，无法完成连接。

解决方法：把 Notion 本地 App 卸载掉。然后重新点击连接，链接会在浏览器里正常打开，授权就能顺利完成了。

权限控制

还有一点——我不太想把整个 Notion 工作空间都暴露给 WorkBuddy，我的 Notion 里有一些私人笔记和工作无关的内容。所以连接成功后，我去了 Notion 的设置里，把 WorkBuddy 的权限限定在「只能访问某一个笔记本」的范围。

具体操作：Notion 设置 → 我的已连接应用 → 找到 WorkBuddy → 选择「选中的页面」，勾选你希望 WorkBuddy 能读写的笔记本或页面。

这样既用上了连接功能，又不用担心隐私问题。

实际使用：写一篇文章到 Notion

以我今天刚做的操作为例。我跟 WorkBuddy 说：「帮我把这篇关于 HanaAgent 本地 AI 的文章发到涯木说数据库，分类数码科技，状态已发布。」

它直接就在我的 Notebooks 里创建了一个新页面，把文章正文写进去，属性全部填好——标题、分类、标签、摘要、slug、日期、状态，一个不漏。

之后 NotionNext 自动同步到网站，几分钟就能在 nickyam.com 上看到。整个过程我没碰一下 Notion 编辑器。

你可以做什么

按我的经验，下面几个场景最实用：

1. 用 WorkBuddy 批量整理 Notion 数据库

在 WorkBuddy 里一句话就能操作多个页面。比如「把这个分类下所有草稿状态的页面改成已发布」，或者「把所有标签带 AI 的文章摘要重新写一遍」。这要是手动在 Notion 里做，得一页一页改。

2. 写作时直接引用 Notion 笔记

写公众号文章时，如果之前把素材记在了 Notion 里，直接在 WorkBuddy 里说：「搜索 Notion 里关于本地 AI 的笔记，把这些内容整合到这篇文章里。」它会把相关笔记找出来直接引用。

3. 创建多级页面结构

比如你要搭一个项目文档库，让 WorkBuddy 在 Notion 里创建一个项目主页 → 下面建 5 个子页面 → 每个子页面写好对应的模板内容。手动做至少要 30 分钟，WorkBuddy 一句话 2 分钟搞定。

目前的问题

说完了好的，说一下我遇到的问题，也供你参考：

本地 App 干扰 OAuth：上面提到的，装了 Notion 桌面端会导致授权跳转卡住，需要卸载或改用浏览器。

权限粒度需要手动设置：默认连接是访问整个工作空间，建议连接后去 Notion 设置里限定范围。

异步任务有延迟：创建大量页面时，Notion 会走异步队列，几十秒到一两分钟才能完成。批量操作时耐心等一会儿就好。

复杂的 Notion 公式和数据库聚合函数暂时不支持读写，不过日常写文章和记笔记完全够用。

手把手搭建｜用 M2 MacBook Air 跑本地 AI 助手，和 HanaAgent 聊聊人生

Sun, 05 Jul 2026 00:00:00 GMT

几天前我干了件挺有意思的事——在自己的 M2 MacBook Air 上搭了一套全本地的 AI 助手，用它来整理人生经历。不是云端大模型，不联网，所有数据留在自己电脑上。

装上之后我做了个小实验：把过去几年的经历一点点讲给它听，让它帮我梳理脉络、提炼主题。效果超出预期，像是在和一个有耐心、有洞察力的朋友聊天。而且因为是本地运行，深夜窝在沙发上打开电脑就能聊，不用考虑 API 费用，不怕隐私外泄。

整个过程涉及四个工具：Ollama（模型运行引擎）→ Qwen 大模型（阿里通义千问）→ HanaAgent（桌面 AI 客户端）。

我的硬件

MacBook Air M2

内存 16GB（统一内存，也就是 GPU 和 CPU 共用）

无风扇（被动散热）

16GB 跑本地大模型属于「刚好够用但不富裕」的级别。如果你也是这个配置，我的调参经验应该可以直接照搬。

第一步：安装 Ollama + 拉取模型

Ollama 是目前跑本地大模型最方便的工具，没有之一。

接下来拉取三个模型：

主对话模型 — Qwen3 14B

轻量任务模型 — Qwen3 8B

视觉模型 — Qwen3-VL 8B

模型拉下来约 20GB。

第二步：自定义模型参数（关键！）

Ollama 默认上下文窗口只有 4096 token，太短了。8B 拉到 32768，14B 拉到 16384。

第三步：内存优化

加到 ~/.zshrc。用完自动卸载。

第四步：安装 HanaAgent

选择 macOS arm64 版 .dmg。

第五步：配置 4 个模型槽位

槽位	用途	我用的模型
对话模型	主对话	qwen3-16k:14b
小工具模型	分类、提取等	qwen3-32k:8b
大工具模型	深度分析	qwen3-16k:14b
视觉模型	处理图片	qwen3-vl:8b-instruct-q4_K_M

Settings → Model Provider → 选 Ollama → Base URL http://localhost:11434/v1。

记得打开辅助视觉开关。

使用场景：和 AI 聊聊人生

我把它当「人生整理师」，WorkBuddy 做日常工作。安静、私密、免费。

避坑指南

上下文长度 — 按上面改到 16k/32k

M2 Air 无风扇 — 14B 连续跑会降频

视觉模型别忘了开

磁盘至少预留 30GB

Google.cn 访问不了？换个 DNS 秒解决

Mon, 01 Jun 2026 00:00:00 GMT

最近遇到一个比较奇怪的现象。

想从 Google 中国站（google.cn）下载 Chrome 浏览器时，发现电脑端始终无法打开页面。奇怪的是，此前一直都能正常访问，而且出口防火墙策略也没有做过任何调整。

更离谱的是，同一时间手机切换到运营商流量后，却可以正常打开网站。

原因其实很简单

根据现象分析，大概率是 DNS 解析出了问题。

简单来说，就是我使用的 DNS 服务器在解析 Google 域名时“指错了路”，返回了一个无法正常访问的 IP 地址，最终导致网站打不开。

一招解决

我将原先使用的阿里云 DNS（223.5.5.5）切换为腾讯云 DNS（119.29.29.29）进行测试，结果立刻恢复正常访问。

进一步验证

为了确认问题来源，我又切换回阿里云 DNS，并使用 nslookup 对 www.google.cn 进行解析。

结果发现，阿里云 DNS 返回的是一个位于境外的 Google Cloud 主机 IP。

而使用腾讯云 DNS 解析时，返回的则是一个国内 IP 地址。

这里还有个小插曲：通过微步在线查询时，这个国内 IP 被标记为“恶意地址”，不过实际访问测试一切正常，并未发现异常。

此外，即使不修改 DNS，只要在本地 Hosts 文件中手动绑定正确的 IP，同样可以正常访问 Google.cn。

总结

这次问题最终并不是防火墙策略导致的，而是 DNS 解析结果发生了变化。

当遇到某些网站突然无法访问，而网络环境和安全策略都没有变化时，不妨优先检查一下 DNS 解析结果，或尝试更换不同的公共 DNS 服务进行验证，往往能够快速定位问题。

3.1万Star！彻底告别传统VPN，这款神器让你一秒组网

Sat, 30 May 2026 00:00:00 GMT

URL

type

Post

status

Published

date

May 30, 2026

slug

say-goodbye-to-traditional-vpn-this-powerful-tool-lets-you-build-a-network-in-seconds

summary

传统的 VPN（比如 OpenVPN、IPsec）配置繁琐、速度慢、容易断线，让人苦不堪言。后来有了被誉为“现代 VPN 终结者”的 WireGuard，速度起飞了，但密钥管理和网络拓扑配置依然是个大工程。难道就没有一种方案：既有 WireGuard 的极速，又有“傻瓜式”的一键连接体验？ 今天，我们就来聊聊 GitHub 上狂揽 3.1万+ Star 的超级开源神器——Tailscale。它被无数开发者称为“网络组网的最终答案”。

什么是 Tailscale？

简单来说，Tailscale 是一款基于 WireGuard 协议的“零配置”虚拟局域网（VLAN）工具。

不管你的设备是在公司内网、家里的路由器后面，还是在云服务器上，只要安装了 Tailscale 客户端，它们就会立刻被拉进同一个私有局域网里。你可以直接用一个固定的局域网 IP互相访问，仿佛它们就插在同一台交换机上。

官方给它的定义是：“使用 WireGuard 和双因素认证（2FA）最简单、最安全的方式。”

为什么开发者对它爱不释手？

1. 极致的“零配置”体验

用传统方案组网，你需要搞懂公网 IP、内网穿透、NAT 类型、防火墙规则、路由表…… 而用 Tailscale，你只需要：下载 -> 登录账号 -> 连接。结束。

它会自动处理所有底层的 NAT 穿透（UDP 打洞）魔法。只要两台设备能上网，就能直连。如果是极端复杂的网络环境（比如两边都在深层对称 NAT 后面打洞失败），它也会自动通过全球分布的 DERP 中继服务器进行加密转发，保证网络“永不失联”。

2. 天生安全的 SSO 整合

告别繁琐的密钥文件分发！Tailscale 巧妙地抛弃了传统的“用户名+密码”或“证书文件”认证，直接接管了现代的身份提供商（IdP）。

你可以直接使用 Google、微软、GitHub 或者公司自建的 SSO 登录。团队新人入职，只需用公司邮箱登录一下就进内网了；员工离职，禁用邮箱账号，他的网络权限瞬间失效。配合 2FA（双因素认证），安全性直接拉满。

3. 基于 Golang，全平台制霸

Tailscale 的核心代码库（包括后台守护进程 tailscaled 和命令行工具 tailscale）95% 以上使用 Go 语言编写。这意味着它天生具备极高的性能、内存安全和极佳的跨平台能力。

它支持你能想到的几乎所有设备：

○ 桌面端：Windows、macOS、Linux (各种发行版)、FreeBSD、OpenBSD。

○ 移动端：iOS、Android。

○ NAS和路由器：Synology (群晖)、QNAP (威联通)、OpenWrt 等。

○ 云原生：甚至完美支持 Kubernetes Operator。

4. 点对点直连（P2P），延迟极低

传统 VPN 都是“中心化”的。比如你和同事都在上海出差，你们想互相传个文件，数据竟然要先绕到位于北京的 VPN 统一网关，再绕回上海，延迟极高且占用网关带宽。

而 Tailscale 构建的是一个 Mesh 网络（网状网络）。只要打洞成功，设备之间就是点对点（P2P）直接通信。加上底层使用了加密极简、性能无敌的 WireGuard 协议，跑满千兆带宽完全不在话下。

Tailscale 能用来干什么？

有了它，你的网络玩法将彻底被打开：

○ 随时随地远程办公：在星巴克无缝 SSH 连回老家吃灰的树莓派。

○ 安全的内网穿透：把家里的 NAS 或者本地跑的 Web 服务暴露给特定的朋友，不用担心被公网黑客爆破。

○ 自建异地联机房：和哥们儿异地组网，流畅游玩《幻兽帕鲁》、《我的世界》等各种局域网联机游戏。

○ 无缝开发测试：前后端分离开发时，前端同学直接访问后端同学本地的 8080 端口，无需再部署到公用测试服。

结语

在计算机网络的世界里，有一句名言：“所有复杂的网络问题，都可以通过加一层抽象来解决。”

Tailscale 就是这层近乎完美的抽象。它把 WireGuard 这种硬核极客协议，包装成了连小白都能一键上手的傻瓜服务，并且完全开源了最核心的客户端和守护进程。对于个人用户，它还大方地提供了支持 100 台设备接入的免费套餐，足够满足绝大多数人的折腾需求。

如果你还在忍受传统 VPN 的折磨，赶紧去试试 Tailscale 吧。相信我，只要用过一次，你就再也回不去了！

参考资料/来源

○ GitHub - tailscale/tailscale

这些年科学上网的姿势

Mon, 13 Apr 2026 00:00:00 GMT

第一阶段：纯机场时代

刚开始接触科学上网，完全不懂技术，自然是从最省心的机场入手。那个年代机场圈还算繁荣，竞争激烈。

先后用过这几家：

rixCloud算是比较早期有品牌意识的机场，界面做得不错，有自己的客户端，当时体验还算可以，算是入门级的"高端机场"。

Amy（按摩院）奶昔的分厂，主攻亚太地区。

奶昔算是有口碑积累的老牌机场，稳定性在当时口碑不错。

这个阶段最大的问题是：命运不由自己掌控。机场说跑路就跑路，说被墙就被墙，充了年费结果某天打开订阅就404，这种经历不止一次。加上高峰期晚上8-11点那个速度，真是一言难尽。

第二阶段：机场 + 自建（初尝试）

慢慢开始觉得纯依赖机场太被动，于是开始折腾自建。但这个阶段属于"主力还是机场，自建图个安心备用"的状态。

先后试过：

搬瓦工（BandwagonHost）

自建的启蒙选择，几乎是那个年代每个折腾VPS的人必经之路。CN2 GIA 线路在当时算是国内访问质量的天花板，延迟低、丢包少。搭 SSR/V2Ray，跑起来那一刻确实有种掌控感。缺点是贵，而且官网买套餐要抢，补货秒没。

搬瓦工（BandwagonHost）主要机房和线路

搬瓦工的核心价值在于线路，机器本身性能一般，选它就是选路由。

DC6 / DC9 — CN2GIA洛杉矶机房，电信走CN2 GIA 回国，是搬瓦工最经典的线路。CN2 GIA属于电信的精品网，全程59.43.x.x 段，优先级最高，晚高峰抗拥塞能力强。缺点是联通、移动走的是普通路由，非电信用户体验打折。

HKBN — 香港香港节点，回程走CN2 GIA，延迟极低（广州方向约 10ms），但价格贵，且库存长期紧张，难抢。

JPOS — 日本大阪走软银（SoftBank）线路回国，对移动用户非常友好，移动有直连软银的海缆，延迟低且稳。

总结：搬瓦工适合电信用户重点考虑DC6/DC9，移动用户可看JPOS，联通用户其实搬瓦工并不算最优解。

DMIT相比搬瓦工更小众一些，胜在线路选择更灵活，有CN2 GIA、CMIN2等多种接入，价格稍亲民，社区口碑一直不错，属于懂行的人才会去关注的服务商。

DMIT 主要机房和线路

DMIT比搬瓦工更灵活，同一个机房经常提供多个线路套餐，按需选择空间更大。

LAX — 洛杉矶提供三个档次：

Lite：普通线路，去程直连，回程走AS4837（联通骨干），适合预算有限

Standard（原 Pro）：去程CN2 GIA，回程CN2 GIA，三网都走精品网，全面均衡

Premium（EB）：去程CN2 GIA + CMIN2，回程针对三网分别优化，移动走CMIN2，联通走 4837/CN2，电信走CN2 GIA，是目前DMIT洛杉矶最顶配

HKG — 香港

Premium：回程走CN2 GIA，延迟极低，是自建党里香港节点的热门选择

Lite：走普通BGP，便宜但高峰期表现一般

TYO — 东京

提供Premium套餐，回程三网优化，移动直连效果尤其好

第三阶段：广港专线 / IX / 腾讯 BGP + 落地家宽

这个阶段算是质的飞跃，开始认真研究入口和落地这两个维度，而不只是随便找台VPS自建了事。

广港专线即广州到香港的专用线路，走的是内地到香港之间的物理专线或优化路由，延迟极低（正常 10ms 以内），稳定性远超公网绕路。对于香港节点来说，这条路是体验天花板。

IX（Internet Exchange，互联网交换节点）通过IXP对等互联接入，绕过运营商的公网拥塞点，直接在交换层面走高质量路由。理解这一层之后，选节点和选服务商的逻辑就完全不一样了，开始会看BGP路由、AS号这些东西。

腾讯BGP利用腾讯云等大厂BGP网络作为中转入口，依托大厂对三网（电信/联通/移动）的优化能力，解决了国内不同运营商访问质量不一致的问题。大厂BGP的IP段本身不容易被墙，稳定性也比普通VPS强得多。

落地家宽这是整个链路里最有意思的一环。海外落地从机房IP换成住宅IP（家宽），适合一些特殊场景使用。

这个阶段的核心思路已经从"找一台能用的服务器"升级成了：精心设计一条完整的链路——国内优质入口 → 中转层 → 海外优质落地，每一段都要单独优化。

专线的路由逻辑——到底过不过防火墙？

这是很多人容易搞混的地方，理解路由层面的差异，才能真正理解为什么"专线"体验不一样。

1. 普通 VPS 自建的路由路径

流量走的是公共互联网，每一个包都要经过GFW的检测节点。协议混淆（XTLS、REALITY 等）的作用就是让流量在这一段看起来像正常 HTTPS，降低被识别和干扰的概率。本质上还是在过防火墙，只是尽量"伪装通过"。

2. IEPL 的路由路径

IEPL（International Ethernet Private Line，国际以太网专线）是运营商之间签订的物理或逻辑专用链路，数据走的是独立于公共互联网的专用通道。

关键在于：这条通道不经过GFW。

GFW的检测部署在公共互联网出口，而IEPL绕过了这些出口节点，走的是运营商间的专用互联链路。所以IEPL节点的特点是：

不需要协议混淆，用最简单的SS也能稳定跑

延迟极低且极稳定，几乎没有晚高峰波动

被封的风险极低，因为GFW根本看不到这条链路

代价是成本极高，IEPL带宽按Mbps向运营商租用，价格远高于普通VPS，所以机场卖IEPL节点的套餐普遍偏贵，且往往限速或限流量。

3. IX 的路由路径——与真实IEPL的差异

IX（Internet Exchange，互联网交换节点）在名字和宣传上经常和IEPL混用，但路由逻辑有本质区别，需要单独说清楚。

IX 的路径大致是：

与 IEPL 的核心差异在于：

IX 的国内段只能走国内大厂机器作为入口，通过内网到达IX接入点完成交换，再经过专线落地。

这意味着：

国内出境段需要有前置机，前置机与IX入口走云厂内网。

不过墙，意味着你的落地机可以直接用ss协议

你的带宽上限受限于你的前置机

你需要单独购买前置机

几个需要注意的点，你的落地机使用什么协议取决于是否过墙。

我目前在使用的

1、机场

仅存eNet一家，不限时的500G流量，完全做备用。

2、线路机

DMIT Malibu ，一年$49，三网去回均走电信CN2，每月流量1T(双向)

DMIT Corona，一年$49，三网各自优化，每月流量2T(双向)

3、专线机

po0 腾讯华东入口，年付1180，200m带宽，每月流量500G(单向)。

你可以理解成是包含了前置机的IX，只不过这是满血版的腾讯锐驰套餐的前置机。正常你在腾讯云买的锐驰只是峰值带宽200m，你如果长时间跑，很快就会被限速，而这个不会。

目前po0为主打方案，入口机直接nftables内核转发到RFC的JPT1和HKT1，相当于同时拥有了沪日专线与沪港专线。

4、落地家宽

Boil 家里云，现在基本上没有使用了，注意是港机限制还是有点多，AI不能用。从一个月$9起价，同时还有很多绝版套餐，比如季付297、半年付777等。

vircs，AT&T落地，50m带宽，流量不限，$276/年，主要做AI分流、PayPal分流。用DMIT做中转相当丝滑。

如何看你的vps路由

安装nexttrace

Cloudflare WARP 复活归来

Fri, 30 Jan 2026 00:00:00 GMT

Warp大概前一年有新协议的时候，很多人在宣传啊，我都没用上，后面就服务器挤破了，直接死得透透的；现在复活回来了。

Cloudflare WARP 已支持后量子加密，是通过 MASQUE 隧道（基于 QUIC 的安全通道）来传输你的请求和 DNS 查询的。

传统 DNS 请求是明文的，容易被劫持或监控。WARP 会把你的域名查询通过 DNS over HTTPS (DoH) 或 DNS over TLS (DoT) 加密发送到 Cloudflare 的 DNS 服务器（1.1.1.1）。

笔者是在mac和iphone上使用的，不知道windows可以不可以，请各位自行尝试。

如果你需要临时使用美区账号，请访问：

https://www.nickyam.com/article/AppleID_us