AI时代前端工程师实战指南：避坑篇

发表于 分类于 阅读次数：

AI时代前端工程师实战指南：避坑篇

深度使用过 AI 才知道的坑，以及对应的防御策略。

7.1 AI 幻觉：它真的知道自己在说什么吗？

AI 的”知识”本质上是对训练数据的模式匹配，它不是真的”知道”某个事实。这会表现为：

常见幻觉类型

类型 表现 例子
虚构 API 推荐一个不存在的库或API “使用 useEffectEvent Hook”（React 19 的 RFC，还没稳定）
错误版本 引用过时的 API 用法 “Vue 3 的 defineComponent 是必须的”（不是必须的）
张冠李戴 把一个库的特性安到另一个库上 “React 的 v-model 指令”（那是 Vue 的）
过度承诺 说某个功能可以实现但实际上不行 “使用 Service Worker 可以实现实时推送”（不完全是）

防御策略

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1. 让 AI 自己标注置信度
   在 Prompt 末尾加一句：
   "对于你提到的库、API、版本号，请标注你的确定程度：
   ✅ 确认存在且版本正确 / ⚠️ 比较确定但建议验证 / ❌ 推测"

2. 用 @Docs 和 @Web 查证
   在 Cursor 中输入 @Docs React 确认 API 是否存在
   或在 Prompt 中说 "请在回答前用 @Web 搜索确认"

3. 关键信息独立验证
   AI 推荐的 npm 包 → 去 npm 官网看下载量和最后更新时间
   AI 推荐的 API → 去官方文档看
   AI 生成的配置 → 手动跑一遍确认

4. 经验法则
   - AI 关于"流行度"和"推荐"的说法要打折
   - AI 给出的版本号和日期，大概率是错的
   - AI 说 "这个很简单" 时，通常它没考虑完整

7.2 安全红线：AI 无心但有毒

代码泄露风险

1
2
3
4
5
6
7
8
9
10
❌ 不要把以下内容发给 AI：
- 数据库密码、API Key、Token
- 客户的敏感数据（手机号、身份证、地址）
- 公司的核心业务逻辑（特别是闭源项目）
- 未公开的产品功能

✅ 发给 AI 前的处理：
- 用占位符替换敏感信息（如 password: "xxx"）
- 代码中的 URL 替换为通用格式（如 /api/v1/xxx）
- 业务数据用测试数据替代

AI 推荐的安全隐患

AI 可能推荐不安全的做法：

1
2
3
4
5
6
7
8
9
10
场景：AI 说"用 innerHTML 直接插入用户评论内容即可"
→ 这是 XSS 攻击的典型入口
→ 正确做法：用 textContent 或 DOMPurify 过滤

场景：AI 说"密码直接存 localStorage"
→ localStorage 可以被 XSS 读取
→ 正确做法：HttpOnly Cookie + 后端 session

场景：AI 说"eval 很方便"
→ 永远不用 eval，AI 不知道你的安全上下文

防御策略

1
2
3
4
5
6
7
8
建立"AI 安全审查"意识：
收到 AI 的代码 → 先过一遍脑中的安全检查清单：

□ 有没有用户输入直接拼接到 DOM 中？
□ 有没有敏感信息可能被暴露？
□ 有没有引入第三方 CDN 资源？（供应链攻击风险）
□ 有没有使用不安全的 JS API（eval、document.write）？
□ 有没有绕过认证或权限控制的逻辑？

7.3 过度依赖：当拐杖变成轮椅

危险信号

1
2
3
4
5
6
以下信号说明你可能过度依赖 AI 了：

⚠️ 没有 AI 就写不了代码，遇到问题第一反应是问 AI 而不是自己思考
⚠️ AI 生成的代码读不懂就部署上去了
⚠️ 同样的简单 Bug 反复出现，没有形成自己的知识体系
⚠️ 对项目代码的整体架构缺乏理解，只知道自己写的部分

合理的使用边界

1
2
3
4
5
6
7
8
用 AI 做                    | 不要用 AI 做
---------------------------|--------------------------
生成样板代码和重复劳动      | 核心业务逻辑
生成测试用例               | 安全敏感代码
辅助 Debug 提供思路         | 不经审查就部署
生成文档和注释              | 架构决策
Code Review 辅助            | 性能关键路径的初次实现
学习新技术的辅助工具        | 替代问题解决能力

保持能力的策略

1
2
3
4
5
6
7
8
1. "先自己试 15 分钟"原则
   遇到问题，先自己尝试 15 分钟，再用 AI。这 15 分钟是保持思考能力的关键。

2. "必须读懂 AI 的代码"原则
   AI 生成的所有代码，必须逐行读懂了才合入。读不懂说明你自己还做不到，先学习。

3. "定期无 AI 日"原则
   每周抽出一天，不借助 AI 编码，保持基本功。

7.4 什么时候不该用 AI

场景 为什么不该用 应该怎么做
刚接手新项目 需要自己理解代码结构，AI 给的是二手认知 先自己读一遍核心代码，再用 AI 验证理解
排查复杂 Bug AI 可能给出猜测性的答案 先自己定位复现路径，缩小范围后再问 AI
性能调优 AI 给出的是通用建议，不是项目特化的 先用 Performance 面板实测，定位瓶颈再针对性优化
敏感数据处理 数据泄露风险 完全自己写，或使用去敏后的数据
面试准备 用 AI 理解概念可以，但必须能脱离 AI 表达 用自己的话重述概念，做模拟面试
架构决策 AI 不理解你的团队、业务、技术债 AI 提供决策依据，你自己做决策

7.5 CI/CD 中的 AI 安全实践

如果团队在 CI/CD 中使用了 AI 生成代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Code Push
    │
    ▼
GitHub Actions / CI
    │
    ├── Lint (ESLint + Prettier)
    ├── Type Check (tsc --noEmit)
    ├── Test (Vitest)
    ├── Security Scan (CodeQL / SonarQube)
    │   └── 🔴 可加一个 "AI 生成代码标记" 检查
    │       如果 PR 中有疑似 AI 生成的代码模式，
    │       标记为需要人工重点审查
    ├── Build
    └── Deploy

7.6 版权与合规

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
法律上需要注意的问题：

1. AI 生成的代码版权归谁？
   - 不同平台政策不同（GitHub Copilot、Cursor、Claude Code）
   - 商业项目建议查阅具体平台的 ToS
   - 安全做法：不直接复制 AI 生成的大段代码，理解后自己改写

2. AI 可能复现有版权的代码
   - Copilot 曾因可能复现 GPL 代码被起诉
   - 关键业务代码建议自己写核心逻辑
   - 开源项目中使用 AI 生成代码需要更谨慎

3. 企业合规
   - 部分企业禁止使用外部 AI 服务（数据安全）
   - 在入职前确认公司的 AI 使用政策
   - 涉及客户数据时严格遵循合同约定

总结

使用 AI 辅助开发是一把双刃剑。用好了，效率提升 2-10 倍；用不好，可能会引入安全隐患、形成过度依赖。

核心原则只有三条：不信任、必验证、保持思考。不信任 AI 的输出，每次生成都必须经过验证，始终保持自己的技术判断力。做到这三点，你就能在享受 AI 效率提升的同时，避免掉入这些常见的陷阱。