Skills

在把任何一层建完整之前，先建一条穿过每一层并且能跑起来的窄路径——一次从未执行过的集成只是猜测。

在实现之后才写下的标准，描述的是那个实现。先写下会失败的检查，看着它失败，然后再开始构建。

保存成功却要重启才生效的设置，比保存失败还糟。说明它何时生效，并从读取它的地方推导出来。

按低于真实窗口的预算来花，并把你每一步都重新发送的工具 schema 算进去——它们是压缩触及不到的地板。

覆盖掉自己反馈变量的重试循环，只把第 2 次的失败展示给第 3 次——于是它又推导出第 1 次已经试过的那个补丁。

从已安装的版本里取签名，不要从记忆里取——一个看似合理的 API，在真正跑起来之前和真的没有区别。

任何从别处手抄过来的东西，只正确一次。能生成就生成，并在副本过期时让构建失败。

会崩溃的生成器告诉你它失败了；输出看似合理的生成器什么也没告诉你。测试它找到了什么，而不是它跑过了。

一个你从没见它失败过的回归测试只是猜测。提交之前，把代码重新弄坏，看着它变红。

诊断是对一台你没有跑过的机器下的论断。先用一条简短的命令复现这次失败——尤其是当诊断来自别人的时候。

原封不动地运行项目自己的验证命令——同样的范围，同样的参数。你临时改出来的那个几乎一样的变体，会在两个方向上都说谎。

在测试里手工组装出来的类，只能证明这个类能用，证明不了有任何东西能走到它——要覆盖生产环境真正走的那条路径。

当一项检查打在错误的目标上，修复会让它变弱。在同一个提交里把这个误报固定成测试，否则规则会悄悄被磨掉。

在报告任务完成之前，先跑那个「若未完成就会失败」的检查——解释不是修复。

不给出分母和构成的比率，每一位数字都是真的，却依然误导人——说出 n，并说清分子里有多少是本来就已知的噪声。

只根据系统的一部分做出的排名，读起来就像是对整个系统的排名——把范围和排除项写在结论旁边，而不是写在结论后面。

当你自己的两次测量相差到没有任何机制能产生的幅度时，缺陷在仪器上。在此之上建立理论之前，先审查那套框架（harness）。

数字和它的限定条件必须是同一个产物。两个段落会各走各的；一个组件做不到。

把失败的实验也发出来，把被取代的那次原样保留，绝不为了显著性重跑。偏差在于挑选，不在于那个数字。

在被守护的东西之后才加的检查，是有人为了发布而关掉的检查。趁还没有东西要拦，就把它接死。

列出要检查什么的门禁是失效即放行的——没人记得加进去的那个站点，正是会出问题的那个。改成列出豁免项，每一条都写明理由，默认就变成了失败。

空的界面、标签页或分类，是产品没有兑现的承诺。有内容之前先藏起来，或者干脆先别做。

放在所涉动作之后的提醒，到达时读者已经做了决定。把它放在前面；重要的时候，别让它能被关掉。