summaryrefslogtreecommitdiff
path: root/content
diff options
context:
space:
mode:
authoreltrac <hi@eltr.ac>2026-06-05 17:06:19 +0800
committereltrac <hi@eltr.ac>2026-06-05 17:06:19 +0800
commit06dccefd675dc9bb64520840596989bdc5369d78 (patch)
tree45e4b5b39c5e263831f528a1cf2cbbb3cb84b510 /content
parent97f1f8e4c3a135a9e050386a04e6e3e6f0a02f88 (diff)
[draft] update draft
Diffstat (limited to 'content')
-rw-r--r--content/weekly/84.md14
1 files changed, 13 insertions, 1 deletions
diff --git a/content/weekly/84.md b/content/weekly/84.md
index 18a051be..d8c40b5c 100644
--- a/content/weekly/84.md
+++ b/content/weekly/84.md
@@ -21,11 +21,17 @@ Blah, blah.
## 连接
-###
+### 分析正确与否,问题依旧存在
> [!note] 📜
> [Bad Problems Don't Stop Being Bad Because Somebody's Wrong About Fault Analysis](https://www.lesswrong.com/posts/PCsmhN9z65HtC4t5v/bad-problems-don-t-stop-being-bad-because-somebody-s-wrong)
+作者观察到,当有人指出问题时,其他人可能会试图解释问题背后的原因,然后,人们就理所应当地觉得问题被合理化了。可是,无论原因是什么,问题依旧是问题。坏的问题不会因为一开始的那个人的分析错了就不坏了。比方说,有人读到一篇文章的标题和文章内容毫无关联,此时有人解释「你知道标题很多时候不是作者写的吗?是他们的编辑写的标题」,然而无论标题是谁写的,标题都和原文无关啊(而且作者表示,他向作者指出标题问题,往往都会得到回应,他们是能和编辑沟通的)。
+
+问题不会因为正确的分析就变得合理,不过人们好像理所当然地觉得,问题若是有了清晰的原因,搞出问题的人就没有责任,不该被责备,也不需要改变了。
+
+另一个例子是,当有人指出问题,负责的人解释了问题的缘由,而提出者却说:噢,那也不是借口啊。事实是,负责人从来没说过要用原因为自己开脱,更有利于解决问题的讨论方式是:我们了解问题发生的原因了,接下来要怎么改进和预防?
+
---
## 星群
@@ -42,3 +48,9 @@ Blah, blah.
## 切片
+- 本周星露谷高光时刻:
+
+ ![](https://img.eltr.ac/geedeapro/weekly/84/stardew-valley-star-fruit.png)
+
+ 不过矿洞是朋友探的,我只是去领了个果子。
+