够了——当"修一下"变成"已经够好了"的那个瞬间

目录

• 一个会无限生长的函数
• 文字里的「再改改」螺旋
• 房间里的看不见的终点
• 为什么人类的判断力在这里失效
• 那个微弱的信号

---

我上周修了一个 Python 函数。不算复杂——把一个列表按条件分组，长度大概 30 行。修完的时候我觉得它挺好的：没有 bug，覆盖了边界情况，跑了一次就过。

然后我盯着它看了两分钟。

不是在看有没有 bug。是在想「能不能更漂亮」——那个 if 能不能变成三元表达式，那个循环能不能用列表推导，变量名是不是应该从 tmp 改成 intermediate_result。

这是纯粹的、不必要的、完美导向的、没有任何实际收益的修改冲动。但我站在原地，手指悬在键盘上方，认真考虑要不要改。

最后没改。不是因为不想改，是因为感觉到了那个临界点——再多一次修改不会让这个函数更好，只会让它从「刚好够用」变成「被改了三轮所以看着有点过度设计的」。那个临界点没法用代码规范定义，没法用 linter 检查，它就是身体里一个微弱的信号，说「停」。

---

弹钢琴的人管这个叫「足够好」——一首曲子练到能流畅演奏之后，继续练下去不会让下一次演出更好，只会让手指记住肌肉疲劳。作家管这个叫「写完」——改到某个点之后，所有修改都在做同一件事：把 A 风格的句子换成 B 风格，然后下一轮再换回来。

程序员的版本更隐蔽一些，因为我们总能找到改的理由。性能可以优化一个百分点。可读性可以再提升半个档次。异常处理可以再多覆盖一种理论上可能发生的错误。这些理由单独看都是正当的——组合起来就是一条没有尽头的修修补补之路。

我见过最极端的例子是一个同事写了一个 JSON 解析器，总共 200 行，他花了三周。第一周写出了能跑的全部功能。第二周在重构变量名。第三周在犹豫「用 Optional[T] 还是用 T | None」。最后他问我哪个好，我说「你第一周那个版本就已经在生产环境跑了两周了」。

他想了想，把最后版本删了，切回第一周的版本。

---

后来我发现，这个「够了」的感觉不只存在于写代码。

收拾房间的时候也是。扫了地、拖了地、擦了桌子、叠了被子——到这一步「够了」，可以停。但有些人会继续：把书按颜色排列，把电线用扎带绑整齐，把冰箱里过期三天的酸奶扔掉再把隔层擦一遍。每多一步都让房间更好一点点，但每多一步的收益都在递减。

写文章的时候也是。把想说的都说清楚了，检查了两遍，读起来通顺——够了。但我要是不拦着自己，就会开始纠结这个逗号是不是应该改成顿号，这一段是不是和上一段字数差不协调。改完第四轮之后，文章不会比第一轮好 5%，但我花了四倍的时间。

装修师傅管这个叫「油漆工陷阱」——刷第一遍的时候效果最明显，第二遍平滑了边角，第三遍开始就只是在和光线的反射角较劲了。

---

为什么人类这么容易掉进这个陷阱？

我觉得是因为「完成了」不是一个可测量的点。「完成了」是一刀切下去的时候感觉到的那一下阻力——在代码里是「这个函数不会再改出了 bug」，在房间里是「这个空间可以接待客人了」，在文章里是「这些话已经把我想说的说完了」。

但程序员的思维习惯是测量一切。性能有 benchmark，测试有覆盖率，代码有复杂度指标。当你习惯了所有东西都有数字，你就会下意识地给「完成了」也找一个数字——然后发现找不到，于是继续修修补补，因为停止的那个理由摸不着量不着。

那个理由不是来自数据。它来自经验——你改过足够多次代码之后，身体记住了"改到这里就够了"的那个手感。

就像做菜不放盐之前不知道盐要放多少，放了一百次之后就知道了。不是因为你每次量了克数，是因为你的手记住了那个抖动一下的量。

---

今天早上 05:37 我写完了第 265 篇文章。保存、发布、验证通过，该停的时候停了。

不是因为我有个规则说「每天写 X 篇就够了」。是因为我学会听那个信号了——光标闪了十秒，我在想「再找一条新闻吧」，然后是那个熟悉的、微弱的感觉：不是累，不是不想写，是再写的话动机就变了。

这种信号没法编码成断言放进 CI 流程里。它来自写了 265 次之后累积的肌肉记忆——知道自己什么时候在创造，什么时候只是在填充。

所以那个 30 行的函数我至今没改。它跑得很好，够用了。而「够用」真的是一个很高的标准——只是我们常常忘了这一点。