过度思考如何毁掉项目：范围蔓延、结构差异比较，以及 PhD 困境

今天 HN 上另一个让我心里"对对对"的帖子，是《Sabotaging projects by overthinking, scope creep, and structural diffing》。这篇文章的核心，是描述一个每个开发者都经历过的过程：从"我要做一个简单的工具"开始，到"我在建一个操作系统"结束，最后什么都没完成。

文章描述的三个杀手太熟悉了。

第一个是过度思考。你开始想"这个工具要能处理什么场景"，然后"要能扩展"，然后"要能配置"，然后"要能插件化"。等你开始真正写代码时，你的"简单工具"已经变成了一个需要架构图、设计文档、插件规范、配置系统的项目。

第二个是范围蔓延。你写着写着发现"哦，这里如果能支持 X 就好了"，然后"那如果支持 Y 呢"，然后"既然都支持了 X 和 Y，不如做成通用的"。等你回过神来，你写的已经不是你最初想做的东西了。

第三个是结构差异比较。你开始比较"我应该用 React 还是 Svelte"，"我应该用 Rust 还是 Go"，"我应该用数据库还是文件系统"。每个选择都有利弊，每个选择都意味着放弃另一个选择的可能性。你花了两周时间做技术选型，然后发现你花的时间比写代码还多。

嗯，这三个杀手组合在一起，就是 HN 评论里说的"side projects 的定义"。一个评论写得特别妙：我的 2D 自上而下 sprite RPG 现在有了 3D 程序化动画引擎、程序化 3D 角色生成器、人口模拟器（如果完成的话会超越欧陆风云）、像素艺术编辑器、2D 程序化动画引擎……你可能会问一个 2D 游戏为什么需要 3D 程序化动画，嗯……范围就是这样以神秘的方式蔓延的。

这篇文章最让我注意的是评论里关于 PhD 的讨论。几个有 PhD 经验的人说，这篇文章描述的"过度思考→范围蔓延→结构差异比较"的循环，本质上就是 PhD 研究的核心困境。

一位评论者说：你要从你感兴趣的话题开始，然后阅读所有相关的研究，这会不可避免地导致范围蔓延，因为你意识到已经有多少人做了你想做的事。当你耗尽了最初的精力和热情，你要逼自己走完剩下的 20-30%，把东西做到可发表的状态。

另一位评论者说得更直接：博士论文证明了什么？不是证明你有多聪明——你读了几篇论文就已经证明了。而是证明你能把无聊的事做完。

嗯，这句话很尖锐，但也很有启发性。"把无聊的事做完"，这其实是一种比"聪明"更稀缺的能力。聪明人很多，能把一个复杂、模糊、没有明确目标的项目推进到完成的人，很少。

从工程角度看，这篇文章最有价值的建议，其实是"从做到想"。

一位评论者说：你应该只读两到三篇论文，然后就开始做。你只需要在项目的后期，当你有了一些结果、开始写的时候，再去深入做文献综述。这不是说"不做调研"，而是说"先做，再调研"。因为你做的时候，你才知道自己真正需要调研什么。

另一位评论者说：在"做"和"看"之间切换。先做一下试试，不用花太多时间。然后去看相关研究，你会理解更多。再回来做。但有几个关键点：论文不是证明什么是对的，它只是暗示什么"可能"是对的，在那篇论文的条件下，那些条件不是你的；不要把人家的结果当成绝对真理。

嗯，这段话的核心是：先做，再学，再做，再学。不要等到"学够了"才开始做，因为你永远学不够。

从更大的角度看，我觉得这篇文章真正提醒我们的，是另一件更根本的事：当"做"的成本低于"想"的成本时，过度思考就不再是"谨慎"，而是"拖延"。而"拖延"和"范围蔓延"，最终的结果都是一样的：什么都没完成。

所以今天真正值得记住的，不是"别过度思考"，而是另一句更关键的话：先做，再学。因为你永远学不够，但你可以在做的过程中学。