打开 GitHub 个人主页时最让人不敢点开的是哪部分往往不是那个写着乱代码的仓库而是那一批“第一次提交之后再没动过”的项目。最近 Hacker News 上有一个很扎心的问题“Ask HN: What are your unfinished projects?”参与回复的人远比想象中多。这个话题之所以能引发共鸣是因为它替大多数开发者说出了不敢承认的现状我们缺少的不是项目创意而是如何对待那些已经做了一半、又很难彻底放下的项目。围绕“未完成项目”网上最常见的讨论会滑向自律、拖延症、时间管理。但我更想从工程角度来拆解这个问题。个人项目停摆通常不是因为懒而是因为启动阶段和收尾阶段需要的是两套完全不同的动力机制。本文会从现象、原因、判断方法、收尾手段和防堆积机制五个层面展开最后给出一套可以复制的操作流程。如果你手头也有三五个“不知道该不该继续”的仓库这篇文章应该能帮你做个了断。1. “未完成项目”的共鸣背后是开发者的真实焦虑这个 Ask HN 帖子之所以容易引起共鸣是因为它没有限定“哪些未完成项目”而是公开邀请开发者分享那些藏在硬盘角落里、不好意思展示的半成品。从这类帖子的回复氛围来看很多人并不是没有任何产出而是有大量“完成了 70%”的私人项目某个 CLI 工具写完了核心逻辑但没写 README某款爬虫能跑通一次但一旦遇到反爬就再也没改进过某套管理后台只剩权限模块没做然后就没有然后了。这种现象在独立开发者和后端工程师中尤其常见。原因在于公司项目的生命周期是靠外部机制推动的需求评审、迭代排期、Code Review、上线窗口、故障告警所有环节都在自动提醒你“这个项目还没结束”。个人项目没有这套机制唯一的外部反馈可能来自 GitHub star、少数几个用户的 issue或者自己某天突然想起来的“这个项目还有个 bug 没修”。从这个角度看未完成项目的堆积本质上不是时间管理问题而是一个缺少反馈闭环的工程问题。只要项目没有明确的完成标准也没有外部验收节点它就会一直处于“看起来还能做但永远不值得现在去做”的灰色状态。这种灰色状态会持续消耗你的注意力让你在新建一个项目时下意识地怀疑“反正最后也做不完还要开始吗”所以讨论未完成项目不是为了逼自己把每个仓库都做到盈利、上线、商业化。而是为了给这些项目一个明确的位置要么继续要么暂停要么正式归档。真正让人焦虑的不是项目没做完而是它一直悬在那里既不结束也没有进展。2. 停摆原因拆解不是意志力问题是反馈与范围问题如果把这类 HN 帖子的高频回复归纳一下会发现项目停摆的原因相当集中也很典型。大多数半途而废的项目并不是死在技术难点上而是死在这些环节。2.1 把项目当作学习载体目标达成后热情自然消退这是最常见的一种情形。当初开始项目是因为想学 Rust、想搞懂消息队列、想练一下新的前端框架。等你把核心概念跑通最想验证的问题已经有了答案项目的价值就结束了。但你会觉得“既然仓库都建了不写完多可惜”于是强行追加一些并不真正需要的功能。结果是学习目标已经完成项目目标却还没完成而你已经失去了持续投入的理由。在这个阶段真正应该做的是承认这是个“学习实验”而不是“产品项目”。学习目标达成时项目就已经毕业了。如果你还把项目当作一个必须上线的产品就会陷入自我怀疑。2.2 需求验证太晚做到一半发现已有更好选择个人开发者很容易跳过需求验证直接进入编码。不少人会在项目做到一半时发现GitHub 上已经有一个成熟方案功能更全文档更好社区更活跃。此时继续自己写下去除了“练手”之外没有实际价值但如果停掉又觉得已经投入的时间被浪费了。这类项目的问题不在于技术能力而在于顺序错了。一个工具类项目最应该先花两小时搜索现有方案、确认差异点而不是先花两周写一个原型再去对比。2.3 每换一个新框架就想把旧项目重写一遍很多开发者的仓库里都有一批“用 Vue 2 写过、又用 Vue 3 重写了一遍、再用 React 重写了一半”的管理后台。这种行为的驱动因素是技术兴奋感而不是用户价值。技术本身没有错但如果你是在个人项目里每接触一个新工具就想重构那项目就永远停留在搭建阶段。更合理的做法是把一个技术栈的组合明确记录在项目的 README 里在项目启动前就决定“这个项目不会为了追新而重构”。如果确实想尝试新框架那就新建一个最小 demo而不是把现有项目改得面目全非。2.4 被无关紧要的细节卡住还有一种非常隐蔽的停摆原因项目主体功能已经完成但卡在一个和核心价值无关的细节上。比如项目还没起名字、Logo 还没设计、部署域名还没备案、默认配色越调越难看。这些事情本身不复杂但会不断消耗耐心最终导致整个项目被搁置。面对这种情况最有效的方式是“冻结非核心事项”。项目能跑、能演示、能解决问题就已经达到可以归档或发布的标准。名字可以先叫tmp-project配色可以先用组件库默认主题域名可以以后再说。不要让这些事成为项目的终点。从以上几种原因可以看出项目停摆常常不是因为你不够坚持而是因为你在用一个不适合该项目的判断标准。学习项目用产品标准要求实验项目用发布标准要求自然容易放弃。3. 一个关键概念开始做和做完是两套动力机制如果说“未完成项目”背后有一套统一的心理学机制那就是创造性工作的启动动力和完成动力并不是同一种东西。写作者会把类似现象称为柯勒律治效应。诗人柯勒律治在创作《忽必烈汗》时因访客打断而中断写作醒来后发现脑海中完整的诗篇已经大部分消失最终只留下残篇。这个典故常被用来描述那种开头猛烈、却难以收尾的创作状态。写代码也一样你可能会因为一个新点子在某个深夜兴奋得睡不着立刻创建仓库、写好架构、跑通最小原型但等到写文档、补测试、处理边界情况时驱动你的已经不再是灵感而是另一种东西——纪律、反馈机制或者外部承诺。理解这个机制后有两件事会变得很清楚。第一不要在灵感最强的时候做“决策”因为那时候你更容易低估后续成本。深夜想到一个点子并提交了第一行代码这没问题但如果你在兴奋状态下又答应了“两周后上线”那么后来多半会后悔。第二要为“收尾”单独设计一套机制而不是等待动力自然出现。公司项目有排期、评审、上线日期来强制收尾个人项目完全可以参考同样的思路给项目设定一个弱化版的截止日期、一个可验证的完成标准以及一个“到期没做完就先归档”的默认规则。有了这套规则你就不必每次靠意志力做决定而是让流程替你处理。4. 先别急着自我批评未完成项目也有不同类型在讨论该不该继续之前可以先做一个分类。有些项目确实应该停掉而有些项目其实已经完成了只是你自己没有意识到。按照项目目的不同个人项目大致可以分成四类。项目类型初始目的真正的完成标志常见误区学习实验型学会一门技术、验证一种思路已经掌握了想学的要点结论已记录误以为必须做出完整产品才算完作品展示型证明工程能力、形成代表作代码整洁、文档清晰、可演示不断堆功能迟迟不发布工具解决型解决自己或小范围用户的实际问题自己已经在用且稳定运行总觉得还不够通用不敢公开产品创业型做成可持续维护的产品有明确用户、使用路径和迭代节奏把学习项目误当产品过度设计从表格里能看出很多“未完成”其实是定义混乱造成的。比如一个学习实验型项目你学会 Spring Cloud 的链路追踪后实验目的就已经完成。但大多数开发者的习惯是项目只要没推到生产环境、没写完整文档就一律归类为“未完成”然后把它挂在自己心里反复产生内疚感。更务实的做法是当项目状态发生变化时主动给它做一个重新定性。如果当初是为了学习而创建那现在就问“我学到东西了吗”如果学到了就把它标记为“实验完成”而不是继续用产品标准折磨自己。如果当初是为了解决自己的问题那现在问“我自己还在用吗”只要还在用哪怕代码结构不完美也已经是一个完整的工具型项目。当然这四类之间可以转换。一个学习型项目做久了可能真的沉淀出了值得公开的作品一个工具型项目也可能逐渐积累用户走向产品化。关键是你得知道当前处于哪个阶段然后按那个阶段的标准去判断“是否需要继续”。5. 判断要不要继续三层过滤法当你在多个半成品项目之间犹豫时最怕的不是选错而是每个项目都花半小时纠结最后哪个都没推进。更有效的方法是套用一套固定的过滤标准快速产出结论。5.1 第一层回到最初目的不要问“这个项目做完会不会很牛”而要问“当初我为什么开始它”。如果真实原因已经完成比如技术已验证、问题已解决、答案已找到那么项目就可以进入归档流程。继续做下去只是出于沉没成本心理而不是真实需要。5.2 第二层判断是否存在真实的使用场景或用户反馈继续投入时间的理由不应该来自“这个项目感觉还有潜力”而应该来自真实信号。信号包括你自己每周还在使用它有外部用户提了 issue或者已经有社区讨论引用它。如果项目从创建到现在除了你自己没有第二个使用者同时你自己也已经不再需要它那它当前的现实价值就很低。5.3 第三层估算剩余完成成本很多项目的最后 20% 恰恰是最耗时的部分部署上线、兼容性处理、边界情况、文档编写、安全加固。如果继续做完还需要投入大量精力而前三层判断又没有给出足够强的理由那么暂停或归档是更合理的选择。套用这三层过滤后项目基本会落入三个结果继续、暂停、归档。其中“暂停”和“归档”的区别在于暂停是“未来可能重新激活”归档是“当前不准备再投入但保留历史记录”。健康的个人项目管理需要同时容纳这三种状态而不是只有“做”和“不做”两个极端。为了让你更直观地做决定可以使用下面这个检查清单。检查项是否当初启动项目的目标是否已经完成可归档看第二行当前是否有真实使用场景/用户反馈值得继续看第三行剩余完成成本是否可以接受可设截止日期建议正式归档是否只是不甘心投入的时间建议归档可以继续如果所有答案都指向归档那么停止就是这个项目最好的结局。6. 低成本收尾让半成品项目变成清晰的历史记录很多开发者不愿意归档项目是因为默认归档需要写很长的文档、补很全的测试、整理所有 commit。这个预期太高了反而会让人一直拖着不处理。低成本收尾的核心原则是把归档动作压缩到 30 分钟以内。一个最小可行的收尾流程只需要三步。6.1 用一条命令盘点本地项目状态先看清楚自己到底有多少个项目、各自最后提交时间是什么时候。下面这段脚本可以遍历~/projects目录下的所有 Git 仓库输出项目名和最后一次提交日期。# 文件路径没有固定要求直接在 shell 中执行 for dir in $HOME/projects/*/; do if [ -d $dir/.git ]; then name$(basename $dir) last_commit$(git -C $dir log -1 --format%cs 2/dev/null || echo never) echo $name,$last_commit fi done | sort -t, -k2执行后你可能会看到类似这样的输出old-crawler,2021-11-03 spring-boot-study,2022-04-18 invoice-generator,2023-09-02这个视图能帮你快速判断哪些项目已经超过了合理的“冷却期”。建议把超过一年没有提交、且你现在无法说出它具体解决什么问题的那批项目列为优先归档对象。6.2 给仓库补一个“状态声明”README归档时不一定要补完整设计文档但至少要写一个状态声明让未来的你或访问仓库的人一眼看懂发生了什么。下面这个模板可以直接复制到项目根目录的 README.md 中。# project-name 项目状态实验完成 | 暂停 | 已归档 最后更新时间YYYY-MM-DD 归档原因一句话说明 ## 1. 这个项目解决什么问题 ## 2. 当前做到哪一步 - [x] 已完成事项 1 - [x] 已完成事项 2 - [ ] 未完成事项 1 ## 3. 过程中最有价值的结论 技术选型结论、踩坑记录、性能数据等一两句即可 ## 4. 运行方式如果代码还能跑不要小看这个简单的模板。它能让你在半年后再看到这个仓库时不用通过读代码来回忆当初发生了什么而是直接通过 README 得到上下文。对个人项目来说README 首先是写给未来的自己看的。6.3 用 Git Tag 标记归档状态如果担心以后误以为项目还处于活跃状态可以在 Git 中打一个带说明的 tag。这样既不删除代码又能清楚地标记项目生命周期节点。# 在本地仓库打归档 tag git -C ~/projects/old-crawler tag -a archive/2025-03 -m 归档目标站点结构已变原方案不再维护保留作为爬虫设计参考 # 如果仓库配置了远程并且你有推送权限再执行推送 git -C ~/projects/old-crawler push origin archive/2025-03注意推送操作需要确保你对远程仓库有合法权限。如果只是本地归档不打 tag、不 push 也不会影响后续查阅。这个动作的核心价值是给项目一个明确的语义边界它不是“做了一半还等着完成”而是“到这里正式结束”。心理上很容易从“未完成”切换到“已归档”从而释放注意力。7. 价值转换把废弃代码变成个人知识资产许多开发者的误区是觉得只有“能跑、能上线、能展示”的代码才值得保存。但从个人成长角度看半成品项目里最值钱的往往不是代码本身而是你在项目过程中踩过的坑、做过的技术选型和验证过的结论。这些内容如果不提炼出来会随着仓库一起腐烂如果提炼出来就能成为长期复用的知识资产。因此收尾的半成品项目不要只停留在“保留历史记录”还应该追问一个问题这个项目里有什么结论值得被沉淀下来可以是一个坑比如“不要把数据库唯一键逻辑放在业务代码里”可以是一个结论比如“在我们这个数据量级下不需要引入消息队列”可以是一个片段比如“这段正则能解析我们内部日志格式已验证可用”。把这类结论集中记到一个统一的文档或笔记系统里按主题而不是按项目组织。比如按数据库、性能优化、前端工程化、网络协议分类。这样当未来你再遇到类似问题时搜索“消息队列 什么时候不需要”就能找到当初实验的记录而不是只能想起“我以前好像做过类似的东西”。从个人知识库的角度看半成品项目其实起到了“实验记录”的作用。它们的价值在于验证而不一定在于交付。只要结论被提取出来项目本身是否上线已经不是重点。你可以把“项目是否做完”和“这次尝试是否产生经验”分开看待这样心理负担会小很多。8. 防止再次堆积设置一个轻量项目准入协议处理历史库存之后还需要防止未来继续堆积。这里并不是要你停止探索新领域而是希望你在启动一个新项目前先用很低的成本建立一个“项目卡片”。很多项目之所以开始得草率是因为新建仓库太容易了。git init加上 IDE 里几行模板一个项目就诞生了。但这意味着你跳过了对“为什么做”的思考。如果能在新建仓库之前花十分钟把下面这张卡片填好后续的停摆率会明显下降。- 项目名 - 开始时间 - 启动动机想学什么 / 想解决什么 - 完成标准满足什么条件就算这个项目可以结束 - 时间盒愿意投入多久 - 复查时间项目卡片的核心是“完成标准”这一项。很多项目从第一天起就没有定义“什么算做完了”于是它就像一个无底洞永远能追加功能。如果你在启动时写下“完成标准是某个接口能生成 PDF 报告并在本地正常打开”那么当这个目标达成后项目就有了一个可以收尾的节点。在此基础上再加三条防堆积规则就足够覆盖大多数场景。单线程规则同时只维护一个需要“对外发布或持续迭代”的项目。其他新想法只允许作为实验项目不承诺上线。实验隔离规则想尝试新技术就新建独立的 demo 仓库不要在正式个人项目里做技术选型冒险。定期盘点规则每季度跑一次第 6.1 节的脚本把所有超过 90 天没有提交的项目列为待归档候选做一次批量清理。这三条规则并不复杂但它们能把“项目是否继续”从一次次的意志力考验变成一个周期性的流程动作。流程一旦建立你就不需要每天反复纠结了。9. 常见问题与排查思路下面整理了一些处理未完成项目时最常见的问题并给出对应的排查思路。问题现象可能原因排查方式解决方案新想法一来就想马上建仓库过两周又没兴趣把灵感冲动当成了执行动力对比“项目卡片”中的动机和完成标准新想法先进入待办清单72 小时后再决定要不要启动项目已经没有使用场景但舍不得删沉没成本心理觉得删了就是白干问自己这个项目的结论是否已被吸收提取关键结论到个人笔记再执行归档 tag不必删除代码不知道该不该继续一个老项目缺少统一的判断标准使用第 5 节的三层过滤法按检查清单逐项回答宁可归档也不要挂起归档要写文档太麻烦导致一直拖把归档想象成写完整设计文档使用 6.2 节的状态声明模板只写状态、进展、结论三部分30 分钟内完成半成品代码结构差觉得放出来丢人用作品级标准衡量实验项目重新给项目定性看初始类型学习实验标注“实验完成”公开时说明是 demo 即可手头同时四五个活跃项目哪个都推进不了缺少单线程规则统计每个项目的最近提交时间只保留一个活跃项目其余先归档这些问题的共性在于它们本质上都不是“代码写不出来”而是“项目的状态不明确”。只要状态明确很多纠结自然就会消失。10. 给个人开发者的工程治理建议如果把个人开发者的代码仓库看作一个长期项目那么它同样需要轻量级的治理规则。不需要像公司那样严格但至少要有一套可持续的约定。建议先统一本地项目的目录结构。很多开发者多年后根本不知道某个仓库在哪、是不是已经迁移过。可以把所有个人实验项目统一放在~/projects下并按领域分子目录例如~/projects/backend/、~/projects/tools/、~/projects/frontend/。这样跑盘点脚本时也更容易归类。其次建议为每个仓库建立统一的“健康标准”。不要求所有仓库都有完整 CI但至少要满足四个条件有 README、有许可证说明、依赖锁定可以复现、代码能本地构建。许可证容易被个人开发者忽略但如果你公开了一个仓库别人就可能拿它作为基础代码复用没有许可证反而不利于知识共享。再就是不要用“完成数量”作为个人成就的唯一指标。一年能完整交付一到两个项目已经比同时开十个坑但全部烂尾更有价值。判断一个项目是否成功可以看它是否产生了经验沉淀、是否解决了一个真实问题、是否被你持续使用。如果三个维度里有一个成立那这个项目就不算白做。处理未完成项目还有一个额外收益它能训练你的决策能力。你需要反复判断“这个项目值不值得继续”这种判断力会延伸到工作场景里的技术方案评估和需求优先级排序。从这角度看清理半成品项目不只是整理仓库也是在整理自己的思考方式。下一次刷新 GitHub 个人主页之前不妨先给最旧的三个仓库补上状态声明。大概率你会发现心里的某个悬了很久的角落也跟着清爽了。