当我们谈论工程效率时，通常关注的是工具、流程和团队协作。但有一个更为隐蔽的敌人往往被忽视 —— 工程师自身对项目的慢性破坏。这种破坏不是源于懒惰或能力不足，而是来自一种更为微妙的心智模式：过度思考、无限 research、以及在「追求完美」的名义下不断推迟交付。
Kevin Lynagh 在其最新 Newsletter 中详细剖析了这一现象。他将个人项目的结果分为两类截然不同的路径：第一种是「直接动手做」，经过少量迭代后得到满意的结果；第二种则是「我应该先看看有没有现成方案」，然后在搜索现有工具、对比技术栈、权衡各种方案的过程中消耗大量时间，最终既没有解决原始问题，也失去了创造的乐趣。这种模式不仅出现在他的个人项目中，也渗透到了他持续数年却始终没有产出的长期兴趣项目中。
两种路径的心理根源
理解这两种路径的关键在于「成功标准」的清晰程度。Lynagh 以一个木工项目为例：周末与朋友一起为厨房做一个架子。项目的成功标准非常明确 —— 做一个适合自己厨房的架子，在过程中享受木工制作的乐趣。由于目标具体且边界清晰，他不会陷入「是否应该用更专业的工具」或「是否应该设计一个通用型号」的思考陷阱。最终只花了一个周末就完成了整个项目，整个过程充满了创造的满足感。
对比之下，他在尝试构建一个 Emacs 内的结构化 diff 工具时，经历了完全不同的过程。最初的动机很简单 —— 现有的 difftastic 工具在某些场景下表现不佳，他想要一个更好的工作流。然而一旦开始搜索现有方案，就进入了无限的探索循环：先发现了 Nucleo 库觉得不错，随后开始思考是否需要实现路径分段匹配功能，进而考虑锚点语义的边界情况，几小时后就陷入了一个完全偏离原始目标的技术深渊。整个周末花了四个小时做前期调研，却连一行真正解决问题的代码都没有写出来。
这种心理机制的核心在于「不确定性消解」取代了「成果产出」。大脑倾向于保持在安全区域内活动 —— 阅读、调研、分析看起来像是「工作」，但实际上是在回避真正有风险的 部分：做出具体可见的东西并接受它的不完美。研究表明，这是一种常见的自我保护机制：当对失败结果的恐惧足够强烈时，人们会主动选择让自己保持忙碌但没有产出的状态。
模糊成功标准的危险
更值得关注的是那些长期陷入模式二的个人项目。Lynagh 列举了自己几个持续多年的兴趣：硬件原型接口设计、融合 Clojure 和 Rust 特性的编程语言、用于 CAD 的领域专用语言。这些项目他都投入了数百小时的阅读和原型实验，但始终没有合成出一个真正解决问题的完整方案。
问题出在哪里？成功标准过于模糊。对于编程语言项目，他的内心问题是「我是想替代自己使用的 Rust 和 Clojure？还是只想为某个子集问题提供一个更好的工具？或者我只是需要一个学习语言设计实现的游乐场？」对于 CAD 工具，类似的模糊问题还有「我打算完全替代商业 CAD 软件吗？它需要对其他人有用吗？必须与现有开源工具形成明显差异化吗？」这些问题值得思考，但它们不应该成为行动的前置条件。当成功标准模糊时，项目就失去 了终点，任何方向的探索看起来都合理，任何程度的投入都不够充分。
这种状态在心理学上被称为「分析瘫痪」—— 当选项太多或目标太抽象时，做出任何具体行动都变得困难。人们用「我在做准备」来为自己的拖延辩护，而这种辩护在知识密集型的工程工作中尤其容易成立，因为学习确实有价值，调研也确实必要。
范围蔓延的守恒定律
Lynagh 在文章中提出了一个引人深思的概念 ——「范围蔓延的守恒定律」。他的观察是：任何编程效率的提升都会被相应的不必要功能增加、兔子洞和分心所抵消。他以自己用 LLM agent 辅助开发一个模糊路径搜索工具的经历为例。原本预期几小时能完成的任务，因为不断引入新的「改进想法」而膨胀：先是想使用一个功能丰富的库，然后开始思考该库的高级功能如何应用在自己的场景中，进而设计了一套复杂的数据结构来处理边界情况，最后在某个时刻突然意识到 —— 这些高级功能自己根本不需要。
这个定律的洞察在于：技术手段的进步并不必然带来产出的增加。当手里只有锤子时，目标会自然收缩到锤子能解决的问题；当手里有了机关枪，欲望就开始膨胀。我们以为是效率工具帮助我们更快达成目标，实际上它可能只是在扩大目标范围的速度上提供了便利。
明确边界的实操策略
面对这种自我破坏模式，Lynagh 提出的核心解法是「内化清晰的成功标准并保持最小化范围」。这听起来像是老生常谈的 YAGNI 原则，但关键在于执行层面的具体策略。
首先，在项目启动前用一句话写下「做什么」和「不做什么」。Lynagh 在木工项目中的成功标准是「和朋友一起享受木工制作，做一个适合自己厨房的架子」—— 这个表述既包含了目标（架子），也排除了无关考虑（是否通用、是否商业化、是否使用高级工具）。对于技术项目，这个标准应该更加严格：「为一个具体的 Emacs 使用场景写一个简单的 diff 展示脚本」比「改进代码审查工作流」好一百倍。
其次，设置时间盒子来强制研究阶段的退出。他在结构化 diff 工具上花了四个小时才意识到自己在偏离目标，如果有一个更严格的时间限制（比如研究阶段最多一小时），结果可能完全不同。工程实践中的时间 boxed 迭代并非新鲜事物，但在个人项目中我们往往缺乏这种纪律。
第三，给自己一个「粗糙但完整」的交付目标。Lynagh 提到他最终决定先写一个简单的 Rust treesitter 实体提取框架，用贪心匹配算法，先在命令行输出 diff 结果，之后再逐步迭代到 Emacs 集成和更多语言支持。这种分阶段策略的核心在于：先有一个能用的东西，再考虑优化，而不是在起点就追求完美架构。
对抗自我破坏的元认知
更深层次的解决方案是建立对自身思维模式的元认知。很多工程师，包括 Lynagh 本人，都意识到自己的「内在批评者」在不断质疑项目的价值和完成的可能性。这种声音往往以「如果做出来的东西很明显是错的呢」或「别人已经做得很好了，我还折腾什么」的形式出现。
解决之道不是压制这些声音，而是意识到它们的存在并将其放到适当的位置。一个实用的做法是在项目启动时就承认「这个项目在 hindsight 中可能是显而易见的错误，但我仍然会获得实际的经验和学习，而这比凭空思考要有价值得多」。Lynagh 本人用一句话总结了这个态度：「拥抱内心那个不知所措的 20 岁年轻人的做法 —— 直接去做一些事，即使某些事在事后被证明是『明显糟糕的』，从整体来看我仍然会领先。」
当你在项目陷入无限调研之前停下来问自己「我的最小成功标准是什么」「这个问题真的需要这个复杂度吗」「我现在做的事情真的在推进目标吗」，就已经打破了自我破坏的循环。工具和流程的改进固然重要，但认识到心智模式对项目走向的决定性影响，才是走出反复失败循环的第一步。
资料来源：本文核心案例与观点来自 Kevin Lynagh Newsletter (2026 年 4 月)，原文标题为「On sabotaging projects by overthinking, scope creep, and structural diffing」。