skill-improver

技能改进

技能是在摩擦中改进的，而不是靠审阅。问题从来不是“这个技能能不能更好”——什么都能更好。问题是：到底出了什么问题，修改技能能否避免它？

大多数摩擦不应该促使技能改动。问题可能出在环境，也可能只是偶发情况，或者已有内容其实涵盖了问题，只是没有触发。根据噪声修改技能，会让一套精炼的技能变得臃肿，而臃肿正是这里真正需要避免的问题——每一行多余的内容，都会让必要内容变得不那么显眼。

从实际发生的事情入手

不要问“进展怎么样”，而要问：具体在哪些地方出现了困惑、重复、走错路后又折返、自行想出变通方法，或用户纠正？

每一种情况都值得考虑。决定一切的问题是：技能能否避免这种情况？该改哪个技能？

通常答案有以下几种：

• 已有技能，但没有触发。 问题出在描述，而不是正文。修正触发条件。
• 技能触发了，却被忽略或误用。 内容没有起作用——通常是因为埋得太深、语气模棱两可，或表述过于笼统，无法对应到具体情况。
• 技能本身没错，但存在反复出现的缺漏。 这是真正的缺口。
• 没有技能涵盖这种情况，而且以后还会发生。 可以考虑新增技能。
• 没有任何办法能解决。 问题出在环境、情况新颖，或确实只是偶发。这是最常见的答案，也完全可以接受。

这种情况发生过两次吗？

发生一次只是个例。根据单次事件编写的技能，会记录一种可能再也不会出现的情况，却会在之后每次加载时占用上下文。

发生两次就形成了值得记录的模式。发生一次则值得记住并留意。

例外情况：单次失败代价高昂，或可能造成不可逆后果。这类问题第一次出现就值得修改。

优先删减

失败后的本能反应是添加一条规则来涵盖问题。这样来几轮，就会写出冗长、含糊、失去锋芒的内容——而新增的规则往往是技能中最少被阅读的部分。

所以先问：把现有原则表述得更好，能否涵盖这种情况？ 通常可以。此时需要的是一句更精炼有力的话，而不是再添一句——技能因此会更短，也更强。

新增内容应该少而精，每一行都必须有存在的价值。想想要删掉什么才能腾出位置；如果没有内容可以删，就要质疑这条新增内容是否真的必要。

通常最有效的改进，是在现有技能末尾补充一种新的失败模式：只写一行，信息密度高，点明刚刚踩过的陷阱。

修正触发条件

没有触发的技能，不能靠改进正文来修复。因为根本没人读到它。

描述中要包含问题实际出现时的情境和措辞——也就是用户真正使用的说法，而不是抽象的主题。还要写明不适用的情况，因为到处触发的技能只会变成噪声，并被忽略；这和没有触发是一样的。

该说什么

简明具体地说明：发生了什么、涉及哪个技能、是否反复出现、要做哪一项改动，以及这项改动是删减还是新增。

如果没有值得修改的内容，就直说。以“无需改动”结尾的复盘是成功的复盘，远胜于为了证明自己有用而凭空找事。

失败模式

• 机械式复盘。 每项任务结束后都进行复盘，产生不断累积成臃肿内容的小改动。
• 凭空想象再改进。 为没有发生过的情况提议修改。
• 不停追加。 每次遇到摩擦都新增一条规则，从不重新删减。
• 触发条件有问题，却去改正文。 重写没人加载过的内容。
• 凭空捏造发现。 只是因为预期要列清单，就硬列出一份清单。
• 因单次事件新增技能。 为只出现过一次的情况，永久付出上下文成本。