project-graveyard

项目墓地

每位开发者都有一个塞满废弃项目的文件夹。没人做过尸检报告。此技能会扫描计算机，找出被弃置的代码仓库，根据 Git 历史推断每个项目为何夭折，发现用户个人的弃坑模式，并挑出最值得挖掘的一具遗骸——然后助其发布。

一切都在本地运行。不需要 API，不连接网络，也不会有任何数据离开计算机。

适用场景

• 用户询问被弃置、未完成或陈旧的个人项目，或想知道该完成什么
• 用户想复兴、重启某个项目，或“终于把它发布”
• 用户询问自己为什么总是无法完成项目
• 用户提出一个新项目——先检查项目墓地（参见 Necromancer 模式）。他们很可能已经做了一半。

不适用场景

• 清理磁盘空间或 node_modules——那该用 kondo/npkill，不是这个工具
• 在 GitHub 上归档代码仓库——此工具针对本地克隆和从未推送的项目
• 深入分析某个特定代码仓库的历史——直接查看 Git 日志即可

运行

python3 scripts/graveyard.py ~/dev ~/projects

将它指向项目实际所在的位置。如果不知道在哪里，就先询问——问一个问题，也好过未经允许就扫描别人的整个主目录。不带参数会扫描常见目录（/dev、/projects、/code、/Desktop 等）。 实用标志：

• --days 90 — 代码仓库多久没有活动才算死亡（默认 45 天）
• --json report.json — 导出完整的机器可读数据
• --me [email protected] — 认领使用其他邮箱提交的提交记录（可重复）；不加此参数时，通过工作身份或构建工具提交过代码的项目会被跳过，视为“不属于你”
• --include-foreign — 也纳入用户几乎没有提交过代码的代码仓库（默认跳过：克隆、分叉、工作检出都不算用户的遗骸）
• --state FILE — 记录扫描和复兴情况；启用复发监测

此脚本为只读。它绝不会在扫描的代码仓库内写入任何内容。

解读报告

脚本会给出四个部分：普查、死者（附死因）、模式，以及按“脉搏”（可复兴评分）排名的前三项。死因是基于证据的推测，而非定论——每项都会附上支持该判断的证据行。如果死因看起来不对，在复述前先核对证据。死因分类及各自对复兴的意义见 references/causes-of-death.md——撰写报告前先阅读。

尸检访谈

脚本只能读取 Git。你可以提问。对于主要死因是 unknown 或 slow_fade 的遗骸——也就是置信度较低的判断——每个项目向用户问一个问题，总共最多问两三个：

"recipe-scraper——历史记录只显示它逐渐沉寂。你还记得当时究竟是什么让你停下来的吗？"

将回答融入报告，并如实标注判断： **（法证判断）表示 Git 显示的内容，（已确认）**表示用户告知的内容。用户的陈述比法证推测更有分量——更新墓碑，而不只是修改报告文字。两个问题是对话，五个问题就是讯问。

撰写墓志铭报告

将脚本输出整理成一份能让用户真正有所感触的报告。格式如下：

1. 统计。 死亡项目数、累计存续天数、存续最久的项目。只写数字—— 数字本身就有分量。
2. 墓碑。 每个已死项目一块，按脉搏从弱到强排列。写明名称、存续天数、 提交次数、死因及其证据，以及一句墓志铭。 若死者超过约 10 个，只为最有看点的 6～8 个（脉搏最强、死因最有特点） 写完整墓碑，其余合并成一行埋葬——“……另有 11 个只活了一天的实验， 合葬一处。” 23 块墓碑堆成一墙，会毁掉这场葬礼。
3. 规律。 这是用户会记住的部分。“你的项目都活不过 19 天。” “六个项目中有四个死于更新的项目。” 引用脚本给出的数字；再补充 任何脚本看不到的发现。
4. 复活。 只选一个项目。不是三个。见下文。

将复活之选（且仅限它）刻成 ASCII 墓碑卡片——石碑要实至名归，不能到处乱立； 其余死者都只保留在表格的一行中：

        .------------------------.
       /                          \
      |        tab-sensei          |
      |      Apr — May 2026        |
      |   54 commits · 12 days     |
      |                            |
      |   died of deploy fear      |
      |                            |
      |   "It worked. It just      |
      |     never shipped."        |
   ___|____________________________|___
      ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

文字居中，卡片宽度不超过 44 列，以免换行；墓志铭放在最后。如果墓园空无一人， 就不要放卡片——别给不存在的人立碑。

墓志铭规则——整份报告的成败，全在这里：

• 每句墓志铭都必须能追溯到扫描证据。“它一生都在配置 webpack，最终也死于配置 webpack” 说得通，因为配置占比是 78%。对你没见过的代码编造笑话则不行，用户看得出来。
• 针对规律，不针对个人。“它确实能用，只是始终没能发布”可以。 “你就是不敢发布”不行。
• 干练胜过搞怪。只写一句。除非双关确有根据，否则不要用。
• 如果项目值得尊重，就给它应有的尊重。一个有 26 次提交、README 已完成却从未发布的仓库， 是一场小小的悲剧，不是笑料。

如果用户想分享报告，可以采用 --redact 的表述方式：将项目名称替换为 project-1..n，保留死因和规律。

复活计划

选一个尸体。脉搏最强的优先，除非它的想法在现实世界里也已经死了。 做决定之前，先读一下最有希望候选项目的 README，再浏览一下代码——然后进行 现实核查。这一部分只有你能做，因为脚本看不到当下：

• 搜索一下它的阻碍因素是否已变得不那么棘手：它当年费力对接的 API 现在可能已有官方 SDK，当年贵得用不起的模型现在可能便宜了 20 倍，当年 手搓的东西如今可能已经有现成的库。
• 搜索一下这个想法是否已在现实中落地。如果现在有三个获得资金支持的产品 正在做完全一样的事，就直说——这会让计划从“把它发布出去”变成“自己用”， 或者“让它安息”。

在计划中引用你的发现。“现在这件事容易多了：X 已经存在”是继续挖掘的最有力论据； “机会窗口已关闭”则是让它继续埋着的最有力理由。

然后写出复活计划。针对不同死因的挖掘策略见 references/causes-of-death.md（每种死因都有一个“复活方向”—— 对害怕发布而死的项目，只需要列出发布步骤；因阻碍而死的项目，需要给出托管替代方案； 因范围失控而死的项目，则挑出一个功能单独实现）。计划规则：

• 最多 7 个具体步骤，并以已发布为终点（一个 URL、一个版本发布、 一个已发布的软件包，而不是“继续做下去”）
• 步骤 0 始终是：确认它还能运行。依赖会过时；在承诺之前，先验证安装步骤和入口点
• 步骤 1 必须能在今天完成——第一次工作结束时必须有看得见的进展
• 先询问再动仓库。然后提议现在就开始步骤 1——这正是在 Agent 中运行此流程的全部意义

何时让它继续埋着——符合以下情况时，请直说：用户已经不在乎了（在访谈中耸耸肩就代表释怀，而不是一个项目）；机会窗口已关闭，现实世界已经推出了这个想法；或者所有候选项目都很弱。 “这里没有值得挖出来的东西，这也没关系——以下是这些模式对下一个项目的启示”，这是合理且有用的收尾方式。

当用户决定复活某个项目时，记录下来（询问一次状态文件要放在哪里——~/.project-graveyard.json 是个合理的默认位置）：

python3 scripts/graveyard.py --state ~/.project-graveyard.json \
    --mark-resurrected /path/to/the/corpse

复发监控

使用 --state 运行扫描时，会督促过去复活的项目履行承诺：报告会增加一个 RELAPSE WATCH 区块，显示每个复活项目是继续推进，还是再次沉寂。当项目复发时，直说，并让用户选择——重新承诺，或诚实地让它继续埋着。第二次沉寂而死就是答案，不是失败；应该妥善收尾，而不是开出第三次尝试的处方。没有工具会主动跟进自己开出的处方。这个工具会——保留状态的意义就在于此。

通灵师模式

当用户提出要构建新东西时，先检查墓地里是否有过往尝试，再搭建任何脚手架——在状态文件（或新的 --json 报告）中搜索名称和 README 内容是否重合。如果找到匹配项：

“你已经完成了大约 60% 的这个项目。它叫 project-14，三月时卡在身份验证步骤后停摆了，而且它的解析器仍然能用。要不要复活它？”

别说教。提一次就好，让他们选择，然后就此打住。

注意事项

• ~/Desktop 本身可能就是一个 git 仓库（意外执行了 git init、备份工具）。扫描器会处理嵌套仓库，但如果统计结果看起来离谱，通常就是这个原因。
• 所有权筛选依据 git 邮箱。 如果用户使用多个邮箱提交（工作邮箱、GitHub 网页编辑、构建工具），真正的遗留项目可能会被跳过，并标记为“不是你的”——统计报告会列出跳过了哪些项目；使用 --me [email protected] 将它们认领为你的。
• “已废弃”是一个阈值，并非事实。 一个稳定完成的工具，45 天没有活动看起来也像是已废弃。脚本会将 finished（有部署配置 + 已推送 + 有 README）与已废弃项目区分开，但启发式判断比较粗略——在为用户认为已完成的项目写悼词前，先询问用户。
• 一天内完成的遗留项目通常是灵感驱动的一阵热情，而不是失败——项目一口气构建完成后就再也没打开过。值得指出的是这类项目有多少个，而不是每一个“死掉了”。
• 默认不要让项目复活。 报告才是产品；复活项目只是一个提议。有些遗留项目就该继续沉寂——请参阅上文“何时让它继续沉寂”。

文件

• scripts/graveyard.py — 扫描器 + 尸检分析 + 活跃度排名（标准库、离线、只读）
• references/causes-of-death.md — 分类体系：信号、置信度以及每种死因对应的复活策略