项目总在本地烂尾？四招终结开发者“完美项目综合症”

你的 GitHub 是不是也藏着一座“乱葬岗”？

打开个人主页，满眼都是只提交过一次 Initial commit 的仓库。那些你曾发誓要“做大做强”的库，那些立志要解决“世界级难题”的微服务，还有那些永远停留在 localhost:3000 的炫酷后台——它们像数字化石，安安静静地躺在那里。

这就是“完美项目综合症”（Perfect Project Syndrome）。别慌，病友不止你一个。

阶段一：灵感上头。 一个新点子从天而降，你觉得它能改变世界。你立刻创建仓库，配置 Linter、ESLint、Prettier、Husky、commitlint，再搭一套 GitHub Actions 的 CI/CD。折腾三小时，业务逻辑一行没写。

阶段二：钻技术牛角尖。 “正好趁机学个新栈！”于是 Next.js、tRPC、Prisma、Turbo、Turborepo、pnpm Workspaces 全招呼上。明明只是个简单的增删改查，被你整成了六角架构加事件溯源。两周过去，连个 Demo 都没有。

阶段三：被人“降维打击”。 刷到 Twitter 上有人用 PHP 和 jQuery，一个周末上线，已经有了 200 个用户。再看自己“技术架构遥遥领先”的项目，还锁在本地出不来。你不是受鼓舞，而是彻底泄气：“连完美栈都跑不通，我还折腾个啥？”

阶段四：历史重演。 一拍大腿：换个新想法！新建仓库，重配 ESLint……旧项目？让它在角落里吃灰吧。循环重启。

这不是你缺乏自律，而是恐惧伪装成了完美主义。

每花一小时调配置、选框架，你就少一小时把作品暴露给世界。而世界有时是残酷的——你的代码、你的产品、你的文字，都可能被批评。但 ESLint 配置不会被骂，CI/CD 流水线不会被嘲，六角架构……好吧，那个也需要懂行的人才能骂（但通常也没人看）。

说白了，技术完美主义是一个装修得漂漂亮亮的舒适区。

第一招：“周五或死”原则（Friday or Die）

如果一个新的想法在一周内做不出能用的 MVP，就直接放弃。

注意，不是好看的 MVP，而是能跑通核心功能的 MVP。不要测试，不要 CI/CD，不要设计系统。就一个功能：解决那个核心问题。一周后，如果它值得做，你再投入工程化；如果不值得，体面地杀掉它，不用愧疚。

第二招：“懒人技术栈”（The Lazy Stack）

做第一版时，只准用你熟悉到骨子里的技术。

别想着“正好用这个项目学学 Rust”。要学技术，开个小号 side project 随便玩。但你要上线的项目，必须用三小时能搞定的栈，而不是三周还搞不定的。先上线，再优化。

第三招：公开构建，哪怕丢人

作者的第一篇文章写得也很烂，第二篇也是。但每一篇都比上一篇好。如果你非要等“完美”了再发，那永远发不出来。真实的反馈，永远比想象中的完美更有价值。

第四招：你的“坟场”不是耻辱柱

那些死掉的仓库不是失败，它们是实验。每一个都教了你一点东西：哪种架构太复杂，哪个想法听起来美妙但做不下去。偶尔回去翻翻，有些项目值得“复活”，有些则值得永远安息。

每次你忍不住要新建一个仓库时，先停下来问问自己：

“我做这个，是为了让它存在，还是为了让它完美？”

如果答案是后者，请立刻关掉编辑器，出去摸会儿草（touch grass）。

类似文章