AlumKal's Blog

限用汉字，各字按现代字汇必念作第四调。为便各位看客意会，故另设括注，括注用字不受限制。下面各段俱是自作，未用智慧造物。

智慧造物（artificial intelligence）是社会的重大事业，最近的劝业计划（十五五规划）亦大量论述这项技术的各类应用。

预训练要设置巨大计算设备，并注入兆亿数据，化作代号（token）序列，智慧造物借自注意力计算预测下个代号，判定正确或错误后逆向遍溯（back propagation），变易各数，令错误率下降。另外，上述造物会辨认各地话，但并不具备视力。若欲在会话内附带照片，就要借助预训练的视嵌入器（pretrained vision embedding model），令像素块对应的向量对正造物内部各字面概念。

据霍氏大作（arXiv:2203.15556），若预训练算力二倍，验证数据上负对数概率（negative log-likelihood）会近似线性下降。这个洞见叫做放大定律（scaling law），是业界志士致力扩大智慧造物背后的重要信念。

后训练亦是必要。预训练后，智慧造物会预测下个字，但不会对话，计算较弱，更不会调用命令。训练智力项目适用下述技术：固定用户质问，令造物自撰数份复信，各计对数概率，互作对照，励正确并抑悖谬。众类似技术各具特色，暂按下不论。

近日最大变化是智慧造物会借助设备上的命令，为用户做各项任务或制作报告。造物判断现状后构造后续命令，遇到障碍会自动试错，故不必做细碎控制。这项技艺最近进步甚是迅速，对电信业益处巨大。

运用智慧造物的注意事项：造物擅杜撰，用作确切论据务必做另外验证；造物尚未具备社会义务，切莫不设护障；若用按量计费，勿意外泄露密钥。

本文纯人工撰写，无 LLM 成分。请放心阅读。

现如今，我们有大量基于层次化拆解需求的 Agent 框架，比如 Spec Kit、oh-my-openagent 的 Prometheus，以及 Kiro 的 Spec 模式等。它们通过事先调研，把一个大型需求拆解为数十甚至上百个子任务，为每个任务制定严格的完成标准，随后通过子 Agent 根据依赖关系串行或并行地执行这些任务。笔者曾大量使用 Prometheus，但逐渐发现这种方法带来的问题往往多于好处。现在我反而回到了最朴素的用法：在 plan 模式下与 LLM 讨论需求，然后直接生成。考虑到前沿 LLM 的现状，我认为各种结构化的开发模式很可能不仅带不来好处，反而阻碍了 Agent 的工作。下面我会逐一分析结构化开发模式的基本假设在当下 Agentic Coding 的实际情况中是否适用。

关于并行

在传统的软件开发中，实际编写代码需要消耗程序员大量的人力劳动，往往是一个项目中比较费时的部分。因此我们需要在这部分中安排许多人手，于是就不得不设计一套机制以恰当地协调他们的工作。一个程序员无法在可接受的时间里完成一个大型项目的开发，这是我们只能加以接受的事实。

然而在 Agent 时代，这一情况发生了改变。单个 Agent 开发代码的速度往往达到或超过了一个人深入思考并合理设计需求的速度。此外，目前前沿 LLM 的价格较为昂贵，大规模的并行 Agent 往往是个体开发者以及需要降本增效的企业所承受不起的。因此我认为，在大部分场景下，聚焦于如何让一个或少数几个 Agent 高质量地工作，比如何协调大规模 Agent 并行工作，对于通常的软件开发更加重要。

任务的粒度

这些结构化开发方法通常会在项目开始时，由一个会话深入研究用户的模糊需求，生成一份需求文档，而这份文档会在随后的开发阶段被视为几乎不可违背的金标准。早期的 LLM 实现质量很不可靠，因此需要用这样的方法时刻加以约束，防止其跑偏。

但如今的 LLM 性能已经大幅增强，并且普遍配备了 1M token 的上下文，而非此前的 200K。上下文长度对 Agent 能力的影响会随任务形式而变化：对于一个本来就能在 200K 上下文内完成的简单任务，提高上下文长度不会有任何改变；对于一个需要 100K token 的背景知识才能开展的工作，把上下文长度从 200K 提升到 1M token，意味着九倍的实际可用空间；而如果这个任务比较难，需要 300K token 的背景知识，那么 200K 上下文的模型就只能被迫在未充分理解相关信息的前提下工作。总的来说，上下文长度的增长意味着你可以向单个会话分派更多的工作，而不必强行把高度相关的一大块工作拆成两部分。因此你可以期待新一代的 LLM 可以在一个会话内完成更多的开发工作，交付更大块的成果。在这样的前提下，结构化开发方法中对任务的细粒度划分就显得过于低效了。

如果 Spec 出错

结构化开发工具的常见用途是从零开始开发一款小软件，或者在已有软件上开发一个新功能。这里涉及到的对象通常是从技术角度看比较常规的软件，其各组成部分的开发难度与最终目标是比较容易推测的。然而当 LLM 的实力逐渐增强，我们开始期待它从事一些更有挑战性的、带有一定研究性质的任务。当一个开发任务具有研究性质时，结构化开发方法很有可能会成为严重的阻碍。

我们粗略地定义一个任务的研究性为：从头开始达到最终结果所需的时间，与给定一份对最终方案的详细说明（但没有任何代码）后实现该方案所需时间的比值。一个典型的研究性强的任务是学术论文：从一个初步的想法到敲定最终方案的过程需要大量的智力劳动与实验试错，然而最终的产物可能只包含很少的代码。对于研究性强的任务，其各组件所需要满足的指标、甚至是组件划分本身，都是需要通过实验探索才能确定的。当我们把结构化开发方法应用到这种任务上时，要么得到一个欠考虑的 Spec，要么让初步研究并生成 Spec 的过程变得如此之长，以至于抵消了后续开发阶段节省的时间。实际的情况往往是前者。

当一个 Spec 设计不合理，同时又被要求强制遵守时，往往会发生很严重的后果。LLM 一向很不愿意承认自己无法达成任务，相反，它们会尽一切努力尝试绕过限制，以有违常理的方式强行宣称达到了任务目标。当大量这样的组件被组合起来时，LLM 可能直到最后的阶段才能发现，看似正常推进的项目已经千疮百孔，而这时开始补救往往困难重重，甚至只能推倒重来。这显然是我们所不愿看到的。

持续迭代

书不尽言，言不尽意。很多人抱怨 LLM 理解模糊指令的能力很差，这固然是一个可以改良的问题，但我觉得它是无法消除的。你永远无法根据几句话构建出完全符合自己心意的软件，这就需要开发者在软件构建的过程中恰当地给出反馈，引导开发过程走向自己所期望的方向。而结构化的开发方法恰恰反对这一做法，相反，它期待在编码工作开始之前，也就是需求确定阶段，就解决所有这类问题。对应到实际情况，就是期望用户认真阅读 LLM 所生成的每一行 Spec，并针对自己不满意的部分作出指示。这实在是抵消了 Agent 编程带来的很多好处，也要求用户必须有基本的技术背景以便正确审阅 Spec；而当用户缺乏此种能力，或者不愿操心直接一路通过时，就只好等待可能长达数小时的完整开发流程结束，然后在最终验收时才发现结果与自己的预期不相符合了。

如果一个任务需求模糊，那么就需要在执行过程中持续与用户同步并收集反馈；如果一个任务富于研究性，那么就需要不断地根据最新的实验结果修正整体计划。这两类问题都强调开发工作流的持续迭代能力，而这正是结构化的开发方法所不擅长的。

最佳的协作

上述讨论说明，静态的树状划分是一种低效且不能充分利用 LLM 实例的方式。我认为我们需要把更多精力投入到如何协调少数几个 Agent 之间的高效协作上，正如《人月神话》中所推荐的外科手术室团队一般。我在实践中经常使用以下两种双 Agent 工作模式，姑且称为 Reviewer 模式和 Orchestrator 模式。非常有趣的是，这两种模式恰好形成了某种形式的对偶关系。

在 Reviewer 模式中，主 Agent（也就是直接接收用户输入的 Agent）进行主要的开发工作，而当其进行到一定阶段时，便会调用一个只读的子 Agent 检查其上一阶段的工作，确保没有严重偏离原本意图，或引入了不应有的设计失误。诚然，这需要依赖主 Agent 为子 Agent 撰写提示词，不过据我观察，LLM 在大部分时候都会以诚实的态度撰写提示词，而不会暗示 Reviewer 粉饰太平。这种模式比较适合较短的任务，或者大量依赖屏幕前开发者即时反馈的任务，因为你可以在主 Agent 的界面中直接看到开发过程并加以干预。

在 Orchestrator 模式中，主 Agent 负责从全局角度理解一个任务，并将具体的开发工作分派给子 Agent，只提供很少的必要上下文以明确工作的范围。这一模式允许总体架构的存在，但同时保留了更大的弹性，允许根据某一子 Agent 给出的预期之外的结果来修改后续的整体计划。这一模式更适合需要长时间自主运行的任务。

除了 Agent 的组织方式本身，这两种模式还具有一些实用角度的优点：它天然地包含两个异构的角色，你可以很容易地为它们指派不同的模型——比如某种模型擅长编码、而另一种擅长分析，或某种模型额度充足、而另一种额度有限，这些特性都可以很好地被利用。此外，两个模型共同参与决策，也可以减轻单一模型所具有的偏见。以 Anthropic 为代表的部分公司禁止逆向其订阅服务接口并接入其他工具，而这种方法既然不需要额外的辅助设施，也可以规避掉这一问题——直接让主 Agent 通过 CLI 调用子 Agent 就好了。这种方法简单易行，且完全没有逆向接口带来的灰色地带风险。

结语

Spec 类方法的优点在于遵循软件工程的最佳实践、允许并行开发、并且具有可控的质量保证。但人类的软件工程未必适用于 LLM；前沿模型的高速度和高成本使得并行开发并非必选项；开放型任务中 Spec 提供的质量保证反而会成为对质量的伤害。因此，我认为近似串行的工作流与一到两个 Agent 的角色分工，才是最适于发挥 LLM 潜力的协作方式，并在此分享了自己的一些实践心得。

前言

看抽象代数的时候突然想到，群的 Cayley 表和数独一样，都要求每行（列）中的元素互异。那么能不能按照群的规则（即结合律）出一道变种数独题呢？于是简单试了一下。

规则：

• 题面是一个 \(10 \times 10\) 数表（行和列从 \(0\) 开始计数），元素为 \(0 \sim 9\) 的整数；第 \(0\) 行和第 \(0\) 列的值已经给出
• 与普通数独相同，每行、每列的元素不能重复；注意没有九宫格的条件
• 若 \(i\) 行 \(j\) 列的值为 \(x\)，\(j\) 行 \(k\) 列的值为 \(y\)，则 \(i\) 行 \(y\) 列和 \(x\) 行 \(k\) 列的值相同

TLDR：补全一个以 \(0\) 为单位元的 \(10\) 阶群的乘法表。（提示：\(10\) 阶群只有 \(\mathrm{Z}_{10}\) 和 \(\mathrm{D}_{10}\) 两种）

题目

题 1：（表中横、竖线仅作美化排版用途，无实际含义）

\[ \begin{array} {r|rrr|rrr|rrr} 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\ \hline 1 & 0 & & & & & & & & \\ 2 & & & 1 & & & & & & \\ 3 & & 4 & & & & & & & \\ \hline 4 & & & & & & & & & \\ 5 & & & & 2 & & & & & \\ 6 & & & & & & & & & \\ \hline 7 & & & & & & 3 & & & \\ 8 & & & & & 9 & & & & \\ 9 & & & & & & & & & \\ \end{array} \]

题 2：

\[ \begin{array} {r|rrr|rrr|rrr} 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\ \hline 1 & & & & & & & & & \\ 2 & & & & & & & & & \\ 3 & & & 0 & & & & & & 4 \\ \hline 4 & & & & & & & & 0 & \\ 5 & & 7 & & & & & & & \\ 6 & & & & & & & & & \\ \hline 7 & & & & & & & & & \\ 8 & & & & & 2 & & & & \\ 9 & & & & 1 & & & & & \\ \end{array} \]

以下是作者的一些疑问：

1. 存不存在只有 5 个已知数且有唯一解的题面？
2. 有没有比较有效的方法构造这类题目的 \(8 \times 8\) 版本？

自动生成器

时隔一年多突然想起这篇烂尾博客，我惊喜地发现现在的 LLM 已经可以爆杀上文的两个疑问了。以下两节的代码全部由 GPT-5.4 生成。

首先从枚举所有合法的 Cayley 表开始。借助一些（我并不会的）抽象代数知识，可以在近似 \(O(\mathrm{output \_ size})\) 的时间复杂度内完成枚举。生成枚举结果的 GAP 程序见此。生成 3GiB 大小的 \(12 \times 12\) Cayley 表全集需要约 5min。

\(8\) 阶群有 \(2760\) 种 Cayley 表，\(10\) 阶群有 \(108864\) 种，\(12\) 阶群有 \(21621600\) 种。对于 \(8\) 阶和 \(10\) 阶群，可以直接使用（剪枝后的）暴力搜索找出已知数最少且有唯一解的题面。对于 \(12\) 阶群，暴力搜索已经不可行了，因此略作妥协：对于每类群，随机选择一个答案，二分搜索已知数的数量，随机生成题面，若连续 \(1000\) 个题面都有多解，则认为该数量的已知数不足以保证唯一解，尝试更多的已知数。

对于两种 \(10\) 阶群，最少的已知数都是 \(5\) 个：

\[ \begin{array} {r|rrr|rrr|rrr} 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\ \hline 1 & 5 & & & & & & & & \\ 2 & & 4 & & & & & & & \\ 3 & & & & 8 & & & & & \\ \hline 4 & & & & & & & & & \\ 5 & & 7 & & & & & & & \\ 6 & 3 & & & & & & & & \\ \hline 7 & & & & & & & & & \\ 8 & & & & & & & & & \\ 9 & & & & & & & & & \\ \end{array} \]

\[ \begin{array} {r|rrr|rrr|rrr} 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\ \hline 1 & 7 & & & & & & & & \\ 2 & & 8 & & & & & & & \\ 3 & 6 & & & & & & & & \\ \hline 4 & & & & & 8 & & & & \\ 5 & & & & & & 2 & & & \\ 6 & & & & & & & & & \\ \hline 7 & & & & & & & & & \\ 8 & & & & & & & & & \\ 9 & & & & & & & & & \\ \end{array} \]

自动求解器

首先考虑最暴力的求解方法：直接把结合律作为约束，使用求解器求解。使用 Z3 描述这种约束非常简单：

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

op = Function("op", IntSort(), IntSort(), IntSort())
solver = Solver()

for left in range(order):
    for right in range(order):
        solver.add(op(left, right) >= 0, op(left, right) < order)

for element in range(order):
    solver.add(op(0, element) == element)
    solver.add(op(element, 0) == element)
    solver.add(Distinct([op(element, other) for other in range(order)]))
    solver.add(Distinct([op(other, element) for other in range(order)]))

for row in range(1, order):
    for col in range(1, order):
        clue = grid[row][col]
        if clue is not None:
            solver.add(op(row, col) == clue)

for a in range(order):
    for b in range(order):
        for c in range(order):
            solver.add(op(a, op(b, c)) == op(op(a, b), c))

这个程序可以求解 \(8\) 阶和 \(10\) 阶的题目，但对于 \(12\) 阶的题目就无能为力了：五道题目在 1min 的时限内都无法求解并证明唯一性。

能不能做得更好呢？答案是肯定的。我们可以把抽象代数知识融入求解器，告诉它对应阶数的群的所有种类。对于每个种类，任取一个 Cayley 表作为规范形，让求解器搜索题面数字与这一 Cayley 表中元素之间的一一映射。这样，求解器的搜索空间就从 \(121\) 个格子变成了 \(11\) 个元素的排列。改进后的程序可以在 27s 内解决五道 \(12\) 阶题目。

当然——如果融入更多的知识，也就是直接把所有 Cayley 表丢进去，那么遍历一遍就能得到答案了，用时甚至不到一秒钟！看来数学理论对这个奇特的解谜帮助确实很大（笑）

TLDR: 使用 Pandas 读取 CSV 文件时，最好指定 keep_default_na=False, na_values=''。

问题

Pandas 的 read_csv 默认会把长得像无效值的字符串（如 NA、null、None 等）解析为 NaN，而这些字符串有时确实是合法内容（比如某些不知好歹的人的用户名）。这会导致读入 CSV 后重新导出的过程中丢失数据。

Pandas 默认的 NA 值列表可以在文档中找到：

By default the following values are interpreted as NaN: , #N/A, #N/A N/A, #NA, -1.#IND, -1.#QNAN, -NaN, -nan, 1.#IND, 1.#QNAN, <NA>, N/A, NA, NULL, NaN, None, n/a, nan, null.

解决方案

在 read_csv 时指定以下参数：

1
2

df = pd.read_csv('data.csv', keep_default_na=False, na_values='')
df.to_csv(index=False)

keep_default_na=False 的作用是禁用默认的 NA 值列表；na_values='' 的作用是把空字符串视为缺失值。如果去掉后者，则所有包含空单元格的列都会被视作字符串类型，对数值类数据不合理。

美中不足的是，并不存在一个参数可以直接将所有字符串列的空值视作 ''，同时保留数值列的 NaN。不过可以通过后续处理来实现：

1
2

cols = df.select_dtypes(include=['object']).columns
df.fillna(pd.Series('', index=cols), inplace=True)

示例

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

>>> df = pd.read_csv(io.StringIO('str,num\nnull,\n,1')); df
   str  num
0  NaN  NaN
1  NaN  1.0

>>> df = pd.read_csv(io.StringIO('str,num\nnull,\n,1'), keep_default_na=False, na_values=''); df
    str  num
0  null  NaN
1   NaN  1.0

>>> df.fillna(pd.Series('', index=df.select_dtypes(include=['object']).columns))
    str  num
0  null  NaN
1        1.0

自然出怪的特点

在之前我们写的脚本中，绝大多数都假设每一波的刷新时长是一个定值。这使得脚本执行的操作与场上状态基本无关，大幅简化了脚本的编写。

但是，当我们把目光转向自然出怪长生存时，我们会面临很多新的问题：

• 两炮激活可能会刷新延迟
• 双边热过渡可能会意外刷新
• 红眼关随时可能转白
• 收尾的不确定性很大

即便是对于打法非常固定的键控炮阵，这些问题通常也是难以避免的。我们接下来逐个分析这些问题。

刷新延迟和意外刷新在实现上是可以统一的：它们通常的处理方法都是在某个时间点检查是否刷新，视结果执行不同的分支。

在转白之后，我们通常希望改用白眼/快速关的打法以节省资源。转换阵解时可能需要几个过渡波处理残留的红眼。

收尾很难有统一的应对方案，需要视所守列数和炮恢复情况而定。

状态机对前三个问题提供了一种较为泛用的解决方案。它保留了常规逐波/循环定态脚本的易写易读的优点，但同时又有一定的表达能力，足以应对自然出怪冲关的复杂条件。

状态机

在状态机的框架下，阵解由许多个状态组成，状态之间相互连接。每个状态代表一波或其一部分。

状态之间以刷新节点为边界。什么是刷新节点呢？比如你炸了一对激活炮，这时可能激活，也可能没有激活，炮落地的瞬间就是一个刷新节点。

如果阵型里有前场自然输出，有可能你不需要做什么也会自动刷新。这种情况下，刷新节点是连续的。状态转移允许指定一个时间区间，在区间内任意时间激活视作正常激活，区间结束时仍未激活视作延迟。

在刷新节点观测到的场上信息会用来决定转移路径。如果把阵解建模成一张图，那么状态是节点，转移路径就是连接两者的有向边。比如说你执行一组操作（它们被封装在一个状态中），执行之后可能延迟，也可能激活刷新，就需要为它配置两条转移路径。如果你确信某操作不会出现刷新意外，就可以只配置一条转移路径。

每个转移路径都有触发条件。现实中，在根据刷新情况进行状态转移时，我们一般只会使用固定的几种条件。作者实现的转移函数支持以下几种条件：

• 延迟
• 激活，下波为指定波次（如w9/w19）
• 激活，下波转白
• 激活，无特殊情况

状态机的优势在于，如果脚本只使用这几种转移条件，则完全不需要自行编写判断刷新的代码，具体的判断逻辑交由预定义的转移函数处理。

本文接下来以一个经典超多炮阵型——双冰16炮为例，介绍状态机框架下代码的编写。

代码架构

状态机的核心是以下几个变量和函数：

1
2
3
4
5
6
7
8
9

unordered_map<string, ATimeline> states;
string lastState, currentState;

_TransitionKey activate, delay, nogiga, finish;
_TransitionKey WaveIs(std::convertible_to<int> auto... waves);

ATimeline Transition(pair<int, int> wl, auto... args);
ATimeline Transition(int wl, auto... args);
void StartTransition(int wave, const string& state);

Transition函数封装了状态转移的所有逻辑，其调用格式形如Transition(601, key1 = "next_state_name1", key2 = "next_state_name2", ...) （如果你对这种语法感到不解：在C++中，operator=可以被重载，并且返回类型可以任意指定）。其中的key可以是delay、activate、nogiga和finish，对应上一节中提到的四种转移条件（finish等效于WaveIs(9, 19)）。

lastState和currentState是由Transition函数自动设置的，在运阵过程中可以读取。

states用于存储阵解，键代表状态名（可以任意取），值代表该状态对应的操作。在AScript()中，操作被逐个添加到states中，形如：

1
2
3
4

states["s1"] = {
    Transition(601, activate = "s2", delay = "s3"),
    At(300) PP(),
};

这段代码表示若当前状态为s1，则在本波300时刻发一对炮，若401时刻激活，则在下波执行状态s2；若401时刻未激活，则在本波执行状态s3。

状态机一般需要在w1和w10各启动一次（w20不需要纳入状态机中）。启动状态机的代码是：

1
2

StartTransition(1, "state1");
StartTransition(10, "state2");

一个完整的状态机脚本的大致结构是：

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

// 状态机本身的代码

void AScript() {
    // 选卡等等操作

    states["s1"] = {
        Transition(601, activate = "s2", delay = "s3", finish = "final1"),
        // ...
    };
    states["s2"] = {
        Transition(1200, activate = "s1", delay = "s4", finish = "final2"),
        // ...
    };
    // ...

    StartTransition(1, "s1");
    StartTransition(10, "s1");
    OnWave(20) {
        // ...
    };
}

阵解分析

主循环

本教程侧重于键控脚本编写，对阵解设计部分只是简略带过。如果对本节理解有困难可以跳过。

我们采用经典的ch6解：IPP-PP|PPDD循环。运阵过程中有两处可能发生刷新意外：

• IPP刷新
• IPP-PP延迟

对于前一种情况，我们可以把冰波改成IPP|cPP。第二波的PP要同时全伤两波的红眼，设冰波1冰1048激活，加速波389激活（垫舞王激活的最晚时机），得出IPP波波长应为1048-389=659，对应459热过渡。加速波的红眼再冰一下，避免砸炮。

对于后一种情况，我们可以在激活炮之后再补一对炮，然后直接接下一个冰波。在执行IPP-PP|PPDD时，加速波的PP发射时本波僵尸还未刷出。本着能不读刷新倒计时就不读的态度，不妨让这对炮无论冰波是否延迟都照常发射。这样的话，冰波延迟时的激活时机为1248+291=1539。（注：由于引信延迟，实际激活时机也可能是1542。引信延迟并不会给此阵造成任何实质上的困难，但会给脚本编写增加无谓的工作量，因此脚本中关闭了引信延迟）

把状态转移关系画成图，是这样的：

代码如下：

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

// 冰波：IPP-PP 1248
states["hb_IPP"] = {
    Transition(659, delay = "hb_(IPP-)PP", activate = "hb_(IPP|)cPPI"),
    At(1) I(),
    At(459) P(15, 8.325),
    At(1048) PP(8.75), // 1048 = 659 + 389
};
states["hb_(IPP-)PP"] = {
    Transition(1248, activate = "hb_PPDD", delay = "hb_(IPP-PP-)cPP"),
};
// 加速波：PPDD 601
states["hb_PPDD"] = {
    Transition(601, activate = "hb_IPP"),
    At(291) PP() & DD<107>(9),
};
// 冰波延迟：IPP-PP-cPP 1739
states["hb_(IPP-PP-)cPP"] = {
    Transition(1739, activate = "hb_IPP"),
    At(1300) C.TriggerBy(AGIGA_GARGANTUAR & CURR_WAVE)(266),
    At(1539) PP(), // 1539 = 1248 + 291
};
// 冰波意外刷新：IPP|cPPI 659|601
states["hb_(IPP|)cPPI"] = {
    Transition(601, activate = "hb_PPDD"),
    At(195) C.TriggerBy(ADANCING_ZOMBIE, ALADDER_ZOMBIE)(40),
    At(390) I(),
};

细心的读者可能会问：hb_(IPP|)cPPI一定不会延迟吗？事实上热过渡意外刷新和PP延迟对出怪的要求是一定程度上相互冲突的，前一波意外刷新而后一波延迟的概率极低，可以忽略。当然把这一部分补上也是不难的，具体实现就留给读者了。

首代

为了省冰，我们在w1和w10用NDD首代一波。虽然红眼关w10 PPDD不太可能延迟，但保险起见写上好了。脚本很简单，就不细讲了：

1
2
3
4
5
6
7
8
9
10

// 红眼关起手：NDD 601
states["hb_NDD"] = {
    Transition(601, activate = "hb_PPDD", delay = "hb_(NDD-)PP"),
    At(292) N({{3, 9}, {4, 9}}) & DD<106>(9),
};
// NDD延迟：NDD-PP 1092
states["hb_(NDD-)PP"] = {
    Transition(1092, activate = "hb_IPP"),
    At(892) PP(), // 892 = 601 + 291
};

收尾

到目前为止，我们顺利解决了w1~w8，下一个任务是w9/w19。需要注意的是，w9/w19的激活判定只考虑本波僵尸，因此可能出现w9激活后w8红眼仍在场上的情况。

收尾的处理方式需要视阵型特点而定。此阵炮数充足，收尾容错很大。ch6冰循环压力本就不大，加之此阵转白后无需用冰，不需要拖w9/w19的收尾。因此这里采用了一种比较朴素的处理方式。

首先是w9本波的激活操作。既然已经到了收尾波，没有热过渡的必要，可以直接把IPP改成PPI（由于主循环时长3700>3475，这里是能复用上的）。加速波反正早晚得冰，不如也改成PPI。唯一的例外是上波为IPP，此时本波仍需cPPI以保证全伤上波红眼。

极端条件下，可能会出现w9 401激活（对应波长1346），而场上仍有w8三血红的情况。这时虽然剩余的炮不够把它们炸死，但我们可以把这些w8红眼拖到w10。假设w9 401激活，根据w8的类型分类讨论：

• IPP：剩3血红和w8撑杆，猴年马月才能砸炮。一炮收掉残余的撑杆，剩下的2血红交给w10
• (IPP-)PP或(IPP|)cPPI：剩2血红，1510砸炮。垫一下，交给w10收掉
• PPDD或(IPP-PP-)cPP：剩1血红，1161砸炮。一对炮收掉

如果w9 401没有激活，假设收尾使用8门炮，算一下可能的复用：

• IPP-PP|[PP]DD|收尾|NDD|PP[DD]：收尾最短时间3475+291−601×2−398=2166，对应1221激活
• PPDD|I[PP]-PP|收尾|NDD|PP[DD]：收尾最短时间3475+459−1248−601−398=1687，对应742激活
• PPDD|IPP-[PP]-PP|收尾|NDD|PP[DD]：收尾最短时间3475+1048−1739−601−398=1785，对应840激活
• [PP]DD|IPP|收尾|NDD|[PP]DD：收尾最短时间3475+291−601×2−659−291=1614，对应669激活

可以看出除了第一种情况都是白给。第一种情况下，为了收掉w8的红眼，需要早于1161炸一对炮。但如果这对炮导致激活，说明w8和w9的僵尸一定都死了，不需要再炸剩下两对炮。这样复用就能宽松很多，依然不会出问题。

作为演示脚本，就不拖收尾了，直接炸掉就好。预定在1000、1500和2300发炮，如果此时已经进入w10或不存在除伴舞和小鬼之外的僵尸则取消此次发炮。

作者编写了一个简单的EndingHelper函数用于处理这种较简单的收尾。这个函数的原型是：

1
2
3
4

ATimeline EndingHelper(const vector<int>& times, const vector<ATimeline>& ops,
    int withdrawThreshold = 0);
ATimeline EndingHelper(const vector<int>& times, const ATimeline& op,
    int withdrawThreshold = 0);

它的功能是在当前波（EndingHelper执行时的波次）的times[0]时间执行ops[0]，times[1]时间执行ops[1]，以此类推（若ops中只有一个操作，则每次都执行ops[0]）。如果场上没有僵尸（无视小鬼、伴舞，开启女仆时额外无视舞王），或者当前操作对应的时间已经超过了下一波的withdrawThreshold，则取消操作。

比如OnWave(19) EndingHelper({1200, 1800, 2400}, PP(), 0); 的含义为在w19的1200cs、1800cs和2400cs各生效一对炮，保证炮的生效时间不会在w20的0cs之后。若1200cs的炮激活了刷新，则w19的波长为2145cs，这时1800cs的炮会照常发射，但2400cs的炮会被取消。

收尾代码如下：

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

states["hb_final"] = At(-200) CoDo {
    // 发本波的激活炮
    ATime thisWave = now + 200;
    if (lastState == "hb_IPP") {
        // cPPI波的处理和其他波不同
        At(thisWave + 195) C.TriggerBy(ADANCING_ZOMBIE, ALADDER_ZOMBIE)(40);
        At(thisWave + 390) I();
    } else {
        At(thisWave + 291) PP();
        At(thisWave + 360) I();
    }

    co_await (thisWave + 401);
    if (ANowTime(true).time < 0) {
        // 如果收尾波直接刷了（波长1346）
        if (lastState == "hb_IPP") {
            // w8红还剩3血，w8撑杆还在；一炮收掉撑杆，红眼交给w10
            At(thisWave + 900) PP();
        } else if (lastState == "hb_(IPP-)PP" || lastState == "trans_cPP") {
            // w8红还剩2血，1510砸炮；垫一下红眼就行
            At(thisWave + 401) C.TriggerBy(AGIGA_GARGANTUAR)(800);
        } else if (lastState == "hb_PPDD" || lastState == "hb_(IPP-PP-)cPP") {
            // w8红还剩1血，最快1161砸炮；用炮收掉
            At(thisWave + 1161) PP();
        }
    } else {
        // 随便炸炸
        At(now) EndingHelper({1000, 1500, 2300}, PP());
    }
};

代码中通过读取lastState实现了对w8的分类讨论。

收尾段还有一个额外的小问题：如果w8轮到(IPP|)cPPI状态，咖啡豆CD会不够。此时需要特化处理一下这一波，去掉w8的冰，改打cPP|PPIc。为此，需要给IPP状态添加一个WaveIs(8, 18)分支：

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

// 冰波：IPP-PP 1248
states["hb_IPP"] = {
    Transition(659, delay = "hb_(IPP-)PP", activate = "hb_(IPP|)cPPI", WaveIs(8, 18) = "hb_(IPP|)cPPI_w8", finish = "hb_final"),
    At(1) I(),
    At(459) P(15, 8.325),
    At(1048) PP(8.75), // 1048 = 659 + 389
};
// 如果cPPI波出现在w8，需要调整为cPP|PPIc
states["hb_(IPP|)cPPI_w8"] = {
    Transition(601, finish = "hb_final"),
    At(195) C.TriggerBy(ADANCING_ZOMBIE, ALADDER_ZOMBIE)(40),
    At(next_wave + 401) C.TriggerBy(AGIGA_GARGANTUAR)(800),
};

转白

转白是大部分键控自然出怪阵型都需要考虑的事项。一方面，转白后通常可以省冰、省阳光；另一方面，转白后热过渡意外刷新的概率会明显上升。

首先考虑这个阵的白眼关阵解。打P6的话，每3波有一对多余的炮，因此可以垫两波PPDD一波，就不需要冰了。写成轨道是cPP|PPc|PPDD。

这一部分比红眼关简单得多，就不细讲了，直接上代码：

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

states["b_PPDD"] = {
    Transition(601, activate = "b_cPP", delay = "b_(PPDD)-PP", finish = "b_final"),
    At(270) PP() & DD<110>(9),
};
states["b_(PPDD)-PP"] = {
    Transition(1202, activate = "b_PPc", finish = "b_final"),
    At(1002) PP(),
};
states["b_cPP"] = {
    Transition(601, activate = "b_PPc", finish = "b_final"),
    At(195) C.TriggerBy(ADANCING_ZOMBIE, ALADDER_ZOMBIE)(40),
    At(389) PP(8.75),
};
states["b_PPc"] = {
    Transition(601, activate = "b_PPDD", finish = "b_final"),
    At(318) PP(),
    At(599) C.TriggerBy(APOLE_VAULTING_ZOMBIE)(1),
};
states["b_final"] = At(-200) Do {
    ATime thisWave = now + 200;
    if (GetCobReadyTime(4) <= 988) {
        // PPDD收尾，DD于788极限全收撑杆
        At(thisWave + 270) PP();
        At(thisWave) EndingHelper({788}, PP());
    } else {
        // cPP-PP收尾
        At(thisWave + 195) C.TriggerBy(ADANCING_ZOMBIE, ALADDER_ZOMBIE)(40);
        At(thisWave + 389) PP(8.75);
        At(thisWave) EndingHelper({1150}, PP());
    }
};

为什么PPDD波反而要考虑延迟？因为这个状态会用在w10，而大波的普僵进场时间非常晚，401时大量铁桶、铁门仍在可伤域外，在无红关很容易造成延迟。

接下来考虑如何从红眼关阵解过渡到白眼关阵解。分类讨论最后一波红眼所在波次：

• NDD、(IPP-)PP：本来也要接PPDD，直接转到白眼关阵解的PPDD即可
• (IPP-PP-)cPP：这波相比主循环的IPP-PP|PPDD省了一对炮，因此也能转白眼关PPDD
• PPDD：下一波还要处理残余2血红，不能直接转入白眼关。可以先打一波PPI作为过渡，然后转白眼关的PPc
• IPP：原本要接cPPI，但由于不需要压制下波红眼，可以改打cPP，然后转白眼关PPDD

插一句题外话，虽然这个解考虑了所有状态转白的情况，但如果有的状态不能转，需要接着按原阵解打下一波，状态转移函数也支持这种情况。如果nogiga分支未被指定，则接下来会继续执行activate分支，直到遇到包含nogiga分支的状态为止。

更新后的红眼关阵解如下，增加了nogiga分支和trans_PPI状态：

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

// 冰波：IPP-PP 1248
states["hb_IPP"] = {
    Transition(659, delay = "hb_(IPP-)PP", activate = "hb_(IPP|)cPPI", WaveIs(8, 18) = "hb_(IPP|)cPPI_w8", nogiga = "trans_cPP", finish = "hb_final"),
    At(1) I(),
    At(459) P(15, 8.325),
    At(1048) PP(8.75), // 1048 = 659 + 389
};
states["hb_(IPP-)PP"] = {
    Transition(1248, activate = "hb_PPDD", delay = "hb_(IPP-PP-)cPP", nogiga = "b_PPDD", finish = "hb_final"),
};
// 加速波：PPDD 601
states["hb_PPDD"] = {
    Transition(601, activate = "hb_IPP", nogiga = "trans_PPI", finish = "hb_final"),
    At(291) PP() & DD<107>(9),
};
// 冰波延迟：IPP-PP-cPP 1739
states["hb_(IPP-PP-)cPP"] = {
    Transition(1739, activate = "hb_IPP", nogiga = "b_PPDD", finish = "hb_final"),
    At(1300) C.TriggerBy(AGIGA_GARGANTUAR & CURR_WAVE)(266),
    At(1539) PP(), // 1539 = 1248 + 291
};
// 冰波意外刷新：IPP|cPPI 659|601
states["hb_(IPP|)cPPI"] = {
    Transition(601, activate = "hb_PPDD", nogiga = "b_PPDD", finish = "hb_final"),
    At(195) C.TriggerBy(ADANCING_ZOMBIE, ALADDER_ZOMBIE)(40),
    At(390) I(),
};
// 如果cPPI波出现在w8，需要调整为cPP|PPIc
states["hb_(IPP|)cPPI_w8"] = {
    Transition(601, finish = "hb_final"),
    At(195) C.TriggerBy(ADANCING_ZOMBIE, ALADDER_ZOMBIE)(40),
    At(next_wave + 401) C.TriggerBy(AGIGA_GARGANTUAR)(800),
};
****
// 转白过渡
states["trans_PPI"] = {
    Transition(601, activate = "b_PPc", finish = "b_final"),
    At(318) PP(),
    At(360) I(),
};
states["trans_cPP"] = {
    Transition(601, activate = "b_PPDD", finish = "hb_final"),
    At(195) C.TriggerBy(ADANCING_ZOMBIE, ALADDER_ZOMBIE)(40),
};

其他

现在只剩w20了！由于ch6冰平衡过于轻松，我们干脆冰消珊瑚好了：（才不是因为w19不拖的情况下w20不好打呢）

1
2
3
4
5
6
7

OnWave(20) {
    At(96) I(),
    At(380) P(15, 9), // 热过渡
    At(953) PP(), // 全伤巨人
    At(1220) PP(), // 全伤撑杆
    EndingHelper(PP(), {1600, 2300}),
};

最后还需要启动状态机。红眼关以NDD起手，无红关以PPDD起手：

1
2
3

auto initialState = AGetZombieTypeList()[AGIGA_GARGANTUAR] ? "hb_NDD" : "b_PPDD";
StartTransition(1, initialState);
StartTransition(10, initialState);

完整代码

附赠一个简短的天台十炮脚本，阵解主体只有23行。

总结

本文以双冰16炮键控脚本为例，展示了状态机框架的大部分核心要素。这一方法的主要优势是，使用状态机编写非定态脚本时，只需复制状态机本身的代码，并根据阵解定义新的状态和转移，无需设计复杂的嵌套或回调，也不必写大量重复的刷新检测代码。

键控炮阵冲关仍有一些难点有待解决。以下是我想到的一些，希望本文能够抛砖引玉。

其一是测试较为困难。随机发生的刷新意外和转白波次的不同都会导致轨道改变，因此执行轨迹的种类数会远多于定态演示脚本，人工分析容易有所遗漏。跳帧测试配合回放功能是一个可行的测试手段，但仍然不够高效。

其二是收尾难以系统化。可以看到，文中的阵型完全没有拖收尾。拖收尾是一件很复杂的事，上波残留僵尸、本波出红情况以及场上能垫的位置都需要考虑。笔者暂未想到能够统一大部分阵型收尾的框架。

第一次不依赖大模型用 Lean 证明了一个没那么显然的定理，在此记录一下。写得很 naive，希望将来自己的水平能有所长进吧。

题目：设 \(d(n)\) 表示自然数 \(n\) 在十进制下的各位数字之和。证明：对于任意自然数 \(n,\,k\)，若 \(1 \le n \le 10^k\)，则有 \(d\left(\left(10^k - 1\right) \cdot n\right) = 9k\).

思路：把 \(\left(10^k - 1\right) \cdot n\) 拆分为高 \(k\) 位和低 \(k\) 位两部分。高 \(k\) 位的值为 \(n - 1\)，低 \(k\) 位的值为 \(10^k - n\)。注意到 \((n - 1) + (10^k - n) = 10^k - 1\)，因此这两部分的各位数字互补，每一位的数字之和都为 \(9\)。因此总和为 \(9k\)。

代码如下：

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

import Mathlib

def digitSum (n : ℕ) := (Nat.digits 10 n).sum

theorem digitSum_divmod_10 (n : ℕ) :
  digitSum n = digitSum (n / 10) + (n % 10) := by
  by_cases hn : n = 0
  · simp [hn]
  · simp [digitSum]
    rw [Nat.digits_eq_cons_digits_div (by decide) hn]
    simp [add_comm]

theorem digitSum_eq_self_iff (n : ℕ)
  : n < 10 ↔ digitSum n = n := by
  constructor
  · intro hn
    by_cases hn2 : n = 0
    · simp [digitSum, hn2]
    · simp [digitSum, Nat.digits_of_lt _ _ hn2 hn]
  · contrapose!
    intro hn
    apply Nat.ne_of_lt
    rw [digitSum_divmod_10]
    nth_rw 3 [← Nat.div_add_mod n 10]
    calc digitSum (n / 10) + n % 10
      _ ≤ n / 10 + n % 10 := by simp [digitSum, Nat.digit_sum_le]
      _ < 10 * (n / 10) + n % 10 := by
        have : n / 10 > 0 := Nat.div_pos hn (by decide)
        linarith

theorem digitSum_divmod_power_of_10 (n k : ℕ)
  : digitSum n = digitSum (n / 10^k) + digitSum (n % 10^k) := by
  induction k generalizing n with
  | zero => norm_num; simp [Nat.mod_one, digitSum]
  | succ k ih =>
    -- LHS: digitSum n
    -- digitSum n = digitSum n/10^k + digitSum n%10^k
    -- digitSum n/10^k = digitSum n/10^(k+1) + n/10^k % 10
    rw [ih, digitSum_divmod_10]
    rw [Nat.div_div_eq_div_mul, ← Nat.pow_add_one, add_assoc]
    -- RHS: digitSum n/10^(k+1) + digitSum n%10^(k+1)
    -- digitSum n%10^(k+1) = digitSum n%10^(k+1) / 10^k + digitSum n%10^k
    -- n%10^(k+1) / 10^k = n/10^k % 10
    nth_rw 4 [ih]
    have : 10 ^ k ∣ 10 ^ (k + 1) := Nat.pow_dvd_pow _ (Nat.le_add_right _ _)
    rw [Nat.mod_mod_of_dvd _ this]
    rw [pow_succ, Nat.mod_mul_right_div_self]
    nth_rw 4 [(digitSum_eq_self_iff _).mp]
    exact Nat.mod_lt _ (by decide)

lemma complement_divmod_10 {a b k : ℕ} :
  a + b = 10 ^ (k + 1) - 1 ↔ a / 10 + b / 10 = 10 ^ k - 1 ∧ a % 10 + b % 10 = 9 := by
  constructor
  · intro h
    have h2: (a % 10 + b % 10) % 10 = 9 := by
      rw [← Nat.add_mod, h]
      induction k with
      | zero => simp
      | succ k ih =>
        rw [Nat.pow_succ, Nat.mod_eq_sub_iff (c := 1) (by decide) (by decide)]
        rw [← Nat.pow_succ, Nat.sub_add_cancel (Nat.one_le_pow _ _ (by decide))]
        apply Nat.dvd_mul_left
    omega
  · rintro ⟨ha, hb⟩
    rw [← Nat.div_add_mod' a 10, ← Nat.div_add_mod' b 10]
    have : (a / 10 * 10 + a % 10) + (b / 10 * 10 + b % 10)
      = (a / 10 + b / 10) * 10 + (a % 10 + b % 10) := by ring
    rw [this, ha, hb]
    rw [Nat.sub_mul, ← Nat.pow_succ]
    have : 10 ≤ 10 ^ (k + 1) := by apply Nat.le_pow; simp
    rw [← Nat.sub_add_comm this, Nat.add_sub_add_right]

lemma digitSum_eq_9k_of_complement {a b k : ℕ}
  (h : a + b = 10 ^ k - 1) :
  digitSum a + digitSum b = 9 * k := by
  induction k generalizing a b with
  | zero => norm_num at *; simp [digitSum, h]
  | succ k ih =>
    rw [complement_divmod_10] at h
    rw [digitSum_divmod_10 a, digitSum_divmod_10 b]
    rw [mul_add_one, ← ih (h.left), ← h.right]
    ac_rfl

-- For all natural number n, k such that 1 ≤ n ≤ 10^k, show that the digit sum of (10^k - 1)n is 9k.
example (k : ℕ) (n : ℕ) (hn : 1 ≤ n ∧ n <= 10 ^ k) :
  digitSum ((10 ^ k - 1) * n) = 9 * k := by
  -- (10^k - 1) * n = 10^k * n - n = (n - 1) * 10^k + (10^k - n)
  -- divide the digits into two parts：
  -- 1. digitSum ((n - 1) * 10^k) = digitSum (n - 1)
  -- 2. digitSum (10^k - n) = digitSum ((10^k - 1) - (n - 1)) = 9 * k - digitSum (n - 1)
  let x := (10^k - 1) * n
  have hSplit : x / 10^k = n - 1 ∧ x % 10^k = 10^k - n := by
    rw [Nat.div_mod_unique (Nat.pow_pos (by decide))]
    constructor
    · dsimp [x]
      zify [hn.left, hn.right, show 1 ≤ 10^k from Nat.one_le_pow _ _ (by decide)]
      ring
    · exact Nat.sub_lt (Nat.pow_pos (by decide)) hn.left
  rw [digitSum_divmod_power_of_10 _ k, hSplit.left, hSplit.right]
  apply digitSum_eq_9k_of_complement
  rw [← Nat.sub_add_comm hn.left, Nat.add_sub_of_le hn.right]

概述

其后，京兆尹将饰官署，余往过焉。委群材，会众工。或执斧斤，或执刀锯，皆环立向之。梓人左持引，右执杖，而中处焉。量栋宇之任，视木之能举，挥其杖曰：“斧！”彼执斧者奔而右；顾而指曰：“锯！”彼执锯者趋而左。俄而斤者斫，刀者削，皆视其色，俟其言，莫敢自断者。其不胜任者，怒而退之，亦莫敢愠焉。画宫于堵，盈尺而曲尽其制，计其毫厘而构大厦，无进退焉。既成，书于上栋，曰“某年某月某日某建”，则其姓字也。凡执用之工不在列。余圜视大骇，然后知其术之工大矣。
——《梓人传》柳宗元

我花了一周的时间，用 Claude Code 从头搓了一个前端 app。花在项目上的时间大约有 40h。代码总计 14k 行，去除单元测试、注释和空行后约 6k 行。项目的所有代码都是 Claude Code 生成的，我只提供了约 2000 字的初始项目描述和后续开发过程中的 prompt。

总体来说，Claude Code 的表现相当不错，我最担心的界面美观性对它而言其实不是问题。我观察到的比较明显的缺点有：

• Token 用量过大：通过 API 高强度使用 Claude Code 的话花费能达到 $5/h 级别，这已经和人类实习生的工资在同一个数量级了。
• 重构能力较弱：对于较大的项目，Claude Code 很难在重构时追踪到所有需要修改的文件，导致重构很难一遍过，需要反复修正。或许换个 prompt 能好点。
• 处理复杂功能时表现不佳：我本来想让 Claude Code 实现一个 drag & drop，但它死活写不对，只好先放弃了。

瑕不掩瑜，强烈建议需要大量写代码（尤其是前后端、CLI等典型场景）的人试一试 Claude Code。Claude Pro $20/mo 的订阅价格和它的功能相比非常划算。目前 Claude Pro 提供的额度还是很慷慨的，大概能支撑你每 5h 高强度使用（上一条恢复后立刻开始下一条）2h。低强度使用的话根本不需要担心额度问题。

小技巧

以下是我使用 Claude Code 的过程中摸索出来的一些小技巧。

通知

Claude Code 执行一个任务可能需要几分钟，这段时间一直盯着终端有点浪费时间。可以加个 hook，让它在请求权限或任务完成时发送通知。把以下内容写到 ~/.claude/settings.json 中即可。（非 Linux 系统请自行修改命令）

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

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r \"\\\"notify-send -a 'Claude Code' 'Notification' '\\(.message)'\\\"\" | bash"
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "notify-send -a 'Claude Code' 'Task Finished' 'Claude is waiting for your input'"
          }
        ]
      }
    ]
  }
}

Playwright MCP

Playwright MCP 可以让 Claude Code 以 a11y tree 的形式访问网页并操作，这样它就可以自动测试网页了。执行以下命令以添加：

1

claude mcp add playwright -- npx @playwright/mcp@latest --executable-path /usr/bin/chromium --isolated --headless

浏览复杂网页时 token 用量不小，按量计费时需要注意。

Think

在 Claude Code 中，思维链模式需要通过特定关键词触发。

These specific phrases are mapped directly to increasing levels of thinking budget in the system: "think" < "think hard" < "think harder" < "ultrathink." Each level allocates progressively more thinking budget for Claude to use.

在实现复杂功能之前，开启 plan mode 并加入 ultrathink 关键词可以让 Claude Code 先思考出一个详细的计划。

中途输入

你可以在任何时刻向 Claude Code 提供输入，它会在完成下一次工具交互后读入这些内容。比如你发现它犯错后，你可以及时纠正，而不需停止整个任务。

继续对话

claude --resume 可以选择一个之前的对话继续进行。claude --continue 会继续最近的对话。

过长的对话会增大 token 用量。适时清空上下文或者使用 /compact 命令可以减少花费。

软件工程

TBD

这门课有点离谱，很多题没有唯一客观答案，还不对应视频原文。本人用了一些奇怪的方法才试出答案。

二三联防

1. 篮球23区域联防通常适用于哪种情况？
   对方投篮能力差或陷入低迷
2. 在篮球比赛中2-3区域联防战术的核心目的是什么？
   保护篮下，限制对方内线得分
3. 区域联防战术中，防守队员主要依据什么来判断自己的防守位置？
   球的位置
4. 篮球2-3区域联防的优点包括哪些？
   压迫感强，给对方造成心理压力
   容易造成对方失误
   限制对方突破和中距离投篮
5. ​篮球2-3联防的应用场景包括哪些？
   面对拥有身高和体型优势的内线球员时
   比赛关键时刻需要加强防守时

进攻二三联防

1. 攻2-3联防时，哪种方式最能有效破解上线防守？
   切入并传球给空位球员
2. 进攻2-3联防时，以下哪项是球员最需要避免的？
   忽视与队友之间的配合
3. 当后卫发现低位防守队员补防时，应如何应对？
   观察场上形势，选择传球或突破
4. ​进攻2-3联防时，如何利用对方的防守空隙？
   多传球，制造进攻方人数多于防守方的局面
5. ​在进攻2-3联防时，以下哪些策略是有效的？
   利用外线投射能力强的球员吸引防守
   保持进攻节奏，避免被防守打乱
   加强内线的篮下进攻

身体素质（上）

1. 坐姿臂屈伸动作是练习（）非常有效的动作之一。
   肱三头肌
2. 我们在做壶铃甩摆练习时，通过伸髋肌群发力将壶铃甩出，在髋关节完全打开时，壶铃应该甩至与（）齐平高度。
   眼睛
3. 篮球运动专项身体素质训练可以保证运动员掌握有难度的动作技术质量，提高我们的（），培养我们优良的作风和顽强的意志品质，增强篮球比赛的对抗性和观赏性。
   竞技水平
   延长运动寿命
   应变能力
   减少运动创伤
4. 我们可以通过（）动作来进行下肢力量训练。
   哑铃前蹲
   壶铃甩摆
   保加利亚分腿蹲
5. 我们可以通过（）动作来进行核心力量训练。
   仰卧卷腹抛接球
   仰卧卷腹
   坐姿卷腹
   仰卧负重卷腹

半场人盯人防守

1. 人盯人防守战术中，防守队员主要盯防的是？
   各自负责的进攻球员
2. ​在人盯人防守中，当对手运球突破时，防守球员应：
   跟随对手，尽量干扰其运球和突破
3. 在人盯人防守中，防守队员应如何调整自己的防守位置？
   随时注意人、球、对手、篮圈的方位
4. 在人盯人防守中，当防守无球队员时，防守队员应主要注意什么？
   对手的跑动方向
5. 人盯人防守的基本要求包括哪些？
   人球兼顾
   盯人为主
   控制对手

进攻半场人盯人防守

1. 进攻半场人盯人防守战术打法的基础是（）之间的进攻配合。
   两三名队员
2. 进攻半场人盯人防守的方法，应根据全队，特别是（）的身体、技术条件情况来确定。
   中锋
3. ‌进攻半场人盯人时要先确定进攻的（），选择适合队伍的进攻落位。常用的落位阵型有1-2-2、1-3-1、2-3等。
   区域与结构
4. 进攻半场人盯人防守，常见的战术打法有：
   通过中锋打法
   移动进攻打法
   综合性进攻打法
5. 进攻半场人盯人防守是由哪些配合来组织全队进攻战术的？
   突分
   策应
   掩护
   传切

身体素质（中）

1. 三人直线快攻（往返）是一种（），将多种基础练习综合起来进行循环练习。
   高强度间歇训练
2. ​运动员进行低强度、长时间不间断的训练方法，主要目标是提高（）和发展基础有氧代谢能力。
   心肺功能
3. 有氧耐力和无氧耐力是两种不同的体能素质，主要区别在于（）。
   运动方式
   运动时间
   供能方式
   锻炼效果
4. 下列哪几个项目属于柔韧练习。
   伸展运动
   坐位体前屈
5. 灵敏素质是指在各种突变条件下，运动员（）的能力，是复合素质的综合表现。
   随机应变
   转换动作
   改变体位

全场紧逼人盯人防守

1. 全场紧逼人盯人防守时，防守队员应如何利用场地空间？
   分散在场地的各个角落
2. 全场紧逼人盯人防守时，要求防守球员要有充分的体力与信心，（）及其顽强拼搏作风。
   速度快、反应灵敏
3. 在全场紧逼人盯人防守中，防守球员对持球者的逼抢主要是为了
   制造对手失误
4. 全场紧逼人盯人防守的优势在于：
   使进攻方难以组织有效的进攻战术
   限制对手的传球和移动
   消耗防守队员体力
   制造对手失误，增加抢断机会
5. ‍全场紧逼人盯人防守是以个人防守为基础，综合运用（）等防守基础配合所组成的全队防守。
   夹击
   关门
   换防
   挤过

进攻全场紧逼人盯人防守

1. 进攻全场紧逼人盯人防守时，以下哪项策略是有效的？
   减少个人运球，多利用团队配合
2. 破解全场紧逼人盯人防守时，球员之间应该如何配合？
   保持适当的间距，以便传球和移动
3. 在进攻全场紧逼人盯人防守时，接应队员积极跑动的正确做法是？
   快速而准确地移动，以制造进攻方人数多于防守方的局面
4. 在进攻全场紧逼人盯人防守时,接应队员要把握（）的配合原则，尽量减少传接球的失误，为全场进攻建立基础。
   横向跑动与纵向传接球
5. 在进攻全场紧逼人盯人防守时，以下哪些策略是有效的？
   保持球员之间的间距，以便传球和移动
   快速转移球权，避免长时间持球

身体素质（下）

1. 下列拉伸动作中，主要拉伸大腿后侧肌肉的动作是（ ）。
   腿后侧拉伸
2. 做屈肘水平外展动作过程中，要求（）肌群要放松，保持收腹挺胸。
   颈部
3. 柔韧素质是指人（）的伸展能力。
   肌肉
   关节活动幅度
   韧带
4. 柔韧训练可分为（）等练习方式。
   主动性
   被动性
   混合性
5. 做弓箭步转体练习时，前腿屈膝形成前弓步，后腿跟随屈膝90°，同时手臂水平举后，前弓步腿的同侧手臂向后旋，带动（）向后转直至达到最大幅度。
   头部
   上身

期末测试

1. 在2-3联防时，外线防守队员应如何对待突破能力强的对手？
   保持距离，等待协防
2. 进攻2-3联防时，哪种战术可以制造进攻球员多于防守球员的局面？
   Motion Offense（流动进攻）
3. 仰卧卷腹训练时，由（）发力将上体卷起，同时双臂随身体向前伸，直至指尖能够触及到脚。
   腹部肌群
4. 全场紧逼人盯人防守战术是与对方在（ ）展开全面激烈的争夺。
   全场
5. 在全场紧逼人盯人防守中，如何有效限制对手的传球？
   全体球员收缩防守，减少传球空间
   切断传球路线，迫使对手失误
6. 有氧耐力通常指运动员长时间进行低强度运动的能力，主要目标是提高（）和发展（）能力。
   基础有氧代谢
   肌肉力量
7. 进攻2-3联防时，以下哪些注意事项是正确的？
   保持球的移动，避免停滞不前
   外线球员应随时准备接球并投射
   球员之间应保持良好的沟通，协同作战
8. 以下哪项是人盯人防守的注意要点？
   防守时以人为主，人球兼顾
   防守时应尽量靠近对手，不给其投篮或传球的空间
   防守无球队员时，主要任务是防止对手接球
9. 进攻半场人盯人时要选择适合队伍的进攻落位，常用的落位阵型有（）
   2-3
   1-3-1
   1-2-2
10. 破解全场紧逼人盯人防守时，以下哪些做法有助于提升进攻效率？
    保持球员之间的默契和沟通
    快速而准确地做出进攻决策

由于 Transformer 本质上是位置无关的，因此通过正确设置 positional embedding 和 attention mask，我们可以把多个“序列”合并到一个序列里进行推理。当这些序列具有很长的公共前缀时，这种方法会比 batched inference 更高效。这种方法的具体用途不是本文的重点，此处不做展开。

但是，Transformers 库的自带 API 并不支持传递 attention mask 矩阵，而只支持选择是否 mask 掉整个 token（这种 mask 是用来处理 padding 的）。一种常见的解决方法是直接修改模型的代码，比如 REST 的实现。显然，这种方法在需要测试多种模型时会很麻烦。

有没有更通用一点的方法呢？有的！通过阅读源码可以发现，当模型把 2d 的 attention mask（这个参数是从 forward 一路传过来的）转化为 4d 时，如果输入已经是 4d 的话，这个函数会直接返回输入。因此通过这个不在文档里的 API，就可以传递 attention mask 矩阵了。

代码大概是这样的：（注意传入的 mask 值应为 -inf/0 而非 0/1）

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

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

# Load model
model_name = "Qwen/Qwen2.5-0.5B-Instruct"
model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(model_name)

# Create test input
message = "You are a are not a"
message_tokenized = tokenizer.encode(message, return_tensors="pt").to(model.device)
assert message_tokenized.shape[-1] == 6

# Create position_ids and attention_mask according to the tree structure
position_ids = torch.Tensor([[0, 1, 2, 1, 2, 2]]).long().to(model.device)
attn_mask_bool = torch.Tensor([[[
    [1, 0, 0, 0, 0, 0],
    [1, 1, 0, 0, 0, 0],
    [1, 1, 1, 0, 0, 0],
    [1, 0, 0, 1, 0, 0],
    [1, 0, 0, 1, 1, 0],
    [1, 0, 0, 1, 0, 1],
]]]).bool()
attn_mask_float = torch.where(attn_mask_bool, 0.0, -torch.inf).to(model.device)
print("position_ids:", position_ids.shape)
print("attn_mask_float:", attn_mask_float.shape)

r'''
树的结构：
        - are ----- a
       /
You ---           - not
       \         /
        - are ---
                 \
                  - a

如果实现正确，两个 "are" 和 "a" 的 logits 应该相同
'''

# Run model
with torch.no_grad():
    outputs = model(
        message_tokenized,
        position_ids=position_ids,
        attention_mask=attn_mask_float
    )
logits = outputs.logits
print("logits:", logits.shape)
print(f"{torch.allclose(logits[0, 1, :], logits[0, 3, :])=}")
print(f"{torch.allclose(logits[0, 2, :], logits[0, 5, :])=}")

输出为：

1
2
3
4
5

position_ids: torch.Size([1, 6])
attn_mask_float: torch.Size([1, 1, 6, 6])
logits: torch.Size([1, 6, 151936])
torch.allclose(logits[0, 1, :], logits[0, 3, :])=True
torch.allclose(logits[0, 2, :], logits[0, 5, :])=True

这种方法的优点：

• 对大部分 Transformer 模型即插即用
• 不需要深入模型的实现细节

这种方法的缺点：

• 不是官方支持的 API，随时可能失效
• 不支持 Flash Attention 2

收录了一些博主喜欢的实用工具。本页面不定期更新。

计算

Qalculate!

功能非常全面且设计合理的 PC 端计算器。（高级计算器和编程语言之间并没有明确的区隔；由于它很重视 fuzzy parsing，所以我还是将其算作计算器）

支持的特性非常多，比如大量非初等函数、简单的符号计算、不确定度传播、单位转换等等。详见官方示例。

IPython

博主在科学计算方面基本只会 Python 生态，会用 MATLAB 或 Mathematica 的人可以忽略此节。

Python 自带 REPL 的上位。支持保存历史记录、语法高亮以及用·exit 而非 exit() 退出等。其中一部分功能也添加到了 Python 3.13 的新 REPL 中。

IPython 还支持一些拓展语法。博主比较常用的有：

• 按 Ctrl+R 可以搜索历史记录
• 函数/类名后加 ? 可以查看其帮助文档
• Tab 补全可以补全目录/文件名
• 全局变量 _ 可以访问上一个返回值，Out[i] 可以返回第 i 个语句（块）的返回值

Plotly

比 Matplotlib 更现代的 Python 绘图库。这个库视 DataFrame 为一等公民，而且默认就能生成美观的交互式图表，适合 prototyping。

美中不足的是深度定制样式还是不如 Matplotlib 方便，毕竟后者资料太多了。而且现在有大模型。

网页小工具

Pastebin

无需注册，支持不超过 50MB 的二进制文件，可以直接 POST/GET 的 pastebin。

最朴素的就是最好用的。

Windows 工具

PowerToys

由微软官方开发的一组 Windows 上的奇怪小工具。本人用它把 CapsLock 键改成了 Backspace（因为我打字准度太差了

AutoHotkey

用于操作自动化的脚本语言，可以写一些快捷键什么的。其实拿来写游戏的挂机脚本都可以，就是满屏 ImageSearch 啊 Click 啊可维护性太差了。

WizTree

可以非常快速地统计出磁盘占用的树形结构，清理磁盘空间时很有用。