第 1 章
AI 时代前端工程师的能力地图
什么变了、什么没变、价值的新落点，以及一份按 5 维度审核的可委托清单
这一章是手册的立场。如果你只读一章，读这一章。
前端这个工种正在经历它有史以来最大的一次重构。不是技术栈换代——那种事 每两年就来一次。是工程师在做的事本身变了：哪些事还需要人做、哪些事 该由 agent 做、价值落在哪里。
本章给出三件事：
- 什么变了、什么没变 —— 区分真噪音和真信号
- 价值的新落点 —— 在 AI 时代，前端工程师的"职业护城河"在哪
- AI 可委托清单（完整版） —— 按 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 可委托清单（完整版）
第 0 章讲过「三档归位」——那是给知识分类（必学 / 仍需理解 / 可委托 AI）。本节讲的是任务——同一段知识，面对具体任务时， 你要给 AI 多少自由度。
同一件事可以横跨两套。比如：必学 React 心智模型（知识层 = 必学）， 但每次实际写组件可以让 AI 起草、你 review（任务层 = Tier 2 委托）。 不矛盾。
5 个判断维度（贯穿本节所有表格）
| 代号 | 别名 | 一句话含义 |
|---|---|---|
| D1 | 可验证 | 你能不能验证 AI 输出对不对？ |
| D2 | 上下文够 | AI 需要的信息，能塞进一个 prompt 吗？ |
| D3 | 错误可逆 | 万一错了，代价大不大？能不能改回去？ |
| D4 | 有规范 | 团队 / 社区有公认的"好"的标准吗？ |
| D5 | 技能保留 | 长期把这件事全交给 AI，你自己会不会失去能力？ |
前 4 项是硬性判断——任意一项答不上 "是" → 不该委托。 D5 是软提醒——即便前 4 项都过，长期反复委托也可能让你失去能力， 所以会单独标注"触发"。
下面把任务按"要给 AI 多少自由度"分成 4 个 Tier，表格列名沿用代号 （D1 / D2 / D3 / D4 / D5 警示），含义对照上表。
Tier 1：完全委托，不必逐行 review
| 任务 | D1 可验证 | D2 上下文够 | D3 错误可逆 | D4 有规范 | D5 警示 |
|---|---|---|---|---|---|
| Commit message 草拟 | 自己读一遍即可 | 当前 diff 就是全部上下文 | 错了重新生成提交 | Conventional Commits 是社区共识 | 无 |
| PR 描述 / 变更日志 | 团队 review 把关 | 已有 commits 就是上下文 | 文档随时可改 | 团队 PR 模板已定 | 无 |
| 文档翻译 | 找母语使用者校对 | 一次翻一段，上下文短 | 翻错了重译即可 | 已有文档风格作锚 | 无 |
| 代码注释润色 | 自己读一遍能懂 | 当前函数 = 全部上下文 | 改坏了 git 撤回 | 项目已有注释风格 | 无 |
| ASCII 图 / Mermaid 草图 | 看图能不能讲清楚 | 用文字描述就够 | 不满意重画即可 | 视觉好坏靠直觉判断 | 无 |
Tier 2：委托后做 diff review
| 任务 | D1 可验证 | D2 上下文够 | D3 错误可逆 | D4 有规范 | D5 警示 |
|---|---|---|---|---|---|
| CRUD 组件骨架 | 单测 + 视觉对比设计 | 类型定义 + 设计稿 | 编译期就会报错 | 项目设计系统已成型 | 无 |
| 表单校验逻辑 | 单测覆盖各种输入 | Zod schema 就是上下文 | 编译期就会报错 | Zod 是社区主流范式 | 第 1 次自己写 |
| 单元测试骨架 | 测试通过即验证 | 待测函数签名 | 加测试不会破坏现有代码 | 团队测试规范已有 | 无 |
| 正则表达式 | 写几个测试用例跑 | 用自然语言描述规则 | 改回去成本极低 | 没有"品味"问题，对就是对 | 触发 |
| SQL 查询（只读） | 对比结果集 | 表结构 schema | 只读不会改数据 | 团队 SQL 风格指南 | 无 |
| 复杂 CSS 选择器 | 浏览器实际验证 | DOM 结构描述 | 改不到就重写 | 没有"品味"问题 | 无 |
| TypeScript 工具类型 | 类型测试 / dtslint | 输入与输出类型签名 | 编译期就会报错 | 团队类型约定 | 触发 |
| 配置文件（tsconfig / eslint） | 跑一遍能否生效 | 项目结构概览 | 改坏了 git 撤回 | 官方默认配置作锚 | 无 |
Tier 3：委托后逐行 review + 测试覆盖
| 任务 | D1 可验证 | D2 上下文够 | D3 错误可逆 | D4 有规范 | D5 警示 |
|---|---|---|---|---|---|
| 业务逻辑组件 | 单测 + E2E 双重把关 | 设计稿 + 业务 spec | 测试拦截 / 上线前发现 | 项目设计系统 | 第 1 次写新模式 |
| 数据转换函数 | 单测验证各种输入 | 输入与输出 schema | TypeScript 类型可拦截 | 团队代码约定 | 无 |
| 写入型 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 设计 | D2 + D3 不过：长期影响、改起来代价巨大 |
| 与法律 / 合规相关的逻辑 | 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 — Datasette 创始人、LLM 工具领域核心实践者的个人博客，质量例外。
- Anthropic: Claude Code best practices （需代理） — 一手厂商文档，关于 agent 协作工作流。
- Next.js Devtools MCP — Next.js 16 内置的 MCP 集成，体验 agent 与框架的深度集成。
访问性说明：以上「需代理」标记的链接在中国大陆需要代理工具访问。 详见 第 0 章「关于访问性」。
下一章：第 2 章 Web 平台基石（即将推出）—— 不依赖框架，但依赖你理解的部分。