AI写代码,资深前端工程师到底怎么用?三个能用,三个别碰

// 你脑子里已经有完整的架构了,只是不想敲
// 比如一个标准的 Zustand store

interface UserStore {
  user: User | null;
  setUser: (user: User) => void;
  clearUser: () => void;
  isLoading: boolean;
}

// AI 帮你秒敲出来,包括 TypeScript 类型

你的大脑(架构师)
    ↓
  【设计图纸】← 你已经想清楚了
    ↓
   AI(施工队) ← 帮你快速搭建
    ↓
  【代码输出】← 你负责验收

// 产品说要把 onSuccess 改成 onComplete
// 涉及 23 个组件文件
// 手动改?要命!
// AI 重构?3分钟搞定

// Before
<Upload onSuccess={handleSuccess} />

// After  
<Upload onComplete={handleSuccess} />

// 老项目遗留了一堆 Class 组件
// 要全部迁移到 Function Component + Hooks
// 这种纯机械工作,AI 最拿手

class UserProfile extends React.Component {
  componentDidMount() {
    this.fetchUser();
  }
// ... 一堆生命周期
}

// AI 自动转换 ↓

function UserProfile() {
  useEffect(() => {
    fetchUser();
  }, []);
// 干净利落
}

// 一个 800 行的怪兽组件
// 要拆成 5 个小组件
// 不改变任何行为,纯拆分
// AI 能帮你拆,但你要盯着

// 生成基础的 Vitest 测试文件
describe('UserCard', () => {
  it('renders user name correctly', () => {
    // AI 能快速搭框架
    render(<UserCard name="张三" />);
    expect(screen.getByText('张三')).toBeInTheDocument();
  });
});

// Mock 明显的依赖
vi.mock('@/api/user', () => ({
  fetchUser: vi.fn(),
}));

// 覆盖基本的 happy path

AI写的测试用例
    ↓
  [绿色的勾勾✓] ← 看起来很美
    ↓
  实际上只测了表面 ← 真正会出bug的地方没测

// ❌ AI 的操作:把状态就近移动(看起来很方便)
function ProductList() {
const [filters, setFilters] = useState({}); // 移到这里了
const [cart, setCart] = useState([]); // 也移到这里了

// 看起来很简洁对吧?
// 但你失去了状态的全局共享能力
}

// ✅ 资深工程师的思考:
// 为什么 filters 要全局?因为多个页面要同步
// 为什么 cart 要全局?因为要持久化
// 为什么这个组件看起来有点别扭?因为它在做边界隔离

// 这个组件故意把逻辑拆得很散
function OrderManagement() {
const { orders } = useOrders(); // 从全局取
const { updateOrder } = useOrderMutations(); // 写操作分离

// AI 会建议:为什么不直接在组件里管理?
// 但资深工程师知道:
// 1. orders 要被多个页面共享
// 2. updateOrder 要被中间件拦截做权限校验
// 3. 状态分离是为了 SSR 友好
}

// ❌ AI的建议:全都memo起来!
const MemoizedHeader = React.memo(Header);
const MemoizedSidebar = React.memo(Sidebar);
const MemoizedContent = React.memo(Content);
const MemoizedFooter = React.memo(Footer);

// 每个函数都useCallback!
const handleClick = useCallback(() => {
  doSomething();
}, []);

const handleChange = useCallback(() => {
  doAnotherThing();
}, []);

// 看起来很"优化"对吧?
// 实际上:
// 1. 这些组件根本不会频繁渲染
// 2. memo 和 useCallback 本身也有开销
// 3. 你增加了维护成本

用户交互模式
    ↓
  实际渲染频率 ← Chrome DevTools 测出来的数据
    ↓
  状态更新路径 ← 找到真正的瓶颈
    ↓
  浏览器行为 ← 回流重绘的根源

// AI的优化:盲目虚拟化
<VirtualList items={list} /> // list只有20条数据...

// 资深工程师的优化:先测量
console.time('render');
// 发现瓶颈在图片加载,不是列表渲染
// 于是用懒加载+占位符,不用虚拟列表

// ❌ AI写的代码(看起来没问题)
function UserProfile({ userId }) {
const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);

// 问题:如果userId快速切换
// 旧请求的响应可能在新请求之后返回
// 导致显示的是旧用户数据
}

// ✅ 资深工程师的修复
function UserProfile({ userId }) {
const [user, setUser] = useState(null);

  useEffect(() => {
    let cancelled = false;
    
    fetchUser(userId).then(data => {
      if (!cancelled) setUser(data);
    });
    
    return() => { cancelled = true; };
  }, [userId]);
}

// ❌ AI写的闭包陷阱
function Counter() {
const [count, setCount] = useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      setCount(count + 1); // count永远是0!
    }, 1000);
    
    return() => clearInterval(timer);
  }, []); // AI经常漏掉依赖
}

// ✅ 正确的写法
function Counter() {
const [count, setCount] = useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      setCount(c => c + 1); // 函数式更新
    }, 1000);
    
    return() => clearInterval(timer);
  }, []);
}

用户点击按钮 (t=0)
    ↓
  请求A发出 (t=10ms)
    ↓
  用户再次点击 (t=50ms) ← AI不知道这会发生
    ↓
  请求B发出 (t=60ms)
    ↓
  请求A返回 (t=200ms) ← 顺序错了!
    ↓
  请求B返回 (t=180ms)

AI 提交代码
    ↓
  你开始Review
    ↓
  ├─ 扫一眼结构 ← 有没有明显的坏味道?
  ├─ 看关键逻辑 ← 边界条件处理了吗?
  ├─ 检查依赖 ← useEffect的deps对吗?
  └─ 跑一遍测试 ← 真的能work吗?
    ↓
  决定: Approve / Request Changes

初级工程师 + AI = 飞速生产bug
    vs
资深工程师 + AI = 腾出时间做架构

问题不清晰 + AI = 放大混乱
架构脆弱 + AI = 粉饰错误
不知权衡 + AI = 选最响亮的那个

    但是

思考清晰 + AI = 消除摩擦
架构稳固 + AI = 快速实现
权衡已知 + AI = 省时省力