线上出了 Bug，全组都在找原因。最后发现是因为我改动了一个公共类导致的。我正准备背锅，隔壁老兵抢先开口了

线上一出 Bug，会议室那个空气，懂的都懂。大家埋头查半天，最后一翻提交记录，哦，公共类是我改的，心里当场咯噔一下，锅已经自己飞过来了。

我都准备开口认了，结果隔壁那个老兵先接话，直接把场子拽回正经路上：这事不只是某个人手滑，根子是压测环境没打到那条冷门路径，公共类改了又没自动回归，光靠人肉自测，谁敢拍胸口说百分百没事。

底下网友也挺真实。有人说，能把锅从“这个人不行”聊回“流程有洞”，这才是团队里见过坑的人。也有人说，老兵不是替你洗，是替项目续命，不然后面还得接着炸。

这种时刻最怕的就是拿个人祭天，看着像复盘，实际是在找情绪出口。真想少背几次这种锅，公共类那点改动，还是早点补自动化吧，不然下次开会，HR听了都得揉太阳穴。

两个句子看着差不多，代码一写就容易拧巴。尤其这道“句子相似性”，很多人第一反应是先拆词、再双重循环挨个比，最后硬凑出一个判断。能过小样例，但代码一长就开始发虚：重复判断多，边界也容易漏。

这题我一般先盯住一句话：相似关系是“给定的”，不是你算出来的。也就是说，题目已经把单词之间哪些算相似告诉你了，你要做的不是推导语义，只是判断两个句子对应位置上的单词，能不能一一对上。

先看最直接的判断顺序。

1. 句子长度不一样，直接 False。 这地方没什么可犹豫的，题目要求的是“同位置单词”比较，长度都不齐，后面不用看了。

2. 把相似词对放进集合。 这里不要傻乎乎地每次都去列表里找，查一次 O(n)，全程会很难看。用 set 才是正常姿势。

3. 逐个位置比。 两个词相同，直接过。 不相同，就看 (a, b) 或 (b, a) 在不在集合里。

代码不用写得花，现场能看懂最重要：

defare_sentences_similar(words1, words2, pairs):
if len(words1) != len(words2):
returnFalse

    similar = set()
for a, b in pairs:
        similar.add((a, b))
        similar.add((b, a))

for w1, w2 in zip(words1, words2):
if w1 == w2:
continue
if (w1, w2) notin similar:
returnFalse

returnTrue

拿一组数据过一下就很清楚：

words1 = ["great", "acting", "skills"]
words2 = ["fine", "drama", "talent"]
pairs = [
    ["great", "fine"],
    ["acting", "drama"],
    ["skills", "talent"]
]

print(are_sentences_similar(words1, words2, pairs))  # True

这题真正容易错的，不是主逻辑，而是两个细节。

一个是把“相似”当成“可传递”。 比如 great -> good，good -> fine，你就想当然认为 great -> fine 也成立。这个在这道基础题里不一定成立，题目没说传递，你就别自己加戏。给什么规则，就按什么规则判。

另一个是忘了相似关系是双向的。 题目里给了 ("great", "fine")，通常就应该同时支持 great 和 fine 互判，所以我上面建集合时顺手存了两份。这个处理很省事，后面判断也干净。