关于 feynman
feynman 是一项由用户主动调用的技能,用于检验其能否解释刚作出的决定。它借助独立评议者找出理解缺口,再逐步收窄提问,直到理由得到说明或缺口被标记。
主要功能
- 01中立重述决定,不提供理由
- 02由独立评议者发现缺口
- 03每次提出一个未解问题
- 04对浅层回答逐步收窄提问
- 05标记缺口,不强行下结论
适用场景
- 01选择方案后检验理解
- 02发现决定背后的假设
- 03逐步厘清含糊的解释
- 04标记需要重新审视的决定
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ lilmgenius/ paperthin --skill feynman安装后在 Claude Code 中输入/feynman确认已加载。
详细介绍
对刚做出的决定进行追问,直到你能解释清楚,或明确指出你无法解释的部分。
目标
做出选择之后,是最容易假装自己理解了的时刻:你可以流畅地复述某个选项,却并未真正理解支持它的理由;等到这一认知缺口开始产生影响时,这个决定可能早已成为其他事情的支柱。费曼测试可以发现这一点——如果你无法用简单的话解释一件事,就说明你还不理解它。因此,不会有人直接告诉你理由;一个从未参与决策的新批评者会追问你实际上无法解释的部分,而浅显的回答只会引出更具体的问题,而不是让你过关。最终,你要么能在真正的压力下解释这个决定,要么坦诚标明自己还做不到。
工作流
- 触发:在做出决定后立即启动——通常是在列出选项、却没有为任何选项提出论据,并选定其中一个之后。
- 复述,不要辩护:中立地陈述这个决定。不要提供背后的理由,也不要让用户借用从未实际提出过的理由。
- 隔离批评者:只把决定——不包括任何理由——交给一个全新且没有上下文的子会话,该子会话从未见证决策过程。让它追问其中的缺口:持怀疑态度的局外人会问什么、哪些假设没有明说、这个选择要成立必须满足什么条件。
- 一次指出一个缺口:告诉用户最关键的未解决缺口,并请他们用自己的话解释。绝不要把多个缺口合并成一份清单。
- 评判解释:如果回答确实解决了这个缺口,就将其关闭并继续。如果回答只是在复述问题、回避问题,或依赖权威(“Agent 提议的”)而不是给出推理,就不要接受。
- 收窄,不要重复:如果回答浅显,不要再次提出同一个问题——应收窄到仍然含糊的具体部分并追问。每一轮都继续收窄;绝不要重新扩大成笼统的“你确定吗?”
- 停止条件:经过多轮追问后,要么每个缺口都得到了真正的解释,要么至少有一个没有。两种结果都有效。
- 对于未解释的缺口:不要强行得出结论,也不要让用户用表面说法掩盖问题。具体指出尚未解决的部分,并标记该决定需要重新审视——这并非判定它错了,而是说明它尚未得到充分论证。
规则
- 在用户尝试解释之前,绝不要提供理由。先交出推理依据,会造成这种技能旨在避免的框架注入问题。
- 追问必须来自一个隔离的子会话,绝不能由做出选择的同一会话自我评估——一个思维无法忘记它刚做出的决定,就像作者无法忘记自己写下的草稿一样。
- 收窄,不要重复。第二次提出完全相同的问题,只会让用户学会更大声地复述;提出更具体的问题,才能检验缺口是否真正弥合。
- 绝不要强行得出结论。坦诚承认无法解释的缺口是有用的结果——它说明这个决定需要重新审视,而不是说明这项技能失效。
- 仅在用户有意调用时使用:随时质疑每个决定的本能,会让用户陷入长期自我怀疑。这项技能只会在用户主动调用时启动。
验证
- 比较用户对某个缺口的首次回答与收窄问题后的回答——每一轮中用户实际能够解释的内容有何变化,才是真正的信号,而不是仅仅没有再出现反对意见。
- 每个已关闭的缺口,都必须对应一段确实解决了实际问题的解释,而不是一段复述。
- 任何仍未解决的缺口都必须具体指出——明确是哪项假设,而不是含糊地说“用户遇到了困难”——并作为该决定的一项标记保留下来,绝不能悄然丢弃。
- 这项技能从未提供过理由;每个用于弥合缺口的理由都必须来自用户。
评论
支持 Markdown