2026-06-03 07:27:48
在上一篇文章里，我说到我在做自己的 LLM Wiki，那我肯定是要把我参与主持的《牛油果烤面包》播客收纳进去的。问题是，播客的内容主要是音频，而我写的所有 skills 都是用来处理基于 Markdown 的文本的，那我要如何收纳音频呢？
跟 ChatGPT 和 Claude 讨论之后，得到的方案是：用 OpenAI 开源的 Whipser 模型，输入音频生成文字稿。在 macOS 上面，只需要用 brew install whisper-cpp 安装 Whipser，然后就可以调用 whisper-cli 来处理音频文件。听起来很简单，但实际操作肯定是要踩坑的。
large-v3 模型会产生 loopWhisper 当下有两个主流模型，large-v3 和 large-v3-turbo。前者大一些，跑起来慢一些，但效果更好一些；后者小一些，速度快两三倍，但输出精度差一些。我让 Claude Code 帮我写实际调用 whisper-cli 的代码，让它分别测试这两个模型的效果，它发现 large-v3 确实好一些，所以我们先选择了它，尽管处理每一期播客都要花 30 分钟。
处理了几期播客后，Claude Code 发现输出的文字稿存在 loop 的问题。意思是，同一句话在音频中只出现了一次，但模型听到了多次，所以同一行文字在文字稿中重复了多次。如果不是 Claude Code 在帮我看着文字稿输出的结果，我自己肯定不会留意到这样的问题（几百上千行的文字稿没办法看）。它留意到这个问题后，跟我解释说更大的模型更容易出现 loop 的问题，建议降级到 large-v3-turbo 试试，降级后问题确实消失了。
最后我跟 Claude Code 做了一个决定：每一期的音频先用 large-v3 处理，等处理完了再分析文字稿，如果同一行内容连续出现 5 次或以上，那就算做 loop，然后用 large-v3-turbo 重新生成文字稿。我们用这个方法把剩余的音频都处理了，大概有 1/3 的文字稿因为存在 loop 而需要重新生成。
我参与录制的节目，开头肯定会有一句「大家好，我是 Cat」，然后 Whipser 会把「Cat」听成了「Kat」。我问 Claude Code 怎么办，它发现 Whipser 可以输入一个文本的 prompt，于是我就把播客的核心信息写到 prompt 里面去，包括我名字的正确拼写：
《牛油果烤面包》播客聊科技发展趋势，聊各行业来龙去脉。我们坐标硅谷，邀请第一线的资深专家分享给大家听！主持人：Cat、斯图亚特、Sean、Vindy、David。
在这段 prompt 的帮助下，Whipser 识别我名字的正确率提高了，虽然还是不完美。
既然可以用文本 prompt，我就把每一期节目的文字描述也追加进 prompt 里，这样 Whipser 听到有关信息能够更好地识别出来。我粗略地看了一下，效果还不错。
2026-05-20 13:55:53
我最近开始构造自己的 LLM Wiki，在这个过程中我需要编写自己的 LLM skills。（一方面我的文档架构跟别人不一样，只能参考别人的 skills 写自己的；另一方面，我就喜欢折腾。）在这个过程中踩了几个坑，在此记录下来。将来不一定有用，因为 LLM 发展太快了，今时今日的局限，6 个月之后可能就不是问题。
我需要跟踪我的哪些博客文章更新了，然后重新生成对应的总结文档，为此我用 JavaScript 计算了每一篇博客文章的 SHA256 hash，然后写到总结文档的头部，只有 hash 对不上时才重新生成总结文档。在 skill 里面我把算好的 hash 提供给 LLM，让它在编写总结文档时把这写到头部，它有时候竟然会抄错整个 hash 中的一个字符。
我问 Claude Code 为什么会发生这样的事情，它说 LLM 擅长顺着 token 吐字符，而 hash 是没有任何语义的随机字符串，LLM 不擅长输出这样的 token，所以会偶尔输错。Claude Code 帮我改了一下 skill，在里面强调了 hash 必须一字不差地抄写到总结文档里。将来我会改用 JavaScript 生成好带 hash 头部的总结文档，再让 LLM 去填充内容，这样才能保证不出错。
我在 skill 里让 LLM 把当前时间的 ISO UTC 时间戳写到文档头部。我跑了一次这个 skill，过了一个小时又跑了一次同一个 skill，发现它写入的时间戳还是一小时前的。我问 Claude Code 为什么会这样子，它说 LLM 会记住「当前时间」这个概念，在同一个对话中不再尝试查时间。
原来 LLM 对时间流逝完全没有概念！这简直就是在时间河流中的刻舟求剑，一旦记下了当前时间就认定它永远不变。为了解决这个问题，我让 skill 调用脚本获取当前的时间戳，不再是自行输出时间戳。因为我已经在用 JavaScript，所以我就让 LLM 调用 Node 执行一行 JavaScript 获取时间戳：
node -e 'console.log(new Date().toISOString())'
我写了一个需要跟我交互的 skill。这个 skill 让 LLM 审阅 Wiki 当中已有概念文档，然后找出可以合并的概念（因为它们是同义词、相关概念或者从属关系），接着问我是否要合并，以及按照哪个方向合并（把哪个概念合并进另一个概念）。我进行是否合并的最终决定。
这个 skill 写着，在 LLM 建议我合并概念 A 和概念 B 时，它应该提供一个有 4 个选项的菜单：
此外我还让 LLM 帮我判断应该往哪个方向进行合并，如果它能决定哪个方向更好的话它就应该把哪个选项放在首位，旁边注明「推荐」，例如说：
实际执行这个 skill 时，它竟然给我出了这样的选项：
这就很自我矛盾了。因为 skill 里面写着，LLM 必须找出值得合并的概念。如果 LLM 推荐我不要合并这两个概念，那就违背了它上文「值得合并」的筛选条件。
更搞笑的是，有时候 LLM 会自作聪明地把两对概念同时拿出来让我审阅，于是给出这样的选项：
遇到这样的问题，我只好跑回去让 Claude Code 帮我改 skill。它往 skill 里面加入了更多约束的 prompt，上述现象确实消失了。但为什么多加约束就能用，约束增加到多少就会影响 skill 执行的质量，这一切我都不知道。
上述问题全部出现在 Sonnet 4.6，换成 Opus 4.7 有没有同样的问题，我不知道。这就是 LLM 踩坑的局限性，你永远不知道这些坑是不是特定模型特定版本导致的。今时今日需要在 harness 层面进行修复的问题，或许 6 个月之后的 LLM 就不再依赖这类 harness 操作。这篇文章 6 个月之后再看，是否还有价值，还真的很难说。
2026-05-07 08:08:22
Reverse Centaur（逆向半人马，也就是马的大脑驾驭人的躯体）是一个很少人讨论的概念，我甚至没见过有人用中文提及。
1997 年 Garry Kasparov 被深蓝击败后提出了 Centaur Chess（半人马象棋）的概念：业余选手搭配普通算法，既可以击败大师选手，又可以击败顶级算法。2000 年到 2010 年期间，这个概念被证实可行。（之后神经网络彻底超越人类，人类的介入只会让结果更差。）
Centaur 成了一个泛指「人类利用和指挥机器」的概念，随后 Cory Doctorow 提出了 Reverse Centaur 的概念，指代「人类被机器指挥和控制」。零工经济（例如外卖骑手）就是典型例子，算法决定如何调度人，被调度的人缺乏对大局的了解，只是充当机器临时的四肢（跑腿），等待被无人驾驶和机器人取代。
AI 时代，鼓吹者当然说未来是半人马模式，人类利用 AI 能做更多原本想做而不能做的事情。但现实也可能发展为更加阴暗的逆向半人马模式，AI 把人类当作外设来用，人类被迫去做自己不想做的事情。
2025-04-19 11:24:00
我还记得在 Facebook 参加「反歧视」培训时，我举手提了一个问题：「如果我们不是歧视少数的一方，而是歧视多数的一方，这是否合法？」我得到的答案是「逆向歧视也是一种歧视」。这意味着不歧视的话，招聘招到什么样的人就是什么样的人，不可能给少数群体安排一个配额。（除非招聘总人数没有上限，在少数群体满足配额之前无论招到什么人都继续招聘。）
Facebook 在这方面是说到也做到的，不存在任何针对少数群体的配额。针对少数群体的弱势地位，有几件事情可以做：
我之前听说 Google 的招聘存在针对少数群体的配额，如果属实的话这其实也是一种歧视。
为什么有些政府或企业会设立 DEI 配额？因为这样子才能显示出自己真的有贡献，产生了影响（impact）。我上面所说的 Facebook 的做法，往往是无法在数字上体现成果的，一测量就会发现数值没产生足够可信的变化，数值浮动可能纯粹是噪声。这样很容易引起别人的质疑，「投入这么多资源去改善少数群体的处境，到底有没有效果？」
设立少数群体的招聘配额或者是晋升配额，通过逆向歧视完成配额，至少避免了上述的质疑，因为少数群体的实际招聘和晋升人数或比例每一年都在涨。这时候政府和企业就可以大谈自己在 DEI 上面的贡献有多少，成果有多出色。然而正是这种急功近利的做法，导致了最近反 DEI 的现象。
Donald Trump 反对 DEI，并且说要创造一个「colorblind and merit-based」的社会，然而真正符合 DEI 精神的做法本身就应该是「colorblind and merit-based」的。他和他的支持者实际反对的是逆向歧视，这是一个合理的诉求，毕竟逆向歧视也是歧视，只不过受到伤害的是多数群体而已。但是这种做法把 DEI 的名字搞臭了，现在不再有一个能代表真正「colorblind and merit-based」的词汇。
真正做 DEI 必须要沉得住气，在数据长期不动的前提下坚持做自己认为正确的事情。我在 Facebook 内部接触到各种帮助员工提升的群体，大多数帮助的结果都无法量化，但如果你相信你帮到了别人你就应该继续做下去。
我曾经跟负责 Facebook 女工程师成长的资深工程师聊过，她说她们组织资深的女工程师对其他女工程师提供帮助，结果就是无法量化。无论你如何分析晋升和绩效数据，都没有可量化的结果。有时候做好事和面子工程是不可兼得的。她最后的结论是，「如果你认定事情是对的，你就应该坚持去做，无论最好是否有可量化的结果」。
2024-07-29 12:37:00
在开发 GitHub Actions 时，有时候会遇到这样的问题：如果这个 Action 接受来自用户的 GitHub token，那该如何以这个 token 背后的身份完成所需的 git 操作？
我在上一篇文章里介绍了我做的 config-git-with-token-action，专门用来解决这个问题的，但这个 Action 在配置 git 的时候又是怎么获取对应的用户名和邮箱的呢？这是通过另外一个叫做 token-who-am-i-action 来解决的。
这个 Action 可以接受用户生成的 PAT (Personal Access Token)，也可以接受 GitHub App 的 token。（默认的 GitHub Actions token 当然是接受的。）它会使用 Action 调用 GitHub API 查询关于 token 自己身份相关的信息，因为类似于 Linux 的 whoami 命令所以我把它叫做 token-who-am-i-action。
这个 Action 能返回的信息当中，首先要看 type 是 User 还是 Bot。
User 的话，它所返回的其他信息包括 name 和 email。这两项都可能是 undefined，因为用户可以选择隐藏自己的名称和邮箱。Bot 的话，它必须返回 name、email 和 appSlug，全部都是字符串，不可能是 undefined。每一个 GitHub App 必须有一个用于显示的名字，然后由此生成对外公开的地址（格式为 https://github.com/apps/${appSlug}）。GitHub App 其实并不存在邮箱，但使用特定格式（${id}+${login}@users.noreply.github.com）生成的邮箱会被正确识别并显示正确的头像，例如说 GitHub Actions 默认 token 的身份使用的邮箱是 41898282+github-actions[bot]@users.noreply.github.com。除此之外，无论是哪种类型的身份，这个 Action 还能返回 login、id 和 globalId。login 对于 User 来说，就是他的个人页面地址（https://github.com/${login}）中的路径，有些文档也把这个叫做 username；对于 Bot 来说，这可以由 appSlug 通过特定格式（${appSlug}[bot]）生成，例如 GitHub Actions 的就是 github-actions[bot]。
至于 id 和 globalId 分别用于 REST API 和 GraphQL。这是 GitHub 数据存储很有意思的一个地方。对于每一种 REST API 的类型（如 user），它背后都是一张独立的关系型数据表，都有一个这种类型内部唯一的 id，但这个 id 可以跟其他类型冲突。在 GraphQL 里面，因为 id 可以用来查询任何类型，所以引入了 globalId 的概念，保证即使跨类型依然唯一。GraphQL 的某些 query/mutation 的 id 默认就是 globalId；但某些必须加上 X-GitHub-Next-Global-ID: 1 的 header 进行请求才是 globalId，否则就是跨类型不唯一的 id。
那我们如何在编写自己的 Action 时调用 token-who-am-i-action 呢？如果你在编写的是 composite action，可以这样写：
runs:
using: 'composite'
steps:
- uses: CatChen/token-who-am-i-action@v1
id: token-who-am-i
with:
github-token: ${{ inputs.github-token }}
- shell: bash
env:
LOGIN: ${{ steps.token-who-am-i.outputs.login }}
GLOBAL_ID: ${{ steps.token-who-am-i.outputs.global-id }}
ID: ${{ steps.token-who-am-i.outputs.id }}
NAME: ${{ steps.token-who-am-i.outputs.name }}
EMAIL: ${{ steps.token-who-am-i.outputs.email }}
TYPE: ${{ steps.token-who-am-i.outputs.type }}
APP_SLUG: ${{ steps.token-who-am-i.outputs.app-slug }}
run: |
echo "Login is $LOGIN"
echo "Global id is $GLOBAL_ID"
echo "Id is $ID"
echo "Name is $NAME"
echo "Email is $EMAIL"
echo "Type is $TYPE"
echo "App slug is $APP_SLUG"
如果你编写的是 JavaScript action 可以先从 NPM 安装同名的 token-who-am-i-action 包，然后再进行调用：
import { tokenWhoAmI } from 'token-who-am-i-action';
const me = await tokenWhoAmI(githubToken);
const {
login,
globalId,
type,
} = me;
if (me.type === 'User') {
const {
id,
name,
email,
} = me;
} else if (me.type === 'Bot') {
const {
appSlug,
id,
name,
email,
} = me;
}
希望这个 Action 对各位 GitHub Actions 开发者有用。非 Actions 开发者也可以直接在 Workflow 里面使用这个 Action，如果你的 Workflow 使用非默认的 GitHub Actions（机器人）身份进行 git 操作的话。大家在使用过程中遇到什么问题，或者是希望增加什么新功能，欢迎到项目的 GitHub 开 issue。
2024-07-01 13:30:00
在开发 GitHub Actions 时，有时候会遇到这样的问题：如果这个 Action 接受来自用户的 GitHub token，那该如何以这个 token 背后的身份完成所需的 git 操作？
使用 token 操作 GitHub API 是很容易的，通过 @actions/github（或 @octokit/core）创建一个 Octokit 实例时把 token 传进去就可以了，之后通过这个实例进行的所有 API 调用（包括 REST 和 GraphQL）都会以这个 token 的身份进行。但命令行的 git 操作怎么办呢？如何让 git commit 的作者变成 token 背后的身份？如何让 git push 以 token 背后的身份进行提交？（这两者并不一定要用同一个身份。）我做了 config-git-with-token-action 就是用来解决这个问题的。
这个 Action 会对 gh 和 git 进行配置，让它们的身份信息变成 GitHub token 背后的身份信息。gh 的配置相对简单一些，把 GH_TOKEN 这一环境变量配置好就行了，然后执行 go auth status 就能打印出 gh 认为自己在使用的身份信息。对 git 进行配置稍微麻烦一些，gh auth setup-git 只能保证 git 在跟 GitHub 交互时从 gh 获得身份信息，但并不指明具体是哪一个身份。为了保证 git commit 使用正确的身份，需要通过 git config 来设置正确的用户名和邮箱。此外，为了保证 git push 使用正确的身份，需要通过 git remote set-url origin 来更新上游地址，在 https://github.com/… 的地址中注入用户名和 token，让它变成 https://username:[email protected]/…。
这个 Action 假设用户在执行它之前已经执行过了 @actions/checkout，所以它不会尝试自行建立项目目录。大家最好使用同一个 token 进行 @actions/checkout，这样项目目录从一开始就是以 token 背后的身份创建的。以下是一个完整的用例：
runs:
using: ‘composite’
steps:
- uses: actions/checkout@v4
- uses: CatChen/config-git-with-token-action@v1
with:
github-token: ${{ inputs.github-token }}
- shell: bash
run: |
echo “Set up git user name: $(git config —get user.name)”
echo “Set up git user email: $(git config —get user.email)”
echo “Set up git remote origin with login and token: $(git remote get-url origin)”
- shell: bash
run: |
touch test_file
git commit test_file -m ‘Created test file’
git push
做为 GitHub Actions 开发者，如果你利用 JavaScript 而非 bash 进行开发，那上述 composite action 的用例并不适用，我们需要一个针对 JavaScript action 的用例。我自己有同样的需求，所以 config-git-with-token-action 同时还是一个 NPM 包，可以在 JavaScript 中进行调用获得同样的功能。（这个包具备完整的 TypeScript 类型信息。）安装好之后，通过 JavaScript 调用的用例如下：
import { configGitWithToken } from ‘config-git-with-token-action’;
await configGitWithToken(githubToken);
希望这个 Action 对各位 GitHub Actions 开发者有用。非 Actions 开发者也可以直接在 Workflow 里面使用这个 Action，如果你的 Workflow 使用非默认的 GitHub Actions（机器人）身份进行 git 操作的话。大家在使用过程中遇到什么问题，或者是希望增加什么新功能，欢迎到项目的 GitHub 开 issue。
至于这个 Action 是如何获取到 token 背后的身份信息的，那是这个系列的下一篇文章要介绍的下一个 Action 负责的。
