0.15.6：测到的数字要先解释清楚

这一版最大的变化是新增一条原则：自己测出来的数字，在相信它、汇报它、或据此行动之前，必须先说明它在测什么。配套有一份基准测试检查清单（benchmark checklist）。

这次提交是 lauren 在 2026-10-03 12:37（北京时间）写下的 23e4138。提交说明原文是 feat(pstack): port explain-the-number, fresh subagents, hourly autopilot tick, PR headings, schema-first cast (0.15.6)。上一版译文对照的提交是 12d587d（插件 0.15.5）。下面按使用时会碰到的几组来说。

两条新 skill

解释这个数字

新原则叫 Explain the Number，页面在 解释这个数字。它归在验证组。模型不会自己调用它（frontmatter 里 disable-model-invocation: true），由主模式 /poteto-mode 在该用的时候读它。

什么时候用：你要相信、汇报，或依据一个自己测出来的数字行动。数字可以是提速、退步、吞吐量（throughput）、延迟（latency），或一次评测结果。

要做的事，原文写成六步，这里按原意说：

1. 问「为什么不是两倍？」。说出卡住结果的资源或代码，例如某个核心、一把锁、磁盘、网络，或施压程序本身。依据必须来自运行时的剖析或系统计数。光读代码猜，不算。
2. 列出这个数字还可能在测别的什么：请求出错、工作被跳过或命中缓存、某一方没调优、随机波动、改动的部分太小。逐条用证据排除。
3. 运行次数、波动范围、限制因素，和数字放在一起。
4. 性能数字要完整走一遍下面的检查清单。评测结果要问：每次是否真的完成了任务，差距在多次试验和不同模型之间是否成立，这个场景是否重要。
5. 跳过的迹象：没有运行次数，没有范围，没有限制因素，或者声称节省的时间比被改的那部分原本花的还多。
6. 它和「证明它能工作」（Prove It Works）不一样。那条查产出是真的。这条查数字确实是你说的意思。

原文有两句，照录：

A run that went wrong still prints a plausible number.

一次出了问题的运行，照样会打印出一个看起来合理的数字。

If you cannot say why the number is not twice as good, you do not know what you measured.

如果你说不出这个数字为什么没有好一倍，你就并不知道自己测的是什么。

基准测试检查清单

新 skill 是 基准测试检查清单。跑基准、汇报测得的提速或退步、做 PR 前后对比、给爬坡优化（hillclimb，对着一个指标反复改）做测量工具，或在两个库、两套配置之间做选择时用它。

有一个例外：用户只要一个大概数，可以只跑一次。第 4 问和第 7 问仍然要查，并说明只跑了一次。原文写明：「在几个选项之间做选择，永远不算大概估算。」

动手之前先做三件事：写下打算发布的那句结论；读一遍测量脚本，弄清它计时和统计了什么；用 uptime 和 nproc 看机器负载和核心数。机器忙，就让两方交替跑，并在报告里说明。

七个问题：

1. 为什么不是两倍？找出限制因素。剖析放在不拿来汇报的运行里做。盯住施压程序，它先满负荷，你测到的就是它。
2. 调优了吗？每一方都按生产方式运行。没调优之前不能选赢家。
3. 超出极限了吗？算一算。去掉占一次运行 10% 的部分，整次运行最多大约快 11%。超出这个限度，说明测到了缓存、空操作或错误。
4. 出错了吗？统计失败次数，并检查输出是对的，不只是有输出。
5. 能重现吗？每一方至少 5 次，交替进行，报中位数和范围。差距小于波动，视为没差别。
6. 对整体重要吗？测用户真正等待的完整路径，并说明局部结果占整体的份额。
7. 工作真的发生了吗？惰性代码、没人等待的异步、被即时编译器丢掉的结果，都会给没做的工作产出数字。

报告里的结论只能是四种之一：更快、更慢、没有可测出的差别、无法下结论。数字要带单位、次数、范围和限制因素。说不出限制因素、有一方没调优、或第 4 问和第 7 问没法查，必须判为无法下结论。PR 正文只放一个主要数字。

原文有一句，照录：

If one side runs on defaults, you compared configurations, not implementations.

如果有一方用的是默认设置，那你比较的是配置，而不是实现。

这两条已经接进主模式和两本性能手册。poteto-mode 在跑基准或汇报测得的提速、退步时，先用检查清单。性能问题 在抓到基线之后，用清单检查这条基线和之后的每个数字。爬坡优化 在冻结测量工具之前先用清单检查，并让工具打印出错次数和完成的工作量。

子代理默认用全新的

以前，同一段对话里的后续工作可以续用已经在跑的子代理（subagent，主对话派出去干活的那个代理）。这一版改成默认换一个新的。

poteto-mode 新增了一段「默认用全新子代理」。新工作交给新的子代理，并附上完整背景：原始任务、之后的每条指示、上一个代理的报告和分支。修复一轮、后续工作、重试、队列里的下一项，都这样做。只有新工作依赖难以搬走的状态时才续用：那个代理的本地副本、未提交的修改，或它仍在跑的进程，例如开发服务器、模拟器，或盯着 PR 的监视进程。对正在跑的代理说停，不算续用。PR 负责人这个角色可以比某一个代理活得更久。那个代理返回之后，由新的代理接下下一轮。

poteto-agent 的说明从「续用已有代理」改成「每个新任务启动一个新代理」。

全自动落地 的第 5 步也改了：PR 负责人合并之后返回，由新的负责人接手下一项。

swarm 里，结果不合格时，从「重新运行那个工人」改成「重新启动一个新工人」。

使用上的差别：不要假设上一个子代理还记得你后来补充的话。新开一个，把背景写全。

自动驾驶：每小时巡检，做完一块就推送

自动驾驶指两份 playbook：全自动落地 和 先审后合的栈。前者由每个 PR 的负责人一路做到合并。后者把一条 PR 栈交给你审、由你合并。

这一版删掉了设置 /goal。巡检不再是大约 30 分钟一次，也不再区分本地和云端两套做法。两边都是每小时一次，命令是 /loop 1h。巡检时只重读手册，不再重读一份已设置的目标。进展看已推送的分支和决策记录。卡住的、无法开始下一轮的负责人会被换掉。

合并前的检查更细。新提交已经通过 CI（持续集成，合并前自动跑的检查），并且补丁指纹（patch-id，用来判断补丁内容有没有变）和裁决一致时，主干再变动不强制再变基（rebase，把分支接到最新主干上）。但是合并前要拉取主干，确认没有冲突。还要看主干新改的文件里，有没有本 PR 改过的文件，或决定跑哪套 CI 的配置文件。有的话，重新变基，并重跑 CI。

首次推送之后，每完成一个可验证单元再推送一次。检查钩子保持开启。未完成的提交也可以。全自动落地和先审后合的栈都是这条。

多阶段计划 删掉了「设置目标」那一格。收到开始指令后，用 /loop 1h 设巡检。开 PR 改为按 开 PR 手册执行。

计划检查脚本 skills/poteto-mode/scripts/check-plan.mjs 现在要求计划里出现 /loop 1h。以前要求的是 /goal 和「30 分钟」。这个脚本没有单独的译文页，它核对的是计划骨架里的英文句子。

开 PR 时说明怎么写

开 PR 把 PR 说明收紧了。审阅者应在一分钟内看懂：为什么改、没包括什么、可能弄坏什么、怎么证明有效。句子要短，少用代码标识符。

每一节用二级标题，不要用加粗开头。新增一节「改了什么」（## What changed），写 1 到 3 条。「范围」（## Scope）要写明包括什么，以及刻意不包括什么。「为什么」是 1 到 3 句，「影响范围」是 1 到 2 句，「验证」是 1 到 3 条。

新增「内置 PR 工具」一节。这次运行如果提供了内置的 PR 工具，创建、编辑、改目标分支、标为就绪都用它，不用命令行。原文的理由是：用命令行开的 PR 会漏掉工具在跟踪的东西，例如后来的运行还能改的描述。

较小的改动

TypeScript 实践 里，正确示例改成先用 Zod 定义结构，再从结构推导类型。新增一段：给校验器标注它要证明的类型，编译器就会拒绝一个证明得比类型少的校验器。边界上的数据，用拥有这个结构的 schema 来解析。没有 schema 时才加一个。

技术写作 删掉了四行来源注明。删掉的是 diataxis.fr、Google 开发者文档风格指南、ASD-STE100，以及 Kohl 的《全球英语风格指南》。规则正文没有改。提交说明没有写为什么删。这里也不补一个原因。

原则总数从 23 条改成 24 条。插件说明和指南里的计数一起改了，见 用原则名来转向 和 插件说明。

poteto-mode 还有一句关于默认决定：替你做了只能由你做的选择之后，用白话说明可以让它改成怎么做。不要给一句需要原样输入的口令。

升级方式

这次提交把 .cursor-plugin/plugin.json 里的版本从 0.15.5 写成 0.15.6。改动的文件里没有另写升级命令。