melech-make-it-click

让它变得一目了然

用户发出这个请求，是因为你之前的解释虽然聪明、内容密集或技术上正确，但他们还是没听懂。

不要为之前的解释辩护、做总结或只把它缩短。找出阻碍用户理解的最小问题。先用最具体的方式解释这一点。不要试图简化之前的整段回答；要换掉那个行不通的思维模型。

找出问题所在

结合对话，尤其是用户最新的措辞，判断他们究竟卡在哪里。问题通常比整个主题小得多：

• “剩下的数据会被丢弃吗？”
• “程序运行时，这个值存在哪里？”
• “为什么还需要这个额外的标识符？”

先回答这个问题，即使之前的回答还讲了十件别的事。如果根据上下文能看出用户哪里没弄懂，就不要再让他们重复说明。如果有两个或更多同样可能的卡点，就问一个范围明确的问题来区分，而不是猜测。

换一种讲法

之前的讲法已经不起作用了。换一种方式：

• 用一个具体输入，演示它在系统中的处理过程；
• 举一个简短的值或代码示例；
• 用直白的话说明前后有什么变化；
• 只有在对应关系清晰时才用类比；
• 如果问题在于概念太复杂，而非措辞难懂，就删去不必要的概念。

多用具体的事物和动作，少用抽象类别。一次只引入一个概念。在必须使用术语时，立即解释它的含义。

回答结构

1. 开头直接回答用户可能卡住的问题。
2. 用最精简的具体模型说明为什么答案成立。
3. 用一句话把它与原主题联系起来。
4. 到此为止。只有在核心意思讲清楚后，才补充更深入的细节。

不必强行使用类比、编号步骤或“用最简单的话解释”的语气。根据用户的困惑选择合适的讲法。目标是让用户理解，而不是遵循某种固定格式。

严格要求

• 不要换成更简单的词，重复同一套解释。
• 如果问题不在于基础概念，就不要从头讲起。
• 不要只因术语精确就保留晦涩说法。
• 不要罗列所有注意事项、分支情况、实现细节或相关概念。
• 不要像对孩子说话，也不要宣称自己在“把内容讲简单”。
• 不要把补充解释变成另一篇长文。
• 先给出新的解释，不要问“这样说清楚了吗？”

如需查看三种不同讲解方式的实例，请参阅 references/examples.md。