第 1 章
AI 时代前端工程师的能力地图
什么变了、什么没变、价值的新落点，以及一份按 5 维度审核的可委托清单
这一章是手册的立场。如果你只读一章，读这一章。
前端这个工种正在经历它有史以来最大的一次重构。不是技术栈换代——那种事 每两年就来一次。是工程师在做的事本身变了：哪些事还需要人做、哪些事 该由 agent 做、价值落在哪里。
本章给出三件事：
- 什么变了、什么没变 —— 区分真噪音和真信号
- 价值的新落点 —— 在 AI 时代，前端工程师的"职业护城河"在哪
- AI 可委托清单（完整版） —— 按 SPEC-0004 的 4 项硬性 + 1 项建议维度判断
1.1 什么变了
写代码不再是稀缺技能
样板代码、CRUD、表单校验、常规组件——这些工作 AI 写得又快又好。 更准确地说：写出"能跑、规范、有测试"的代码，已经从工程师的核心能力 变成了 agent 的基础输出。
这不意味着工程师失业。意味着工程师的价值定位变了：从"会写代码的人" 变成"知道该让 AI 写什么 + 能判断 AI 写的对不对 + 能把 AI 写的 东西组装成有用的产品的人"。
学习曲线被压平了
过去，前端入行需要先吃下"HTML/CSS/JS + 一个框架 + 一个构建工具"这一大坨。 现在，AI 可以在几小时内帮你产出能跑的项目，但你看不懂出错信息、改不了 非平凡的 bug、做不了架构决策。
结果是：入门门槛降低了，但"独立工作"的门槛反而提高了。 "会调用 AI" 和 "能交付产品" 之间的鸿沟，正是这本手册想填的。
工具链一年迭代两次
2024 → 2025 → 2026，前端工具链的更替速度是肉眼可见的：
- ESLint + Prettier → OXC（oxlint + oxfmt），Rust 原生，快两个数量级
- Webpack → Turbopack（Next.js 16 默认）
- npm → pnpm → 同时 Bun 在抢位置
- Jest → Vitest
- middleware.ts → proxy.ts（Next.js 16）
- Class 组件 → Function 组件 → Hooks → RSC + Cache Components
如果你试图"学完所有工具"——你永远学不完。手册的策略是：学心智模型， 不学命令行参数。后者交给 AI 和官方文档。
"全栈"的语义变了
过去说"全栈工程师"，意思是"既会前端也会后端"。现在的全栈是：
- 前端 + 后端 + 数据库 + 部署 + 可观测性 + AI 集成
听起来更难，但实际上更容易——因为每一层都有 AI 帮你扛。关键变化是 从"垂直深度"转向"垂直整合"：能把一整条链路打通，比在某一层挖得很深 更值钱。
1.2 什么没变
容易忽视的一点是：很多看起来"会被 AI 取代"的能力，其实从未如此重要。
心智模型仍然必学
你可以让 AI 写 React 组件，但只有你理解 React 渲染规则，才能判断
它有没有引入不必要的重渲染、有没有滥用 useEffect、组件树拆分得合不合理。
同样的逻辑适用于：
- 浏览器渲染管线（看到 jank 时知道往哪查）
- 事件循环与异步模型（调试 race condition）
- HTTP 协议（理解为什么这个接口慢、缓存怎么命中）
- TypeScript 类型系统（看懂 AI 推断出来的复杂类型对不对）
理解必学，敲字可委托。 这是本手册反复出现的核心句。
工程品味仍然必学
什么叫"好的代码"是一个主观但有规律的判断。AI 写的代码默认是"工业平均 水平"——能用，不出彩，偶尔有坑。把这种平均水平变成"清晰、可维护、好读" 需要的不是更多技术，是品味：
- 命名为什么这么取
- 函数为什么这么切
- 抽象为什么提到这一层而不是那一层
- 什么时候该重复、什么时候该 DRY
这些没法外包。AI 能模仿你的品味（如果你在 AGENTS.md 里写清楚了）， 但你得先有品味才行。
业务判断仍然必学
这个 feature 该不该做、做到什么程度、和现有系统如何兼容、上线后怎么 观察效果。
这些问题 AI 答不了——它没有你的用户、你的业务约束、你的组织上下文。 任何把这部分委托给 AI 的人，都在用别人的判断替代自己的判断。
调试能力仍然必学
让 AI 写代码很爽。让 AI 调试别人（或者 AI 自己）写的代码——经常是个深坑。 调试需要：
- 假设 / 验证 / 收敛的科学方法
- 对系统行为的因果直觉
- 对工具（DevTools、Profiler、Source Map）的熟练
这部分可以被 AI 辅助（让它解释错误信息、给出可能的原因），但 不能被 AI 代劳。这是本章 D5 警示最集中的区域。
1.3 价值的新落点
如果说过去工程师的价值是"把需求翻译成代码"，那么 AI 时代的价值落在：
落点一：判断（Judgment）
我应该让 AI 做什么 / 不做什么。
包括：
- 把任务拆解到 AI 能稳定完成的颗粒度
- 识别 AI 输出中的"看起来对但实际错"
- 知道何时该自己上、何时该让 AI 上
- 判断架构决策的长期代价
判断力是反 AI 内卷的核心能力。AI 越强，判断力越值钱。
落点二：上下文管理（Context Engineering）
给 AI 什么样的上下文，决定它的输出质量。
第 9 章会详细展开。简单说就是：
- AGENTS.md 是项目级上下文
- specs/ 是决策级上下文
- journal/ 是教训级上下文
- prompt 是任务级上下文
会管理上下文的工程师 = 能驾驭 agent 的工程师 = 2026 年值钱的工程师。
落点三：验证（Verification）
AI 写了一段代码，怎么验证它对不对。
这是 D1（验收标准可被快速验证）在工程师能力上的对应面。验证手段包括：
- 自动化测试（单元 / 集成 / E2E / 可视化回归）
- 类型系统（让错误在编译期暴露）
- 静态分析（lint / typecheck / 安全扫描）
- 线上观察（错误监控 / 性能监控 / 业务指标）
验证是工程师在 AI 时代的"防御工事"。AI 越多代码，验证越关键。
落点四：品味（Taste）
在两个"都能用"的方案里挑出更好的那个。
品味没法 5 分钟教会，但能通过两件事培养：
- 读大量好代码（React 源码、TC39 提案、Next.js 文档）
- 反复经历"过去自己写得很烂"的尴尬
品味是工程师的长期资产。这也是为什么本手册 D5 维度会警示： 不要把所有动手机会都委托给 AI——你需要保留培养品味的训练场。
1.4 AI 可委托清单（完整版）
每一项都按 D1（可验证）/ D2（上下文可塞）/ D3（错误代价低）/ D4（品味已规范）四项硬性判断，并标注是否触发 D5 警示。
Tier 1：完全委托，不必逐行 review
| 任务 | D1 | D2 | D3 | D4 | D5 警示 |
|---|---|---|---|---|---|
| Commit message 草拟 | 自检 | diff 即上下文 | 改提交即可 | Conventional Commits 规范 | 无 |
| PR 描述、变更日志 | 团队 review | commits 即上下文 | 文档可改 | 模板已定 | 无 |
| 文档翻译 | 母语者 review | 段落级 | 可重译 | 风格指南 | 无 |
| 注释润色 | 读一遍 | 函数级 | 改回去 | 注释规范 | 无 |
| ASCII 图、Mermaid 草图 | 视觉验 | 描述级 | 重画 | 视觉直觉 | 无 |
Tier 2：委托后做 diff review
| 任务 | D1 | D2 | D3 | D4 | D5 警示 |
|---|---|---|---|---|---|
| CRUD 组件骨架 | 单测 + 视觉 | 类型 + 设计 | 编译报错 | 设计系统 | 无 |
| 表单校验逻辑 | 单测 | Schema 即上下文 | 编译报错 | Zod 已成范式 | 第 1 次自己写 |
| 单元测试骨架 | 测试本身验自己 | 函数签名 | 加测试不破坏代码 | 测试规范 | 无 |
| 正则表达式 | 测试用例 | 规则描述 | 改回去 | 无品味需求 | 触发 |
| SQL 查询（只读） | 结果集对比 | 表结构 | 只读 | 团队 SQL 风格 | 无 |
| 复杂 CSS 选择器 | 浏览器实测 | 元素描述 | 改回去 | 无品味需求 | 无 |
| TypeScript 工具类型 | 类型测试 | 输入/输出类型 | 编译报错 | 团队约定 | 触发 |
| 配置文件（tsconfig / eslint） | 跑一遍 | 项目结构 | 改回去 | 官方默认 | 无 |
Tier 3：委托后逐行 review + 测试覆盖
| 任务 | D1 | D2 | D3 | D4 | D5 警示 |
|---|---|---|---|---|---|
| 业务逻辑组件 | 单测 + E2E | 设计稿 + Spec | 测试拦截 | 设计系统 | 第 1 次写新模式 |
| 数据转换函数 | 单测 | 输入/输出 schema | 类型拦截 | 团队约定 | 无 |
| 写入型 SQL / 数据迁移 | dry-run + 备份 | 表结构 + 影响范围 | 难回滚 → 慎重 | 团队规范 | 无 |
| API route / Server Action | 集成测试 | 类型 + 业务规则 | 测试拦截 | 团队约定 | 无 |
| 错误处理逻辑 | E2E 模拟错误 | 错误分类 | 测试拦截 | 团队约定 | 触发 |
Tier 4：AI 辅助，最终由人写
这一档不算"委托"。是把 AI 当成更聪明的搜索引擎和 rubber duck。
| 任务 | 为什么 |
|---|---|
| 性能问题诊断 | D1 不过：性能问题的"对错"需要 profiling 验证，不是 5 分钟能判定的 |
| 架构决策 | D1+D2 都不过：影响长期、上下文超过单 prompt |
| 安全审计 | D3 不过：错误代价极高且滞后 |
| 涉及业务规则的核心逻辑 | D2+D4 不过：业务上下文 AI 拿不到 |
| 新框架 / 新概念学习 | D5 强警示：让 AI 帮你"理解"等于没理解 |
| 调试不熟悉的代码 | D5 强警示：调试是核心能力训练 |
永不委托
| 任务 | 为什么 |
|---|---|
| 任何你说不清楚验收标准的事 | D1 不过 |
| 加密 / 密钥管理 / 鉴权代码 | D3 极高代价 |
| 数据库 schema 设计 | D3 + D2 都不过 |
| 与法律 / 合规相关的逻辑 | D3 极高代价 + D4 不规范 |
| 让 AI 自主提交代码到生产 | D3 灾难级代价 |
1.5 关于 D5 警示
D5 是建议性维度，不是硬性排除。上述清单里被标 "触发" 的任务，技术上 都通过了 D1–D4，完全可以委托。
但本手册希望你注意：
长期反复把这些任务委托给 AI，会让你在它们上面失去能力。
特别警示的几项：
- 正则表达式：每次让 AI 写，你就少一次"打开 regexr.com 搞清楚 lookahead 语法"的机会。建议自己写过 5 个再开始委托。
- TypeScript 工具类型：泛型推导是 TS 真正强大的部分。让 AI 写完别只 复制粘贴，至少读懂为什么这么写。
- 错误处理逻辑：错误处理反映工程师对系统失败模式的理解。每次委托等于 让 AI 替你"预想"系统会怎么坏。
- 调试（在 Tier 4 警示更强）：调试不可委托——可以让 AI 帮你分析， 但别让它替你下结论。
D5 的简单触发判断（来自 SPEC-0004）：
如果你过去 3 年只让 AI 做这件事，现在让你 30 分钟内独立完成，做得到吗？
做不到 → 这就是 D5 想保护的能力。
1.6 三类读者的优先级
新入行 / 转行者
前 6 个月别急着委托太多。 你需要建立基础肌肉记忆：
- 必学：第 2 章 Web 平台基石、第 4 章 JavaScript / TS、 第 5 章 React / Next.js
- 自己写：表单、CRUD、第一个 React 组件、第一个 Hook、第一次调试
- 委托：Tier 1 全部 + Tier 2 中无 D5 警示项
优先级警示：D5 标了"触发"的项，你都属于"前 5 次自己写"那一档。
1–3 年经验
你可以开始放心委托 Tier 1–2，重点训练 Tier 3 的 review 能力。
- 必学：第 5 章 React / Next.js、第 6 章 工程化、 第 7 章 质量与交付
- 警示：Tier 3 委托后不要省 review，省了就违背 D3
- 拓展：第 9 章 AI 原生工作流 学习上下文管理
资深工程师
你应该已经能稳定把 Tier 1–3 委托出去。重点是 Tier 4 的判断力 + 团队级 AI 工作流的建立。
- 必读：本章 + 第 9 章 AI 原生工作流
- 实操：把团队的 AGENTS.md / specs / journal 立起来
- 反思：D5 警示对自己团队的应用——哪些能力是团队不该失去的
延伸阅读
- Andrej Karpathy: Software 2.0 — 工程师价值变迁的早期论述（2017，仍然有效）
- Simon Willison: Coding with LLMs — 个人博客，但 Simon 是 Datasette 创始人 + LLM 工具领域核心实践者， 灰名单。
- Anthropic: Claude Code best practices — 一手厂商文档，关于 agent 协作工作流。
- Next.js Devtools MCP — Next.js 16 内置的 MCP 集成，体验 agent 与框架的深度集成。
下一章：第 2 章 Web 平台基石 —— 不依赖框架，但依赖你理解的部分。