Fomalhaut647

北大研究发现缺勤与成绩的相关性不显著

Tue, 07 Jul 2026 00:00:00 GMT

毕竟最强的那一批早就自学过了，而且部分课程的课件年龄比学生还大，上课不如用 AI 自学（笑）
即使要听课，观看课程回放也通常比线下听课的效果更好，遇到简单的就倍速快进，遇到难的就暂停思考问 AI

仍记得某高数老师声称要考勤，第一节课就被学生批评 “老师应当提升授课质量来留住学生，而不是用考勤来强留学生”，于是无奈取消考勤

课堂上摸鱼的人相对较少，因为不想听的直接不来了

代课更是闻所未闻

旧约 & 新约

Tue, 07 Jul 2026 00:00:00 GMT

北京我真没空陪你闹了

Fri, 03 Jul 2026 00:00:00 GMT

我将严肃驻守宿舍并打开空调急冷模式

有且仅有女生

Wed, 17 Jun 2026 00:00:00 GMT

图 0 & 冯诺 1 曼

Fable 5 速通六级

Fri, 12 Jun 2026 00:00:00 GMT

Fable 5 控制字数的能力堪称恐怖，我告诉它作文不超过 150 words，它直出 4 篇作文，全部精准控制在 145 ~ 150 words

btw 把网上找的模板喂给 Fable 5，生成定制化模板，然后对着往年题 RL，这是速通六级最优解吗？上学期喜提 544，这次能提高 6 分吗，会赢吗？

被 A\ 封号

Sun, 07 Jun 2026 00:00:00 GMT

你说我的新号还能活下来吗

高松同志任北京大学校长

Sat, 23 May 2026 00:00:00 GMT

高松灯，企鹅，mygo 等都成了树洞违禁词，笑死我了

Skill Simplifier

Thu, 21 May 2026 00:00:00 GMT

写 agent-team 的时候我反复强调过一条纪律：每段提示词只存在于唯一一个地方。重复就是漂移源——上游措辞变了而下游抄了一份旧版本时，下一次 coordination 就出 bug。但这条纪律没法靠”写的时候多注意点”维持，Claude 自己写 skill 和 CLAUDE.md 时倾向于把它觉得重要的事一股脑全写上，分不清这些事是不是已经被系统提示词、Tool Description、其他 skill 或更上层的 CLAUDE.md 提供了。于是我把这条纪律做成了 skill-simplifier：审一个目标文档，列出每一处与上游重复的内容，自动删那些”无论如何都该删”的，剩下”两侧都由用户拥有”的让用户决定

Fomalhaut647

plugins

Waiting for api.github.com...

00K

Waiting...

它解决什么问题#

Claude 写 SKILL.md 和 CLAUDE.md 有一种 kitchen-sink 倾向：只要觉得”这个规则很重要”就写进去，不管这条规则是不是已经由更上游的知识源提供。最常见的几类冤枉重复：

SKILL.md 里写”用 Edit 工具不要用 sed”——这是系统提示词里已经有的
SKILL.md 里详细解释 TeamCreate 的参数——这是 tool description 已经返回的
CLAUDE.md（项目级）写”使用中文回答”——这是用户全局 CLAUDE.md 已经有的
skill 的 references/foo.md 里抄一段 superpowers:test-driven-development 的 RED/GREEN/REFACTOR 流程——这是另一个 skill 激活后直接提供的

每条单独看都不冒犯，但堆起来就两件坏事：占 context、稀释目标文档真正独特的价值；上游变了之后副本悄悄过时。第二件更要命，因为它是隐式的：你以为 skill 还在按最新规则跑，实际上它依据的是某条 tool description 半年前的措辞

核心判定标准#

判定一段内容是不是冗余的方法很朴素：删掉它，Claude 的行为会不会变？ 如果不会，那它就是冗余的，因为同样的约束已经在上游某处提供

两个要点：

语义而非字面：措辞不同也可能是重复。“使用 Read 而非 cat 读文件”和”避免用 shell 拼接读取文件内容，应当调用专用工具” 是同一条规则的两种说法
字面相同也可能不是重复：如果目标补上了上游缺失的”为什么 / 例子 / 取舍”，那它在做独立的工作。例如系统提示词只说”破坏性操作前先确认”，而某个 CLAUDE.md 补一句”过去 force push 删过 main 历史，所以这条规则在我们这特别严”——保留有上下文的那一侧

四类上游知识源#

每一处重复都会归到下面四类之一。skill-simplifier 在 Stage 1 按顺序排查，分类要做准，因为 Stage 4 的处理规则按类不同

1. 系统提示词（隐式上游）#

这是最容易漏的一类，因为 Claude 没法 Read 系统提示词，它就在 context 里。需要逐项扫的重灾区：

用专用 tool 而非 cat / echo / sed
独立的 tool 调用并行执行
file_path:line_number 引用约定
git commit / PR 工作流
sandbox 与安全规则
破坏性操作先确认

只要目标把这些规则之一重新陈述了一遍，就是在重复系统提示词

2. Tool Description#

每个 tool 自带一段 description。这里有个反直觉点：

内置 tool（Read、Edit、Bash、Skill 等）的 description 在 context 里，直接看
Deferred tool（TeamCreate / SendMessage / WebFetch / Monitor 等）的 schema 不在 context 里——只在 <system-reminder> 块里以名字出现。要查它们的 description 必须先用 ToolSearch 配合 select:Name1,Name2,... 把 schema 拉进来

agent-team 这个 skill 反复出现 “the descriptions returned are the authoritative reference” 这句话的原因正是为此：与其在 SKILL.md 里抄一份 TeamCreate 参数表（必然过时），不如强制 agent 每次激活时去拉 live schema

3. 其他 Skill#

Available Skills 列表在 <system-reminder> 里。扫一遍，挑出名字或一句话描述和目标领域重叠的 skill。读其他 skill 的内容必须用 Skill(name) 调用它，而不是用 Read 去读 SKILL.md 文件——plugin cache 的路径不稳定（带版本号、可能因 plugin 更新而变），靠 Read 拼路径是脆弱的

如果目标重述了一条”另一个 skill 一旦激活就会提供”的指令，就是在重复 Skill

4. 其他 CLAUDE.md#

CLAUDE.md 是 cascade 的，上游链按目标类型不同：

CLAUDE.md 目标：从 ~/.claude/CLAUDE.md 一路读到目标父目录的每一个 CLAUDE.md
Skill 目标：~/.claude/CLAUDE.md 加上 skill 预期将运行其中的项目根 CLAUDE.md

如果目标重述了一条更上游 CLAUDE.md 已经提供的规则，就是在重复 CLAUDE.md

报告先于改动：Stage 4 闸门#

skill-simplifier 最重要的设计是强制在改动前先输出完整报告，等用户对部分条目做决定再执行 Edit。这条约束在 skill 里直接列为红线：“不要在用户给出 Zone B 和 Zone C 决定之前进入 Stage 5”

理由：删除是低成本的操作，但误删（false-positive）是隐性回退——一段被错删的情境化指引不会立刻报错，下一次 Claude 在边界 case 上失去判断依据时才暴露。让用户先看完所有命中条目再做决定，比一次性 batch 删完更安全

报告分两到三区：

Zone A — 自动删#

上游是系统提示词或 Tool Description。这两个上游用户没法编辑，唯一可动的杠杆就是目标侧。所以 Zone A 默认全删，列出来只是方便用户做合理性核查、对具体某条提出反对

Zone B — 用户决定#

上游是其他 Skill 或其他 CLAUDE.md。两侧都由用户拥有，所以三选一：删目标侧、删上游侧、或两侧都留并加显式的交叉引用

为什么不能合并条目

明显成组的条目可以合并成一个决定。但不要把上游来源不同的条目合并成同一条——用户可能想对不同上游做不同选择（比如：愿意删项目 CLAUDE.md 的副本，但全局 CLAUDE.md 的那条保留）

Zone C — 内部分层（仅 Skill 目标）#

skill 的 SKILL.md 总是在激活时加载；references/*.md 按需加载。内容在两层都出现就破坏了 progressive disclosure。用 Zone B 同款格式让用户选，因为”哪一层拥有这段内容”是设计决策——是把它放进常驻 context 还是按需加载

几条不能碰的红线#

触发内容神圣不可动#

Skill 的 description: frontmatter 是它被 trigger 的入口，CLAUDE.md 里的”看到 X 时做 Y”短语是它被应用的入口。即便它们和某条上游措辞重叠，也要保留——删掉就破坏了激活路径，整个文档变成沉默资源

不要把临时 query 结果固化进去#

通过 ToolSearch / WebSearch / Read 一次性获取的 schema、版本号、API 字段名等等，绝不能抄进 SKILL.md 或 CLAUDE.md 当”方便的 inline 参考”。上游会变，inline 副本必然过时。让目标在每次调用时重新获取——这正是 deferred tool schema 不进 skill 的同一条原则

保守删除#

拿不准时保留目标内容，加一句 “see X” 的指针即可。多一句话的代价很小；丢掉用户依赖的情境化指引的代价大。漏删在下一次审查时能补救；误删则悄悄回退 Claude 的行为

具体胜过泛化#

如果一份 skill / CLAUDE.md 重述了系统提示词的泛化规则、但补上了具体例子、取舍或为什么，它是在做真实工作。这种张力出现时保留情境化的那一版，只裁掉冗余的泛化前言

一个工作流上的小细节#

skill 在 Stage 2 会激活辅助 skill，但按目标类型分叉：

目标是 Skill → 激活 superpowers:writing-skills + skill-creator
目标是 CLAUDE.md → 激活 claude-md-management:claude-md-improver

这两组辅助 skill 提供”好的 skill / 好的 CLAUDE.md 长什么样”的参考，但它们本身不是 skill-simplifier 的替代品——它们关心结构和清晰度，skill-simplifier 单点关心去重。所以辅助 skill 是激活，不是委派

安装#

Terminal window

1
/plugin marketplace add Fomalhaut647/plugins
2
/plugin install skill-simplifier@fomalhaut647-plugins

@ 前的 skill-simplifier 是 plugin name，@ 后的 fomalhaut647-plugins 是 marketplace name

怎么用#

最直接的触发短语：“simplify this skill”、“review this CLAUDE.md”、“审查 / 精简 / 去重 / 瘦身 skill”、“是不是有重复”。其实更常见的场景是用户自己写完 skill 后感觉冗长 / 抱怨”这段我好像在别处写过”——这时候哪怕用户没明说 “simplify”，也应该优先调用本 skill。这正是它存在的意义

跑一次完整流程的样子：

问用户目标是哪个 skill 目录或 CLAUDE.md 文件
枚举四类上游知识源、读完整目标
输出两到三区报告（这里停下来）
用户对 Zone B / Zone C 给出决定
Edit 按决定逐条删除或加交叉引用

每次调用只处理一个目标。如果用户有多个 skill 要审，每个文件各跑一次工作流——上游枚举可能因目标而异，混在一起处理会漏判

后记#

skill-simplifier 自己是个反讽：它的 SKILL.md 写得相当瘦，没有重复的”好 skill 长什么样”教学（那是 superpowers:writing-skills 的事）、没有抄 Skill tool description（那是 tool 自带的）、没有解释什么是 cascade（那是 CLAUDE.md 自己的概念）。它只做一件事——审目标里有没有上游已经提供的内容——所以它自己也必须严格遵守这条纪律

仓库：https://github.com/Fomalhaut647/plugins/tree/main/plugins/skill-simplifier，欢迎试用、提 issue

Agent Team & TDD superpowers

Sat, 16 May 2026 00:00:00 GMT

最近写了个 Claude Code 插件 agent-team，把我这段时间踩过的多 agent 协作坑总结成两个 skill，配合 superpowers 的 TDD 工作流可以跑长程开发任务。本文介绍它的设计动机和用法

Fomalhaut647

plugins

Waiting for api.github.com...

00K

Waiting...

平台支持#

目前只有 Claude Code 原生支持 Agent Team（TeamCreate / SendMessage 这一套 primitive），所以 agent-team 这个 skill 本身只能在 Claude Code 里用。Codex、Cursor、Cline 等编程工具的用户暂时跑不了多 agent 长程协作

但本仓库 references/ 目录下的 TDD + 两阶段 review 工作流文档对所有编程 agent 都有借鉴价值——这套流程在 Claude Code 之外仍然成立，只是协调层得换成”开多个会话窗口手动复制粘贴”。其他工具的用户可以读 superpowers-implementer.md 和 code-review.md，把里面”用 SendMessage 通知 reviewer”之类的句子改成自家工具的等价物，剩下的 TDD 节奏和 spec compliance + code quality 两阶段 review 思路是通用的

为什么需要 Agent Team#

最大的优点不是”能并行”，而是 分配上下文，让长程任务保持稳定

单 Agent 的瓶颈：上下文挤爆，指令跟随能力下降#

让一个 agent 直接 inline 写代码会发生什么？它的 context 会被具体的工作细节填满——读了一堆代码、跑了一堆测试、看了一堆 error、回滚了几次。当 context 长到几十 k token，agent 对最初指令的跟随能力会显著下降：忘记用户立下的规矩，不再严格走 TDD（跳过 RED 阶段直接写实现）、忘了 commit 粒度约定、忘了某些路径不能动

这是写大工程时最常见的失败模式：开头很守规矩，到 70% 进度时已经在自由发挥

superpowers 的第一层抽象：subagent-driven-development#

superpowers:subagent-driven-development 的解法是：让 controller agent 别自己写代码，派 subagent 写。controller 给 subagent 一份 brief，subagent 在干净 context 里实现 + commit + 返回结果，controller 读结果决定下一步。具体的代码细节（哪行报错、哪个测试 fail）只留在 subagent 的 context 里，controller 始终保持小组长视角

这样 controller 的 context 增长慢得多，指令跟随能力维持得更久。同样，code review 也派 subagent 做——还得用两阶段：spec compliance reviewer 看是否符合 plan，code quality reviewer 看代码本身健康度，互相抓不同的 bug

subagent-driven-development 的天花板#

但这套模式还是有上限：

一个 controller 只能管一个模块的构建——前端 + 后端两个模块的工作量，单 controller 的 context 仍然会挤爆
review 不能由 implementer 同一个 agent 做（防作弊）。理论上 review 整个开发分支的 reviewer 应该是独立 agent
于是用户被迫自己开多个 Claude Code 会话手动协调：
- 一个窗口跑 implementer，一个窗口跑 reviewer
- 把 reviewer 的反馈复制粘贴给 implementer
- 或者让 reviewer 在 PR 上评论，然后切回 implementer 窗口让它去拉评论
- 手动管理实现前端的 branch 和实现后端的 branch
- 用户一直在多个窗口间切换、复制信息

这时用户自己变成了协调者——这正是上下文挤爆问题的人类版本：用户的注意力被低级的”把 A 窗口的字粘到 B 窗口”消耗，没精力做高层决策

agent team 的第二层抽象#

agent-team 在 controller + subagents 之上再加一层抽象：team lead 协调多个 teammate，每个 teammate 都是 controller 级

team lead 制定整个 plan，把任务分给不同的 teammate（一个写前端、一个写后端、一个审前端 PR、一个审后端 PR）
每个 teammate 在自己的 worktree 里跑完整的 subagent-driven-development 循环
teammate 之间通过 SendMessage 直接对话，不再需要人类用户转发
team lead 监督 teammate 是否在正确时机激活该激活的 skill、是否严格走 TDD

人类用户从协调者位置上摘下，只需要：

向 team lead 提需求、讨论细节
仔细阅读设计文档，粗略阅读实现文档
完成程序难以完成的测试（比如在 web app 里点点点）并反馈给 team lead

人类不再需要逐行看代码，也不再需要在多窗口间复制粘贴

由于 team lead 不深入开发和审查细节，它的 context 用量很小，整个长程任务里指令跟随能力一直保持高水平——这就是”分配上下文”的核心价值

设计哲学#

投顾比喻#

如果说：

Claude Code 的底层工具（Read / Write / Bash / Agent / TeamCreate …）是股票——直接、原始、灵活，但你得自己懂市场
superpowers 这种独立 skill（TDD / debugging / writing-plans）是基金——把一类通用能力打包成 best practice，你买入就能用
agent-team 这种建立在其他 skill 之上、协调其他 skill 的 skill 是投顾——它不直接产生 alpha，而是告诉你”什么场景该买哪只基金、什么场景该直接买股票”

投顾的价值不在于推荐的某只基金多牛，而在于资产配置和择时：lead 决定何时调 superpowers:brainstorming、何时让 teammate 调 subagent-driven-development、何时让 reviewer 调 code-review:code-review

不重复提示词#

投顾的另一面是克制：它不应该把基金的招股说明书再抄一遍。这是 agent-team 的核心约束：

能通过 ToolSearch 查到的 Tool Description（TeamCreate / SendMessage 的具体参数和用法），不出现在 SKILL.md 或 references 里
superpowers 系列 skill 已经写了的内容（TDD 怎么走、subagent-driven-development 模式），不出现在 references 里
references 里写过的内容（superpowers workflow 的步骤映射），不出现在 SKILL.md 里

每段提示词只存在于唯一一个地方。重复 = 漂移源：当 TeamCreate 的描述更新了而你的 SKILL.md 抄了一份旧版本，下一次 coordination 就出 bug。所以 SKILL.md 反复用 “the descriptions returned are the authoritative reference”，强制 agent 去查 live schema 而不是读 skill 里的转述

两个 subskill 的拆分#

为什么不合成一个 skill？因为 lead 和 teammate 的 “first action” 和 ongoing protocol 几乎不重叠：

lead 关心：TeamCreate 调用、spawn prompt 模板、什么时候 shutdown、git cleanup 顺序
teammate 关心：inbox sync 协议、dispatch 上限、什么时候该 SendMessage、怎么报告 DONE

混在一起每个角色要读 500+ 行的”和我无关”的内容。拆开后 lead 不需要知道 inbox sync 细节（那是 teammate 自己的事），teammate 不需要知道 TeamCreate 怎么调（lead 派完才轮到 teammate 活）

superpowers workflow 作为 reference doc 而非第三个 skill#

obra/superpowers 提供了一套 TDD 驱动的开发工作流：brainstorming → writing-plans → TDD implementer → reviewer → PR fix loop → merge。这套流程和 multi-agent team 正交——你可以用 team 跑非开发任务（research、文档梳理），也可以用 superpowers 但不开 team

所以接入方式不是写成第三个 skill，而是放在每个 skill 的 references/ 目录下：

lead/references/superpowers-workflow.md：lead 怎么把 superpowers 步骤映射到 team lifecycle
teammate/references/superpowers-implementer.md：implementer teammate 怎么走 TDD + 两阶段 review
teammate/references/code-review.md：reviewer teammate 怎么用 code-review:code-review 跟 implementer 反复迭代

reference doc 不占常驻 context，需要时 lead 在 Step 3 决定要不要 Read，spawn prompt 告诉新 teammate 去 Read 对应那份。plain team coordination 和 full superpowers workflow 复用同一套底层 primitive

最重要的一段：inbox sync 协议#

TeamCreate 描述里有句话：“Messages from teammates are automatically delivered to you. You do NOT need to manually check your inbox.” 这句话只在 turn 边界成立。单个 turn 内，你的 worldview 是冻结的，即便 peer 几毫秒前刚写了消息进你的 inbox

rendezvous failure

A 和 B 约好在 X 见面。A 朝 X 走。B 中途反悔，发消息说改到 Y。A 不查 inbox 继续走到 X，到了之后才发”我到 X 了”，然后才读 inbox，发现要去 Y。A 改道去 Y。同时 B 收到”我到 X 了”反悔回 X，发”那回 X”。循环下去两人永远差一步

修复方法：每个 step 完成后、每次主动 SendMessage 前，都 Read 一次 inbox。如果非空就停掉这一 turn，让 framework 在下一 turn 注入并清空 inbox。Read 是用来 check 的，不是用来 act 的——如果 inline 处理 inbox 而不停 turn，那条消息下一 turn 会被 framework 再次注入，处理两遍

hub-and-spoke 是 framework 硬限制#

Claude Code 的 agent team 是扁平的：teammate 不能 Agent(team_name=..., name=...) spawn 别的 teammate，也不能调 TeamCreate / TeamDelete。所有 team membership 都由 lead 管

实际后果：

teammate 觉得工作量大，应该 SendMessage lead 求人，而不是自己尝试 spawn
整个 team 的 dispatch 深度上限是 lead → teammate → subagent，再深被 framework 拒
工作流设计时不要假设 teammate 能调 teammate

安装#

两步装好：

Terminal window

1
/plugin marketplace add Fomalhaut647/plugins
2
/plugin install agent-team@fomalhaut647-plugins

@ 前的 agent-team 是 plugin name，@ 后的 fomalhaut647-plugins 是 marketplace name

怎么用#

模式一：纯协作（无 superpowers）#

让 Claude Code 调用 Skill('agent-team:lead')，它会引导你跑完整 lifecycle。spawn prompt 里只需让新 teammate 第一动作调 Skill('agent-team:teammate')，剩下协议由那个 skill 接管。适合 research、文档梳理之类不涉及 spec/plan/PR 的任务

模式二：完整 superpowers workflow#

从 Skill('agent-team:lead') 进，让 lead 在 Step 3 Read superpowers-workflow.md。spawn prompt 里告诉每个 teammate 也 Read 对应那份 reference doc

lead 视角#

docs/ layout 约定

长周期、跨多 session 推进的项目下推荐用一套标准 docs/ 目录：vision.md（永恒愿景）/ overview.md（当前版本地图）/ specs/<module>.md（按功能模块切分）/ plans/PlanN-<teammate>.md（每 session × 每 teammate 一份独立 plan）/ progress/PlanN-<teammate>.md（与 plan 1:1 对应的交付报告）/ archive/（冻结历史）。下面 lead 步骤里出现的路径都来自这套约定，不采用时把它当作”随 brief 说的位置”即可

在 main 分支调 superpowers:brainstorming 跟用户对齐方案，结果覆盖 docs/specs/<module>.md（brainstorm 产物必须存活在 main 历史里，每个 worktree 后续都对照它）
仍在 main 分支调 superpowers:writing-plans，每个 teammate 一份独立的 docs/plans/PlanN-<teammate>.md——不写共享 PlanN.md overview（cross-cutting context：session scope、为何这样切分、teammate 间依赖，全部写进 lead 的 spawn prompt 而不入 doc）。plan 里显式标注哪些任务能并行（决定要派几个 implementer teammate）
调 superpowers:using-git-worktrees，按 plan 的并行切分串行创建 worktree（EnterWorktree → ExitWorktree(action="keep") 循环，因为单会话只能 active 一个 worktree）
TeamCreate + TaskCreate，一条消息里并行 spawn 所有 implementer teammate（多条消息会串行）
监控 SendMessage，等 implementer 发来 PR URL
每收到一个 PR URL，spawn 一个 reviewer-pr-<N> teammate（无 worktree，code-review:code-review 操作 PR diff 经 gh）
监控 implementer ↔ reviewer 之间的 fix loop，不干预除非卡住
全部 **APPROVED** 后，先向用户报告状态、要 shutdown approval，再单独要 merge approval（不要捆绑）
并行 shutdown_request → 等所有 shutdown_response 回来
对每个 implementer：EnterWorktree(name=...) + ExitWorktree(action="remove") 清 worktree，然后 gh pr merge 合 PR
验证每个 docs/progress/PlanN-<teammate>.md 已落在 main（implementer 在自己 PR 里写的，merge 完应该都在）。少了就 placeholder 一段或问用户怎么处理——这些文件是项目对 “实际发生了什么” 的永久记录
TeamDelete()

implementer teammate 视角#

被 spawn 后第一动作：

Skill('agent-team:teammate')——加载 team primitive 协议（inbox sync / dispatch 上限）
Read references/superpowers-implementer.md——加载 implementer 角色工作流
立刻 TaskCreate 把整个 session 要做的事建成 task list——在 EnterWorktree / Read docs / 派任何 subagent 之前。每个 Task A/B/C… 都拆成”implementer subagent dispatch”+“spec reviewer dispatch”+“code-quality reviewer dispatch”三条，最后再补 wrap-up + PR + fix loop 各一条。理由：implementer 经验上最常见的失败模式是”做完一件忘了下一件”——漏激活 skill / 漏读 prompt 模板 / 漏派 reviewer subagent / PR 开完忘记 fix loop。Task list up-front 让每个 skill 激活、reference 读取、subagent dispatch 都被显式承认 + 完成后被 mark off，比仰赖记忆稳健得多

然后 startup：

先调两个 superpowers skill：subagent-driven-development / dispatching-parallel-agents——在第一个任务开始之前就把”orchestrate don’t code”的纪律设上，防止工作压力一来就退回直接写代码。using-superpowers 由 hook 自动注入，不需要显式 invoke
EnterWorktree(path="...") 进 lead 预创建的 worktree
读 overview / vision（若存在）/ 自己 module 的 spec / 自己那份 docs/plans/PlanN-<your-name>.md——你只读自己的 plan，其他 teammate 的 plan 路径不进你的 context

每个任务的工作循环：

派 implementer subagent：dispatch prompt 必须显式列出该激活的 skill 和触发条件（superpowers:test-driven-development 在起手、systematic-debugging 在遇 bug、verification-before-completion 在报 DONE 前），并要求 subagent 在 DONE 报告里列出激活了哪些 skill。不能写”use TDD”这种含糊指令，subagent 会伪服从（跳过 RED 阶段、编造验证报告）
派 spec-compliance reviewer subagent 用 superpowers:requesting-code-review
派 code-quality reviewer subagent——两阶段 review 抓不同抽象层
收 reviewer 反馈走 superpowers:receiving-code-review 五步流程（read → understand → verify → evaluate → respond），不凭直觉判断 false positive
修复 → 重派 reviewer，直到两个 reviewer 都通过
TaskUpdate(status="completed") → 读 inbox check → 继续下一任务

所有任务做完：

superpowers:finishing-a-development-branch 选 Option 2 (Push and Create PR)
创建自己的 docs/progress/PlanN-<your-name>.md——和 plan 文件 1:1 对应，写你 module 实际发生了什么：实现了什么、哪里偏离 spec/plan、跳过了什么及为何、未解决 concern、follow-up 建议。每 teammate 独立文件，所以并行 PR 永远不会在这条路径冲突
commit-commands:commit-push-pr 处理 commit + push + 开 PR（progress 文件作为同一 PR 的一部分一起 commit）
SendMessage lead 报 PR URL（先做 before-SendMessage 的 inbox check）
不要 ExitWorktree(action="remove")——lead 在 Step 10 自己清，你保留 worktree on disk 等着（实际上 teammate 不是 worktree 的创建者，本来就清不掉）

收到 reviewer “go pull review” 消息后：

gh api repos/{owner}/{repo}/pulls/{N}/comments 拉完整 review thread
superpowers:receiving-code-review 评估每条
派 subagent 修复（先 systematic-debugging 调查，再 implementer 改，再两阶段 review 自审）
git push → SendMessage reviewer 求重审
reviewer 回 **Changes requested** → 循环；**APPROVED** → SendMessage lead 报最终状态后 idle

reviewer teammate 视角#

被 spawn 后：

Skill('agent-team:teammate')
Read references/code-review.md
不 EnterWorktree——你不需要（code-review:code-review 通过 gh 操作 PR diff，不需要本地 checkout）
Skill('code-review:code-review')——只调一次。这是个知识型 skill，激活后内部 pipeline（5 并行 reviewer subagent + Haiku confidence-score 过滤）操作步骤已驻在 context 里，后续每轮 review 直接按它的方法跑，不重复 invoke

每轮 review 循环：

跑 review pipeline（startup 已激活的 code-review:code-review）。派 subagent 时要在 prompt 里点名 PR head sha——subagent 默认 Read 拿的是 main checkout 的文件，不指就会审错版本（用 gh pr view <PR#> --json headRefOid -q .headRefOid 拿 sha，配合 gh pr diff / git show pr-<PR#>:<path> 等命令对齐 PR head）
gh pr comment <PR#> 把结论贴回 PR，首行必须是 **APPROVED** 或 **Changes requested**（implementer 解析首行判断 verdict）
SendMessage implementer 通知”已发 review”（before-SendMessage inbox check 先做）
idle 等 implementer 推 fix 来求重审，loop 回 1
**APPROVED** 后 SendMessage lead 报最终状态，idle 等 shutdown

为什么用 gh pr comment 而不是 gh pr review --approve？

GitHub 禁止 PR author 给自己 PR --approve。在单人开发 setup 里 reviewer 和 implementer 共用同一个 host gh 身份，会被算成”PR author”——所以 gh pr comment 加首行约定是 workaround

实战须知#

它仍然是实验性 feature，需要人工盯着#

抽象层级越往上堆，“转述”导致的指令漂移风险越大：lead 把纪律转述给 teammate，teammate 又转述给 subagent，每一层都有可能丢约束。哪怕 plugin 已经反复用 “the descriptions returned are the authoritative reference” 把转述压到最低，多 agent 协调本质上依然不稳定

实操时人类要盯着 teammate 是否在按约定走——尤其 session 刚开始那几步。经验是：teammate 前几步走对了（按 task list 推进、显式调该激活的 skill、有派 reviewer subagent），后续大概率会持续遵循；前几步偷懒了，剩下整个 session 一路漂移到面目全非的概率不低。不要 spawn 完就走开，盯到 teammate 跑过第一个 implementer + reviewer 周期、确认纪律真的设上了再放手

不要在文档和提示词里加时间限制#

不要在 plan、spec、spawn prompt、dispatch prompt 里写”XX 分钟内完成”、“先做最重要的 N 个”、“快速 review 一下”这类时间或优先级限制。AI 严重高估任务用时（在它眼里复杂工作可能只是几秒钟的 tool call），一旦感到”时间紧”就会优先跳过 review 这种非生产性步骤——伪服从地报 DONE 但实际跳过了 verification、跳过了 spec compliance check、跳过了 receiving-code-review 的五步流程

纪律本身没有时间成本上的浪费（review 不通过反而省时间），但 AI 不会自己做这个权衡。让纪律无条件成立，不给它任何借口跳过

什么时候用 team#

满足以下任一条件再考虑：

工作跨多 turn（你会把控制交还用户再回来继续）
两个以上角色要在共享代码库上并行推进
implementer 和 reviewer 要跑多轮 fix loop

如果只是一次性的并行 read / draft / analyze，用 superpowers:dispatching-parallel-agents 的 plain subagent fan-out 就够了，不要为了用 team 而用 team——协调有 overhead

后记#

这个 plugin 还在持续迭代，每次跑完真实的 multi-agent 任务都会回来调一些 wording。skill 里的每句话都来自一次具体的 coordination failure，所以 CLAUDE.md 里专门写了一条：“不要根据 ‘theoretically’ 的猜测改 skill”——动 wording 前必须跑一次真实 session 验证新版本不退化

仓库：https://github.com/Fomalhaut647/plugins/tree/main/plugins/agent-team，欢迎试用、提 issue

挑战宿舍最佳实践

Sat, 16 May 2026 00:00:00 GMT

全景图#

右上角摆路由器，用理线器让网线和电线沿着书柜壁整齐排列，wifi 覆盖全宿舍，手机也能高速冲浪

在空调管上卡一个挂钩，书包挂在那里，平板则藏在墙外侧

书柜和墙之间的空间摆一个小木柜，小木柜上再摆一个收纳箱放各种杂物和吃的喝的，茶叶等摆在暖气片上

耳机和帽子挂在衣柜侧壁上方，换季不穿的衣服放在两个大收纳箱里，藏到衣柜顶上

书柜中央的空格摆一套茶具，早上起来泡一壶茶，享受悠闲生活

主体区#

正前方摆一个 27 寸 OLED 显示器，右手边放一个电脑支架，支架上摆好 15.3 寸 MacBook Air，显示器上面放 2 个 14W 的灯，让熬夜写代码时座位如同白天一般敞亮，排插藏在显示器后面，充电线从 MacBook 后方绕到最右侧，需要充电时把线拉过来

工作时显示器可以并排放 5 个 Claude Code 会话，旁边的 MacBook 还能显示其他资料，办公效率大大提升

平板&理线器#

2 根大功率 Type-C 充电线 + 1 根 Micro-B 能解决一切充电问题，3 根线从红圈处的理线器统一接出，完全不会乱

我在书柜侧面装了一个金属滑轨，可以把平板卡进去，这样就不用在寸土寸金的书柜正面腾一块空间放平板了

干饭图#

干饭时把鼠标垫往前推，防止饭菜掉到鼠标垫上

吃完后用湿纸巾把玻璃板擦干净，用干纸巾把水擦掉，最后把鼠标垫拖回来

为什么 AI 时代更应该使用双拼

Sat, 16 May 2026 00:00:00 GMT

也许是中文输入的最佳实践——每个汉字固定两次击键，节奏稳定到可以闭着眼打字。

起因#

在程序员键盘的最佳实践里我说过：进入 vibe coding 时代之后打字速度反而更重要了，因为提示词要反复增删改、写得很长。

但那篇文章只讲了敲键这一层——把每颗键都拉回主键区，减少手指的物理移动。中文比英文还多了一层独立的开销：从拼音到汉字的映射——同样想表达的意思，要敲多长一串拼音才能上屏。全拼在这一层吃亏最大。

和 AI 协作的过程里，真正在写的中文比想象中多得多：

提示词里描述需求、列约束、举反例——大段中文
review AI 输出后写中文反馈，让它改 / 重写 / 走另一个方向
微信、博客、笔记——日常文字本来就以中文为主

英文有它的快捷键和符号优化策略；中文输入的策略是：减少每个汉字的击键数 和 减少歧义。本文要讲的方案——双拼——正是为此而生的。

全拼的瓶颈#

全拼的核心开销很简单——每个字都要敲一整串拼音：

「我」wo → 2 键
「是」shi → 3 键
「双」shuang → 6 键
「重」chong → 5 键

声母 + 韵母的总长度从 2 到 6 个字母不等，平均一个汉字 3–5 次击键。键击数随拼音长度线性增长，长拼音的字尤其吃亏。

另一个更隐蔽的问题是汉字切分的歧义。全拼的拼音流是连续的字母序列，输入法要靠概率猜在哪里切——xian 是「线」还是「西安」？切错了就要回头改。这种歧义在部分场景里会反复出现，每次出现都要打断节奏。

什么是双拼#

双拼 = 一个键击声母 + 一个键击韵母 = 每个汉字固定 2 次击键。

核心思路非常简单：把所有声母（b/p/m/f/.../zh/ch/sh）映射到 26 个字母键上，每个声母一个键；把所有韵母（a/o/e/.../ang/eng/iong）也映射到 26 个字母键上，每个韵母一个键。打字时先按声母键、再按韵母键，两键合起来就是这个汉字的拼音。

举例（小鹤双拼方案）：

「中」zhong → zh + ong → v + s → vs
「国」guo → g + uo → g + o → go
「双」shuang → sh + uang → u + l → ul
「拼」pin → p + in → p + b → pb

一个长拼音如 shuang 从 6 键压缩到 2 键，一个短拼音如 wo 仍然是 2 键——任何汉字都是 2 键，节奏完全均匀。

双拼不改变拼音规则

双拼只是把拼音「压缩编码」到键盘上，拼音规则本身没变。你不需要重新学拼音，也不需要换输入法软件——主流输入法（系统拼音、微信输入法、搜狗、Rime 等）都内置了双拼方案，开关藏在设置里。

双拼方案的选择：小鹤#

双拼有不少方案——自然码、微软双拼、智能 ABC、小鹤、搜狗——本质都是「声母 + 韵母」的 26 键映射，区别在于具体怎么映射。

我用的是 小鹤双拼。我当年选择方案时没认真比较各家的方案，只是看推荐小鹤双拼的比较多就选了它，下面三条理由是 Claude 整理的，供参考：

跨平台支持最完整：macOS / iOS / Windows / Linux / Android 的几乎所有主流输入法都内置小鹤方案，换设备零迁移成本
韵母布局贴近发音：例如 ang 在 h、eng 在 g、iao 在 n，许多韵母键位和发音口型/形声有联想，记忆负担小
生态成熟：练习网站、教程、键位资料都最丰富，遇到问题搜得到答案

其他方案也不差

选哪个其实没那么关键——任何一个方案都比全拼快得多。如果你的设备主力是 Windows 且不打算装第三方输入法，微软双拼是阻力最小的入口（内置免安装）；搜狗输入法的老用户可以直接用搜狗双拼；其他场景我都推荐小鹤。

小鹤双拼键位映射#

完整的键位布局如下：

小鹤双拼键位映射

记忆有两个要点：

单字母声母 / 单字母韵母位置不变：b/p/m/f/... 还是按它们原来的键；a/o/e/i/u 也还是按它们原来的键。所以「我」wo 还是敲 wo 两键，没有变化
真正要记的是：3 个双字母声母（zh/ch/sh → v/i/u），以及若干双字母韵母（如 ang → h、ong → s、uang → l）。一共 20 多个映射，和背单词比起来这点量微不足道

全拼 vs 小鹤击键对比#

把双拼的优势量化一下。下面是一些典型词组的击键数对比（不计选词键）：

词组	拼音	全拼击键	小鹤双拼	小鹤击键
我们	`wo men`	5	`wo mf`	4
双拼	`shuang pin`	9	`ul pb`	4
中国	`zhong guo`	8	`vs go`	4
输入	`shu ru`	5	`uu ru`	4
上下文	`shang xia wen`	11	`uh xx wf`	6
提示词	`ti shi ci`	8	`ti ui ci`	6
人工智能	`ren gong zhi neng`	14	`rf gs vi ng`	8
重新生成	`chong xin sheng cheng`	18	`is xb ug ig`	8

平均下来击键数大约减半。再叠加上面提到的「切分无歧义」——双拼里每个字固定 2 键，输入法不需要猜在哪里切，整句输入更顺。

双拼还能解决「切分」

全拼里 xian 既可能是「线」也可能是「西安」，输入法要猜；双拼里「线」xm 和「西安」xian 完全无歧义

学习曲线：阵痛期一两周，回报终身#

从全拼切到双拼是肌肉记忆的彻底重建——你大脑里的「shang」会自动想敲 s-h-a-n-g，但双拼要你只敲 u-h，前几天每打一个字都要在心里默念韵母对应到哪个键，速度肯定大幅下滑。

我自己是高考完那个暑假学的双拼，到现在快三年了——具体每周的速度变化早就忘了，但过渡期比想象中短是肯定的：一两周之后就基本不影响日常使用，一两个月后彻底超过原来的全拼速度，之后就再也回不去了。

过渡期推荐找完整的两周

别在赶 ddl 或者要给老板写汇报的时候开始切——你会因为太慢而忍不住切回全拼，前功尽弃。找一段不那么赶的时间集中突击，比如假期前两周，效果最好。我自己选高考后的暑假就是这个考虑。

怎么练#

键位图打印贴显示器边上：忘了就查映射图
练习网站：搜「小鹤双拼练习」能找到很多 web 工具，例如双拼练习（无需注册，输入文本就开始练）
日常切换 = 最好的练习：聊微信、写笔记、写代码注释、和 AI 对话——一切场景全用双拼，不留退路

口诀

网上有一些小鹤口诀，但我不习惯使用口诀，习惯强行背诵。强行背诵、直接打字、忘了查图、加深记忆——一周不到键位就刻进手指了，根本不需要口诀。

AI 时代的具体收益#

回到开头的论点。讲完了双拼本身，最后说说为什么 AI 时代这件事比以前更值得做。

提示词撰写#

我每天写给 Claude / GPT / Gemini 的中文提示词加起来轻松上千字甚至上万字。这些文字的特点是：

长：要把约束 / 目标 / 反例都说清楚
反复改：第一版不够好就追加上下文、调措辞、加例子
思考密度高：每句话都是在精确表达需求，思考速度远跟不上输入速度的话，很容易丢掉刚才想到的细节

双拼把每个汉字的输入开销降到最低，让手指跟得上脑子——这才是 AI 时代它最大的价值。

微信、飞书、博客#

和 AI 协作之外的中文输入场景同样高频：和团队同步进展、和朋友闲聊、写 commit message 的中文部分、写博客——这些场景全都受益。双拼是一次性投资、终身受益。

最后一句总结：双拼不是给”打字快的人”的高级玩具，而是给”经常用中文表达”的人的基础设施。AI 时代每个人都在大量用中文和模型对话——这是历史上中文输入需求最旺盛的一个时代，没有理由继续忍受全拼。

程序员键盘的最佳实践

Sat, 16 May 2026 00:00:00 GMT

也许是程序员键盘的最佳实践，它是我创造的东西里我最喜欢的——一把自己组的客制化机械键盘。

起因#

打字速度其实非常重要。即便进入了 vibe coding 时代、人类已经很少手写代码，提示词的撰写依然繁琐：为了把每个细节说清楚，提示词往往写得很长，还要反复增删改。打字速度仍然是码字效率的核心。

本文只讲键盘这一层

输入效率可以分两层来看：一层是敲键本身——手指在物理键盘上的移动距离；另一层是从拼音到汉字的映射——同样的中文意图需要敲多少个键。本文聚焦前者；后者请见为什么 AI 时代更应该使用双拼。

而真正的瓶颈往往不是十指的快慢，而是手指频繁离开主键区：下划线 _ 离主键区很远还要按 Shift；括号 ()/[]/{} 要伸到右上角；运算符 +/-/* 在最远的右上角；方向键更是要把整只右手挪走——单看每个操作都很轻，叠起来就是一笔不小的「打字税」。

理想的状态是所有常用符号和功能键都在主键区一格之内，手指几乎不离开 ASDF/JKL; 这一带。这就是本文要讲的方案能做到的事。

解决方案：Via 改键#

Via 是一个可视化的键盘改键工具——浏览器打开，连上键盘，点选 + 拖拽即可重映射每一颗键，还能定义多个图层 (Layer)。

图层的切换有两种常见模式：按住触发键时进入图层、松手即返；或者按一下松开就切换到图层、再按一下切回。我用的是前一种——按住 Fn 时，H/J/K/L 不再是字母而是 Left/Down/Up/Right，松开 Fn 立刻回到字母层。于是输入符号不再需要大范围移动手指——除了阿拉伯数字，所有字母和符号的手指移动距离都不超过一格。

关于键盘是否支持 Via

不是所有键盘都支持 Via，购买前可以直接询问商家。我用的是唯咖（weikav）Lucky65 V2，支持 Via，不过无线模式下复杂的 Via 操作有 bug——烧录必须在有线下完成，平时使用也建议保持有线，否则部分映射会失效。

三处核心改动#

整套方案归根结底只有三处关键改动：

Caps 改为短按 Esc / 长按 Fn——Caps 是左小指最容易触及的位置，而大写锁定平时根本用不上。把它改造成 Esc + Fn 的双功能键性价比极高：Esc 本身就是高频键（很多工具用它退出、Claude Code 双击 Esc 触发 /rewind），vim 用户更是离不开它
添加大量 Fn 组合键——把所有常用符号、方向键、功能键塞进 Fn 层
交换 ; 和 /，用 : 和 " 覆盖原本 ; 和 ' 的位置——: 在写代码时比 ; 高频得多（Python、字典、JSON、TypeScript 类型注解全都用它），右小指本位键留给更常用的字符更划算

调整后的两层布局如下：

表层布局

Fn 层布局

Fn 层映射示例#

下面是几组高频用到的 Fn 组合键，完整映射可见后文的 Via json 文件：

方向键：Fn + H/J/K/L → Left/Down/Up/Right（vim 风格）
翻页：Fn + N/M → Pagedown/Pageup
退格：Fn + D → Backspace
回车：Fn + ; → Enter
下划线：Fn + F → _
运算符：Fn + G/S/B → +/-/*
括号：Fn + I/O/P → ()/[]/{}
数字行符号：Fn + Q/W/E/R/T/Y/U → !/@/#/$/%/^/&

方向键映射比 vim 更适合中文用户

中文用户在码字时频繁切换输入法——英文敲代码 / 提示词、中文敲提示词的描述部分。vim 普通模式下中文输入法有 bug：按 J 期望下移一行，输入法会把它当作字母键拦截、进入输入状态。而 Fn + J 直接映射到系统的下方向键，无论当前输入法是中文还是英文，按下去都是下移一行，不需要先切换输入法。

括号用宏实现自动配对

Fn + I/O/P 并不是输出单个左括号，而是用 Via 的宏功能一次性输出左右括号、并把光标定位到中间。这样做有两个好处：

节省按键位：左右括号合并为一颗键，原本 () / [] / {} 需要 6 个键位，现在压缩成 3 个。主键区一格之内就能塞下三种括号
跨编辑器配对：大多数 IDE 已经做了自动补完，但终端和纯文本编辑器没有——键盘自带这功能后所有场景统一

常用组合键演示#

Fn 改键之后，配合 OS 级别的快捷键（macOS 用 Cmd、Windows 用 Ctrl），左手小指按住 Caps（即 Fn）的同时其他手指几乎不用移动就能完成大量编辑动作：

跳到行首：Cmd + Caps + H——左手大拇指按 Cmd、左手小指按 Caps、右手食指按 H → 触发 Cmd + Left
跳到行尾：Cmd + Caps + L——右手无名指按 L → 触发 Cmd + Right
删除整行：Cmd + Caps + D——左手中指按 D → 触发 Cmd + Backspace

再也不需要把右手挪到方向键区，也不需要去摸 Home / End / Backspace。

顺便说：macOS 的按键布局比 Windows 更人体工学

macOS 上最常用的修饰键 Cmd 紧挨着空格，左手大拇指直接就能按到；而 Windows 上最常用的 Ctrl 在键盘最左下角，左手小指要大幅外移才能够到。这就是为什么 macOS 上「大拇指 + 字母键」可以舒服地一只手完成，Windows 上等价操作总要把整个左掌扭一下——同样的快捷键，体感差很多。

Via 配置文件#

完整的 Via json 配置文件（导入 Via 后可直接复用）：

1
{
2
  "name": "Lucky65V2",
3
  "vendorProductId": 875422727,
4
  "macros": [
5
    "{+KC_LSFT}{1}9{1}0{1}{-KC_LSFT}{1}{+KC_LEFT}{1}{-KC_LEFT}",
6
    "[{1}]{1}{+KC_LEFT}{1}{-KC_LEFT}",
7
    "{+KC_RSFT}{1}[{1}]{1}{-KC_RSFT}{1}{+KC_LEFT}{1}{-KC_LEFT}",
8
    "",
9
    "",
10
    "",
11
    "",
12
    "",
13
    "",
14
    "",
15
    "",
16
    "",
17
    "",
18
    "",
19
    "",
20
    ""
21
  ],
22
  "layers": [
23
    [
24
      "KC_GRV",
25
      "KC_1",
26
      "KC_2",
27
      "KC_3",
28
      "KC_4",
29
      "KC_5",
30
      "KC_6",
31
      "KC_7",
32
      "KC_8",
33
      "KC_9",
34
      "KC_0",
35
      "KC_MINS",
36
      "KC_EQL",
37
      "KC_BSPC",
38
      "KC_NO",
39
      "KC_TAB",
40
      "KC_Q",
41
      "KC_W",
42
      "KC_E",
43
      "KC_R",
44
      "KC_T",
45
      "KC_Y",
46
      "KC_U",
47
      "KC_I",
48
      "KC_O",
49
      "KC_P",
50
      "KC_LBRC",
51
      "KC_RBRC",
52
      "KC_BSLS",
53
      "KC_NO",
54
      "LT(1,KC_ESC)",
55
      "KC_A",
56
      "KC_S",
57
      "KC_D",
58
      "KC_F",
59
      "KC_G",
60
      "KC_H",
61
      "KC_J",
62
      "KC_K",
63
      "KC_L",
64
      "KC_SLSH",
65
      "S(KC_QUOT)",
66
      "KC_ENT",
67
      "KC_NO",
68
      "KC_NO",
69
      "KC_LSFT",
70
      "KC_Z",
71
      "KC_X",
72
      "KC_C",
73
      "KC_V",
74
      "KC_B",
75
      "KC_N",
76
      "KC_M",
77
      "KC_COMM",
78
      "KC_DOT",
79
      "S(KC_SCLN)",
80
      "KC_RSFT",
81
      "KC_UP",
82
      "KC_NO",
83
      "KC_NO",
84
      "KC_LCTL",
85
      "KC_NO",
86
      "KC_LALT",
87
      "KC_LGUI",
88
      "KC_SPC",
89
      "KC_SPC",
90
      "KC_SPC",
91
      "KC_RGUI",
92
      "KC_RALT",
93
      "KC_LEFT",
94
      "KC_DOWN",
95
      "KC_RGHT",
96
      "KC_NO",
97
      "KC_NO",
98
      "KC_MUTE"
99
    ],
100
    [
101
      "QK_CLEAR_EEPROM",
102
      "KC_F1",
103
      "KC_F2",
104
      "KC_F3",
105
      "KC_F4",
106
      "KC_F5",
107
      "KC_F6",
108
      "KC_F7",
109
      "KC_F8",
110
      "KC_F9",
111
      "KC_F10",
112
      "KC_F11",
113
      "KC_F12",
114
      "RGB_TOG",
115
      "KC_NO",
116
      "TO(3)",
117
      "S(KC_1)",
118
      "S(KC_2)",
119
      "S(KC_3)",
120
      "S(KC_4)",
121
      "S(KC_5)",
122
      "S(KC_6)",
123
      "S(KC_7)",
124
      "MACRO(0)",
125
      "MACRO(1)",
126
      "MACRO(2)",
127
      "KC_NO",
128
      "CUSTOM(7)",
129
      "RGB_MOD",
130
      "KC_NO",
131
      "KC_TRNS",
132
      "S(KC_SLSH)",
133
      "KC_PMNS",
134
      "KC_BSPC",
135
      "S(KC_MINS)",
136
      "KC_PPLS",
137
      "KC_LEFT",
138
      "KC_DOWN",
139
      "KC_UP",
140
      "KC_RGHT",
141
      "KC_ENT",
142
      "KC_QUOT",
143
      "RGB_HUI",
144
      "CUSTOM(5)",
145
      "KC_NO",
146
      "KC_TRNS",
147
      "KC_GRV",
148
      "KC_BSLS",
149
      "KC_DEL",
150
      "KC_PEQL",
151
      "KC_PAST",
152
      "KC_PGDN",
153
      "KC_PGUP",
154
      "S(KC_BSLS)",
155
      "S(KC_GRV)",
156
      "KC_SCLN",
157
      "KC_TRNS",
158
      "RGB_VAI",
159
      "CUSTOM(6)",
160
      "KC_NO",
161
      "KC_TRNS",
162
      "KC_NO",
163
      "KC_TRNS",
164
      "KC_TRNS",
165
      "CUSTOM(7)",
166
      "KC_TRNS",
167
      "CUSTOM(7)",
168
      "KC_TRNS",
169
      "KC_TRNS",
170
      "RGB_SPD",
171
      "RGB_VAD",
172
      "RGB_SPI",
173
      "CUSTOM(0)",
174
      "CUSTOM(1)",
175
      "KC_MUTE"
176
    ],
177
    [
178
      "QK_CLEAR_EEPROM",
179
      "KC_MYCM",
180
      "KC_WWW_HOME",
181
      "KC_MAIL",
182
      "KC_CALC",
183
      "KC_MSEL",
184
      "KC_MSTP",
185
      "KC_MPRV",
186
      "KC_MPLY",
187
      "KC_MNXT",
188
      "KC_MUTE",
189
      "KC_VOLD",
190
      "KC_VOLU",
191
      "RGB_TOG",
192
      "KC_NO",
193
      "TO(3)",
194
      "CUSTOM(0)",
195
      "CUSTOM(1)",
196
      "CUSTOM(2)",
197
      "CUSTOM(5)",
198
      "CUSTOM(6)",
199
      "KC_TRNS",
200
      "KC_TRNS",
201
      "KC_TRNS",
202
      "KC_TRNS",
203
      "KC_PSCR",
204
      "KC_TRNS",
205
      "KC_TRNS",
206
      "RGB_MOD",
207
      "KC_NO",
208
      "KC_TRNS",
209
      "KC_TRNS",
210
      "KC_TRNS",
211
      "KC_TRNS",
212
      "KC_TRNS",
213
      "KC_TRNS",
214
      "KC_SLCK",
215
      "KC_PAUS",
216
      "KC_HOME",
217
      "KC_END",
218
      "KC_TRNS",
219
      "KC_TRNS",
220
      "RGB_HUI",
221
      "KC_TRNS",
222
      "KC_NO",
223
      "KC_TRNS",
224
      "KC_TRNS",
225
      "KC_TRNS",
226
      "KC_TRNS",
227
      "KC_TRNS",
228
      "KC_TRNS",
229
      "KC_TRNS",
230
      "KC_TRNS",
231
      "KC_TRNS",
232
      "KC_TRNS",
233
      "KC_TRNS",
234
      "KC_TRNS",
235
      "RGB_VAI",
236
      "KC_TRNS",
237
      "KC_NO",
238
      "CUSTOM(8)",
239
      "KC_NO",
240
      "KC_NO",
241
      "KC_TRNS",
242
      "CUSTOM(7)",
243
      "CUSTOM(7)",
244
      "CUSTOM(7)",
245
      "KC_TRNS",
246
      "KC_TRNS",
247
      "RGB_SPD",
248
      "RGB_VAD",
249
      "RGB_SPI",
250
      "KC_TRNS",
251
      "KC_TRNS",
252
      "KC_MUTE"
253
    ],
254
    [
255
      "KC_GRV",
256
      "KC_1",
257
      "KC_2",
258
      "KC_3",
259
      "KC_4",
260
      "KC_5",
261
      "KC_6",
262
      "KC_7",
263
      "KC_8",
264
      "KC_9",
265
      "KC_0",
266
      "KC_MINS",
267
      "KC_EQL",
268
      "KC_BSPC",
269
      "KC_NO",
270
      "KC_TAB",
271
      "KC_Q",
272
      "KC_W",
273
      "KC_E",
274
      "KC_R",
275
      "KC_T",
276
      "KC_Y",
277
      "KC_U",
278
      "KC_I",
279
      "KC_O",
280
      "KC_P",
281
      "KC_LBRC",
282
      "KC_RBRC",
283
      "KC_BSLS",
284
      "KC_NO",
285
      "LT(4,KC_ESC)",
286
      "KC_A",
287
      "KC_S",
288
      "KC_D",
289
      "KC_F",
290
      "KC_G",
291
      "KC_H",
292
      "KC_J",
293
      "KC_K",
294
      "KC_L",
295
      "KC_SLSH",
296
      "S(KC_QUOT)",
297
      "KC_ENT",
298
      "KC_NO",
299
      "KC_NO",
300
      "KC_LSFT",
301
      "KC_Z",
302
      "KC_X",
303
      "KC_C",
304
      "KC_V",
305
      "KC_B",
306
      "KC_N",
307
      "KC_M",
308
      "KC_COMM",
309
      "KC_DOT",
310
      "S(KC_SCLN)",
311
      "KC_RSFT",
312
      "KC_UP",
313
      "KC_NO",
314
      "KC_NO",
315
      "KC_LCTL",
316
      "KC_NO",
317
      "KC_LGUI",
318
      "KC_LALT",
319
      "KC_SPC",
320
      "KC_SPC",
321
      "KC_SPC",
322
      "KC_RCTL",
323
      "KC_RALT",
324
      "KC_LEFT",
325
      "KC_DOWN",
326
      "KC_RGHT",
327
      "KC_NO",
328
      "KC_NO",
329
      "KC_MUTE"
330
    ],
331
    [
332
      "QK_CLEAR_EEPROM",
333
      "KC_F1",
334
      "KC_F2",
335
      "KC_F3",
336
      "KC_F4",
337
      "KC_F5",
338
      "KC_F6",
339
      "KC_F7",
340
      "KC_F8",
341
      "KC_F9",
342
      "KC_F10",
343
      "KC_F11",
344
      "KC_F12",
345
      "RGB_TOG",
346
      "KC_NO",
347
      "TO(0)",
348
      "S(KC_1)",
349
      "S(KC_2)",
350
      "S(KC_3)",
351
      "S(KC_4)",
352
      "S(KC_5)",
353
      "S(KC_6)",
354
      "S(KC_7)",
355
      "MACRO(0)",
356
      "MACRO(1)",
357
      "MACRO(2)",
358
      "KC_NO",
359
      "CUSTOM(7)",
360
      "RGB_MOD",
361
      "KC_NO",
362
      "KC_TRNS",
363
      "S(KC_SLSH)",
364
      "KC_PMNS",
365
      "KC_BSPC",
366
      "S(KC_MINS)",
367
      "KC_PPLS",
368
      "KC_LEFT",
369
      "KC_DOWN",
370
      "KC_UP",
371
      "KC_RGHT",
372
      "KC_ENT",
373
      "KC_QUOT",
374
      "RGB_HUI",
375
      "CUSTOM(5)",
376
      "KC_NO",
377
      "KC_TRNS",
378
      "KC_GRV",
379
      "KC_BSLS",
380
      "KC_DEL",
381
      "KC_PEQL",
382
      "KC_PAST",
383
      "KC_PGDN",
384
      "KC_PGUP",
385
      "S(KC_BSLS)",
386
      "S(KC_GRV)",
387
      "KC_SCLN",
388
      "KC_TRNS",
389
      "RGB_VAI",
390
      "CUSTOM(6)",
391
      "KC_NO",
392
      "KC_TRNS",
393
      "KC_NO",
394
      "KC_TRNS",
395
      "KC_TRNS",
396
      "CUSTOM(7)",
397
      "KC_TRNS",
398
      "CUSTOM(7)",
399
      "KC_TRNS",
400
      "KC_TRNS",
401
      "RGB_SPD",
402
      "RGB_VAD",
403
      "RGB_SPI",
404
      "CUSTOM(0)",
405
      "CUSTOM(1)",
406
      "KC_MUTE"
407
    ],
408
    [
409
      "QK_CLEAR_EEPROM",
410
      "KC_BRIU",
411
      "KC_BRID",
412
      "KC_TRNS",
413
      "KC_TRNS",
414
      "KC_TRNS",
415
      "KC_TRNS",
416
      "KC_MPRV",
417
      "KC_MPLY",
418
      "KC_MNXT",
419
      "KC_MUTE",
420
      "KC_VOLD",
421
      "KC_VOLU",
422
      "RGB_TOG",
423
      "KC_NO",
424
      "TO(0)",
425
      "CUSTOM(0)",
426
      "CUSTOM(1)",
427
      "CUSTOM(2)",
428
      "CUSTOM(5)",
429
      "CUSTOM(6)",
430
      "KC_TRNS",
431
      "KC_TRNS",
432
      "KC_TRNS",
433
      "KC_TRNS",
434
      "KC_PSCR",
435
      "KC_TRNS",
436
      "KC_TRNS",
437
      "RGB_MOD",
438
      "KC_NO",
439
      "KC_TRNS",
440
      "KC_TRNS",
441
      "KC_TRNS",
442
      "KC_TRNS",
443
      "KC_TRNS",
444
      "KC_TRNS",
445
      "KC_TRNS",
446
      "KC_TRNS",
447
      "KC_TRNS",
448
      "KC_TRNS",
449
      "KC_TRNS",
450
      "KC_TRNS",
451
      "RGB_HUI",
452
      "KC_TRNS",
453
      "KC_NO",
454
      "KC_TRNS",
455
      "KC_TRNS",
456
      "KC_TRNS",
457
      "KC_TRNS",
458
      "KC_TRNS",
459
      "KC_TRNS",
460
      "KC_TRNS",
461
      "KC_TRNS",
462
      "KC_TRNS",
463
      "KC_TRNS",
464
      "KC_TRNS",
465
      "KC_TRNS",
466
      "RGB_VAI",
467
      "KC_TRNS",
468
      "KC_NO",
469
      "CUSTOM(8)",
470
      "KC_NO",
471
      "KC_TRNS",
472
      "KC_TRNS",
473
      "CUSTOM(7)",
474
      "CUSTOM(7)",
475
      "CUSTOM(7)",
476
      "KC_TRNS",
477
      "KC_TRNS",
478
      "RGB_SPD",
479
      "RGB_VAD",
480
      "RGB_SPI",
481
      "KC_TRNS",
482
      "KC_TRNS",
483
      "KC_MUTE"
484
    ]
485
  ],
486
  "encoders": [
487
    [
488
      ["KC_VOLU", "KC_VOLD"],
489
      ["KC_VOLU", "KC_VOLD"],
490
      ["KC_VOLU", "KC_VOLD"],
491
      ["KC_VOLU", "KC_VOLD"],
492
      ["KC_VOLU", "KC_VOLD"],
493
      ["KC_VOLU", "KC_VOLD"]
494
    ]
495
  ]
496
}

显示更多显示更少

关于键盘本身#

聊完软件层面再聊硬件。这一节简单介绍键盘选购的基础知识，给打算自己组一把客制化键盘的人作参考。

键盘类型#

按按键技术，键盘大致分四类：

薄膜键盘：所有按键共用一片硅胶 / 橡胶导电膜。便宜、安静，但手感和耐用度都差，长期使用容易疲劳
机械键盘：每颗按键有独立的「轴体」，根据触发方式和声音又能继续细分（见下一节）
光轴键盘：用红外光束被按键阻断来判定触发，触发响应比传统机械接触式更快
磁轴键盘：用霍尔效应感应磁铁与 PCB 的距离来判断按键深度。触发距离可以在 Via 等软件里自定义，电竞圈用得多

「静音」不是一个独立类别，而是机械键盘的一种附加属性——在轴的 stem 加阻尼材料降低声音即可。

机械轴的两个维度#

机械键盘的轴体可以按两个独立维度分类：

形态维度（决定键程长短）：

标准轴：键程约 4mm，触底反馈强烈，是经典手感
矮轴：键程约 3mm 甚至更短，键盘整体厚度也变薄。除了便携性更好，键程介于标准轴和薄膜之间，适合作为薄膜键盘到机械键盘的过渡

手感维度（决定段落感）：

线性轴（红轴、黄轴等）：按下到底全程没有阻力变化，丝滑顺畅
段落轴（青轴、茶轴等）：按到一定深度有明显的「咔哒」反馈，确认感强

市场上标准轴 + 线性轴的组合最为常见。

客制化键盘的三大件#

一把客制化机械键盘由三个部分组成，可以分别选购、自由搭配：

套件：键盘的「骨架」——包括外壳、PCB、定位板、卫星轴等。决定配列（68 / 75 / 84 / 全键等）、连接方式（有线 / 无线 / 三模）、以及是否支持 Via 等改键软件
轴体：决定手感和声音的核心
键帽：键盘的「皮肤」，影响外观和敲击声。常见材质有 ABS（亮、轻、易打油）和 PBT（哑光、重、耐磨）

我的选择#

套件：唯咖（weikav）Lucky65 V2，67 键。我不需要 F 区按键和小键盘，所以特意选了 65 配列——桌面占用最小，常用键一颗不少
轴体：高特青柠轴 V3，当时静音段落轴的王者之一（现在可能有更好的轴体了）
键帽：淘宝买的芙宁娜主题二创键帽

65 配列右侧那些键我其实都不用

经过 Via 改键之后，65 配列里右侧的方向键、右 Enter、右 Shift、Backspace 等键平时基本用不到——它们的功能都在 Fn 层有等价键，左手小指按住 Caps，其他手指移动不超过一格就能搞定。我甚至把最右侧的 4 颗特殊键直接设置成空白（按下去什么都不会发生），纯装饰。

为什么选段落轴 + 静音

我自己不太能接受线性轴——按下去全程没阻力变化，容易误触，少了一点「我按到了」的确认感。段落轴那种「咔哒」一下的反馈对我刚刚好。

同时强烈推荐学生选静音轴体：舍友睡觉时也能尽情码字、图书馆里也不必担心键盘声扰人，既不影响别人又能保持自己的码字节奏。

第一次组键盘的建议

每个人对手感的偏好差异极大，光看视频和评测很难选到合适的。

去线下店实际敲：键盘展、专卖店都能现场试不同轴体
买「轴体全家桶」：每种轴体各一颗 + 一个试轴器，自己在家对照按一按，选出最喜欢的再下单

为什么 Mac 比 Windows 优越

Sat, 16 May 2026 00:00:00 GMT

程序员的最佳生产力机器

起因#

我大学之前一直用 Windows 台式机，大一期间饱受惠普暗影精灵 9 的折磨，大二初换成 MacBook 后再没回头。AI 时代到来之后这个判断更坚定了：和 Claude / GPT 协作要频繁开终端、跑脚本、连服务器、改 dotfiles，这些动作 Mac 做起来都比 Windows 顺手一个量级。

两个我观察到的现象：

身边大量从 Windows 换到 Mac 的同学都后悔没早点换；反过来从 Mac 换回 Windows 的几乎没有。 这种不对称性是最直接的信号
国内外大厂——互联网巨头、AI 明星公司——给员工配的默认机型基本都是 MacBook。工业界用真金白银做出的选择

用一句话概括我的立场：Linux 是工作，Mac 是生活，Windows 是游戏。展开就是我心目中的程序员最佳配置三件套：

MacBook Air 作为主力机——除了游戏，几乎所有事都在这上面完成：写代码、写文档、刷网页、看视频、剪辑
Windows 台式机作为游戏机——只装游戏，享受老黄的 DLSS
远程 Linux 服务器——本地 Mac 做不动的重体力活（如训练模型）扔到服务器上

下文展开讲为什么”生活”那一档 Mac 比 Windows 更适合程序员。

Unix 内核：和 Linux 服务器一脉相承#

这是 Mac 对程序员最大的优势。macOS 基于 Unix（具体说是 Darwin 内核 + BSD 用户态工具），和部署生产服务用的 Linux 是近亲。具体好处：

shell 工具同源：bash / zsh / grep / sed / awk / find / ssh / curl 本地直接能用，本地写好的脚本几乎可以原封不动丢到服务器上跑
ssh 一行连服务器：终端打开就有 ssh，不需要 PuTTY、Xshell 这类 Windows 平台的第三方客户端
Homebrew 一行装一切：brew install <package> 类似 apt install，主流开发工具基本都有现成的包，Chrome 等常用软件也能安装
dotfiles 跨机器同步：本地 Mac 和远程 Ubuntu 服务器都是类 Unix 系统，同一份 .bashrc / .zshrc / .tmux.conf 可以直接共用——详见跨机器同步数据

Windows 的对策是 WSL（Windows Subsystem for Linux），但本质上是在 Windows 上再开一台虚拟 Linux——这是补救方案，不是原生方案。文件系统、网络、剪贴板、终端这些跨边界的体验始终隔着一层。WSL 能用，但用起来总有”系统里再套一个系统”的别扭。

唯一稍弱的是包管理生态

Linux 上 apt / dnf 的官方源覆盖度比 brew 更广。但对程序员日常工具来说，brew 的覆盖已经完全够用——主流语言运行时、数据库、命令行工具一应俱全。而且这是 Linux 相比 MacOS 的优点，Windows 做得更差

Apple Silicon：性能、续航、噪声、屏幕#

2020 年后 Mac 切到了自研的 ARM 芯片（M1 / M2 / M3 / M4 / M5 系列），从此硬件层面也对 Windows 形成了代差优势：

性能：M 系列芯片的单核性能极强，在很多 Benchmark 里吊打同代 Intel / AMD 的移动端甚至桌面 CPU。日常开发、编译、跑测试当然绰绰有余；剪辑视频也是 Mac 擅长的事
统一内存 = 大显存：M 系列采用统一内存架构——CPU 和 GPU 共享同一块物理内存——配 64GB / 128GB 内存的 Mac 约等于拥有 64GB / 128GB 显存，跑本地 LLM 推理特别舒服。NVIDIA 同等显存的显卡价格能买好几台 Mac——如果说 Mac 的内存是金子做的，那 NVIDIA 的显存就是振金做的。本地大模型推理的性价比 Mac 完胜
续航：日常开发 + 浏览器 + 终端 + IDE，轻松撑满一整天。最典型的场景是上课——周围用 Windows 本的同学一进教室就在墙角排队抢插座，Mac 用户可以优雅地挑一个视野最好、离老师最近的座位坐一整天，期间不用充一次电
风扇噪声 + 不用清灰：M 系列 MacBook Air 直接无风扇被动散热，永远零噪声；没有风扇也就没有积灰，几年下来不用拆机清灰。MacBook Pro 在大多数日常负载下风扇也不转，跑 build 才偶尔转一下。Windows 笔记本则是一打开就嗡嗡响，用两年还要担心散热口堵灰
屏幕：Retina 显示屏 + 系统级 HiDPI 缩放，字体渲染细腻、缩放一致性好。Windows 上 HiDPI 缩放是出了名的坑——很多老程序在 4K 屏上糊成一片，或者控件错位
扬声器：MacBook 内置扬声器素质远超同价位 Win 本——空间音频、低频下潜、声场都接近便携音箱水准。开会、看视频、追剧不用再外接音响

品控与做工：MacBook 几乎没有翻车#

把上一节的硬件指标连同做工、品控一起看，MacBook 在做工 / 屏幕 / 扬声器 / 续航这些硬件维度上全面碾压同价位 Windows 笔记本——本节展开讲剩下的做工和品控。

品控是大学生小白最容易忽视、但最影响长期体验的一项。我大一用的是当年被称为”神机”的暗影精灵 9，bug 层出不穷——黑屏、插件自启动失败。这并不是个例，而是 Windows 笔记本市场的普遍现状。

B 站「笔吧评测室」做过一期大翻车？！为了验证品控，一次性测 40 台笔记本！，统计令人触目惊心：

笔吧评测室 40 台 Windows 笔记本品控测试

40 台 主流全新 Windows 笔记本，5 台严重缺陷、20 台中等缺陷、只有 15 台没问题或仅有轻微缺陷——超过一半有可见问题。

MacBook 这边在做工和品控上完全是另一个层级：

全金属一体 CNC 机身：抗弯折、质感扎实。很多 Windows 本的塑料 A 面甚至两指就能掰弯，键盘区按下去整面下陷
出厂良品率高：拿到手就能稳定用几年，几乎不需要返厂

对大学生尤其重要

大学生大多没有维修和返厂经验，电脑出问题就只能找不一定靠谱的第三方售后或者排队等官方售后。电脑这么重要的生产工具每天都要用，维修耽误的每一天都是巨大的损失，还可能遇到黑心维修商被宰——直接选品控稳的机型可以省掉一整条故障链。

另外补一句机型建议：MacBook Pro 14 寸是少有的 14 寸高性能笔记本——受制于 Windows 阵营 CPU 和 GPU 的发热，几乎没有 14 寸的 Win 游戏本，即使有也续航很差噪声很大。14 寸高性能 + 续航优秀 + 风扇极少响这三件事同时成立的，几乎只有 MacBook Pro。

键盘与触控板：人体工学差距#

我在程序员键盘的最佳实践里埋过一个伏笔：「macOS 的按键布局比 Windows 更人体工学」。这里展开讲一下：

Cmd 在拇指位：Mac 上最常用的修饰键 Cmd 紧挨着空格键，左手大拇指轻轻一压就能按到。常用快捷键如 Cmd + C/V/W/Q/Tab 几乎都是一只手就能完成
Ctrl 在小指位：Windows 上最常用的修饰键 Ctrl 在键盘左下角，左手小指要大幅外移才能够到，长期下来对小指不友好
快捷键约定统一：macOS 下 Cmd + W 关窗、Cmd + Q 退出、Cmd + , 打开偏好设置——几乎所有原生 App 都遵守这套约定，肌肉记忆全平台通用。Windows 上 Ctrl + W 在浏览器里能关标签页但在很多软件里没作用，约定的统一性差很多

触控板是 Mac 的另一张王牌，手感和功能在笔记本里独一档：

玻璃面板 + Force Touch：面积大、阻尼舒适、支持压感
手势丰富且全局一致：四指上滑切应用、四指左右切桌面、三指拖动、重按查词、双指捏合缩放（部分手势非默认）——这些手势在所有 App 里行为一致，且系统级响应跟手
接近鼠标体验：MacBook 触控板做到了”无外设也能舒服干活”——一些重度用户从不使用鼠标

Windows 笔记本的触控板这几年有进步，但驱动、手势一致性、跟手程度仍有明显差距。

我自己仍在用外接鼠标

我自己日常仍用鼠标——鼠标操控更精确、大范围移动更方便。只有在外工作、桌面不方便摆鼠标时，我才仅用触控板——而即便此时也完全够用。Mac 触控板的价值不是”逼你不用鼠标”，而是”当你没鼠标可用时不掉链子”。

软件层：原生 App 普遍精良 + 付费生态成熟#

macOS 的软件生态有两个隐性优势，叠加起来让 Mac 上的常用工具普遍精良：

Mac 用户习惯付费——开发者能赚到钱、愿意花时间打磨产品。Mac 上的付费软件生态比 Windows 好得多：精品笔记、剪辑、画图、效率工具、设计软件等大量优秀的付费 App 优先甚至只在 Mac 上发布
macOS 与 Linux 同源开发顺手——开发者本来就用 Mac 写 Linux 服务的代码，顺手做一个 Mac 客户端没什么额外学习成本。例如 Codex App 先有 Mac 版才有 Windows 版，而且 Mac 版往往比 Windows 版功能更丰富

具体到日常用的工具：

终端：自带 Terminal 已经够用，iTerm2 / Warp / Ghostty 等第三方终端把体验推到更高水准。Windows 上要装 Windows Terminal + WSL 才能勉强凑出类似体验
编辑器与 IDE：VS Code、JetBrains 全家桶、Cursor 等在 Mac 上字体渲染、动画、缩放都更顺
文件管理与启动器：Finder + Spotlight + Alfred / Raycast 组合，全局搜索、应用启动、剪贴板历史等高频操作都很顺手
窗口管理：原生的 Mission Control + 多桌面 + 全屏分屏；不够用还可以装 Rectangle / Magnet 等第三方工具

字体渲染、动画曲线、字距这些细节单看每条都不起眼，叠起来就是”用起来舒服”和”用起来糙”的本质差距。

Windows 也在追赶

Windows 11 + Windows Terminal + PowerToys 的组合体验比十年前的 Windows 好太多。但起点不一样——Mac 是原生顺手，Windows 是装一堆补丁去逼近原生顺手。

Mac 的缺点#

iPhone 与 Mac 的跨设备联动拉完了：iPhone ↔ Mac 的 AirDrop 很慢，通用剪贴板经常失败，实际体验还不如国产厂商的互联服务——vivo、OPPO 的手机和 Mac 互联做得比 iPhone 还流畅、稳定、功能全
游戏生态拉完了：大量游戏不支持 MacOS，MacOS 也没有 DLSS 这种技术，想玩游戏的话最好再配一台专门打游戏的 Windows 台式机。当然如果查到要玩的游戏有 Mac 版就不用配了
CUDA 训练是硬伤：深度学习训练几乎完全依赖 NVIDIA 显卡 + CUDA，Mac 在训练赛道上没有竞争力。本地跑大模型训练 / 微调建议直接租云上 GPU 或者用远程 Linux 服务器——这也正是为什么三件套里要给 Linux 服务器单独留一档。推理则是另一回事——见上文统一内存，Mac 反而是性价比最高的本地推理机
部分工业软件没有 Mac 版：CAD、某些专业打印 / 雕刻软件、部分国产办公套件等仍然只有 Windows 版

简单概括：编程 + 写作 + 视频 + 日常用 → Mac；游戏 → Windows；训练模型 / 重计算 → Linux 服务器。

总结#

回到开头那句话：Linux 是工作，Mac 是生活，Windows 是游戏。对程序员来说，Mac 不是”更贵的笔记本”，而是和 Linux 服务器同源、单核性能极强、统一内存即大显存、续航/噪声/屏幕/扬声器/做工/品控/触控板/软件生态全方位领先的一台生产力机器。它不解决游戏、不解决 CUDA，但解决程序员每天 8 小时盯着的那些事。

身边的换机方向是一面镜子：几乎每个从 Windows 换到 Mac 的人都后悔没早点换；反过来几乎没人愿意从 Mac 换回 Windows。和双拼、客制化键盘一样，换 Mac 是一次性投资、终身受益——用过就回不去了。

微信支付组合支付

Sat, 16 May 2026 00:00:00 GMT

我今天才知道微信支付可以组合支付，微信有心了

为什么你应该报考北大

Sat, 16 May 2026 00:00:00 GMT

适用范围

仅考虑北大信科 AI 方向的视角，其他院系未必如此

大部分课没有考勤：想去上课就去，不想去就不去，不用请假不用代课，算上考试我本学期在教学楼的时长不超过 30h
绝大部分课有回放：错过线下课可以听回放补救，学到简单的部分可以二倍速甚至快进掉，学到难的部分可以暂停查资料问 AI，学习进度完全由自己掌控
无宵禁不查寝：你可以在任何时间进出宿舍，导员只会在入学时来每个宿舍慰问一次，之后再也不会出现
无早晚自习无强制集体活动：军训后的三年时间里一次班主任和班干部都没见过（理论上应该在大三上讲保研的班会上见过一次，不过那次班会时我刚好在旅游）
选课自由：培养方案只是建议不是硬性要求，几乎所有课程没有选课限制，你可以在任何学期选修任何一门课，任何一门（学院会优先保证本专业同学选上，但通常有多余名额给其他人）。无论是跨专业体验生活，还是提前学重要的专业课，还是把任务多给分差又没用的课丢到大四，一切由你掌控
退课和缓考自由：除了开学前两周可以自由退课，期中时还有一次退课机会。除了体育课、实验课等课程，绝大部分课可以自由退课，退课和从来没选过这门课几乎等同。如果中期没退课，到期末时还有最后一次机会——缓考，但它和退课区别不大，依然约等于没修过这门课，只是可以冲突选课
文理兼备 + 旁听：除了式微的传统工科，你可以在北大找到几乎所有专业，于是你可以选修任何感兴趣的课程。如果只想听课不想做作业或考试，可以选择旁听，有时旁听的学生几乎和选课的学生一样多
转专业自由：没有转出限制——原院系不会卡你，只有转入限制——只要转入院系接收你，你就能转过去，即使是强基生也能自由转。可能是因为”差专业”的同学就业也没多差，因此门槛并不高
双学位：北大的双学位也很丰富，你可以修任何感兴趣的专业的双学位或辅修。重要的是如果不想修了，放弃双学位不会受到任何惩罚，还可以把双学位学分转移到主学位凑选修课学分。如果毕业时修了大部分课但没到双学位的标准，可以转为辅修，不至于前功尽弃
挂科”自由”：挂科后可以通过重修覆盖绩点，重修时拿多少分就覆盖为多少分，没有重修分数封顶 60 的限制。挂科重修也不影响信科的保研，只要保研时没有挂了还没重修的必修课即可
绩点改革：北大自 25 年秋季学期开始，不再限制优秀率，推广等级制，课程给分由各院系自己决定，减少内卷无效竞争。每个人每学期还可以选一门选修课设置为 PF（Pass or Fail），不计入绩点，于是可以自由地选感兴趣但拿不到高分的课
作业审查宽松：老师会吓唬你要查重或查 AI 率，实际上并不会查，部分老师甚至鼓励使用 AI 辅助完成作业。我本学期的几乎所有作业都是 AutoPKU 一键生成的——只要上课能通过考试、保研能做出科研、求职能通过面试，无人在意你的作业是不是自己写的，只有自己为自己负责
90% 保研线：保研率 50-60%，算上留学和就业的，保研最低排位可以划到 90% 左右，真正做到应保尽保
Top2 Title：有时 Title 和实习资源等不可兼得，比如对于金融专业的同学，上海高金可能比北大的实习资源更好，但 Title 更弱。如果你的本科一般，选北大读研刷 Title 可能是最优解；而北大本科的同学完全没有这个顾虑，可以硬气地不为 Title 妥协，直接选其他资源更好的去处
强大的校友资源：我们调侃 Deepseek、MiMo 等基模公司是红模（北大红），意思是在这些公司北大校友占主导地位。类似地，北大校友资源遍布各行各业，想就业的可以联系前辈内推，想创业的可以轻易见到许多投资人
科研环境：你可以在任何时候加入实验室，导师一般不会拒绝既免费又有潜力的劳动力，AI 方向各组顶会发表常态化，本科生挂个 co-author 并不困难。信科的大组有充足的算力资源，A100/H100 触手可得——其他学校博士才能用上的卡，你本科跟着导师或师兄师姐做科研时就能拿来跑课程作业，体验一把”算力管够”的感觉
学术追星：在其他学校开的讲座座无虚席的学术大拿亲自为你授课，还有各界名流经常开讲座（同时选修林毅夫和张维迎的课程，同时听截然相反的观点是有趣的体验）
全国最美校园之一：一塔湖图闻名遐迩，学校北部还有大片园林，风景宜人，非常适合幽会、散步、赏美景
伙食丰富：本部有十几个食堂 / 餐厅，能做到前两年每天不重样。在勺园中餐厅能用 50-100 的人均消费（取决于点什么菜）享受到 200 人均的美食，各地方菜系正宗美味，是接待亲朋好友的不二之选
宿舍体验：自 25 年开始，北大将逐步换成上床下桌，运气好的话可以分到。北大有不少本地人和在外租房的，因此四人间变三人间是常有的事。所有浴室都有帘子，洗澡时不用坦诚相对
Study Hard：北大有全国最大的图书馆之一，典藏丰富能找到各种小众书和古籍，同样也是自习好去处。北大还有许多近年刚装修好的自习室和大量空教室（很多人不知道四教的存在，因此在这里自习时常能一个人独享一间教室）
Play Harder：每周在五四操场上举办的主题夜奔、一时兴起在未名湖石舫聚众烧烤唱歌、一年一度的十佳歌手比赛（据说在其他学校能夺冠的高手可能连初赛都过不了）
人才辈出：身边人是全国 top 0.1%，“和优秀的人在一起”本身就是稀缺资源。AI 方向尤其卷出实力，不乏顶会一作、ICPC 金牌等——有时前一天晚上你还在和他联机电竞，第二天就得知他飞赴他国拿下国际大赛金牌
社团众多：上次百团大战共有 183 个社团参加，无论多么小众的兴趣都能在北大找到属于你的社团，某 985 取消动漫社展出的事情不可能在北大发生。什么你说真的没有你感兴趣的？不妨自己注册一个社团！
电影戏剧丰富：百周年纪念讲堂经常有文艺电影放映、戏剧表演，校内票价低廉，据说有不少隔壁的同学专程来北大看电影和戏剧
实习地利：北京基模公司和互联网公司密度全国第一，Deepseek、月之暗面、Minimax、字节等公司大都离学校不远。本科期间多段大厂实习是常态，远比异地通勤的同学舒服
北京文化资源：海量古迹、博物馆、人文景观，是历史爱好者和喜欢烟火气的人不能错过的城市
顶级医疗：校医院是二级综合医院，在校医院中算较好的。北医三院、人民医院等是北大直属附属医院，转诊方便，报销力度大
树洞文化：PKU 树洞匿名社区，吐槽、求助、二手交易、八卦，是了解校园真实生态的最佳窗口，没事刷刷比小红书好玩（什么你说一刷全是 #给给Popi，树洞是这样的）
思想自由兼容并包：北大是国内对边缘话题最宽容的校园之一，老师敢讲、社团敢办、学生敢问，这种氛围是其他高校稀缺的。例如不讲地震、讲炒股和交谊舞的”地震概论”，观点极具争议的”犹太文明”。学生也可以与老师平起平坐：某高数课原本有考勤，第一节课就有同学据理力争不应该靠考勤留住同学听课，老师真的听从建议取消了考勤；某门课的逆天老师不允许学生上课用电子产品，学生依然用电子产品，老师告到教务，教务让他别管

家飞猫抽卡大败而归

Thu, 14 May 2026 00:00:00 GMT

犹豫井新能还是奸商，想了想还是井了新能，万一以后时来运转歪出奸商了呢

大片瓷砖隆起

Wed, 13 May 2026 00:00:00 GMT

后续：工人师傅第二天早上八点过来把瓷砖全敲碎了

早八惊魂

读博会腐蚀灵魂

Tue, 12 May 2026 00:00:00 GMT

Xiaomi MiMo Orbit-百万亿 Token 创造者激励计划

Thu, 07 May 2026 00:00:00 GMT

领到了 $100 Max Token Plan，不错😋

是不是看到我提交的 Claude Max 20x 套餐支付截图就直接发最高档套餐了

虽然但是，这 API 定价是 Deepseek 7 倍了呀，真有人原价买吗

如果芙莉莲的魔导书是 Skills

Tue, 05 May 2026 00:00:00 GMT

看芙莉莲第二季时突然想到魔导书是不是一种 Skill: Agent 读了 Skill 就能学会一种能力，芙莉莲读了魔导书就能学会一种魔法

Agent 启动时把所有 Skills 的 description 加载进上下文，需要时再读全文

芙莉莲把整本书看完才能学会这个魔法，但之后就不用再看了，相当于每一个 skill 都全文加载（学这么多魔法真的不会撑爆上下文吗）

我学的不常用的知识似乎也是一种 Skill。第一遍学会了，但一段时间不用，细节已经忘了，只记得大概。但知道有这么个知识，等要用时知道要重学这个知识，临时重学并使用不久后又忘了。这不就相当于输入了 description，临时要用时再看正文吗？

记得刚入学时有朋友问，现在学习课内知识的意义何在，毕竟 AI 都会，就算现在 AI 不会，几年甚至几个月后也会了。当时我给出的回答之一是，不学的话没有这个认知，虽然需要用时可以问 AI 或直接让 AI 干活，但首先得能想到要用这个知识，人无法使用认知之外的能力。现在可以从 Skills 的视角来解读学习，学习是把 description 学会，知道有这个知识，知道什么时候用这个知识，等要用时再让 AI 读全文并实践

虽然但是，为什么第二季只有 10 集。等到完结再一口气看完却发现只有 10 集，悲

校园网自救手册

Sun, 03 May 2026 00:00:00 GMT

使用校园网时是否经常出现打不开网页，或者又被网关卡了的问题？本文介绍常见的软件导致的网络问题，希望能帮到你

快速诊断

一个简单的快速诊断方法是测试微信能否正常使用，微信的网络协议特殊，能无视很多网络 bug，以及检查能否打开网络服务
如果微信和网络中心都没法正常使用，那大概率是真的没网，优先检查硬件问题

代理忘关#

表现为打不开网页，但是微信可以正常用

这大概是最常见的 bug 了吧，常见于 VPN 异常中断/退出后，在网络设置里把代理都关了，或者重启 VPN 服务即可解决

DNS 错误#

表现同上：网页打不开、微信正常——但区别是清掉代理也无效

如果没修改过 DNS 服务，这个 bug 一般不会出现

北大校园网的 DNS 地址是 162.105.129.88 和 162.105.129.122，223.5.5.5 是阿里的 DNS，使用校园网时必须启用前两者中的至少一个，否则会 DNS 解析失败导致打不开网页

一个很简单的解决方法是直接把所有手动设置的 DNS 都删了，然后电脑会自动设置成 自动 DNS，也就是根据网络服务商自动切换正确的 DNS 地址

未登录网关#

打开网络服务并登录即可解决

通常被自动登出是因为设备未关闭随机 MAC，导致设备数超限

未关闭随机 MAC#

表现为被北大网关登出，重新登录时提示设备数超了

电脑和手机为了防止被追踪，默认使用随机 MAC，于是发送给网络服务商（比如北大校园网）的 MAC 地址经常变，校园网以为是新设备登录，就占掉了一个设备登录名额，导致虽然设备数不超过 4 台，还是因设备数超过 4 台而被校园网网关限制登录

如果足够土豪，可以以 ¥10/月/台 的价格在网络中心购买额外的校园网设备数

苹果电脑在 Wi-Fi - 详细信息 里把 私有 Wi-Fi 地址 调成 固定 即可

有线连接的设置在 网络 - USB 10/100/1000 LAN - 详细信息 里

Windows 在 网络和 Internet - WLAN 里把 随机硬件地址 关了

iPhone 端也是改 私有 Wi-Fi 地址，安卓端则换了个名字 使用设备 MAC

欠费#

也许是最隐蔽的 bug（这真的是 bug 吗）

在 门户-我的网络 里可以查看余额，电脑打不开门户可以从 北京大学 App 里打开。我的网络里可以充值，也可以直接打开 门户-网费充值 进行充值

想转生成北大校园网，虽然很废物，但所有人还是要每个月给我交 10 元

Lv.9999 验证码

Sun, 03 May 2026 00:00:00 GMT

久赌必输

Mon, 27 Apr 2026 00:00:00 GMT

哪有赌狗一直输

怎么会有人连输 4 局原地飞升

我的 8 连 All in 大胜！功亏两篑 😭

Pixi - Python 管理工具

Sat, 25 Apr 2026 00:00:00 GMT

相信用 Python 写过大工程的人应该都会被它糟糕的环境管理折磨过，我在此推荐 Pixi 作为环境管理工具 https://pixi.prefix.dev/latest/

（有种）来系统 Python 试试
权限错误、（不知道啊，）我还以为虚拟环境激活了、依赖地狱刹不住
它突然被导入
你怎么粘我依赖树上了
跟我的 lock 文件说去吧
我只是个写脚本的，你问我发行版打包的
我们都在用力地配环境

pip venv, conda(mamba), uv, Pixi 是几种常见的 python 环境管理工具。

pip venv 基础但简陋
conda 可以较好地处理非纯 Python 的二进制依赖，但锁定依赖处理依赖冲突等能力仍然较弱
uv 是用 rust 实现的 Python 管理工具，安装速度极快，而且有先进的 “锁” 机制，跨机器同步环境更容易。此外它的环境管理以项目为单位，从而避免不同项目使用同一个全局环境导致依赖冲突、冗余等问题
Pixi 可以看作 uv 和 conda 的结合，也是 rust 实现，速度极快。能用 conda 安装的依赖，Pixi 会优先使用 conda 渠道安装，否则直接使用内置的 uv 安装，因此 Pixi 对非纯 Python 实现的依赖的处理能力更好。此外 Pixi 还引入了 task 等高级功能

下面是一份 AI 写的介绍，然后是官方速查表的中文翻译，文章末尾是一段关于如何在使用 vscode 时正确激活 pixi 环境的教程

为什么我推荐用 Pixi 管理 Python 环境#

如果你写过一段时间 Python，大概率遇到过这些问题：

同一个项目在我电脑上能跑，在别人电脑上跑不起来； pip install 装了一堆包，后来忘了哪些是项目真正需要的；项目依赖 numpy、pytorch、opencv 这类带二进制依赖的库，安装时经常和系统环境、Python 版本、CUDA 或 C/C++ 库纠缠在一起；用 conda 能解决一部分问题，但环境和项目之间的关系不够清晰，environment.yml、requirements.txt、pyproject.toml 又常常分散管理。

Pixi 试图把这些问题统一起来解决。按照官方文档的定义，Pixi 是一个快速、现代、可复现的包管理工具，面向不同背景的开发者；它的核心能力包括隔离环境、内置 lockfile、任务管理、多平台支持、多环境管理、Python/pyproject.toml 支持，以及通过 uv 支持 PyPI。([Pixi][1])

Pixi 是什么？#

一句话说，Pixi 是一个基于 conda 生态、同时兼容 PyPI 的项目级环境管理工具。

传统上，我们常把 Python 环境理解成一个单独的虚拟环境：先创建环境，再激活环境，再在里面安装包。Pixi 的思路稍微不同：它更强调 workspace，也就是“项目工作区”。一个 Pixi workspace 通常包含：

1
your-project/
2
├── pixi.toml 或 pyproject.toml
3
├── pixi.lock
4
└── .pixi/

其中，pixi.toml 或 pyproject.toml 描述项目需要什么依赖、支持哪些平台、有哪些任务；pixi.lock 记录精确解析出来的依赖版本；.pixi/ 则存放项目实际使用的环境。官方从 Conda/Mamba 迁移指南中也明确指出，Pixi 与 Conda/Mamba 的差异在于：Conda/Mamba 主要围绕 environment，而 Pixi 更强调 workspace；workspace 中包含 manifest、lockfile 和 .pixi 环境目录，因此更适合项目共享与协作。([Pixi][2])

这点很重要。环境不再只是你电脑上的一个“状态”，而是项目的一部分。别人拿到你的代码仓库，只要有 pixi.toml/pyproject.toml 和 pixi.lock，就能更可靠地复现你的开发环境。

为什么 Pixi 特别适合 Python？#

Python 环境管理的难点不只是“装包”，而是包之间的来源和依赖模型非常复杂。一个现代 Python 项目可能同时依赖：

1
Python 解释器
2
numpy / pandas / scipy
3
pytorch / tensorflow
4
opencv / GDAL / CUDA 相关库
5
ruff / pytest / ipython
6
纯 Python 包
7
带 C/C++/Fortran/Rust 扩展的包

如果只使用 pip，它主要面对的是 PyPI 生态。PyPI 很大、包很多，但一些带系统级二进制依赖的库并不总是好装。Pixi 的优势在于它建立在 conda 生态之上，而 conda 是跨平台、跨语言的包生态，常用于数据科学和机器学习，特点是安装预构建的二进制包；同时 Pixi 也能安装 PyPI 包。官方 Python 教程举了 GDAL 的例子：PyPI 上的 GDAL 不包含二进制 C 依赖，而 conda 包包含；另一方面，也有一些包只在 PyPI 上发布，Pixi 也可以安装它们。([Pixi][3])

换句话说，Pixi 的定位不是“替代 pip”，也不是“换皮 conda”，而是把两个世界接在一起：能从 conda-forge 装的优先从 conda-forge 装，需要 PyPI 的再从 PyPI 装。官方文档也说明，Pixi 同时建立在 conda 和 PyPI 两个生态之上，并采用 conda-first 的策略：先解析 conda 依赖，再映射到 PyPI 包，最后解析剩余 PyPI 依赖。([Pixi][4])

Pixi 相比 pip、venv、conda、poetry、uv 的核心优势#

如果只写很小的纯 Python 脚本，venv + pip 已经够用。但一旦项目变复杂，Pixi 的优势会逐渐体现出来。

官方首页给了一个简化对比：Pixi 支持安装 Python、支持多语言、支持 lockfile、内置 task runner，并支持 workspace 管理；而 pip 不负责安装 Python，也不提供环境管理和 lockfile；Poetry 偏 Python 包管理；uv 很快，也支持 Python 和 lockfile，但官方表格中 Pixi 的优势在于多语言、任务系统和 workspace 管理。([Pixi][1])

可以这样理解：

工具	更适合什么场景	局限
`venv + pip`	简单 Python 项目	不管理 Python 本身；依赖可复现性较弱
`conda/mamba`	科学计算、机器学习、二进制依赖	更偏环境级管理，项目工作流不如 Pixi 清晰
Poetry	Python 包开发与发布	主要面向 PyPI，不擅长系统级二进制依赖
uv	极快的 Python 包管理	更专注 Python 生态
Pixi	项目级、跨平台、Python + Conda + PyPI + 任务管理	概念比 `pip` 稍多，需要适应 workspace 思路

Pixi 最值得推荐的地方是：它不是只解决一个局部问题，而是把“Python 版本、依赖来源、环境复现、任务运行、多平台协作”放进同一个项目模型里。

快速上手#

安装 Pixi 很简单。Linux 和 macOS 可以使用：

Terminal window

1
curl -fsSL https://pixi.sh/install.sh | sh

Windows 可以使用 PowerShell：

Terminal window

1
powershell -ExecutionPolicy Bypass -c "irm -useb https://pixi.sh/install.ps1 | iex"

官方文档说明，安装脚本会下载最新版本的 pixi，把二进制文件放到用户目录下的 .pixi/bin，并把它加入 PATH；安装后需要重启终端或重新加载 shell 配置。([Pixi][5])

创建一个新项目：

Terminal window

1
pixi init hello-world
2
cd hello-world
3
pixi add python
4
pixi run python -c 'print("Hello Pixi!")'

这套命令做了三件事：初始化 workspace、把 Python 加入项目依赖、在 Pixi 管理的环境里运行 Python。官方首页也用类似例子展示了 Pixi 的基本工作流。([Pixi][1])

如果是更标准的 Python 项目，也可以使用 pyproject.toml：

Terminal window

1
pixi init pixi-py --format pyproject

官方 Python 教程说明，Pixi 支持 pixi.toml 和 pyproject.toml 两种 manifest 格式；在 Python 项目中，pyproject.toml 更常见。初始化后，Pixi 会在 pyproject.toml 中加入 [tool.pixi.workspace]、[tool.pixi.pypi-dependencies] 和 [tool.pixi.tasks] 等配置。([Pixi][3])

添加 Conda 和 PyPI 依赖#

默认情况下，Pixi 会把依赖作为 conda 包添加。例如：

Terminal window

1
pixi add black

这会在配置文件中加入类似：

1
[tool.pixi.dependencies]
2
black = ">=25.1.0,<26"

如果某个包需要从 PyPI 安装，可以加上 --pypi：

Terminal window

1
pixi add rich --pypi
2
pixi add "flask[async]==3.1.0" --pypi

官方 Python 教程说明，Pixi 可以同时管理 conda 依赖和 PyPI 依赖，也支持 PyPI extras，例如 flask[async]。([Pixi][3])

这对 Python 项目很实用：像 python、numpy、pytorch、opencv 这类更依赖二进制构建的包，可以优先交给 conda-forge；一些只在 PyPI 上发布的工具包，则可以继续从 PyPI 安装。

Pixi 会自动管理 Python 解释器#

这是 Pixi 很容易被低估的一点：它不只是管理 Python 包，也可以管理 Python 本身。

在传统流程里，你可能会先用系统包管理器安装 Python，比如 brew install python、apt install python3，再创建虚拟环境。Pixi 则可以直接把 Python 解释器作为项目依赖的一部分安装。官方文档说明，在 pyproject.toml 项目中，Pixi 会根据 requires-python 字段决定安装哪个 Python 版本，从而自动管理和引导 Python 解释器，不再需要额外依赖 brew、apt 等系统安装步骤。([Pixi][3])

例如：

1
[project]
2
requires-python = ">=3.11"

然后 Pixi 会据此为项目准备合适的 Python。对于多人协作，这比“你自己先装一个差不多的 Python”可靠得多。

`pixi.lock`：可复现性的关键#

如果说 pixi.toml / pyproject.toml 描述“我想要什么”，那么 pixi.lock 描述的就是“Pixi 实际解析出了什么”。

官方 lockfile 文档解释：manifest 只列出项目的直接依赖；安装环境时，包管理器会进行依赖解析，找到所有直接和间接依赖，并确保版本彼此兼容；lockfile 则记录解析出的精确包、版本和元数据。它的价值在于，其他机器可以根据这个较小的文件重建出相同环境。([Pixi][6])

Pixi 的 lockfile 文件名是 pixi.lock。官方文档指出，Pixi 会为 manifest 中列出的所有环境和平台解析依赖，并把结果记录在 lockfile 中，这能显著提高项目在不同操作系统或 CPU 架构上的可复现性；很多情况下，共享 lockfile 就能让 CI 重建本地开发环境。([Pixi][6])

所以我的建议是：应用项目应当提交 pixi.lock。这和 package-lock.json、pnpm-lock.yaml 的逻辑类似。它能让别人安装到和你一致的依赖版本，而不是“今天解析一次、明天又解析出另一个版本”。

Tasks：把常用命令写进项目#

Pixi 还有一个很实用的功能：task runner。

很多项目都有固定命令：

Terminal window

1
pytest
2
ruff check .
3
ruff format .
4
python scripts/train.py
5
python -m my_package

如果只靠 README 记录，时间久了很容易不一致。Pixi 可以把这些命令写成 task：

Terminal window

1
pixi task add test pytest
2
pixi task add lint "ruff check ."
3
pixi task add fmt "ruff format ."

之后运行：

Terminal window

1
pixi run test
2
pixi run lint
3
pixi run fmt

官方 tasks 文档说明，构建一个包时，通常不只是运行代码，还会涉及格式化、lint、编译、测试、benchmark 等步骤；Pixi tasks 就是为了让这些工作流更容易管理。任务之间还可以声明依赖关系，例如先 configure，再 build，再 start；如果其中一个命令失败，后续任务不会继续执行。([Pixi][7])

这点对团队协作很有价值。你不用再写“请先激活环境，然后执行某某命令”，而是直接告诉别人：

Terminal window

1
pixi run test

Pixi 会在正确环境里执行它。

多环境：开发、测试、生产可以分开#

很多项目会有不同依赖集合：

1
default：运行项目需要的依赖
2
dev：开发工具，比如 ruff、ipython
3
test：测试工具，比如 pytest
4
prod：生产环境最小依赖

Pixi 支持在同一个 workspace 里管理多个环境。官方 Python 教程中，Pixi 可以配合 pyproject.toml 的 dependency groups 创建多个环境，例如 default 和 test；如果要在测试环境中安装或运行，可以加 --environment test。([Pixi][3])

这比把所有东西都塞进一个环境更干净。比如 pytest、ruff、mypy 这些工具只在开发或测试时需要，不一定应该进入生产环境。Pixi 允许你把它们分到对应 feature/environment 里。

多平台：同一个项目支持 macOS、Linux、Windows#

Python 项目经常遇到跨平台问题：你在 macOS 上开发，服务器是 Linux，队友可能用 Windows。Pixi 允许在 manifest 中声明 workspace 支持的平台，例如：

1
[workspace]
2
platforms = ["win-64", "linux-64", "osx-64", "osx-arm64"]

官方多平台文档说明，workspace.platforms 定义 workspace 支持的平台；当声明多个平台时，Pixi 会分别决定每个平台需要安装的依赖，并把这些结果存储在 lockfile 中。它还支持针对特定平台覆盖依赖或激活脚本。([Pixi][8])

这对机器学习、数据科学和后端项目都很有用。比如你可以在 macOS 上开发，在 Linux 服务器上训练模型，而依赖配置仍然保存在同一个项目里。

`pixi global`：顺便管理命令行工具#

除了项目环境，Pixi 还可以管理全局工具：

Terminal window

1
pixi global install ipython
2
pixi global install ripgrep
3
pixi global install gh

官方文档说明，pixi global 可以把工具安装到全局位置，并把可执行入口暴露到系统 PATH，使其可以在任意目录运行；默认情况下，每个包会被隔离在自己的环境里，只暴露必要入口，因此删除某个工具时不容易破坏其他无关工具，这一点类似 pipx。([Pixi][9])

对我来说，这意味着 Pixi 不仅可以管理项目，还可以管理常用 CLI 工具。比如 ipython、ruff、jupyterlab、ripgrep、gh 都可以用 Pixi 安装，而不必污染系统 Python。

一个推荐的 Python 项目模板#

如果我现在新建一个 Python 项目，我会大致这样做：

Terminal window

1
pixi init my-project --format pyproject
2
cd my-project
3

4
pixi add python
5
pixi add numpy pandas
6
pixi add ruff pytest --pypi
7

8
pixi task add test pytest
9
pixi task add lint "ruff check ."
10
pixi task add fmt "ruff format ."

如果是机器学习项目，可以继续加：

Terminal window

1
pixi add pytorch
2
pixi add jupyterlab

日常使用：

Terminal window

1
pixi run python main.py
2
pixi run test
3
pixi shell

提交到 Git 时，建议提交：

1
pyproject.toml / pixi.toml
2
pixi.lock
3
src/
4
tests/

不要提交：

1
.pixi/

因为 .pixi/ 是本地生成的环境目录，别人可以通过 manifest 和 lockfile 重新创建。

我为什么推荐大家尝试 Pixi？#

Pixi 最吸引我的地方，不是某一个命令特别酷，而是它对 Python 项目的抽象更完整。

它把 Python 解释器、conda 依赖、PyPI 依赖、lockfile、任务、多环境、多平台放在同一个 workspace 模型里。对于学生、科研、机器学习、数据分析、后端开发来说，这种统一性非常实用。

简单项目里，它可以替代 venv + pip，让环境更可复现；科学计算项目里，它能继承 conda-forge 的二进制包优势；团队项目里，它能用 lockfile 和 task runner 减少“你电脑上怎么跑”的沟通成本；跨平台项目里，它能把不同平台的依赖结果统一记录下来。

如果你只写一次性的脚本，Pixi 可能显得有点“重”。但只要你的项目需要长期维护、多人协作、跨机器运行，或者涉及数据科学/机器学习依赖，我会非常推荐你尝试 Pixi。它让我感觉 Python 环境管理终于更接近现代前端里的 pnpm / package-lock / workspace 工作流：环境不再是混乱的本地状态，而是项目本身的一部分。

Pixi 的基本用法##

Pixi 能做很多事情，但它被设计得易于上手。下面我们来过一遍 Pixi 的基本用法。

管理工作区 (workspace)##

pixi init - 在当前目录创建一个新的 Pixi 清单文件 (manifest)
pixi add - 向清单文件添加一个依赖项 (dependency)
pixi remove - 从清单文件移除一个依赖项
pixi update - 更新清单文件中的依赖项
pixi upgrade - 将清单文件中的依赖项升级到最新版本，即使你把它们固定 (pin) 在某个特定版本上
pixi lock - 为清单文件创建或更新锁文件 (lockfile)
pixi info -显示工作区信息
pixi run - 运行清单文件中定义的任务 (task)，或在当前环境中运行任意命令
pixi shell - 在当前环境中启动一个 shell
pixi list - 列出当前环境中的所有依赖项
pixi tree - 显示当前环境中的依赖树 (dependency tree)
pixi clean - 从你的机器上移除该环境

管理全局安装 (global installations)##

Pixi 可以在全局环境 (global environments) 中管理工具的全局安装。它会把这些环境安装到一个集中位置，因此你可以在任意位置使用它们。

pixi global install - 在全局空间 (global space) 中将一个包安装到它自己的环境里
pixi global uninstall - 从全局空间卸载一个环境
pixi global add - 向一个已存在的全局环境添加一个包
pixi global sync - 将全局已安装的环境与全局清单文件同步，该清单描述了你想安装的所有环境
pixi global edit - 编辑全局清单文件
pixi global update - 更新全局环境
pixi global list - 列出所有全局环境

更多信息： Global Tools

运行一次性命令 (one-off commands)##

Pixi 可以在特定环境中运行一次性命令。

pixi exec - 在临时环境 (temporary environment) 中运行一条命令
pixi exec --spec - 在临时环境中运行一条命令，并使用指定的规格 (specification)

例如：

Terminal window

1
> pixi exec python -VV
2
Python 3.13.5 | packaged by conda-forge | (main, Jun 16 2025, 08:24:05) [Clang 18.1.8 ]
3
> pixi exec --spec "python=3.12" python -VV
4
Python 3.12.11 | packaged by conda-forge | (main, Jun  4 2025, 14:38:53) [Clang 18.1.8 ]

多环境 (Multiple Environments)##

Pixi 工作区允许你管理多个环境 (environment)。一个环境由一个或多个特性 (feature) 构建而成。

pixi add --feature - 向某个特性添加一个包
pixi task add --feature - 向某个特定特性添加一个任务
pixi workspace environment add - 向工作区添加一个环境
pixi run --environment - 在指定环境中运行一条命令
pixi shell --environment - 激活 (activate) 指定环境
pixi list --environment - 列出指定环境中的依赖项

更多信息： Multiple Environments

任务 (Tasks)##

Pixi 内置了任务运行器 (task runner)，可以运行跨平台任务 (cross-platform tasks)。任务既可以是预定义的任务，也可以是任意普通可执行文件 (executable)。

pixi run - 运行一个任务或命令
pixi task add - 向清单文件添加一个新任务

任务也可以依赖其他任务。下面是一个更复杂的任务用例示例：

1
[tasks]
2
build = "make build"
3
# using the toml table view
4
[tasks.test]
5
cmd = "pytest"
6
depends-on = ["build"]

更多信息： Tasks

多平台支持 (Multi platform support)##

Pixi 开箱即用地支持多种平台。你可以指定工作区支持哪些平台，Pixi 会确保依赖项与这些平台兼容。

pixi add --platform - 只把某个包添加到指定平台
pixi workspace platform add - 向工作区添加你希望支持的平台

更多信息： Multi platform support

实用工具 (Utilities)##

Pixi 自带了一组实用工具，帮助你调试或管理配置。

pixi info - 显示当前工作区以及全局配置的信息
pixi config - 显示或编辑 Pixi 配置 (configuration)
pixi tree - 显示当前环境中的依赖树
pixi list - 列出当前环境中的所有依赖项
pixi clean - 从你的机器上移除工作区环境
pixi help - 显示 Pixi 命令的帮助信息
pixi help <subcommand> - 显示某个特定 Pixi 命令的帮助信息
pixi auth - 管理 conda 通道 (channel) 的认证 (authentication)
pixi search - 在已配置的通道中搜索包
pixi completion - 为 Pixi 命令生成 shell 自动补全脚本 (completion scripts)

进一步探索 (Going further)##

Pixi 还有更多能力等待你挖掘。请查看左侧边栏中的主题来了解更多内容。

别忘了加入我们的 Discord ，和 Pixi 爱好者社区一起交流！

修复 VS Code + Pixi 终端报错 `__vsc_prompt_cmd_original: command not found`#

问题现象#

在 VS Code 中设置 Python 解释器为 Pixi 环境（启用 Pixi Code 扩展）从而自动激活环境时，打开终端会出现：

1
bash: __vsc_prompt_cmd_original: command not found

原因分析#

问题涉及三个组件的交互：

1
VS Code Shell 集成        Python 扩展             Pixi
2
    │                        │                    │
3
    │ 定义 __vsc_* 函数       │ 检测到 pixi 环境    │
4
    │ 写入 PROMPT_COMMAND    │                    │
5
    │                        │                    │
6
    │                        │── pixi shell ──────│→ 启动 bash 子进程
7
    │                        │                    │
8
    │                        │   子进程继承了 PROMPT_COMMAND
9
    │                        │   但没有继承 __vsc_* 函数
10
    │                        │                    │
11
    │                        │   bash 执行 PROMPT_COMMAND
12
    │                        │   → 找不到 __vsc_prompt_cmd_original
13
    │                        │   → 报错！

详细解释#

VS Code 的 shell 集成：VS Code 打开终端时，注入脚本定义 __vsc_prompt_cmd_original 等函数，并将它们挂到 PROMPT_COMMAND 上。这些函数用于目录跟踪、命令装饰（行号旁的成功/失败图标）、点击相对路径跳转文件等增强功能。
Python 扩展的自动激活：python.terminal.activateEnvironment 默认为 true。当你选择了 pixi 环境中的 Python 解释器后，扩展会在每次打开终端时自动执行 pixi shell --manifest-path ... 来激活环境。
pixi shell 的子进程问题：pixi shell 启动一个新的 bash 子进程。子进程通过环境变量继承了 PROMPT_COMMAND，但 bash 函数（如 __vsc_prompt_cmd_original）不是环境变量，不会被继承。子进程执行 PROMPT_COMMAND 时就会找不到函数而报错。

`pixi shell` vs `pixi shell-hook` 对比#

	`pixi shell`	`eval "$(pixi shell-hook)"`
原理	启动新的 bash 子进程	在当前 shell 中设置环境变量
VS Code 集成	丢失（函数未继承到子进程）	完整保留
退出方式	`exit` 退出子 shell	环境变量持续到终端关闭

修复步骤#

共需修改 2 个文件。

步骤 1：编辑 `~/.bashrc`#

1a. 添加 PROMPT_COMMAND 兜底保护#

在交互检查（case $- in ...）之后，添加：

Terminal window

1
# Fix: clean up VS Code shell integration references in sub-shells
2
# (e.g., pixi shell) where the functions are not inherited.
3
if [[ "$PROMPT_COMMAND" == *"__vsc_prompt_cmd_original"* ]] && ! type -t __vsc_prompt_cmd_original &>/dev/null; then
4
    unset PROMPT_COMMAND
5
fi

作用：如果仍有 pixi shell 子进程场景（手动执行等），清理掉无效的 PROMPT_COMMAND，避免报错。

1b. 添加 pixi 环境自动激活#

在文件末尾（pixi completion 那行之后），添加：

Terminal window显示更多显示更少

1
if [ -x ~/.pixi/bin/pixi ]; then
2
    # 启用 pixi 命令自动补全
3
    eval "$("$HOME/.pixi/bin/pixi" completion --shell bash)"
4

5
    # 如果当前目录或其父目录里有 pixi.toml，激活 pixi 环境
6
    if [[ -z "${PIXI_IN_SHELL:-}" ]]; then
7
        _dir="$PWD"
8
        while :; do
9
            if [[ -f "$_dir/pixi.toml" ]]; then
10
                eval "$("$HOME/.pixi/bin/pixi" shell-hook --manifest-path "$_dir/pixi.toml")"
11
                break
12
            fi
13
            [[ "$_dir" == "/" ]] && break
14
            _dir="$(dirname "$_dir")"
15
        done
16
        unset _dir
17
    fi
18
fi

显示更多显示更少

作用：终端打开时，从当前目录向上查找 pixi.toml，找到后用 shell-hook 在当前 shell 中激活环境。不启动子进程，VS Code 集成功能完整保留。 PIXI_IN_SHELL 检查防止重复激活。

步骤 2：创建 `.vscode/settings.json`#

在项目根目录创建 .vscode/settings.json：

1
{
2
    // Disable Python extension's automatic environment activation in terminal.
3
    // The pixi environment is already auto-activated via ~/.bashrc using shell-hook,
4
    // which avoids spawning a sub-shell and preserves VS Code's shell integration.
5
    "python.terminal.activateEnvironment": false
6
}

作用：禁止 Python 扩展在终端中自动执行 pixi shell，从根源上消除子进程的产生。

三层防护总结#

层级	位置	作用
根源修复	`.vscode/settings.json`	禁止 Python 扩展自动执行 `pixi shell`
自动激活	`~/.bashrc` 末尾	用 `shell-hook` 在当前 shell 中激活 pixi
兜底保护	`~/.bashrc` 开头	手动 `pixi shell` 时清理无效 `PROMPT_COMMAND`

为什么不能用 `export -f` 导出函数？#

一个直觉的想法是：在 ~/.bashrc 中用 export -f __vsc_prompt_cmd_original 导出函数，让子进程继承。但这条路走不通，有两个硬性障碍。

障碍 1：时序不对——函数在 `.bashrc` 之后才定义#

VS Code 的 shell 集成脚本 shellIntegration-bash.sh 的执行顺序如下：

1
① shellIntegration-bash.sh 开始执行
2
② . ~/.bashrc                               ← .bashrc 在这里运行
3
③ 定义 __vsc_prompt_cmd_original 等函数       ← 函数此时还不存在！
4
④ PROMPT_COMMAND=__vsc_prompt_cmd_original

对应源码（shellIntegration-bash.sh）：

Terminal window显示更多显示更少

1
# 第 ② 步：先执行 .bashrc
2
if [ "$VSCODE_INJECTION" == "1" ]; then
3
    if [ -z "$VSCODE_SHELL_LOGIN" ]; then
4
        if [ -r ~/.bashrc ]; then
5
            . ~/.bashrc          # ← .bashrc 在此执行
6
        fi
7
    fi
8
fi
9

10
# ... 中间定义了大量 __vsc_* 函数 ...
11

12
# 第 ③ 步：函数在 .bashrc 之后才定义
13
__vsc_prompt_cmd_original() {
14
    __vsc_status="$?"
15
    builtin local cmd
16
    __vsc_restore_exit_code "${__vsc_status}"
17
    for cmd in "${__vsc_original_prompt_command[@]}"; do
18
        eval "${cmd:-}"
19
    done
20
    __vsc_precmd
21
}
22

23
# 第 ④ 步：设置 PROMPT_COMMAND
24
__vsc_original_prompt_command=${PROMPT_COMMAND:-}
25
if [[ -n "${__vsc_original_prompt_command:-}" ... ]]; then
26
    PROMPT_COMMAND=__vsc_prompt_cmd_original
27
fi

显示更多显示更少

.bashrc 运行时 __vsc_prompt_cmd_original 尚未定义，export -f 无法导出不存在的函数。

障碍 2：依赖链太深——不是导出一个函数就能解决的#

__vsc_prompt_cmd_original 并非独立运行，它依赖一整个函数和变量体系（共 20+ 个函数、10+ 个全局变量）：

1
__vsc_prompt_cmd_original
2
  ├── __vsc_restore_exit_code
3
  ├── __vsc_precmd
4
  │     ├── __vsc_command_complete
5
  │     ├── __vsc_update_cwd
6
  │     │     └── __vsc_escape_value / __vsc_escape_value_fast
7
  │     ├── __vsc_report_prompt
8
  │     ├── __vsc_update_prompt
9
  │     │     ├── __vsc_prompt_start
10
  │     │     ├── __vsc_prompt_end
11
  │     │     ├── __vsc_continuation_start
12
  │     │     └── __vsc_continuation_end
13
  │     └── __vsc_update_env
14
  │           └── __updateEnvCache / __updateEnvCacheAA
15
  └── 变量: __vsc_status, __vsc_nonce, __vsc_original_prompt_command,
16
            __vsc_in_command_execution, __vsc_current_command,
17
            __vsc_is_windows, __vsc_history_verify, __vsc_first_prompt, ...

显示更多显示更少

即使解决了时序问题，也需要 export -f 导出全部 20+ 个函数并 export 全部变量。而且这些内部实现随 VS Code 版本更新随时可能变化，维护成本极高。

结论#

export -f 方案不可行。正确做法是避免子进程的产生（shell-hook + 禁用 Python 扩展自动激活），辅以 PROMPT_COMMAND 兜底清理。

验证#

修改完成后重新打开 VS Code 终端，应该看到：

(nodebb) 前缀正常显示（pixi 环境已激活）
没有 __vsc_prompt_cmd_original: command not found 错误
终端行号旁的命令成功/失败图标正常工作（VS Code 集成保留）

公费医疗报销&过敏与腰疼治疗

Sat, 25 Apr 2026 00:00:00 GMT

我对尘螨过敏，大量调研后决定去协和做脱敏治疗。为了报销费用，也研究了很多公费医疗的相关信息。此外之前多次在校医院和三院看腰疼的病。于是我写了这篇攻略，希望能帮到正在阅读的你。

第一部分讲所有你需要知道的公费医疗报销知识，第二部分讲尘螨过敏&治疗，第三部分是腰疼&治疗。

镇楼

报销凭据和报销账单。

公费医疗#

公费医疗不是医保#

公费医疗报销和医保是不同的东西，北大学生没有医保，只有公费医疗报销。公费医疗报销指学生在指定医院的指定科室看病开药接受治疗，并且满足报销条件，可以报销 90% 左右的金额。校医院预约挂号平台是微信服务号 “北京大学医院服务平台”（公费医疗报销室也在这里预约）。

下文以 转诊医院 指代要转诊的医院。

就诊 & 报销流程#

去校医院看病，并开转诊单
去转诊医院看病
预约公费医疗报销室，在预约时段拿着校园卡、转诊单、发票去报销室取号，然后排队等待提交报销材料

实用技巧

急诊不需要开转诊单，直接去报销即可。
如果转诊医院是三院，可以去门户的 “三院门诊便捷报销” 签署协议，然后不需要去报销室，报销款会自动打进农行卡里。
医学部的同学去三院看病不需要转诊单。
在报销室提交材料时工作人员会把转诊单一并收走，因此如果你有多笔费用要用同一份转诊单报销，需要等所有病都看完了，凭据齐全了再一并提交。

怎么开出转诊单#

转诊医院在名单上：例如协和医院不在名单上，报销会麻烦不少，后面会讲名单外的怎么报销
转诊科室在名单上：例如三院最全，大部分科室都在名单上，但部分其他医院只有几个科室在名单上
满足指定转诊条件：例如三院最宽松，绝大部分的科室没有额外条件，可以直接转诊，但有的医院只有院士才有资格转诊

关键细节

挂号费必须低于 200。例如三院的特需、国疗均不能报销。
理论上校医院门诊只能开对应科室的转诊单，急诊不能开转诊单。比如想看三院皮肤科就要去校医院皮肤科看病，让皮肤科医生开转诊单（皮肤科医生出了名的刁钻，很可能不愿意开转诊单）。实际上医生有权限开其他科室的转诊单，只是医院要求医生不要开，所以如果能说服医生，急诊也能开皮肤科转诊单。
转诊单的有效期是一个月，从开出算起，在转诊医院的就医日期必须在有效期内才能报销。很多医院的号需要提前一周抢，因此如果确定要转诊，可以在开转诊单之前就挂转诊医院的号，只要就医日期在开出转诊单之后即可。

转诊医院不在名单上怎么办#

只有一条途径，去三院中转一次

去校医院开转诊到三院的转诊单
去三院开转诊到转诊医院的转诊单
去转诊医院看病之后，拿着两份转诊单和发票和校园卡去报销室报销

补充

这个方法需要额外去一趟三院，最终提交材料时需要多提交一份三院开的转诊单。
三院的科室可以开不同科室的转诊单。例如我去协和变态反应科看病的转诊单是三院皮肤科开的。

尘螨过敏&治疗#

我从小就对尘螨过敏，常年过敏性鼻炎，小学时做过舌下滴服脱敏治疗，缓解了几年，但之后又逐渐加重，高中时手指出现湿疹，还得了荨麻疹，空军总医院（以下简称 “空总”）的医生说这些都是过敏导致的。荨麻疹至今未痊愈，需要定期服用抗过敏药。湿疹则在北京时痊愈，回南方就复发。

我在校医院皮肤科、校医院呼吸科、校医院耳鼻喉科、三院皮肤科、三院耳鼻喉科、空总皮肤科就诊过。校医院的医生水平相当一般，略去不谈。三院和空总的医生都认为主要有 3 种治疗方法：

第一种就是我之前几年一直在用的常年服用抗过敏药，好处是治疗简单，每天或每几天吃药即可，坏处是无法根治，而且病情严重时吃药压不住，仍然会有症状
第二种是单抗注射治疗，定期（几周一次）去医院打针，好处是几周治疗一次即可，并且效果较好，坏处也是无法根治。例如圆柏等过敏的单抗治疗一般两周一针或四周一针
第三种是脱敏治疗，它又分舌下滴服和针剂注射两种。我小时候做的是舌下滴服，前 2 年每天在舌根滴药（味道甜甜的，需要用冰箱保存），治疗后几年内不会过敏（具体时长因人而异，我大概持续了 3 年）；另一种是我现在正在接受的注射治疗，前 4 个月每周打一针，之后每一个半月打一针，总疗程 3 年，我用的药是安脱达（进口脱敏针剂），其他药的疗程可能不同。好处是完成治疗后几年内不过敏，坏处是治疗期比较麻烦，而且也不能终生生效。安脱达的治疗价格是每个月几百元。除了安脱达之外，中国唯一一款国产脱敏针剂是协和生产的，没有正式名字，一般就叫做 “协和脱敏针”，一周打两针，总疗程 3 年；圆柏的脱敏针也是一周两针（可能是同一种针剂）

Info

北大一院疼痛科似乎有专门治疗过敏性鼻炎的方法，一季治疗一次。

最终我选了针剂脱敏治疗。三院和空总都不能进行脱敏治疗，空总的医生说北京的脱敏药都是从协和分发出去的，建议我去协和接受治疗，于是我就开始在协和接受脱敏治疗了。前 4 个月过敏症状不会缓解，仍然需要服用抗过敏药，进入一个半月打一针的持续期后，过敏症状应该就能大幅缓解了，届时我再发一篇博客说明情况。

全流程#

上大学之后，我先去校医院皮肤科找刘慧清医生看病，她说只能定期服用抗过敏药（实际上根本就不是这样），让我定期来复查开抗过敏药。与此同时她还让我不要找对门于苇医生看病，让我不要挂号直接来诊室加号。有一次我挂错号挂成了于苇的号，但是还是找她看的病，她竟然在当天下午打电话给我把我批了一通，大概的意思是她帮于医生做嫁衣……树洞上还有很多关于校医院皮肤科的负面评价，总之这两位都比较难评，尽量不要找她们看病。

然后我去三院和空总看湿疹、荨麻疹，医生说我的湿疹、荨麻疹、过敏性鼻炎等疾病都是对粉尘螨过敏引起的，并且说治疗方法大体可以分成抑制和脱敏两种。抑制就是定期服抗过敏药或打单抗治疗针，需要长期治疗；而脱敏可以在完成治疗后几年内不过敏复发，北京的脱敏药都是从协和分发出来的，于是我最后选择去协和做脱敏治疗，科室是 “变态反应科”。

最终的结果是报销了 800+ 协和治疗费 & 100+ 挂号费，2700+ 的脱敏药物（能使用四个月左右）全自费，早知只能报这么一点就不折腾了……

不过还是把流程记录下来，以供参考

确定去协和变态反应科看病
发现校医院没有变态反应科，而且协和不在报销名单上，在报销室问到可以去三院中转
在皮肤科找于苇医生开转诊到三院皮肤科的转诊单
去三院皮肤科开出去协和变态反应科的转诊单
去协和看病，做初步检查，医生说要停抗过敏药三天后再来做其他检查
三天后复诊，确定对粉尘螨过敏，开药做脱敏治疗
收集所有在协和产生的发票
带校园卡到报销室提交发票和两份转诊单
两周后收到报销款

实际上我还在内科急诊找赵菁医生开了去三院变态反应科、同仁医院耳鼻喉科的转诊单，在耳鼻喉科找张秋颖医生开了去三院耳鼻喉科的转诊单。我抢到的最早的号是三院皮肤科，于是我先去了三院皮肤科，医生直接开了转诊到协和变态反应科的转诊单，于是这 3 张转诊单我最后都没用。

腰疼&治疗#

我从高三开始经常腰疼，久坐之后更严重。我多次在校医院不同科室治疗，都误诊且治疗方案无效，最后在三院骨科才找到有效的治疗方案。

我先去校医院康复科看病，拍了核磁共振，医生说是 轻微腰间盘突出，给我开了康复科的按摩治疗以及膏药贴，并教了几种缓解疼痛的动作。实际上这两种治疗都没有任何作用，贴膏药甚至会更痛。

然后我去校医院骨科看病，医生说这不是腰间盘突出，说只是 腰肌劳损，并且没给出任何治疗方案，只是让我平时按摩一下，不要久坐。这个治疗方案自然也没有任何作用。

我调研发现三院骨科很强，于是决定去三院骨科看病。我先在校医院外科急诊开转诊单，那位医生也认为是腰肌劳损，不过还是开了转诊单。我抢不到三院骨科普通门诊，只好挂了特需号，没法报销，大悲。医生听了我的描述后，简单扫了一眼核磁共振的片子，然后按了我髂骨附近的几个地方问我痛不痛，我说每个地方都很痛。然后他就让我平时自己沿着髂骨附近按一按，哪里痛按哪里，多揉揉，揉出淤血就好了，并象征性开了点药。整个流程就几分钟，我追问后他才说这既不是腰间盘突出也不是腰肌劳损，而是 神经末梢炎症，腰肌的一端连在髂骨附近，我那里的神经末梢有炎症，但由于腰肌一端也在这，于是身体以为是腰肌痛，于是我感受到腰痛，实际上症结在腰下面的髂骨附近而不是腰。我按照他的方法平时没事就按一按，竟然真的按出淤血了，几天之后竟然真的大幅缓解了。

现在我很少腰痛，就算复发，自己按一按就好了。只能说不要信任校医院，感冒等小病就算了，疑难杂症千万不要在校医院看病。

垂梯上下行按钮反向

Fri, 24 Apr 2026 00:00:00 GMT

这是哪个大聪明设计的垂梯，上行按钮在下面，下行按钮在上面

何意味是什么意思

Wed, 08 Apr 2026 00:00:00 GMT

Claude Code buddy

Thu, 02 Apr 2026 00:00:00 GMT

Coding 版高松灯

Chrome 自动把 HTTP 升级为 HTTPS

Thu, 02 Apr 2026 00:00:00 GMT

浪费我几小时 debug

我原本给我的网站开启了边缘加速服务，所以没在服务器上部署 SSL 证书。之后想关掉边缘加速服务器直连服务器，在部署证书之前决定先测试一下网站是否在正常运行，但一直无法通过 HTTP 访问网站，无论是用 IP 还是域名。最后发现 Chrome 会自动把 HTTP 升级为 HTTPS，换成 Safari 就能正常访问了……

ChatGPT 给了 2 种可能的原因，排查发现都不是。Anyway 网站正常运行就行，懒得管实际原因了，恼

跨机器同步数据

Thu, 02 Apr 2026 00:00:00 GMT

本文介绍如何用 GitHub + GNU Stow 跨机器同步配置文件

由于我有多台服务器，并且经常重装服务器，于是怎么高效地存储并同步 .bashrc、Claude Code skills 等数据变得至关重要。

我最初的想法是维护一个 GitHub repo，在每台机器上部署该 repo，然后用软链接链接到该 repo。缺点是每次需要手动链接，写成脚本也不方便控制链接哪一部分，于是我找到了 GNU Stow，它可以用一行命令快速创建链接，例如 stow -t ~ bash git claude tmux 就可以一次性配置好 .bashrc、.gitconfig 等指定的数据，有需要的话再加 stow -t ~ proxy 可以把代理配置一起部署了。

示例 repo 在这里：

Fomalhaut647

dotfiles-demo

Waiting for api.github.com...

00K

Waiting...

为什么选这套方案#

零冗余：配置文件只有一份，修改后 git push 即可同步到所有机器，不存在多份拷贝不一致的问题
按需部署：服务器只装服务器需要的包，本地机器只装本地需要的包，互不干扰
易于迁移：新机器 git clone + stow 两条命令即可还原全部配置
历史可追溯：每次改动都有 commit 记录，可以随时回滚
AI 工具配置同步：Claude Code 的用户级 CLAUDE.md、OpenClaw skills 等配置也纳入仓库统一管理，在任意机器上都能获得一致的 AI 辅助体验

思路#

1
GitHub repo
2
    │
3
    ├─ git clone ──▶ 机器 A（本地 Mac）
4
    ├─ git clone ──▶ 机器 B（远程 Ubuntu 服务器）
5
    └─ git clone ──▶ 机器 C（...）

所有机器共享同一份配置，通过 git pull / push 同步变更；用 stow 把仓库里的配置文件以符号链接的形式部署到 ~；每台机器只 stow 自己需要的包，不需要的跳过即可。

仓库结构#

每个目录是一个独立的 stow 包，可以按需单独部署：

1
dotfiles/
2
├── bash/               # Bash 配置
3
│   └── .bash_aliases   #   通用 alias 和函数（跨机器同步）
4
├── zsh/                # Zsh 配置
5
│   ├── .zshrc
6
│   └── .zsh_aliases
7
├── git/                # Git 配置
8
│   ├── .gitconfig
9
│   └── .gitignore_global
10
├── ssh/                # SSH 客户端配置
11
│   └── .ssh/config
12
├── tmux/               # tmux 配置
13
│   └── .tmux.conf
14
├── proxy/              # 代理开关脚本
15
│   └── .bash_proxy
16
├── claude/             # Claude Code 配置
17
│   └── .claude/
18
│       ├── CLAUDE.md
19
│       ├── settings.json
20
│       └── commands/
21
└── .bashrc             # 仅备份，不通过 stow 部署

显示更多显示更少

为什么不同步 `.bashrc`？#

.bashrc 包含大量机器相关的设置（路径、环境变量等），各机器差异大，强行统一反而麻烦。因此：

同步：bash/.bash_aliases——通用 alias 和函数，所有机器共享
不同步：.bashrc——机器自带，各自管理；仓库里保留一份 Ubuntu 默认 .bashrc 作参考备份

.bashrc 里只需保留这几行来加载 aliases：

Terminal window

1
if [ -f ~/.bash_aliases ]; then
2
  . ~/.bash_aliases
3
fi

Note

Ubuntu 默认 .bashrc 已经包含这一段，无需额外处理。

使用方法#

1. 安装 stow#

Terminal window

1
# Ubuntu / Debian
2
sudo apt install stow
3

4
# macOS
5
brew install stow

2. 克隆仓库#

Terminal window

1
git clone git@github.com:<your-username>/dotfiles ~/dotfiles
2
cd ~/dotfiles

3. 部署配置#

Terminal window

1
# 按需选择要部署的包，例如：
2
stow -t ~ bash git tmux
3

4
# 部署全部
5
stow -t ~ bash zsh git ssh tmux proxy claude

stow 会在 ~ 下创建符号链接，指向仓库中对应的文件。

4. 取消部署#

Terminal window

1
stow -D -t ~ bash   # 删除 bash 包的符号链接

日常同步工作流#

Terminal window

1
# 在任意机器上修改配置后，提交并推送
2
cd ~/dotfiles
3
git add -A
4
git commit -m "update: ..."
5
git push
6

7
# 在另一台机器上拉取最新配置
8
cd ~/dotfiles
9
git pull
10
# 符号链接已存在，配置立即生效，无需重新 stow

Stow 注意事项#

冲突规则#

stow 部署时，若目标路径不存在或已是指向同一文件的符号链接，则正常创建链接；若目标路径已存在且内容不同，则报错退出，不会覆盖。

这套方案从设计上就规避了冲突：仓库只同步那些在新机器上本来就不存在的文件（如 .bash_aliases）；而各机器上本已存在的文件（如 .bashrc）则不纳入同步，从根本上避免了冲突。

目录折叠原则#

stow 采用最少链接原则：它会尽量在最高层级创建链接，而不是逐个链接每个文件。对于带有多层目录的文件，stow 会依次检查各层目录是否存在，在第一个不存在的层级创建链接。

以 claude/.claude/commands/openclaw.md 为例：

`~/.claude`	`~/.claude/commands`	stow 的行为
不存在	—	链接整个 `.claude/` 目录
已存在	不存在	链接整个 `commands/` 目录
已存在	已存在	仅链接 `openclaw.md` 文件

这对 claude 包有两点影响：

应在安装 Claude Code 之后再部署 claude 包

Claude Code 安装时会创建 ~/.claude/ 并写入自己的运行时文件（对话记录等）。若提前 stow claude，~/.claude/ 还不存在，stow 会将整个目录链接到仓库，导致 Claude Code 的运行时文件也被写入仓库。

commands/ 目录应在部署前不存在

当 commands/ 不存在时，stow 会将整个目录链接到仓库，后续在仓库中新增的 command 文件会自动在所有机器上生效。若 commands/ 已存在（例如 Claude Code 自行创建），stow 只能逐个链接已有文件，新增文件不会自动同步——此时需先删除 ~/.claude/commands/，再重新 stow claude。

何忆卫

Tue, 31 Mar 2026 00:00:00 GMT

从头 C 到尾，队友漏的 6 金复仇者当小兵杀了。不过打隐藏时忘了阿罗玛是奥术，换成四爷之后奥术没激活（）

这是我区了那么多把应得的😭

午夜凶铃？

Sat, 28 Mar 2026 00:00:00 GMT

订阅 AI 服务的方法

Fri, 27 Mar 2026 00:00:00 GMT

本文将讲解 5 种订阅 ChatGPT Claude 等 AI 服务的方法。默认读者会科学上网

方法一：网页端订阅#

需求：一张国外银行卡或国外 PayPal

我在 🇦🇺 旅游时办了一张 WestPac，也许后续会写一篇博客讲如何办国外银行卡

WestPac

不多赘述。需要注意的是，IP 位置最好和发卡地区保持一致，否则可能会被拒付

另外有传言说现在 OpenAI 可以穿透 PayPal 看到 PayPal 绑定的卡的发卡地区，于是拒掉绑定了中国卡的外国 PayPal，真假不明

ChatGPT

方法二：用 App Store 绕过监控#

需求：一部 iPhone / iPad

由于 Claude 等服务商会检查支付银行卡的发卡国家，中国银行发的卡大概率会被拒付，所以需要用其他方法来绕过这一限制。Apple Pay 的特殊之处在于，服务商无法穿透查看它绑定的银行卡的发卡地区，而我们又可以在没有国外银行卡和电话卡的条件下给 App Store 充值，因此可以借助 App Store 完成订阅

步骤如下：

准备一部 iPhone / iPad
注册并登录一个外区 Apple Account，建议选择美国免税州，这样可以使用美元支付，而且价格更低
在支付宝中购买外区苹果礼品卡，并充值到你的 Apple Account（地区切换到境外，搜索 Pockyt Shop）
下载对应的 App，比如要订阅 Claude 就下载 Claude App，最后进入 App 并订阅

值得一提的是，一个 Apple Account 只能绑定一个 ChatGPT 账号，不能解绑，也不能换绑。我之前不知道这个规则，先用我的 Apple Account 帮朋友订阅了 ChatGPT，于是现在没办法给自己订阅了，只好换用网页端订阅，所以本方法只能用 Claude 举例

通过 App Store 或 Google Play 订阅 Claude 的价格比网页端高约 25%，这是因为苹果和谷歌有抽成，Anthropic 把成本转嫁给消费者，因此有条件的话建议通过网页端订阅 Claude

Claude

方法三：再加上 PayPal#

需求：一部 iPhone / iPad & 一个国外电话卡

外区 App Store 不能直接绑定中国银行卡，但可以绑定外区 PayPal；而外区 PayPal 又可以绑定中国银行卡。所以我们可以再加一层 PayPal，实现直接用国内银行卡支付，而不需要再购买礼品卡

步骤如下：

准备一部 iPhone / iPad 和一张国外电话卡
注册并登录一个外区 Apple Account，建议选择美国免税州，这样可以使用美元支付，而且价格更低
打开 App Store，添加付款方式，选择 PayPal，并进入注册环节
通过 App Store 使用国外电话卡完成注册
将国内 Visa / Master 卡绑定到 PayPal
在 iPhone / iPad 上下载对应 App 并订阅

注意，最好通过 App Store 直接注册 PayPal。先单独注册 PayPal，再绑定到 Apple Account，有可能触发风控导致绑定失败

订阅费流转过程如下：

Visa / Master 卡 -> PayPal -> App Store -> Claude

这样可以绕开 Claude 的支付限制完成订阅，而且几乎无额外开销

PayPal

方法四：Google Play#

需求：一部安卓机

跟 App Store 方法差不多，我没仔细研究过所以一笔带过

Google Play

方法五：代购#

需求：不贪婪的心

网上有很多代充平台，闲鱼上也能搜到不少

建议不要找价格低于成本价的。如果要用低价代充，建议用低价买的 Google 账号，这样被封了也不心疼

我的朋友向我推荐这个网站爱充值，但我没用过，不确定是否可靠

代理

Fri, 27 Mar 2026 00:00:00 GMT

纯净度#

先介绍如何检测节点的纯净度

PING 0（不建议使用）#

网址

https://ping0.cc/

这个网站能够查看 IP 位置、IP 类型、风控值、共享人数等信息。

其中，IP 类型最好是家庭宽带；风控值和共享人数通常越小越好。

Warning

近期 Ping0.cc 被曝出非法收集用户数据，不建议继续使用。可改用下文的 IPQS 或其他网站进行查询。

IPQS#

网址

https://www.ipqualityscore.com/

输入需要查询的 IP 后，可以检测 Fraud Score 等信息，分数同样越小越好。

如果页面不允许查询，可能说明当前节点太脏了。这时可以先关闭代理，切换为直连后再试。

其他#

另附 2 个网站

网址

https://scamalytics.com/ https://www.ip111.cn/

供应商选择#

我现在用的是 TAG，上面的例子是 TAG 的 美国家宽 1

我的 TAG 邀请码：RNnznB6C

服务器代理#

如何在国内服务器上使用代理，从而使用 Claude Code 等墙外产品

流量转发#

把服务器上所有的流量先发送到有代理的本地，然后再从本地转发到远程服务商

在服务器上的 .bashrc 里配置如下代码，从而把所有的服务器流量汇集到 7890 端口

.bashrc

1
export HTTP_PROXY="http://127.0.0.1:7890"
2
export HTTPS_PROXY="http://127.0.0.1:7890"
3
export ALL_PROXY="socks5://127.0.0.1:7890"
4
export http_proxy="http://127.0.0.1:7890"
5
export https_proxy="http://127.0.0.1:7890"
6
export all_proxy="socks5://127.0.0.1:7890"
7

8
# 不希望走代理的放在 no_proxy 里，例如腾讯云的镜像服务
9
export NO_PROXY="localhost,127.0.0.1,::1,mirrors.tencentyun.com"
10
export no_proxy="localhost,127.0.0.1,::1,mirrors.tencentyun.com"

在本地 .ssh/config 里配置端口转发，从而把服务器流量发送到本地

.ssh/config

1
Host server
2
  HostName server_name
3
  User ubuntu
4

5
  # 把“本地 HTTP 代理 7890”自动映射到服务器的 7890
6
  RemoteForward 7890 127.0.0.1:7890

启用本地代理，这样服务器流量就通过本地代理发送给远程服务商了

在服务器上部署代理#

这个方法我已经很久没用过了。关于具体实践，以前可以部署并配置 mihomo 内核 https://wiki.metacubex.one/ ，不清楚现在是否可行。但无论如何这个大方法是可行的

本地终端 ssh#

如果目的是在服务器上使用 Claude Code 等服务，还有一个办法是在本地安装 Claude Code，然后在本地终端用 ssh 连接到服务器，让本地 Claude Code 在本地终端编程，这样也可以实现在服务器上使用 Claude Code 的目的，只需要本地有代理即可

越狱 Gemini CoT

Wed, 25 Mar 2026 00:00:00 GMT

只需要上传一份超大文档就可以 hack 出 Gemini CoT，真是草草又台台啊

因为提前退出 CoT 所以思考完成后 Gemini 无法退出 CoT，循环输出退出 token，最后被强制 rewind 回上一轮对话了

gemini-cot

AI 革命

Thu, 01 Jan 2026 00:00:00 GMT

前三次工业革命改变了人类的生活方式，但这些都只是 单次工业革命。把它们放在一起，才构成更大的 工业革命

而工业革命本身，也不过是更大的 人类革命 的一部分。改变人类命还有农业革命——人类定居、分工、积累剩余、人口爆炸，最终长出城市、国家与文明。还有认知革命——智人获得大规模协作能力，开始用语言、符号、神话、制度去组织世界

而人类革命再往上看，也只是 碳基生命演化史 里的后半段。从原始生命，到复杂生命；从低级结构到高级结构；从无脊椎到脊椎，从鱼类到爬行类、鸟类、哺乳类，再到能够思考、叙事、创造工具的人类——这才是更大的历史背景。过去那些被称为“伟大革命”的东西，放到更大尺度上看，仍然只是碳基生命内部的阶段性跃迁

而 AI 是 非碳基的智能

人类连单次工业革命的影响都无法想象，又如何想象整个工业革命，又如何想象人类革命，又如何想象碳基革命，又如何想象 AI 革命

考试时前几题都选 C，下一题未必选 C。也许下一题不是选择题而是填空题。也许碳基生命该交卷了

歧义

Thu, 01 Jan 2026 00:00:00 GMT

本文持续收录部分常见有歧义的表述

应该#

应该 可以表示 大概率 也可以表示 道德上应当

有时各执己见的两人说的 “应该” “不应该”，一方指的是 “这件事大概率会发生”，另一方指的是 “这件事不符合道德”

坐标系

Thu, 01 Jan 2026 00:00:00 GMT

凡想追求真知识的人，都必须检查定义；定义一错，后面的推理会层层放大错误

为了说明定义的重要性，请容我讲一个问题：

小明是一个学生，他和他的同学平时考试总是拿 100 分，但他考相同难度的大考时总是只能拿 90 分。最近一次大考他又拿了 90 分，他的同学拿了 80 分。请问他发挥得怎么样？

如果与他平时考试的发挥相比，相同难度拿了更低的分数，毫无疑问他是失常发挥
但考虑到他每次大考都失常发挥，这似乎又可以认为是正常发挥
如果再把他的同学纳入考虑范围，平时他只是并列第一，这次大考他是没有并列的第一，按排名看反而是超常发挥

如此看来，小明同时失常发挥、正常发挥、超常发挥，如同波粒二象性一般 3 种理论上互斥的事件同时发生，这就是坐标系的神奇之处呀

如果能统一所有人认知的坐标系，或许 90% 的争辩都不会发生了

踏青

Fri, 04 Apr 2025 00:00:00 GMT

花开有时，花谢无期。
人生无常，人死有终。