Cursor 项目做到一半跑不动了，怎么救

这是 AI 编程最常见的断点，有个说法叫”75% 魔咒”：页面能点、demo 能演示、发给朋友看很惊艳，但一接真数据、一加第二个用户角色，整个就散架。

散架不是模型变笨了，是它一路都在满足”能看见效果”这个目标，没人为”能不能长大”负责。

先认清楚断在哪

对照下面五条，中三条以上就是结构问题，不是 bug：

1. 数据存在浏览器里。localStorage 存用户、存订单、存购物车。
2. 没有登录态。切换用户靠改一个写死的 currentUser 变量。
3. 每个页面各写各的 fetch。同一个接口在三个组件里被请求了三次，地址还不一样。
4. 没有错误处理。接口一挂，整页白屏。
5. 同一份状态存在多处。购物车数量在 localStorage、组件 state、和某个全局变量里各有一份，互不同步。

这五条的共同点是：每一处都能单独修，但修的时候会牵动别处。这就是”改 A 崩 B”的来源。

五步，按顺序来

顺序很重要。跳过第 1 步直接改代码，改到一半你会发现已经找不到”改之前能跑”的版本了。

第 1 步：冻结

git add -A
git commit -m "freeze: 能跑的状态，收尾起点"
git tag baseline-$(date +%Y%m%d)

打完 tag 之后，所有收尾工作在新分支上做：

git checkout -b finish

这个动作的意义：任何时候都能回到”至少能演示”的状态。AI 项目最怕的是改到第三天后发现还不如原来，而原来的版本已经找不回来了。

冻结之后给自己定一条规矩：不再让 AI 整文件重写。要改函数就只让它输出那个函数，要改组件就只输出 diff。

第 2 步：把现状画出来

不用画得很漂亮，一张表就够：

页面	读什么数据	写什么数据	现在存在哪
首页	商品列表	—	组件里写死的数组
详情页	单个商品	—	同上
购物车	购物车项	增删改	localStorage
我的	用户信息	登录	localStorage

画完你会立刻看到两件事：同一份数据在多处有副本，以及有些数据根本无处可存（比如”订单”这个词在代码里根本不存在）。

这张表后面就是建库的依据。

第 3 步：抽 API 层

在动任何页面之前，先把所有数据访问收口到一个地方。

// src/api/client.js —— 以后所有请求都从这里出
const BASE = import.meta.env.VITE_API_BASE || '/api';

async function request(path, options = {}) {
  const res = await fetch(BASE + path, {
    headers: { 'Content-Type': 'application/json', ...options.headers },
    ...options,
  });
  if (!res.ok) {
    const msg = await res.text().catch(() => '');
    throw new Error(`${res.status} ${path} ${msg.slice(0, 120)}`);
  }
  return res.status === 204 ? null : res.json();
}

export const api = {
  listProducts: () => request('/products'),
  getProduct: (id) => request(`/products/${id}`),
  getCart: () => request('/cart'),
  addToCart: (id, qty) => request('/cart', { method: 'POST', body: JSON.stringify({ id, qty }) }),
};

然后把组件里的 fetch('http://localhost:3000/...') 全部换成 api.listProducts()。

这一步就能让项目稳一半：接口地址不再散落各处，改域名只改一个文件，出错时有统一的错误信息。

第 4 步：补登录态和路由守卫

AI 项目最常见的”鉴权”是这样的：

const user = { id: 1, name: '测试用户', isAdmin: true };  // 写死在文件里

正确的最小实现：

1. 后端出一个 POST /auth/login，返回 token
2. 前端存 token（localStorage 存 token 是可以的，存用户数据和业务数据不行）
3. request() 统一带上 Authorization 头
4. 路由守卫：没有 token 就跳登录页
5. 后端每个接口都验 token——这一步最重要，前端守卫只是体验，后端校验才是安全

只做前端不做后端，等于没做。任何人用 Postman 直接打接口都能拿到全部数据。

第 5 步：一个一个功能迁，每迁一个提交一次

别想着”一次性重构完”。按页面走：

迁首页 → 提交 → 迁详情页 → 提交 → 迁购物车 → 提交 → 迁订单 → 提交

每迁完一个，用真实数据点一遍。发现新问题记下来，不要当场改——当场改就会回到”改 A 崩 B”。

三种情况，直接重写更划算

第 1 步之后如果发现下面任意两条，停下来算一下重写的成本：

• 没有路由，所有页面在一个 App.jsx 里靠 if 切换
• 没有数据模型，字段名在前后端之间对不上（前端 productName，后端 title）
• 有 3 套以上并存的样式方案（Tailwind + 内联 style + 一个 index.css）
• AI 已经把同一个文件重写了十几遍，里面有大量注释掉的旧代码

这些不是”结构缺失”，是”结构不存在”。补结构的耗时通常超过用同一套 UI 重写一个干净的项目——重写至少每一步你都清楚发生了什么。

收尾做完，会得到什么

• 一份能跑的数据库结构（而不是浏览器的 localStorage）
• 一个统一的 API 层
• 一套真的登录态
• 一个能回归的基线版本

这四样东西，才是”能上线”和”能演示”的分界线。后面加功能才不会每次都在拆地基。

卡住的话

把项目结构（tree -L 2 的输出）、package.json、以及你最后卡住的那个报错发过来。诊断免费，先判断该救还是该重写，再谈钱——很多时候答案是”这个不用花钱，你自己按上面五步走就行”。

---

相关：AI 项目接手救援 · 案例：Cursor 做的后台，密钥写在前端 · 完整报价单