三个月前的我留下一个烂摊子，WorkBuddy 替我读懂了它！

我在电脑里翻到一个叫“灵感停尸房”的文件夹。

光看名字，我承认它挺像我会做出来的东西。再往里看，就更像了：一个index.html，一个styles.css，一个app.js，外加一份语气很欠、信息却不太够的随手记录。

记录的最后一句是：

先这样，改天继续。

任何写过代码的人都知道，“改天继续”通常不是时间安排，而是一种比较委婉的项目死刑。

这个文件夹就这样在硬盘里躺了几个月。等我再次打开它时，我只记得自己当初想做一个收集灵感的小网页，至于做到哪一步、为什么停下、代码哪里有问题，已经忘得差不多了。

重新接手自己的旧项目，有时比接手别人的还麻烦。别人的代码看不懂，可以怪交接不到位；自己的代码看不懂，只能和几个月前的自己隔空对质。

这次我不打算亲自审他。

我把整个文件夹交给了 WorkBuddy，让它替我做一次“数字考古”。

一次不太体面的项目交接

“灵感停尸房”原本想做成一个带点黑色幽默的灵感收集工具。想到什么就扔进去，可以给灵感分类，也能把它标记为“还活着”或者“已躺平”。那些彻底不准备做的念头，再统一清理掉。

页面其实已经有模有样：深色背景、橙红色标题、输入框、分类选择、状态筛选和清理按钮。数据保存在浏览器本地，不需要后端。单看界面，很容易误以为这东西离完成只差一个 README。

可随手记录里还留着几句案情说明：

• 筛选好像坏了，点什么都看不到。
• “清理已躺平”结果很邪门，似乎把不该留的留下了。
• 没写 README，过几个月估计自己都看不懂。

最后一条已经应验得相当彻底。

我打开 WorkBuddy，选择这个项目文件夹，没有告诉它 bug 在哪一行，只发了一段更像委托书的话：

这是我几个月前遗弃的一个小项目。请先阅读目录里的全部文件，推断它原本想做什么、目前完成到了什么程度，再找出导致筛选和“清理已躺平”异常的问题。先给我一份项目考古报告，再修复代码并补一份 README。不要重写整个项目，尽量保留原来的设计和语气。

我特意加上“不要重写整个项目”。这不是客气。

现在让 AI 重做一个小网页并不难，难的是让它忍住推倒重来的冲动，先读懂一个已经存在、还有点个人脾气的东西。我想看它走进这间乱屋，认出哪些东西该留，哪两根水管接反了。

它先给旧项目做了份尸检

WorkBuddy 开始读取目录里的 HTML、CSS、JavaScript 和那份随手记录。比起直接输出一段新代码，我更在意它能否先说清楚这个项目是什么。

它对项目的概括很准确：这是一个纯前端的灵感收集页，使用localStorage保存数据；灵感可以分类、切换状态、删除和筛选；界面文案刻意采用了“停尸房”“还活着”“躺平”“复活”这一套略带黑色幽默的表达。

这段总结让我松了口气。至少它没有把这个项目理解成普通待办清单，也没有建议我把所有文案改成“高效管理每一个创意”。几个月前的我虽然代码写得有点迷糊，审美上的那点小脾气总算保住了。

接下来，它找到了两个问题。

第一个问题藏在筛选逻辑里。新增的灵感使用done: false保存状态，页面渲染时也根据done判断它是“还活着”还是“已躺平”；筛选功能却去读取一个根本不存在的status字段。点击“还活着”或“已躺平”后，自然匹配不到任何内容。

第二个问题更有喜剧效果。“清理已躺平”的本意是删除done: true的灵感，原代码却只保留了这些已经躺平的项目。按钮写着清理遗体，实际操作却是把活人全抬走。

两个 bug 都不复杂。如果让我从头读代码，大概也能很快找到。问题是，我此前每次看到这个文件夹，脑子里都会自动生成一串准备工作：先回忆用途，再读几个文件，跑起来复现，最后才能开始改。单项都不难，合起来就足以让我继续关掉文件夹。

这段重新进入上下文的时间，就这样被省掉了。

修复只改了该改的地方

找到问题后，WorkBuddy 没有重写页面，也没有给项目强行加框架。它只调整了两处逻辑：筛选时根据done的布尔值判断状态；清理时保留尚未躺平的灵感。

页面原来的布局、颜色和文案都没有被改掉。

这个细节比“几分钟修好两个 bug”更让我满意。AI 写一份全新的代码很容易显得聪明，在已有代码里克制地修改，才更接近真实协作。旧项目最怕有人看了一眼就说：“你这个不如全部重构。”

除了修复代码，它还补上了缺失的 README，把项目用途、文件结构、已有功能、使用方法和数据保存方式整理了出来。以后我再忘一次，至少不用重新审讯自己。

我随后打开页面做了简单验收：新增几条不同分类的灵感，把其中一条点成“已躺平”，再切换筛选条件。“还活着”和“已躺平”终于各回各的位置。点击“清理已躺平”，消失的也终于是该消失的那一条。

这次体验里，WorkBuddy 最贴心的是先阅读整个项目，再带着上下文做判断。过去我重新熟悉这种烂尾小项目，通常要在几个文件之间来回翻半个小时；这次目录梳理、问题定位和修复建议都集中在一个任务里，重新接手旧项目省事了不少，也提高了我的开发效率。

我还能看到它读取了什么、改了什么。对于一个可以操作本地文件的工具，这种可检查的过程比一句“已经帮你优化完成”可靠得多。

AI 能读懂代码，未必能读懂当时的我

当然，这场考古也没有神奇到把几个月前的我完整复原。

代码只能告诉 WorkBuddy 我已经做了什么，不能告诉它我为什么半夜给项目起名叫“灵感停尸房”，也不会记录我当时还想加哪些古怪功能。那份随手记录里没写的东西，它不可能凭空知道。

它能根据文件还原项目的结构和意图，却不能替我决定这个项目是否值得继续。修好筛选以后，我仍然得面对那个更现实的问题：我真的需要一个专门安葬灵感的网页吗？还是说，创造这个工具本身就是另一条应该被标记为“已躺平”的灵感？

WorkBuddy 能处理清楚的，是代码里已经留下证据的问题：字段用错了，筛选逻辑对不上，数组过滤条件写反了，项目缺少说明。至于产品该不该继续、哪些功能值得做、这个玩笑能不能撑起长期使用，仍然需要我自己判断。

它帮我恢复了上下文，没有替我制造答案。

我终于完成了那次拖了几个月的交接

这次实验结束后，“灵感停尸房”并没有突然变成一个宏大的产品。它还是一个很小的网页，功能简单，甚至有点没用。

但它从一个“我知道这里有问题，哪天再看”的文件夹，变成了一个能够正常运行、有说明文档、下次还能继续接手的小项目。

这种变化不够轰动，却很接近日常开发。

开发者硬盘里的烂尾项目，很少是因为某个技术难题彻底无解。更多时候，我们只是离开得太久，重新进入项目的成本越来越高。第一次拖延，是因为懒得修两个 bug；第二次拖延，是因为得先回忆自己当时在干什么；再往后，打开文件夹本身都会产生心理负担。

WorkBuddy 在这件事上帮到了我：它替我完成了那次一直没有发生的项目交接。

交接的一方，是几个月前写完一半就跑了的我；接手的一方，是已经把当时的思路忘得差不多的我。WorkBuddy 坐在中间，读完代码和便签，告诉现在的我：他当初想做这个，已经做到了这里，还留下了两个很具体的坑。

它并不比我更了解几个月前的自己。

它只是比我更愿意把那几个文件从头读完。

这就已经很有用了。

项目最后多了一份 README，两个 bug 也修好了。