这两年刷技术社区，最常见的几个关键词就是「AI 提效」「十分钟上线一个营销页」「用 Prompt 写完一个项目」。

作为一个干了 8 年的前端，我当然承认 AI 带来的效率红利——我自己也在用 Cursor、Copilot、各种 LLM 写代码、补测试、查文档。
但这两年下来，我越来越强烈地意识到一件事：

“会用 AI” 本身不是本事，能为 AI 产出的代码兜底，才是。

以前我们写代码，脑子里有清晰的模块边界、职责划分。现在有了 AI，很多人习惯的是先喂一段 Prompt，看 AI 回什么，再想办法塞进项目里。
如果你只是这样用 AI，你得到的不是“提效”，而是更快地把项目写成一坨谁也不想维护的屎山。

下面我就从一个 8 年前端的视角，讲讲我自己是怎么看待「从 Prompt 搬运工到架构兜底人」这件事的。

要警惕 AI 只“跑通”不“善后”

我现在几乎天天用 AI 写代码，但有一个前提：AI 给我的东西，默认是不可信的草稿。

我在日常工作里真切踩到、或者在别人代码里见过的几个典型坑，大概是这些：

  • 副作用和资源释放

    • 在 useEffect / 各种响应式监听里，AI 很喜欢一股脑把订阅、事件监听、定时器全写进去，但清理逻辑写得非常敷衍，甚至不写。
    • 闭包本身不是问题，问题是订阅的生命周期和数据的生命周期错位，久而久之就是内存泄漏、重复监听、重复请求。

  • 异步请求的边界条件

    • 用户疯狂点击刷新 / 切 Tab，AI 默认你永远在“理想网络环境”下，几乎不会帮你加 AbortController 或者请求竞态保护。
    • 结果就是：后返回的老请求覆盖先返回的新数据，各种诡异的状态错乱。

  • 依赖引入的“隐性体积”

    • 为了完成一个并不复杂的功能，AI 很自然地帮你引入一个 100KB+ 的库。它不会替你思考：
      • 你们项目有没有体积预算？
      • 有没有现成的封装可以复用？
      • 这个功能是不是用几行原生 + 适当封装就能解决？

这些坑，本质上都是工程视角的问题，而不是“这段代码能不能跑起来”的问题。

所以我对“用 AI 提效”的基本态度是：

AI 负责给我一个能跑的初稿；我负责让这段代码配得上进你们的代码库。

我会怎么做？

  • 看所有副作用相关的代码：事件监听、定时器、订阅、全局状态写入。
  • 对所有网络请求加上：超时机制、取消机制、竞态保护。
  • 对所有新增依赖做一次“引入理由 + 体积 + 使用范围”的 review。
  • 对关键逻辑加上最小单测 / 契约测试，起码保证回归成本可控。

如果做不到这些，再快的提效都只是把未来的维护成本借来透支。

架构和规范：别被 AI 牵着鼻子走

我越来越有这种直观感受：

普通人被 AI 牵着鼻子走，架构兜底的人，会反过来用规范把 AI 关在笼子里。

以前我写一个中大型前端项目，脑子里最先冒出来的是：

  • 领域是怎么拆的？
  • 模块边界在哪里？
  • 哪些是 domain 层，哪些是 app / service 层，哪些是 UI 壳？

有了 AI 之后，如果只剩下“喂一段 Prompt，拿一段代码”，项目的熵增速度会快得离谱。

所以这两年我做得最多的一件事，其实不是“教团队怎么写 Prompt”，而是：

先把规则和边界定清楚，再允许大家带着 AI 一起写。

比如我会在团队里推这样几类约束：

  • Cursor / AI 使用规范

    • 哪些目录（比如核心交易链路、风控逻辑）禁止 AI 直接生成实现，只允许在注释 / 文档 / 测试上辅助。
    • 哪些模块可以 AI 先写一版，但必须满足：
      • 类型完整、不可 any 滥用
      • 通过指定 ESLint 规则
      • 内部抽象层级不能超过约定的复杂度

  • 类型定义和领域模型

    • 先把关键领域模型抽象成 Type / Interface，再让 AI 在这些类型的约束下生成代码。
    • 这样可以尽量避免 AI 直接在业务代码里“击穿”你的领域边界。

  • 依赖白名单 / 黑名单

    • 白名单：组件库、工具库、日期处理、请求库等有统一选型，AI 必须在这些库范围下找解法。
    • 黑名单：历史上踩过坑、体积太大、维护不善的库，直接在规则里禁止建议。

  • PR 模板 + Review Checklist

    • 每个包含 AI 生成代码的 PR，在描述里要写清楚：这部分是 AI 初稿 + 人工修改的范围。
    • Review 的时候，人工重点盯：边界条件、副作用、依赖选择、与现有架构是否一致。

这些东西听起来很“工程化”，但我现在越来越觉得：

用 AI 之前先想清楚架构和规范，是一个架构兜底人和 Prompt 搬运工之间最大的差别。

提效的真正意义：把时间挤到深水区

我自己对“提效”的理解，大致是这样的：

提效的意义，是为了腾出时间去研究那些 AI 还没学会、也暂时替代不了你的硬核能力，而不是心安理得地退化成一个 Prompt 搬运工。

这几年我用 AI 省下来的时间，主要花在几件事上：

  • 补上底层原理的短板

    • 比如重新系统性梳理：Event Loop、微任务 / 宏任务、浏览器渲染管线、内存回收等。
    • 去看 Vue / React 等框架的部分源码，研究它们如何处理调度、依赖收集、更新批次等。

  • 练「排障闭环」能力

    • AI 很难完全帮你搞定那种：线上偶现、只在某一类机型 / 某一版浏览器出现的 Crash。
    • 这类问题往往需要你去：
      • 仔细看监控和日志
      • 制造或捕获最小复现
      • 在 Chrome DevTools 里看 Memory Heap / Performance Timeline
      • 甚至去翻一眼浏览器的已知 issue

  • 加强工程化手感

    • 把 CI / CD、单测、契约测试、端到端测试、灰度发布这些东西玩熟。
    • 能站在更高一层看：“我们的交付链路是不是健康的？”

坦白说，如果你把 AI 省下来的时间全部拿去摸鱼，那你在团队里的边际价值，很快就会被下一代更便宜的 AI 操作员稀释掉。

我怎么判断自己是不是还在当「Prompt 搬运工」？

从面试官的角度去拷问候选人是一种方法，我更常用的，是把这些问题用来拷问我自己。

如果你也在用 AI 写代码，不妨一起自查一下：

  1. AI 改了底层公共组件，你会怎么确保线上不崩？

    • 你会不会：
      • 首先看「影响面」和「依赖关系」
      • 补上必要的测试
      • 设计一套回滚策略和监控指标？

  2. 你有没有给自己和团队划定过「AI 禁区」？

    • 哪些业务模块你会明确规定：
      • 只能人工设计和实现
      • AI 只能用于文档 / 注释 / 测试
    • 你的理由是什么？是因为这里风险高，还是因为这里有团队的核心竞争力？

  3. 在审美同质化的今天，你怎么用工程手段支撑“良好体验”？

    • 如果 UI 组件、动效很多是 AI / 库生成的，你有没有想过：
      • 通过哪些工程化手段（设计系统、交互规范、动效基线、性能预算），让体验保持稳定和高级感？
      • 怎么在“快”与“好看、好用”之间找到一个你认可的平衡点？

  4. 面对 AI 生成的代码，你的第一反应是什么？

    • 是“哇真方便，复制粘贴完事”？
    • 还是“这个实现我大概懂 7 成，但还有 3 成不踏实，我要把这 3 成抠清楚再合并”？

如果大部分时候，你只是把 AI 当成一个“更聪明的 Stack Overflow 复制器”，那你大概率还停留在「Prompt 搬运工」阶段。

写在最后：手可以闲一点，脑子得转得更凶

说句心里话，我一点也不怀疑 AI 会越来越强，强到今天我们认为很“高级”的工作，也会被一点一点侵蚀掉。

所以我现在更愿意这样看待自己的角色：

AI 负责拓宽“能做的事情”的边界，我负责守好“应该怎么做才算负责任”的底线。

在没有 AI 的年代，我们习惯了靠手速、靠熬夜、靠体力堆产出。
在有 AI 的时代，手确实可以闲下来一部分了，但这并不意味着你可以脑子也一起放假。

反而是现在，我更常提醒自己：

手是可以比以前更闲一点，但脑子得转得比以前更凶。

从「Prompt 搬运工」到「架构兜底人」，中间隔着的，既不是几条 Prompt 模板，也不是几篇工具教程，而是你愿不愿意、敢不敢为 AI 生成的每一行代码的后果负责。

如果你也有类似的思考，欢迎一起聊聊你在团队里是怎么用 AI 的，以及你见过的那些“AI 把坑挖大了”的真实案例。