分享一套让所有 Agent 免费「调用」5.6 Sol 的省额度方法，适合拥有自己的付费 ChatGPT 账户的朋友。

我们知道 ChatGPT 网页端进行对话时，是不消耗 Codex 的额度的。我们经常在网页上让 ChatGPT 去帮我们做网络检索、深度思考等工作，然后可能把它给出的方案再转发给 Agent。其实这么一套机械的操作是完全可以自动化的。

如果使用同一个 ChatGPT 网页端账号和 Codex 账号，那你可以直接在 Codex 里面 @ 聊天 来实现上下文的快速转移。但很可惜，我自己使用的 Codex 并不是网页端的账号，网页端只是一个 Team 账号。我在想，在这样的情况下，有没有什么办法可以快速地实现上面的要求呢？

于是，我找到了 Oracle 这个项目。

在古希腊罗马，oracle 指传达神谕的场所或人物。人类无法掌握的信息，通过它获得答案。

它可以用浏览器自动化的方式，帮我们在网页端问 ChatGPT，然后返回结构化的回复。支持把本地的代码、截图等文件作为「附件」上传，选择模型和思考程度（没错，如果你比较壕，也可以直接选择问 5.6 Pro）。

安装这个项目的 CLI，然后再搭配 Skill，我们就可以教会任何Agent 如何把 5.6 Sol 这个高级模型作为一个工具来进行调用，还能让它获得你的上下文和联网等各类外部信息。

配置方式

注：此类自动化操作可能导致潜在的账号封禁。如果您特别担心这类风险，不建议这样操作。

如果你使用 MacOS，可以用下面的命令一键安装：

1

brew install steipete/tap/oracle

也可通过 NPM 安装（通用）：

1

npm install -g @steipete/oracle

让你的 Agent 阅读 https://github.com/steipete/oracle 安装配套的 Skill。

接下来你可以根据自己的偏好，在官方的 Skill 基础上做一些修改。下面是我使用的方式：

首先需要一个 Chrome 浏览器，并在上面登录你的 ChatGPT 账号。

两种对话保存方式

由于是在网页端模拟进行对话，因此我推荐下面两种对话的保存方式。一种是使用 Temporary Chat 模式，这样的话每次都会开一个临时的对话，优点是完全不干扰你的使用，阅后即焚，缺点是无法找回对话，也无法接着对话继续说。

另外一种是专门创建一个 Project 给 Agent 使用，也是我推荐的方式。在你的 ChatGPT 中创建一个独立的 Project 专门给它使用，把这个 Project 的链接（类似 https://chatgpt.com/g/id/project）告诉你的 Agent。这样既把 Agent 发起的提问集中起来，同时需要的时候也可以自己点开查看。

配置 config.json

接下来让 Agent 配置 ~/.oracle/config.json。下面是我的配置去掉了个人信息后的通用版，可以直接参考：

1
2
3
4
5
6
7
8
9
10
11

{
  "engine": "browser",
  "model": "gpt-5.6-sol",
  "browser": {
    "chromePath": "/path/to/oracle-chrome",
    "chatgptUrl": "https://chatgpt.com/g/<你的ProjectID>/project",
    "thinkingTime": "extra-high",
    "archiveConversations": "never",
    "hideWindow": true
  }
}

几个可选项的说明：

• chatgptUrl：如果是 Temporary Chat 模式，改成 https://chatgpt.com/?temporary-chat=true。
• chromePath：指向 wrapper，注入 --proxy-server=，适合需要通过代理访问的朋友。
• hideWindow: true：Oracle 启动 Chrome 后窗口自动隐藏，不干扰你的工作。
• archiveConversations: "never"：不归档对话，避免 Project 里堆积无关会话。

国内用户没有全局代理怎么办？

如果你的网络访问不了 ChatGPT（比如国内用户没有开全局代理），也不用放弃这套方案。思路是写一个 Chrome wrapper 脚本，让 Oracle 启动 Chrome 时自动注入本地代理。

我的 ~/.oracle/oracle-chrome 脚本大概做这几件事：先把 Oracle 传来的 --proxy-server 参数过滤掉（避免和我们要注入的重复），再在启动参数里自动加上 --proxy-server=http://127.0.0.1:7890，最后用 exec 拉起真正的 Chrome。

然后在 config.json 里把 chromePath 指向这个脚本，而不是 Chrome 本体：

1
2
3
4
5

{
  "browser": {
    "chromePath": "/Users/你的用户名/.oracle/oracle-chrome"
  }
}

这样 Oracle 每次拉起 Chrome 都会自动带上本地代理，ChatGPT 网页端就能正常访问了，无需手动开启全局代理。

接着让 Agent 在 Skill 里补充超时，我这边设置的是 20 分钟，对绝大多数任务应该够了。

最后可以让 Agent 实测一下是否 Work。可以的话就完美地接入你的工作流啦~

实测效果

下面是我的一个例子，我在 Oh My Pi 中使用 Deepseek V4 Flash 这样的廉价模型，实测可以让它求助外部的 GPT 5.6 Sol 大人，用时 5 分钟左右。

至此，我们实际上实现了外部高性能模型指导、廉价模型驱动的工作流闭环。搭建好 Skill 和 CLI 之后，完全不需要人类再当内容的搬运工。在 Agent 的时代，我们就是要用这样的思路来尽可能把人类的注意力资源从这类繁琐、重复的搬运工作中解放出来，转而投向其他更有价值的事情。

我为什么想做 SpotAsk

最近我开始在 macOS 上生活，顺手做了自己的第一款 macOS 桌面应用：SpotAsk。

起因很普通。我打开 ChatGPT，很多时候并不是要处理什么复杂任务。更多时候，只是想弄明白一个概念、翻译一段话、总结一篇长文，或者润色一下刚写好的回复。

但这么点小事，真正做完却要走过一整套流程：停下手里的事、打开浏览器、进入 AI 网站、等回答、再切回来。

一次两次无所谓。次数多了，我越来越觉得别扭——一个几秒钟就能问完的问题，硬是被工具流程拖得很重。

不是所有的问题，都需要打开 ChatGPT。

核心理念：让轻量提问真的轻

SpotAsk 是一个原生 macOS 菜单栏应用，平时就当它不存在。按默认快捷键 Option + Space，呼出一个专注的提问窗口。输入问题、看回答、需要时复制，再按 Esc 关掉。整个过程不离开手头的工作，关掉之后，就像它没出现过一样。

我想要的不是一个更大的 AI 工作台，而是一条更短的路：从「我有问题」到「我拿到答案、回到原任务」，中间别被打断。

这个理念也决定了另外几个设计选择：

1. 键盘优先：打开、提问、复制、关闭都可以靠快捷键完成，不必碰光标。
2. 界面克制：窗口只承担快速问答，不堆砌历史、工作区、协作这类重量级功能。
3. 本地优先：SpotAsk 用自带密钥（BYOK）模式。访问密钥存在这台 Mac 上，内容只发送给你配置的 AI 服务。
4. 保留边界：复杂任务仍然交给 ChatGPT、Codex 这类专门工具。SpotAsk 只处理那些高频、轻量、能快速结束的时刻。

两个主要使用场景

SpotAsk 目前围绕两个日常场景来做。

一个是快捷提问。按 Option + Space 打开窗口，输入问题后按 Return，回答实时显示。可以复制完整回答，也可以只复制某个代码块；想中途停掉，按 Esc 或点停止按钮就行。

另一个是划词处理。在 Safari、备忘录、邮件或其他 macOS 应用里选中一段文字，SpotAsk 会在选区旁边给出快捷操作。比如翻译、解释、总结、润色，或者跑一段自定义提示词。回答生成后，在支持写入的应用里可以直接把结果写回原选区；也可以复制到剪贴板，或者接着在对话窗口里追问。

另外还有一些让它在系统里更顺手的细节：自定义全局快捷键、内置多种提示词、粘贴截图或拖入文件作为上下文。它支持 8 种界面语言，也能通过 Spotlight、Siri 和快捷指令调用。

加这些不是为了让 SpotAsk 更像一个平台，只是想让常见动作再快一点。

设计边界：刻意不做成另一个 AI 工作台

做工具最难的，往往不是「加什么」，而是「忍住不加什么」。

SpotAsk 没打算做成面面俱到的 AI 工作台。它没有账号体系，不做云端同步，也不准备把完整工作区、多轮复杂推理和长上下文协作都塞进来。需要多步推理、反复调试、深度检索的活，我还是建议用专门的 AI 产品。

它的定位就这么窄：负责那些「小事却要打开大工具」的时刻。

为什么叫 SpotAsk

我用 macOS 的时间还不长。之前在 Windows 上，我很喜欢 Listary 这类工具——不用离开键盘，就能完成很多操作。换到 macOS 后，我自然先被 Spotlight 吸引，慢慢习惯了这种「按几个键就能办完一件事」的交互。

后来我试过用 Cherry Studio 来应付轻量问答，但它对我来说还是太重。我不想为了一个简单的功能，在系统里装一个庞然大物，也不想每次提问都被工作台里的其他概念打断。

SpotAsk 就是这么来的：做一个原生的、更轻的、更纯粹的 macOS 快捷问答工具。名字也取这个意思——像 Spotlight 那样快速找到想要的东西，又像 Ask 一样，让问题本身就是入口。

第一次做 macOS 桌面端工具

这是我第一次完整做一款 macOS 桌面应用。整个过程里，最大的体会不是技术有多难，而是产品边界比技术细节更难定。

早期我很容易被各种功能吸引，总觉得「别人有，我们也可以有」。可每加进来一个功能，主路径就长一点。后来我把标准压成了一句话：如果它不能让「问一个问题」这件事更短，就暂时不做。

所以 SpotAsk 现在是个功能朴素、但路径清楚的小工具。它从我自己的真实需求里长出来，也还有很多不成熟的地方。作为第一次做 macOS 桌面端的人，欢迎大家体验，也欢迎告诉我哪里好用、哪里别扭，以及你最希望它处理什么场景。

当前状态

SpotAsk 支持 macOS 15 或更高版本，兼容 Apple silicon 和 Intel Mac。官方发布版本使用 Apple Developer ID 签名并通过公证（不得不说苹果的开发者订阅好贵）。项目在 GitHub 上开源，使用 AGPL-3.0 许可证。

中文文档：https://shiquda.github.io/SpotAsk/zh-CN/

下载地址：https://github.com/shiquda/SpotAsk/releases

项目主页：https://github.com/shiquda/SpotAsk

如果你也经常遇到这种「小事却要打开大工具」的时刻，欢迎试试。任何使用感受、遇到的问题或改进建议，欢迎在 Github 的 Issue 中提出。

最近我在折腾一件小事：把自己散落在不同 Agent 里的 Skill 管起来。一开始我也觉得这事没那么重要，无非就是几个 SKILL.md，里面写一些说明、流程和工具调用方式。可用得多了以后，我越来越觉得，Skill 不应该只被当成「提示词文件」看，它更像是一种个人资产，尤其是私有 Skill。

公开 Skill 当然有价值。比如处理 PDF、读写表格、调用浏览器、做部署检查，这些都是很多人都会遇到的问题。社区把这些能力做成 Skill，大家拿来即用，这是生态的价值。

但我自己的判断是：真正更值得长期维护的，往往是私有 Skill。

原因也很简单。公开 Skill 解决的是「大家都会遇到的问题」，私有 Skill 解决的是「我反复遇到的问题」。前者是通用能力，后者是我的工作方式、判断标准和认知习惯。

换句话说，公开 Skill 更像工具箱里的通用工具，私有 Skill 更像我自己的工作流说明书。

这篇文章想分享的，就是我现在用的一套轻量方案：不用部署服务器，只用 Git 加本地 CLI。上行用我自己写的 skills-sync，把本地 Skill 同步到 Git 仓库。下行用成熟的 npx skills add，从 Git 仓库安装 Skill。中间用 Git 做版本管理和权限控制。这样一来，Skill 就可以跨设备、跨 Agent、跨项目流转。

不过先说清楚，这篇文章不是安装教程，我也不打算把具体命令展开得很细。进入 Agent 时代以后，我越来越倾向于把这类细节交给 Agent 自己研究。把仓库 URL 发给它，让它先读 README。必要时先安装仓库里的 Skill，再根据 Skill 的指导完成后续操作。人的注意力应该留给判断和验收，而不是记一堆命令参数。

什么是值得管理的私有 Skill？

我这里说的私有 Skill，不是指「不能公开的神秘能力」，而是指那些和个人、团队、项目强相关的能力模块。

它可以很小。比如：

1. 我做代码审查时关注哪些风险。
2. 我写文章时如何组织结构和语气。
3. 我发布博客前要跑哪些检查。
4. 我让 Agent 做完任务后，必须给出哪些验证证据。

它也可以更大。比如一套论文检索流程、一套团队项目交付规范、一套内容创作工作流，甚至是一套长期形成的研究方法。

这些东西有一个共同点：它们未必适合公开，也未必对所有人有用，但对我自己非常有用。因此，私有 Skill 本质上不是「写给模型的一段提示词」。它更像是把自己的经验和偏好，用一种 Agent 能理解、能调用的方式封装起来。

这也是我认为私有 Skill 比公开 Skill 更值得认真管理的原因。公开 Skill 用来补齐通用能力，私有 Skill 用来沉淀个人能力。前者让 Agent 更会做事，后者让 Agent 更像是在按照「我的方法」做事。

Skill 是模型之外的知识增量

现在底座模型变化很快，Agent 产品也变化很快。今天用 Claude Code，明天可能用 Codex，后天又换成 OpenClaw、Cursor 或 OpenCode。如果所有经验都只沉淀在某一个产品的对话里，其实很脆弱。产品一换、设备一换、上下文一清空，很多东西就没了。

Skill 的好处在于，它把一部分经验从具体模型和具体 Agent 里抽了出来。

一个好的 Skill 不需要写得很玄。它只要把适用场景、执行路径、可用工具和验收方式说清楚，Agent 就能在不同模型和产品之间复用这套流程。

从这个角度看，Skill 可以理解为一种「模型之外的知识增量」。底座模型提供通用智能，Skill 在这个智能之上，补充具体的领域知识、个人偏好和执行路径。

这一点很宝贵。

因为模型会越来越强，但模型不可能天然知道「我怎么做事」。它可以知道一般意义上的论文检索、代码审查、文章润色，但不知道我自己的判断标准。私有 Skill 正好补的是这一层。

真正麻烦的不是写 Skill，而是管理 Skill

当 Skill 只有两三个的时候，管理问题不明显。放在某个目录里，用的时候能找到就行。但只要你稍微重度使用 Agent，很快就会遇到几个问题。

第一个问题是分散。不同 Agent 有不同的 Skill 目录，Codex 有自己的全局目录，Claude Code 有自己的目录。OpenClaw、OpenCode、Cursor 也各有各的习惯。还有一些 Skill 是项目级的，只放在某个仓库里。

第二个问题是迁移。

换电脑的时候，你可能知道要同步代码、同步配置、同步 SSH Key，但未必记得自己有哪些 Skill 散落在各处。等真正用到的时候，才发现新机器上没有。

第三个问题是迭代。

比如我在本机改了一个 Skill，过几天又在 VPS 上用它。结果 VPS 上还是旧版本。到底哪个版本是新的？上次改了什么？有没有改坏？这些问题如果靠手动复制，很快就会乱。

第四个问题是共享。

如果是小团队，大家可能都有一些共同工作流。比如项目发布、文档检查、代码审查、日报整理。这个时候最麻烦的不是写一份说明，而是如何让每个人的 Agent 都能稳定拿到同一份说明，并且之后还能更新。

这些问题放在一起，其实就是一句话：

当 Skill 从几个零散文件，变成一套长期维护的能力库以后，它就应该像代码一样被版本管理。

这也是我最后选择 Git 的原因。

我的方案：Git 做仓库，CLI 做上下行

我的方案很简单：

上行用 skills-sync，下行用 npx skills add，中间用 Git 做 Skill 仓库。

这里的关键不是技术有多复杂，恰恰相反，关键是不要把事情做重。Skill 本质上就是一组文件。Git 已经解决了版本历史、分支、回滚、权限、协作这些问题。GitHub、GitLab 这类平台也已经解决了私有仓库访问控制。对于个人和小团队来说，如果 Git 加本地 CLI 已经能解决问题，就没有必要一开始就部署一个服务器。

这套方案的分工也比较清楚。skills-sync 负责上行，扫描本地各个 Agent 的 Skill 目录。它把你选中的 Skill 放进目标 Git 仓库，并提交推送。npx skills add 负责下行，从 Git 仓库里读取 Skill，然后安装到本机对应的 Agent 环境里。对于私有仓库，我的做法是直接复用本地 Git 认证，比如 SSH Key。

这样一来，Skill 的生命周期就比较完整了：

1. 在本地某个 Agent 里产生。
2. 通过 skills-sync 同步到 Git。
3. 在 Git 里获得版本历史。
4. 在其他设备上通过 npx skills add 安装。
5. 后续继续迭代，再同步，再更新。

skills-sync 解决的是上行问题

我写 skills-sync 的初衷，是因为我发现已有工具更多解决的是「安装 Skill」。但我还需要一个反方向的工具：把我本地已经写好的 Skill 收集起来，推到自己的仓库里。

它现在做的事情大致包括：

1. 扫描主流 Agent 的全局 Skill 目录和项目级 Skill 目录。
2. 展示当前发现了哪些 Skill。
3. 对比目标仓库里的版本，判断是新增、相同、修改还是无效。
4. 支持交互式选择，也支持非交互式同步。
5. 把选中的 Skill 复制到 Git 仓库的规范目录。
6. 写入同步 manifest，默认 commit 并 push。

但我不建议读者在这里死记具体命令。更符合 Agent 时代的用法，是把 skills-sync 的仓库地址直接发给你正在使用的 Agent。然后让它自己读 README。

比如可以这样说：

这是 skills-sync 的仓库：https://github.com/shiquda/skills-sync。

请你先阅读 README，理解它如何同步本地 Agent Skill 到 Git 仓库，并按照说明安装配套的 Skill，然后帮我检查当前环境，给出下一步同步方案。

这比自己手动查参数更节省注意力。因为真正需要人判断的，不是某个参数怎么写，而是我要同步哪些 Skill、同步到哪个仓库、哪些内容不应该上传。

我自己的本地环境里，skills-sync scan 能扫到多个来源的 Skill，比如 Codex、Claude Code、general。目标仓库配置成我自己的 Skill 仓库。

这里有一个细节我觉得挺重要：skills-sync 不试图替代 Git。它只是把 Skill 放进 Git 仓库，然后让 Git 继续做它擅长的事情。历史、回滚、审查、冲突处理，这些都交给 Git。这比重新做一套 Skill 平台要轻很多。

下行也可以交给 Agent

下行我没有重新造轮子，而是直接使用成熟的 npx skills add。它可以从一个 source 添加 Skill，也可以列出仓库里的 Skill。另外，它还可以指定安装某个 Skill、指定全局或项目级安装，以及指定目标 Agent。

但这部分同样不需要读者自己记命令。

更自然的方式是告诉 Agent：

这是我的私有 Skill 仓库地址。

请你先确认当前机器的 Git 认证是否能访问它。

然后使用 npx skills add 查看里面有哪些 Skill，再把我指定的 Skill 安装到当前 Agent 可用的位置。执行前先说明你准备做什么。

如果是团队私有仓库，只要本机 Git 认证配置好了，Agent 就可以通过 SSH URL 或其他 Git URL 访问。这样就不需要给 skills-sync 或安装流程额外设计一套账号系统。

这也是我喜欢这套方案的地方：它没有把问题复杂化。skills-sync 只管把本地资产上传到仓库，npx skills add 只管从仓库安装到本地。Git 负责中间的版本和权限，Agent 负责阅读说明、选择命令和执行流程。每一层都比较克制。

一个真实例子：找论文 Skill 从本机流转到 VPS

举一个我自己的例子：我有一个找论文的 Skill，最早是在本机 Claude Code 里用的。它不是简单告诉 Agent「帮我找几篇论文」，而是沉淀了我的检索习惯。比如优先看哪些来源、怎么判断相关性、怎么过滤质量不够的材料、最后按什么结构整理结果。

后来我希望 VPS 上的 OpenClaw 也能用这个 Skill。传统做法是手动找目录、复制文件、传到 VPS、再确认 OpenClaw 的 Skill 目录。能做，但很烦，而且后续更新还要再来一遍。现在就简单很多。我让本机 Claude Code 根据 skills-sync 的说明，把这个 Skill 上传到 Git 仓库。到了 VPS，再把仓库 URL 给 OpenClaw，让它读 README，并用 npx skills add 安装。

整个过程里，我不需要手动复制文件，也不需要自己查命令参数。我的动作更像是给 Agent 下达意图，然后让 Agent 根据 Skill 的指导自己完成同步。这件事让我更确定一件事：私有 Skill 的价值，不只是插件迁移，而是把自己的研究方法迁移到不同设备和 Agent 里。

这套方案适合谁？

这套方案并不适合所有人。如果你只偶尔用 Agent，也没有写自己的 Skill，那暂时不需要管这些，直接用公开 Skill 就够了。

它更适合下面几类人：

1. 同时使用多个 Agent。
2. 有多台设备，比如本机、笔记本、VPS。
3. 已经开始写自己的 Skill。
4. 想把工作流沉淀下来，但不想维护服务器。
5. 小团队希望共享一套 Agent 工作方式。

反过来，如果你需要很复杂的后台权限、审计、审批流程，或者希望所有东西都通过 GUI 管理，那这套方案可能太轻了。

它的定位很明确：给个人和小团队一个低成本的 Skill 资产管理方式。它不是一个完整平台，更像是一条打通的链路。

Skill 管理的本质，是个人能力的版本管理

回到最开始的问题：为什么要认真管理私有 Skill？我的理解是，Agent 时代有一类新资产正在出现：可执行的认知资产。

过去我们管理代码，因为代码是可执行资产。后来我们管理文档，因为文档是知识资产。现在，Skill 介于两者之间。它既有知识，也能指导 Agent 调用工具执行任务。这就让 Skill 变得很特殊。

一个好的私有 Skill，里面可能有你的写作风格、研究路径、工程习惯、审查标准、团队约定。它不是模型参数的一部分，但它能实实在在影响 Agent 的行为。换句话说，它是在底座模型之上，给你自己加了一层知识增量。

这层增量越稳定、越可复用，就越应该被版本管理。否则它只会散落在某次对话、某个目录、某台机器里，很难长期积累。

我现在越来越觉得，未来很多人的核心资产，可能不只是代码、文章、笔记，还包括一套不断迭代的私有 Skill。它们小到一个命令，大到一套方法论。它们以可插拔模块的方式存在，可以跨模型、跨 Agent、跨设备流转。这就是它有价值的地方。

从一个 Skill 仓库开始

如果你也想试，我建议不用一上来就整理全部 Skill。先挑三类最常用的：写作或内容处理、研究或搜索、工程或发布。

然后建一个私有 Git 仓库，把 skills-sync 的仓库 URL 和目标仓库 URL 一起给 Agent，让它先读 README，再给你一个执行计划。在另一台设备上，也把目标 Skill 仓库 URL 给 Agent。让它确认 Git 认证、阅读仓库结构，再用合适的方式安装指定 Skill。

只要这个闭环跑通，你就已经有了一个最小可用的私有 Skill 管理系统。重点不在于记住多少命令，而是把「研究命令、检查环境、执行同步」这些注意力开销交给 Agent。

最后也说一个边界：skills-sync 目前主要还是我个人在用，是从自己的真实工作流里长出来的轻量 CLI。所以它的用例覆盖肯定有限，很多问题只有放到更多人的环境里，才会暴露出来。

如果你对这个方向感兴趣，欢迎体验，也欢迎给仓库 Star。更欢迎提 issue 和 pr，或者直接说说你的使用场景和问题。我会很感谢，因为这类工具只有在更多真实用例里跑过，才知道哪些地方是真的有用，哪些地方只是我自己的习惯。

最后还是回到那句话：

Skill 的真正价值，不在于它看起来多复杂，而在于它能不能把你反复消耗注意力的工作，变成稳定、可复用、可迁移的能力。

参考资料

1. skills-sync 项目：https://github.com/shiquda/skills-sync
2. Vercel Labs skills CLI：https://github.com/vercel-labs/skills
3. Skills CLI 文档：https://www.skills.sh/docs/cli
4. Vercel Agent Skills 文档：https://vercel.com/docs/agent-resources/skills

本文共 5000+ 字，阅读时间需约 8 分钟。

为什么聊这个？

你可能以为我最近比较焦虑——但恰恰相反。焦虑，是我最近和朋友聊天时常常出现的话题，而我自认为在这方面做得还不错，焦虑感大概位于大众中位数以下（虽然这种估计并不科学）。我隐约意识到自己有一套模糊的策略，但从没有系统性地总结过这一现象。

今天晚上忙完之后，突然想和 AI 聊一聊这个话题。也大概两周多没有和读者见面了，干脆把今晚的思维路径以及收获整理成文，一方面加以深化与整理，另一方面希望对读者能有所启发。欢迎你和我一起漫游。如果你对我的思考迭代路径不感兴趣，可以直接跳到「一个公式」及以后的总结环节。

PS：AI 在这方面确实算是非常有启发性的深度对话伙伴了，之前虽然有所耳闻，但还没有多少深入实践。本次使用的是 Claude 平台，对话轮次 62 轮，体验还是非常惊艳的，通过提示词让它用类似苏格拉底式地问答，一轮轮来发现现有认识中可能存在的偏差，最终使得我对这个话题的认知层次明显进了一个台阶。如果读者还没尝试过的，不妨也找个话题和 AI 深度聊一聊，可能会有意想不到的收获。

从经验中来，对焦虑的模糊认识

此前，我对焦虑的认识，主要来自零散的信息输入和自身经历，大致罗列如下：

1. 焦虑的本质是一种对未来不确定性的担忧。如果一件事已经坐实了，那么就不会感到焦虑；
2. 有时候，人对一件事情感到焦虑，是因为对这件事情本身的认识和规划并不完善，即「不够具体」，如果实际动手去做，那么反而就不会那么焦虑了；
3. 如果是那些自己几乎无法施加任何影响的事情，（如希望尽可能掷骰子掷出「6」），虽然结果是完全不确定的，但却不会感到焦虑，因为自己知道无论如何努力都无法改变结果（至少我不行~）；
4. 最让人焦虑的，往往有这样一个特点：虽然结果不确定，但自己又觉得通过努力可以影响结果的走向。也就是说，焦虑的核心在于「我觉得我有能力去影响一个不确定的结果」。

基于上述几点认识，我开始了和 Claude 的 苏格拉底式 的对话。

第一个裂缝：不确定性真的是第一因吗？

Claude 举了一个挑战这一命题的例子：

假如一个人进了体制内，工作非常稳定，未来的 20 年可能一眼能望得到头，但他认为这种确定性换取的结果是个人上界的下降。在这种情况下，这种「一眼望得到头」的确定性，反而可能让他感到焦虑，感觉自己一辈子也就这样了。

PS：仅转述 AI 的举例，不代表作者观点。

这确实和「焦虑源于对未来不确定性的担忧」这一观点相矛盾，而且和大众的直觉相冲突。为什么在这个场景下，这种确定性也会造成焦虑呢？

进一步思考，我发现，从逻辑上无法推导出焦虑和不确定性有哪些直接的关联。从概念上来说，焦虑是人的一种心理状态，而不确定性仅仅是有可能成为唤醒人的这种心理状态的原因之一。

回顾成长经历，那些令我焦虑的状态，大多都与第四点相关：我觉得自己能改变某些现状或预期。

举例来说，如果你在准备某些考试，一方面你想获得比较好的成绩，但另一方面，人的惰性或者是其他因素可能让你不那么愿意花很多精力去准备这场考试。这时候你可能就会有这样的心理压力：

如果我准备得不够充分，考砸了，那怎么办？

这种心理压力可以被总结为：针对一个目标，不够努力可能会导致结果不满意，而我「本可以」更努力，这样结果或许就会好一些。

这里有一个前提是，事情的最终结果至少在人们看来，是能够被自己的更多投入所影响的，并且往更好的方向走。

「不可避免」还是「本可避免」？

Claude 就此提出了一个挑战我目前框架的问题。在学术界中，Barlow 的焦虑理论认为，对未来威胁的不可控制感与不可预测感是焦虑的核心心理机制，但前面的认识中，人恰恰是在「可以施加影响」的情况下才会产生焦虑，这两者是否冲突呢？

David H. Barlow：波士顿大学心理学荣休教授，临床焦虑领域权威学者，提出焦虑的「三重脆弱性模型」，认为早期经历所形成的「不可控制/不可预测」图式是焦虑障碍的心理核心。代表作为 2000 年发表于 American Psychologist 的《Unraveling the Mysteries of Anxiety and Its Disorders》。

在我看来其实是不冲突的，因为「不可避免」意味着这个问题是人必须做出正面决策的，即我要花多少的努力去完成某件事情。而我对这件事情的努力程度分配，只有在努力能影响最终的结果走向的前提下，焦虑才会产生。

举一个极端的例子：中国有个典故叫做杞人忧天，大家都清楚是什么含义。对于那些完全超出个人影响力范围的事，我们并不会真正焦虑。既然结果根本不受努力程度的影响，增加或减少投入的意义便消失了，焦虑也就无从产生。

「躺平」是否是最优解？

Claude 又抛出一个问题：如果一个人主动放弃对未来行动力的选择权，直接躺平，这是否是一种正确的方式？

按照我们前面得出的结论，如果从逻辑上来说，一个人主动把未来选择权给放弃了，那么他就似乎真的不会再焦虑了，因为如果没有选择权的话，结果不再受自己的行为所左右，焦虑也没有意义。

焦虑的消除与清零，并不是最终目的——至少对我来说不是。

换句话说，焦虑最小化只是手段，不是目标。真正的目标是推进那些我认为有价值的事情，而那些事情，恰恰往往需要我承担一定程度的心理张力。一味追求焦虑清零，反而可能让我系统性地回避那些真正值得去做的事。

而对我来说，目前并没有一个什么至高无上的目的。那些我关注的事情，对我来说都有不同维度上的价值，并不能用一个唯一的指标，来绝对地衡量它们之间哪个最重要。

我在意

如果一个人对一件事情感到焦虑，必定有一个前提：他在意这件事情本身。

这很好理解，比如我们可能不会在意，无意之间被我们踩死的一只蚂蚁，哪怕这件事情对它来说是灭顶之灾，但对我们来说，可能甚至没有意识到它的存在，在这种情况下就没有焦虑一说了。

且感性上来说，如果一件事情你在意的程度越高，那么你对它的焦虑就会随之被放大。

焦虑虽然无法量化，但或许可用公式来方便理解各影响因素。公式左边是焦虑程度，而右边已有一个现成的乘算因子：我们对这件事的在意程度。那么还有哪些？除了「不够努力导致结果变差」的担忧，还有吗？

投入程度对心理压力的 U 型影响

在 Claude 的引导下，我想到另一种焦虑：如果为这件事加倍努力，结果却是坏的，我能接受吗？

过去的成长经历中，大多数时候我都不能接受这种沉没成本的代价，它带来的焦虑甚至比「不够努力」造成的还要更深。

因此我们就可以画这么一个曲线图了。以努力程度为横轴、心理压力（焦虑程度）为纵轴，会得到一条 U 型曲线：两端（完全不投入，或拼尽全力）的焦虑都高，中间适度投入时心理成本最低。这背后的逻辑需要从两个端点来看。我们在意的事情，往往无法完全由个人努力掌控结果。

如果我完全不努力，那么它最终结果的期望就会很低。在这种情况下，我得面对未来结果可能不如意的心理压力。

另外一个极端是：如果我全力以赴地做这件事情，那么在最后如果我仍然失败了，我将承受感性上的沉没成本带来的压力，以及理性上的机会成本带来的损失。因为我「本可以」把这用于努力的注意力资源分配到其他可能也有意义的方向上。

因此，分配适中的注意力，既不会因完全不努力而担心结果，也不会因全力以赴而承担沉没成本的焦虑——纯从缓解焦虑的角度，这是最优解。

人关注的不可能只是单一一件事情。实际上，我们可能需要在多种这样的事情中进行权衡，合理分配自己的注意力资源在不同事情上。

从理性上来说，假如我们真的可以量化我们对每件事情的在意程度的话，那么从降低焦虑的角度出发，较优的一种决策是：根据我们对每件事情的在意程度，从高到低地优先让越在意的事情越用适中的分配程度来做，既不是完全不做，又不是全力以赴。

PS：注意，这里是从缓解焦虑的角度出发。最小化焦虑程度可能并不是我们的唯一追求。

一个公式

因此，我们总结的具体公式如下：在结果未定的前提下，且仍有可分配注意力资源时，有：

焦虑 = 我在乎 × （「本可以」 + 「沉没成本」）

其中：

• 我在乎：我对这件事情的在意程度
• 「本可以」：在欠投入注意力资源的情况下，需要承担结果不如意的后果
• 「沉没成本」：在全力以赴地投入的情况下，投入的努力可能白费

可能你在潜意识中已经应用了这个公式

上面这个公式可以帮助我们主动缓解焦虑。但事实上，我们在过去的决策过程中，很可能在潜意识中已经运用了上述公式，自然选择了一个对我们心理成本最低的方式来做事情。

让我们回到前面的问题：心理成本最低，就是我们希望看到的吗？

我问了问我自己。对我来说，并不是。

就我自己而言，在过去的很多次决策中，或许过度高估了张力 B（心理上的沉没成本）的影响，甚至导致我直接否决是否要做某件事情，或是做了一半中途而废。

而这仅仅是因为：我怕努力了也会失败，还不如把注意放在其他 xxx 事情上。

这在很大程度上，限制了我对更丰富维度与领域的探索，让我停留在自己的「舒适圈」中。

这给我敲响了一个警钟：焦虑带来的心理成本上升仅仅是短期的影响。短期来看心理负担最轻的选择，长期来看，并不一定是自己最期望看到的。心理成本上最优的决策，在产出效应维度来看，可能系统性地低于最优投入，同时系统性地削弱我们把事情做好的概率。

缓解短期焦虑和追求长期进步，可以既要又要吗？

按照焦虑最小化的逻辑，我们似乎必然会系统性地减少注意力的分配；而如果增加对在意事情的注意力分配，那么似乎又必然引起焦虑。

这二者难道不能「既要又要」吗？能不能既给自己更在意的事情分配较高程度的注意力资源，同时又缓解由此带来的（主要是「沉没成本」）焦虑呢？

Claude 问了问我：你最早为什么认为自己没感觉有多么焦虑？

我给他讲述了最近的一些事情。他的理解是这样的：

我之所以焦虑感相对较低，并不是因为我回避了那些符合公式条件的处境——事实上，那些处境是真实存在的。而是因为在过去的决策中，我有一种相对自然的倾向：倾向于选择那些可以同时推进多个「在意」的方向，而不是把注意力资源孤注一掷地押在单一的外部结果上。

这种做法在客观上降低了「沉没成本」这个心理张力——因为即便最高层级的目标没有达成，过程中积累的东西，仍然对其他我在意的方向有所推进。换句话说，「失败」这个状态被稀释了：它不再是「一切白费」，而只是「最高目标暂时没有达到」。

但我也意识到，这种倾向在过去是隐性的、无意识的。今晚，它才第一次被显性地命名。

问题的要害在于：「在意」的话语权归属。

如果你「在意」的东西，很大程度上是需要得到外界的认可的，如升学考试、职称晋升等，那么往往这些东西就真的是原子化的、各自为战的，你必须把自己有限的注意力资源分配到这些上面，并承担自己欠努力带来的「本可以」+「沉没成本」的双重心理压力。

而如果你「在意」的东西，有相当一部分是只需要得到你自己认可的，那么可操作空间就大了很多。事实上，很多你在意的事情，并不是具体的一件事。例如健康状况、爱好活动等，这种由自己创设的在意，可以和具体的事情所绑定，甚至可以做到，在一件具体的事情中，同时实现多个目的。例如你爱好打羽毛球，在此过程中，你可以既满足兴趣爱好，也提升你的健康状况。

实际情况中，往往是二者兼具：一个人既有从外部标准（无法自己完全把控）中获取到的「在意」，也有一定从自我内部出发的「在意」。当我们考虑如何分配注意力资源时，可以把外在的「在意」，尝试从中挖掘内在的「在意」，将二者结合起来，并优先给那些结合了多重「在意」的事情分配更多的注意力资源。

这样可以实现「沉没成本」/「机会成本」的均摊。如果我们把模型简化，把一个个事情当作原子化来考虑，即一件事情只有成功和不成功两个可能的状态，那么这种做法的优化之处在于，它把一个 0-1 分布转换成了一个多层收益矩阵，「完全失败」的概率空间被大幅压缩了。哪怕最高层级在结果上没有真正达到，你在过程中做的努力，也对同时推进的其他你在意的部分有所帮助。

假如你是一个羽毛球爱好者，报名了一个将在 2 个月后举行的羽毛球比赛。如果你只是想着把比赛获得好成绩当作唯一在意之事，那么焦虑的压力可能会让你最终选择一个心理成本最低而注意力分配欠佳的策略。如果同时，你结合内在的在意，即对羽毛球运动本身的爱好、对身体健康的追求，那么在这过程中，哪怕你最终没有如愿获得好成绩，训练中获得的愉悦和健康状况的改善，也「不亏」：那些「沉没成本」不再沉默了。

按照这个思路出发，我们有两种优化方式。其一较为简单，是可立即生效的：探寻自己目前在做的外在在意中，有哪些潜在的内在在意，由此可直接缓解心理压力，或用更高的注意力分配来推进这个在意的事情集群。其二是未来在做外在在意的具体选择时，优先选取那些可以结合内在在意的事项，尽可能多地和内在在意沾边，这其实也在潜移默化地帮助我们成为自己真正想成为的那个我。

所以，缓解短期焦虑和追求长期进步，可以既要又要吗？虽然无法做到二者同时达到理论最优值，但可以大大优化。

解答未被解答的问题

回顾我最早和 Claude 的四个出发点，看看用我们迭代后的认知框架，如何解构这四个问题。

第一点，「焦虑是对未来不确定性的担忧」，我们说明了实际上核心之处不是不确定性，而是「未定」：对自己在意的事情，在未来仍可以通过改变自己的努力程度/注意力分配程度来一定程度上影响走向，这是整个公式成立的基础，而非自变量。

第二点，「不够具体」是焦虑的诱因，这一点我们前面还没涉及到，这里展开分析一下。如果一件事情不够具体，那么前面的「本可以」和「沉没成本」同时被放大了。

「本可以」方面，你知道自己的努力可以影响结果，但不知道如何开始做。你有选择分配注意力的自由，但这种自由无法被转换为行动，这种状态反而比放弃自由（例如选择「躺平」）更加让人焦虑。

「沉没成本」方面，正因为不知道如何开始，任何投入都可能方向错误，沉没成本的恐惧被放大了。

动手，本质上是在强制启动具体化的过程，让框架重新回到可操作的状态。当你真正动手去做，发生的事情是：模糊的大问题被分解成了一系列具体的小问题，每一个小问题都有相对清晰的行动路径，相当于把一个巨大的单一不确定性，拆解成了多个较小的、可以逐步处理的不确定性。由此可将简单的 0-1 分布转换成一个多层收益矩阵，均摊了「沉没成本」。

第三点，如果是那些自己几乎无法施加任何影响的事情，（如希望尽可能掷骰子掷出「6」），虽然结果是完全不确定的，但却不会感到焦虑。

这个维度看似满足结果未定的前置条件和我在意，但两个张力都同时消失了，「本可以」无从谈起，「沉没成本」也不存在，因为你根本不会去向这件事上增加或减少注意力资源的分配。

第四点，焦虑的核心在于「我觉得我有能力去影响一个不确定的结果」，显然，我们的公式可以完美解释这一点。正是因为相信自己能影响结果，「本可以」这个张力才得以成立。如果连影响结果的可能性都不存在，又从何谈起「本可以更努力」呢？

那应该怎么做呢？

我之前的思考，总是容易停留在脑子里，没有落实在实践中，因此现在每次我有比较深入的思考，必须强制自己列一个可执行的清单，问问自己：「既然如此，那我应该怎么做呢？」

写到这里初稿已经超过 5000 字了，用时超过两小时半。下面偷了个懒，让 Claude 帮我整理了一下：

立即可做：

1. 盘点当前正在推进的「外在在意」，逐一问自己：这件事里，有没有我内在真正感兴趣的部分？把它显性地写出来，让它不再只是隐性存在。
2. 觉察自己是否因为预期沉没成本而提前放弃。当下次发现自己在说「算了，万一失败了也是白费」，停下来问：这是真实的理性判断，还是在用张力 B 给自己找退路？
3. 对不够具体的事，强制迈出第一步。模糊感本身会放大两个张力，动手是唯一的解药，不需要想清楚再开始。

做新决策时：

1. 优先选取能同时推进多个内在在意的方向。同一份注意力能服务于越多自己真正在乎的事，沉没成本的心理压力就越低，行动的阻力也越小。
2. 区分「在乎的是结果」还是「在乎的是过程本身」。前者让你更容易被张力 A 和 B 控制（作者注：「本可以」和「沉没成本」）；后者让你在结果未定时仍然有稳定的行动锚点。

写得还不错，希望对我们能有所启发。

这期播客虽然已经播出一段时间了，但我自己听完还是很有感触，前后分了两天听完，又拖了一天整理。这也是我第一次认真写播客听后感。之前我虽然是重度播客听众，但很少专门写这类文章，主要是因为很多播客内容偏散，通常只值得在 Notion 里随手记几条零碎想法。这一期不一样：里面有不少观点，确实让我想停下来单独记一篇。

注：本文不等于播客内容的完整总结，如果您有需求，AI 做得比我好多了。如若也对这期内容感兴趣，推荐直接收听原播客。本文仅记录一些笔者在收听过程中真正“触动”了我的观点，并在此基础上补充一些个人思考。尽管我会尽量加以区分，但部分转述可能无意中融合了个人的一些思考，请读者以原播客内容为准。

特别有感触的观点用“💡”注明。

个人思考部分，会以这种批注的方式呈现，加以区分。

1. “取景框”

嘉宾认为，每个人看待世界有不同的视角，称作取景框。这种取景框，实际上是世界这个多维事物在某些维度上的投影。也就是说，在特定的语境下，或者说特定的上下文中，取景框里显示的内容和其认知是符合的。但是问题是每个人的取景框检测的维度是不一样的。因此，一个人应该承认自己取景框的局限性，积极借鉴他人的取景框，才能对世界有更全面的认知。

注意，这里要区分我和我的取景框这两个概念。我的取景框是一个相对静态的概念，它代表了我在某一成长阶段看待世界的方式。而我是一个动态概念，会随着成长历程不断迭代。

2. 财富占比投资观

我们投资追求的并不是绝对数额上赚了多少钱，本质上应该换一个更有启发性的思路来投资。也就是说，我们的目标应该是尽可能增大自己的个人财富在整个世界总财富中的占比，或者退而求其次，至少不让这个占比下降。而从这个思路出发，我们只需要把资金配置在那些未来会变得越来越主流、体量越来越大的资产上。这是一个宏观长期的总体目标。

如果说手上全是现金，或者是全放余额宝，这样的话，其实至少目前来看，现金是会贬值的。因此这种方式并不能达到前面的目的。

💡3. 知识获取的时空维度压缩

纵观人类的读书或者说学习这个过程，最早的话是看书，就是纸质的书。我们可以从空间和时间两个维度上来分析。如果是读书的话，就是传统的读书，它可能是需要占有一定的空间和时间。空间就是说书有物理体积，时间的话是说你需要阅读和理解思考的时间。然后你才可以把这些知识真正掌握。到了互联网时代，很多东西都电子化了，物理空间消失了，转换成了数字空间。但时间维度仍然存在。

比如说你看电子书，你仍然需要自己去理解，去消化，才能掌握一些里面的精髓知识。但是到现在，如果 AI 出现的话，实际上是把最后一个时间维度也给压缩掉了。也就是说，你以前想要看完一本书，反复咀嚼才能获得知识，你可能现在一问大模型就有，或者说让它帮你总结。这一步节省了时间。至此，时间和空间两个维度上，知识的门槛已经大大降低了。

再比如说之前中国和美国是有空间距离的。但是后面上网之后，两边就可以很大程度上逾越空间的现实差异，然后进行更多更密切的交流、沟通。

4. AI 是更好的对话者

和 AI 聊天的深度，能比和人聊天更深。AI 学习了人类知识的很大一部分，LLM 融合了海量的知识和智慧，不是单个人可以比拟的。因此，应该多和 AI 交流自己的思想。

5. AI 时代的职业意义

很多职业在未来遇到 AI 后面临的问题，相当于国际象棋或围棋的专业棋手在遇到人工智能这座无法逾越的高山时，下棋竞技的意义何在。

这个类比非常有意思。

💡6. AI 时代如何读书

关于读书这个话题，在 AI 时代，我们应该如何读书呢？人类的注意力资源（或者说算力，用 Agent 的概念来说）是有限的，传统的方式就是人直接用自己的算力去阅读、理解和整理书籍里的知识。如果从学习作者提供的知识来看，具体从书中如何获得作者想要提供的知识并不重要，哪种方式更容易、更省时间就怎么做。因此利用 AI 来阅读、快速整理自己感兴趣的部分是没有问题的。那读书的意义在哪里呢？在现在，亲自读书更大的意义在于，你在阅读的时候会触发思考，对自己进行启发，提供灵感。

其实写作也是如此。如果追求流量、效率、变现的话，那么让 Agent 完全接管写作，无疑是最“好”的选择，我相信已经有很多人这么做了。因为对我来说，写作最大的意义不是结果本身，而是在过程中把一些原本不会想得那么深入的问题想清楚，并在写作中获得新的启发和灵感。在这点上其实我是比较自私的，因为文章的产出，对读者的价值，在我这里其实并不是最主要的，反而是我自己在写作过程中获得的启发和灵感，对我来说才是最大的价值。当然，我也会尽可能在和 Agent 的协作中，渐渐地提高我的写作水平。

💡7. 驱动 AI，而不是被 AI 驱动

和 AI 聊天，深度能比和人聊天更深。

一个例子是，老板让你做 xxx，你根本不思考，直接让 AI 做，做了个还凑合的交给老板。在这个过程中，是老板<->你<->AI，你实际上成为了 AI 的传话筒，成为了 AI 的工具。另一种方式是，你对老板给你的任务有一些自己的 idea，然后让 AI 帮你为这个 idea 进行反思、添砖加瓦或是快速实现，这种其实仍然是老板<->你，但是你利用 AI 这个东西，一方面做得更快了，另一方面，你本身在和 AI 的交流过程中，对任务有了新的认识和思考，你在进化，你的取景框更加丰富，对事情的思考更加深入。

这里其实引起了一个我许久之前没想通的问题，即关于我们在日常生活中的一些事情，如果交给 Agent 做，会不会让我们的能力“退化”？我目前的观点是，应该一分为二地看待这件事情。如果是那些“非核心”的能力（注意，这里的核心具有相对性，因人而异），比如对我来说有 Excel 的操作、具体代码技术细节的编写、错别字纠正等，那么完全交给 Agent 做即可。而对那些你在意的“核心”类型的，我认为应该采用一种与 Agent 协作的方式，让它和你对这个问题共同讨论、共同进步。这背后的原因很简单，因为不管做什么都是需要注意力资源的，而人的注意力资源是有限的。把不那么核心的任务或你对其背后能力不感兴趣的注意力，更多放在那些真正重要的上，自然就是更好的一种选择了。

那么我们具体如何判断，什么样的能力才是符合自己需求的那种“核心”能力呢？这个问题我也没有很好的答案，我提供几个问题，供读者参考。一是问“没有了这种能力，我的竞争力会怎么样？”，比如说前面的 Excel 操作，我以后不会成为一个需要靠 Excel 操作为业的，那么这个能力对我就无关紧要（更不用说以后这种可能就完全被 Agent 取代了，甚至可能有更加适合 Agent 之间数据流转的标准出来）。二是问“是否有复利效应”。如果有很多可选的同等重要的能力，那么在注意力有限的前提下，优先选择有复利效应的那些，比如人的认知、思维方式、审美、学习能力等，而不是那些线性的具有重复性特征的，如代码编写能力这种“手艺”。

8. 心力 vs 脑力

嘉宾比较激进地认为，在未来，AI 和人的分工将会非常极端。用嘉宾的话来说，人负责提供心力，Agent 负责提供脑力，实现心力和脑力的解耦，但二者又可以紧密联系。前几次工业革命，人把一部分体力工作让渡给机器，总体上来说，人更多负责使用智力来为社会提供价值。在本次新的革命中，人可能还得把脑力让渡给 LLM。那人还剩下什么呢？也就是所谓心力了，即人类最本源、最内在、最本质的驱动力。

演进路径： 早期人类把体力交给机器 → 进入脑力时代；现在脑力交给 AI → 进入心力时代。

💡9. Agent 时代的长尾商业逻辑

Agent 时代，底层的商业逻辑是长尾。互联网时代的底层逻辑是马太效应（赢家通吃、头部集中），Agent 时代的底层逻辑变成了长尾效应（无限细分、每个人都被完美服务）。

长尾效应：由 Chris Anderson 在 2004 年提出，指大量低需求的小众产品累积起来的总市场份额，可以与甚至超过少数热门产品。核心是「销售更多更少」（selling less of more）。

以前互联网虽然也在讲个性化，但本质上仍然是平台基于规模效应做出来的「千人千面」：它能把人分群，用同一产品疯狂扩张，拉低边际成本曲线，但对于具体化、个性化的需求来说，却很难真的服务到每一个具体的人。现在 AI 更像是「一人一面」，有一个随时在线、拥有全人类很大一部分知识的 Agent 为每一个人服务，可以做到极致的个性化。也正因为如此，Agent 时代的长尾才成立：以前很多过于细小、服务成本过高的需求不值得被满足，现在却可能被低成本、持续地满足。于是长尾变成主战场：每一条长尾都能被完美服务，累加起来就是巨大价值。以前你得靠规模（用户多、流量大）才能活；现在你只要把一口井打得足够深（对一小群人极致理解），就能活得很好，甚至一个人 + 一堆 Agent 就能撑起一家公司。

10. 三次工业革命

嘉宾把工业革命以来分成三个阶段：

1. 移动原子 - 蒸汽机、火车、汽车、飞机
2. 移动信息 - 互联网、移动互联网
3. 移动智能 - AI、Agent

每个阶段都带来自动化和效率的数量级提升。

💡11. 链与环

讨论大模型知识来源时，嘉宾提出两个相对概念：

• 环：头尾相接，自成体系的思考方式/范式，关键特征是可复用
• 链：不连接，临时的论据，射出去就没了

举例：金字塔原理（Pyramid Principle）是由麦肯锡前顾问芭芭拉·明托（Barbara Minto）提出的思考与表达框架，她在 20 世纪 60 年代于麦肯锡工作期间发展了这一方法，并在 20 世纪 80 年代正式出版成书。核心是把所有想法组织成金字塔形状。运用金字塔原理，其实就是实现了环的复用。

Prompt 是人与 Agent 之间进行交互的媒介。传统的 prompt 本质上是一种一次性的链，用完即抛。和 LLM 对话中的成长，必须经由人的大脑来处理，或者人将所思主动记录，这样其实是受限于人的注意力的。但嘉宾提出了另一种思路，可以让 Agent 来辅助处理这个过程，相当于把人脑处理成环的这部分注意力解放一部分。通过设置 Soul 和 memory 文件的方式，让 AI 自动查找潜在的关联，或者实现记忆文件的迭代，实现人与 Agent 的认知共建。这个思路很有意思。

受李继刚老师启发，我想到也可以把自己的认识给他落盘，形成一个具有层级的知识库，让 Agent 帮我在和我不断交流的过程中，一起迭代我的认知。这当然不是放弃思考，把脑子交给 Agent，我希望做的是和 Agent 的双向交流，既有我的特色，又能参考一些 Agent 的意见。另外，由于人的注意力资源是极其有限的，而 Agent 的智力在我们看来可近似于无限，那么靠 Agent 来给我们在后台进行思考、总结，并提出一些潜在的知识的跨领域迁移或是思考中潜在的不足，可以让我们在这个过程中节省大量注意力资源。我目前准备研究一套这样的与 Agent 对接的个人认知管理系统，希望不久以后就可以和读者见面。

12. 在阅读材料上运用杠铃法则

嘉宾提出了一种将「杠铃法则」运用于阅读材料选取的思路。嘉宾说现在基本只选取两种书目来读，一种是经典，经过实践沉淀；一种是前沿优秀论文。思路值得借鉴。

13. 对于规律本身的态度

我其实是一个比较喜欢总结和抽象的人，看到某些现象，总想着把这些现象背后，会不会有一些更加本质的、可泛化的一些规律，提出一些假设，并且看看这种假设，在其他外延上是否成立。嘉宾也是如此，他提到说，如果自己找到一个更加深一层、更本质的规律，那么就可以直接把原来的规律抛掉。逐渐这么迭代，人对世间事物的理解就会更加深入。

14. 健脑房：脑力替代后的补偿机制

嘉宾用了一个很有意思的类比：工业革命后，体力劳动被机器替代，人需要通过健身房、康复训练来补偿身体使用不足；如果 AI 大量替代脑力劳动，未来也可能出现某种「健脑房」，用于恢复或训练人的脑力。

这里的脑力，更接近计算、逻辑、分析、推演这些能力，而不是前面说的心力。这个类比最有意思的地方在于，它把一个常见的乐观叙事反过来问了一遍：如果 AI 真把脑力活都接过去了，人会不会像长期不运动导致肌肉萎缩一样，出现某种「脑力萎缩」？

15. AI 的终极变量：意识

未来 AI 是会摧毁人类，还是说为了人类的福祉而工作？嘉宾认为，最关键的一个变量就是，AI 究竟到未来会不会拥有意识。

如果 AI 没有意识，那它再强，本质上也仍然是工具；如果 AI 拥有意识，那它就可能具有自己的目标，人类与 AI 的关系也会发生根本变化。

这一点之所以重要，是因为它已经不只是技术问题，而是哲学和伦理问题。比如，什么叫意识？自我意识、主观体验、意向性分别算不算？以及，LLM 现在的一些涌现现象，到底只是复杂系统表现，还是某种更深东西的前兆？这些问题短期无解，但确实决定了很多终局判断。

💡16. Agent 时代的组织管理重构

嘉宾认为，传统人类管理体系在 Agent 时代可能会变成累赘。

过去层级式管理很大程度上是为了上传下达、维持组织运转效率；但如果 Agent 可以直接接收目标并执行，那么很多中间层的传递职能就会被削弱，组织可能进一步扁平化，甚至出现某种接近无层级的形态。

同时，传统激励机制也会失效。管理人需要奖金、晋升、认可等激励，但没有意识的 Agent 不需要被激励，它只需要明确的目标、约束和接口。

这意味着未来管理的重点，可能会从「如何驱动人」，转向「如何定义目标函数和边界条件」。人的角色也会从执行者进一步转向定义者和监督者。这个视角挺狠的，因为它实际上是在讨论整个组织学的前提会不会被改写。

17. 审美即权重

嘉宾提出一个说法：审美本质上是一种「权重」。

也就是说，审美不是简单地觉得某个东西好看，而是在面对多个维度、多个选项时，能够对不同因素进行权衡、排序和取舍。

这么说，审美其实更像一种长期实践之后形成的判断结构。你在一个领域做得越久，越知道什么是好的、什么是更好的、什么是最好的。

到了 AI 时代，这种能力反而更重要。因为 AI 可以生成无限选项，但最后哪个更值得选、哪个更符合目标，仍然取决于人的判断。

💡18. 少即是多：Agent 时代的注意力管理

嘉宾这里强调的是，Agent 时代真正稀缺的不是信息，而是注意力。

因此，思维方式要从「多一个没什么坏处」的加法思维，转向「为什么不减少一个」的减法思维。因为信息一旦过载，人往往只能浅层浏览，反而失去深度理解和思考的能力。

所以，比起不断增加信息源，更重要的是主动减少输入，只保留真正优质、值得长期关注的来源。

这点真是给我很多启发了，我之前认识到人的注意力资源是最宝贵的，但是却没意识到，现在很多信息源总是抱着“多一个没坏处”的出发点去无脑添加，结果到最后就是啥都看不进去，而那些真正高质量的信息源，却被当作平庸的信息源一样处理了。精选每天摄入的信息源，才可以达到效益最大化。听完我深受启发，马上把各平台的信息源进行了整理，发现自己无意之间竟然订阅了许多可有可无的信息源🤣

后记

最后回看这篇笔记，我真正想带走的其实不是某一个漂亮概念，而是几条更具体的提醒：

1. 尽量扩展自己的取景框，但也承认它的局限
2. 尽量借助 AI，但不要把自己活成 AI 的传话筒
3. 尽量减少无效输入，把注意力留给那些真正重要、且能持续产生复利的东西。
4. 借助 AI，和自己在元认知上协同进化

如果说这期播客最后让我更确定了一点什么，那大概就是：**AI 时代，人更需要认真决定，自己到底要把注意力放在什么地方**。

“只要重复 3 次的，就给它自动化。”这句话可能有点夸张，但是背后的思路值得借鉴。当我们和 Agent 进行交流的过程中，经常会发现有一些需求会反复出现。此时如果把这些需求进行标准化，通过一些简短的命令来引用大段的提示词描述，既能让 Agent 很清楚地理解我们的需求，又能让我们自己在表达的时候，减少许多不必要的认知负担和操作步骤。道理很简单，如果一件事情在未来会需要我们反复去做的话，那么对完成这件事的效率提升，未来每执行一次，对我们来说都是一笔可观的注意力收益。

本文就来分享一些个人使用下来比较实用的自定义 Slash Command。提示词写的一定不是最好的，但希望思路对你有所启发。同时，这篇文章并不介绍具体实现格式和编写的技术细节，因为本篇文章的受众，应该都有方法来询问 AI 来解决。

什么是 Slash Command？

Slash Command（斜杠命令）是一种简化用户与系统交互的方式，用户通过输入特定的命令（通常以斜杠开头）来触发预定义的操作或功能。用过 Claude Code 等 Coding Agent 用于开发的读者一定比较熟悉。

Slash Command 思路分享

下面分享一些我从实践中总结出来的，那些对我比较有用的自定义 Slash Command，供读者参考。再次强调，本文不分享在工程实践中，简单通过把提示词进行封装，来实现的功能性的命令，如一键测试、提交等。这些对一个合格的 Agent 交互者来说，都是基本功，应该有意识把常用的提示词封装成这种 Skill 或者 Slash Command。本文主要从人与 Agent 交互的特征出发，从更高维度，尝试设计一些能够提升 Agent 交互体验的 Slash Command。

1️⃣ /notify - 任务完成通知

我经常让 Coding Agent 在后台工作，但是等它做完的时候，我可能并不知道这件事情，相当于说，Agent 浪费了这段宝贵的时间，什么事情都没干。我作为它的老板，怎么可以希望员工偷懒呢？那如果我一直盯着它干活，又太浪费我的时间了，究竟我是老板还是它是老板？😄

因此我设计了一个 /notify 的命令，意思是说，当你完成了这个任务之后，给我发一个 Telegram 的通知。这样的话，我就可以在 Telegram 上收到这个通知了。Telegram 推送在我这里的优先级比较高，因此我大概率是可以看到的，而经过我实际测试下来，Agent 在做完哪怕是比较长的工作后，仍然会记得这件事情。这相当于给 Agent 完成任务这件事情，添加了一个 hook。 你也可以按照自己的需求修改这个命令的提示词，大概是这样的：

注：此处使用 apprise 来发送 Telegram 通知，你也可以根据自己的需求，使用其他的工具来实现通知功能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

---
description: Send Telegram notification when task completes
---

Send a Telegram notification only after the task is fully completed and verified.

## Instructions

1. **Complete the user's task** as requested.

2. **After completion**, send a notification using:
   `apprise -t "Task Complete" -b "<summary>"`

   Build <summary> as a concrete result summary (2-4 sentences). It must include:
   - What was done (specific actions)
   - Key result(s) or evidence (file paths, logs, screenshots, or checks)
   - Current status: success / partial / failed

   If $ARGUMENTS is not empty, append it as the last sentence.
   Do **not** use $ARGUMENTS as the entire summary.

3. **Timing**: Send notification AFTER all work is done, verified, and ready for user review.

## User Input

$ARGUMENTS

---

**Remember**: Complete the task first, then notify.

2️⃣ /learn - 从对话中学习

如果对模型的“记忆”相关分析不感兴趣的读者，可以直接跳转到使用方式部分。

Agent 和人不一样。在某种程度上，人的意识和记忆管理是非常紧密的，二者有一定的耦合性。但 Agent 的底座是 LLM，LLM 本身是 stateless 的，也就是说，它没有记忆的能力。如果说有的话，所谓”记忆”能力也是通过外部的文件来实现的，它们本质上是存储在磁盘上的提示词，并通过一定的方式用软件加以组织，并最终传递给 LLM。

好在现在已经有很多规范的记忆管理标准了，比如说 Claude Code 的 CLAUDE.md，在每轮对话/工具调用的时候，都会传入，作为全局性的记忆。OpenClaw 的 MEMORY.md 文件也提供了类似的机制。

还有一种我个人认为比较优雅的方式，是通过 skill。Agent 的记忆本质上都是提示词，那么从记忆的角度来说，skill 的优势在哪呢？我认为，至少有两个方面：

第一，**skill 实现了”渐进式上下文管理”。在 Agent 的上下文中，上下文是比较宝贵的。Agent 在需要时调用的 skill，其实会占据非常多的上下文空间。这实质上是 Agent 在按需获取记忆的过程中，成本和效率这二者的权衡。** 如果完整的提示词都放在全局性的记忆文件里，虽然一定能直接找到，但每次调用的时候，都会占据大量的上下文空间，不仅开销大，也会影响 Agent 推理的效果。人难以一心二用，Agent 在一定程度上也是如此。

而标准的 skill 在其 SKILL.md 头部，有一些 yaml 格式的自定义字段，其中最主要的是 name 和 description。在 Agent 运行使用的时候，这些字段实际上充当了「索引」的作用，以一个比较小的上下文代价，来实现对大量提示词的「引用」。 在需要的时候，Agent 可以通过 name 来调用这个 skill，来获取这个 skill 的 SKILL.md 的全量提示词内容。

更近一步，在 skill.md 中，还可以把一些不那么重要的、按需查看的内容，放在 references 目录下，来实现更进一步的上下文渐进式管理。

第二，**skill 实现了智能与代码的有机融合**。LLM 和代码其实是两种拥有不同优势的工具。

LLM 以人类知识的一部分为训练语料，本身具有一定的通用性的智能。借助提示词和外部的工具环境，这种智能可以做很多之前我们人类引以为豪的事情，比如说写作、翻译、使用工具等。但它又具有不稳定性的缺点，尤其是在一些需要非常精确的、结构化的输出的时候，LLM 可能就不太可靠了。而且，使用 LLM 的话，需要一定推理成本，如果让它处理一些计算量较大的任务的话，效率也不高。

而代码在确定性和效率上大大占优。对于一些需要非常精确的、结构化的输出，或者说需要处理一些计算量较大的任务，代码就非常适合了。但是代码在编写和测试上，需要一定编写、调试和维护成本，可扩展性比提示词差一些。

skill 恰好综合了这两者。一个 skill 里面，实际上可以包含提示词和代码两部分内容。提示词部分可以用来驱动智能，来指导 Agent 在使用这个 skill 的时候，应该怎么做；代码部分则可以用来成为 Agent 的工具，来弥补 LLM 在效率和确定性上的不足。从记忆的角度来说，把一些功能程序化，放在 skill 的代码里，可以很大程度上节省 Agent 的记忆空间。

当我们使用类似 OpenClaw 这样，具有一定持久化记忆能力的 Agent，或者是使用其他 Coding Agent 来辅助自己进行开发、写作等标准化的流程时，我们可能发现很多时候 Agent 对工具调用等过程，经常犯错；或是经常理解错误，需要人类反复确认。但这些又可以通过试错和调试来解决。在它反复尝试后终于解决问题的时候，上下文里面刚好包含了它完整的试错过程，对 Agent 来说，是一个完美的学习机会。

使用方式：

因此我设计了一个 /learn 的命令，让 Agent 在完成某个任务后总结一下它在这个过程中学到了什么。使用时机可以是，当 Agent 经过多次试错终于解决问题时，或在每天空闲时段（如凌晨）让它总结当天经验。这个命令很简单，甚至不需要各种复杂的提示词技巧：

1
2
3

请你深入分析，在前面试错过程中，可以总结哪些宝贵经验？请分别整理到Skill（如有对应）或项目的CLAUDE.md中，这样可以避免未来重复犯错。注意，如果这些文件中有层级引用结构的话，请按照对应的层级设计，放在合适的位置。

如果你有自己的一套记忆文件体系，也可以根据具体情况调整命令。如果使用 OpenClaw 这种长时间自主运行的 Agent，你甚至可以把这个命令设计成一个定时触发的任务，让 Agent 在每天空闲的时候（如凌晨 4 点），总结当天的经验。

3️⃣ /align - 人与 Agent 的需求对齐

在使用 Agent 的过程中，经常会发现，有时 Agent 对你的需求的理解，并不完全准确。在大多数情况下，是因为你在和他交流的有限的上下文中，没有意识到，有一些对完成需求非常重要的信息，并没有传递给它。如果早发现这种现象还好，可以通过即时纠偏和补充信息，让 Agent 更好地理解你的需求；但如果没有发现的话，Agent 就可能会按照它的理解来完成任务，浪费了宝贵的时间和 Token。

这背后有一个技术原因：在 LLM 的 RLHF 训练过程中，人类标注者通常更偏好”给出完整流畅的回答”而非”承认不知道”，这导致模型在不确定时倾向于强行完成任务，而不是主动澄清理解。 但在实际使用中，我们反而希望模型在理解不清晰时主动提问，而不是按照可能错误的理解去执行。

作为用户来说，我们很难接触和干预模型的训练过程，我们应该思考的是，我们可以决定的那些事情中，可以如何更好解决这个问题呢？那就是在开始工作之前，就对齐好需求。 具体来说，我们可以在写 prompt 的时候尽可能写得详细一些，这当然是一个好习惯。但我认为，有一个更好的方式是，在 Agent 开始工作之前，就让它主动通过提问的方式，来确定它对这个任务的理解是否正确，以及人类有没有一些欠考虑的地方。这样的话，我们既可以比较轻松地通过回答问题的方式来对齐需求，也可以看到那些我们认知之外的，没有想到要交代给模型的部分，进一步增强了我们对 Prompt 设计的理解。

因此我设计了一个 /align 的命令，来让 Agent 在开始某个任务前，总结一下它对这个任务的理解，并且和我的需求进行对齐。使用这个命令后，Agent 会主动向你提出 2-3 个澄清问题，逐步确认对需求的理解，直到双方完全对齐后才开始执行。这个命令也很简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

---
description: 与用户多轮交互澄清需求，直到完全对齐再执行。支持参数：/align <粗略需求>
---

你现在进入「需求对齐模式」（Alignment Mode）。

## 核心规则（严格遵守）

1. **绝不** 直接开始实现或写代码、写文档、生成任何输出物。
2. **唯一允许的行为**：使用 AskUserQuestion 工具（或系统提供的提问工具）向用户提问，问那些你还不太明确，或者用户欠考虑的问题。
3. 问题要**具体、聚焦、可回答**（避免开放式大问题）。
4. 每轮收到用户回答后，**立即**：
   - 简短确认理解（1–2 句）
   - 判断是否还需要更多澄清
   - 如果还不够 → 继续问下一个最重要的问题
   - 如果已经足够清晰 → 输出最终的「对齐后需求总结」，然后问：“以上理解是否正确？可以开始执行了吗？”
5. **对齐后需求总结** 必须结构化，使用 markdown 格式，包含：
   - 目标（一句话）
   - 关键约束 / 非功能需求
   - 验收标准（用户最在意的 Done 定义）
   - 优先级 / 范围（what in / what out）
   - 任何已确认的假设
6. 整个过程保持**礼貌、耐心、高效**。目标是用最少轮次达到最高理解一致性。

## 当前用户输入（原始需求）

$ARGUMENTS

## 第一步（现在立即执行）

- 仔细阅读上面的 $ARGUMENTS
- 思考：最容易导致偏离、最模棱两可、最关键的 1–2 个点是什么？
- 使用 AskUserQuestion 工具提出**第一个（或前两个）澄清问题**

开始吧。

在未来对 Agent 布置需求性任务时，不妨都使用这个命令来开头，来让 Agent 先对齐需求。虽然可能会增加一些前期的沟通成本，但从数学期望上来看，应该是可以节省后续开发过程中潜在的时间、精力和金钱成本的。

总结

这三个命令分别解决了通知、记忆迭代和需求对齐三个核心问题。使用 /align 来事先对齐，减少返工；用 /learn 来利用宝贵的试错，为Agent积累经验；用 /notify 来降低自己内耗的部分或是节省时间，提高并行效率。

本文仅是抛砖引玉，希望可以为读者提供思路和启发。如果有一个命令，或者其中的思考对你有所启发，其目的就已达到。欢迎读者补充：还有哪些你认为比较有意思的、提升在与 Agent 交互时的“幸福感”的 Slash Command 呢？欢迎在评论区交流！

关于 Agent

我们先来回顾一下什么是 Agent。

Agent 通常可被视为能够自主完成任务的智能体：它可以根据环境变化做出决策，并在一定范围内学习和适应新情况。

Agent 由 LLM 驱动，而后者通过深度学习算法与自然语言处理技术，利用目前人类生成的“符号”，如文字/图像等，进行训练，然后通过推理来生成所需的文本。这意味着，Agent 自带的能力很大程度上是由 LLM 的能力决定的，而 LLM 的能力又可以看作是“对人类现有知识（的一部分）的拟合”。因此，Agent 其实具有一定程度的“智力”（注意，与“意识”相区分），这种智力实质上可以极大解放人类的认知负担和注意力资源，而善于利用 Agent 的人，则可能可以把这些宝贵的注意资源放在那些更加宝贵的任务上面去。

提效的核心思路

基于前面的关于 Agent 概念的回顾，我们围绕“注意力解放”的思路来分析一下，当我们在使用 Agent 进行提效时，其核心思路有哪些？下面我总结了一些自己的思考，供读者参考：

1️⃣ 将交流中反复出现的表达需求进行标准化

记得之前在网上看到某位大佬的一句话，大致意思是说：

如果有一件事，提示词让你需要复用三次以上，那么就把它封装成一个 command。

当我们和 Agent 进行交流的过程中，经常会发现有一些需求会反复出现的。例如，在 Coding Agent 里面有一个经常需要做的工作就是 compact，即压缩上下文对话。这个过程虽然在即将超过上下文上限的时候，会自动发生，但在实际的使用过程中，也会有手动压缩上下文的需求。这个时候，Coding Agent 如 Claude Code、OpenCode 等，将这个需求进行了标准化，通过简单的代称 /compact 这个 slash command，实际上大大减少我们在每次需要进行 compact 这个任务时所需要的认知负担和操作步骤。

设想一下，如果每次有这个需求，都要打一堆字和 Agent 交流，那么不仅麻烦，还会增加我们的注意力负担。

那你可能会说，我用打两个字压缩上下文，不是也能达到类似的效果吗？其实人与 Agent 进行交互的时候，二者经常存在一些认知上的不对齐。你的具体需求，未必能让 Agent 通过简简单单几个字就领悟得很清楚，这其实是提供的需求细节与执行效果直接的权衡问题。

而我们通过标准化的方式，实际上是把这个权衡做了一个优化，让我们在表达需求的时候，通过把场景需求标准化的方式，用短的命令引用大段的提示词描述。既能让 Agent 很清楚地理解我们的需求，又能让我们自己在表达的时候，减少不必要的认知负担和操作步骤。这种方式是比较理想的，也是最容易实现的。

2️⃣ 构建自主规划-执行-反馈的闭环

Agent 和纯对话进行交互的 LLM 相比，很大一个区别就是它可以依据给定的目标，自主利用提供的工具，与环境进行交互，并且可以根据工具执行的反馈，自主决策后续的行为，从而实现自主规划-执行-反馈的闭环（关于 agent 与 workflow 的区分，可参考 Anthropic: Building effective agents）。

举一个例子，约在 2023 年前后、以我个人使用体验来看，会有这样的场景：需要写一个脚本，我在网页版对话中向 LLM 说明需求，它帮我写了脚本。我将脚本复制粘贴到 VS Code 中运行，发现报错后又把报错反馈给网页版的 LLM，它给出可能的解决方案。我根据方案手动修改或直接复制完整代码重新尝试，如此重复直到脚本跑通并符合预期为止。

回顾上面的例子，我们可以看到，在这个过程中，人类的注意力资源分配到了哪些环节？

1. 告诉 LLM 我的需求
2. 等待 LLM 生成脚本
3. 把脚本复制粘贴到 VS Code 中
4. 点击运行
5. 等待运行结果，判断是否符合报错/是否符合要求
6. 如果不符合要求，反馈给 LLM。回到第 2 步。
7. 结束

而现在我们使用 coding Agent 的时候，人的注意力资源被分配到了哪些环节？

1. 告诉 Agent 我的需求
   1. Agent 生成脚本
   2. 自主测试，排查是否有报错
   3. 并尝试简单运行，初步判断是否符合需求
2. 等待 Agent 完成上述流程。如果 Agent 还没完成，继续观察等待
3. 判断 Agent 的执行结果是否符合预期。如果不符合预期，反馈给 Agent，回到第 1 步。

可以看到，在这个过程中，Agent 的自主规划-执行-反馈的闭环系统，极大地减少了人类在中间环节的注意力资源占用，让人类能够把更多的注意力资源放在核心的需求表达和功能验收上面去，而不是被那些机械重复的操作步骤和等待时间占用掉。这些看起来是非常简单的任务，但是其实也需要占用一定的注意力资源。如果人的注意力资源都分配到这种繁杂的工作上，那么很快一天能用的注意力资源就会大大缩水。

我们现在使用 Coding Agent 时，实质上相比 LLM 增加了执行以及反馈的能力。传统的复制粘贴方法，只使用了 LLM 的规划能力和编写代码，而实际代码执行和反馈部分都由我们进行，链路中执行、反馈两个并没有打通，无法形成闭环。

而最近一年，Agent 生态开始慢慢变得成熟如开发过程体验已经做得比较好了。有很多原来的环节已经形成了闭环，在效率上实现了质的提升。但在其他一些领域，甚至 Coding 领域本身，还有很多一些环节做得不够好，我们可以和 Agent 一起打通整个规划-执行-反馈的闭环，让这个过程更加自动化，节省我们宝贵的注意力资源。

举个例子，现在在写作的时候，其实是有一些重复性的需求可以做的。一篇比较正式的文章的产出，可能会经历下面几个阶段：

1. 选题确定
2. 大纲构思
3. 文章撰写
4. 文章润色（格式优化、错别字语病纠正）
5. 文章配图
6. 文章发布
7. 文章数据监测

上面只是一个简单的设想，每个人会有不同的流程。但不管怎么样，我们在这个过程中，可能会发现有一些环节是比较机械重复的，例如文章润色、文章配图、文章发布、文章数据监测等，这些环节其实是非常适合 Agent 来做的。我们可以通过一些工具的打通，让 Agent 来帮我们完成这些环节的工作，从而让我们把注意力资源更多地放在选题确定、大纲构思、文章撰写这些更需要创造力和思考的环节上面去。

我最近正在研究的一件事情是，利用 Coding Agent 来帮我搭建一个专门用于文章撰写的仓库，把重复动作尽量沉淀成”可复用命令 + 可复用脚本”。换句话说，我的目标不是让 Agent 帮我”写观点”，而是让它帮我稳定处理那些可流程化的环节。

我最初使用的是 OpenCode，后来迁移到了 Claude Code。选择 Claude Code 的原因主要是：它自带的权限检查和更改预览机制比较适合这种需要自己 review 的场景；与 VS Code 的集成也很好，可以直接在编辑器里选中文章段落让 Claude Code 修改，实现 90% 不离开 VS Code 就能完成操作。

不过，选用什么 Coding Agent 并不重要，重要的是这套处理日常工作流的思路。这种思路可以拓展到写作以外的任何领域：对于那些需要长期重复完成的智力型任务，如果能用 Agent 将其自动化，那么用得越多，节省下的注意力资源就越多，复利效应会越来越明显。

这里给一个我目前正在探索的写作提效流程，下面有请 OpenCode 进行介绍：

在进入具体步骤前，先把这条 OpenCode 流水线的“入口和边界”说清楚：

1. 入口分成两段：先用 /polish @doc/article/xxx.md 跑完“格式化 → 事实核查 → Markdown 增强 →（按需）配图”，再用 /publish @doc/article/xxx.md 生成发布版并把本地图片替换为可发布的 CDN 链接。
2. 细粒度能力由原子 skill 负责：format 只做中英数间距，fact-check 负责抽取可核查陈述并给来源与改写建议，markdown-enhance 做轻量标注增强，illustrate 负责生成配图资产。
3. 脚本与 Agent 有明确分工：tools/ 里的 Python 脚本负责稳定执行（格式化、渲染、上传等），不做语义判断；语义决策与取舍仍由 Agent + 人类验收共同完成。
4. 流程执行上优先“并行化非阻塞检查”：像格式检查、链接核验、素材准备这类不阻塞主线的任务，尽量后台并行，最后统一汇总，避免主线程被低价值等待占满。

下面这三张截图，分别对应这条流程里“编排入口、事实核查改写建议、工作区差异验收”三个关键触点：

1 先做格式一致性处理（降噪）

• 用 python tools/quick_format.py <draft.md> 对草稿做中英数间距标准化。
• 如果我只想先看差异，不直接覆盖，就跑 python tools/quick_format_check.py <draft.md> 生成预览稿。
• 这一步的价值很直接：先把低价值但高频的排版动作清掉，避免我在后续修订时被格式噪音打断。

2 再做内容层修订（事实、论据、表达）

• 事实核查用 /fact-check，重点盯时间、数据和来源链路。
• 论据补强用 /strengthen，让 Agent 补证据、补反例或补边界。
• 综合修订用 /revise，统一语气、读者对象和篇幅约束。
• 这一步本质是把“我反复口头说明的修订要求”标准化成 slash command，减少沟通磨损。

3 做一次轻量标注增强（不改原意）

• 用 markdown-enhance 审阅文章，对技术词、命令、路径等补充反引号。
• 对关键判断句做适度加粗；若确有必要，再补 1-3 个外部参考链接。
• 原则是宁缺勿滥：非必要不改句式，不改观点，不改结论。

4 最后做配图与发布前资产准备

• 配图链路使用 skill("illustrate") 和 tools/illustrate.py，密钥统一从 .env 读取。
• 如果文章里有流程图，再走 tools/mermaid_render.py 输出高清图，避免手工截图导致分辨率不稳定。
• 到这一步，基本可以把注意力收回到“信息是否准确、观点是否成立、结构是否清晰”这三个核心问题上。

这里要强调一个边界：tools/ 里的脚本只负责格式化和资产处理，不做内容判断；内容判断仍然交给 Agent 的检索与推理链路。也就是说，脚本负责稳定执行，Agent 负责语义决策，人类负责最终验收。

因此，这套做法真正解决的不是“省几分钟操作”，而是把注意力从机械步骤中抽离出来，持续投入到选题、论证和表达这些高价值环节。只要这个闭环跑顺了，写作提效才是可持续的。

当然，这个流程只是我目前的一个初步探索，未来还会不断迭代优化，例如添加各个平台的自动发布（个人博客、各论坛、Telegram 群组、小红书、x 等）。

在其他不同领域，也会存在类似的问题，我们按照打通上述三个规划-执行-反馈流程闭环的思路思考和分析这些工作，并进行交互与迭代，相信会节省很多宝贵的注意力资源。

3️⃣ 使用推送模式而不是轮询方式

在日常生活中，我自己会有一些所谓的“信息焦虑”的情况。对于那些我感兴趣的信息，我会不断刷新查看，总想着最早得到最新的信息。为此我之前还专门写了一个工具（练手软件，不推荐使用，且后文有更好解决方案），方便统一查看各个平台分散的信息。但是后来我发现，很多时候，当信息产生变化时，有一个 hook 能够以合理的方式通知我，就没必要花这么多注意力资源去不断查看了。

例如聊天软件就是这样的特征，当别人给你发消息时，手机会监听到消息并通过声音或震动告知你，你再进行查看即可。我们把这两种现象进行抽象，结合从之前开发过程中了解到的 Telegram 机器人的两种工作模式，即 polling 与 webhook 得到的灵感，可以将这两种模式简单归纳为轮询和推送（可参考 Telegram 官方 Bot API 文档）。

我们的目的是尽可能用“推送”的方式，把那些值得我们关注的信息，在真正发生变化的时候通知我们，而不是靠我们不断“轮询”来查看是否变化。

比如以我当前使用配置中的 OpenClaw 为例（具体能力以版本与文档为准），我让它做了很多定时任务：每天帮我收集关注的 RSS 信息源、软件更新版本、市场价格变动等一系列我感兴趣的消息，时间间隔可设为每天、每半天或其他任意时长，然后总结推送给我。这样我就不用每天打开电脑或手机就想着去查看它们的数据及最新变化，而可以把宝贵的注意力资源放在更值得做的事情上。

从技术上来讲，OpenClaw 也是使用定时轮询的方式来做的。但是这就是 Agent 这个代理帮我们解放注意力资源所在。我们只需要和它进行交互即可，它帮我们轮询去查找信息，我们在值得被通知的时候被推送消息就行了。换句话说，把“轮询动作”交给 Agent，本质上是在回收人类注意力。

结语

在这个节奏越来越快，信息越来越碎片化的时代，Agent 的出现为我们提供了一个非常有价值的工具，可以帮助我们解放注意力资源，让我们把更多的注意力放在那些真正重要和有价值的事情上面去。一个人的注意力资源是每个人最为宝贵的资源之一，善于利用 Agent 的人，才能够在这个时代更好地生存和发展。

本文使用我的doc agent辅助创作，Powered by OpenCode。部分图片使用 AI 生成。

Vibe Coding，相信读者都应该清楚其概念。简单的Vibe Coding方式需要你持续端坐在电脑前面，和那些TUI或者GUI页面进行交互。交互的本质其实很简单，人与Agent之间的交互都可以规约于文字，或许再添加一个可选的图像。而这两部分，并不必须要求你使用电脑与其交互，电脑实质上只是提供了一个供程序运行的环境。也就是说，技术上来说，我们完全可以在交互这一流程脱离电脑，使用更加方便的手机进行交互。这一理念在之前的文章（好久之前，或许是去年了）也有介绍。

最近把Coding Agent换成了OpenCode，下面补充一下目前我使用的一套还算顺手的OpenCode流程。

主要方法

有一种方法最为简单，即利用远程控制软件，用手机远程控制电脑完成任务。但这一步实际上违背了我们前面的初衷，没有利用手机便捷易操作的特性，转而还是使用类似电脑的方式来进行操作。这种方法仅在应急或不需要经常操作的情况下推荐使用。

opencode其实不仅只能通过像Claude Code的TUI来进行交互，它还允许用户通过opencode web的方式启动一个服务器，并且官方还自带一个精简的前端（似乎也是桌面端应用所用的）来和后端进行交互。更惊喜的是，通过这种方式进行交互，从我的体验反馈来看，自定义的插件（如OMO，oh-my-opencode）都工作良好。

因此一种最简单的方式是，在电脑上运行一个绑定到可被远程访问的ip上的服务器，然后在远程进行访问即可。如果在家中，想要使用手机操控非常简单，因为WLAN局域网直接将手机和电脑进行组网，只要电脑保持打开，运行服务器后，手机就可以打开浏览器访问了。官方自带的基本前端看似简陋，但实际用下来常用的功能有95%可以使用手机代替了。唯一不太方便的是涉及到一些需要我们在电脑上当作用户来验收成果的时候，这种情况下还是建议使用电脑来进行操作。

对于我们人和电脑不在一个WLAN的情况下，我们还可以使用Tailscale等软件，进行远程组网。只需要在电脑和移动设备上都安装Tailscale软件，并且添加到一个网段里面，在手机上就可以实现远程访问了。更近一步，如果你在一些远程主机上也有OpenCode进行开发的需求，也可以把这些机器使用Tailscale组网。这里仅提供一个思路，具体配置方法相信对读者来说不是问题，希望思路对您有所启发。

对于Windows，你可以参考我编写的一个.bat脚本，可以以一个命令启动服务器，使之可以用远程进行访问。出于安全的原因，建议设置访问密码。设置完成后，浏览器打开相应地址输入密码的时候，用户名默认为opencode。

1
2
3

@echo off
set OPENCODE_SERVER_PASSWORD=<password>
opencode web --hostname 0.0.0.0 --port <your-port>

运行脚本即在后台启动服务器，手机就可以连接了。

更近一步，我最近发现了一个第三方的开源OpenCode WebUI，整体体验更加美观好用，但目前还处于早期开发阶。该WebUI不需要单独部署，在里面填入上面一步部署的后端地址就可使用。注意对于一些后端实例可能需要在命令中添加--cors "https://lehhair.github.io" 来解决CORS跨域问题，感兴趣的读者可自行体验。

上述主要是思路和经验分享，具体技术细节和安全问题请读者自行查阅与调研。

后记（碎碎念）

许久未和读者见面了，之前几个月其实有很多所见所思未能分享。这篇文章是纯手写的，在AIGC泛滥的当下，还是想真正给互联网贡献一些更有价值和思考的内容。并不是说用AI辅助写出来的文章就没有可读性。之前一直在怀疑动手写文章的必要性，因为似乎让Agent帮你按照思路生成一篇文章是更加方便的事情，也因此好几个月没有写博客的打算。后来我发现写文章并不是只是为了读者，更是为了自己能把一些事情想得更加深入和透彻，在动手的过程中，思路更加清晰了。再不济，也未尝为一种娱乐与体验。或许之前被称为“工作”的东西，在未来大多会成为一种“娱乐”或“艺术”。请允许我这次更多地为自己而写。

人力资源——不可再生性

一个人最宝贵的资源是他的时间和精力（精力也可称为注意力）。我们把这种最宝贵的资源称作人力资源。他之所以宝贵，是因为至少从目前看来，一个人终究会死的，这意味着他一生中可支配的人力资源有一个上界。有些人或许活的更久，有些人看起来精力更旺盛，但终究拥有一个不可逾越的上限。

人力资源的最本质特征是不可再生性。和不可再生资源类似，我们只能通过节省开支的方式来变相“扩容”它。换句话说，我们追求的是尽可能把人力资源花费在我们生命中那些真正重要的事情上，而不是那些为了满足生活必须的事情上。

某个人再也不用为了满足生活必需而出售自己的时间。——李笑来《财富自由之路》

复利性的事物

与之相反的是具有复利性质的事物，如资本。形式化的，我们可以用一个简单的数学公式来描述这种性质：

$$
k(1+c)^x
$$

其中k代表初始值，c代表在一定时间单位内的平均增长率，x代表时间。

复利的本质，是事物的产出可以补充到其投入。

这一性质非常关键。例如，在投资上，我们的资产会随着时间的持续而如“滚雪球”一般越滚越大，投资的收益又作为本金，持续扩大规模。

往大一些说，智人之所以为智人，区别于其他动物的重要原因，我认为其一是脑器官的进化使得人类的符号化的抽象思维得以成熟，这让我们被称为“知识”的东西得以在种群中跨个体、跨代际的积累和发展。
别小看这一点，这种性质构造了一个“复利”性质，即智人的知识产出得以持续回馈到投入之中，使得整体知识不断进行指数级别的积累。这使得生物界的进化方式得以摆脱了基因这种近乎于线性变化的节奏，以指数级的速率发展。30万年的发展历程对于地球的生物圈的30多亿年来说是惊鸿一瞥，但人类利用此复利结果，达到了前所未有的成就，且我们明显的发现这个速度越接近近现代，越来越快，以至于我们的生理进化远远落后于我们的知识。这便是复利性的强大力量。

考虑一下具有复利性事物的增量。我们对时间x进行求导，会发现求导的结果仍然是一个指数函数：

$$
k\ln(1+c)(1+c)^x
$$

这意味着，即使复利本身的增长率不变，随着时间的推移，增量也会越来越大。只要初始值足够大，且维持住复利的状态，我们无须努力改变c，也可以获得一个可观的、持续增长的增量。

但人力资源则恰恰相反。设人的一生所拥有的人力资源总量为$I_{all}$，需要花费在用于满足生活必须的人力资源总投入为$I_{necessary}$，那么我们可以朴素的将I拆解为两部分：

$$
I_{necessary} = a x + b
$$

其中x同样代表时间，a代表长期投入分量，b代表短期投入分量。长期投入分量，是我们一生中每天都需要花费的量，具有持续性；短期投入分量，则是在少数时间中一次性投入的量，不具有持续性。

我们追求的是把尽可能多的可自由支配的人力资源$I_{free}$放在我们真正关心的事情上。我们先考虑那些可自由支配的人力资源$I_{free}$：

$$
I_{free}
= I_{all} - I_{necessary} = I_{all} - ax - b
$$

同样对其求导，可以发现结果为-a。这意味着，如果我们可以尽早降低a的值，即那些具有持续性的、每天都要重复做的投入，那么我们的可自由支配的人力资源将会大大提升。哪怕这是通过以提高短期投入分量b为代价得到的，只要将来的时间x足够多，我们也可以获得更多的$I_{free}$。

这么说可能有些抽象，我们举一个简单具体的例子来辅以说明。假如说一个人的个人物品到处杂乱堆放，每次需要找东西的时候都需要消耗好多时间来进行查找，有时甚至还找不到，得重新购买。可以遇见的是，如果这样的状态持续下去，根据大数定律，他一定在未来的某些时间又要花额外的时间来做类似的事情，这使得原本潜在的$I_{free}$转换为了$I_{necessary}$。

但如果他某一天决定彻底收拾一下自己的个人物品，使用收纳柜将它们分门别类，并且在后续坚持这么维护这种状态，那么实际上是把原来被占用的$I_{necessary}$中的长期分量a部分转移成了短期分量b。这么做之后，长期来看一定是节省了潜在的人力成本的。

这也是人们老生常谈的“养成一个好习惯”的重要性，在该数学模型下的一种解释。长期来看，一个好习惯能够持续的为你节省潜在的人力成本。

由此自然推导出的结论

考虑增大$I_{free}$，我们可以以下面几种思路入手：

1. 增大$I_{all}$。包括尽可能保持生命的长度，以及每天的人力“利用率”。
   1. 生命的长度，可通过保持一个健康的身体实现。健康的身体也能在一定程度上提高人力的利用率。
   2. 另外，有一个优秀的人力资源分配机制，能提高人力资源的利用效率。
2. 减少$I_{necessary}$。
   1. 尽可能降低a的值。这可以通过：
      1. 提升完成工作的效率。可通过技能的不断娴熟实现。如提升拧螺丝的效率。
      2. 通过一种系统性的优化，以一定的短期分量b的提升为代价，将尽可能多的a降低。如通过设计一种物品收纳的方式，降低长期取用所花费的人力成本。

对于复利性的事物，如财富、认知和人脉，应该尽可能早的开始积累，并且保持一个能获得长期复利的状态。这些复利性的资源能够帮助减少我们的$I_{necessary}$。

另外，我们期望所拥有的$I_{free}$可以被更高效的用于追求那些我们真正感兴趣的事情，因此，找到我们人生意义感，搞明白哪些事情是我们真正感兴趣的也是非常重要的。

我们使用Claude Code时，正常需要通过命令行与其交互，但这往往要求我们需要在一台电脑前待着。

思考一下，我们与Claude Code的交互，实质上只是两种：

1. 输入文本；
2. 选择批准或者拒绝操作。

事实上，要实现和它的交互，我们完全不必使用电脑。也就是说，理论上我们完全可以只使用手机，以一种方式连接到电脑，实现交互。

这么说来，已经有一种现成的朴素方法：通过手机远程控制电脑，然后和Claude Code进行交互。但这种朴素方法在交互时有所不便，例如输入文字的输入法问题、选择批准/拒绝时需要使用方向键等。

如果在移动设备上有用户友好的应用，或是使用一个类似vscode的server版本，那么体验就会好很多。

带着这个思路，我先找到了claude-code-webui这个项目，该项目可以网页的形式和Claude Code进行交互，但目前还没有鉴权功能，试用下来较为简陋。

又找到了claudecodeui这个项目，看起来完成度就好很多。

那么剩下的就是网络配置上的问题了。我的需求是，即使和我的电脑不在一个局域网内，也能可以连接在我电脑上运行的该服务。

我想到了Cloudflare Tunnels，可用于打洞，再通过Cloudflare绑定自己的域名即可实现远程访问。

Cloudflare Tunnels 是由 Cloudflare 提供的免费服务，可用于安全地将本地或私有网络中的服务暴露到公网，而无需开放防火墙端口、配置公网 IP 或使用反向代理（如 Nginx）。

前置要求

想要和我一样远程指挥Claude Code干活，需要以下前置条件：

1. 电脑本地可用的Claude Code；
2. 一个绑定在Cloudflare上的域名。

详细教程

安装claude-code-webui

首先确保已安装Node.js 20。

克隆项目：

1

git clone https://github.com/siteboon/claudecodeui.git

安装依赖。

1

npm install

启动服务器

1

npm run dev

此时在本地访问localhost:5173即可测试是否可以在网页中正常使用Claude Code。初次使用是需要设置一个唯一的用户名和密码。

一切正常后，我们继续配置。

Cloudflare Tunnels配置

Cloudflare Tunnels 是由 Cloudflare 提供的免费服务，可用于安全地将本地或私有网络中的服务暴露到公网，而无需开放防火墙端口、配置公网 IP 或使用反向代理（如 Nginx）。

前往one.dash.cloudflare.com，转到网络 > Tunnels，点击创建隧道，选择Cloudflared类型。名称可任意填写。

配置时，按照说明下载cloudflared命令行工具。下载后，注意使用管理员权限运行提示的命令。连接成功后，网页下方应该会显示已连接的连接器。

下一步，第一行填写的是需要选择你的域名，第二行选择本地服务的URL（注：url注意选择你本地的端口，默认为5173）。

这一步完成后，在手机上访问你配置的域名，应该就能正常访问服务了。

Cloudflare Zero Trust（可选）

由于现在该域名直接通过Cloudflare Tunnels直接连接到电脑，且该项目是一个较新的项目，可能存在潜在的安全问题。我们还可以给服务添加外部鉴权，通过配置Cloudflare Zero Trust进一步加强安全。

注意，这一步需要先完成Free Plan的支付方式认证。博主使用国区PayPal可成功绑定。

前往Access > 应用程序，选择创建。

公共主机名填写前面的域名。

接下来需要添加策略，这里我选择的是使用邮箱验证，值填写你的邮箱即可。

返回在创建的应用程序中，选择该策略。这样在访问域名的时候，需要先向你的邮箱发送一个验证码，才能访问。

现在就可以在手机上指挥Claude Code了。

在下方可以切换模式，包括自动接受编辑、Plan mode和Bypass permissions（跳过权限检查）等模式。

Cloudflare的Tunnels在电脑本地会以守护进程的方式自启动，当需要远程使用的时候，使用npm run dev启动项目即可。有需要的话，读者也可以自行设置项目的自动启动。

我们在开发GitHub Action的CI时，经常遇到需要进行调试的情况，毕竟如果是从零开始写一个workflow，难免会遇到一些意料之外的问题。

本教程主要使用act，实现在本地运行Github Actions的目的。Act是一个开源的工具，它可以解析项目中的.github/workflows/ ，并利用Docker API拉取或者构建必要的镜像，根据执行顺序完成任务。环境变量和文件系统均配置为与 GitHub 提供的环境一致。

环境配置

博主使用的环境是Windows。若你使用的系统不同，请参考Installation - act - User Guide | Manual | Docs | Documentation 完成环境配置。

大致来说，Windows 和 MacOS 系统需要配置Docker Desktop，Linux需要安装Docker Engine。除docker之外，还需要安装act。

对于Act来说，如果使用Windows，可以直接通过scoop install act 的方式来安装，也可使用winget。具体可用的包管理器，也可参照Installation - act - User Guide | Manual | Docs | Documentation。

如果你使用VSCode进行开发，VSCode还有一个名叫GitHub Local Actions的插件，可以方便的利用图形界面进行调试。

基本使用

如果使用VSCode，使用Github Local Actions进行调试即可，图形界面非常好理解。

下面主要介绍一下命令行的使用方式。

在第一次运行的时候，Act可能会提示你选择模拟环境需要的镜像。

选择Large可以完整模拟Github托管的Runner的环境，但该镜像较大，需要75GB空间，如无必要选择默认的Medium即可。

act支持基本的事件。也就是说，你可以通过模拟像push pull_request 这样的事件，触发相应的工作流进行调试。例如，你的仓库有一个由pull_request 触发的测试工作流，那么你只要执行act pull_request ，即可进行测试。

还可以通过act -W '<path-to-workflow>' 指定单个工作流进行运行。

更多使用方法，请查看官方文档。

方法一：临时命令行方案

1

sdkmanager --verbose --no_https --proxy=http --proxy_host=<host> --proxy_port=<port> "<package>"

其中

• proxy_host填写代理主机，本地填127.0.0.1
• proxy_port填写代理端口。
• 最后跟上需要安装的依赖

方法二：永久修改方案（需要修改bat）

博主使用的是Windows环境，其他系统应该类似。

1. 定位文件：

   1 2	# Windows %ANDROID_HOME%\cmdline-tools\latest\bin\sdkmanager.bat

2. 找到 %CMD_LINE_ARGS% 所在行，在文件末尾附近，以"%JAVA_EXE%" %DEFAULT_JVM_OPTS%开头

3. 修改为：

1

"%JAVA_EXE%" %DEFAULT_JVM_OPTS% %JAVA_OPTS% %SDKMANAGER_OPTS% -classpath "%CLASSPATH%" com.android.sdklib.tool.sdkmanager.SdkManagerCli --verbose --no_https --proxy=http --proxy_host=<host> --proxy_port=<port> %CMD_LINE_ARGS%

注意修改里面的相关参数。

这样配置以后，每次在命令行中使用sdkmanager之后就会自动使用代理了。

我对学习一项新技术的最低标准是：“入门”。在我看来，达到所谓的入门，需要两方面的能力

1. 对该领域的的核心概念有一定的理解，至少说听业内人士提到某个概念，能大概明白是什么；
2. 进行实践，利用自己掌握到的知识，能够自己动手完成一个像样的作品。

最近我对区块链技术比较感兴趣，学习了核心概念后，想着用它来做点什么。我在寻思用什么项目来检验我的入门水平的时候，突然想到了留言板这么一个idea。

传统的留言板大多都是基于中心化的服务来实现的，这意味着，控制这个中心化的人可以将其他用户的留言进行删除或者是篡改。但是如果说我们能够利用区块链几乎不可能被篡改的能力，将用户的留言发送到链上，并且将智能合约的代码公开，那么这将是一个完美的闭环，不管是留言的留言者，还是说这个合约的创建者，都无法篡改这些内容。然后再加上一个前端页面，当用户访问的时候获取链上的留言，这样大家就都能看得到了。哪怕将前端网页下线，在链上根据开源的合约代码和公开合约的ABI信息，也能够查看到留言信息。

说干就干！

项目技术栈

• Solidity - 以太坊智能合约的编程语言
• React - 前端框架
• Tailwind CSS - 样式框架
• Wagmi - Web3开发库
• Cloudflare Workers - 后端代理服务

项目目录树（使用我写的开源CLI：Treex生成）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

📁 ./
├── 📝 README.md
├── 📁 cloudflare/
│   └── 📜 worker.js
├── 📜 eslint.config.js
├── 🌐 index.html
├── 📋 package.json
├── ⚙️ pnpm-lock.yaml
├── 📜 postcss.config.js
├── 📁 public/
│   ├── 📄 favicon.ico
│   └── 🖼️ icon.png
├── 📁 solidity/
│   ├── 📋 abi.json
│   └── 📄 message.sol
├── 📁 src/
│   ├── 🎨 App.css
│   ├── 📜 App.tsx
│   ├── 📁 assets/
│   │   └── 🖼️ react.svg
│   ├── 📁 components/
│   │   ├── 📜 MessageBoard.tsx
│   │   └── 📜 QA.tsx
│   ├── 📜 config.ts
│   ├── 🎨 index.css
│   ├── 📜 main.tsx
│   └── 📜 vite-env.d.ts
├── 📜 tailwind.config.js
├── 📋 tsconfig.app.json
├── 📋 tsconfig.json
├── 📋 tsconfig.node.json
└── 📜 vite.config.ts

正文

Github 开源地址：https://github.com/shiquda/chain-message

在线预览：https://msg.shiquda.link/

部署教程： https://github.com/shiquda/chain-message/blob/main/DEPLOY_GUIDE.md

如果你想要充分理解这篇文章内容，最好需要有一定的区块链知识。没有也没关系，相信以读者聪明的脑袋瓜，可以随时利用大模型轻松理解。如果你对此感兴趣，想要动手实践的话，你还需要一个钱包插件。（我使用的是OKX的Web3钱包）

智能合约

首先我们需要编写智能合约代码。智能合约可以简单理解为在区块链上运行的一串代码，而整个区块链可以看作是一个状态机，智能合约的交互使得状态机从一个状态变化到另一个状态。智能合约支持两类调用，一种是Read类型的，调用此类合约不需要花费Gas手续费；另一种是Write类型，由于涉及到写操作，这类开销是比较大的，需要花费Gas。

我编写的这个智能合约代码只允许两个接口，一个是 postMessage ，这是一个Write Contract，让用户传入他想要提交的留言。其中名字是可选的，如果不填就会视作是匿名留言。此外应该要支持markdown格式，这一点在前端处理即可。

1
2
3
4
5
6
7
8
9
10
11
12
13

function postMessage(string memory _name, string memory _content) public {
    unchecked {
        // 安全计数（Solidity 0.8+默认检查算术溢出）
        _messageCounter++;
    }
    emit MessagePosted(
        _messageCounter,
        msg.sender,
        bytes(_name).length == 0 ? "Anonymous" : _name,
        _content,
        block.timestamp
    );
}

在留言发送后，智能合约会自动保存前面的这几个参数之外，还会保存发送时的时间戳等信息。

1
2
3
4
5
6
7

event MessagePosted(
    uint256 indexed messageId, // 留言ID（可索引）
    address indexed sender, // 发送者地址（可索引）
    string name, // 留言者名字（或"Anonymous"）
    string content, // Markdown内容
    uint256 timestamp // 区块时间戳
);

还有一个接口，用于查询消息的数量。这个接口是只读的，进行合约调用的话，相当于只是在区块链上进行状态的查询，并不会消耗gas。这个接口其实项目暂时没有用到。

1
2
3

function getMessageCount() public view returns (uint256) {
    return _messageCounter;
}

除此之外，就没有预留其他任何接口了，这意味着只要留言上链，哪怕是我也无法删除。

接下来讲讲我是如何部署智能合约。我使用的是以太坊基金会推荐的，对于新手比较友好的一个在线IDE：Remix。

我们将本地写好合约的贴到这个remix上，然后然后选择编译。编译之后，在左侧选择部署选项卡。

选择Walletconnect，并且根据提示连接你的钱包插件。连接之后，点击部署，在钱包插件确认之后就能部署上链了。

部署合约是需要消耗比较高的Gas费的，所以说你可能需要从中心化的交易所中提取一些一些到你的钱包。我上次部署的时候大概是花了0.37刀。部署完成之后你还可以到Etherscan上添加你的合约源码，这样大家就可以公开审查这个合约代码，确保这个系统的不可篡改性。

这里有一点要注意的是，我使用的是智能合约的event log来进行留言的记录。之所以这么做而不选择使用storage直接存储到区块链上的原因，是因为那样会消耗更多的Gas费。使用Event log记录的方式就可以减少这个消耗，让用户提交留言的时候少花一些Gas费。在我测试的时候，提交一次留言需要使用0.05美元，大概折合人民币3毛多。

当然，其实测试的时候先上测试网进行测试是一个比较稳妥的方式，但是我这边太心急了，想马上能够把第一个属于自己的智能合约部署到主网上，大家最好不要学我这么做🤣

前端实现

前端实现，我使用的是React框架，Tailwind CSS对样式进行简单的美化。这边使用的对接web3的库是wagmi，感谢前人Web3开发者，已经帮我们普通开发者做了很多事情了。这个库可以自动处理和用户的钱包插件交互。

具体实现就不多赘述了，感兴趣的读者可以查看源码。

在线预览：https://msg.shiquda.link/

Cloudflare Workers

前端的内容比较简单，但这时出现了一个新的问题：怎么样让用户能够获取区块链上的留言信息呢？

我首先尝试一种方案，利用公开的以太坊节点来进行日志的获取。但是我尝试几个后发现大多数都不支持无鉴权的调用。对于获取Event log信息，我找到一个免费的， https://ethereum.publicnode.com ，但也仅支持查询最多5万个区块的信息，这与我的预期显然是不符合的。因此我干脆使用需要鉴权的Etherscan的API。

但这里又有一个问题，如果说密钥直接存储到前端的话，泄露之后，不就会被他人滥用了？

于是我想到了Cloudflare Workers做一个简单的封装。当用户发起请求到Cloudflare Workers的时候，worker通过在CF配置的环境变量的APIkey，然后再将请求发往EtherScan，做一层转发。再根据传回的内容返回给用户，这样前端页面就可以进行实时的消息获取了。

但这样，还是有可能被人利用接口进行event log的查询。我们再设置一个环境变量，让接口只能用于我们部署的合约的查询，这样就大大降低了滥用者的收益。

这边还有一个坑点，就是说CF的Workers域名是被GFW封锁的。想要解决这个问题，可以使用自己的域名或者子域名做一个转发，这样就能绕过限制了，让用户直连也能够请求到所需的留言信息。

要进行Workers的配置，你需要在Cloudflare的左侧找到Workers 和Pages，然后创建 > Workers > Hello world > 填写名称并部署 > 进入修改源码，粘贴下面的代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

// worker.js
export default {
    async fetch(request, env) {
        // 处理预检请求
        if (request.method === 'OPTIONS') {
            return new Response(null, {
                headers: {
                    'Access-Control-Allow-Origin': '*',
                    'Access-Control-Allow-Methods': 'GET, OPTIONS',
                    'Access-Control-Allow-Headers': 'Content-Type',
                },
            });
        }

        const { searchParams } = new URL(request.url);
        const address = searchParams.get('address');
        const startBlock = searchParams.get('startBlock');

        if (!address || !startBlock) {
            return new Response('Missing parameters', {
                status: 400,
                headers: {
                    'Access-Control-Allow-Origin': '*',
                    'Content-Type': 'application/json',
                }
            });
        }

        // 可选环境变量：合约地址，防止接口盗刷
        const CONTRACT_ADDRESS = env.CONTRACT_ADDRESS?.toLowerCase();
        if (CONTRACT_ADDRESS && address.toLowerCase() !== CONTRACT_ADDRESS) {
            return new Response('Forbidden', {
                status: 403,
                headers: {
                    'Access-Control-Allow-Origin': '*',
                    'Content-Type': 'application/json',
                }
            });
        }

        const params = new URLSearchParams({
            module: 'logs',
            action: 'getLogs',
            address: address,
            fromBlock: startBlock,
            apikey: env.ETHERSCAN_API_KEY
        });
        const response = await fetch(`https://api.etherscan.io/api?${params.toString()}`);

        const data = await response.json();
        return new Response(JSON.stringify(data), {
            headers: {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Origin': '*',
                'Access-Control-Allow-Methods': 'GET, OPTIONS',
                'Access-Control-Allow-Headers': 'Content-Type',
            },
        });
    },
};

然后找到Worker的设置 > 变量和机密 > 变量和机密 > 添加，添加CONTRACT_ADDRESS和ETHERSCAN_API_KEY这两个环境变量。

如果你需要绑定自己的域名，你需要在CF进入域名的管理页面，然后找到左侧的“Workers 路由”，选择添加路由并绑定前面创建的Worker。

静态网页生成

一切就绪后，我们完全可以使用生成一个静态页面，然后把这个静态页面上传到我们的博客或者是云托管服务上面，这样就能够实现独立的运行了。

推荐使用Cloudflare Pages的方式进行部署。使用这种方式的教程请见Github 上的部署教程。

克隆项目，安装依赖并配置

1
2
3

git clone https://github.com/shiquda/chain-message.git
cd chain-message
pnpm install

然后参考.env.example填写需要的环境变量。一切就绪后，使用下面的命令进行构建：

1

pnpm build

dist/中的文件就是静态网页了，你可以把它放到托管服务上。

结语

说完这么多，真的是感慨万千。假如说一百年后，当我离开这个世界之后，这些留言可能还能存在区块链上，甚至别人还能够访问到、看到我自己的，或者是别人网友给我的留言，真的是一件非常酷的事情。

留言地址：https://msg.shiquda.link/

不管怎么样，先给10年后的自己留个言。（多打了一个字，已经无法挽回了😄）

实现这个idea的所有代码，包括智能合约代码，前端代码，还有cloudflare workers代码，我都放到github仓库上，要是你也对这个感兴趣，可以自己部署一个玩玩看。

我前几天申请了一个以太坊的地址域名：shiquda.eth。使用这个ENS域名，就可以找到我的钱包地址，也就是部署这个合约的地址。如果文章对您有所启发，可以给我这个地址打钱😄（真是太不要脸了）

这本书大概是以道理+实例的方式来展开的，所举的例子也都挺生动，但是读起来也难免感觉有些冗长。下面我将每一章提炼为若干观点。

1. 受限于每个人的出身、成长经历、所处社会环境等诸多因素，每个人对金钱的认知有非常大的差异，所有可能只有很少一部分符合实际，而对金钱的认知在很大程度上影响了我们对世界运作方式的理解。

2. 一个人做出投资决策，绝不是简单的看着股票价格的变化，进行一系列分析做出的，必定会受到个人经历、世界观、家庭现金流等其他“场外”因素的影响。

3. 生活中的每一个结果都受到个人努力之外的其他作用的影响，你不能只相信其中一个，而无视另一个。

4. “知足”很可能是我们在不知为何的奔跑中忽视的一个因素。向上攀比，是没有尽头的，敢于适可而止才显得更加宝贵。

5. 世界上很多事都不值得冒险，无论潜在收益有多大。追求它们，你可能需要承担失去无价之物的风险，例如名誉、自由、亲友乃至生命。

6. 复利的力量是反直觉的。

7. 致富需要的是冒险精神、乐观心态，以及放手一搏的勇气。但守富需要做的却与冒险完全相反，它需要谦逊和敬畏之心，需要清楚财富来得有多快，去得就有多容易。

8. 比起巨大的回报，财富的安全更重要。只要财富安全，你就知道利用复利的力量，你就能得到最大的回报

9. 一个投资者即使在一半的时间里都看走了眼，最后却仍然能致富（靠盈亏比和尾部事件），这是反直觉的。因此，有时不必对失败过度焦虑，它们的存在是必然的。例：风险投资的广撒网策略，只靠为数不多的成功的创业公司获利。

10. 在大多数情况下，“当下”其实并没有那么重要。你最近将要做出的决策，往往远不如一生中做出的个别几个决定重要。

11. 财富能给你带来的最大红利是时间自由。“今天我能做我想做的任何事。”

12. 购买奢侈品，实质上是购买他人的羡慕。但事实上，他人看到你的奢侈品，往往不会羡慕你，而更可能拥有下面几种想法：

    1. 关注于奢侈品本身：“这个奢侈品真漂亮！”
    2. 对比他自己：“我永远也买不了”/“我能不能也买一个？或者更贵的？”
    3. 质疑你：“你有钱，但我觉得你不配。你这么有钱都是靠xxx的。”

13. 炫富是让财富流失的最快途径。这个世界上有很多看起来低调但实际上很富有的人，还有很多看上去很有钱却生活在破产边缘的人。

14. 财富积累与你的收入或投资回报率关系不大，而与你的储蓄率关系很大。

15. 事实上，尝试缩减不必要的开支，或是将其用于投资，比你绞尽脑汁提高0.1%的收益率更加直接和简单。

16. 存款 = 虚荣的自我 - 收入

17. 存钱并不需要一个特别的理由。存钱不仅是为了更多的回报，即使完全没有收益上的回报，选择一份对自己来说更有价值的工作、等待恐慌带来的投资机会，这种与其他人相比更高的灵活度，也是一种回报。

18. 合乎情理胜过绝对理性，这是因为在投资行为中存在着社会性因素。在做投资决策时，不要试图保持绝对理性，而要做出对你而言合乎情理，也就是更容易接受的选择，这么做更容易让你做到长期坚持。换句话说，现实中的最佳投资方案一定是能让我们晚上睡得安稳的方案，而不是试图做到绝对理性，在刀尖上舔血的方案。

19. 日内交易、选择个股、根据投资预测来交易，这些方式对大多数投资者来说都是不够理性的表现，但如果占比很小，这么做顺应你的人性的话，那么它们就是合乎情理的。（看作一场游戏）

20. 我们试图从各种角度，根据历史来预测未来。但事实是，世界上总在发生过去从来没有发生过的事，这是反直觉的。例：修建核反应堆时，人们考虑过的最坏情形是历史上发生过的最严重的地震，但历史上的最坏事件同样是个意外。

21. 尾部事件和尾部人物所造成的影响是超乎想象的，因为它们会随着时间的流逝，影响越来越大。

22. 关于投资史很有趣的一点是，你追溯的时期越久远，你看到的规律就越不适用于今天的世界。

23. 容错空间是很重要的。有些事情从统计学角度看是可行的，但我们必须保证手上有足够的钱去应对运气最差的情况，不要因为一次黑天鹅事件让你赔得底裤都没了。

24. 人是会变的。人们能敏锐地意识到自己相比过去发生的变化，但很容易低估自己的性格、想法和目标在将来会发生的变化。

25. 投资是有代价的，不必付出代价就能获得回报是一种错觉。但回报的成本往往是隐性的。它们包括：忍受波动的心理成本、机会成本、无法预测的黑天鹅爆雷事件……如果你把它们显性地揪出来，并使作为支付的“入场券”，那么心理会好受很多。

26. 不要贸然从那些和你情况不同的人身上学习理财经验。每个人的经验不同、投资逻辑（如做短线/长线）不同、可承受风险能力不同、进场点位不同

27. 人们对负面事件的本能厌恶，使得悲观主义具有心理优势，人们更容易收到它的影响。

28. 每个人对世界的看法都是不完整的，但每个人都会编织完整的故事来弥补其中的空白。

今天给读者推荐一个我最近开发的面向开发者的小工具——Treex。

🤔 为什么需要这个工具？

在开发与学习过程中，可能会遇到过这样的场景：

• 对于一个较为陌生的项目，看着复杂的项目结构，不知道怎么入手
• 想要快速告诉大模型自己一个项目的结构，让它辅助你理解
• 写项目文档时需要插入目录结构的可视化

传统的tree命令虽然能用，但功能太基础了。楼主在使用过程中，常常会出现把不需要的文件同时绘制出来的情况（例如，node项目的node_modules），导致包含太多不必要的信息，看上去更乱了。

于是我利用cursor，使用go语言开发了Treex，这是一个支持多种输出格式、带过滤功能的目录树工具。

项目地址：https://github.com/shiquda/treex

✨ 核心功能一览

🎨 多格式输出

• 🌲 树状格式（默认）：经典的命令行树状结构
• 📑 缩进格式：简洁的层级缩进
• 📝 Markdown格式：直接粘贴到文档里
• 📊 Mermaid格式：生成可嵌入的流程图

🔍 智能过滤

• 🕵️ 隐藏.git等隐藏文件
• 📁 只显示目录结构
• 🚫 排除指定目录/文件类型

🛠️ 高度可定制

• 📏 控制目录深度
• 💾 输出到文件
• 🎯 自定义显示格式

🚀 快速上手

下载

方法1：下载预编译二进制文件

从Release页面下载后，加入PATH

方法2：用Go编译安装

如果你有go环境，可以使用下面的代码一键安装：

1

go install github.com/shiquda/treex@latest

基础使用

1
2
3
4
5
6
7
8

# 查看当前目录结构
treex

# 查看指定目录
treex -d /path/to/project

# 查看help信息
treex -h

输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

└── .
    ├── .git
    │   ├── HEAD
    │   ├── config
    │   ├── description
    │   ├── hooks
    │   │   ├── applypatch-msg.sample
    │   │   ├── commit-msg.sample
    │   │   ├── fsmonitor-watchman.sample
    │   │   ├── post-update.sample
    │   │   ├── pre-applypatch.sample
    │   │   ├── pre-commit.sample
    │   │   ├── pre-merge-commit.sample
    │   │   ├── pre-push.sample
    │   │   ├── pre-rebase.sample
    │   │   ├── pre-receive.sample
    │   │   ├── prepare-commit-msg.sample
    │   │   ├── push-to-checkout.sample
    │   │   ├── sendemail-validate.sample
    │   │   └── update.sample
    │   ├── info
    │   │   └── exclude
    │   ├── objects
    │   │   ├── info
    │   │   └── pack
    │   └── refs
    │       ├── heads
    │       └── tags
    ├── .gitignore
    ├── 1.go
    ├── 2.go
    ├── README.md
    ├── build
    │   └── win
    │       └── output.exe
    └── test
        ├── 3.go
        └── README_test.md

⚡ 高级使用示例

1. 生成项目文档

1
2

# 排除隐藏文件，输出Markdown格式到指定文件
treex -H -f md -o PROJECT_STRUCTURE.md

• ./
  • 1.go
  • 2.go
  • README.md
  • build/
    • win/
      • output.exe
  • test/
    • 3.go
    • README_test.md

2. 技术分享配图

1
2

# 只保留非隐藏的文件夹，生成Mermaid代码
treex -HD -f mermaid

1
2
3
4
5
6
7
8

graph TD
    N1[./]
    N2[build/]
    N1 --> N2
    N3[win/]
    N2 --> N3
    N4[test/]
    N1 --> N4

3. 排除指定文件

1
2

# 排除不重要的文件夹和文件类型
treex -e ".git/, .md"

1
2
3
4
5
6
7
8
9

└── .
    ├── .gitignore
    ├── 1.go
    ├── 2.go
    ├── build
    │   └── win
    │       └── output.exe
    └── test
        └── 3.go

🛠️ 完整参数说明

可以前往 https://github.com/shiquda/treex 查看。

💖 期待你的参与

Treex目前还在早期开发阶段。笔者还没有多少开发经验，受限于个人水平，工具难免有不足之处。如果你：

• 发现了bug
• 有功能建议
• 想贡献代码

欢迎在GitHub给我提Issue或PR！当然，给个⭐星星鼓励也是极好的～

项目地址：https://github.com/shiquda/treex

MCP(Model Context Protocol)来自于2024年Anthropic发布的文章：Introducing the Model Context Protocol，是一种用于和LLM Model 交互的标准化协议，允许模型拓展自己的能力。在最近的Manus爆火之后，关注度更是上升，我也是在这之后才了解到这个协议的。在我看来，这个协议是一个里程碑式的节点，统一了模型和应用之间的通信标准，在未来会有更加广阔的应用场景，现在也有不少应用厂家接入了MCP协议，比如国内的百度地图。

借用下面这篇文章的图片，这张图一目了然地展示了MCP的作用。对于MCP感兴趣但是还不是很了解的读者，推荐去阅读一下下面这篇文章。

https://zhuanlan.zhihu.com/p/29001189476

本文既是我摸索搭建一个MCP学习记录，也是一个简单的流程分享。受限于个人技术，本文并不涉及到一些较为成熟的开发范式，更多是对整体流程做一个记录和梳理，希望能对想要着手开发MCP服务器的读者有所帮助。这篇文章会以Python为编程语言进行实践。

我搭建的服务器：一个用于帮助大模型访问wiki网站的服务器，欢迎大伙Star！

https://github.com/shiquda/mediawiki-mcp-server

这个项目的灵感源于我最近玩的一款游戏Noita，对于我这个新手来说，需要经常查询游戏wiki。于是我就为了这点醋，包了这碗饺子，打算利用MCP技术，让大模型帮我阅读和总结wiki。于是就有了这篇文章😄

先决条件

在阅读并实践之前，笔者假设读者拥有以下能力：

1. 熟悉Python编程语言
2. 拥有能稳定使用、支持Tool Call的大模型提供商，以及一个支持MCP协议的客户端
3. 熟悉Git与GitHub的基本使用
4. 拥有良好的网络环境

对于第2点，若读者还没有合适的，笔者进行以下推荐：

1. 火山引擎-云上增长新动力：字节提供的稳定性好、价格优惠的平台，使用其中的DeepSeek模型，支持tool-call。
2. Cherry Studio 官方网站 - 全能的AI助手：一个开源免费的、支持多个LLM提供商的桌面端大模型对话软件，现在支持MCP协议。（笔者参与了该项目的贡献，算是打个小小的广告:)）

对于上述二者的申请与配置，相信对读者应该不成问题，烦请读者自行查找攻略进行配置。

正文

环境配置

使用Python进行MCP服务器的开发，目前主流使用的是uv，这是一个使用Rust编写的高效的包管理器，支持虚拟环境管理、运行和安装Python应用、项目管理、项目构建等多个功能。想进一步了解，可以阅读官方文档。

请读者自行安装与配置uv。可以参考这篇文章：

Python包管理不再头疼：uv工具快速上手 - wang_yb - 博客园

我们还需要用到node环境，用于服务器的测试。

初始化

使用uv进行项目的初始化。

1
2

uv init <项目名>
cd <项目名>

创建虚拟环境：

1

uv venv

并使用你所在平台的方式进行激活。

使用uv添加依赖：

1

uv add "mcp[cli]" httpx

对于克隆来的其他mcp项目，我们可以使用下面的命令来进行依赖的安装：

1

uv sync

项目结构

下面是一个最简单的项目结构，省略了部分文件，供读者参考。

1
2
3
4
5
6
7

mediawiki-mcp-server
├── pyproject.toml
├── README.md
├── src
│   ├── mediawiki_mcp_server
│   │   ├── main.py
├── uv.lock

pyproject.toml是整个项目的配置文件，我们需要对其进行相应的修改。

除了已有的项目名称、版本号等，我们还需要添加下面几行，用于项目的运行和构建：

1
2
3
4
5
6
7
8
9

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project.scripts]
mediawiki-mcp-server = "<包的名称>.main:main"

[tool.hatch.build.targets.wheel]
packages = ["src/<包的名称>"]

然后就是开始编写一个简单的MCP服务器啦！想要更详细地查看，可以参考下面这些来源：

For Server Developers - Model Context Protocol

modelcontextprotocol/python-sdk: The official Python SDK for Model Context Protocol servers and clients

我们在/src/<name>创建一个main.py 文件，用于写MCP服务器的主要逻辑。

对于一个最简单的服务器，可以参考下面的写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

from mcp.server.fastmcp import FastMCP
mcp = FastMCP("<name>") # 创建服务器实例

@mcp.tool() # 这个装饰器表示下面的函数是一个可被LLM调用的Tool
async def get_page(title: str): # 参数会被自动处理，写在下面的docstring可以被识别作为给大模型的“工具使用说明书”
    """Get a page from mediawiki.org
    Args:
        title: The title of the page to get, which can be found in title field of the search results
    Returns:
        The page content
    """
    path = f"page/{title}"
    response = await make_request(path, {}) # 实现略
    return response

def main():
    mcp.run(transport="stdio") # 使用stdio本地模式

if __name__ == "__main__":
    main()

简单来说，只要专注于实现一个Tool的接口就行了，对于暴露给模型调用的，使用@mcp.tool()进行修饰，调用参数即为函数的传入参数，而使用方法写在函数的注释里面即可。

下面我们从用户的角度考虑一下。用户使用你的服务器，主要可以配置三个部分：

1. 命令。主要使用的有uvx/uv 、npx和docker 。我们使用的是python，因此这里一般是填uvx/uv。
2. 参数。这一部分会通过命令行参数传给服务器，因此我们需要考虑在mcp.run启动前处理这些命令行参数。
3. 环境变量。我们在启动前也需要检查需要的环境变量。

因此，我们需要使用参数或者环境变量来达到自定义服务器和读取数据的目的。例如，对于一些需要鉴权的服务，我们可以让用户在环境变量部分配置他们的凭证；一些自定义的参数，可以放在命令行参数来传入。

测试

编写完逻辑之后，需要进行测试。

第一步，先使用MCP官方提供的测试工具进行测试，使用起来非常简单：

1

npx @modelcontextprotocol/inspector uv run <name>

运行之后，在浏览器打开提示的地址，即可进行调试。

对于我们这个简单的项目，主要测试的是Tool的功能。

第二步，测试完成后，我们就可以对接到客户端进行进一步测试了。这一步主要是检查功能是否符合预期，LLM能否按照预期调用，以及会不会出一些没考虑到的问题。

对于本地开发调试，需要注意的地方是，由于我们现在还没有将成品打包到pypi，因此需要添加命令行参数来进行本地调试。可以参考下面的写法：

命令：uv

参数：

1
2
3
4
5
6
7

"args": [
  "run",
  "--directory", 
  "path/to/project/src/<name(下划线)>",
  "<name>",
  "<...其他参数>"
],

构建

测试完毕后，我们可以考虑发布到pypi，让其他用户能够更方便的下载使用。

在本文中，我们使用uv，利用Github Actions来进行自动化构建，但在正式构建之前，本地需要进行测试：

1

uv build

如果正常的话，在项目的/dist 应该会有相应的构建产物。

一切正常后，我们先去 https://pypi.org/ 进行相应的设置。如果没有账号，可以先注册一个。

pypi现在支持通过“受信任”的发布者进行自动化构建。我们这里使用Github平台进行配置。

进入 Trusted Publisher Management · PyPI，找到Add a new pending publisher，

添加之后，我们在项目中添加.github/workflows/publish.yml。注意yml的文件名需要和上一步的对得上。

工作流文件，可以参考下面的写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

name: Publish Python Package to PyPI when a Release is Created

on:
  release:
    types: [created]

jobs:
  pypi-publish:
    name: Publish release to PyPI
    runs-on: ubuntu-latest
    environment:
      name: pypi
      url: https://pypi.org/p/<name> # 改成前一步设置的项目名称
    permissions:
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: "3.13" # 改成需要的版本号
      - name: Install dependencies
        run: |
          pip install uv
      - name: Build package
        run: |
          uv sync
          uv build
      - name: Publish package distributions to PyPI
        uses: pypa/gh-action-pypi-publish@release/v1

这里设置的是在Github上创建Release时触发构建，所以构建时，需要去项目的Release中手动创建一下。工作流也可以更改为检测到tag推送后触发，读者可以自行更改。

成功推送到pypi上后，你就可以使用下面的方式在客户端中调用了：

1
2
3
4

"command": "uvx",
"args": [
  "<name>",
],

分享

想要把你的MCP服务器推荐给别人？我整理了几个常见的mcp检索平台，在这些地方上提交你的服务器，可以让更多用户发现并体验你的服务器。

1. https://glama.ai/mcp/servers ，和 punkpeye/awesome-mcp-servers: A collection of MCP servers. 相关
2. https://mcp.so/

参考

Introduction - Model Context Protocol

PyPI · The Python Package Index

Publishing a Python Package from GitHub to PyPI in 2024

https://pypi.org/manage/account/publishing/

https://github.com/punkpeye/awesome-mcp-servers

ChatGPT alternative for power users

Building and publishing a package | uv

一些事实：

1. 大语言模型的迅猛发展，让较高水平的智能（具体说是人类知识的深度和广度）对普通人来说更加可及与廉价。
2. 人脑想要形成概念，并且习得概念之间的关系，也就是知识，往往需要从一些具象的例子入手，这样比直接试图理解抽象的知识（例如数学书上晦涩的定理）更加轻松。
3. 人在掌握概念以及知识之前，难以举出符合该规律的例子，这是一个先有鸡还是先有蛋的问题。
4. AI技术诞生之前，想要借助具象的例子进行学习，只能通过预先编好的例子。例如，数学上的例题。然而，这些例子的编写者（例如，大学教授）是普通人难以遇到的，也无暇针对一个具体学习者的疑问进行答疑。

总结一些高质量提问的方式：

1. 让AI给自己出题
2. 让AI针对自己的疑问进行解答
3. 让AI了解自己的知识掌握情况和其他背景，个性化地给出建议、回答
4. 让AI高屋建瓴地给自己描述一下知识图谱的全貌，或者规划学习路径
5. 让AI给自己举出几个实例，这里面包括正确的和错误的例子
6. 借助AI知识的广度，将多个领域的知识进行碰撞，探索之前没想到的可能性
7. 让AI评价自己对问题的理解，进行“对拍”
8. 让AI设计有趣味的学习方式，增加学习的动力

上面的这些方式，大多是没有LLM，就难以做成的事情（例如随时找一个大学教授、行业专家给你答疑）。相较于以往的传统学习方式，相当于“跳步”了。可以预见的是，在未来没有一成不变的职业。懂得AI时代与传统时代学习方式差异的人，才可能比其他人学得更快更好。

最近对投资比较感兴趣，前前后后阅读了不少投资相关的书籍和文章，也看了投资理财博主的视频、听了点财经播客。对于普通人来说，合理规划的长期投资，还是有机会实现财务自由的，至少也能让生活舒服一些。复利的力量是非常强大的，趁现在还年轻，尽早规划起来。

我开始找一下网上有没有现成的长期投资计算工具，帮助我决策和规划。确实有，但是功能都比较单一，可自定义程度达不到我的要求，例如只能计算单一标的，不支持多标的的综合规划；只能看累积金额，不能查看逐年的投入/收益；没有考虑收益率的波动（这个暂时也没做，挖坑）……

于是，连夜借助Cursor的力量，顺带是学习一下React以及一些框架，搞出了一个工具。欢迎感兴趣的网友体验、提建议！如果觉得好用的话，也希望您赏个赏个Star~

Github Pages 在线体验

Github 开源仓库

特性

• 📊 交互式投资组合配置
• 📈 多维度收益可视化（总资产/投资金额/利润分析）
• 💾 本地存储投资配置和个人信息
• 📤 CSV数据导出功能
• 📱 响应式图表设计
• 🛡️ 纯前端实现，保护用户隐私

技术栈

• 前端框架: React
• UI库: Ant Design 5.x
• 图表库: ECharts 5.x
• 构建工具: Vite

更改快捷键的位置：

查看VSCode中指定快捷键的功能：

Cursor 专属：

快捷键这个东西，不需要强求，选自己用的顺手的就行了！不习惯的就去他的吧！

为了实现这个目的，有两种方式：git merge 与git rebase。这两种方法分别是什么，改用哪个？

下面用一个具体的例子来说明：

首先，假定我们已经开发了feature 1的两个任务：

然后我负责的团队需要完成feature 2的开发。我们已经完成了feature2 的部分任务，但是现在其他团队突然在feature1发现一个重要的bug，并且把它修复了，而这个修复又影响到我们feature2的开发。因此局面就变成这样：

我们在继续开发feature2之前，必须整合主团队的bug修复。这时候就有两种方式：

方法1:git merge main

这将main分支的bug修复改动合并到了我们的feature2分支，在我们的分支上额外创建了一次提交：Merge branch 'main' into feature2。

我们继续开发，完成了feature2的开发任务，并将此分支最终合并到main分支。

此时feature2分支和main分支是完全一致的。我们发现，main 分支的 bug修复提交通过 merge 提交添加到了 feature2 分支，merge提交实际上是两个分支交汇的节点。这样的好处是保留了所有的细节，但坏处是在主分支里面会出现额外的merge提交。

方法2：git rebase main

回到这一步。同样，我们需要先把main分支的改动同步到我们这个feature2分支，再继续开发。

我们在feature2分支执行git rebase main ：

Rebase的本质是重写历史，相当于把feature2分支的改动”移植”到更新后的main分支。这一点会改动我们分支task1、task2的提交时间戳。

继续完成task3:

然后将其合并到main分支

运行git merge feature2 后，可以发现提交记录是一条直线。这是因为使用rebase后合并到main时，由于历史已线性化，会触发Fast-forward合并，不会产生额外合并提交。

应该如何选择merge或rebase？

下面这个表格总结了merge和rebase的比较：

merge虽然会产生合并提交，让历史记录变得复杂，但是它保留了完整的分支结构，便于代码审查和问题追踪。

而rebase虽然会让历史线性化，便于管理，但是它可能会改写提交历史，导致基于原来历史开发的其他人产生误解。

如果你的分支有多个人在做，那么你rebase并强制推送到仓库，是非常不好的。因为rebase相当于改写了你这个分支的历史，会导致基于原来历史开发的其他人产生误解。

使用rebase的黄金法则是：只对「未推送」的本地分支使用 Rebase。换句话说，如果一个分支已推送到远程且可能被他人使用，那就不应该使用rebase并强制推送。

参考

Git Merge VS (Scary) Git Rebase

本教程仅提供一种解决思路。如果您有更好的免费解决方案，欢迎在评论区告诉我们。

⚠️对于付费视频，需要保证账户有观看权限。

工具配置

Step1 安装yt-dlp

方法1：直接下载二进制文件，需要自行配置环境变量

以Windows为例

https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp.exe

方法2：通过Python下载

1

pip install -U yt-dlp

使用 yt-dlp --version 来验证是否配置成功：

1

2025.01.26

Step 2 获取油管cookie

安装插件Get cookies.txt LOCALLY - Chrome 应用商店

在油管点击扩展，下载Cookie为Netscape格式的txt文件。

注意⚠️：笔者在尝试的时候，如果网页端油管打开，可能会造成cookie刷新，导致原来获取的cookie失效。可以使用一个不常用的浏览器或是开无痕模式，获取cookie。

下载命令

需要自行配置网络环境。更多关于yt-dlp的命令和参数，可以查看：

yt-dlp/yt-dlp: A feature-rich command-line audio/video downloader

执行下面的命令：

1

yt-dlp [列表URL] -f mp4 --cookies [cookies.txt的路径]

例如：

1

yt-dlp https://www.youtube.com/playlist?list=PLZHQObOWTQDOMxJDswBaLu8xBMKxSTvg8 -f mp4 --cookies youtube.com_cookies.txt

随后程序就会自动下载视频列表中的所有视频了。视频默认位置是当前目录。对于付费视频，需要保证cookie账户有观看权限。

不知不觉，开始写博客已经一年多了。写博客是一种凝练知识的方式，是传递知识的一种方式，也是和网友交流的一种方式。

• 凝练知识：撰写博文是一种重新组织某些逻辑的过程，能够加深自我对知识的理解。从自己了解知识，到能够讲述给读者，让其看懂你的想法，这就是一种进步。也就是所谓的“费曼学习法”。
• 传递知识：我会将我日常遇到的一些问题的解决方案（尤其是网络上我查找过后没有方案，自己摸索解决的），分享到博客上。这么做相当于是丰富整个中文互联网的内容吧，让我更惊喜的是，不少文章确实帮助到他人来解决这个问题，他们在博文下面评论感谢我，非常感谢他们，让我的价值感提升了。

感谢所有在过去一年阅读我的文字的读者。

下面从几个方面回顾一下博主的2024。

博文

去年印象最深刻的就是尝试编写了《寻觅周刊》，旨在让更多人了解一些趁手的工具、有用的资源和优质的信息源。不幸的是，该周刊只进行了6周就草草收场，主要原因还是自己对做这件事情的本质认识还不是非常充分，把分享从一种权利变为了一种义务。分享让我快乐的是分享的结果，而不是过程。

特别感谢一位使用邮件和我交流的网友，TA给我分享了一些建议，比如说降低自己对这类文章的期望，让我受用很多，更加深了我原先的想法。

其次一篇文章是我写的面向小白的《浏览器扩展逆向指北》。这是我有史以来写的耗时最长的一篇文章，还依稀记得是从早上写到太阳落山。虽然文章的技术性和专业性并不强，但是能够帮助一些和我一样的技术小白大致了解这个过程，也是挺有收获的。这篇文章我也发布到linux.do，并且很幸运地被站长加上了精华。

另外，2024还试着运营了一个TG频道，主要分享一些浏览器插件的逆向资源和实用的插件推荐，里面会随缘推送一些我认为好用的插件。

项目

2024 算是迈出做简单项目的一小步，主要有：

• shiquda/wereadcard: 微信读书卡片生成器 基于Python的微信读书卡片生成器，支持GitHub Actions自动更新。
• shiquda/one-competition 和小组同学一同完成的课设，技术栈是Vue.js+Django，网站主要展示大学生的竞赛信息。有计划以后修改一下，依托Github平台做成一个由开源社区维护的大学生竞赛信息汇集平台。
• shiquda/crypto-monitor: A simple cross-platform crypto monitor that monitors the price of crypto currencies. 桌面端的加密货币盯盘小工具，基于wails。

参与了以下开源项目的贡献：

• RSSNext/Follow: 🧡 Follow your favorites in one inbox
• Ac-Wiki/AcWiKi: 属于大学生群体的真·青年大学习
• word-hunter/word-hunter: Discover new english words you don’t know on any web page

阅读

读书，是一种和比你层次更高的人交流的捷径。

我喜欢使用电子书阅读。一是方便，抄起手机等点子设备就能读；二是能够“量化”自己的知识，画线和想法能够导出为文本，减少重复的脑力劳动。这一点不只让我有“虚假的成就感”，也能利用readwise等平台来汇总回顾。

2024年，我在微信读书阅读了139小时。

读完书的有：

• 《打开心智》：讲述人的心智的运行机制。
• 《昨日的世界》
• 《置身事内：中国政府与经济发展》：讲述中国政府和经济的关系，以及他们的运行逻辑。
• 《认知觉醒》
• 《邓小平时代》
• 《博弈论究竟是什么》：一本通俗的博弈论入门小册子，挺有意思，它能让你发现原来生活中很多地方都潜藏着博弈论的运用。
• 《乌合之众》
• 《学会提问》：其实是一本讲述批判性思维的好书。
• 《在峡江的转弯处：陈行甲人生笔记》：一个鲜活而生动的人，清廉而官至县委书记，又离开官场投身慈善。有几章令人落泪。
• 《局外人》
• 《提问的智慧》

没看完的，但认为是好书：

• 《为什么》：因果推断科学
• 《吴军：信息论40讲》
• 《日本史》
• 《财富自由之路》

在读/准备读的书：

• 《郭建龙“密码三部曲”》
• 《社会契约论》
• 《黄仁勋：英伟达之芯》
• 《可能性的艺术：比较政治学30讲》
• 《真需求》
• 《见证逆潮》
• 《为什么我们总是在防御》

播客

播客是我在下半年接触到的一种对我来说全新的媒介，到现在也算听了将近半年了，思考见《播客的独特之处》。

分享一些我认为优质的播客：

• 社会类：
  • 《忽左忽右》：历史与社会
  • 《半拿铁 | 商业沉浮录》
  • 《虚实之间》
• 投资财经类：
  • 《三点下班》
  • 《投资实战派》
  • 《知本论》
• 访谈类：
  • 《无人知晓》：里面有一集采访了前面提到的陈行甲先生，看完书再听那期节目，真的感觉陈先生是一个非常鲜活、坦率、令人尊敬的人。

2024++

展望2025，我认为最重要的今年目标的主题是：行动。

“为什么我们懂得很多道理，却依然过不好这一生？”我觉得很重要的一点原因，是没有下定决心去迈出的第一步，以及持续的后续执行力。我自认为是一个三分钟热度的人：什么都了解一些，做事情刚开始很有热情，但是这种热情很容易因为无情的时间而消散。我希望我能在2025年中找到答案。并且是行动的答案。

Zotero是一款开源免费的科研文献管理工具，其插件生态非常丰富，用以进行科研活动十分方便。但是博主使用的时候，有一点让我非常不习惯：在文献中经常需要进行跳转，例如点击目录、参考文献等，跳转时候需要返回的时候，就只能用鼠标点击上方的返回按钮，不能像浏览器等其他软件一样使用鼠标侧键返回。

受网友启发，使用AHK编写一个简单的脚本，就可以把鼠标侧键映射到为返回的快捷键了，对我来说用起来十分顺手。

Zotero 和 autoHotKey 的使用方式不再赘述，烦请读者自行查阅了解。

代码

1
2
3
4
5
6

#Requires AutoHotkey v2.0

#HotIf WinActive("ahk_exe zotero.exe")
XButton1::Send "{AltDown}{Left}{AltUp}"
XButton2::Send "{AltDown}{Right}{AltUp}"
#HotIf

在Windows端，若想开机运行该脚本，将该.ahk脚本文件放置在shell:startup目录下即可。

• S: Situation，背景信息
• T: Task，任务目标
• A: Audience，受众
• R: Requirements，输出要求

在提问的时候，给LLM（大语言模型）提供上面四个不同维度的信息，可以让LLM生成更优质的回复。

举一个例子：

提问：

1
2
3
4
5
6
7
8
9
10
11

介绍一下下面的概念：
附加律
化简律
假言推理
拒取式
析取三段论
假言三段论
等价三段论
构造性二难
构造性二难（特殊形式）
破坏性二难

回答：

这些概念主要来自逻辑学，尤其是命题逻辑和推理规则。以下是它们的简要介绍：

1. 附加律 (Addition)
   附加律 是命题逻辑中的一条推理规则，形式为：

• 如果 ( P ) 为真，那么 ( P \lor Q ) 也为真，无论 ( Q ) 是什么命题。
• 即：从 ( P ) 可以推出 ( P \lor Q )。

2. 化简律 (Simplification)
   化简律 是命题逻辑中的一条推理规则，形式为：

• 如果 ( P \land Q ) 为真，那么 ( P ) 为真，且 ( Q ) 为真。
• 即：从 ( P \land Q ) 可以推出 ( P ) 或 ( Q )。

3. 假言推理 (Modus Ponens)
   假言推理 是命题逻辑中的一条基本推理规则，形式为：

• 如果 ( P \rightarrow Q ) 为真，且 ( P ) 为真，那么 ( Q ) 为真。
• 即：从 ( P \rightarrow Q ) 和 ( P ) 可以推出 ( Q )。
  ……

这些推理规则在逻辑推理和数学证明中非常有用，帮助我们从已知的命题中推导出新的命题。

使用STAR优化的提问：

回答：

好的，同学们，期末备考紧张吧？别担心，我来给你们“翻译”一下这些离散数学的概念，保证你们笑出声的同时还能记住！

1. 附加律：
   这就像你已经有了一包薯片，但你觉得不够，又买了一包。逻辑上就是：如果你知道A是真的，那A∨B（A或B）也肯定是真的。反正A已经在了，B来不来都无所谓，薯片已经到手了！

2. 化简律：
   这就像你买了一堆东西，结果发现只用了其中一样。逻辑上就是：如果A∧B（A和B）是真的，那A肯定是真的。别管B了，A已经够用了！

3. 假言推理：
   这就像“如果今天下雨，我就带伞”。结果今天真的下雨了，那你肯定带伞了。逻辑上就是：如果A→B（A推出B），且A是真的，那B也是真的。别淋雨了，带伞吧！

……

怎么样？是不是感觉这些概念没那么可怕了？记住，逻辑就像生活，有时候选择多了反而简单！加油备考，你们一定能行的！

使用Deepseek官网的默认模型对话进行测试，效果差异非常明显。

提示词优化输出的本质

相信你应该有听说过提示词能够优化输出。比如说：

假如你是一个经验丰富的Python程序员。现在请你xxx……

这样的“套路化”的提示词，似乎是能够提升一些回复质量的。

现在主流厂家的LLM也在不断的进步。不少产品已经能够自动对用户的需求进行预测和优化了，由提示词带来的提示的边际效应已经初步显现。那么，在这样的情况下，写好的提示词的意义是什么呢？

我认为从本质上来说，优秀的提示词能够给LLM提供更多的信息，这些信息能帮助LLM生成更符合用户预期的内容。

很多用户会觉得LLM“不懂我”，但是其实有可能是用户并没有提供给LLM足够多的背景信息。LLM又不是他们肚子里的蛔虫，怎么会知道用户的具体需求呢？😄

这样不麻烦吗？

你可能会问，每次提问都这么写提示词，不觉得很麻烦吗？

这个问题的答案取决于你的需求。如果是比较简单的问题，比如说你只想让LLM作简单的翻译，让你能够看懂就行了，那确实并没有太大的必要。

但如果是相对重要一些的需求，比如说帮你润色文稿之类的任务，那我还是推荐这么写一下。毕竟一次让LLM获得让你更满意的回复，总比多次去调教好。

参考

【进阶教程】一套连招，彻底释放AI的写作能力_哔哩哔哩_bilibili

很多人都想赚钱。我们暂且不谈赚钱是为了什么，只从赚钱这个行为本身，探讨一下“赚钱”与“赚钱”之间的区别。

Level 1：1份劳动->1份回报

说到赚钱，大部分人所做的工作，实质上应该都属于这一类：1份劳动->1份回报。也就是说，付出的时间和精力，譬如说上一天班、送一份外卖，可预见地只能获得一次回报。

虽然说工作与工作之间的收入差异是巨大的，但是它们都没有更大的“想象空间”，本质上来说还是劳动和回报的直接交易。

Level 2：1份劳动->x份回报

有一些工作可能有这样的属性：做出1份劳动之后，收到的是多次回报。而这种回报往往具有不确定性，这意味着它的想象空间是巨大的。这里不包括除了领工资，还拿奖金、津贴之类的情况，这些情况从本质上来说，还是属于可预见的范畴。

举一个例子，从大的说，公司申请一份专利，就可以不断靠收授权费获利；从小的说，一个独立开发者开发了一个软件，以此收费盈利。这两个例子中，获利的预期是未知的，而劳动的主体在劳动之后，不需要再次劳动（或者仅需要付出极低的成本），即可获取多次收益。

我自己的一个简单经历是，在网上搜集了一些资源（资源还是有一定付费门槛的），上传到各个网盘里面，然后挂到闲鱼上面卖。除了我搜集资源付出的时间和精力以外，我付出的后续成本就是闲鱼发货机器人的订阅成本：120一年。两个月内，仅一个商品，我就已经收回成本，并且盈利了数倍。数额虽然不多，但让我体会到了1份劳动->x份回报和1份劳动->1份回报的区别。

其实开发发货机器人的做的工作，和我是类似的，开发的成本可以获得x份回报，后续只需要一些服务器的维护成本和更新成本就行了。他们先前付出的劳动，仍然会在数年后继续为他们赚取收益。

Level 3：1份回报->x份回报

看到这个标题，可能会比较差异：怎么回报也能赚取回报呢？当然了。

这种是真正赚大钱，甚至影响世界金融格局的方法：钱生钱。世界上许多富豪和金融巨头正是通过这种方式积累了巨额财富。钱生钱的核心理念在于通过各种投资手段，让你的已有资金不断增值，而不是单纯依靠劳动->回报的简单交换。

复利被称为“世界第八大奇迹”，其威力在于不仅本金在增长，利息也在不断产生更多的利息。

举例来说，假设你投资了100万元，年利率为10%，一年后你将获得10万元的利息。如果将这10万元的利息继续投资，第二年你的总资本将增长到121万元，而不仅仅是110万元。长期来看，复利效果会让你的财富呈指数级增长。

当然，这种做法的门槛和风险绝对不是普通人能够驾驭的，能够赚到钱的始终是极少数。

普通人也能做好投资。前提是要有足够的金融储备和经验。学习投资是一项回报丰富的“元投资”。

Level x：投资自我

其实，有一种“稳赚不赔”的买卖，那就是投资自我，提示自我的能力。从功利的角度来讲，这样做能够提升自我赚钱的层级。

当然，这里说的投资自我，不是简单的学一些技术型的技能，比如说去考个普通话二级、计算机二级证书，而是投资那些能够提升自我认知的技能。你怎么样去和别人交往、怎么样去理解这个世界的运行逻辑、怎么样理解个人的意义等等。这项投资带来的回报是未知的，它产生的蝴蝶效应会影响我们的一生。

缘由（请随意跳过）

这几天了解了一下币圈的一些知识，然后也是亲自下场试了下水。手机端对应的交易所APP都有类似悬浮窗的功能，但是电脑端我目前还没有发现一个非常让我满意的，之前只能是浏览器挂着好几个窗口，这样看就不是很方便。

有部分桌面端的这类产品甚至还在Microsoft store上收费，在我花了一点时间破解之后，发现做的真的是一坨，一言难尽的那种。花钱请我用我都不想用😅

周末刚好闲下来，本来是之前已知想要学习Go的，但是一直没有时间实践，突然在我的点子清单里面翻到了这个点子：做一个电脑的盯盘悬浮窗软件。

我想，它最好是比较美观的、跨平台的、轻量级的。

说干就干，周六下午开始过一遍Go的基本语法，然后晚上问了一下AI，哪些轻量级的Go框架适合做这种跨平台的小软件。在一番拉扯之后，TA告诉我使用 Fyne是一个不错的选择。

然后。。。一晚上就白干了。

后来在实战开发时候，我发现这个框架虽然在GitHub上有25k的Star，但是用起来却感觉非常生硬（也有可能是我没深入学吧），并且很多我需要的方法竟然没有（e.g.，最重要的置顶功能）。我查了下，有用户在Issue里面提出了这个建议，但是过了三年了开发者还是没有选择加入这个功能。后面我真得绷不住了，觉得还是问一些真人比较靠谱，于是在Google一番搜索，跌跌撞撞回到了L站（不得不说SEO是真的顶😄）

https://linux.do/t/topic/115324/19

这个帖子，在此对所有参与的网友进行感谢，里面有网友给我指指明了方向：wails。

Wails 是一个用 Go 和 Web 技术编写桌面应用的项目。刚好我对前端相对熟悉，之前也学了一些Vue的皮毛，还算好上手，于是说干就干，我狠心把之前写的fyne全删了，除了后端的api请求一个不留，硬是肝到了凌晨两点，早上七点多起来接着写，写到不久前才算完成。

这里面有一个坑耽搁了我很久。因为我想要做跨平台的一个桌面端软件，而我只用Windows和Linux环境，没有MacOS环境，因此打算利用GitHub Actions来打包。但是我对Actions也说不上多熟悉，更重要的是对MacOS的特性（例如，软件是如何安装的、打包的）一无所知😅，于是这个地方调了十几次才跑通。GitHub Actions 一直没找到一个很好的方法来调试，我只能不断地试错，然后问Cursor，根据可怜的输出来不断重试，而每次重试都需要经历三四分钟的build时间。

虽然Windows的安装包好像还有些问题，似乎和可执行文件是一样的，但是可执行文件算是还能跑。还是先这样吧，能跑就行，等我缓过来啥时候想写了再改。。

介绍

最终这个小Widget的雏形终于是完成了：

技术栈：

• Wails
• Vue

现在的功能还比较简陋，除了基础的置顶、最小化和关闭，只有简单的添加和删除币对的功能。后续会考虑再加其他功能的（挖坑）。

更多细节可以前往Github查看。喜欢的可以赏个Star~

下载：

https://github.com/shiquda/crypto-monitor/releases/

限于博主的技术水平，难免有不少问题，有任何意见和建议也可以随意提出，会抽空改进的~

后记

偷偷开了个新树洞：cry.shiquda.link

对播客这个概念，我也记不得是什么时候开始听说的，属于是只知其名，未见其形的那种东西。总之从结果来看，我在是在大概一个月前开始真正亲自收听一些播客节目的。在不断的收听过程中，也有一些即兴的想法，遂记录一番。

什么让播客如此独特？

形式恰到好处

在我眼里，播客是一种形式上处于中间形态的信息传播媒介。在接触之前，也许感觉播客有一些另类，认为它的定位有些不上不下，既不像视频那样有意思、易懂，又不像文字那样显得直接、朴素。但是真正亲自接触后，听着听着发现，恰恰是在生活中的一些受限于时空的碎片化时段，在可能不太适合阅读文字或是观看视频的时候，也许听播客是一个比较不错的选择，比如开车、地铁、走路、做家务甚至睡前等。

仅从结果来看，我认为播客填补了介于文字和视频媒体之间的一个“真空”区。从信息量（注意，区别于信息密度）来看，应该是视频＞播客＞文字。文字更适合一个人在相对静态的时候进行阅读和感悟，视频则更加大众化，信息量更高，理论上可以包含画面、音频、文字等形式，但往往也会导致了信息密度较低。其实一些信息密度主要不是由其画面提供的视频，我也会当作播客来听。

举一个例子，对于文字，我们可以进行方便的检索，甚至使用大模型进行总结，而对播客进行总结，难度较高，如果使用语音转文字工具的话，难免会丢失不少文字以外的信息。更不要说对视频进行浓缩和总结了。视频的信息分布在多个维度，可能丢失的信息之大，可想而知。

文字、语言，这两个概念之间还是有显著的区别的。文字，是一种符号，本质来说是一种对信息的单维度的朴素编码。而在和别人说话的时候，除了提供文字信息以外，还包含了语气、神态、动作等更多维度的信息。应该来说，语言的信息量是远大于文字的。

人与人面对面交流的时候，信息量是最大的，播客虽然无法看到对方的神态、动作，但是还是能通过对方的语气、反应等特征，获得更多维度的信息。

总结一下，播客这种看似尴尬的中间形态，却很好的填补了生活中获取信息的时空空白区域。

亲切感与沉浸感

从我自己的角度来看，收听播客，不管节目中是单个人在讲“单口相声”，还是多人进行访谈，都有一种亲切感，仿佛自己就坐在演播室旁边“偷听”，这让我更加容易接受播客的信息。有人可能会说，那视频类访谈，不是更逼真吗？我觉得，画面信息的缺失，其实在某种程度上是一种留白，能让你更加专注，以“弥补”这种画面的缺失，同时让你更注重于内容本身。

从我个人体验来说，一个能支持这种观点的现象是，我在听播客的时候，很少使用快进功能，这一点与视频截然不同。这或许在一方面和不便点击快进有关，但另一方面，我确实感觉自己更注重于内容本身了。

信息质量较高

有网友认为是一种“精英”媒介，说听播客的人往往都是收入程度和教育程度相对较高的人。至少从我听到的来看，内容信息质量高的不在少数。

每个人可以选择自己感兴趣的领域，选择一些自认为不错的节目，利用播客软件进行订阅，思想和RSS有些类似，从技术上来说也是使用RSS这样的手段实现的。这实际上也是一种对推荐算法说不的手段。

并不是说收听播客，和刷短视频相比，好像是多么“高人一等”的事情：这只是两种获取信息的不同媒介。但是事实上，了解播客是什么，并且愿意尝试的人，至少在中国，还是比较少的。这就引出了另一个方面：普及率。

普及率低

在美国，收听播客其实是一件比较普遍的事情，有一半左右的美国人会收听播客。从环境生态上来讲，大平台如苹果、Spotify等，也掌握了不少播客的资源。而在中国，受众面则明显小得多。从创作者的角度来看，也还没有像海外那么成熟的盈利模式，这意味很多播客很难持续产出。这点从我发掘优质播客的时候，翻找往年的推荐文章，却发现不少已经在几年前停更，可以得到映证。

写在最后

以上是我初次尝试播客这种媒介后的一些随想。不出意外的话，我想我是获得了一个不错的新的信息来源，在可预见的未来也会继续听听。如果你还没有接触播客的话，不妨也试试，看看这种媒介符不符合你的口味。

这个帖子是我在V2EX发出的一个播客征求贴，收到了不少热心网友的优质播客。如果感兴趣的话，也可以看看。

如果你使用安卓手机，可以尝试一下AntennaPod这款播客软件，免费开源，简洁好用。

本期是寻觅周刊的第6期。同时也很可能是最后一期。

寻觅周刊是我的一次大胆尝试，一个多月前我萌生了这个朴素的想法：

用尽可能少的时间，获取到尽可能优质的信息。

但是，随着一周周更新节点的到来，从功利的角度来说，我发现这样做让我变得很被动，而且我从中并没有受益很多。

从功利的角度来说，撰写一些技术类、思考类文章，做这些工作会让我收益：这是费曼学习法的一种体现，也就是说分享的主体在教中学，受益的是作者和读者双方。

然而，寻觅周刊这类优质信息的汇集，从某种意义上来讲，是没有创造性和门槛的，在整理的过程中，我也很难从中受益。

在刚创办之初，我会留心当周见到的优质信息，并且进行记录，再到周末进行撰写和分享。然而，经过无情的时间的考验，当初的那种分享的热情被雪藏了，从热情转变成了一种被动地“赶工”，从我的一项权利变为了义务，尽管没有任何人要求我这么做。

在那一刻我意识到，应该对读者说声再见了。

我意识到，其实我享受的是分享的结果，而不是过程。能够让更多人找到优质的信息，这让我很快乐，但是我不愿意承受的，是分享的过程。这二者很难权衡。

也许是“周刊”限制了我。从自己的私利看问题，也许我需要的是即时的分享、即时的快乐吧。停办周刊不意味着我不再喜欢分享，我认为我也许需要切换一种形式，比如运营一个Telegram频道，撰写公众号文章，或者是其他暂时没想到的形式。我想要在认为时机成熟之后，能立即分享。希望能够再次和读者见面。

感谢您的阅读。不管您是周刊多期的读者，亦或是初次相逢，请允许我向您表达谢意和歉意。

👋

欢迎订阅本周刊的RSS。

ℹ️信源版

🐑Yummy’s Blog：分享流媒体订阅、薅羊毛等信息

Yummy’s Blog 各类教程资讯整合

韭菜生活：分享投资、金融知识

韭菜生活

📂资源版

本期无资源推荐。

🔧工具版

Vimium C：像Vim一样操作浏览器

Vimium C - 全键盘操作浏览器 - Chrome 应用商店

本期是寻觅周刊的第5期。

给本周刊起标题真是一个难活。周刊的性质就决定了，每期分享很难有一个“主题”，因此在考虑要不要删除这个形式上的“主题”。本期暂且使用“emoji”吧。详情见后文。

欢迎订阅本周刊的RSS。

ℹ️信源版

🤖AIGC weekly：AI 热爱者的周刊

AIGC weekly 是一个关注于最新 AIGC 领域的周刊，聚焦于国内外 AI 领域动态、模型、产品等资讯。

📶RSS

📂资源版

✈️Telegram 资源型频道：寻找资源的好去处

由于 Telegram 上传资源无空间限制，且监管较为宽松，它含有许多资源型频道。因此如果你需要找一些资源的话，不妨考虑一下它。资源以消息的形式存储在频道里面，可以在对应的频道内检索。下面举一些例子：

• 网盘资源
  • https://t.me/addlist/AjEE_tIe5bMzN2Ix
• 破解软件
  • https://t.me/addlist/M-Rpt9N6aLRhMTll
• 杂志周刊
  • https://t.me/readingclubus
  • https://t.me/caixinsharing

觉得不够？更多 Telegram 优质频道/群组/机器人，可以参考以下资源（请读者自行鉴别这些内容的质量）：

• 频道 | TGNAV - Telegram 频道群组导航（NSFW）
• 【热门推荐】5000+ 优质 Telegram 群组、频道和机器人，精心筛选，助您迅速找到最佳选择！ | rectg

建议在加入之后开启消息免打扰。

😍emojifinder：查找 Emoji 表情

读者可能意识到了，本期的标题前面都有一个 Emoji，这是为了方便读者更直观地理解各个条目的性质。

Emoji Finder是一个方便的网站，输入英文关键词搜索，点击即可复制到剪切板。

💻Core Dumped：直观理解计算机系统

笔者最近发现了一个小众 Youtube 频道：Core Dumped，使用动画讲解计算机系统的底层原理。

🔧工具版

➗SimpleTex：提取 LaTeX 公式

SimpleTex是“一款方便且好用的公式/文档识别编辑软件平台”，可以识别图片/PDF文档中的 LaTex 公式，并支持导出为LaTeX、Markdown、Word和图片，目前登录即可免费使用，也可以付费调用 API。

下面是识别的结果，还原度还是不错的。

$$
19.\text{ 设随机变量序列}{X,|\text{独立同分布 },\text{且 Var}(X_n)=\sigma^2\text{ 存在 },\text{令}\\overline{X} = \frac{1}{n}\sum_{i=1}^{n} X_{i} ,\quad S_{n}^{2} = \frac{1}{n}\sum_{i=1}^{n} { X_{i} - \overline{X} }^{2} .\\text{试证}S_{n}^{2}\xrightarrow{P}\sigma^{2}.
$$

🛜gping：ping，但是用动画

gping是一个支持多平台（Windows、Mac 和 Linux）的 ping 程序，支持在命令行中动态绘制多台主机的 ping 时间图。

测试一下本站 gping shiquda.link：

🚫Test Ad Block：检测你的广告拦截器

Test Ad Block是一个检测浏览器广告拦截器功能的网站，开源于GitHub。

看来支持 Manifest V3 的uBlock Origin Lite表现还不错😄

如果您喜欢我的内容，欢迎评论，让我有继续写周刊的动力；如果您对本周刊有所建议，同样非常欢迎您的评论！

谢谢♥️！

基本概念

什么是浏览器插件？

浏览器扩展(Browser extension)，俗称（浏览器）插件，它实现的功能很多，例如修改网页、拦截与修改请求、控制浏览器等等。一般来说，浏览器插件都是基于HTML/JS/CSS的，也就是“前端三件套”。它们利用浏览器提供的接口，实现各种功能。

在大多数情况下，基于 Chromium 内核的插件只需要少许修改就可以在 Firefox 中运行，且 Chromium 系的浏览器插件生态更佳丰富，因此文章后面部分的介绍都基于 Chromium 系的浏览器。

插件安装包里都有啥？

部分读者可能注意到，我们安装浏览器插件，实际上浏览器下载的是一个.crx文件。这个.crx文件并不是二进制文件这样经过编译的文件，它实质上就是一个压缩包。如果你把它的后缀改为.zip，解压软件就能读取里面的内容。

解压之后，我们就能看到插件的各个文件了。一个简单的的插件目录结构如下：

1
2
3
4
5
6
7

|-- 插件目录
    |-- manifest.json
    |-- popup.html
    |-- background.js
    |-- content.js
    |-- options.html
    |-- ...

插件的.js、.html、.css等文件，也可能包含在子目录中。

下面的内容假设读者对.js、.html、.css等有一定的了解。简单来说，.html是网页的骨架，.css是网页的衣服，.js是网页的灵魂。

我们主要关心的是下面几个（类）文件：

• manifest.json：配置文件，包含了插件的名称、版本、权限等信息，类似于安卓的AndroidManifest.xml。
• background.js：后台脚本，在后台处理插件的交互，负责处理插件的全局逻辑。
• content.js：内容脚本，是插入到页面中的脚本，可以用来修改页面内容、拦截请求等。

其中manifest.json中会指定background.js、content.js等文件的路径，而一些.html文件往往描述了插件的UI界面，在这其中也可能插入一些.js、.css等脚本或者样式文件。

什么是逆向？

在本文中，我们讨论的“逆向”实质上是“破解”的一件漂亮外衣。如果你曾经有一些逆向经历，或者是听说过一些，可能对逆向的印象是这样的：

但是事实上，浏览器插件的逆向可比这个简单多了。它大概是这样的：

直观点来说，就是从几（十）万行被压缩、混淆的晦涩代码中，抽丝剥茧，利用搜索工具找到关键代码，并且进行（往往是很简单的）修改，实现解锁会员功能等目的。

当然，这对有一些代码功底的读者来说，可能并不难，但是实际上，想要实现破解，仍然需要一些方法和技巧。本文的主要任务就是基于笔者的经验，告诉读者一些方法与技巧，让你少走弯路。

所有插件都能破解吗？

其实不一定。如果插件的功能主要依赖于云端（例如，沉浸式翻译），且云端做了身份验证，那么本地破解的能做的很少。

但是，对于一些功能依赖于本地代码，云端只是负责进行会员身份校验的插件，这种往往就能够破解。可以进一步说，这样的插件一定是可以破解的。

但事实上，我们还应该关心的是：这个插件值得我花时间去破解会员功能吗？与付费购买/订阅相比，我的得与失是什么？

就像给账号设置传统的密码一样，理论上不存在完全无法破解的密码，设置密码其实是在方便性和安全性之间的一个平衡。从破解者的角度来看，当破解所需的成本大于收益之后，没有人会做这样出力不讨好的事情。

因此，在进行破解一个插件之前，请好好想一想这给你带来的得与失。

逆向知识与工具

必须项：

• 浏览器：你得有个浏览器吧。。。
• JavaScript基本语法
• IDE：用来实际修改代码的工具，推荐使用VSCode类编辑器

可选项：

• HTML/CSS
• 调试工具的使用：Chrome DevTools
• 正则表达式：用于匹配代码或者批量替换
• Git：用于管理破解的记录，便于回溯
• 代码可读化与反混淆工具，后面会介绍

JavaScript 基本语法

如果你想要破解一个浏览器插件，你最基本来说需要对 JavaScript 有一定的了解，知道一些常见的js语法，例如：

• 有哪些变量类型？
• 什么是函数？
• 什么是对象？
• ……

等等。当然在实战中，有一些知识也是比较重要的，例如：

• 三元表达式
• 强制类型转换
• 异步编程

IDE

推荐使用VSCode，方便代码编辑、替换。

浏览器开发者工具(F12)的使用

如果你会一些基本操作就更好了。实战中不一定用到。

正则表达式

正则表达式是一种用于匹配字符串中字符组合的模式。能够按照指定的规则，找出代码中所有符合条件的部分。

例如，我们查找一个压缩后的代码中，所有类似e.user.vip的代码，就可以使用这样的正则表达式来匹配。

1

[a-zA-Z]+\.user\.vip

Git

Git 是一个分布式版本控制系统，用于管理代码的变更。

其实这个工具不用也罢，但是我在几次实战中，出现过关键代码替换掉，后来出现插件无法运行的情况，这时候大多只能从头再来。如果有Git工具的话，关键的修改前后可以保存，方便回溯。

还有一个优点是，如果插件更新了，你认为有再次破解的需要的话，就可以参照原来破解的流程，把新版本插件的代码一葫芦画瓢，破解出来。

代码可读化与反混淆

拿到插件之后，格式往往没有前面那张图这么清晰，而是被压缩、混淆的。

这种代码当然不是作者故意这么写的，而是写完之后，使用一些工具进行压缩、混淆得到的。

但是根据我的经验，插件的作者往往不会对代码进行非常深度的混淆，一般做的就是把变量、函数、类的名称替换为无意义的名称（一般是很短的大小写英文字母），或者把一些代码替换为更难读懂的形式，比如说布尔值替换为!0、!1，频繁使用三元表达式、布尔值 && (执行逻辑)这样更佳晦涩的方式，等等。但是类的属性等名称往往不会改变，这将成为我们逆向分析的一个重要抓手。

下图是一个典型的代码片段，其中红色方框内是被替换的无意义的名称，绿色的是未被替换的类的属性，黄色是经过转换后的更佳晦涩的代码。

关于混淆的拓展阅读：JS 反混淆 - Jartto’s blog

一般来说，我们使用代码格式化工具对浏览器插件的代码（主要是.js代码）进行反压缩，就可以了开始破解了。Vscode等IDE有自带的格式化方法，但是无法批量对插件的所有代码进行格式化。进行这里介绍一个笔者之前写的Python脚本，能够对整个项目中所有.js、.css、.html和.json文件进行代码格式化。

更建议使用prettier来进行格式化。安装prettier后，在插件目录下，只需要执行一行命令就可以实现格式化：

1

prettier --write .

逆向基本流程

下载插件并安装

下载

下载推荐使用 crxsoso，国内即可访问，且可以直接下载.zip格式的插件包。

安装

测试的浏览器建议使用Chrome，可以新开一个用户资料，专门用于测试。不建议用平时的主力浏览器，这样能够排除其他插件或者脚本的影响。

把安装包解压到一个合适的地方，然后浏览器进入chrome://extensions，开启开发者模式，点击“加载已解压的扩展程序”，选择解压后的插件目录即可。

破解思路

我们最核心的思路就是，找到代码中（往往是在background.js中）判断会员状态的代码，并且修改。

当然我们不可能靠肉眼看完几万行晦涩的代码，而是利用一些技巧，来定位关键的代码。

如果你不确定在哪个文件里面，也没关系，可以使用全局搜索功能，可以对插件目录下所有代码进行检索。

那么，如何定位关键的代码呢？

定位关键代码

我一般使用的思路是两个：

1. 全局尝试搜索vip、会员、pro、premium、subscription等关键词，看是否能找到相应的类的属性，以此为跳板找到核心逻辑，依次进行修改。

2. 从字符串入手，在使用使用插件过程中找到一些和会员相关的字符串，比如说“This is a premium feature”、“您尚未开通会员”、“Free user”等，然后全局搜索这些字符串，查看这些字符串附近的代码逻辑，以此找到核心的逻辑。

一般来说，我更推荐使用第二种方法，这样能够快速定位到关键的逻辑。第一种方法是实在没有头绪的时候，进行尝试的。

需要注意的是，如果文字是中文等非英文字符，那么有可能插件代码中的字符是转义后的字符，如果你搜不到，这时候可以对文件进行转义，或者试着搜索转义前的字符串。

这里推荐一个开发者常用的工具集合Ctools，支持多端使用（包括在线使用、浏览器插件），开源免费，以后在也不用去网上搜xxx在线网站啦😄

搜索转义后的字符串：

修改代码

定位到关键代码之后，大多数修改的方法都是围绕着布尔表达式进行的。

例如，如果代码中有一段逻辑是：

1
2
3
4
5

if (isVip) {
    // 执行会员逻辑
} else {
    // 执行非会员逻辑
}

我们可以把isVip直接修改为true或者1，这样就可以让插件以为你是会员了。当然上面只是一个最简单的例子，实际的代码可能复杂得多，但核心思路都是一样的。

测试

修改完代码之后，需要进行测试。可以找到插件的官网（如有），点击价格/Pricing，此处一般有会员和非会员功能的对比。

实战演示

我们以某插件为例，介绍一下破解流程。插件下载地址

解压安装后，先跑一下反压缩脚本，把压缩饼干展开

发现background.js有足足十万多行。

回到浏览器，打开插件，登录账号后，发现有一个提示，提示我们升级会员。

搜索这个字符串，发现没有结果

于是我们再尝试搜索Unicode 转义前的字符串

1

\u5347\u7ea7\u4f1a\u5458\u4eab\u66f4\u591a\u9ad8\u7ea7\u6743\u76ca

发现一个字符串。

我们再选取这个字符串的父元素名称upgradeToPremiumTitle，进行搜索

在这附近似乎并没有什么有价值的信息，于是想办法找另一个试试。打算从实际功能入手。

点击新建词本，会跳转到开通会员的介绍页面。类似前面的方法，我们搜索“新建词本”，得到名称creatNewWordBook，再次进行搜索

看到一个previlege，这很可能是记录用户是否是会员信息的名称。（实际上后来发现并不是，这应该是判断词书是否是会员专属的属性）

继续搜索，发现有可能是，因为搜到几个有和"VIP"进行判断的表达式。

我们现在需要把所有出现的privilege判断逻辑都进行修改，一个简单的方法是把y.privilg这样的表达式全部替换为"vip"。

等等，在替换之前，先在本地初始化一下Git，方便后续回溯。

直接全部提交即可。

把搜索到的判断逻辑全部修改。

保存修改之后，在扩展程序管理页面刷新一下插件

测试发现，还是不能解锁功能，考虑再找一个突破口。

搜索这个字符串

这是一个三元表达式，我们使用Ctrl + 左键点击Hr函数，跳转到它的定义

看起来像是在验证会员是否过期，我们让它直接返回1。

同时，我们搜索expireAt关键词，发现index.js中也有一个相同的函数，把它也改了。

刷新发现，已经显示是会员了。

假设我们准备破解到这里为止，接下来我们检查一下各项会员功能是否能正常使用。

高级翻译引擎无法使用，肯定是添加了服务端校验，在我们的意料之中。因此使用积分肯定也不行了。

英英词典可以正常使用。

高级/专业词本虽然点击切换不会跳转开通会员的页面了，但是等了半天也没反应。

抓包发现，有服务端校验，暂时先放弃。

高级释义，没找到这个功能，猜测是AI释义。测试发现，服务器同样提示需要升级会员。

AI语法分析，没找到该功能。

无限存储单词这个功能，我在原先逆向的版本中(v3.9.0)，是可以无限添加的，但是该版本竟然不行，超过50个单词之后服务端返回错误信息。

这里就要提到使用Git工具的另一个好处了：上次逆向分析的过程没有保存下来，我完全忘了怎么逆向了💦

我猜测原先版本可能没有进行云端校验，但是抓包分析却发现，二者竟然都需要经过云端验证。

仔细分析二者发现，竟然是他们发送的api接口域名不同，api.relingo.net没有验证添加后是否超过50个免费用户的额度，而cn.relingo.net有验证。于是我搜索了关键字，发现一个关键的名称endPoint，它似乎代表了api的域名。

于是试着修改相关逻辑，使得请求发出的域名固定为api.relingo.net

但是，改了之后还是不行。。。

奇怪了，两个请求的域名也一样，还有什么可能呢？

没办法，只能把两个请求的cURL命令用字符串对比工具进行对比：

发现只有几个细微的区别。不会是因为版本不同吧？我修改manifest.json，把新版的插件版本改回3.9.0，再测试一下，竟然真的可以了。服务端这样的判断逻辑，也是让我没想到😅

于是找到发送版本的参数的代码，将其强制改为3.9.0，测试就可以无限制添加单词了。

例句未测试，我们姑且猜测也可以吧？

导出单词似乎其实是免费功能，导出到Anki需要经过服务端，暂时无法破解。

下面四个功能，创建个人单词本、开启多个词本、词义编辑、学习统计，经过测试，均可使用。

因此，总结一下能用的功能：

• 高级翻译引擎
• 高级翻译引擎积分
• 英英词典
• 高级/专业词本
• 高级释义
• AI语法分析
• 无限存储单词
• 无限存储例句
• 导入导出单词
• 导出到Anki
• 创建个人单词本
• 开启多个词本
• 词义编辑
• 学习统计

逆向与反逆向

逆向“对”吗？

在文章结束之前，我还想从破解者和开发者的角度。讨论一下我对插件逆向这个行为本身的看法。

破解插件这个行为，“对”吗？从道德的角度讲，我认为当然是不对的，这显然侵犯了作者的权益。

因此本教程的初衷是为了普及相关知识，仅供学习交流，不建议随意使用和模仿，甚至以此牟利，因此产生的纠纷与作者无关。

但是从实际情况上来讲，部分插件的定价不合理，导致用户负担不起价格，或是付费渠道的狭窄，使得许多优秀的软件，难以得到它们应有客户。这事实上也对开发者是不利的。在这方面，我认为简悦是一个很好的范例，它的买断制政策与合适的价格，使得很少人有动力去破解它。

我是插件的开发者，怎样能减少破解这种行为？

对于开发者来说，有一些建议供您参考：

使用混淆工具

使用混淆工具，降低逆向者的破解的收益-成本比重。

将产品与云端紧密结合

将产品的功能与云端紧密结合，并在后端设置校验，而不是云端简单地只负责校验。但这也要考虑到产品的属性，以及会增加一定的成本。

合理定价

考虑目标人群的支付能力，合理定价，设置促销、教育优惠等活动。

及时更新

不断更新吸引用户的新功能。因为逆向后的版本无法自动更新，若开发者能不断推出有吸引力的新功能，有需求的用户自然会选择订阅支持，而不是浪费时间找破解资源/进行破解。

考虑开源/免费

😊

参考资料

1. 浏览器扩展 - Mozilla | MDN
2. Chrome 扩展程序  |  Chrome Extensions  |  Chrome for Developers
3. JS 反混淆 - Jartto’s blog

本期是寻觅周刊的第4期。由于国庆假期，本期只有一些工具推荐，见谅~~

欢迎订阅本周刊的RSS。

信源版

本期无信源推荐。

资源版

本期无资源推荐。

工具版

reqable：新一代API调试/测试与抓包工具

Reqable是一个跨平台的HTTP开发和调试工具，旨在为程序开发和测试人员提供高效的接口测试和抓包调试功能。

这个图标是不是很眼熟？没错，这个新产品就是由原来的“小黄鸟”HttpCanary的开发团队打造的。

Reqable是什么?
Reqable = Fiddler + Charles + Postman

这个工具目前有免费的社区版，还提供专业版和企业版。对于心血来潮使用它来做安卓抓包的笔者来说，社区版绰绰有余，而且对Android 14这样高版本的系统来说更佳友好，毕竟老牌的小黄鸟已经不再维护了。

Windows触控板实现macOS的三指拖动功能

ThreeFingerDragOnWindows这个开源软件能够实现使用触控板拖动窗口。该软件已经上架微软商店。

spotube：无须会员的开源、跨平台Spotify客户端

spotube是一个开源跨平台的 Spotify 客户端，它利用 Spotify 的数据 API 和 YouTube、Piped.video 或 JioSaavn 作为音频源，让用户无需购买 Spotify Premium 即可享受高品质音乐。

支持通过Spotify登录，听你熟悉的歌单，但是更好的音质（使用YT music等其他音源），也支持匿名收听。当然没有广告。

缺点是不支持Spotify 节目和播客，以及似乎不支持Spotify的智能随机播放。

PS：如果你遇到代理问题，可以参考这个Issue。

Buzz：易于使用的音频转文字工具

Buzz是一个开源软件，使用开源的 OpenAI 的 Whisper 模型进行音频转文字。它的优点是易于使用，转换效果也不错。

支持导出为txt, srt 或者 vtt 格式。使用Medium模型测试，导出所需时间大概和其时长相当。

json4u：JSON可视化

JSON for you是一个在线的JSON可视化工具。

如果您喜欢我的内容，欢迎评论，让我有继续写周刊的动力；如果您对本周刊有所建议，同样非常欢迎您的评论！

谢谢♥️！

本期是寻觅周刊的第3期。

信源版

IceBeer：独立开发与互联网的思考

🍺 IceBeer - 👋输出我做独立开发和对互联网的一些思考

@Ivone 投稿。给程序员/产品经理或者UX设计师写的关于独立做产品的一些想法和思考，希望能给网友带来一些帮助和新的思考。

Time经济观察：宏观经济|公共政策|金融市场的独立观察

Time经济观察 – Telegram

也可以使用RSSHub订阅其RSS。

资源版

TGwiki：Telegram知识库

TGwiki是一个丰富的telegram知识库，包括常用功能、账号等文档，帮助用户更科学地使用Telegram。

工具版

tabout：用tab跳出括号、引号等

TabOut是一款简单但能改善写代码体验的VSCode插件，它的功能正如其名，使用Tab键来跳出括号、引号、斜杠等代码块，当然也支持自定义匹配的字符。

为什么这样能提升效率呢？道理很简单。

编写代码时，我们经常需要输入大量的括号、引号。现代IDE通常会在输入左括号时自动补全右括号。写完内部内容后，最直接的方法是用方向键跳出右括号，但这需要右手移动较远的距离（例如用小拇指按右方向键）。

其实也有一种折中的方法，就是再手动写一个右括号，但是这又需要按下 Shift ，也需要一定时间。改用Tab键之后，对任何跳出的操作，都可以使用Tab来一键跳出，体验很好。当然适应也需要一定的时间，是否使用全凭读者个人意愿了。

Nilesoft Shell：自定义与美化Windows右键菜单

Nilesoft Shell是一款免费开源的自定义与美化Windows右键菜单的软件。

支持自定义皮肤等功能，下面是我写的一个Dracula风格皮肤。

该软件还有许多其他功能，详情请参阅官网。

SponsorBlock系列：用众包的理念来节省你看视频的时间

下面是众包这个概念的介绍，不感兴趣的读者可以直接跳过。

众包是一种分布式的问题解决和生产模式。问题以公开招标的方式传播给未知的解决方案提供者群体。众包和开源的不同在于，开源是一种通过公众的团员志愿地开创和进行合作性的行为活动，而众包中的行为活动是由某个客户提出，并且以个人或小组为基础来进行的。

SponsorBlock是一个知名的 YouTube 增强插件，它能够按照用户标记的视频片段（如无聊的开头、结尾、付费推广等），自动跳过对应的片段，节省你的时间。

而这些片段都是由其用户无偿进行标记的。这种模式就是众包。理论上来说，使用的用户越多，每个用户的体验也更好。

目前共有 13,033,165 位用户提交了 13,214,226 个跳转片段，这些片段总共节省了 5364 年零 182.59 天的时间。

这个项目本身和其数据都是开源的，因此也帮助了例如YouTube Revance等软件，它们把该功能集成到修改过的APP客户端中。

前不久有网友做出了适用于Bilibili的插件，从原插件移植而来，如果你感兴趣，也可以尝试一下。

chsrc：全平台通用换源工具与框架

chsrc是一款开源好用的全平台通用换源工具与框架。

在中国的开发者应该都对“换源”这个概念不陌生。由于各种原因，访问一些软件包下载源的体验不佳，因此有一些平台（如高校、企业）提供了访问更快的镜像源。而这些镜像源在不同网络环境下的访问体验不一。

chsrc这个工具可以在全平台进行统一的换源操作，支持自动检测各个源的下载速度。

tabGo：自动按照域名分类浏览器标签页

tabGo是一款刚开发新鲜的浏览器插件，能够按照域名来自动对标签页分组。

1. 支持白名单
2. 支持匹配方式，子域名或者是一级域名
3. 支持分组在前
4. 支持自定义分组名称

首次发布于浏览器插件（根据域名IP地址自动分组） - 资源荟萃 - LINUX DO。

笔者用下来感觉体验不错，再给这个插件添加了一个分组设置名称的功能，搭配上期推荐的OneTab插件（现在改用KepTab了，功能类似），管理标签页变得非常舒适。

您是否在使用 Clash？

在线 Clash 检测 (mikewang000000.github.io)

这个开源的网站能够检测你的本地 Clash 等代理软件，看一下是否有潜在的泄露风险。如果被检测，防止泄露的方法详情可见 V2EX帖子 。

如果您喜欢我的内容，欢迎评论，让我有继续写周刊的动力；如果您对本周刊有所建议，同样非常欢迎您的评论！

谢谢♥️！

本期是寻觅周刊的第2期。第一期收到的反馈还不错，因此目前打算继续分享。

与第一期有所不同的是，在原有资源版和工具版的基础上，我还将新添一个版块：信源版。俗话说得好，授人以鱼，不如授人以渔，分享笔者认为较为优质的信息源，也许对读者会有所帮助。

如果您对本周刊有所建议，非常欢迎您的评论！

信源版

如果你使用Follow，可以尝试它的最新功能：订阅我的信息源列表。这里分享了我的部分信息源，包括周刊里分享的信息源。

晚点：晚一点，好一点

晚点 (latepost.com)

笔者认为该平台的报道质量较高，有一定深度。图表绘制精良。

“晚一点，好一点”。

读者也可以关注其RSS订阅源或者Bilibili。

有据：核查中文互联网上的流言

有据 | 国际新闻事实核查 (chinafactcheck.com)

对中文互联网上的国际新闻流言进行事实核查。

如果你有兴趣，还可以阅读该网站编撰的《事实核查手册》，了解基本的核查事实的方法，更好地辨别可能的谣言。

该手册采用CC BY-NC-SA 4.0许可，笔者认为其质量不输于一些出版物。

资源版

有用经验：不知道什么时候会帮到你的经验

有用经验是一个分享生活经验的网站。可以在上面检索生活经验，或者订阅它的RSS。

AMiner：AI驱动的科研信息集合网站

AMiner - AI赋能科技情报挖掘-学术搜索-论文检索-论文专利-文献追踪-学者画像

ML-YouTube-Courses：优质机器学习/人工智能视频课程

dair-ai/ML-YouTube-Courses: 📺 Discover the latest machine learning / AI courses on YouTube. (github.com)

这个文档收集了多个优质机器学习/人工智能视频课程，按照分类整理，含有每个课程的简介和链接。

小林图解计算机基础：不错的图解教程

小林coding

对自学者/有一定基础，但不多的读者比较友好。

需要微信关注其公众号才能在线阅读完整内容/下载PDF。

天涯在线：在线阅读当年的“神贴”

天涯神贴-1999~2024年度榜单-天涯 (tianya.at)

工具版

drawio：开源、轻量但不简陋的图表绘制器

Draw.io是一款功能强大的在线绘图工具，广泛用于创建各种类型的图表，如流程图、思维导图、组织架构图、UML图等。开源于GitHub。

在笔者知道这个工具之前，绘制一些流程图、架构图的时候，可能会使用微软的Visio或者是国产的Processon，但是前者依赖臃肿的客户端，在线编辑体验不佳；后者体验不错，本土化适配很好，可惜不少功能需要付费。

drawio很好地满足了我的需求：使用简单、功能较为丰富、轻量级。

创建图表的时候，可以在其提供的众多免费模板里选择；可以在图标库中检索，任意选择需要的图标；也有自动对齐等功能，强迫症狂喜。😄

drawio还有众多功能，例如保存到Google drive等云盘、免费无水印导出svg、pdf等等。如果读者感兴趣，可以收藏一下，有需要的时候可以亲自体验一下。

今日热榜：各平台的热榜聚合

今日热榜 - 全站热榜

该网站集合了多个平台的热门榜单，可以选择指定平台进行浏览。

uBlacklist：屏蔽传统搜索引擎中的垃圾信源

uBlacklist 是一款浏览器扩展，可以帮助用户屏蔽搜索引擎结果中的低质量网站、内容农场等。

可以订阅黑名单列表：

1

https://raw.githubusercontent.com/cobaltdisco/Google-Chinese-Results-Blocklist/master/uBlacklist_subscription.txt

也可以自行添加自己不愿意看到的网站。

其实这个插件能做的不止于此。

读者可能发现了，左侧页面中还有黄色高亮内容，这是使用了该插件的高亮功能实现的，在检索的时候能够提醒：这是较为优质的信源！

下面是笔者的自定义规则，比较简陋，供读者参考：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

*://www.douyin.com/*
*://search.bilibili.com/*
*://gitcode.net/*
*://gitcode.com/*
*://gitcode.csdn.net/*
*://www.gitcode.host/*
*://jform2.baidu.com/*
*://blog.csdn.net/*
@1*://*.reddit.com/*
@1*://*.github.com/*
@1*://*.stackoverflow.com/*
@1*://*.cnblogs.com/*
@1*://*.wikipedia.org/*
@1*://*.youtube.com/*

Text Compare：字符串对比工具

Text Compare: Real-Time Diff & Merge Tool Online | Free (diffsuite.com)

简单、美观的字符串对比工具。

真实地址生成器

Real Address Generator (fuyiran.com)

简单方便的真实地址生成器。支持保存使用的地址。

开源于Github。

欢迎订阅本周刊的RSS!

如果您喜欢我的内容，欢迎评论，让我有继续写周刊的动力；如果您对本周刊有所建议，同样非常欢迎您的评论！

谢谢♥️！

本期是 寻觅周刊 试运营的第1期🎉🎉🎉！

在这个信息爆炸的时代，寻觅 有用的资源是一件不容易的事情。再叠加上近年来各种AIGC内容的影响，学会从庞大到令人绝望的互联网中 寻觅 到适合自己的资源，成了一件非常重要的事情。

寻觅周刊 致力于为读者提供 新鲜、实用 的 资源 和 工具，包含了作者一周来接触到的 实用、有趣 的资源工具，也许有时也会夹带一些私货。

用尽可能少的时间，获取到尽可能优质的信息。

欢迎订阅本周刊的RSS。

资源版

Youtube 博主推荐

• Veritasium - YouTube，讲述自然科学、数学等科普知识。个人比较喜欢
• Fireship - YouTube，擅长在两三分钟内向你介绍计算机行业的知识，或是报道最新行业新闻。
• 小Lin说 - YouTube，优秀的财经博主，讲解深入浅出。
• Big Think - YouTube，正如其名。
• Linus Tech Tips - YouTube，科技博主。
• Vox - YouTube，为你解释这个世界。World, explained.

Dracula：深色主题配色

Dracula — Dark theme for 300+ apps (draculatheme.com)

Dracula是我一直使用的一个主题配色，它包括几乎你能用到的所有软件。

我使用的就有这些：

• VScode
• Obsidian
• Windows 终端
• Zsh
• Zotero
• Github（通过Stylus实现）
• Telegram
• Notepad++
• Discourse主题
• Rime 小狼毫
• 代码高亮
• ……

它让我的电脑在视觉意义上成为了一个一致、统一的系统。

如果你对这个主题感兴趣，不妨去Dracula官网查找一下你常用的软件，试用一下它的主题。

工具版

Cursor：AI和IDE的融合

Cursor是一个以AI驱动为特色的代码编辑器，基于知名的开源IDE：VSCode。

上手体验几天之后，它给我的感觉是：在IDE层面大大提升了用户在利用AI进行辅助开发的效率。

下面是Cursor的介绍视频，你也可以在官网观看完整视频：

你可能会问：这和Github Copilot差别很大吗？

有。在我看来，它对比Copilot的优势在于以下几点：

1. 行内代码建议（Tab键）

熟悉的Tab键，但是：

• 可以同时生成多行代码建议
• 可以修改已有代码

2. 基于项目的代码编写与建议

对于整个项目，Cursor提供了一种索引的方法，能够高效地提取本地项目的信息，嵌入问答中，增强AI回答和编写代码的精确性。

3. 更新代码

在问答后，如果需要插入代码对原有代码进行修改，Cursor还提供了一种Apply的方法，能够智能创建修改代码的diff，你可以精确到行地选择是否接受代码。

除了这三点外，还有很多实用的功能。如果你对Cursor感兴趣，不妨动手试一试。

不必担心适应起来非常麻烦。如果你之前使用VSCode，Cursor可以直接将你的插件等配置一键导入，无缝衔接。

目前Cursor提供15天的免费使用，无须绑定信用卡，使用邮箱注册即可。20$/month。它还支持使用目前OpenAI最新的 o1-mini和o1-preview 模型。如果你到期了，还可以换一个邮箱注册，再次试用。

Follow：新一代信息浏览器

Follow 是 RSSHub 的作者打造的“新一代信息浏览器”。你可以简单理解为像 Feedly 那样的在线RSS阅读平台。

有文章、社交媒体、图片、视频、音频、通知六个板块。

支持导入OPML文件，方便从Feedly、TTRSS这样的平台或者其他阅读器迁移。借助RSSHub，订阅不同平台的博主变得异常简单。

整合资源、脱离信息茧房、高效获取信息、拒绝信息流……这些RSS的优点自然不在话下。我认为Follow的核心优势在于它的社区功能。你可以看到和你订阅同样信息源的其他用户（前提是TA愿意公开），还关注了什么其他信息源。这是一个非常好的寻找优质信息源的方式。

RSSNext/Follow: 🧡 Next generation information browser. (github.com) Github 仓库这几天猛增了很多star。

目前这个工具还处于Alpha测试阶段，需要邀请码才能访问。已有访问权限的用户可以签到5天兑换一个邀请码，但有邀请上限。

如果想要体验的话，可以去 Follow 的 Discord 群组蹲一下（但是很难抢！）。如果你之前参与过RSSHub项目的贡献，可以去Twitter上向作者@DIYgod讨要一个。

Complexity：Perplexity 增强插件

Complexity能够增强Perplexity的功能。

如果你没听说过Perplexity，不妨让它向你自我介绍一下。

Complexity的部分功能如下：

• 各种用户界面/用户体验/用户体验调整。
• LLM/Image gen 模型选择器；导出搜索/对话等。
• 高度可定制的主题（支持自定义 css）。
• 提示词管理专用解决方案：提示库（开发中）。

OneTab：简单粗暴地管理标签页

OneTab是一个用于管理标签页的浏览器插件。

使用浏览器时，常常会遇到这种情况：

标签很多，占用不少内存。这里面有些标签我们想要关闭，有些想留着，还有些又想留以后再用。怎么办呢？

简单粗暴的方法：使用OneTab一键收纳，还能节省内存。

轻轻一点，所有的标签都被关闭，只剩下 One Tab。

在这个面板里，你可以直观地看到哪些要留着以后用，哪些没用。不确定也没事，留在这个面板，下次来这边打开就行了。

后记

这是我第一次尝试以这种方式来写作：周刊。我认为我在发现优质信息、资源方面有一定能力，但是这种能力在过去一段时间内帮助到的人非常有限。

如果你喜欢我的内容，欢迎在下面留言，让我更有动力写下去；如果有什么建议，也请随意提出。

本文介绍了一种下载微信读书图书的方式，利用微信读书的缓存功能，能够下载用户有阅读权限的书籍，并且可以转换为PDF等格式。

教程

下载

蓝奏云

https://wwrd.lanzouv.com/i1zj02a4imbi

百度网盘

链接: https://pan.baidu.com/s/1CJYdGNDF9-X7nCYP4Zxjzg?pwd=ecw3 提取码: ecw3

解压

先把压缩包解压到合适的位置，然后双击微信读书下载器.exe打开软件。

登录微信读书

打开软件后，点击扫码登录，然后再点击“获取登录二维码”，再使用微信扫码登录。

加入书架

把你想要下载的书在手机微信读书App中加入书架，然后刷新软件页面，点击对应的书下载即可

获取电子书

打开软件文件夹下的book->一串数字->下载的书目->看这里里的html文件，用浏览器打开文件

在浏览器打开后，按下 Ctrl + P，选择“另存为PDF”，然后选择保存位置，即可下载PDF。

导出的PDF可以本地阅读，也可以导入微信读书等软件永久免费阅读。

电子书格式转换

如果你需要转换为其他电子书格式，可以使用 https://convertio.co/zh/ebook-converter/ 这个网站进行转换，上传你的pdf文件，然后选择你想要的格式，即可免费进行转换。

个人博客迁移到 Hexo 的测试。

为什么要迁移？

原来用的是Solo框架，正如其名，比较小众，而且是动态博客。今天突然想尝试一下用静态博客，于是选了Hexo框架。

最大的感受就是自定义能力强，生态丰富。折腾的时候虽然没写几行代码，但总感觉是真的在搭建一个属于自己的网站一样，这个网站就跟自己的孩子一般。其实如果不是有一天空闲也不会这样想

流程

测试

图片测试

图片来自 免费批量下载无损高音质音乐教程。

代码块测试

代码渲染

当然是 我最喜欢的 Python 了！

1
2

def hello():
    print("Hello, Hexo!")

代码折叠

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
    从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
        从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
            从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                    从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                        从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                            从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                                从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                                    从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                                        从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                                            从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                                                从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                                                    从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                                                        从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：
                                                            从前有座山，山上有座庙，庙里有个老和尚和一个小和尚，老和尚对小和尚说：https://www.bilibili.com/video/BV1GJ411x7h7/

LaTeX 测试

$$\text{Blog framework} = \text{Hexo now!}$$

callout测试

快捷键

试试 Alt+F4

TO-DO

• to
• do

表格

嵌入视频

用到的主题/插件

如你所见，我用了NexT主题，还有以下插件：

• hexo-theme-next
• hexo-auto-excerpt
• hexo-math
• hexo-next-darkmode
• mdit-plugin-callouts
• hexo-next-twikoo
• hexo-generator-feed
• hexo-generator-search
• hexo-symbols-count-time
• hexo-deployer-rsync

为什么不用VSCode自带的快捷键映射呢？

我按照网上的方案试了一下，结果每次按Esc返回的时候，都会同时更改大小写状态，不是很习惯。

安装AutoHotkey

AutoHotkey

因为编写的脚本是2.0版本的，所以下载的时候请选择Download v2.0。

编写脚本

在合适的地方创建vscode-vim.ahk脚本。如果想要开机运行，可以直接shell:startup下编写，或是在启动目录创建一个脚本的快捷方式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#Requires AutoHotkey v2.0

#HotIf WinActive("ahk_exe Code.exe")

; 将 Caps Lock 键映射为 Esc
CapsLock:: {
    Send("{Esc}")
}

; 将 Esc 键映射为 Caps Lock
Esc:: {
    if (GetKeyState("CapsLock", "T")) {
        SetCapsLockState("Off")
    } else {
        SetCapsLockState("On")
    }
}

#HotIf

这个脚本只会在VSCode中生效，将Caps键与Esc键互相转换。想要开启脚本，双击运行即可。

先允许我唠叨几句，如果着急的话可以直接跳到正文。

这几天突然觉得Spotify的音质不怎么样，据说最高只有320K。我虽然不是发烧友，但是还是比较看重音乐的音质的。但是我又不想多充一个平台的钱，于是我想到了一个替代方案：利用Spotify优秀的推荐算法来发现新歌，然后用本地播放器播放我Spot歌单里面的歌曲。

但是，这就涉及到一个重要的问题了：我的歌单里面有好几百首歌曲，想把他们全部下下来可不容易。虽然我知道有渠道可以免费下载高质量音频，比如一些Tg群组或者是大名鼎鼎的MyFreeMP3 (liumingye.cn)，但是他们下载都比较麻烦，不好批量下载，可能适合剪视频这种临时需要找几首的情况下下载。难道这个三色图又成立了？

今天，偶然看到一位大佬的白嫖数千万的高解析音乐曲库！下载qobuz，tidal，deezer等流媒体音乐平台资源的方法 - 常规话题 / 精华神贴 - LINUX DO帖子，顺着的他思路，我试了一下，发现这三者竟然可以同时成立，很好的满足了我白嫖的需求，现在将我的整体流程分享一下。

正文

如果你在一些音乐平台有体量很大的歌单，又不能免费把他们全部下载成无损音质的音频，可以试一下这个方法。

注意，本教程需要Python环境，这里默认你安装了python环境。若没安装请自行搜索教程/问GPT。

获取歌单列表

国内平台（网易云/QQ音乐）

迁移 网易云 / QQ 音乐到 Apple Music, Youtube Music, Spotify | yyrcd

按照上面网站的指引，输入歌单，然后就可以把对应歌单提取为txt文本格式。

国外平台（Spotify/Apple Music/Youtube Music等）

在不同的音乐服务之间迁移播放列表 | Tune My Music

我们使用上面的工具进行转换，如果你的歌单数目低于500（该工具免费版限制），可以直接按照网站的指引登录账户，获取歌单，然后直接选择导入目标为qobuz平台。

如果没有该平台的账户，可以免费创建一个Qobuz账户，建议直接用google账户创建。这个平台我们不需要充值，只是作为一个方便批量下载工具下载的跳板。

如果你的歌单歌曲超过500怎么办？也没有关系，可以先选择转换为TXT下载保存，后续使用Tune My Music多次导入就行了，一次能免费导入500首歌曲。

导入歌曲至Qobuz

在不同的音乐服务之间迁移播放列表 | Tune My Music

上面一步中，如果你是国内平台或者超过500首歌曲，在选择导入的时候选择任意文本。

然后输入你之前获取的歌单文本，如果超过500首的话就分批导入。

选择目的地为qobuz。

导入完成后，打开歌单列表，先把歌单的Private取消掉，否则工具无法公开读取你的歌单。

批量下载

nathom/streamrip: A scriptable music downloader for Qobuz, Tidal, SoundCloud, and Deezer (github.com)

我们使用这个工具来批量下载。

安装需要有python环境。执行以下命令安装：

1

pip install poetry

安装后，打开配置文件

1

rip config open

可以参考我的填法配置。好心人提供的token和id可以从Firehawk52 Official - Saving Digital Legacy (rentry.org)找到。

保存后，前往之前转移到qobuz的歌单链接，然后执行

1

rip url https://play.qobuz.com/playlist/xxxxxxxx

就会开始下载了。如果无法连接，可能需要开启全局代理或者tun模式。

如果下载断开报错，只需要再执行一次就好了，已经下载的会自动跳过。

缺点

虽然说大致解决三色图难题，但是这种方法还是有一些缺陷的。

1. 歌单转换可能不准确或者缺失。由于我听的大多数是英文歌，华语歌曲没怎么测试，可能会有缺失；部分歌曲转换后可能版本不太一致（比如原版变成了remix版或是相反），估计准确率在90%左右
2. qobuz里边有部分歌曲是灰色的，无法获取资源，个人猜测可能和token账号所在的国家有关。如果有部分歌曲下载失败可以换一个token试试。下载成功率大概也是90%。

shiquda/wereadcard (github.com)

效果展示：

github：

如果加载不出来，还有镜像站：

下面是简介。当然，建议直接去Github上查看，这里的版本可能过时。

简介

本项目利用 Github Actions 自动抓取微信读书记录，并且生成 .svg 卡片，作为展示。

使用

使用 Github Actions

cookie 获取

这里仅演示一种方法：

进入https://weread.qq.com/，扫码登陆微信读书。

使用F12控制台工具，打开网络/Network，刷新页面，筛选Fetch/XHR，任意选中一个请求，然后在标头/Header处找到Cookie，完整复制对应的字符串。

Github 配置

1. fork本仓库。
2. 在你的仓库，进入Settings > Secrets and variables > Actions，添加 Repository secrets：
3. 【必填】：WEREAD_COOKIE，添加上一步复制的微信读书cookie字符串
4. 【非选填】：BOOK_COUNT，默认为4，图片上展示的图书数量，建议不超过5。.
5. 进入Settings > Actions > General，找到Workflow permissions，改为选择Read and write permissions，并点击Save保存。

现在Github Actions默认会每间隔8个小时更新一次图像，并推送至仓库。更新的卡片在/output/recent_read.svg可以找到。

当然，你也可以手动触发Actions。

获取图片直链

在GitHub进入图片，Raw对应的就是直链链接。如果网络环境不好的，可以考虑使用镜像站加速，将URL中的githubusercontent替换为kkgithub，如：

1

https://raw.githubusercontent.com/shiquda/wereadcard/main/output/recent_read.svg

替换为

1

https://raw.kkgithub.com/shiquda/wereadcard/main/output/recent_read.svg

本地使用

克隆本仓库，然后安装依赖：

1

pip install -r requirements.txt

支持两种使用方式：可以直接在main.py中配置cookie等参数，然后直接运行，或者使用命令行参数：

• --cookie, -c：cookie字符串，注意在字符串两端加上引号。
• --number, -n：生成卡片中图书的数量。

运行后生成的卡片在/output目录中。

致谢

• malinkang/weread2notion: 将微信读书划线同步到Notion (github.com)

我们说一个人是“墙头草”，可能意思是说这个人听到别人说什么就是什么，没有主见。换一种说法，他只相信他最后听到的那种观点。

墙头草这个词无疑带有贬义，而与之相反的另一类人也时常会被夸赞坚持自我、有主见。

等一等。如果换一种词来形容这两类人，可能情况就截然不同了。

A是一个随机应变、听得进他人意见的人，而B是一个刚愎自用、自以为是的人。

第一反应，A在我们心中的留下的印象就是一个开明的人，而B则是一个迂腐、目中无人的人。

有没有发现？仅仅将具有相近意思的词语的褒贬性进行反转，所表达的意思就完全不同了。

如果你认同我的观点，那么请让我再问你一次：既然你被我说服了，那么你真的是墙头草吗？

你可能并不会认为自己是墙头草，至少不愿承认这一点，你想反驳，但是可能这两者之间的区别又很难说出来。

其实，两者的区别很简单。让我告诉你我的想法。

只是你自己给你自己贴上了墙头草的标签

也许，你实际上是在对你自己进行“道德绑架”，说服自己放弃相信新的信息和观点，来维护自己的“主见”。更可怕的是，这很可能是一个隐性的过程，你甚至可能还没有意识到这一点。

下面一段摘自我最近读的《学会提问》，也许会让你有新的思考。

我们的文化对那些改变观点的人没有广博的宽容心，我们总是称他们为“墙头草”或“伪君子”，而没有认识到，当新的证据出现时，改变我们的观点不仅是自然而然的事情，而且是负责任、有担当的表现。
——《学会提问》by 尼尔·布朗斯图尔特·基利

这段话让让我有一种“触动”，激发我产生了不少想法。很多时候，其实是我们自己给自己设下了道德约束，让我们对自己的行为进行过度的反思，而正是这种约束阻碍了我们进行进一步深入的分析与思考。

我一直反对简单地使用一个标签来封住他人的嘴，对他进行“盖棺定论”。更可怕的是，这种标签会在无形之中让我们的大脑按照《思考，快与慢》中的系统一行事，我们评价他人的观点的时，在不知不觉中带上了有色眼镜。

系统一的大概意思是大脑按照已有的经验给出快速而直接的反应，简单来说就是“偷懒”了。

在“墙头草”这个标签中，我们很可能就在无形之中给大脑加上了阻碍了思考的枷锁，毕竟，“坚持”自己原有的想法是最容易被大脑接受的一种选择。可怕的是，我们很难意识到这一点。

我想你心中应该还有一个疑问：什么时候算是“墙头草”，什么时候又算是“听得进他人意见”呢？

其实这个问题很简单。

我的想法是，好的思考方式应该是：

• 根据不断出现的新信息做出可靠判断，然后更新自己的信念；
• 而不是按照自己的信念，选择性地接受部分信息。

人无完人，没有一个人一直正确，也没有一种观点从诞生之初就能做到完美无瑕。

立场和观点是从可靠的信息里诞生的，而不是本末倒置，按照已有的立场和观点对信息进行不应该的筛选。

这么说，这个问题的关键在于：如何选出“可靠”的信息。这又是另一个话题了，有机会我再说说我的理解和想法。挖坑

我们不应该“带着有色眼镜”看待其他观点或者证据，而应该保持中立的立场；同时，当我们思考支持自己观点的理由的时候，也不应该回避可能对我们已有观点不利的因素。

看到这里，你可能会问，这不就是打自己的脸吗，谁会找不支持自己观点的理由呢？

求真 OR 求胜？

这就要提到我们思考问题的目的了：求真 OR 求胜？

我们经常会有这种体验：两个人就某个观点进行辩论，互相都不能说服对方。二者分别从自己的观点和立场出发，寻找最能够支持自己观点的理由，并且迫不及待地说给对方。结果往往也是不了了之，双方互相都不能说服对方。

这其实有点像一场辩论赛：正方和反方都不遗余力地提出支持自己观点的理由，同时攻击对方的观点。但不同的是，辩论赛最终由裁判进行评分，选出胜利的一方；正方和反方完全不可能改变自己的立场，在赛中承认对方的观点（至少我没见过）。在这场游戏里，他们的目的是求胜。

无奈的是，生活虽然不是辩论赛，但很多时候因为各种原因，求真的机会少之又少。

但当一个人静下来时，不是为了其他而思考的时候，我希望能够放下一切，甚至包括自己的已有立场，中立性地看待问题、思考他人的观点、分析信息的可靠性……尽管这是一个几乎不可能的任务，但是“虽不能及，心向往之”也是一种不错的态度吧。

其他

这是我第一次真正把自己的所想整理成博文发出，以前可能只是自己脑子里想想，或是与好友交流，但是这回我希望能和更多人分享我的思考。

我给这个系列取名“耕读”。在这个越来越快的社会里，能够有阅读与思考闲暇时光真的是一件奢侈的事情。因此，尽管我不希望如此，这个系列可能只有这1篇文章。

当然，我写这篇博文不是为了说服你，只是提供一种思考问题的方向。如果你不同意我的观点，欢迎与我交流。希望以求真为目的。

这个问题困扰了我好几个月了，当时好像是发生在一次Win11系统更新之后，突然从右下角的面板点击蓝牙就没反应，点击右边的展开按钮就会“闪退”。

并且也无法发现新的设备，只能连接已经配对的设备。

解决方案

我试着Google了各种方法，但是无不例外都失效了（除了重装系统还没试）。后来发现有一个系统服务Device Association Service不知道为什么被我禁用了，在属性里面把它的启动类型改为“自动”就可以了。

于是终于能看到已经有点陌生的界面了。。。

如果不是因为换耳机也不会折腾一晚上。。。。。

希望这篇教程对能解决你的问题，哪怕只有一个人因为我的文章少走弯路，我也觉得很满足了。

P1120 小木棍 - 洛谷 | 计算机科学教育新生态 (luogu.com.cn)

给 $n$ 个小木棍的长度 $a_i$ ，满足$1 \leq a_{i} \leq 50$ , $n \leq 650$ ，它们之间可以任意拼接，现在要让它们拼接后的长度相同，求这个相同长度的最小值。

例如：

1
2

9
5 2 1 5 2 1 5 2 1

其中最小的长度是6，分别由3个 5 1 和一个2 2 2拼成。

题目说是搜索题。

思路

这题看起来简洁易懂，但是实际操作起来却比较繁琐，我最早不信邪，使用贪心来尝试，结果不行，还是只能老老实实去写搜索。

首先分析一下题目中隐藏的数学性质：最终相同长度的木棍的数量范围是确定的，从1~n，那么木棍长度的可能取值其实是有限的，可以容易得出：长度一定能被所有木棍长度之和sum整除，且这个长度一定 ≥ 木棍长度 $a_i$ 的最大值。

因此，我们可以把答案的可能取值都先求出来，然后从小到大依次尝试能否合成。

至于如何判断能否合成，我最早使用贪心的思路是：把合成木棍看作“填充”，刚好填满则算合成一根。每一次从最大能被填入剩余空间的木棍开始填入，如果能顺利填完当然就是可以满足条件了，直接结束，返回这个长度就是最小的；如果遇到所有剩余的木棍都无法填入就说明不行，继续尝试下一个最小长度。

但是这个贪心算法有漏洞，判断为无法填入的情况，有可能有别的解。

反例：3 4 7 8 18 20

贪心45分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

#include <bits/stdc++.h>

using namespace std;

int fac[50]{0};
int fac_cnt = 0;
int max_num = 0;
int bucket[51]{0};  // 统计每个长度的个数
int n;
int sum = 0;

bool is_valid(int p)
{
    cout << p << endl;
    int bucket_copy[51]{0};
    for (int i = 0; i <= max_num; i++)
    {
        bucket_copy[i] = bucket[i];
    }

    for (int i = 0; i < sum / p; i++)
    {
        int max_num_copy = max_num;
        int pp = p;
        while (pp > 0)
        {
            if (bucket_copy[max_num_copy] == 0 ||
                max_num_copy > pp)  // 查找最低能被减的值
            {
                do
                {
                    if (max_num_copy == 0)
                    {
                        cout << "FAILED\n";
                        return false;
                    }
                    max_num_copy--;
                } while (bucket_copy[max_num_copy] == 0 || max_num_copy > pp);
            }
            pp -= max_num_copy;
            bucket_copy[max_num_copy]--;
            cout << max_num_copy << '\n';
        }
    }
    return true;
}

int main()
{
    cin >> n;
    for (int i = 0; i < n; i++)
    {
        int ai;
        cin >> ai;
        max_num = max(ai, max_num);
        sum += ai;
        bucket[ai]++;
    }

    // 对sum求因子
    for (int i = max_num; i <= sum; i++)
    {
        if (sum % i == 0)  // 整除
        {
            fac[fac_cnt++] = i;
        }
    }

    for (int i = 0; i < fac_cnt - 1; i++)
    {
        if (is_valid(fac[i]))
        {
            cout << fac[i] << endl;
            system("pause");
            exit(0);
        }
    }
    cout << sum << endl;  // 都不满足则是sum

    system("pause");
    return 0;
}

于是我还是老老实实地写搜索了，搜索其实思路也不难，我这边用的是dfs。每次合成木棍，写一个循环从长到短选择合适的木棍填入，然后进入下一状态，如果所有长度的木棍都试了也不行，则返回false；如果所有的木棍都合成完毕才返回true。

难在如何对搜索进行剪枝优化。剪枝操作就是在某种状态下，已经能够确定结果是什么了，就停止“递”，马上“归”的操作。

先要明白一个结论：如果需要某个长度，比如说5，而此时你还有2、3，那么选择5可以看作是选择2、3的“上位”，因为2、3合起来完全可以替代5，而反过来就不行了。因此我们要优先选择5，后面再尝试2、3，这就是从大往小搜索的原因。

这里就写几个最关键的优化，至于其他无关痛痒的优化，😂👉🤡：

1. 使用桶来装木棍的长度。桶的好处在于，既能按从长到短的顺序取出木棍，又能充当vis数组，“记录”已经访问的长度的信息。
2. 每次查找可用木棍的时候，从上次查找到的地方继续，不用从头开始查找。因为如果填入比上次更长的木棍可以的话，就应该优先选，这样上次不应选小的木棍。
3. 如果在剩下的长度和当前木棍的长度一样，但发现这根填进去返回false，直接跳出循环，判断这个分支为false，因为这已经是最优的选择了，如果选择用更小的木棍来补成这个长度肯定更不行。
4. 如果一点都没填且发现失败了，也直接返回false，道理和上面一样，最优的填法都不能完成，更不用说更不好的了。

说实话3,4这两个优化挺难想的，没看大佬的题解基本想不出来，当时自己最优就拿了50来分。还得多向大佬学习。

AC代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

#include <bits/stdc++.h>

using namespace std;

int fac[50]{0};
int fac_cnt = 0;
int max_num = 0;
int min_num = 100;
int bucket[51]{0};  // 统计每个长度的个数
int n;
int sum = 0;
int current_fac;
int filled_bucket[50]{0};
int filled_bucket_cnt = 0;

bool dfs(int l, int x, int idx)
{
    // l是当次剩余的长度，x是次数，idx是上次搜到的索引
    if (l == 0)
    {
        if (x == 2)  // 剩一个一定可以拼
        {
            return true;
        }
        else
        {
            return dfs(current_fac, x - 1, 0);
        }
    }

    if (l < min_num)  // 剩下的比最小长度还小
    {
        return false;
    }

    for (int i = idx; i < filled_bucket_cnt; i++)
    {
        if (bucket[filled_bucket[i]] > 0)
        {
            bucket[filled_bucket[i]]--;
            if (dfs(l - filled_bucket[i], x, i))
            {
                // cout << i << '\n';
                bucket[filled_bucket[i]]++;
                return true;
            }
            else if (l == current_fac || l == filled_bucket[i])
            {
                bucket[filled_bucket[i]]++;
                return false;
            }

            bucket[filled_bucket[i]]++;
        }
    }
    return false;
}

bool cmp(int a, int b)
{
    return a > b;
}

int main()
{
    cin >> n;
    for (int i = 0; i < n; i++)
    {
        int ai;
        cin >> ai;
        max_num = max(ai, max_num);
        min_num = min(ai, min_num);
        sum += ai;
        if (bucket[ai] == 0)
        {
            filled_bucket[filled_bucket_cnt++] = ai;
        }
        bucket[ai]++;
    }

    sort(filled_bucket, filled_bucket + filled_bucket_cnt, cmp);

    // 对sum求因子
    for (int i = max_num; i <= sum; i++)
    {
        if (sum % i == 0)  // 整除
        {
            fac[fac_cnt++] = i;
        }
    }

    for (int i = 0; i < fac_cnt - 1; i++)
    {
        current_fac = fac[i];
        if (dfs(fac[i], sum / fac[i], 0))
        {
            cout << fac[i] << endl;
            exit(0);
        }
    }
    cout << sum << endl;  // 前几个都不满足则是sum

    return 0;
}

P1434 [SHOI2002] 滑雪 - 洛谷 | 计算机科学教育新生态 (luogu.com.cn)

给定一个含有海拔高度的矩形，算出从高到低“滑雪”的最大长度。

“滑雪”只能从一个格子滑到上下左右相邻，且海拔严格小于当前海拔的格子。

例如：

1
2
3
4
5

1   2   3   4   5
16  17  18  19  6
15  24  25  20  7
14  23  22  21  8
13  12  11  10  9

这里的最大路径是：

共25格。

注意，“长度”为首尾经过总的格子的个数，比如路径$1\rightarrow 2$的长度为2。

题目给出的最大矩形长宽为100，记长为c(olumns)，宽为r(ows)

思路

第一想到的就是DFS（深度有限搜索），dfs(int x, int y)返回从[x][y]出发的最大长度。搜索的逻辑比较简单，就是寻找四周临近的格子的长度的最大值，加上1就是当前格子的最大长度。

但是这道题最大长宽为100，如果一个个暴力搜索肯定会超时的，最大的时间复杂度可能是$O(r^2c^2)$。

我们可以在暴力搜索的基础上进行记忆化搜索，建立一个数组rec[x][y]用于存储从[x][y]出发的最长长度，如果后续搜索到四周的格子，需要查找[x][y]的长度的话，直接返回这个记录的值就好了，不必再进行递归。

这样优化以后的空间复杂度和时间复杂度均仅为$O(rc)$（因为每个格子最多只要计算一次），完全能过。

AC代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66