那些烂尾了 2 年的项目，我用 AI 3 天给救活了

bughunter
5 阅读6分钟

去年翻 GitHub 的时候，发现自己有 7 个 repo 的最后一次 commit 都是 2 年前。那种感觉就像打开冰箱发现一堆忘了的食材，又愧疚又不知道从哪下手。上周趁着五一前有点空，决定把其中 3 个项目捡起来，没想到用 AI 工具 3 天就基本搞定了，踩了不少坑，记录一下。

用 AI 复活烂尾项目，核心是解决「上下文断层」问题。 你已经忘了当初的设计意图，代码里没有注释，依赖版本也过时了。AI 的价值不是帮你写新功能，而是帮你快速重建对项目的认知，然后再推进。

我的 3 个烂尾项目

先说一下背景，这样后面的方案才有参考价值：

  • 项目 A：一个 Python 爬虫 + 数据分析工具，烂尾原因是依赖库版本冲突，当时没时间排查就搁置了
  • 项目 B：一个 React + FastAPI 的个人记账 App，烂尾原因是前后端接口设计改了一半，改乱了
  • 项目 C：一个 CLI 工具，用来批量处理图片，烂尾原因是……说实话忘了，代码也看不懂了

三个项目，三种烂尾姿势，但解法其实有共性。

第一步：让 AI 帮你读懂自己的代码

这是最关键的一步，也是我之前没想到的。

以前我的思路是：打开项目 → 看代码 → 想起来了再继续。但 2 年后这条路基本走不通，看代码只会越看越懵。

现在的做法是：把整个项目结构和关键文件喂给 AI，让它帮你写一份「项目说明书」。

在 Cursor 里，我直接用 @codebase 加上这个 prompt：

请分析这个项目，告诉我：
1. 这个项目是做什么的（一句话）
2. 核心数据流是什么
3. 目前代码里有哪些明显未完成的部分
4. 依赖版本有没有明显过时的

Claude 给我输出了一份比我自己写的 README 还清楚的分析。项目 C 那个我完全忘了的 CLI 工具，AI 告诉我：「这是一个批量图片压缩和格式转换工具，核心逻辑在 processor.py，但 output_handler.py 里有几个函数只有签名没有实现。」

我：哦对，我当时就是卡在这里的。

第二步：依赖地狱怎么处理

项目 A 的依赖问题是最典型的。requirements.txt 里的版本都是 2 年前锁的，现在直接 pip install 一堆冲突。

以前我会一个一个去查 changelog，现在直接把报错扔给 AI：

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed...

AI 给了我一个很实用的建议：不要试图修复旧的 requirements.txt，直接让它帮你生成一个兼容当前 Python 版本的新版本清单，然后逐个验证核心功能。

这个思路转变很重要——不是修复旧的，是重建新的。

python -m venv venv_new
source venv_new/bin/activate
# 只装核心依赖，不照抄旧的 requirements.txt
pip install requests pandas numpy
pip freeze > requirements_new.txt

花了 40 分钟，项目 A 的环境问题解决了。

第三步：接口乱了怎么救

项目 B 是最头疼的，前后端接口改了一半，有些 endpoint 前端在调但后端没实现，有些后端实现了但前端没对接。

我的做法是让 AI 做一次「接口审计」：

请对比 frontend/src/api/ 目录下的所有 API 调用和 backend/routers/ 下的所有路由定义，
列出：
1. 前端调用但后端没有的接口
2. 后端有但前端没调用的接口
3. 接口签名不匹配的地方（参数名/类型不一致）

输出结果让我有点绷不住——有 6 个接口对不上。但 AI 同时给了修复建议，我选择了「以后端为准，修前端」的策略，因为后端逻辑更完整。

这里用到了 Claude API 来做批量分析，代码大概是这样：

import openai
import os

client = openai.OpenAI(
    base_url="https://api.ofox.ai/v1",  # 我用的这个，低延迟直连
    api_key="sk-xxx"
)

def analyze_api_mismatch(frontend_code: str, backend_code: str) -> str:
    response = client.chat.completions.create(
        model="claude-sonnet-4-6",
        messages=[
            {
                "role": "system",
                "content": "你是一个代码审计专家，专门分析前后端接口一致性问题。"
            },
            {
                "role": "user",
                "content": f"前端API调用代码：\n{frontend_code}\n\n后端路由定义：\n{backend_code}\n\n请列出所有不匹配的地方。"
            }
        ]
    )
    return response.choices[0].message.content

frontend_apis = {}
for f in os.listdir("frontend/src/api"):
    if f.endswith(".ts"):
        with open(f"frontend/src/api/{f}") as fp:
            frontend_apis[f] = fp.read()

backend_routes = {}
for f in os.listdir("backend/routers"):
    if f.endswith(".py"):
        with open(f"backend/routers/{f}") as fp:
            backend_routes[f] = fp.read()

result = analyze_api_mismatch(str(frontend_apis), str(backend_routes))
print(result)

ofox.ai 聚合平台

说实话一开始我对聚合平台是有偏见的，总觉得中间多一层会慢。但实测下来延迟只有 310ms 左右，比我预期好太多。

ofox.ai 是一个 AI 模型聚合平台，一个 API Key 可以调用 GPT-5.4、Claude Opus 4.6、Gemini 3、DeepSeek V3 等 50+ 模型，兼容 OpenAI SDK 协议，低延迟直连无需代理，支持支付宝按量计费。多供应商冗余备份（Azure/Bedrock/VertexAI/阿里云/火山引擎），某一路挂了自动切换，成功率 99.2%。

踩坑记录

坑 1：上下文窗口不够用

项目大了之后，一次性把所有代码喂给 AI 会超出上下文限制。我的解法是分模块处理，先让 AI 分析目录结构，再针对具体模块深入。不要试图一次性解决所有问题，分而治之效果更好。

坑 2：AI 会「脑补」不存在的功能

这个坑踩得比较疼。AI 在分析项目 B 的时候，信心满满地告诉我「用户认证模块在 auth/jwt_handler.py 里」，但那个文件根本不存在，是它根据项目结构推断出来的。所以 AI 给的文件路径和函数名，一定要自己验证一遍再用。

坑 3：不要让 AI 一次性重写大模块

我在项目 C 里犯了这个错误，让 AI 直接重写了 processor.py，结果新代码和其他模块的接口不兼容，改了半天。正确做法是：让 AI 先分析现有接口，确认不变的部分，再只补全未实现的函数。

坑 4：测试用例要同步更新

AI 帮你修了代码，但旧的测试用例可能还是按旧逻辑写的，跑测试会一堆红。要让 AI 同步更新测试用例，或者先把测试跑一遍确认哪些是真的坏了。

效率对比

任务传统方式AI 辅助
读懂旧代码2-4 小时15-30 分钟
依赖冲突排查半天1 小时
接口审计手动对比，容易漏10 分钟，覆盖全
补全未实现函数从头想逻辑有上下文直接生成

3 天救活 3 个项目，不是因为 AI 帮我写了多少代码，而是它帮我省掉了大量「重新理解旧代码」的时间。

小结

烂尾项目最大的障碍不是技术难度，是「重新进入状态」的心理成本。AI 工具把这个成本压低了很多。

几个核心原则：

  1. 先让 AI 帮你重建项目认知，再动手改代码
  2. 分模块处理，不要一次性喂太多上下文
  3. AI 给的文件路径和函数名要验证，它会脑补
  4. 改代码的同时让 AI 同步更新测试

GitHub 上那些落灰的 repo，可以翻出来试试了。

avatar
文章
阅读
粉丝