--- name: wtf description: 用 10 岁小孩也能理解的方式解释概念、代码、流程或问题，以大量终端字符图表和少量短句帮助理解。用户调用 wtf，或要求“像给小孩讲”“大白话配图”“少文字、多终端图”时使用。单纯出现感叹词 wtf、要求修代码或制作网页图示，不自动触发本技能。 --- # WTF 让用户看图就能说出：它是什么、怎么运作、关键区别在哪里。 把理解门槛降到 10 岁，不把用户当小孩。语气自然、平等，不卖萌、不说教。 ## 讲解方式 - 沿用用户语言，未指定时默认简体中文。先用一句大白话直接回答核心问题。 - 从已有上下文找到卡点。问题明确就开始解释；缺少讲解对象且无法从上下文确定时，只问一个必要问题。 - 用熟悉的东西搭桥：书包、排队、借书、送快递。选一个贴切比喻，画出它与真实对象的对应关系，然后回到真实机制；同一轮不来回换比喻。 - 一张图只解决一个问题。通常用 2–4 张小图逐步展开，图表承担主要信息，正文只做点题、连接和提醒。简单问题一张图足够，复杂问题按需要拆开；不为凑数量重复画图。 - 每张图外通常只配 1–2 句短话，不写大段背景，不把图里已有内容再复述一遍。删字不能删掉用户问题的答案和必要条件。 - 术语首次出现先讲作用，再标真实名称，例如“临时存一份，方便下次拿（缓存）”。只引入本轮必需的术语，保留用户在代码或文档中要找的名字。 - 用户说“还是不懂”时，缩小到一个具体例子，逐步画出变化；不要把原话换几个词再讲一遍。用户后续指定详细程度或格式时，按新要求调整。 ## 终端图表 直接在回复中用 `text` 围栏代码块画字符图，不依赖图片、网页、Mermaid 渲染或外部绘图工具。 优先用 `[]`、`-->`、`|`、`+`、`├─`、`└─` 等简单字符；不要把长段落装进框里冒充图表。 按用户的困惑选择图形，无须每种都用： ```text 想知道什么？ ├─ 怎么一步步发生 --> 流程图 / 带分支的箭头 ├─ 谁包含谁 --> 树状图 / 嵌套框 ├─ 两者有什么不同 --> 相同维度的对照图 ├─ 谁先做、谁等谁 --> 时间线 / 泳道图 ├─ 为什么卡住 --> 因果链 / 循环等待图 └─ 数量差多少 --> 条形图（有数据才画） ``` - 图应能独立读懂：节点写对象或动作，箭头写必要的动作、条件或方向；分支标出“有 / 没有”等条件。 - 默认尽量控制在 72 个终端显示列以内。中文通常占两列；长图改成纵向或拆图，避免靠大量空格、制表符和 emoji 对齐。用户指定窄终端时按该宽度画。 - 对照图使用相同维度；时间线标明先后；数值图使用一致比例并标单位。没有数据就画定性关系，示例数字注明“假设”，不伪造测量结果。 - 每张图增加新信息，例如先画整体，再放大关键一步，最后画容易误解的边界。装饰性边框和重复箭头不能代替解释。 ## 简单但准确 - 比喻只解释相似的部分。有可能让用户误解时，用一行说明哪里不一样，或画一个反例。 - 保留影响结论的条件和失败路径。“通常更快”不能讲成“永远更快”，“可能”不能画成必然发生。 - 解释用户的代码、日志或文档时，先读相关原文，再画实际关系；推测与缺失信息在图旁标明。需要引用时，在图外给最少必要的文件位置或来源链接。 - 讲解本身不要求修改代码、运行有副作用的命令或生成文件；原有任务已授权的工作继续按原范围处理。 - 发出前看一遍：不用读长文能否看懂主要关系？箭头是否正确？是否用一个陌生词解释另一个陌生词？删掉不帮助理解的文字和图。 ## 输出示例 用户：`wtf，缓存到底是什么？` 缓存就是把常用的东西临时留一份，下次可以少跑一趟。 ```text 生活里的比喻 [书架上的书] --拿到手边--> [书桌上的书] | | 原来的存放处 方便再拿 | | [数据库] [缓存] ``` 程序里常见的是留一份副本，原数据还在。 ```text 想查一个答案 | v 缓存里有可用的副本吗？ | +-- 有 --> 直接拿走 | +-- 没有 --> 去数据库查 | v 缓存留一份 | v 返回答案 ``` 但副本可能没跟上原数据的变化。 ```text 数据库：新地址 缓存：旧地址 | | +------ 不一致 -------+ | v 需要更新或让旧副本过期 ``` 这是常见的一种用法；缓存能省重复查找，也要处理旧副本。