为什么对着 JD 准备仍然低效
很多人知道要看 JD，知道要把 JD 上的要求逐条拆解成知识点，知道要对每个知识点做准备。但实际做下来还是觉得效率很低——JD 看了三遍，要准备的东西列了满满一页，但不知道从哪里开始，准备了一阵子又觉得什么都没到位。
问题不在于"有没有对着 JD"，而在于"怎么对着 JD 建立系统"。
JD 告诉你的不只是知识点
JD 上写的"熟练掌握 React 原理"，不只是告诉你"React 是个考点"。它背后有一个隐含的意思：这家公司大概率在使用 React，面试官默认你对 React 有实战经验，你不仅要知道怎么用，还要知道它为什么这样设计。
同理，JD 上写"有前端工程化经验"，不只是告诉你"webpack 是个考点"，而是暗示这家公司可能在构建链路、模块化管理、发布流程上有一定的复杂度，他们希望你有处理这类问题的经验。
读 JD 不是在找"会不会考这个"，而是在理解"这家公司的技术栈和复杂度大概在什么水平"。
知道这个之后，准备的方式就不一样了：不是把知识点背下来等着被问，而是确保自己能在面试里讲出和这个技术栈深度匹配的真实经验。
把 JD 拆解成知识骨架的节点
拿到一个 JD，第一步不是列知识点清单，而是把它翻译成自己的知识骨架上对应的节点。
假设 JD 要求：熟悉 React 生态（React、Redux、React Router）、有 TypeScript 项目经验、了解前端工程化（webpack、CI/CD）、有性能优化经验。
对应的知识骨架节点可能是：
- React 核心：state 管理、生命周期、Fiber 架构、hooks 原理
- 状态管理：Redux 的设计思想、Redux Toolkit 的现代用法、什么时候该用 Redux 什么时候不该用
- TypeScript：类型系统、泛型、工具类型、React+TS 的最佳实践
- 工程化：构建链路、模块化、CI/CD 流程、灰度发布
- 性能优化：Core Web Vitals、React 性能优化手段、浏览器渲染性能
现在对着骨架过一遍：哪些节点是你有深度经验的？哪些节点是你用过但理解不深的？哪些节点是你知道概念但没有实战过的？
用 PIE 框架定优先级
把拆解出来的节点放到 PIE 框架里评估优先级：
P - Performance impact（对候选岗位的影响力）：这个技能在这个岗位上出现的频率有多高？被问到的概率有多大？比如 React 在一个纯 React 技术栈的公司，影响力就是最高的。
I - Interviewability（被问到的可准备性）：这个技能被面试官问到时，能不能通过准备得到显著提升？比如算法题，准备效果很好；但公司文化和工作方式这类问题，准备效果很差。
E - Expertise gap（当前差距）：你现在和"能讲清楚"之间还有多大差距？差距大的优先补，差距小的可以快速过一遍。
三个维度都高的，最优先准备。P 和 E 高但 I 低的，比如系统设计题，准备起来边际成本高，可以放在后面。
用 STAR 框架准备项目经验
JD 上通常会要求"有大型项目经验"、"有架构设计能力"。这类要求不是靠背知识点能回答的，需要准备具体的项目故事。
STAR 框架是一个好用的工具：
Situation（背景）：这个项目是在什么背景下做的？当时的技术挑战是什么？
Task（任务）：你在这个项目里承担什么角色？你的主要目标是什么？
Action（行动）：你具体做了什么？用了什么技术方案？为什么这样选？
Result（结果）：最终效果怎么样？有什么可以量化的数据？
准备两到三个这类故事，每个都能讲三到五分钟，是对抗这类 JD 要求的有效手段。
优先级排好之后怎么做
假设你排出来的优先级顺序是：
第一优先：React 核心（因为你对这个最熟，但表达不够系统） 第二优先：TypeScript 泛型和工具类型（因为有一些经验，但细节记不清） 第三优先：性能优化（因为做过一些项目，但没形成体系） 第四优先：工程化（因为经验比较少，临时补不了太多）
接下来不是一口气全部同步推进。正确的方式是把时间切成块，每天集中一个块只做一个领域。
比如每天早上有半小时碎片时间，晚上有一小时整块时间。早上那半小时用来做"快速过一遍"——看一篇核心文章、画一张小图、整理一个知识点。晚上那一小时用来做"深度输出"——对着一个知识点做五分钟口头练习、默写一个机制的关键步骤。
每三天回过头检查一次：这个领域的知识点，我能用自己的话讲清楚了吗？不能的话，是卡在哪里了？
用 PDCA 循环做周检视
每周花半小时做一次 PDCA 检视：
Plan（计划）：这周打算在哪个领域投入多少时间？
Do（执行）：实际执行情况怎么样？有没有被其他事情打断？
Check（检查）：这周的执行让我在这个领域的理解提升了吗？能讲清楚一个之前讲不清楚的点了吗？
Adjust（调整）：下周的计划需不需要调整？哪个领域需要加时间，哪个领域可以放一放？
坚持四周，你会发现自己的准备从"在焦虑里打转"变成"在系统里有节奏地推进"。
这一章想说的
对着 JD 准备低效，通常不是因为不够努力，而是因为没有系统。
把 JD 翻译成骨架节点、用 PIE 框架排优先级、用 STAR 框架准备项目故事、用时间块做执行、用 PDCA 做检视——这套系统不复杂，但能帮你把有限的准备时间用在刀刃上。
记住一个原则：不是 JD 上写的每一条都要花同样力气准备的。花力气的地方只有一个标准：最能拉开你和其他候选人的差距的地方。