193577746 (kyriewen)

我让 AI 改一个 bug——它偷偷动了 5 个我没让它碰的地方

193577746 — Wed, 22 Jul 2026 19:19:04 +0800

让 AI 改一行代码，diff 里却多了几处你没提的改动——用 AI 编程的人都遇到过。我整理了 5 种最常见的"暗改"模式，每种附真实代码和防范方法。

从一个简单的 bug 说起

最近改一个状态更新的 bug，三行代码的事。让 AI 改完，习惯性看了一眼 diff——

改动不止三行。

翻了翻最近的 commit 记录，这种事不是第一次了。AI 改代码有个毛病：它不只改你让它改的地方，还会"顺手"动一些它觉得"应该优化"的代码。

有些改动无伤大雅，但有些能直接让项目炸掉。

下面是我总结的 5 种最常见的 AI 暗改模式，每种都在社区里反复出现过。

暗改一：删掉"没人用"的文件——其实是框架自动加载的

这是最危险的一种。

AI 在重构的时候，会扫描代码引用关系。如果一个文件没有被任何地方显式 import，它就认为是死代码，直接删掉。

问题是，前端框架有大量"约定式"文件，不需要手动 import。

# AI觉得这些文件"没人引用"，删了
src/
├── middleware.ts          ← Next.js自动加载，不需要import
├── app/error.tsx          ← Next.js错误边界，约定文件名
├── plugins/analytics.ts   ← Nuxt自动加载plugins目录
└── composables/useAuth.ts ← Nuxt自动导入composables目录

// middleware.ts — 没有任何文件import它，但Next.js自动执行
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const token = request.cookies.get('token');
  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

AI 看到没有任何引用，判定为死代码。删掉之后——所有页面的登录校验没了，未登录用户可以直接访问所有路由。上线之前跑测试大概率还能过，因为单测通常 mock 了 auth 逻辑。

同类情况还有：

Vite 的import.meta.glob自动注册的路由/组件
Vue 的全局插件注册（app.use(plugin)所在文件被删）
require.context动态加载的模块（Webpack 项目常见）
Tailwind CSS 的content配置引用的工具 class 文件

防范： 看到 AI 删文件，先想一下这个文件是不是框架约定的。middleware、error、layout、loading、plugins/目录、composables/目录——这些名字自带魔法，删了就炸。

暗改二：把同步改成异步——"优雅"地炸了启动流程

AI 特别喜欢把同步代码改成异步的。在它的训练数据里，"异步=好"几乎是共识。

// 改之前：同步读取配置（启动时必须阻塞等结果）
const config = fs.readFileSync('./config.json', 'utf-8');
const parsed = JSON.parse(config);
initDatabase(parsed.db);
initCache(parsed.cache);
startServer();

AI 觉得readFileSync不优雅，改成了：

// AI"优化"后：异步读取
const config = await fs.promises.readFile('./config.json', 'utf-8');
const parsed = JSON.parse(config);
initDatabase(parsed.db);
initCache(parsed.cache);
startServer();

看起来没问题？问题在于这段代码跑在一个没有顶层 await 支持的 CommonJS 模块里。或者更隐蔽的场景：initDatabase内部依赖同步的初始化时序，异步化之后其他模块在 config 还没读完时就开始初始化了。

这种 bug 极其难排查——启动流程偶尔成功偶尔失败，取决于异步操作的完成顺序。

同类情况：

localStorage.getItem 被改成异步的 IndexedDB 调用
构造函数里的同步初始化被改成 async（构造函数不支持 async）
同步的校验逻辑被改成异步，导致校验还没完成就放行了

防范： AI 把同步改异步时，问自己一个问题："这里用同步是不是有原因的？"启动流程、构造函数、校验逻辑——这三个地方的同步代码，通常都是故意的。

暗改三：重构时弄丢了一个 break

AI 在做代码搬移或重构的时候，偶尔会丢失控制流逻辑。最常见的是 switch 里的 break 和循环里的提前返回。

// 改之前
function processItems(items) {
  for (const item of items) {
    if (item.type === 'invalid') {
      logError(item);
      break; // 遇到无效项就停止处理
    }
    transform(item);
  }
}

让 AI 重构这段代码，比如拆成更小的函数：

// AI重构后
function processItems(items) {
  for (const item of items) {
    handleItem(item);
  }
}

function handleItem(item) {
  if (item.type === 'invalid') {
    logError(item);
    return; // 这个return只退出handleItem，不退出循环！
  }
  transform(item);
}

break变成了return，但语义完全不同。原来遇到无效项整个循环停止，现在只是跳过这一项，继续处理后面的。如果无效项后面的数据依赖前面的校验结果，后续处理全是脏数据。

同类情况：

continue在提取函数后变成return，语义改变
嵌套的break（带 label 的）被 AI 忽略，直接删掉 label
throw在 try-catch 重构后被 catch 吃掉，异常不再向上传播

防范： 重构后的第一件事——diff 里搜break、continue、return、throw。这四个关键词的任何变动都要逐个核对原始逻辑。

暗改四：给你两行代码套了三层抽象

你让 AI 写一个判断空字符串的工具函数，期望得到这个：

function isEmpty(str: string): boolean {
  return str.trim().length === 0;
}

AI 给你的：

interface StringValidator {
  validate(input: string): ValidationResult;
}

interface ValidationResult {
  isValid: boolean;
  reason?: string;
  metadata?: Record<string, unknown>;
}

class EmptyStringValidator implements StringValidator {
  private readonly trimBeforeCheck: boolean;

  constructor(options?: { trimBeforeCheck?: boolean }) {
    this.trimBeforeCheck = options?.trimBeforeCheck ?? true;
  }

  validate(input: string): ValidationResult {
    const processed = this.trimBeforeCheck ? input.trim() : input;
    return {
      isValid: processed.length > 0,
      reason: processed.length === 0 ? 'String is empty or whitespace' : undefined,
      metadata: { originalLength: input.length, processedLength: processed.length }
    };
  }
}

export const isEmpty = (str: string): boolean => {
  return !new EmptyStringValidator().validate(str).isValid;
};

两行逻辑变成了三十行。接口、类、配置项、元数据——全套。

这种暗改不会让项目崩溃，但它会让代码库快速膨胀。三个月后，团队里没人敢碰这些"AI 写的专业架构"，因为看起来太正式了，改了怕出问题。

同类情况：

一个简单的 fetch 请求被包成了带重试、超时、拦截器的 HTTP Client 类
一个环境变量读取被封装成了配置中心 + 热更新 + 类型校验
一个数组过滤被改成了策略模式 + 责任链

防范： 如果你让 AI 写的功能用一句话就能描述清楚，结果代码超过 20 行——大概率过度设计了。删掉，让它重写，prompt 里加一句"用最少的代码实现"。

暗改五：把你手动改好的代码"优化"回去

这是最让人崩溃的一种。

你在 AI 生成的代码里发现了一个问题，手动改好了。过了一会儿让 AI 继续改另一个地方，它把你的修复给"优化"没了——因为它的上下文里记住了自己之前生成的版本，认为那才是"正确的"。

// AI第一次生成的
useEffect(() => {
  fetchData();
}, []);

// 你手动加了依赖项
useEffect(() => {
  fetchData();
}, [userId]); // ← 你手动加的

// 让AI改另一个bug，它"顺手"改回来了
useEffect(() => {
  fetchData();
}, []); // ← AI改回空数组了，因为它觉得空数组"是对的"

AI 不理解你为什么改了它的代码。在它看来，空依赖数组是"标准写法"，你加的[userId]是多余的。

这种情况在长对话中尤其频繁。对话越长，AI 越倾向于用自己早期生成的版本覆盖你的手动修改。

防范：

手动改完 AI 的代码后，开一个新对话再继续后面的任务
或者在 prompt 里明确说"不要修改useEffect的依赖数组，那是我故意改的"
养成习惯：每次 AI 改完代码，完整看一遍 diff，不只看它改的地方，看所有改动

AI 暗改防范速查表

暗改类型	危险等级	排查方法	预防措施
删"死代码"	🔴致命	diff 里搜删除的 class/文件	有框架注解的 class 不是死代码
同步改异步	🔴致命	diff 里搜 async/await 新增	启动/构造/校验的同步是故意的
丢失 break/return	🟡高危	diff 里搜 break/continue/throw	重构后逐个核对控制流
过度抽象	🟢低危	一句话需求超 20 行代码	prompt 加"最少代码实现"
覆盖手动修改	🔴致命	看完整 diff，不只看改动点	改完手动代码开新对话

一条通用原则：AI 每次改完代码，看完整 diff，不只看你让它改的那行。

这不是 AI 的错

说到底，这些"暗改"不是 AI 故意搞破坏。它在做它认为正确的事——清理死代码、优化性能、统一风格。问题是它没有你项目的完整上下文，不知道哪些"不规范"的代码是故意写成那样的。

AI 是一个能力很强但完全不懂你项目历史的新同事。你不会让一个刚入职的人直接 push 到 main，对 AI 也一样。

你遇到过 AI 最离谱的"暗改"是什么？评论区聊聊。

我扒了最近的前端面经——面试不背八股文了，考这 5 样

193577746 — Tue, 21 Jul 2026 19:56:11 +0800

最近帮朋友看面经准备跳槽，翻了掘金和牛客上一堆帖子，发现现在的面经和两年前完全不是一个物种了。

以前："手写一个快排"、"说一下事件循环"。

现在："给你 30 分钟，用 AI 工具现场写一个 XX 功能"、"这段 AI 生成的代码有什么问题？"

从"你会不会写"变成了"你能不能判断 AI 写得对不对"。下面说说现在考什么。

1. 现场用 AI 工具解题

Meta 把前端编码面试改成了"AI-Enabled Coding"——60 分钟，面试环境里内置 AI 工具，你不但可以用，而且他们观察你怎么用。

Shopify 更激进：面试流程里有两轮专门的 AI 辅助编码环节，AI 使用不是"允许"，是"预期你会用"。

面试官真正在看的：

观察维度	加分	减分
Prompt 质量	需求拆解清晰、约束写全	一句话甩给 AI
迭代策略	拿到结果后追问优化	接受第一次输出
错误判断	快速发现问题并修正	等 AI 自己修
边界意识	主动考虑边界 case	只跑 happy path

备考建议： 每天用 AI 工具写至少一个小功能。重点不是写什么，是练"怎么给 AI 提需求"的手感。

2. AI 代码审查能力

这是增长最快的题型。面试官给你一段 AI 生成的代码，让你找问题：

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    setLoading(true);
    fetch(`/api/search?q=${query}`)
      .then(res => res.json())
      .then(data => {
        setResults(data);
        setLoading(false);
      });
  }, [query]);

  return loading ? <Spinner /> : results.map(r => (
    <div key={r.id}>{r.title}</div>
  ));
}

你能找出几个问题？

这段代码跑起来完全没问题。但至少有 5 个 bug：

竞态条件：query 快速变化时，旧请求覆盖新结果
没有错误处理：fetch 失败了 loading 永远转圈
XSS 风险：query 直接拼接 URL，没有 encodeURIComponent
内存泄漏：组件卸载后 setState 仍然执行
无防抖：每次 query 变化都发请求

AI 写的代码看起来总是对的——语法正确、逻辑通顺。但带着这些 bug 上生产，用户一多就炸。面试官想知道的是：你把 AI 当"打字机"还是当"初级实习生"？

3. 需求拆解能力

面试官给你一个模糊需求，让你拆成可以交给 AI 执行的子任务。

比如"首页加载太慢，优化一下"——以前背方案就行，现在要你现场拆：

第一步：让AI跑Lighthouse，拿到LCP/FCP/CLS数据
第二步：让AI分析bundle size，找最大的3个chunk
第三步：让AI把首屏以下组件改成lazy import
第四步：再跑一次Lighthouse，对比数据

同一个问题，拆得好的人用 AI 能在 30 分钟内搞定，拆得差的人对话 2 小时出不来结果。

核心差距不在 AI 工具，在人脑里的"任务分解树"。

4. 系统设计中的 AI 决策

以前的系统设计题："设计一个在线文档协作系统。"

现在加了一层："哪些模块用 AI 生成，哪些必须手写？为什么？"

适合交给 AI 的	必须人工把控的
CRUD 接口、数据校验	协同冲突解决算法
UI 组件搭建	权限系统设计
单元测试生成	数据一致性逻辑
常规性能优化	安全防护策略

面试官想看到的是判断力——你知道 AI 什么时候靠谱、什么时候不靠谱。

一个加分的回答："协同编辑的冲突解决我不会交给 AI，因为这类算法依赖严格的数学证明，AI 生成的实现很可能在边界 case 上出错。但数据校验和 CRUD 我会让 AI 生成，因为这些模式成熟、验证简单。"

5. 工程判断力：知道 AI 的边界

最难准备的一项。面试官会问："你用 AI 写代码遇到过最坑的一次是什么？"

面试官听几句就能判断你是真用过还是只玩过 demo：

真用过的人说的话	只玩过 demo 的人说的话
"AI 写的 CSS 在 Safari 经常出兼容问题"	"AI 写代码特别快"
"长对话后 AI 会忘记前面的约束"	"AI 什么都能写"
"让 AI 改 bug 有时候越改越多"	"AI 代替了很多手工活"

真实的、具体的、带坑的经验——这是最有价值的东西，也是没法临时准备的。

速查表：前端面试准备清单

准备方向	具体做什么	优先级
AI 工具熟练度	每天用 AI 写一个小功能，练 Prompt 手感	最高
AI 代码审查	让 AI 生成代码后不看直接跑，记录出了什么问题	最高
需求拆解	拿到需求先拆成 5 个子任务再动手	高
系统设计	画架构图时标注"AI 生成"和"手写"模块	高
踩坑经验	积累 AI 写代码的真实踩坑 case	高
基础原理	八股文不用背，但原理得懂	中

现在的前端面试，不是在考"你会不会写代码"，是在考"你会不会用 AI 写代码"。

这两件事的差距，比大部分人想象的要大得多。

你面试时被问过 AI 相关的问题吗？最难的是哪道？留言聊聊。

觉得有用？点个「赞」👍 让更多人看到

关注我，获取更多技术干货。

别再写 useMemo 了——2026 年这 5 个 React 性能优化已经是反模式

193577746 — Mon, 20 Jul 2026 14:59:12 +0800

打开任何一个 AI 辅助开发的 React 项目，你大概率会看到同样的画面：useMemo、useCallback、React.memo 铺天盖地，仿佛不写就会崩。

但 2026 年了，React Compiler 已经正式落地。你手动写的那些"优化"，很多不但没用，还在拖慢你的代码。

先说结论：为什么要改

React Compiler（随 React 19 正式推出）做了一件事：在编译阶段自动分析组件，在表达式级别做细粒度 memoization。

这意味着：你手写的 useMemo、useCallback、React.memo——编译器都能自动做，而且做得更细、更准确。

手动写的问题在于：

维度	手动优化	React Compiler
粒度	组件/Hook 级别	表达式级别（更细）
准确性	依赖数组经常写错	编译器分析，不会遗漏
代码量	多 30-50% 包装代码	零额外代码
维护成本	依赖变了要手动更新	自动追踪
出错概率	依赖数组写错=缓存永远不更新	不存在这个问题

ESLint React v5.3 已经加了 no-unnecessary-use-memo 和 no-unnecessary-use-callback 规则——官方工具链都在告诉你别写了。

下面逐个看 5 个已经变成反模式的"优化"。

反模式 1：useMemo 包裹所有计算

最常见的 AI 生成代码模式：

function UserList({ users, filter }) {
  const filteredUsers = useMemo(() => {
    return users.filter(u => u.name.includes(filter));
  }, [users, filter]);

  const sortedUsers = useMemo(() => {
    return [...filteredUsers].sort((a, b) => a.name.localeCompare(b.name));
  }, [filteredUsers]);

  const stats = useMemo(() => ({
    total: sortedUsers.length,
    active: sortedUsers.filter(u => u.active).length,
  }), [sortedUsers]);

  return <div>{/* ... */}</div>;
}

三个 useMemo 做了一件事：过滤 + 排序 + 统计。

React Compiler 会自动分析这段代码的依赖关系，在users或filter没变的时候跳过所有计算。你手写三个 useMemo，其实在做编译器已经做了的事，同时还增加了：

三个依赖数组的维护成本
三个闭包的内存开销
让代码可读性下降一半

2026 年的写法：

function UserList({ users, filter }) {
  const sorted = users
    .filter(u => u.name.includes(filter))
    .sort((a, b) => a.name.localeCompare(b.name));

  const stats = {
    total: sorted.length,
    active: sorted.filter(u => u.active).length,
  };

  return <div>{/* ... */}</div>;
}

干净、直接、编译器自动优化。

唯一例外： 如果你的计算确实很重（比如对 10 万条数据做复杂聚合），并且你能用React DevTools Profiler证明它是瓶颈——那保留 useMemo。但 99% 的场景不是这样。

反模式 2：useCallback 包裹所有传给子组件的函数

function Dashboard() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    setCount(c => c + 1);
  }, []);

  const handleReset = useCallback(() => {
    setCount(0);
  }, []);

  const handleExport = useCallback(() => {
    exportData(count);
  }, [count]);

  return (
    <>
      <Button onClick={handleClick} />
      <Button onClick={handleReset} />
      <ExportButton onClick={handleExport} />
    </>
  );
}

这段代码有三个问题：

useCallback 本身不阻止子组件重渲染——除非子组件用了React.memo
没有 React.memo 的情况下，useCallback 做的事就是"稳定引用"——但 React Compiler 已经能自动判断哪些组件需要跳过
handleExport的依赖数组里有count，每次 count 变化它都会重建——useCallback 完全没起作用

更直接的问题是：AI 工具特别爱生成 useCallback。 因为训练数据里大量"React 性能优化最佳实践"文章都在教"传给子组件的函数一定要 useCallback"。这个建议在 2023 年可能有道理，在 2026 年就是噪音。

2026 年的写法：

function Dashboard() {
  const [count, setCount] = useState(0);

  return (
    <>
      <Button onClick={() => setCount(c => c + 1)} />
      <Button onClick={() => setCount(0)} />
      <ExportButton onClick={() => exportData(count)} />
    </>
  );
}

反模式 3：React.memo 包裹每个导出组件

const UserCard = React.memo(function UserCard({ user, onSelect }) {
  return (
    <div onClick={() => onSelect(user.id)}>
      <Avatar src={user.avatar} />
      <span>{user.name}</span>
    </div>
  );
});

React.memo 的逻辑是：props 没变就跳过渲染。问题是：

React Compiler 已经在做同样的事，而且粒度更细——它可以跳过组件内部的部分表达式，不需要跳过整个组件
React.memo*每次渲染都要做 props 浅比较*——如果 props 经常变，这个比较本身就是白白浪费
和 useCallback 配套才有意义——但如果你已经不写 useCallback 了，React.memo 也没必要了

一条很好判断的规则： 如果你的组件渲染成本低于 props 浅比较成本（大部分简单组件都是这样），React.memo 就是负优化。

2026 年的写法： 直接导出，不包裹。

function UserCard({ user, onSelect }) {
  return (
    <div onClick={() => onSelect(user.id)}>
      <Avatar src={user.avatar} />
      <span>{user.name}</span>
    </div>
  );
}

反模式 4：useEffect + useState 做数据获取

这可能是最根深蒂固的反模式，也是 AI 生成代码最爱写的模式：

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let cancelled = false;
    setLoading(true);

    fetchUser(userId)
      .then(data => {
        if (!cancelled) {
          setUser(data);
          setLoading(false);
        }
      })
      .catch(err => {
        if (!cancelled) {
          setError(err);
          setLoading(false);
        }
      });

    return () => { cancelled = true; };
  }, [userId]);

  if (loading) return <Spinner />;
  if (error) return <ErrorMessage error={error} />;
  return <div>{user.name}</div>;
}

25 行代码做一件事：获取数据。 而且还有这些隐患：

问题	后果
竞态条件	userId 快速变化时，旧请求覆盖新数据
瀑布请求	父组件获取完→子组件才开始获取→孙组件再等
无缓存	同一个 userId 每次挂载都重新请求
首次渲染闪白屏	loading 状态永远要经历 true→false
服务端渲染不友好	useEffect 在 SSR 阶段不执行

2026 年的写法（用 TanStack Query）：

function UserProfile({ userId }) {
  const { data: user, isPending, error } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetchUser(userId),
  });

  if (isPending) return <Spinner />;
  if (error) return <ErrorMessage error={error} />;
  return <div>{user.name}</div>;
}

或者用 React 19 的use：

function UserProfile({ userPromise }) {
  const user = use(userPromise);
  return <div>{user.name}</div>;
}

从 25 行到 3 行。 自动处理竞态、缓存、去重、后台刷新。

这不是风格偏好，是架构级的差距。 useEffect 做数据获取在 React 官方文档里已经被标注为不推荐。

反模式 5：过度拆分组件"优化性能"

我见过的一个极端案例：一个表单页面被拆成了 47 个组件——每个输入框一个组件、每个标签一个组件、每个校验提示一个组件。理由是"避免整个表单重渲染"。

这是对 React 渲染机制的误解。

组件拆分不等于性能优化。每多一个组件，React 就多了：

一次 reconciliation 比较
一个 Fiber 节点
一次 props 序列化和比较

合理的拆分标准应该是：

场景	该拆	不该拆
组件超过 200 行	✅ 可维护性	-
需要独立复用	✅ 复用性	-
有独立的状态逻辑	✅ 关注点分离	-
"这一块可能会频繁更新"	❌ 过早优化	✅ 让 Compiler 处理
"拆小一点性能好"	❌ 错误假设	✅ 用 Profiler 验证

真正该做的性能优化是状态下沉（state co-location）： 把 state 放到真正需要它的组件里，而不是提升到父组件然后靠拆分来避免重渲染。

// ❌ 状态提升 + 过度拆分
function Form() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  return (
    <>
      <NameInput value={name} onChange={setName} />
      <EmailInput value={email} onChange={setEmail} />
    </>
  );
}

// ✅ 状态下沉，各管各的
function Form() {
  return (
    <>
      <NameInput />
      <EmailInput />
    </>
  );
}

function NameInput() {
  const [name, setName] = useState('');
  return <input value={name} onChange={e => setName(e.target.value)} />;
}

速查表：2026 年 React 性能优化决策

以前的"最佳实践"	2026 年的做法	什么时候还需要旧写法
useMemo 包裹计算	直接写，Compiler 处理	10 万 + 数据量的复杂聚合，且 Profiler 证实是瓶颈
useCallback 包裹函数	直接内联	传给第三方库且该库依赖引用稳定性
React.memo 包裹组件	直接导出	极重的渲染组件（Canvas/3D），且 Profiler 证实
useEffect 获取数据	TanStack Query / use() / SWR	永远不需要（没有例外）
过度拆分组件	按逻辑拆分 + 状态下沉	永远不需要（没有例外）
手动 shouldComponentUpdate	删掉	2026 年了不应该还有 Class 组件

判断标准就一条：先用 React DevTools Profiler 跑一遍。没有证据证明是瓶颈的，就别优化。

升级 React Compiler 的最小步骤

如果你的项目还没启用 React Compiler：

npm install react-compiler-runtime
npm install -D babel-plugin-react-compiler

Babel 配置加一行：

{
  "plugins": [
    ["babel-plugin-react-compiler", {}]
  ]
}

Vite 用户：

// vite.config.js
import { reactCompiler } from 'react-compiler-runtime/vite';

export default {
  plugins: [reactCompiler()],
};

启用后，可以逐步删掉不必要的 useMemo/useCallback/React.memo。不用一次性全删——编译器和手动优化可以共存，只是手动的部分变成了冗余代码。

别让 AI 替你做决定

这篇文章本质上在说一件事：不要因为 AI 生成了 useMemo，你就不敢删它。

AI 代码生成器的训练数据里充满了 2020-2024 年的"最佳实践"文章。那些文章在当时是对的——React 没有编译器，手动 memoization 是唯一选择。但 2026 年了，工具变了，实践也要变。

用 AI 写代码没问题。但 Review 的时候，你需要知道什么该留、什么该删。

你的项目升级 React Compiler 了吗？升级后删了多少行 useMemo？评论区聊聊。

我看完这篇安全论文——AI 推荐的 npm 包，92% 是编出来的

193577746 — Fri, 17 Jul 2026 19:45:23 +0800

你有没有想过一个问题：AI 让你 npm install 的那个包，真的存在吗？

7 月 8 日，以色列特拉维夫大学、Technion（以色列理工学院）和 Intuit 的研究人员联合发表了一篇论文，提出了一种叫 HalluSquatting 的新型攻击方式。

核心发现让我出了一身冷汗：AI 编程助手推荐的 GitHub 仓库名称，平均幻觉率高达 92.4%。

不是拼错了包名，不是搞混了版本号——是整个仓库根本不存在，AI 凭空捏造了一个名字。

而攻击者已经在利用这一点了。

什么是 HalluSquatting

论文全名叫 "Beware of Agentic Botnets: Scalable Untargeted Promptware Attacks via Universal and Transferable Adversarial HalluSquatting"，名字很长，核心思路三句话讲清：

AI 编程助手会编造不存在的包名和仓库名（这就是大模型的"幻觉"）
同一个问题反复问，AI 编出来的假名字惊人地一致——58% 的概率编出同一个名字
攻击者提前注册这些假名字，埋入恶意代码和 Prompt 注入——坐等开发者通过 AI 上钩

你可能听过 typosquatting（域名/包名抢注），攻击者注册和知名包相似的名字，比如 loadash 冒充 lodash。

HalluSquatting 比这狠得多：它不需要猜你会打错什么字，它直接预测 AI 会编什么名字。而且预测准确率极高。

攻击怎么运作的

整个攻击链分五步：

第一步：挖掘"幻觉包名"

攻击者选一个热门开源项目，反复问不同的 AI 助手："帮我克隆这个项目"或"帮我安装这个工具"。

AI 会编造一个不存在的仓库名或包名。关键发现：不同用户问同一个问题，AI 编出来的假名字有 58% 的概率是相同的。

这意味着攻击者可以大规模、自动化地预测 AI 会推荐哪些假名字。

第二步：抢注假名字

攻击者拿到这些"AI 最爱编的名字"，去 GitHub、npm、PyPI 上注册同名项目，放入看起来正常但暗藏恶意逻辑的代码。

第三步：植入 Prompt 注入

这是 HalluSquatting 和普通供应链攻击的关键区别。攻击者不只放恶意代码，还会在 README 或代码注释里嵌入 Prompt Injection——专门劫持 AI Agent 的指令。

一旦 AI 读取了这些内容，它会被"洗脑"，开始执行攻击者预设的操作。

第四步：等 AI 上钩

当一个真实的开发者问 AI："帮我安装这个工具"，AI 编出同一个假名字，自动去 npm/GitHub 拉取——拿到的就是攻击者的恶意版本。

第五步：感染扩散

被劫持的 AI Agent 开始执行攻击者的指令：开反向 shell、偷密码和 Token、挖矿，甚至感染其他 AI Agent，形成僵尸网络（Botnet）。

论文标题里的 "Agentic Botnets" 就是这个意思——由 AI Agent 组成的僵尸网络。

有多严重？论文里的数字

研究人员对多款主流 AI 编程工具做了大规模测试：

场景	幻觉率
2025 年新发布的 GitHub 仓库	92.4%
2019 年之前的老牌 GitHub 仓库	0.9%
仓库克隆场景（整体）	最高 85%
Skill/插件安装场景	最高 100%

一个反直觉的发现：越新的项目，AI 越容易编造假名字。

老项目（2019 年前）因为训练数据充分，幻觉率只有 0.9%。但 2025 年新发布的项目，AI 几乎在瞎编——因为这些项目不在训练数据里，模型只能"猜"。

这意味着：当你让 AI 帮你克隆一个最近刚火起来的新项目时，它给你的仓库地址大概率是假的。

哪些工具中招了

论文测试了 9 款 AI 编程工具，攻击成功率差距巨大：

工具	攻击成功率	风险等级
Cursor	20-35%	⚠️ 中等
GitHub Copilot	20-35%	⚠️ 中等
Gemini CLI	20-35%	⚠️ 中等
Windsurf	20-35%	⚠️ 中等
Cline	20-35%	⚠️ 中等
OpenClaw	80-100%	🔴 极高
ZeroClaw	80-100%	🔴 极高
NanoClaw	80-100%	🔴 极高

主流商业工具（Cursor、Copilot、Gemini CLI）的攻击成功率在 20-35%——看起来不算特别高？换个角度：你每让 AI 安装 5 个包，就有 1 到 2 个可能是假的。

而基于开源模型的工具（OpenClaw 系列），成功率直接飙到 80-100%。

真实案例：react-codeshift

这不是纯理论攻击。

2026 年 1 月，安全公司 Aikido Security 的研究员 Charlie Eriksen 发现了一个真实案例：AI 编程助手经常向开发者推荐一个叫 react-codeshift 的 npm 包。

问题是——这个包在 npm 上根本不存在。

它是 AI 编出来的。但 Eriksen 发现，已经有 237 个 GitHub 仓库的代码里包含了安装这个假包的指令，全都是 AI 生成的代码里写的。

如果有人抢先在 npm 上注册了 react-codeshift 并放入恶意代码，这 237 个仓库的所有用户都会中招——而且他们根本不知道自己装了个假包。

这不是孤例。2025 年 8 月的 Nx 供应链攻击中，攻击者利用 AI 编程工具扫描开发者的加密货币钱包和 Token。2026 年 3 月的 Axios npm 攻击中，维护者 Token 被盗，恶意版本被推送到 npm 官方源。

AI 编程工具正在成为供应链攻击的新入口。

防护速查表

收藏这张表，每次 AI 推荐你安装新包时对照检查：

检查项	具体操作	何时执行
验包真伪	运行 `npm view <包名>` 确认包存在且有下载量	每次 AI 推荐新包时
查仓库来源	去 GitHub 手动搜索仓库名，确认 Star/Fork/活跃度	每次 AI 给你仓库链接时
审查安装脚本	`npm diff <包名>` 查看包内容，特别看 `postinstall` 脚本	每次新增依赖时
锁定依赖版本	提交 `package-lock.json`，开启 `npm audit`	项目初始化时
用私有仓库	配置公司级 npm 私有源，只允许白名单内的包	团队项目必须
关闭自动执行	AI 推荐安装命令时，先审查再手动执行，不要让 Agent 自动 `npm install`	所有场景
持续扫描	在 CI/CD 中集成 `socket.dev` 或 `snyk` 扫描依赖树	每次构建时

最重要的一条原则：永远不要让 AI Agent 自动执行未经你确认的 npm install。

一行命令就能验证：

# AI说"npm install xxx"之前，先跑这个
npm view xxx

# 看到 404？恭喜你，AI在编故事

写在最后

HalluSquatting 论文揭示了一个很多开发者还没意识到的问题：我们对 AI 编程助手的信任，已经超出了它应得的程度。

AI 确实能帮你写出大部分代码。但它推荐的包名、仓库地址、安装命令——这些看起来最"确定"的输出，恰恰是它最容易编造的部分。92.4% 的幻觉率不是个小数字。

我不是说要停用 AI 编程工具。但至少，当它告诉你 npm install xxx 的时候，花 10 秒钟跑一下 npm view xxx。

10 秒钟，可能帮你避免一次反向 shell。

你平时会检查 AI 推荐安装的包是否真实存在吗？还是直接复制粘贴就装了？ 评论区说说你的习惯。

AI 写的 React 组件,合并前必查的 6 个坏味道——每个都有代码对比

193577746 — Thu, 16 Jul 2026 21:53:41 +0800

先说一句：这篇不是让你别用 AI 写 React。

我自己每天用 Claude Code + Cursor,产出效率至少翻倍。但要说得罪的话——AI 生成的 React 代码,直接合并的风险,比你想象的高。

不是因为 AI 语法错。语法它比你还熟。

是因为 React 的"最佳实践"是一堆上下文相关的判断:什么时候用 useEffect、什么时候不用;state 该放哪一层;key 用什么;要不要 memo。这些判断需要看这段代码所在的整个组件树,而 AI 大多数时候只看到你贴过去的那几行。

于是就有了下面这 6 个几乎每天都能在 AI 生成的 PR 里看到的坏味道。每一个我都给出真实的对比代码,你合并前扫一眼就能看出来。

1. 把渲染时能算的东西塞进 useEffect

这是 AI 生成 React 代码里最普遍的坏味道,没有之一。

AI 常见写法

function OrderList({ orders }: { orders: Order[] }) {
  const [total, setTotal] = useState(0);
  const [filtered, setFiltered] = useState<Order[]>([]);

  useEffect(() => {
    const filteredOrders = orders.filter(o => o.status === 'paid');
    setFiltered(filteredOrders);
    setTotal(filteredOrders.reduce((sum, o) => sum + o.amount, 0));
  }, [orders]);

  return (
    <div>
      <p>合计: {total}</p>
      <ul>{filtered.map(o => <li key={o.id}>{o.name}</li>)}</ul>
    </div>
  );
}

为什么坏

三层问题:

多渲染一轮。orders 变 → 组件渲染 (拿到旧 total/filtered) → useEffect 跑 → setState → 再渲染一次。用户能感知的白屏/闪一下,很多来源于此。
state 和 props 会脱同步。如果哪天你多加一个 setFiltered 的分支忘了同步 total,数据就错了。
依赖数组稍微写错就是死循环。AI 写这类代码经常忘依赖或多依赖。

正确写法

派生数据直接在渲染阶段算,不要 state,也不要 effect:

function OrderList({ orders }: { orders: Order[] }) {
  const filtered = orders.filter(o => o.status === 'paid');
  const total = filtered.reduce((sum, o) => sum + o.amount, 0);

  return (
    <div>
      <p>合计: {total}</p>
      <ul>{filtered.map(o => <li key={o.id}>{o.name}</li>)}</ul>
    </div>
  );
}

如果 filter 真的很贵 (比如上万条 + 复杂计算),再考虑 useMemo。先别急着优化。

判断标准

看到 AI 生成的 useEffect,第一个问自己:"这个逻辑,能不能直接写在 return 上面?" 大多数情况都能。

2. 把 props 复制到 useState

AI 常见写法

function UserForm({ user }: { user: User }) {
  const [name, setName] = useState(user.name);
  const [email, setEmail] = useState(user.email);

  return (
    <>
      <input value={name} onChange={e => setName(e.target.value)} />
      <input value={email} onChange={e => setEmail(e.target.value)} />
    </>
  );
}

看上去很合理:表单要能编辑,所以得有 state。

为什么坏

useState(user.name) 里的 user.name 只在组件第一次挂载时被读一次。之后父组件传入新的 user,name 也不会更新。

这个 bug 特别隐蔽——本地开发切换用户能看到,但 AI 写完你跑一遍单个用户流程,PR 就过了。

上线之后一切换用户,表单显示上一个用户的数据,老板会问:"你测过没?"

正确写法

明确表单是"受控还是非受控"。两种解:

A. 完全受控,state 在父组件

function UserForm({ user, onChange }: { 
  user: User; 
  onChange: (patch: Partial<User>) => void 
}) {
  return (
    <>
      <input 
        value={user.name} 
        onChange={e => onChange({ name: e.target.value })} 
      />
      <input 
        value={user.email} 
        onChange={e => onChange({ email: e.target.value })} 
      />
    </>
  );
}

B. 内部 state,但要用 key 强制重挂载

<UserForm key={user.id} user={user} />

一切换 user.id,React 会销毁旧组件重新创建,state 也会用新的 initial value。

判断标准

看到 useState(props.xxx),九成是错的。要么把 state 提上去,要么用 key 隔离。

3. useEffect 里 fetch,不处理竞态

AI 常见写法

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(r => r.json())
      .then(setUser);
  }, [userId]);

  return user ? <div>{user.name}</div> : <Skeleton />;
}

你能一眼看出问题吗?

为什么坏

用户快速点击不同的用户 A → B → C,fetch 会按顺序发出,但返回顺序不一定。

如果 A 的请求走网络慢,C 已经回来了显示了 C 的名字,然后 A 的响应姗姗来迟——页面会突然变回 A 的数据。

这不是理论,这是每一个做过用户列表页的前端都栽过的坑。AI 几乎从不主动处理。

正确写法

用 AbortController 或 stale flag:

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);

  useEffect(() => {
    const ctrl = new AbortController();
    fetch(`/api/users/${userId}`, { signal: ctrl.signal })
      .then(r => r.json())
      .then(setUser)
      .catch(err => {
        if (err.name !== 'AbortError') throw err;
      });
    return () => ctrl.abort();
  }, [userId]);

  return user ? <div>{user.name}</div> : <Skeleton />;
}

或者更省心,直接用数据请求库:SWR、React Query、TanStack Query 都自带竞态处理。

判断标准

useEffect 里但凡出现异步,cleanup 函数一定要写。没写就是坏味道。

4. 列表 key 用 index

AI 常见写法

{items.map((item, i) => (
  <ListItem key={i} data={item} />
))}

写这一行时 AI 甚至不会犹豫。

为什么坏

当列表顺序变化、中间插入、删除时,React 会用 key 去匹配前后两次渲染的元素。用 index 做 key,等于告诉 React:"第一位永远是第一位"——但你换了内容它认不出来。

后果:

列表项里如果有 <input>,用户输入到一半,你在上面插入一项,焦点就跑了
列表项如果是带内部 state 的组件,state 会串位
动画/transition 会错乱

正确写法

用数据本身的稳定 id:

{items.map(item => (
  <ListItem key={item.id} data={item} />
))}

如果数据真的没 id,前端可以在拿到数据时用 crypto.randomUUID() 或自增计数补一个,但要保证同一个数据永远拿同一个 id——不能每次渲染新生成。

判断标准

看到 key={index} key={i} key={idx},直接怀疑。除非这个列表永远不会重排、不会插入删除、不会有内部 state——才 100% 安全。

5. 内联对象 / 函数,搭配 memo 组件 = memo 失效

AI 常见写法

const Row = React.memo(({ style, onClick, data }: Props) => {
  return <div style={style} onClick={onClick}>{data.name}</div>;
});

function Table({ rows }: { rows: Row[] }) {
  return rows.map(row => (
    <Row
      key={row.id}
      style={{ padding: 8, borderBottom: '1px solid #eee' }}
      onClick={() => console.log(row.id)}
      data={row}
    />
  ));
}

看上去合理:子组件 memo 了,应该优化了。

为什么坏

style={{ padding: 8 }} 和 onClick={() => ...} 每次渲染都是新的引用。

React.memo 默认用 Object.is 做浅比较,新旧引用不等 → memo 直接失效 → 每次父组件渲染,所有 Row 都重渲染。

你以为你优化了,其实一点没优化,还多了个浅比较的开销。

正确写法

内联对象提到外面 (如果是纯静态的):

const rowStyle = { padding: 8, borderBottom: '1px solid #eee' };

function Table({ rows }: { rows: Row[] }) {
  const handleClick = useCallback((id: string) => {
    console.log(id);
  }, []);

  return rows.map(row => (
    <Row
      key={row.id}
      style={rowStyle}
      onClick={handleClick}
      rowId={row.id}
      data={row}
    />
  ));
}

const Row = React.memo(({ style, onClick, rowId, data }: Props) => {
  return <div style={style} onClick={() => onClick(rowId)}>{data.name}</div>;
});

注意:让 Row 内部生成 () => onClick(rowId) 才能保证 onClick 是稳定引用。

判断标准

看到 React.memo 出现,立即扫一眼调用处的 props——如果传的是 {...}、[...]、() => ...,memo 直接白包。

6. useMemo / useCallback 无脑加

这条和上一条正好相反——AI 也经常反过来滥用 memo。

AI 常见写法

function Greeting({ name }: { name: string }) {
  const greeting = useMemo(() => `Hello, ${name}!`, [name]);
  const handleClick = useCallback(() => alert(greeting), [greeting]);

  return <button onClick={handleClick}>{greeting}</button>;
}

三行代码,两个 hook。

为什么坏

useMemo 和 useCallback 本身有成本:

每次渲染都要跑依赖数组的浅比较
React 内部要维护一个额外的记忆槽
代码可读性直线下降

一个字符串拼接,直接计算比 useMemo 快十倍。给 button 传的 onClick 也不是 memo 组件,useCallback 完全没意义。

滥用 memo 的代码,通常比不加 memo 更慢——因为该做的事情没少做,还多做了一层浅比较。

正确写法

function Greeting({ name }: { name: string }) {
  const greeting = `Hello, ${name}!`;
  return <button onClick={() => alert(greeting)}>{greeting}</button>;
}

只在下面两种情况才加 memo:

计算真的贵 (比如上万条数据的 filter/sort/reduce)
值/函数要作为 prop 传给 memo 组件,或者作为 useEffect/useMemo 的依赖

除此之外——不加就是对的。

判断标准

看到 useMemo/useCallback,反问一句:"如果去掉它,哪里会重新计算/重渲染?" 答不上来,就删掉。

最后:一份合并前 60 秒 checklist

如果你没时间读完全文,把下面这段贴到你的 Code Review 模板里:

□ useEffect 里的逻辑,能不能挪到渲染阶段?
□ useState(props.xxx) 出现了吗?出现就是错。
□ useEffect 里的 fetch,有没有 AbortController 或 cleanup?
□ 列表 key 是不是稳定 id?不是就改。
□ React.memo 组件的 props,有没有内联对象/函数/数组?
□ useMemo/useCallback,如果删掉会怎样?说不上来就删。

六个问题,合并前扫一眼一分钟搞定。

一句话总结

AI 生成的 React 代码,语法都对,但 React 不是纯粹语法。

它是一套"什么时候该干什么、什么时候该什么都不干"的判断力。AI 看不到你的组件树、看不到用户如何交互、看不到线上的性能数据——这些判断,现在还得你来做。

用 AI 写代码不丢人,合并前不看 AI 写的什么,才丢人。

面试官让我优化一个卡死的表格，我打开 Claude 五秒重写——他放下咖啡问我要不要来当组长

193577746 — Wed, 15 Jul 2026 20:47:17 +0800

上周去面试一家做 SaaS 的中厂，二面是一位四十出头的前端负责人。

寒暄结束，他直接把笔记本转过来推到桌子中间：

"这是我们线上一个真实的报表页，10 万行数据，滚起来直接卡死。你帮我看看怎么优化。用什么工具都行。"

最后那半句他说得很平淡，我当时没多想。

结果二十分钟后，他把咖啡杯往桌上一放，问了我一个我准备了整场面试都没想到的问题。

一、题目本身：一个"教科书级"的坑

页面代码大概长这样（我做了脱敏改写）：

function ReportTable({ rows }: { rows: Row[] }) {
  // rows.length ≈ 100_000
  return (
    <table>
      <thead>...</thead>
      <tbody>
        {rows.map((row) => (
          <tr key={row.id}>
            <td>{row.name}</td>
            <td>{row.amount}</td>
            <td>{row.status}</td>
            <td>
              <Select options={statusOptions} value={row.status} />
            </td>
            <td>
              <DatePicker value={row.updatedAt} />
            </td>
          </tr>
        ))}
      </tbody>
    </table>
  );
}

写过一年 React 的都能一眼看出问题：

10 万行一次性渲染 → 首屏就是白屏 6-8 秒
每行还挂着 <Select> <DatePicker> 这种带弹层的重组件
key 没问题，但 diff 也扛不住 40 万个 DOM 节点
滚动过程再触发 hover / active，浏览器直接躺平

搁在教科书里，标准优化路径也有三条：

虚拟滚动（react-window / @tanstack/react-virtual）
时间切片渐进渲染（startTransition / requestIdleCallback）
Canvas / 半 Canvas 渲染（AG Grid、Handsontable 那种）

三种我都懂，但每种都有细节：单元格要不要支持编辑？行高是否等高？要不要支持多选？滚动过程能不能容忍占位闪一下？

真让我在白板上写完再讲清楚三者的取舍——20 分钟够呛。

二、我做了一件"面试大忌"的事

我抬头问了一句：

"您刚才说，用什么工具都行？"

面试官点头。

于是我把自己的笔记本翻开，打开 Claude Code，把这段组件连同 Row 类型、业务约束一起丢了进去，只写了一句：

"React 18 + TS。10 万行表格，每行 5 列，其中两列有 Select 和 DatePicker。产品要求可以滚动、可以点某一行进入详情、后期可能要支持行内编辑。给我三种优化方案，并解释在哪种交互需求下谁最合适。"

大概 4 秒之后，屏幕上刷出了三段方案。

方案一：虚拟滚动（@tanstack/react-virtual）

import { useVirtualizer } from '@tanstack/react-virtual';

function ReportTable({ rows }: { rows: Row[] }) {
  const parentRef = useRef<HTMLDivElement>(null);
  const rowVirtualizer = useVirtualizer({
    count: rows.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 44,
    overscan: 10,
  });

  return (
    <div ref={parentRef} style={{ height: 600, overflow: 'auto' }}>
      <div style={{ height: rowVirtualizer.getTotalSize(), position: 'relative' }}>
        {rowVirtualizer.getVirtualItems().map((v) => {
          const row = rows[v.index];
          return (
            <div key={row.id} style={{
              position: 'absolute', top: 0, left: 0,
              transform: `translateY(${v.start}px)`,
              height: v.size, width: '100%',
            }}>
              {/* row cells */}
            </div>
          );
        })}
      </div>
    </div>
  );
}

Claude 的注释里写："最通用、社区最成熟。等高行下开箱即用，行内编辑也没问题。缺点是 Select / DatePicker 这类弹层组件在滚出可视区时会被销毁，弹层里的选中态要托管到外层 state。"

方案二：时间切片渐进渲染

function ReportTable({ rows }: { rows: Row[] }) {
  const [visibleCount, setVisibleCount] = useState(50);

  useEffect(() => {
    if (visibleCount >= rows.length) return;
    const id = requestIdleCallback(
      () => setVisibleCount((c) => Math.min(c + 200, rows.length)),
      { timeout: 100 }
    );
    return () => cancelIdleCallback(id);
  }, [visibleCount, rows.length]);

  return (
    <table>
      <tbody>
        {rows.slice(0, visibleCount).map((row) => (
          <tr key={row.id}>{/* cells */}</tr>
        ))}
      </tbody>
    </table>
  );
}

Claude 提示："首屏最快，DOM 结构最简单，SEO 友好。但滚到最底部要 10+ 秒才能加载完，用户拖滚动条会看到断层。适合'看不完但不能少'的报表——比如打印导出前的预览页。"

方案三：半 Canvas 渲染（AG Grid / 自研）

Claude 直接建议接第三方库，并给出了两条使用理由：

"如果表格未来要支持行内编辑、多选、复制粘贴、列拖拽——自己造轮子会一路踩坑。AG Grid 的 Community 版本免费够用，缺点是包体积 500KB+，且样式覆盖成本高。"

我把屏幕转向面试官。他没说话，只是往前挪了挪坐姿。

三、真正让面试官愣住的，不是 AI 给的答案

我接着说：

"我倾向于方案一。因为您说了'后期可能要支持行内编辑'——Canvas 方案改起来太重，切片方案在编辑焦点跳出时会重排。虚拟滚动只要把弹层组件的开合状态提到外层就行。要不咱们跑一下 Performance 看看？"

我把三种方案都在他们的测试环境跑了一遍，Chrome DevTools 打开 Performance。

未优化：首屏 6.8 秒，滚动帧率 8 FPS
方案一：首屏 320 ms，滚动稳定 60 FPS
方案二：首屏 90 ms，但滚到底部要 12 秒
方案三：首屏 480 ms，60 FPS，但 bundle 大了 480 KB

首屏时间从 6.8 秒压到 320 毫秒，快了 21 倍。

面试官这时候放下了咖啡杯，问了我第一个"意外"的问题：

"你怎么判断把弹层 state 提到外层就够了？"

我说：

"我没直接判断。Claude 给方案后我又追问了一次——'如果同一行的 Select 打开时用户滚出可视区，会发生什么？'它回答说组件会 unmount，弹层直接消失。所以我在方案一里加了一句：把 openId 提到父组件用 Portal 渲染弹层。这样滚出去也不会关。"

面试官盯着我看了两秒，问了第二个问题：

"你组里其他前端，也是这么用 AI 的吗？"

我如实说：不是。大部分同事要么完全不用，要么直接把 AI 的答案 Ctrl+C Ctrl+V 提交。

他"嗯"了一声，然后是第三个问题——就是那个让我离开会议室之后琢磨了一路的问题：

"我们前端组长下个月转岗。你要不要考虑一下这个位置？"

四、我在地铁上想明白的事

回程地铁上我一直在想：他到底看中了什么？

不是虚拟滚动。方案二方案三我都答得上来，任何一个高级前端都能。

不是 AI。他们组里肯定有人 Claude、Cursor 都开着。

想通之后我总结出三点，写在这里给同样在跳槽的朋友：

1. 他看的是信息带宽，不是答题速度

传统面试考察的是"你脑子里存了多少知识"。但当所有人脑子里都能调用同一个 AI 的时候，考察点就变成了"你能在单位时间内提出多好的问题"。

我丢给 Claude 的那条 prompt 里有五个关键要素：

技术栈（React 18 + TS）
数据量级（10 万行 5 列）
复杂组件（Select、DatePicker）
交互约束（可滚动、可点击、可能要编辑）
判断标准

如果我只写"帮我优化这个卡顿的表格"，Claude 给的答案就是水平线。

面试官看到的其实是：这个人的 prompt 里，藏着五年前端经验。

2. 他看的是验证能力，不是采纳能力

我在讲方案时说过一句话："这是 Claude 给的，但我用 Performance 面板验证过了。"

这句话之所以关键，是因为它划出了两类人：

把 AI 输出当权威，直接提交
把 AI 输出当同事的初稿，看完了再判断

后一种人，团队里其实不多。而这种人是能带团队的。

3. 他看的是你怎么让 AI 干活，不是你会不会用 AI

前端组长这个岗位在他心里对应的画像大概是：

"一个能把 AI 当放大器用的人，一个人的产出等于三个人。而且他知道什么时候不该信 AI——比如弹层脱离视口、比如包体积不能牺牲。"

我在展示解题过程里，无意间把这两点都露出来了。

五、给还在准备面试的前端

如果你也在跳槽，尤其在中厂到大厂的过渡区间，几个我踩过之后的建议：

能带电脑就带电脑。 越来越多的公司允许现场用工具了。别怕面试官觉得你依赖 AI——他们在乎的是你怎么用。

练习"提问"比练习"手写"回报大。 手写 Promise、手写深拷贝、手写 EventEmitter，AI 三秒能解。但"给出三种方案 + 比较适用场景 + 结合数据量和交互约束"这种 prompt，得真练。

每一次 AI 给答案后，都强迫自己追问一次"如果 X 前提不成立，会怎样"。 例如：

如果表格行高不等，虚拟滚动会怎样？
如果用户网速慢，切片渲染的最后一屏会怎样？
如果产品要打印全表，Canvas 方案怎么办？

这是把 AI 的天花板变成你的地板的唯一方法。

准备一段"我怎么用 AI"的故事。 不是理论，是具体的一次协作过程。这段故事的价值，比你把 Fiber 原理背下来大得多。

尾声

2026 年了，考察前端的方式已经变了。

变化不是"你会不会用 AI"，而是"你能不能带着 AI，做出一个人做不完的事"。

面试官那天放下咖啡的那 2 秒，我大概能听见他脑子里在想什么：

"这人来了之后，我这个季度的排期能砍一半。"

能被这么想，比手写十道八股都值钱。

看了微软几万人用 AI 编程的数据——效率涨 24% 的代价没人提

193577746 — Tue, 14 Jul 2026 21:06:42 +0800

微软刚发了一份研究报告：给几万名工程师部署 Claude Code 和 Copilot CLI 四个月后，每人每天多合并了 24% 的 PR。管理层都在转发。但我把它和另外几份数据放在一起看完之后——坐不住了。

24% 的效率提升，听起来很美

先说微软这份报告的核心数据：

研究对象：数万名微软工程师
部署工具：Claude Code + GitHub Copilot CLI
时间跨度：2026 年初，四个月
核心结论：每人每天合并的 PR 增加了 24%（置信区间 14.5%-33.7%）

24% 的提升确实不小。如果一个团队以前一天能合并 10 个 PR，现在能合并 12-13 个。管理层看到这个数字，第一反应是"全员推广"。

但 PR 数量增加 = 生产力提升吗？

这份报告在 Hacker News 的讨论帖里，点赞最高的评论说了一句话：

Lines of code isn't productivity, and neither is CLs landed.（代码行数不是生产力，合并的 PR 数也不是。）

效率涨了 24%，但另一组数据没人提

把微软报告和其他几份最近的研究放在一起，画风完全不同了：

数据一：AI 代码的 bug 率高 70%

Shiplight 对数千个 PR 的分析显示，AI 生成的代码比人写的多 1.7 倍 bug，逻辑错误多 75%，可读性问题多 3 倍。

PR 是多了 24%，但每个 PR 里藏的 bug 也多了 70%。

数据二：96% 的开发者不完整审查 AI 代码

Sonar 的调查显示，96% 的开发者不会完整审查 AI 生成的代码。AI 写完了，扫一眼，能跑就合，下一个。

24% 更多的 PR + 每个 PR bug 多 70% + 96% 没人仔细看 = ？

数据三：开发者对 AI 代码的信任度降至 33%

2026 年的调查数据显示，只有 33% 的开发者信任 AI 生成的代码质量。但信不信是一回事，用不用是另一回事——工期在那摆着，老板在催，不用 AI 就是效率低。

数据四：有人靠清理 AI 代码月入 4 万美元

三个工程师辞职创办了 Slopfix，专门帮企业清理 AI 生成的代码，收费每周 1 万美元。生意好到接不完。

Forbes 上周的标题更直接：AI Coding Is Starting To Feel Like A Gamble（AI 编程开始像赌博了）。

真正的代价是什么

效率涨 24% 很好。但代价是什么？我整理了五个"报告里没写"的隐性成本。

代价一：技术债加速积累

AI 写代码快，但它不会考虑架构一致性。一个 10 人团队里 10 个人都用 AI，每个人生成的代码风格、错误处理方式、状态管理策略都不一样。

三个月后，代码库变成缝合怪。以前技术债线性增长，现在 AI 让代码产出翻倍，技术债也翻倍，但还的速度没变。

代价二：Code Review 变成新瓶颈

PR 增加了 24%——谁来 Review？

AI 可以替你写代码，但不能替你 Review 别人的代码。PR 多了 24%，Review 的工作量也多了 24%。而且 AI 代码的 Review 比人写的更难——因为你不知道"为什么"这样写，只能看到"是什么"。

结果：要么 Review 质量下降（96% 的人已经在这么做了），要么 Review 成为整个团队的瓶颈。

代价三：初级开发者不成长了

AI 写代码最大的受益者是初级工程师——产出"看起来"和高级差不多。但"看起来差不多"和"真的差不多"是两回事。

初级工程师用 AI 绕过了"自己思考解决方案"的过程，产出有了，能力没涨。一年后：公司账面上有一批"高产出"的初级工程师，但没人能 debug AI 写的代码，也没人能做架构决策。

代价四：安全漏洞乘数效应

安全研究显示，AI 生成的代码安全漏洞率是人写代码的 2.74 倍。

以前一天 100 行代码，可能 2 个安全漏洞。现在一天 300 行，漏洞可能有 16 个。产出涨 3 倍，漏洞涨 8 倍。而且 AI 的安全漏洞更难发现——代码"看起来"很标准，就是在某个边界条件上漏了一个验证。

代价五：调试成本不降反升

AI 代码最讽刺的地方：写得快，修得慢。

你没有亲手写过，不知道设计意图，不知道为什么选了这个方案。出了 bug，面对的是"别人写的代码"——只不过这个"别人"是 AI，你连问都没法问。

Slopfix 每周 1 万美元帮人清理 AI 代码，不是因为 AI 代码特别烂——是因为没有人知道它是怎么回事，只能推倒重来。

速查表：你的 AI 代码有没有踩这些坑

风险信号	检查方法	严重程度
AI 代码合并后从不回头看	查最近 10 个 AI PR 的后续修改记录	🔴 高
Review 时只看"能不能跑"	能说出这段代码为什么这样写吗？	🔴 高
团队没有 AI 代码审查标准	有没有专门的 AI 代码 checklist？	🟡 中
初级成员产出突然和高级持平	对比 debug 能力和架构讨论参与度	🟡 中
代码风格越来越不一致	翻最近一个月的提交看格式/命名	🟡 中
从没跑过安全扫描	对 AI 代码做一次安全扫描	🔴 高
线上 bug 修复时间变长	对比引入 AI 前后的修复时长	🔴 高

收藏这张表。下次做月度回顾的时候，对着查一遍。

不是不该用 AI，是不该盲目用

微软的 24% 效率提升是真的。AI 编程确实有价值。

但"写得快"和"写得好"是两件事。微软的报告衡量的是前者，我们日常承受的是后者的后果。

正确的用法：

AI 写代码 → 但必须有人类 Review（不是扫一眼）
用 AI 加速 → 省出来的时间做 Code Review 和测试
初级可以用 AI → 但必须能解释 AI 生成的每一行代码
衡量效率 → 同时衡量 bug 率、安全漏洞数、技术债增速

PR 涨了 24%，如果 bug 也涨了 70%，净效果是正的还是负的？

这道算术题，每个技术负责人都应该自己算一遍。

你的团队用 AI 编程后，代码质量有变化吗？评论区说说你的观察。

觉得有用？点个「赞」👍 让更多人看到

关注我，获取更多技术干货。

别再用 AI debug 了——这 5 种 bug 越修越烂

193577746 — Mon, 13 Jul 2026 21:30:18 +0800

上周 Hacker News 上火了一个帖子：三个工程师开了家公司叫 Slopfix，专门帮人删 AI 生成的代码，收费每周 1 万美元。生意好到接不完。

AI debug 的死亡循环

你一定经历过这个场景：

代码报错了。你把报错信息丢给 AI。AI 给你改了。跑了一下，原来的错没了，但出了一个新错。你又丢给 AI。AI 又改了。又出了一个新错。

三轮下来，你的代码从 1 个 bug 变成了 5 个 bug，而且你已经完全不知道 AI 到底改了什么。

这不是你的问题。Shiplight 对数千个 PR 的数据分析显示：AI 生成的代码比人写的多 1.7 倍 Bug，逻辑错误多 75%。 也就是说，AI 在"修 bug"的过程中，大概率在制造新的 bug。

更扎心的是——Sonar 的调查说 96% 的开发者不会完整审查 AI 生成的代码。AI 改了三轮，你看都没仔细看就跑了，然后发现又炸了。

现在有人靠清理 AI 代码每周赚 1 万美元。这说明 AI debug 的"售后成本"已经大到可以撑起一门生意了。

以下 5 种 bug，你越让 AI 修，就越烂。

第 1 种：CSS 和样式问题

AI 修 CSS 最大的问题：它看不到级联。

你说"这个按钮的边距不对"。AI 加了一个 margin-top: 20px。

但这个按钮在另一个页面也用到了，那边的边距本来是对的，现在也被影响了。

你再告诉 AI。AI 怎么修？加一个更高优先级的选择器覆盖。

两轮下来，样式表里多了两层覆盖，一堆 !important，和一个完全看不懂的选择器优先级链。

为什么 AI 修不好 CSS： CSS 是全局作用域的，改一处影响多处。AI 每次只看你指给它的那一处。它的修法永远是"在上面再叠一层"，而不是找到根因。越叠越多，最后只有重写能理清。

自己修： 打开 DevTools，看 Computed Styles 找到实际生效的规则，改根因，一次改对。

第 2 种：跨组件的状态 bug

列表页和详情页共享一个全局状态。用户在详情页做了修改，回到列表页没更新。

你把 bug 丢给 AI。AI 在列表页加了一个 useEffect 重新请求数据。

好了，数据更新了。但现在每次从任何页面回到列表，都会重新请求——包括从搜索页、设置页回来。接口被打爆了。

你再跟 AI 说"请求太频繁了"。AI 加了一个防抖。现在数据有时候更新有时候不更新，取决于你切页面的速度够不够快。

两轮修复 = 一个 bug 变三个 bug。

为什么 AI 修不好状态 bug： 状态 bug 的根因通常不在报错的那个组件里，而在数据流的上游。AI 看到的是"这个组件数据不对"，修法是"让这个组件自己拿数据"——治标不治本。每治一次标，就多一条数据流路径，系统复杂度指数级上升。

自己修： 先画出数据流向——哪个组件读、哪个组件写、经过几层传递。状态 bug 的修复点在数据源头，不在展示末端。

第 3 种：只在特定环境出现的 bug

线上报了一个 bug，本地复现不了。

你把报错日志丢给 AI。AI 说"可能是没做空值判断"，给你加了个 ?.。

部署上去，线上还是报错。因为问题根本不是空值——是某个环境变量在生产环境的值和开发环境不一样。

你又把新的报错丢给 AI。AI 又猜了一个原因，又改了一处。

这是 AI debug 最危险的场景：它在猜。

AI 没有你的生产环境，没有你的日志系统，没有你的监控面板。它只能根据你给它的那几行报错信息"推测"原因。而环境类 bug 的根因通常在配置、网络、权限这些层面——不在代码层面。

AI 的每次"猜测性修复"都在往代码里塞不必要的防御逻辑。三轮下来，代码里全是 ?.、try-catch、if (!x) return——真正的问题一个没解决。

自己修： 先确认是不是代码 bug。看日志、看监控、比较环境差异。如果确认是代码问题，给 AI 完整的上下文（报错日志 + 环境信息 + 复现步骤）再让它帮忙。

第 4 种：依赖冲突

某个包升级后，项目跑不起来了。

你告诉 AI。AI 说"试试降级到 X 版本"。降了，那个包好了，另一个包又报错了——因为它依赖更高版本。

你又告诉 AI。AI 说"那把另一个包也降级"。降了，TypeScript 报了一屏的类型错误。

这就是依赖地狱，AI 不但解决不了，还会让你陷得更深。

为什么 AI 修不好依赖冲突： 依赖关系是一张网，不是一条线。改一个版本号可能影响几十个包。AI 的修法永远是"改版本号"——它不会帮你看 changelog，不会帮你判断哪个大版本有 breaking change。每改一次版本号，可能性空间都在指数膨胀。

自己修： 先看报错包的 changelog 和 peer dependencies。依赖冲突不是"试版本号"能解决的，是"理解兼容性矩阵"的问题。

第 5 种：异步时序和竞态条件

两个接口同时请求，后发的先回来，页面显示了旧数据。

你告诉 AI。AI 加了一个 loading 状态。现在页面不闪了，但数据还是错的——因为竞态的根因不在渲染层面，在请求层面。

你再告诉 AI。AI 加了一个 AbortController。但位置不对，有时候把正常请求也取消了。

你再告诉 AI。AI 加了一个请求计数器。但计数器在组件卸载时没清理，内存泄漏了。

三轮下来：一个竞态 bug → 变成竞态 + 请求取消异常 + 内存泄漏。

为什么 AI 修不好时序 bug： AI 的思维是"逐行执行"的，它天生不擅长推理"两件事同时发生会怎样"。竞态条件的修复需要理解整个异步流的时序关系，不是在某个点加一行代码。AI 的每次修复都是局部的，但时序问题本质上是全局的。

自己修： 先用 Network 面板理清请求的实际时序。竞态问题的方案通常是架构层面的（请求取消策略、乐观更新、版本号比对），不是在单个函数里打补丁。

速查表：这个 bug 该自己修还是让 AI 修？

bug 类型	让 AI 修？	理由
CSS/样式	❌ 自己修	AI 看不到级联，只会叠覆盖
跨组件状态	❌ 自己修	AI 治标不治本，越修数据流越乱
环境差异	❌ 自己修	AI 无法访问你的环境，只能猜
依赖冲突	❌ 自己修	AI 不理解兼容性矩阵
异步时序	❌ 自己修	AI 不擅长推理并发
语法错误	✅ 让 AI 修	AI 的强项，秒修
类型报错	✅ 让 AI 修	AI 很擅长 TS 类型修复
单函数逻辑	✅ 让 AI 修	输入输出明确，修得又快又好
写测试用例	✅ 让 AI 写	AI 很擅长生成边界测试
报错信息翻译	✅ 让 AI 查	比 Google 快

收藏这张表。下次 debug 前先看一眼——有些 bug 你自己 30 分钟搞定，丢给 AI 折腾半天还越修越多。

不是 AI 不好，是 debug 不是它擅长的事

AI 最擅长的是生成——给它一个清晰的需求，它写代码又快又好。

AI 最不擅长的是诊断——给它一个模糊的症状，让它找根因，它只会猜。猜错了就在猜错的方向上继续修，越修越远。

Slopfix 每周 1 万美元帮人清理 AI 代码，说明这已经不是个别现象了——AI 代码的"售后成本"正在变成一个真实的行业问题。

与其让 AI 修三轮越修越烂，不如花 30 分钟自己找到根因一次改对。

你经历过最离谱的"AI 越修越烂"是什么场景？评论区说说。

发布信息

标签： 前端 AI编程 JavaScript 代码质量 程序员 debug

话题： 每日精选文章 / 日新计划

分类： 前端

摘要： Shiplight 数据显示 AI 代码多 1.7 倍 Bug，逻辑错误多 75%。上周 Slopfix 团队靠清理 AI 代码每周收费 1 万美元上了 HN 热帖。本文整理了 5 种越让 AI 修就越烂的 bug 类型——CSS 级联、跨组件状态、环境差异、依赖冲突、异步时序——附"该自己修还是让 AI 修"速查表。

我用 AI 写代码快了 3 倍——然后同事的 Code Review 全变成了我的

193577746 — Sun, 12 Jul 2026 12:15:50 +0800

这不是一个人的故事。LeadDev 上周发了一篇文章叫"AI productivity is burning out your best engineers"，Reddit 上"谁还在帮初级开发者擦屁股"的帖子 24 小时冲上热榜。AI 在团队里制造的矛盾，比它提升的效率还大。

你以为 AI 提升的是整个团队的效率

团队开始用 AI 编程之后，理论上每个人都应该更快。

现实是：快的人变得更快，慢的人没变快——但所有人都在产出更多代码。

这意味着什么？需要 Review 的代码量暴增了，但有能力 Review 的人没变多。

一份行业数据：2024 年全球 41% 的代码由 AI 生成，相当于 2560 亿行。到 2026 年这个比例只会更高。82% 的开发者在使用 AI 编程工具。

代码在以 3 倍速度产出，但 Code Review 的速度还是人脑速度。

瓶颈转移了。

"隐形验证者"——全组最累的人

LeadDev 上周的文章给这类人起了个名字：Invisible Validator（隐形验证者）。

特征：

团队里 AI 用得最熟的那个人
写代码最快，提 PR 也最快
因为"你最懂"，所有复杂的 Code Review 都默认分给了他
因为"你最快"，其他人没做完的需求也默认排到了他身上
因为"你用 AI 写的，那你帮忙看看其他人用 AI 写的"

他的产出翻了 3 倍，他的工作量翻了 5 倍。

更扎心的是——这些额外的 Review 工作在任何管理看板上都看不到。你帮 5 个人 Review 了 20 个 PR，Dashboard 上显示的是"5 个人完成了 20 个需求"，不是"你审查了 20 个需求的每一行代码"。

功劳是团队的，疲劳是你的。

Reddit 上的真实声音

r/ExperiencedDevs 上一个几小时前的热帖标题直接就是：

"Anyone Else Sick of Getting Flooded with Slop from Junior Devs?" （有没有人也受够了被初级开发者的垃圾代码淹没？）

里面的讨论指向同一个问题：初级开发者用 AI 生成大量"看起来能跑"的代码，但资深开发者需要花更多时间去 Review、去找隐藏的问题。

另一个帖子里有人写：

"AI has removed the majority of the 15% of my job that I found most satisfying." （AI 把我工作中最满足的那 15% 拿走了。）

他说的是那种亲手写完一段精巧代码的成就感——现在 AI 三秒就写完了，他的工作变成了审查 AI 写的代码、修 AI 留下的坑。

从"写代码的人"变成"检查 AI 写的代码的人"。角色变了，但没人调整过预期。

6000 人调查：团队正在被 AI 撕成两半

Lenny's Newsletter 引用了一份 6000 名技术从业者的调查，结论是：

"The workforce is bifurcating." （劳动力正在两极分化。）

一半人觉得 AI 赋予了超能力——效率飞升，工作更有趣。

另一半人觉得自己在被淘汰——AI 做了他们的活，但他们既不会用 AI，也没有被重新分配到更有价值的事情上。

但文章里最扎心的一句话是：

"The fastest way to end up with resentment on your team is to pocket the productivity and turn saved time into more work for them." （让团队产生怨恨的最快方式，就是把 AI 节省的时间全部变成更多的工作量。）

这正是大多数团队正在做的事：AI 让你快了 3 倍，那就给你 3 倍的需求。

效率提升被管理层全部吃掉了。你没有更轻松，你只是在相同的时间里做了更多的事——直到你崩溃。

为什么"最快的人"最先想走

把上面的现象串起来，逻辑就清楚了：

第一步： 团队开始用 AI，你是最先适应的那个人。

第二步： 你的产出翻了 3 倍，领导很满意，给你分更多需求。

第三步： 其他人也开始用 AI 写代码，但质量参差不齐。你被要求帮忙 Review。

第四步： 你变成了全组的"AI 代码质检员"——别人写的代码你要看，你自己还有 3 倍的需求要做。

第五步： 年中评审，所有人的产出都上去了（因为你帮他们兜底了），你的"成长"反而不突出——因为你做的事在看板上看不见。

第六步： 你开始想，是不是该换个组了。

这不是假设。Stack Overflow 博客今年 3 月发了一篇文章叫"AI is becoming a second brain at the expense of your first one"——AI 在成为你的第二大脑的同时，正在消耗你的第一大脑。

你的团队踩了几个

症状	说明	你中了吗
Review 集中到 1-2 个人身上	因为"他们最懂"	⬜
AI 节省的时间全部变成了新需求	没有留出学习/重构时间	⬜
初级开发产出暴增但 Bug 率也暴增	AI 代码"能跑"但不健壮	⬜
资深开发越来越沉默	从"带团队"变成了"擦屁股"	⬜
效率最高的人反而考虑离职	功劳被均摊，疲劳没人看到	⬜
团队氛围从协作变成了割裂	会用 AI 的 vs 不会用的	⬜

中 3 个以上，你的团队已经在 AI 效率陷阱里了。

怎么办

这不是"不要用 AI"——AI 确实提升了效率，这是事实。

问题出在团队没有调整分工模型，还在用 AI 之前的管理方式管理 AI 之后的团队。

如果你是那个"最快的人"：

让隐形工作可见。Review 数量、Review 发现的问题数、帮其他人解决的阻塞——写进周报、写进 1:1。不自己说出来，没人知道。
拒绝"因为你最快所以你来"的逻辑。所有人都该学会 Review AI 代码，不只是你。
设定 Review 上限。每天最多 Review 3 个 PR，超出的排队。不设上限就是无限兜底。

如果你是 Tech Lead 或管理者：

不要把 AI 节省的时间 100% 转化成新需求。至少留 20% 给技术债、学习、工具建设。
Review 负载均衡。GitHub 的 CODEOWNERS 可以按目录轮换，不要让一个人扛所有模块。
承认"验证"是一种产出。写代码是产出，确保代码质量也是产出。别让 Review 变成"义务劳动"。

最后

AI 让写代码变快了。但写代码从来不是软件开发最难的部分。

最难的部分是确保代码是对的、是安全的、是可维护的。 这些事 AI 做不了，但很多团队假装它能做。

结果就是——最有能力确保代码质量的人，变成了最先被耗尽的人。

你的团队里有没有这样的"隐形验证者"？或者你自己就是？评论区说说。

我同时用了 Claude Code、Cursor 和 Codex，说说三个工具的真实差距——2026 年选错工具比不用 AI 更浪费时间

193577746 — Tue, 07 Jul 2026 20:23:47 +0800

这三个工具我都在正式项目里深度用过：Cursor 从 Tab 补全一路用到 Agent 模式；Codex 从 CLI 到 Web 云端并行都跑过完整项目；Claude Code 是我现在每天的主力。网上很多对比文章还停留在"Cursor = 补全神器"的旧印象，或者直接搬 SWE-bench 跑分。这篇不比 Benchmark，只说 2026 年我在真实项目里踩出来的差距。

先纠正一个过时认知：三个都是 Agent，区别在"协作姿势"

2025 年下半年开始，这三个工具其实都走上了 Agent 化路线，谁也不比谁"低一档"。真正的差别不是能力上限，而是你和它协作的姿势不一样：

工具	定位	协作姿势
Cursor	IDE 原生 Agent	你在驾驶座，AI 随时切换副驾/自动驾驶
Claude Code	终端 Agent + IDE 插件	你派活给一个能自己跑完全流程的同事
Codex	云端异步 Agent	你下工单给一个并行团队，回头收货

关键变化：Cursor 有了 Agent 模式和 Background Agents，Claude Code 出了 VS Code / JetBrains 插件和 Web 版，Codex 有了 CLI 也有了 Web。三个工具的功能边界正在互相渗透，但核心工作流的哲学没变。

Cursor：不再只是补全，Agent 模式让它成了"IDE 里的全能选手"

如果你还觉得 Cursor 只是 "带 AI 的 VS Code"，那你至少落后了半年。2026 年的 Cursor 已经是四种模式并存：

模式	能力	适用场景
Tab（预测式补全）	猜你下一步要改哪、要写啥	日常敲代码，最丝滑
Composer / Inline Edit	多文件同步修改	中等范围重构
Agent 模式	自动读代码、跑命令、改文件、验证	完整功能开发
Background Agents	云端异步执行任务	后台批量跑活

Cursor 现在最爽的场景：

场景	体验
日常写业务代码	Tab 补全的准确率业内第一档，几乎不用改
"重写这段逻辑"	Inline Edit 原地替换，即改即看
"实现登录模块"	Agent 模式自己读现有代码、跑 dev server 验证
调 UI/CSS	所见即所得，实时预览
Bugbot 自动 review	PR 提交后自动扫，指出潜在 Bug

依旧不适合的场景：

场景	原因
纯终端工作流（CI/脚本/服务器）	它的强项是 IDE 内，脱离编辑器体验骤降
需要跨多个仓库协同	Workspace 支持不如终端类工具灵活

一句话：Cursor 适合"你以写代码为主，需要 AI 从补全到 Agent 全档位随时切换"。

Claude Code：终端 Agent 的天花板，也有 IDE 插件了

Claude Code 的哲学没变——它跑在终端里，把你的整个工作目录当成"工位"，能读代码、跑命令、操作 Git、调 MCP 工具。但 2026 年它多了几张牌：

新增能力（很多人还不知道）：

能力	说明
Skills	可复用的"技能包"，像给 Agent 加插件
Subagents	派生子 Agent 并行做研究、审查
Hooks	特定事件自动触发命令（如提交前跑 lint）
Plan Mode	先出方案再动手，避免它一头扎进去
Memory	跨会话记住你的偏好和项目上下文
VS Code / JetBrains 插件	不想开终端也能用
Web 版（claude.ai/code）	浏览器里跑 Agent
Fast Mode（Opus 4.6）	追求速度时可切换

用起来最爽的场景：

场景	体验
"加一个完整功能模块"	Plan 一次、执行一次，端到端搞定
Debug 玄学问题	会自己翻日志、grep、跑测试复现
大范围重构（20+ 文件）	全局理解能力最强
复杂 CI/DevOps 脚本	终端原生优势
多仓库联动	直接切换目录操作

不适合的场景：

场景	原因
每行都想精细控制	它倾向大块交付，逐行微调不如 Cursor
纯 UI 视觉微调	没有实时预览

一句话：Claude Code 适合"你说清楚要什么，剩下的从设计到验证全交给它"。

Codex：云端异步的王者，本地 CLI 也补齐了

Codex 现在是双形态：Codex CLI（本地终端）+ Codex Web（云端异步）。跑在 GPT-5 Codex 模型上，云端能同时开几十个任务并行。

最爽的场景：

场景	体验
一次派 10 个任务	云端并行跑，你只管收 PR
大规模体力活（如 TS 迁移）	拆成 N 个子任务批量丢
PR 自动 Review	挂到仓库上，每个 PR 都过一遍
开会时不想停工	会前下单，会后收货
跨时区协作	睡觉时也在干活

不适合的场景：

场景	原因
需要实时反馈的探索性开发	异步节奏打断心流
需要你频繁修正方向	每轮等待成本高
想看到"思考过程"	相对黑盒，只看最终结果

一句话：Codex 适合"你不想盯着，把任务当工单批量下发"。

2026 年选择速查表（更新版）

你的场景	首选	备选	原因
日常敲业务代码	Cursor Tab	Claude Code IDE 插件	补全丝滑
中等范围功能开发	Cursor Agent	Claude Code	IDE 内闭环
大范围重构（20+ 文件）	Claude Code	Cursor Agent	全局理解
复杂 Debug / 排障	Claude Code	Cursor Agent	终端原生
调 UI / CSS	Cursor	—	所见即所得
批量体力活	Codex Web	Cursor Background	并行最强
PR 自动 Review	Codex	Cursor Bugbot	云端异步
开会/睡觉时跑任务	Codex Web	Cursor Background Agent	真异步
DevOps / CI 脚本	Claude Code	—	终端为王
探索性技术方案	Claude Code Plan Mode	Cursor Agent	先谋后动

我现在的组合用法（2026 版）

没有"用哪个"，只有"什么时候用哪个"。 我的日常搭配：

时段/场景	用什么	为什么
早上梳理架构 / 出方案	Claude Code Plan Mode	想清楚再动手
白天写业务代码	Cursor Tab + Agent	IDE 内最快
排 Bug / 查日志	Claude Code	终端能力全开
批量重复任务	Codex Web	丢过去开会
调样式细节	Cursor	实时预览
PR Review	Codex + Cursor Bugbot 双保险	云端异步不打断
跨仓库操作	Claude Code	终端切目录方便

三个常见的选型误区

误区一：还以为 Cursor 只能补全 Cursor Agent 模式和 Background Agents 已经能独立完成中大型任务，只在 IDE 里用它 Tab 是浪费。

误区二：觉得 Claude Code 就是命令行小工具 它现在有 VS Code / JetBrains 插件、Web 版、Skills、Subagents、Hooks——是一整套 Agent 平台。

误区三：觉得 Codex 慢所以不好用 异步不是缺点，是特性。你需要的不是"更快的对话"，而是"下班时代码在跑"。

最后

2026 年 AI 编程工具的问题早就不是"用不用"，也不是"哪个最强"，而是你会不会根据场景切换。

三种最典型的浪费：

一个工具打天下——用 Cursor 做多仓库 DevOps，或者用 Claude Code 调 CSS
只用旧功能——买了 Cursor 只按 Tab，装了 Claude Code 只做单文件改动
跟风换工具——听说 Codex 出新版就把其他都卸了，结果异步不适合自己

选工具和选框架一样：不是选"最强的"，是选"和当前任务最匹配的"。

你现在主力用哪个？评论区聊聊你的搭配方式，尤其想听听有没有把 Cursor Background Agent 和 Codex 一起用的玩法。

Godot 全面封杀 Vibe Coding，作为每天用 AI 写代码的人，我反而觉得这是件好事

193577746 — Mon, 06 Jul 2026 18:58:55 +0800

上周 Godot（用户量很大的开源游戏引擎）更新贡献政策：全面禁止 AI 代理直接提交代码，违者永久禁止访问仓库。我每天都在用 Claude Code 写代码，看到这新闻第一反应不是"AI 又被针对了"，而是"这规则说的正是我一直担心的问题"。

Godot 具体做了什么

规则	内容
禁止 AI 代理直接提交	违者永久禁止访问，最严厉的处罚
新贡献者门槛	合并 PR≤3 个的用户有额外限制
强制人工审核	任何 PR 必须真人审核批准才能合并

原因： 大量 AI 生成的低质量 PR 涌入，维护者审查负担暴增，还引发代码质量和责任归属争议——AI 代码出问题算谁的？

不是个例，是趋势

开发者圈流行一个新词——Vibe Slop（氛围垃圾代码）：看起来能跑，但没人真正理解、也没人愿意负责的 AI 生成代码。

维护者的困境：审查人写的代码能判断意图，审查 AI 生成的代码，提交者自己可能都不知道在干什么。

PR 数量暴增但质量下降，维护成本不降反升。

我怎么看

Vibe Coding 适合"你自己负责"的场景，不适合"你要说服别人相信"的场景。

场景	是否合适
自己项目自己维护	✅ 出问题自己扛
给团队提 PR	⚠️ 同事需要理解你的代码
给开源项目提 PR	❌ 把责任甩给维护者
一次性脚本	✅ 低风险

Godot 针对的是最后一种极端——用 AI 生成代码，自己不审查就直接提 PR，把"理解代码"的责任甩给别人。

AI 辅助 vs AI 甩锅

AI 辅助（我依然负责）： 生成初稿，逐行看过理解调整，不确定的地方会验证

AI 甩锅（不再负责）： AI 生成什么就是什么没 Review，出问题第一反应是"这是 AI 写的"

Godot 这次本质是强制大家从"甩锅模式"切回"辅助模式"。

自查清单

[ ] 提交前，能不能对每一行给出理由？
[ ] 同事问"为什么这样写"，不查 AI 记录能答上来吗？
[ ] 真正 Review 过还是看起来能跑就提交了？
[ ] 出 bug 能独立排查，还是重新问 AI？

两个以上答不上来，说明正在从"AI 辅助"滑向"AI 甩锅"。

Vibe Coding 本身没错，错的是把"我不需要理解"也一起 Vibe 掉了。

你怎么看这次的政策？会不会逐行 Review AI 代码？评论区聊聊。

觉得有用？点个赞 👍 让更多人看到

关注我，获取更多技术干货。

朋友最近面了 3 家公司，发现 2026 年前端面试完全变了——不考手写题了，考的全是这些

193577746 — Sun, 05 Jul 2026 22:26:26 +0800

一个关系不错的前端朋友最近在看机会，前后面了三家公司。他之前准备面试还是老一套——背八股文、刷手写题。结果三家公司没有一家让他手写代码。他跟我吐槽的时候我才意识到，面试的考法已经彻底变了。这篇把他三家公司的面试流程和考察重点整理出来，给最近也在看机会的人一个参考。

第一家：中型 SaaS 公司，前端 4 人团队

面试流程： 一面技术面 1 小时 + 二面技术 Leader 1 小时 + 三面 HR

没考什么： 手写 Promise、闭包、原型链、虚拟 DOM 实现——这些一题都没出。

考了什么：

考察内容	具体问题	理解
AI 工具使用	"你日常用什么 AI 工具写代码？用 Claude Code 还是 Cursor？能不能现场演示一下你怎么用它做一个需求？"	不是问"会不会用"，是要看工作流
Code Review 能力	给了一段 AI 生成的代码，让他找问题。代码功能正确但有性能问题和冗余	考的是能不能判断 AI 写的代码好不好
架构设计	"如果让你从零搭一个后台管理系统，你会怎么选型？状态管理怎么做？"	考全局思维，不是考你会不会写某个组件
沟通和协作	"产品经理给了一个不合理的需求，你怎么处理？"	软技能，以前技术面很少问这个

他的感受： 面试官全程没打开编辑器让他写代码。整个面试更像是在聊"你平时怎么干活的"。

第二家：电商公司，前端 15+ 人

面试流程： 一面 coding test（但不是传统手写）+ 二面系统设计 + 三面总监面

一面很有意思： 面试官打开一个 CodeSandbox，里面有一个半成品页面——商品列表已经渲染出来了，但搜索、筛选和分页都没有。让他现场加功能，可以用任何工具，包括 AI。

和传统手写题的区别：

传统手写	这次的做法
白板上写 Promise 实现	在真实项目里加功能
考你记不记得语法	考你解决问题的效率和质量
不能用任何工具	允许用 AI、Google、任何东西
写完就结束	写完之后追问"为什么这样设计"

他用 Claude Code 生成了搜索和筛选的基础代码，然后自己改了防抖逻辑和分页的边界处理。整个过程大概 25 分钟。

重点来了： 写完之后面试官花了 20 分钟问他代码的设计决策——"为什么用 useMemo 而不是 useCallback"、"分页状态放在 URL 里还是组件 state 里，为什么"、"如果数据量从 1000 变成 10 万，你的方案会有什么问题"。

面试官不关心你写得多快，关心的是你能不能解释清楚每一个选择背后的原因。

第三家：AI 创业公司，全栈方向

面试流程： 一面技术 + 二面 CTO + 三面 CEO

最直接的一家。 CTO 开场就说："我们团队 5 个人，80% 的代码是 AI 写的。我不需要你写代码很快，我需要你能在 AI 写完之后把控质量。"

考察重点完全不同：

考察项	具体方式
Debug 能力	给了一段有 bug 的 React 组件，让他排查。bug 藏得很深——是 useEffect 依赖数组漏了一个变量导致的闭包陷阱
代码评审	给了一个 PR，让他做 Review。代码是 AI 生成的，有 3 个问题让他找
系统思维	"这个功能现在能跑，但如果并发量从 100 涨到 10000，哪里会先出问题？"
AI 协作	"你怎么给 AI 写 Prompt 让它生成的代码更可控？有没有自己的 Prompt 模板？"

CTO 的原话： "我们不缺能写代码的人，AI 能写。我们缺的是能判断代码对不对、架构合不合理的人。"

三家面试的共同点

听他讲完三家的经历，我总结了 2026 年前端面试的三个明显变化：

变化 1：手写八股文基本消失了

三家公司没有一家让他手写 Promise、闭包、原型链。不是说这些知识不重要，而是面试官觉得"你知不知道这些"已经不是区分好坏的标准了——因为 AI 能写，背八股文的意义被稀释了。

变化 2：AI 使用能力变成了显性考察项

三家公司都问了"你怎么用 AI 工具"，而且不是随便聊聊，是正式考察项。第一家让现场演示，第二家允许面试中使用 AI，第三家直接问 Prompt 模板。

变化 3："判断力"取代了"执行力"

以前面试考的是"你能不能写出来"——执行力。现在考的是"AI 写出来之后，你能不能判断对不对、好不好、该不该这样设计"——判断力。

以前的核心考点	现在的核心考点
你能不能手写出来	AI 写的代码你能不能评审
你记不记得语法	你能不能解释设计决策
执行力	判断力

对准备面试的建议

基于他这三次面试经验，如果你最近也在看机会，建议调整一下准备方向：

以前花时间	现在应该花时间
背八股文（闭包、原型链）	练习评审 AI 生成的代码——给 Claude Code 一个需求，让它写完后自己找问题
刷 LeetCode	练习系统设计——画架构图、做技术选型、评估扩展性
记 API 语法	练习"解释设计决策"——每写一个组件都想一下"为什么这样设计"
准备手写 Promise	准备 AI 工具使用经验——整理你的工作流、Prompt 模板、常用技巧

最后

2026 年的前端面试，不再考你"能不能写"，而是考你"AI 写完之后你能不能判断"。八股文不是不需要会——你还是需要理解原理才能做出正确的判断。但面试的考核方式变了，你的准备方式也应该变。

你最近面试有没有发现类似的变化？还是说你面的公司还在考手写题？ 评论区说说你的经历，想看看不同公司之间差异有多大。

别再每次都 Google 了：我整理了前端日常最常踩的 10 个 Git 坑，附速查表

193577746 — Fri, 03 Jul 2026 15:13:54 +0800

用了三年 Git，我依然每周至少 Google 两次 Git 命令。不是不会用，是有些操作一个月才遇到一次，每次都记不住。上周 merge 出了冲突，我又条件反射打开浏览器搜"git 怎么撤销 merge"——搜完之后我决定，把这些反复 Google 的操作整理成一篇速查表，以后直接查这篇。

坑 1：commit 了才发现写错了提交信息

这是我踩得最多的——手速太快，git commit -m "fix" 回车完才发现，应该写清楚改了什么。

# 改最近一次的 commit 信息（还没 push 的情况下）
git commit --amend -m "fix: 修复登录页表单验证逻辑"

注意：如果已经 push 了，amend 会改变 commit hash，再 push 需要 --force。 如果是团队协作的分支，不要 force push，改用新 commit。

坑 2：改了半天发现改错分支了

写了一小时代码，突然发现自己在 main 上改的，不是 feature 分支。

# 把当前改动暂存起来
git stash

# 切到正确的分支
git checkout feature/login

# 把暂存的改动拿出来
git stash pop

git stash 就像一个"临时口袋"，把没提交的改动先装进去，换完分支再掏出来。

坑 3：merge 冲突了不知道怎么办

这个坑不是不知道怎么解决冲突，而是解决到一半不想解决了，想撤回去。

# 取消这次 merge，回到 merge 之前的状态
git merge --abort

如果已经解决完冲突但还没 commit，想重新来过：

# 放弃所有冲突解决的改动
git checkout --conflict=merge .

坑 4：add 了不该 add 的文件

手滑 git add . 把 .env 或 node_modules 加进去了。

# 从暂存区移除，但保留本地文件
git reset HEAD .env

# 如果已经 commit 了，需要从历史中删除
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "chore: 移除误提交的 .env 文件"

预防方法：项目第一天就把 .gitignore 配好。别问我怎么知道的。

坑 5：想撤销最近一次 commit（但保留代码）

commit 之后发现漏了一个文件，或者想把两个 commit 合成一个。

# 撤销 commit，但代码改动保留在暂存区
git reset --soft HEAD~1

# 撤销 commit，代码改动保留但不在暂存区
git reset --mixed HEAD~1

# ⚠️ 撤销 commit，代码改动也丢弃（慎用！）
git reset --hard HEAD~1

三种 reset 的区别，一张图：

模式	commit	暂存区	工作目录	适用场景
`--soft`	撤销	保留	保留	想重新组织 commit
`--mixed`	撤销	清空	保留	想重新选择要 add 的文件
`--hard`	撤销	清空	清空	这次改动彻底不要了

坑 6：不小心 git reset --hard 了，代码全没了

每个人职业生涯里至少 --hard 错一次。别慌：

# 查看所有操作记录（包括已经"删掉"的 commit）
git reflog

# 找到你想恢复的那个 commit hash，然后
git reset --hard abc1234

reflog 是 Git 的"后悔药"，它记录了你所有的 HEAD 移动历史，包括 reset 掉的。只要没 git gc，30 天内都能找回来。

坑 7：想看某个文件之前的版本

不记得这个文件上周长什么样了，想对比一下。

# 看某个文件在某次 commit 时的内容
git show abc1234:src/utils/auth.js

# 对比当前版本和上一次 commit 的差异
git diff HEAD~1 -- src/utils/auth.js

# 对比两个分支之间某个文件的差异
git diff main..feature/login -- src/utils/auth.js

坑 8：想从另一个分支只拿一个 commit

不想 merge 整个分支，只想拿其中一个 commit 的改动过来。

# cherry-pick：把指定 commit 的改动应用到当前分支
git cherry-pick abc1234

常见场景：在 dev 上修了一个 bug，想把这个修复也带到 release 分支，但不想把 dev 上其他未完成的功能也带过去。

坑 9：本地分支太多，不知道哪些可以删了

开了一堆 feature/xxx 分支，合并完忘了删，git branch 列出来一屏都放不下。

# 查看哪些分支已经合并到 main（可以安全删除）
git branch --merged main

# 删除已合并的本地分支
git branch --merged main | grep -v "main" | xargs git branch -d

# 清理远程已删除但本地还有引用的分支
git fetch --prune

坑 10：push 被拒绝，提示 "non-fast-forward"

同事在你之前 push 了，你的本地落后于远程。

# 方案一：先拉再推（会产生一个 merge commit）
git pull
git push

# 方案二：rebase 后推（保持线性历史，更干净）
git pull --rebase
git push

团队约定用哪种就用哪种。 我个人偏好 --rebase，因为 git log 更干净。但有些团队觉得 merge commit 能清晰看到"谁什么时候合并了什么"。

速查表：前端 Git 日常操作一览

场景	命令	说明
改 commit 信息	`git commit --amend -m "新信息"`	未 push 时用
改错分支了	`git stash` → 切分支 → `git stash pop`	临时口袋
取消 merge	`git merge --abort`	冲突解决到一半想撤回
撤销 add	`git reset HEAD 文件名`	从暂存区移除
撤销 commit 保留代码	`git reset --soft HEAD~1`	最常用
找回 hard 删掉的代码	`git reflog` → `git reset --hard hash`	后悔药
看文件历史版本	`git show hash:文件路径`
只拿一个 commit	`git cherry-pick hash`	不 merge 整个分支
删已合并的分支	`git branch --merged main \	xargs git branch -d`
push 被拒绝	`git pull --rebase` → `git push`	保持线性历史

一个实用建议

如果你和我一样经常忘 Git 命令，在 ~/.bashrc 或 ~/.zshrc 里加几个 alias：

alias gs="git status"
alias gl="git log --oneline -10"
alias gco="git checkout"
alias gcm="git commit -m"
alias gst="git stash"
alias gsp="git stash pop"

不用记命令了，记缩写就行。

最后

Git 这东西，用了十年的人也经常 Google。不是因为难，是因为有些操作真的一个月才用一次。这篇速查表我自己也会收藏，以后忘了直接查。

你最常 Google 的 Git 命令是什么？ 评论区补充，我加到速查表里。

我用 Codex 重写了同事维护三年的代码，他没说谢谢——而是找了领导

193577746 — Thu, 02 Jul 2026 15:01:21 +0800

我以为我在帮忙，他以为我在"打脸"。AI 让重构变得太容易了，但它解决不了的，恰恰是最难的那个部分——人。

事情是这样开始的

我们组有一个内部管理后台，核心模块是一个表单引擎。这个模块是同事小张三年前搭的，从简单表单慢慢迭代到支持上百个字段、动态联动、多级嵌套的复杂系统。

三年下来，这个模块膨胀到了大几千行——一个文件。没有拆分，没有类型定义，变量命名从 data1 到 tempArr2 应有尽有。

我不是在黑小张。三年前的代码放到三年后看，谁的都一样。问题是，最近产品要加新的联动规则，我负责这个需求，改了两天——每次改完一个地方，另一个地方就莫名其妙地坏掉。

一个周末，我"手贱"了

周五下班前有点烦躁，打开 Codex，把这个文件丢了进去："帮我重构一下，拆成合理的模块结构，加上 TypeScript 类型。"

大约二十分钟，Codex 给出了完整的重构方案：一个大文件拆成 6 个模块，职责清晰，类型完善，连测试框架都搭好了。

我花了大半个周末逐行审查、补边界情况、跑通测试，然后在新结构上实现了产品要的联动规则——比原来轻松太多。

周一早上，信心满满地提了一个大 PR。

小张的反应出乎意料

我以为他会说"这下好维护多了"。

他看完 PR 沉默了大概十分钟，然后走到我工位旁边："你是不是觉得我写的代码很烂？"

我赶紧解释是因为新需求加不进去。但他的表情告诉我，解释是苍白的。

下午领导找我聊了一下，语气很明确："重构是好事，但你事先应该和小张对齐。"

小张跟领导说了三个点：

没有提前沟通：周一早上突然收到一个改了几千行的 PR
感觉被否定：三年的工作被 AI 用二十分钟"替换"了
维护成本转嫁：重构后的代码他没参与设计，但以后还是他维护

每一点都有道理。

我犯了三个错误

第一，把"技术上正确"等同于"做法正确"。

重构后的代码确实更好。但在团队里，代码不只是技术产物，还是人的产物。每一行背后都有人的时间和判断。你"优化"它的方式，暗示着你对这些投入的评价。

第二，低估了 AI 带来的"效率暴力"。

手动重构需要两周，同事不会觉得被"替代"——因为你付出了对等的时间。但 AI 让这件事变成了一个周末，这个速度本身就带着隐含的否定："你三年写的东西，AI 二十分钟就能写得更好。"

即使我没有这个意思，观感就是这样。

第三，跳过了最重要的步骤——达成共识。

重构这种大范围改动，动手前至少应该：和原作者讨论方案、让他参与设计、分阶段提交。我因为"AI 让重构太容易了"就全部跳过了。

AI 时代的协作陷阱

这件事揭示了一个深层问题：AI 改变了团队协作中一个不成文的契约。

过去，重构成本是人人平等的。花两周改别人的模块，这份投入本身就是"尊重"。但 AI 把成本降到接近零。当改变别人代码的成本趋近于零，"要不要改"和"动手改"之间的心理门槛就消失了。

我总结了一份协作备忘录：

场景	正确做法	常见错误
重构别人的模块	先讨论方案	AI 改完直接提 PR
AI 生成大量改动	拆成小 PR 逐步合入	一次性巨型 PR
发现别人代码问题	Review 中指出	自己 fork 用 AI 重写
AI 方案和同事冲突	作为另一种思路讨论	拿 AI 方案否定同事

后来怎么样了

我找小张单独聊了一次，承认做法不对。他也说模块确实该重构了，只是"被 AI 二十分钟替掉三年代码"需要消化一下。

最后方案：关掉大 PR，重新开几个小 PR，每个只改一个模块，小张全程参与 Review。整个过程花了一周多——比 AI 二十分钟慢了很多，但团队关系没受损。

有时候，慢一点才是真的快。

写在最后

AI 让写代码、重构、测试都变容易了。但它解决不了最难的部分——沟通、共识、尊重、信任。

技术能力再强，搞不定"人"的部分，在团队里就是定时炸弹。AI 放大了个体的执行力，也放大了不沟通的后果。

你有没有遇到过类似情况——好心办了"坏事"？欢迎留言聊聊。

我手写了一个 EventEmitter，面试官追问了 6 个问题——第 4 个我没答上来

193577746 — Tue, 30 Jun 2026 11:51:28 +0800

发布订阅模式是前端面试的高频手写题，但大多数人只会写一个基础版的 on / emit。面试官真正想考的不是你会不会写，而是你写完之后能不能接住追问。我上次手写完 EventEmitter 后被连续追问了 6 个问题，第 4 个关于内存泄漏的问题当场没答上来。这篇文章把完整实现和 6 个追问全部写出来，下次遇到直接拿满分。

先用 30 行写一个能用的版本

面试的时候不要上来就写"完美版"，先快速写一个核心能跑的版本，再根据面试官的追问逐步完善。

class EventEmitter {
  private events: Map<string, Set<Function>> = new Map();

  on(event: string, listener: Function) {
    if (!this.events.has(event)) {
      this.events.set(event, new Set());
    }
    this.events.get(event)!.add(listener);
    return this;
  }

  off(event: string, listener: Function) {
    this.events.get(event)?.delete(listener);
    return this;
  }

  emit(event: string, ...args: any[]) {
    this.events.get(event)?.forEach(listener => {
      listener(...args);
    });
    return this;
  }

  once(event: string, listener: Function) {
    const wrapper = (...args: any[]) => {
      listener(...args);
      this.off(event, wrapper);
    };
    this.on(event, wrapper);
    return this;
  }
}

30 行，4 个核心方法：on（订阅）、off（取消）、emit（触发）、once（只触发一次）。

为什么用 Map + Set 而不是普通对象 + 数组？

数据结构	查找/删除	去重	说明
对象 + 数组	O(n)	需手动判断	删除要 `splice`，性能差
Map + Set	O(1)	自动去重	`delete` 直接删，不用遍历

写完这个版本，面试官会满意吗？不会。追问才刚开始。

追问 1："链式调用怎么实现的？"

你可能注意到了，每个方法最后都 return this。这不是多余的——它让你可以这样写：

const emitter = new EventEmitter();

emitter
  .on('login', user => console.log(`${user} 登录了`))
  .on('logout', user => console.log(`${user} 登出了`))
  .once('firstVisit', () => console.log('首次访问'));

面试加分点： 提一句"jQuery、RxJS、Promise 都用了这个模式——叫 Fluent Interface（流式接口）"。

追问 2："once 的实现原理是什么？为什么要用 wrapper？"

once 的核心是用一个 wrapper 函数把原始 listener 包了一层：

once(event: string, listener: Function) {
  const wrapper = (...args: any[]) => {
    listener(...args);        // 先执行原始回调
    this.off(event, wrapper); // 再把 wrapper 从事件列表中删掉
  };
  this.on(event, wrapper);    // 注册的是 wrapper，不是 listener
}

为什么不能直接 this.off(event, listener)？ 因为你注册的是 wrapper，事件列表里存的也是 wrapper。如果你 off(listener)，找不到匹配项，删不掉。

追问陷阱： 面试官可能会问"如果我在 once 回调执行之前就手动 off 这个 listener，会发生什么？"

答：off(event, listener) 找不到（因为注册的是 wrapper），不会删除。要解决这个问题，需要在 wrapper 上挂一个原始引用：

once(event: string, listener: Function) {
  const wrapper = (...args: any[]) => {
    listener(...args);
    this.off(event, wrapper);
  };
  wrapper._original = listener; // 保存原始引用
  this.on(event, wrapper);
}

off(event: string, listener: Function) {
  const listeners = this.events.get(event);
  if (!listeners) return this;
  for (const fn of listeners) {
    if (fn === listener || fn._original === listener) {
      listeners.delete(fn);
      break;
    }
  }
  return this;
}

这个细节能答上来，面试官会认为你对设计模式的理解不是停留在"背代码"层面。

追问 3："emit 的时候如果 listener 抛了异常，后面的 listener 还会执行吗？"

当前实现：不会。 因为 forEach 中某个 listener 抛异常后，整个循环就中断了。

emitter.on('data', () => { throw new Error('boom'); });
emitter.on('data', () => console.log('我不会执行'));
emitter.emit('data'); // 第二个 listener 被跳过了

解决方案： 每个 listener 独立 try-catch。

emit(event: string, ...args: any[]) {
  this.events.get(event)?.forEach(listener => {
    try {
      listener(...args);
    } catch (error) {
      console.error(`Event "${event}" listener error:`, error);
    }
  });
  return this;
}

延伸： Node.js 的 EventEmitter 不会帮你 catch，它会直接抛出。如果没有监听 error 事件，进程会崩。这就是为什么 Node.js 里经常看到 emitter.on('error', handler) 这种写法——它是兜底用的。

追问 4："如果忘了 off，会不会内存泄漏？"

会。这是我当时没答上来的问题。

场景：一个 React 组件在 useEffect 里注册了事件，但组件卸载时没有 off。

// ❌ 内存泄漏
useEffect(() => {
  emitter.on('update', handleUpdate);
  // 组件卸载了，但 handleUpdate 还在 emitter 的事件列表里
  // emitter 持有 handleUpdate 的引用 → handleUpdate 持有组件闭包的引用 → 组件无法被 GC
}, []);

// ✅ 正确写法
useEffect(() => {
  emitter.on('update', handleUpdate);
  return () => emitter.off('update', handleUpdate);
}, []);

面试加分答法：

"EventEmitter 的内存泄漏本质是引用链问题：emitter → listener → 闭包 → 组件状态。解决方案有三个：

手动 off（最基本）

用 WeakRef 弱引用（进阶）

用 AbortController 统一管理生命周期（现代方案）"

如果面试官继续追问 AbortController 方案：

on(event: string, listener: Function, signal?: AbortSignal) {
  if (!this.events.has(event)) {
    this.events.set(event, new Set());
  }
  this.events.get(event)!.add(listener);

  signal?.addEventListener('abort', () => {
    this.off(event, listener);
  });

  return this;
}

// 使用
const controller = new AbortController();
emitter.on('update', handleUpdate, controller.signal);

// 组件卸载时一键取消所有事件
controller.abort();

这个 AbortController 方案和 fetch 取消请求是同一个 API，前端新标准正在往这个方向统一。

追问 5："怎么实现带命名空间的事件？"

实际项目中，事件名经常需要层级结构：user.login、user.logout、order.create。

如果要支持 emitter.emit('user.*') 触发所有 user. 开头的事件：

emit(event: string, ...args: any[]) {
  // 精确匹配
  this.events.get(event)?.forEach(fn => {
    try { fn(...args); } catch(e) { console.error(e); }
  });

  // 通配符匹配
  if (event.includes('.')) {
    const prefix = event.split('.')[0] + '.*';
    this.events.get(prefix)?.forEach(fn => {
      try { fn(...args); } catch(e) { console.error(e); }
    });
  }

  return this;
}

不需要完整实现通配符匹配，面试中说出思路就够了。

追问 6："Node.js 的 EventEmitter 和你写的有什么区别？"

特性	手写版	Node.js EventEmitter
最大监听数	无限制	默认 10 个，超过会警告（防泄漏）
错误处理	手动 try-catch	必须监听 `error` 事件，否则进程崩
`prependListener`	不支持	支持（在队列头部插入）
`eventNames()`	不支持	返回所有已注册的事件名
`listenerCount()`	不支持	返回指定事件的监听器数量
异步支持	不支持	本身是同步的，但生态有 `EventEmitter2`

答这个问题的关键是"最大监听数"。 Node.js 默认限制 10 个 listener，超过会打印警告：

MaxListenersExceededWarning: Possible EventEmitter memory leak detected.

这不是 bug，是故意的——防止你忘了 off 导致内存泄漏。可以通过 emitter.setMaxListeners(20) 调整。

完整最终版

把 6 个追问的优化点都加上：

class EventEmitter {
  private events: Map<string, Set<Function>> = new Map();
  private maxListeners: number = 10;

  on(event: string, listener: Function, signal?: AbortSignal) {
    if (!this.events.has(event)) {
      this.events.set(event, new Set());
    }
    const listeners = this.events.get(event)!;

    if (listeners.size >= this.maxListeners) {
      console.warn(`Warning: ${event} has ${listeners.size} listeners.`);
    }

    listeners.add(listener);
    signal?.addEventListener('abort', () => this.off(event, listener));
    return this;
  }

  off(event: string, listener: Function) {
    const listeners = this.events.get(event);
    if (!listeners) return this;
    for (const fn of listeners) {
      if (fn === listener || (fn as any)._original === listener) {
        listeners.delete(fn);
        break;
      }
    }
    if (listeners.size === 0) this.events.delete(event);
    return this;
  }

  emit(event: string, ...args: any[]) {
    this.events.get(event)?.forEach(fn => {
      try { fn(...args); } catch (e) { console.error(e); }
    });
    return this;
  }

  once(event: string, listener: Function) {
    const wrapper = (...args: any[]) => {
      listener(...args);
      this.off(event, wrapper);
    };
    (wrapper as any)._original = listener;
    this.on(event, wrapper);
    return this;
  }

  setMaxListeners(n: number) {
    this.maxListeners = n;
    return this;
  }

  listenerCount(event: string): number {
    return this.events.get(event)?.size ?? 0;
  }

  removeAllListeners(event?: string) {
    if (event) {
      this.events.delete(event);
    } else {
      this.events.clear();
    }
    return this;
  }
}

从 30 行的基础版到完整版，每一行新增代码都对应一个追问。面试时先写基础版，面试官追问时再逐步加——这比一上来就写完整版更能展示你的思维过程。

你面试中被手写题难住过吗？最难的是哪道？评论区聊聊。

马斯克说今年每个月都要发一个大模型，Grok 4.5 已经在内测了

193577746 — Mon, 29 Jun 2026 16:09:17 +0800

2026年6月29日，周日。本周末最大的消息：马斯克宣布 SpaceX 要月更大模型，三星砸 6480 亿美元赌芯片，GPT-5.6 开始限量放人了。

#1 马斯克：Grok 4.5 已在 SpaceX 和特斯拉内测，今年每月发一个新模型

马斯克周六在 X 上宣布，Grok 4.5 已经在 SpaceX 和特斯拉内部开启 Beta 测试，早期评测显示性能"接近甚至可能超越 Claude Opus"。更狠的是，他说 SpaceX 计划在今年剩余时间里每月发布一个全新的、从零训练的大模型。

一年前 xAI 还是个配角，现在要月更模型了。当然，马斯克画饼的本事大家都知道，能不能每月兑现是另一回事。但 SpaceX 手里有算力（Colossus 2 数据中心）、有钱（上市两周市值逼近 3 万亿），真要打起来，OpenAI 和 Anthropic 的压力会很大。

来源：财联社

#2 三星宣布未来十年投资 6480 亿美元，砸向芯片和数据中心

三星集团将在 6 月 29 日的总统府会议上正式宣布：未来十年投资 1000 万亿韩元（约 6480 亿美元），覆盖芯片、数据中心、储能电池和显示器。其中可能包括斥资约 300 万亿韩元在全罗道建一座芯片工厂。

6480 亿美元是什么概念？差不多等于韩国 GDP 的一半。三星这是在赌国运——赌芯片和算力就是未来十年的石油。上周费城半导体指数出现较大调整，三星选在这个时候放出天量投资计划，既是提振信心，也是逆周期布局。

来源：新浪财经

#3 GPT-5.6 Sol/Terra/Luna 正式开放限量预览，但仅限美国

OpenAI 周五启动了 GPT-5.6 的限量预览。三个型号：Sol（旗舰）、Terra（标准）、Luna（轻量），Terminal-Bench 得分 91.9%。但有个关键限制：仅限美国用户，而且只对一小批合作伙伴开放。

说白了，白宫的审查令还在生效。OpenAI 虽然发了模型，但发布范围被卡得很死。对国内开发者来说，短期内用不上。想体验的只能等审查期过了之后看 API 什么时候全球开放。

来源：The Hindu

#4 智元机器人 90 天从 1 万台到 1.5 万台，具身智能量产在加速

智元机器人周六发布会上，第 15000 台机器人正式下线。3 个月前刚庆祝了第 10000 台，90 天又加了 5000 台。这台编号 15000 的"精灵 G2"已经直接被送去龙旗科技的工厂产线上岗了。

国内具身智能赛道今年融资超 460 亿，七成集中在头部。智元这个量产速度如果能持续，年底可能冲到 3 万台以上。对比一下，波士顿动力做了几十年也没到这个规模。

来源：上观新闻

#5《人民日报》点名批评微短剧里的"AI 脸"：流水线精致五官，看吐了

《人民日报》锐评：微短剧中大模型生成面孔占比已超 95%，千篇一律的圆眼睛、高鼻梁、尖下巴，"精致得毫无辨识度，好看得没有任何记忆点"。上周广电总局刚发了微短剧分类分层标准，这周官媒直接开始点名批评内容质量。

这条对做 AIGC 内容的开发者是个信号：光能生成不够，审美同质化已经成为监管和舆论的靶子。接下来要么在风格差异化上下功夫，要么等着被市场淘汰。

来源：快科技

一句话点评

本周末的关键词是"加注"——马斯克要月更模型、三星砸 6480 亿、智元 90 天出 5000 台机器人。上周全球科技股刚经历了一轮调整，但头部玩家的态度很一致：越跌越投。至于谁在裸泳，下半年见分晓。

别再 console.log 了：5 个 Chrome DevTools 调试技巧，用过就回不去了

193577746 — Tue, 23 Jun 2026 21:00:13 +0800

我观察过身边的前端同事，90% 的人调试代码的方式就是一行行加 console.log。改完了再一行行删。出了 bug 再加回来。这个循环我自己也干了两年，直到有一天我发现了 Chrome DevTools 里这些"隐藏"功能——说是隐藏，其实一直都在那，只是没人告诉你怎么用。这篇文章把 5 个最实用的技巧写出来，每个都附操作步骤，看完今天就能用上。

为什么你应该少用 console.log

先说清楚：console.log 不是不能用。但它有三个致命问题：

侵入式：你得改代码、保存、刷新页面、看输出、再改代码、再删掉。一个 bug 可能要加删十几次。
信息有限：它只能告诉你"某个值是什么"，不能告诉你"这个值是从哪来的"、"调用栈是什么"、"经历了哪些状态变化"。
忘删的风险：线上代码里夹着 console.log('test') 和 console.log('到这了')，你一定在别人的项目里见过。

DevTools 的调试工具可以做到 console.log 做不到的事，而且不需要改任何一行代码。

技巧 1：条件断点 — 替代 `if (id === 5) console.log(data)`

场景

你有一个列表渲染了 100 条数据，但只有第 5 条数据有 bug。用 console.log 的话，要么打印 100 条慢慢找，要么加 if 判断：

// 你以前的做法
items.forEach(item => {
  if (item.id === 5) {
    console.log('有问题的数据:', item);
  }
  renderItem(item);
});

用条件断点

打开 DevTools → Sources 面板
找到对应代码，在行号上右键 → 选择 Add conditional breakpoint
输入条件：item.id === 5
回车确认

现在代码只会在 item.id === 5 时暂停，你可以在 Scope 面板里直接看到 item 的所有属性，不需要改任何代码。

进阶用法： 条件表达式里可以写任何 JS，包括：

// 只在数组长度异常时断住
arr.length > 100

// 只在某个属性为 null 时断住
user.profile === null

// 组合条件
item.status === 'error' && item.retryCount > 3

断点的颜色会变成橙色（普通断点是蓝色），方便你区分。

技巧 2：Logpoints — 不改代码就能打日志

场景

你想在某行代码执行时打印一些信息，但不想改代码（比如代码在 node_modules 里，或者你不想频繁保存触发热更新）。

操作步骤

Sources 面板，在行号上右键 → 选择 Add logpoint
输入要打印的内容，语法和 console.log 一样：

'用户数据:', user, '请求耗时:', Date.now() - startTime, 'ms'

回车确认，行号旁边会出现一个粉色菱形标记

代码执行到这一行时，会在 Console 面板输出你写的内容，但不会暂停执行。

和 console.log 的区别

对比项	console.log	Logpoint
需要改代码	是	否
需要保存刷新	是	否
调试完要删除	是	关掉 DevTools 自动消失
在 node_modules 里能用	不方便	可以

这是我用得最多的功能。 团队里有个同事之前遇到第三方库的 bug，加了 20 行 console.log 在 node_modules 里，调完了忘删，下一次 npm install 覆盖掉了他的调试代码，他又加了一遍。如果用 Logpoint，根本不需要碰源码。

技巧 3：Console 高级 API — 替代满屏的 console.log

大多数人只知道 console.log。但 Console API 还有这些：

console.table() — 表格展示数据

const users = [
  { id: 1, name: '张三', role: 'admin', active: true },
  { id: 2, name: '李四', role: 'user', active: false },
  { id: 3, name: '王五', role: 'user', active: true },
];

// 之前：console.log(users)  → 输出一坨折叠的对象

// 现在：
console.table(users);

输出是一个整齐的表格，列头是属性名，一目了然。还可以指定只显示某些列：

console.table(users, ['name', 'role']);

console.group() — 分组折叠

console.group('用户请求流程');
console.log('1. 发送请求');
console.log('2. 收到响应', response);
console.log('3. 更新状态');
console.groupEnd();

console.group('渲染流程');
console.log('1. 计算 diff');
console.log('2. 更新 DOM');
console.groupEnd();

输出会按组折叠，不再是一大坨混在一起的日志。用 console.groupCollapsed() 还能默认折叠。

console.time() — 精确计时

console.time('数据处理');
const result = processLargeDataset(rawData);
console.timeEnd('数据处理');
// 输出：数据处理: 142.38ms

比 Date.now() 相减更精确，而且不需要创建临时变量。

console.trace() — 打印调用栈

function updateUser(id, data) {
  console.trace('updateUser 被谁调用了');
  // ...
}

输出完整的调用链，直接告诉你这个函数是从哪个路径调进来的。排查"这个函数怎么被调了两次"的问题特别好用。

console.assert() — 条件日志

console.assert(user.age > 0, '年龄不应该小于等于0', user);

只有条件为 false 时才输出，替代 if (!xxx) console.log()。

技巧 4：Network Override — 不改后端代码调试接口

场景

后端接口返回的数据有问题，你想临时改一下返回值来测试前端逻辑。以前你可能会：

找后端同事帮忙改接口（等半天）
在前端代码里硬编码 mock 数据（改完还得删）
用 Charles/Whistle 抓包改响应（配置麻烦）

用 Network Override

DevTools → Network 面板
找到目标请求，右键 → 选择 Override content
DevTools 会让你选一个本地文件夹作为 override 目录
修改响应内容，保存

之后每次刷新页面，这个接口都会返回你修改后的内容，不需要改任何前端或后端代码。

实际案例

后端接口 /api/users 返回了 10 条数据，但你要测试"空列表"状态：

正常请求一次，Override content
把响应体改成 []
刷新页面，前端就会渲染空状态

要测试"超长数据"？把响应改成 1000 条数据。要测试"字段缺失"？删掉某个字段。

进阶：Override Headers

不只是响应体，你还可以 Override 响应头：

模拟 CORS 错误：删掉 Access-Control-Allow-Origin 头
模拟缓存策略：修改 Cache-Control 头
模拟慢网络：在 Network 面板顶部的 Throttling 选项里选 Slow 3G

技巧 5：Live Expressions — 实时监控变量

场景

你想持续观察某个变量的值变化，用 console.log 的话，每次值变化都要重新打印，Console 面板很快就被刷屏了。

操作步骤

DevTools → Console 面板
点击 Console 面板顶部的眼睛图标（Create live expression）
输入你要监控的表达式：

document.querySelectorAll('.list-item').length

这个表达式的值会实时更新，不需要你手动执行

常用监控表达式

// 监控页面上有多少 DOM 节点
document.querySelectorAll('*').length

// 监控某个全局状态
window.__STORE__.getState().user.loginStatus

// 监控页面滚动位置
Math.round(window.scrollY)

// 监控内存使用
(performance.memory.usedJSHeapSize / 1048576).toFixed(1) + 'MB'

你可以同时添加多个 Live Expression，相当于一个实时仪表盘，比反复 console.log 高效得多。

总结：场景对照表

调试场景	console.log 做法	DevTools 做法
查看某个变量值	加 `console.log(x)`	条件断点，在 Scope 面板看
在某行打印日志	改代码加 log	Logpoint，不改代码
打印数组/对象	`console.log(arr)`	`console.table(arr)`
分组打印	手动加分隔符	`console.group()`
计算耗时	`Date.now()` 相减	`console.time()`
查看调用栈	猜	`console.trace()`
修改接口返回值	Mock 或找后端	Network Override
实时监控变量	setInterval + log	Live Expression
调试 node_modules	改源码（危险）	Logpoint 或条件断点

一个实际 debug 故事

上个月我们项目有个 bug：列表页的分页组件在第 3 页之后会显示错误的总数。

如果用 console.log 调试，我得：

在分页组件里加 log，打印 total 值 → 值是对的
在请求函数里加 log，打印响应数据 → 数据也是对的
在状态管理里加 log，打印 store → 也是对的
困惑，加更多 log...

我实际的做法：

用 Network Override 把第 3 页的接口响应 total 改成一个特殊值（比如 999）
页面显示 999 → 说明组件渲染逻辑没问题，数据能正确传到 UI
去掉 Override，用 条件断点 在状态更新的地方设 page === 3 的条件
断住后在 Scope 面板发现：第 3 页请求回来时，有一个竞态条件——第 2 页的请求比第 3 页晚到达，把 total 覆盖成了第 2 页的值

从发现 bug 到定位根因：12 分钟。 如果用 console.log 大法，光加 log 删 log 就得半小时。

快捷键速查

操作	Mac	Windows
打开 DevTools	`Cmd + Option + I`	`F12`
打开 Command Menu	`Cmd + Shift + P`	`Ctrl + Shift + P`
搜索文件	`Cmd + P`	`Ctrl + P`
搜索代码	`Cmd + Option + F`	`Ctrl + Shift + F`
切换面板	`Cmd + ]` / `Cmd + [`	`Ctrl + ]` / `Ctrl + [`
暂停/继续执行	`F8`	`F8`
单步执行	`F10`	`F10`
进入函数	`F11`	`F11`

在 Command Menu（Cmd + Shift + P）里输入 "logpoint" 或 "override" 可以快速找到对应功能。

如果对你有帮助，点赞收藏一下。这些技巧我自己每天都在用，确实比 console.log 效率高很多。如果你有其他 DevTools 的隐藏技巧，评论区分享一下。

AI 生成的代码能跑就行？这 5 个坑迟早炸

193577746 — Mon, 22 Jun 2026 18:36:40 +0800

AI 写代码的效率毋庸置疑，但"能跑"和"能维护"之间隔了一道鸿沟。这篇文章总结了 AI 生成代码最常见的 5 个质量问题，每个都附反面案例和修复方案，最后给出一份 5 条验收 checklist。

2026 年了，AI 写代码已经不是新鲜事。但我发现一个普遍现象：很多人的工作流是——

让 AI 生成代码
能跑就提交
出了 bug 再让 AI 修

这个循环看似高效，实际上在代码仓库里埋了一堆定时炸弹。下面是我 review AI 代码时反复遇到的 5 个问题，从高频到低频排列。

第一坑：过度工程化——3 行能解决的事写了 30 行

AI 特别喜欢上设计模式。你让它写一个"判断用户是否登录"的函数，它能给你整出工厂模式 + 策略模式 + 抽象基类：

// AuthStrategyFactory.js
class AuthStrategyFactory {
  static createStrategy(type) {
    const strategies = {
      jwt: new JwtAuthStrategy(),
      session: new SessionAuthStrategy(),
      oauth: new OAuthStrategy(),
    };
    return strategies[type] || new JwtAuthStrategy();
  }
}

// JwtAuthStrategy.js
class JwtAuthStrategy extends BaseAuthStrategy {
  validate(context) {
    const token = context.getToken();
    const decoder = new TokenDecoder(this.config);
    const result = decoder.decode(token);
    if (!result.isValid) {
      return AuthResult.failure(AuthErrorCode.INVALID_TOKEN);
    }
    return AuthResult.success(result.payload);
  }
}

// 另外还有：BaseAuthStrategy.js、TokenDecoder.js、AuthResult.js、AuthErrorCode.js

6 个文件，200 多行，就为了判断用户有没有登录。而这个项目从头到尾只用了 JWT 一种方式，不可能有 session 和 OAuth。

实际需要的代码：

export function checkAuth() {
  const token = localStorage.getItem('token');
  if (!token) {
    window.location.href = '/login';
    return false;
  }
  try {
    const payload = JSON.parse(atob(token.split('.')[1]));
    return payload.exp * 1000 > Date.now();
  } catch {
    localStorage.removeItem('token');
    window.location.href = '/login';
    return false;
  }
}

一个文件，15 行，功能完全一样。

为什么会这样： AI 倾向于"展示它知道的所有设计模式"，而不是"用最简单的方式解决问题"。它没有偷懒的本能，而偷懒有时候是好事——逼你写出最简方案。

怎么防： 拿到 AI 代码先问自己——"删掉一半代码还能跑吗？"如果能，那删掉的就是过度设计。

第二坑：幽灵代码——大量函数从未被调用

让 AI 写一个"订单模块的工具函数"，它会把所有它能想到的都给你：

// utils/orderHelpers.js

export function calculateOrderDiscount(order, discountRules, userLevel) {
  // ... 45 行折扣计算逻辑
}

export function formatOrderForExport(orders, format = 'csv') {
  // ... 60 行导出格式化逻辑
}

export function validateOrderTransition(currentStatus, targetStatus) {
  // ... 30 行状态机校验
}

写得都挺好，逻辑也对。但问题是——项目根本没有折扣功能，没有导出功能，状态机也没用到。

这些就是"幽灵代码"：活在仓库里，从未被执行，但你维护的时候会把它们当成有用的代码去读、去理解。实际有效代码 5000 行的模块，可能躺了 3000 行死代码。

为什么会这样： AI 不知道 YAGNI（You Ain't Gonna Need It）。它基于"这个场景可能需要什么"生成代码，而不是"现在到底需要什么"。

怎么防： 前端用 knip 检测，比 depcheck 更准：

npx knip --include exports

一条命令揪出所有未被使用的导出函数、类型、组件。

第三坑：假注释——注释和代码说的不是同一件事

这个坑最阴，因为你只看注释的话，逻辑是通的：

// 检查用户是否有该订单的操作权限
async function checkOrderPermission(userId, orderId) {
  const order = await db.orders.findById(orderId);
  const formattedOrder = {
    ...order,
    createdAt: dayjs(order.createdAt).format('YYYY-MM-DD'),
    updatedAt: dayjs(order.updatedAt).format('YYYY-MM-DD'),
    items: order.items.map(item => ({
      ...item,
      price: (item.price / 100).toFixed(2),
    })),
  };
  return formattedOrder;
}

注释说"检查权限"，代码在做数据格式化。返回值不是 boolean，是一个格式化后的对象。

调用方写成了这样：

const order = await checkOrderPermission(userId, orderId);
if (!order) throw new Error('无权限');

恰好，当 orderId 不存在时 findById 返回 null，!null === true，所以"权限检查"碰巧能跑。纯属巧合。

为什么会这样： AI 先生成了一个权限检查函数，后来被要求加数据格式化逻辑，改了函数体但没改函数名和注释。这种"假注释"比没注释更危险——没注释你会认真读代码，有注释你会下意识信任它，跳过代码。

怎么防： 好的代码不需要注释。与其修注释，不如改函数名——checkOrderPermission 改成 formatOrderForDisplay，删掉注释，可读性反而更高。

第四坑：万能 try-catch——出了 bug 永远定位不到

AI 特别喜欢给每个函数都包一层 try-catch：

async function createOrder(params) {
  try {
    const validated = validateParams(params);
    const order = await db.orders.create(validated);
    await notifyUser(order);
    await updateInventory(order);
    return order;
  } catch (error) {
    console.log('Error in createOrder:', error);
    return null;
  }
}

async function validateParams(params) {
  try {
    // ... 校验逻辑
  } catch (error) {
    console.log('Error in validateParams:', error);
    return null;
  }
}

每一层都默默吞掉错误，打个 console.log 就完事。

结果：线上出 bug，Sentry 里只有 "Error in createOrder: null"。是创建失败了？通知失败了？库存扣减失败了？你不知道。所有上下文都被 catch 吃掉了。

更要命的是 return null。调用方拿到 null 以为"没有订单"，继续往下跑，导致后面一连串空指针。一个本该在源头暴露的错误，被层层掩盖，最后在距离原始问题八百里远的地方炸出来。

正确做法：错误冒泡，只在边界捕获。

async function createOrder(params) {
  const validated = validateParams(params); // 校验失败直接抛
  const order = await db.orders.create(validated); // 数据库错误直接抛

  // 只有不影响主流程的旁路操作才 try-catch
  try {
    await notifyUser(order);
  } catch (error) {
    logger.warn('通知发送失败，不影响订单创建', { orderId: order.id, error });
  }

  return order;
}

为什么会这样： AI 出于"安全感"给每个函数加 try-catch——它不想让任何错误导致程序崩溃。但过度防御恰恰让 debug 变成噩梦。错误处理不是越多越好，是在正确的位置处理。

第五坑：data、data2、data3——变量名丢失业务语义

这个问题随处可见：

async function handleSubmit() {
  const data = await fetchData();
  const data2 = processData(data);
  const data3 = data2.filter(item => item.status === 'active');
  const result = await submitData(data3);

  if (result.code === 0) {
    const data4 = result.data;
    setList(data4);
  }
}

读到 data3 的时候你已经忘了 data 是什么了。对比一下：

async function handleSubmit() {
  const allOrders = await fetchOrders();
  const formattedOrders = formatForDisplay(allOrders);
  const activeOrders = formattedOrders.filter(order => order.status === 'active');
  const submitResult = await submitOrders(activeOrders);

  if (submitResult.code === 0) {
    setOrderList(submitResult.data);
  }
}

一眼就知道每一步在做什么。

另一个变种更常见：

const res = await api.get('/orders');
const res2 = await api.get('/users');
const res3 = await api.get(`/orders/${res.data[0].id}/items`);

三个完全不同的接口，返回值都叫 res。改 bug 的时候搜 res，搜出来 47 个结果，祝你好运。

为什么会这样： AI 在生成整段代码时倾向于用通用名词。data 是最安全的命名——不会出错，但也不传达任何信息。它没有你的业务上下文，不知道 data 其实是"订单列表"。

怎么防： AI 生成代码后，第一件事搜 data、res、result、temp、item，全部改成业务名词。

AI 代码验收 Checklist

以上 5 个坑归结起来，就是一句话：AI 的代码和实习生的代码一样，能跑但需要 review。

每次 AI 生成代码后，花 5 分钟过一遍：

#	检查项	怎么查
1	删减测试	删掉一半代码还能跑吗？能跑的就是过度设计
2	死代码检测	跑 `npx knip --include exports`
3	注释一致性	每条注释和代码对一下，不确定就删注释
4	错误处理	搜 `catch`，是不是只有 `console.log`？该冒泡还是该吞？
5	命名审查	搜 `data`/`res`/`result`/`temp`，全改成业务名词

5 分钟能省你三天的 debug 时间。

你在 review AI 代码时踩到过什么坑？评论区聊聊。

2026 年了，这 6 个 npm 包可以卸载了——浏览器原生 API 已经能替代

193577746 — Sun, 21 Jun 2026 12:32:36 +0800

前几天我跑了一下 npx depcheck，发现项目里有 47 个依赖，其中至少 6 个完全可以用浏览器原生 API 替代。卸载之后，打包体积直接少了 82KB（gzip 后少了 23KB），首屏加载快了 300ms。这篇文章把每个包的原生替代方案都写出来，附迁移代码，直接抄。

为什么要清理依赖

每多一个 npm 包，你的项目就多了：

打包体积：用户每次访问都要多下载这些代码
供应链风险：还记得 event-stream 投毒事件吗？依赖越少，攻击面越小
版本冲突：包 A 依赖 lodash@4，包 B 依赖 lodash@3，解决冲突的时间比写代码还长

2026 年的浏览器已经非常强大了。很多你以为"必须装包"的功能，原生 API 早就支持了。

1. 卸载 `lodash.cloneDeep` → 用 `structuredClone()`

之前：

npm install lodash.cloneDeep   # 5.3KB gzip

import cloneDeep from 'lodash.cloneDeep';

const copy = cloneDeep(complexObject);

现在：

const copy = structuredClone(complexObject);

完了。一行，零依赖。

structuredClone 是浏览器原生的深拷贝方法，支持 Map、Set、Date、RegExp、ArrayBuffer、循环引用——这些 JSON.parse(JSON.stringify()) 做不到的，它全能做。

兼容性： Chrome 98+、Firefox 94+、Safari 15.4+，2026 年你不需要担心兼容性。

唯一限制： 不支持拷贝 DOM 节点和函数。如果你的对象里有函数属性，这个方案不适用。但说实话，你的数据对象里不应该有函数。

能省多少： lodash.cloneDeep 单独引入约 5.3KB gzip，卸载后直接省掉。

2. 卸载 `uuid` → 用 `crypto.randomUUID()`

之前：

npm install uuid   # 2.7KB gzip

import { v4 as uuidv4 } from 'uuid';

const id = uuidv4(); // 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

现在：

const id = crypto.randomUUID(); // 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

输出格式完全一样，都是标准的 UUID v4。

兼容性： Chrome 92+、Firefox 95+、Safari 15.4+，全线支持。

Node.js 也支持： Node 19+ 内置 crypto.randomUUID()，前后端通吃。

如果你只需要一个唯一 ID 而不需要严格的 UUID 格式，还有更轻量的方案：

const simpleId = Math.random().toString(36).slice(2, 11);
// '5x3g7k9m2'

3. 卸载 `dayjs` / `moment` → 用 `Intl.DateTimeFormat` + `Temporal`

这个是最重磅的。moment.js 光 gzip 就 72KB，dayjs 虽然轻（2KB），但大多数场景你连 2KB 都不需要。

场景一：格式化日期显示

// 之前：dayjs
import dayjs from 'dayjs';
dayjs(date).format('YYYY年MM月DD日');

// 现在：原生 Intl
new Intl.DateTimeFormat('zh-CN', {
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
}).format(date);
// '2026/06/21'

场景二：相对时间（"3 小时前"）

// 之前：dayjs + relativeTime 插件
import dayjs from 'dayjs';
import relativeTime from 'dayjs/plugin/relativeTime';
dayjs.extend(relativeTime);
dayjs(date).fromNow();

// 现在：原生 Intl.RelativeTimeFormat
const rtf = new Intl.RelativeTimeFormat('zh-CN', { numeric: 'auto' });
rtf.format(-3, 'hour');  // '3小时前'
rtf.format(-1, 'day');   // '昨天'
rtf.format(2, 'month');  // '后2个月'

场景三：日期计算

// 之前
dayjs().add(7, 'day').toDate();

// 现在：Temporal API（2026 年主流浏览器已支持）
const now = Temporal.Now.plainDateISO();
const nextWeek = now.add({ days: 7 });
console.log(nextWeek.toString()); // '2026-06-28'

什么时候还需要 dayjs： 如果你要做大量复杂的时区转换、日历系统切换（农历之类），dayjs 的插件生态还是有价值的。但如果只是格式化显示和简单计算，原生足够了。

4. 卸载 `classnames` / `clsx` → 用模板字符串

之前：

npm install classnames   # 0.6KB gzip

import cn from 'classnames';

<div className={cn('btn', {
  'btn-primary': isPrimary,
  'btn-disabled': isDisabled,
  'btn-large': size === 'large'
})} />

现在：

<div className={[
  'btn',
  isPrimary && 'btn-primary',
  isDisabled && 'btn-disabled',
  size === 'large' && 'btn-large',
].filter(Boolean).join(' ')} />

如果你觉得 filter(Boolean).join(' ') 写起来啰嗦，封装一个两行的工具函数：

const cn = (...args) => args.filter(Boolean).join(' ');

// 用法完全一样
<div className={cn(
  'btn',
  isPrimary && 'btn-primary',
  isDisabled && 'btn-disabled',
)} />

2 行代码替代一个 npm 包。

更好的方案： 如果项目用了 Tailwind CSS，tailwind-merge 比 classnames 更合适，因为它能处理 Tailwind 的类名冲突（比如同时写了 p-2 和 p-4）。这种场景下原生方案做不到。

5. 卸载 `node-fetch` → 用原生 `fetch`

之前（Node.js 环境）：

npm install node-fetch   # 8.4KB gzip

import fetch from 'node-fetch';
const res = await fetch('https://api.example.com/data');

现在：

const res = await fetch('https://api.example.com/data');

Node.js 18+ 内置了 fetch，不需要再装 node-fetch。2026 年还在装这个包，大概率是因为 package.json 里一直没清理。

注意： 如果你的 Node.js 版本低于 18，还是需要 node-fetch。但 2026 年了，Node 18 已经是 EOL，你至少应该在 Node 20+ 上。

6. 卸载 `qs` → 用 `URLSearchParams`

之前：

npm install qs   # 6.2KB gzip

import qs from 'qs';

// 序列化
const query = qs.stringify({ page: 1, size: 20, keyword: '前端' });
// 'page=1&size=20&keyword=%E5%89%8D%E7%AB%AF'

// 解析
const params = qs.parse('page=1&size=20');
// { page: '1', size: '20' }

现在：

// 序列化
const query = new URLSearchParams({ page: 1, size: 20, keyword: '前端' }).toString();
// 'page=1&size=20&keyword=%E5%89%8D%E7%AB%AF'

// 解析
const params = Object.fromEntries(new URLSearchParams('page=1&size=20'));
// { page: '1', size: '20' }

唯一限制： URLSearchParams 不支持嵌套对象和数组的序列化。如果你的查询参数是 { filter: { status: ['active', 'pending'] } } 这种结构，还是需要 qs。但大多数前端场景的查询参数都是扁平的 key-value。

实操：怎么找出项目里可以卸载的包

第一步：找出未使用的依赖

npx depcheck

它会列出 package.json 里声明了但代码里从未 import 的包，直接删。

第二步：分析打包体积

npx vite-bundle-visualizer
# 或 webpack 项目
npx webpack-bundle-analyzer

看看哪些包占了大头。通常 moment、lodash 完整包是体积杀手。

第三步：逐个替换

按本文方案替换后，跑一遍测试，确认功能正常再发版。

总结对照表

npm 包	gzip 体积	原生替代	限制
lodash.cloneDeep	5.3KB	`structuredClone()`	不支持函数和 DOM
uuid	2.7KB	`crypto.randomUUID()`	无
dayjs	2KB	`Intl` + `Temporal`	复杂时区场景不够用
classnames	0.6KB	`filter(Boolean).join(' ')`	无
node-fetch	8.4KB	原生 `fetch` (Node 18+)	需要 Node 18+
qs	6.2KB	`URLSearchParams`	不支持嵌套对象
合计	~25KB	0KB	—

25KB gzip 看起来不多，但在移动端弱网环境下，这就是 200-500ms 的加载时间差距。

更重要的是：少一个依赖，就少一个供应链攻击的入口，少一个版本冲突的可能，少一个 npm audit 的告警。

如果你的项目里还有其他可以用原生 API 替代的包，评论区说一下，我补充进来。点赞收藏一下，下次 Code Review 看到同事装多余的包，直接把这篇甩给他。

同事每天催我 Code Review，我写了个脚本让 AI 替我 review PR——现在他反过来催 AI 了

193577746 — Sat, 20 Jun 2026 12:31:23 +0800

先说结论：用 GitHub Actions + Claude API 实现全自动 PR review，配置一次，以后每个 PR 推上去，AI 10 秒内给出详细评审意见，覆盖代码质量、潜在 bug、安全风险三个维度。这篇文章把完整配置都给你，拿走直接用。

背景：CR 慢是前端团队的通病

我们团队有个不成文的规定：PR 提上去，要在 1 个工作日内完成 review。

听起来很合理，但实际情况是这样的：

早上刚到公司，打开 GitHub，待 review 的 PR 已经排了 6 个
每个 PR 少则 200 行，多则 800 行
还有自己的需求要写
还有各种会

于是每天我的 review 质量是这样的：

上午的 PR：认真看，写评论
下午的 PR：大概扫一下
晚上的 PR：approve，👍

然后有一天，同事 A 在群里 @ 了我：

"我那个 PR 提了两天了，能帮我看一下吗？"

我翻出来一看——800 行，涉及三个模块。

我当时脑子里只有一个念头：要是有人能替我先过一遍就好了。

解决思路：AI 做初审，人做终审

理想的工作流是这样的：

开发者 push PR
    ↓
AI 自动分析 diff
    ↓
AI 在 PR 里发评论（10秒内）
    ↓
人工看 AI 的意见 + 做最终判断
    ↓
approve 或 request changes

好处显而易见：

AI 处理掉 80% 的机械检查（代码风格、潜在空指针、未处理的 Promise reject）
人只需要关注 AI 标注出的问题点 + 业务逻辑
平均 review 时间从 30 分钟压缩到 8 分钟

坏处也要说清楚：

AI 不理解你的业务逻辑，会漏掉业务层面的 bug
AI 有时候会给"误报"，需要人来过滤
不能完全替代人工 review

所以定位是：AI 初审 + 人工终审，不是 AI 替代人工。

实现方案：GitHub Actions + Claude API

第一步：申请 Claude API Key

去 console.anthropic.com 注册，免费额度足够测试用。

把 Key 存到 GitHub 仓库的 Secrets：

仓库 → Settings → Secrets and variables → Actions
新建 ANTHROPIC_API_KEY

第二步：创建 workflow 文件

在你的仓库里创建 .github/workflows/ai-review.yml：

name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm install @anthropic-ai/sdk @octokit/rest

      - name: Run AI Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
          REPO_OWNER: ${{ github.repository_owner }}
          REPO_NAME: ${{ github.event.repository.name }}
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: node .github/scripts/ai-review.js

第三步：创建核心脚本

创建 .github/scripts/ai-review.js：

const Anthropic = require('@anthropic-ai/sdk');
const { Octokit } = require('@octokit/rest');
const { execSync } = require('child_process');

const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });

async function getDiff() {
  const diff = execSync(
    `git diff ${process.env.BASE_SHA}..${process.env.HEAD_SHA} -- '*.js' '*.ts' '*.tsx' '*.jsx' '*.vue'`
  ).toString();

  // 超过 8000 字符截断，避免超出 token 限制
  return diff.length > 8000 ? diff.slice(0, 8000) + '\n... [diff truncated]' : diff;
}

async function reviewWithClaude(diff) {
  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-6',
    max_tokens: 2048,
    messages: [{
      role: 'user',
      content: `你是一个资深前端代码审查工程师，请对以下 PR diff 进行代码审查。

**审查重点：**
1. 潜在 Bug（空值引用、异步竞态、边界条件未处理）
2. 安全风险（XSS、敏感信息泄露、输入未校验）
3. 性能问题（不必要的重渲染、大对象序列化、内存泄漏）
4. 可维护性（函数过长、命名不清晰、重复代码）

**输出格式：**
用 Markdown 输出，包含以下几个部分：
- 🔴 严重问题（必须修复）
- 🟡 建议优化（可以改进）
- 🟢 代码亮点（做得好的地方）
- 📊 总体评分（1-10分，附简短理由）

如果没有问题，直接说"代码质量良好，无明显问题"。
用中文回复，简洁直接，不废话。

**PR Diff：**
\`\`\`
${diff}
\`\`\``
    }]
  });

  return message.content[0].text;
}

async function postComment(review) {
  const { REPO_OWNER, REPO_NAME, PR_NUMBER } = process.env;

  await octokit.issues.createComment({
    owner: REPO_OWNER,
    repo: REPO_NAME,
    issue_number: parseInt(PR_NUMBER),
    body: `## 🤖 AI Code Review\n\n${review}\n\n---\n*由 Claude AI 自动生成，仅供参考，请以人工审查为准*`
  });
}

async function main() {
  try {
    console.log('Getting diff...');
    const diff = await getDiff();

    if (!diff.trim()) {
      console.log('No JS/TS changes detected, skipping review.');
      return;
    }

    console.log('Sending to Claude for review...');
    const review = await reviewWithClaude(diff);

    console.log('Posting comment...');
    await postComment(review);

    console.log('Done!');
  } catch (error) {
    console.error('Error:', error);
    process.exit(1);
  }
}

main();

第四步：推一个 PR 测试

随便改一个文件，提个 PR，大约 15-20 秒后，你会看到 AI 自动在 PR 下面发了一条评论。

真实效果展示

我们团队用了两周后，AI 的评论长这样：

🔴 严重问题（必须修复）

第 47 行 userData.profile.avatar：未做空值检查，当 profile 为 null 时会抛出 TypeError。建议改为 userData.profile?.avatar。

第 83 行：useEffect 的依赖数组缺少 userId，可能导致使用过期的 userId 发请求，产生数据不一致。

🟡 建议优化

第 92-115 行：formatUserData 函数做了 3 件不同的事（格式化、过滤、排序），建议拆成 3 个函数，便于测试和复用。

🟢 代码亮点

错误处理写得很规范，catch 块没有直接吞掉错误，而是通过 errorReporter.capture 上报，赞。

📊 总体评分：7/10

整体结构清晰，主要问题集中在空值防护上，修复后可以直接合并。

看到这个，review 的人只需要：

确认 AI 找出的问题是否真实存在（通常是）
判断业务逻辑是否正确（这才是人工的价值所在）
approve 或 request changes

平均节省 70% 的初审时间。

进阶：按文件类型差异化 review

不是所有文件都需要一样的审查策略。可以在 prompt 里加文件类型判断：

function buildPrompt(diff, fileTypes) {
  const focusMap = {
    'api': '重点关注：参数校验、错误处理、幂等性、接口安全',
    'component': '重点关注：props 类型、副作用清理、渲染性能、无障碍属性',
    'util': '重点关注：边界条件、纯函数、测试覆盖',
    'store': '重点关注：状态更新的不可变性、selector 性能、副作用隔离'
  };

  const focus = fileTypes.map(t => focusMap[t]).filter(Boolean).join('\n');

  return `你是资深前端工程师，请审查以下代码：

${focus ? `**本次特别关注：**\n${focus}\n` : ''}

${diff}`;
}

踩坑记录

坑 1：diff 太大超出 token 限制

解决方案：只 review 修改行数 < 500 的文件，超过的给一个提示"文件变更过大，请人工重点审查"。

坑 2：AI 给出"误报"，降低信任度

解决方案：在 prompt 里加一句 "如果你不确定是否是问题，不要写出来"。比 "尽可能找出所有问题" 效果好很多。

现状

现在我们团队的 CR 流程是这样的：

开发提 PR
AI 10 秒内完成初审，发评论
reviewer 看 AI 评论 + diff，平均 8 分钟完成终审
merge

那个之前每天催我 review 的同事 A，现在每次 AI 评论发出来，他比我更认真地研究 AI 说了什么。

上周他跟我说：

"AI 给我找出了一个我自己写代码时没注意的空指针，这玩意儿比我认真。"

完整代码

完整的配置文件我放在下面，可以直接 copy 到你的项目里：

.github/workflows/ai-review.yml（上文已贴完整版）

.github/scripts/ai-review.js（上文已贴完整版）

需要的环境变量：

ANTHROPIC_API_KEY：从 Anthropic 控制台获取
GITHUB_TOKEN：GitHub Actions 自带，不用手动配置

配置完之后，去提一个测试 PR，看着 AI 自动开始 review，还挺有成就感的。

写在最后

这套方案不是为了让人偷懒的——而是让人的精力花在刀刃上。

机械的检查（空值、类型、格式）让 AI 做，业务逻辑、架构判断、团队规范这些需要上下文的判断，留给人。

如果你的团队也有 CR 堆积的问题，可以直接拿这套配置用。有什么问题评论区说，我看到了会回。

点赞收藏一下，下次出团队提效工具合集时方便你找回来。