下午那两小时，我见过太多人上午估分六十多，出成绩时案例卷四十出头。这不是知识点没背熟的问题——能去考软件设计师的人，教材基本都翻过一遍，该记的概念也没落下。真正把人卡住的是另一件事：案例卷从来不考"你知道不知道"，它考的是"你能不能在二十分钟里，把知道的东西摆到阅卷人想看到的位置上"。这两件事之间隔着的，就是备考案例分析真正要解决的东西。

这篇内容面向的是准备参加软件设计师考试、尤其是下午案例卷反复卡在及格线附近的人。我会从评分规则讲起，把六道大题的采分点一处一处拆开，中间用一道模拟的数据流图题完整走一遍从读题到作答的全过程，再讲算法填空怎么从上下文里"抠"出答案，最后落到六十天的备考节奏和考场两小时的操作细节。基础不太牢的可以按顺序看，已经做过几套卷子的可以直接跳到自己最疼的那一类题。

1. 先搞清楚你在跟什么规则博弈

1.1 卷面结构：六个题、选五个、七十五分

案例卷的构成是固定的：一共六道大题，前四道必答，第五、第六道二选一，也就是通常说的 Java 和 C++ 那一组。每道大题 15 分，总分 75 分。合格线按总分的 60% 划，也就是 45 分。

很多人第一次看到这个结构会犯一个直觉错误：以为 15 分就是要拿满分才稳。实际上你算一笔账——五道题各拿 9 分，正好 45 分；如果其中两道有把握的题能拿到 11 到 12 分，剩下三道各拿 8 分，总分就接近 50 了。这个算术很重要，因为它决定了你的备考姿势：案例分析不是"补齐短板"的考试，而是"把稳的题做厚、把弱的题做到不空着"的考试。

还有一点常被忽略：六选五意味着你可以放弃一类题。但"放弃"不等于"完全不看"。我建议的策略是放弃一道最没把握的题型深度钻研，但基础套路还是要过一遍，因为考场上题目难度会有浮动，某一年的算法题可能特别绕，而 Java 题反而给了一个你熟悉的框架——这时候临场换题的能力就是救命稻草。

上面这个时间是按两小时 120 分钟倒推的：五道题占 100 分钟，留 15 到 20 分钟做整体检查。这个节奏看着宽松，但真正进考场你会发现读题的时间远超预估，尤其是数据流图那种图多字多的题，光把图看清楚就要七八分钟。

1.2 阅卷是按点给分，"意思对了"不算分

这是我最想强调的一点，也是绝大多数人第一次做案例卷吃亏的地方。案例卷的评分是采分点制：每道大题背后有一张评分细则，上面列着若干个采分点，每个点对应 1 到 2 分。阅卷人手里拿的是这张细则，看到你答的内容命中某个点就给分，没命中就跳过。

这意味着什么？意味着你写了三行字，逻辑上完全正确，但如果其中没有出现评分细则上要求的关键词，这几行字就是 0 分。反过来，你只写了五个字但正好是那个词，分就到手了。

举个最典型的场景。数据流图题问"图中缺失了一条数据流，请补充"。评分细则上写的采分点通常是三项：起点、终点、数据流名称。你答"应该有一条从借阅记录表流向图书库存的数据流"——这三项你占了起点和终点，名称说得含糊，可能只拿 1 到 2 分。而标准答法"数据流名称：库存更新信息；起点：借阅处理；终点：图书库存表"，三项齐全，拿满分。

所以答题的第一原则是：能用规范术语就不要用日常表达，能分点写就不要写成一段话，能写出起点终点就绝不只写"它们之间有数据传递"。

1.3 三个高频失分动作，看看你中了几个

第一个动作是答非所问。题目问"补充图中的外部实体 E1、E2"，你在答题区写了一堆分析过程，最后才冒出"E1 是读者"这几个字。阅卷人扫一眼看不到答案位置，很可能就直接跳过了。案例卷的答题纸是按题号分区的空白格子，你写得再工整，如果关键答案埋在中间一段话里，风险极高。

第二个动作是超范围作答。有些题只问"补充两条数据流"，有人怕不保险，写了五条，其中三条是错的。这在采分制里是纯亏——多写不扣分，但会稀释阅卷人对正确答案的注意力，而且如果你把原本正确的那条描述得含糊不清，反而可能被判错。

第三个动作是符号和格式混乱。UML 题里多重度写成"多对多"，E-R 图里联系类型的菱形没画，SQL 语句漏写分号或者把表名写成中文，这些都是"知道但写不出"的典型表现。要解决它只有一个办法：动手写，不要只在心里过。

提示：练习案例卷时一定要用空白纸写答案，不要在原题上标注。你需要在模拟时就建立起"看到答题框、快速定位答案、分点书写"的肌肉记忆，这个能力靠看是练不出来的。

2. 六类题型的采分点长什么样

2.1 数据流图：四个空格的四种填法

数据流图题的出题结构非常稳定，一般是给一张分层数据流图，其中挖掉一部分内容让你补。挖的位置通常集中在四类元素上：外部实体、数据存储、加工、数据流。这四类的答题思路完全不同，得分开练。

补外部实体相对简单。找的方法是看数据的源头和终点：图外有谁给系统送数据、系统把结果送给谁。题干描述里出现的角色词——"读者""管理员""供应商""客户""银行"——基本就是答案。要注意用词要和题干一致，题干叫"读者"你就别写"用户"。

补数据存储要靠"数据在哪停下来"。数据存储的本质是一批需要持久化保存的数据，题干里出现"记录""档案""台账""库存""日志""清单"这类词的地方，往往对应一个数据存储。找的时候往下游看：某个加工的输出如果不再流向别的加工，而是需要长期留着，那它多半进了一个数据存储。

补加工最难，因为它要求你概括一段业务逻辑。判断方法是找"一组输入流全部到齐、然后产生一组输出流"的位置。如果某几条数据流在图上悬空没有归属的加工，那缺失的就是它。

补数据流是出现频率最高的一类，也是最容易丢分的。标准答法必须三要素齐全：名称、起点、终点。这里有个诀窍——数据流的两个端点一定是"加工—存储""加工—实体""实体—加工""存储—加工"这四种组合之一，绝对不可能出现"存储到存储"或者"实体到实体"。你如果推出来的端点是两个存储，那一定是推错了。

还有一个知识点年年考但年年有人栽：父子图平衡。父图里某个加工的一条输入流或输出流，在展开后的子图里必须能找到对应的流。题目常问"子图与父图是否平衡，若不平衡请说明"，答案通常是某个数据流在子图里多出来或者少掉了。检查方法很笨但很有效：把父图里这个加工的所有输入输出流列成一列，再逐条去子图里对，缺哪条写哪条。

2.2 数据库设计：从 E-R 图到关系模式的一条链

这道题的骨架是一条固定的转换链：现实需求 → E-R 图 → 关系模式 → 主键外键 → SQL。题目会在这条链上挑几个环节挖空。

E-R 图部分常考的是联系类型判断。两个实体之间到底是一对一、一对多还是多对多，判断依据是业务语义："一个读者可以借多本书，一本书同一时间只能被一个读者借"，那借阅这个联系就是多对多（把时间维度放进去看）。这里有个小技巧：把两个实体的实例数分别问一遍，如果两边都是"多个"，就是多对多。

转换成关系模式时有个铁律，背下来能省很多时间：

• 每个实体转成一个关系，属性照搬，实体的标识属性做主键；
• 多对多联系必须单独转成一个关系，主键是两个实体主键的组合，同时这两个主键又分别是外键；
• 一对多联系可以并入"多"的那一端，把"一"端的主键作为外键放进去；
• 一对一联系可以并入任意一端，或者单独成表。

范式部分常考的是判断当前关系属于第几范式、以及为什么要拆。判断方法：先看有没有非主属性部分依赖候选键（有就是 1NF 不满足 2NF），再看有没有非主属性传递依赖候选键（有就是 2NF 不到 3NF）。答题时别说"因为它有冗余"，要说清楚"存在非主属性对候选键的传递依赖"，这才是采分点上的词。

SQL 填空是送分区。常考的就是那么几种：CREATE TABLE建表带主外键约束、SELECT带GROUP BY和HAVING、多表连接、INSERT INTO、UPDATE ... SET ... WHERE、创建视图。有个细节要注意——WHERE和HAVING的区别（前者过滤行，后者过滤分组）、COUNT(*)和COUNT(列名)的区别（后者不计 NULL），这两个点被考过很多次。

2.3 UML 图：三种图的符号必须能默写出来

UML 题一般在用例图、类图、状态图、活动图、顺序图里挑一到两种。答题分两块：一块是补图上的空缺（多重度、关系类型、消息名称），一块是文字说明（用例描述、类的作用）。

多重度的写法必须规范，常见的就是这几个：1、0..1、*、1..*、0..*、n、m..n。有人习惯写"1 到多"，这在采分点上是不给分的。判断多重度的方法和判断联系类型一样：站在一端的某个实例上，问"它对应另一端的几个实例"。

用例图里最容易混的是include和extend。记忆口诀是：include是"必须做"，extend是"可能做"。比如"下单"必然包含"计算总价"，这是 include；"下单"之后可能"使用优惠券"，这是 extend，而且 extend 是有方向性的，箭头从扩展用例指向基础用例。另外注意泛化关系（空心三角箭头）和普通关联（实线）的区别。

类图的六种关系要能画能认：依赖（虚线箭头）、关联（实线）、聚合（空心菱形）、组合（实心菱形）、泛化（空心三角）、实现（虚线空心三角）。聚合和组合的区别在于生命周期是否绑定——整体没了部分还在是聚合，整体没了部分也活不了是组合。举个例子，"部门"和"员工"是聚合，因为部门撤销了员工还在；"订单"和"订单明细"是组合，因为订单删了明细就没意义了。

2.4 算法填空：把代码当成一道完形填空

这道题是很多人的心头痛，但它其实是六道题里套路最固定的。出题结构是给一段 30 到 50 行的 C 语言代码，挖 3 到 5 个空，再问一句时间复杂度、或者问这个算法用了什么策略。

关键在于先判断算法策略，再读代码。因为不同策略的代码骨架差别很大：

判断出策略之后，看变量名。真题的代码虽然长，但变量命名通常有语义——w[]是重量、v[]是价值、dp[][]是状态表、low/high是区间端点。先给每个变量标注一句中文含义，再回头看空在哪，往往自己就浮出来了。

2.5 Java 与 C++：怎么选、怎么读一段陌生代码

选哪门语言，我的建议很直接：选你写过的那门。如果两门都只是"学过"，选 Java，因为它的语法噪音小，extends、implements、super、this这些关键词语义单一，不容易被指针和模板语法干扰。

这道题的出题套路是给一个完整的设计场景（比如一个简易的图形编辑器、一个订单状态流转系统），然后给一段不完整的代码框架，挖 5 个空。考点集中在三处：继承与多态、接口实现、设计模式。

设计模式里出现频率最高的几个，要能默写骨架：

• 单例：私有构造 + 静态私有实例 + 静态公有获取方法，双重检查时注意volatile和同步块；
• 工厂方法：抽象产品 + 具体产品 + 抽象工厂声明返回产品的抽象方法；
• 观察者：主题持有观察者集合，attach/detach/notify，观察者接口有update；
• 策略：抽象策略接口 + 若干具体策略 + 上下文持有策略引用；
• 模板方法：抽象类里定义final的流程方法，中间调用若干抽象钩子方法。

读代码的技巧是从框架往细节推：先看清楚有几个类、谁是父类谁是子类、有没有接口、主方法里是怎么调用的。绝大部分空格的答案都能从"上一行写了什么"和"这个方法应该返回什么类型"两个线索推出来。比如一个空让你填方法的返回语句，往上看这个方法的签名是public Shape createShape(String type)，那答案必然是return new 某个Shape(...)。

3. 一道数据流图模拟题的完整作答复盘

3.1 题干与图形（按真题结构改编）

为了把上面讲的方法落到实处，我编了一道结构上贴近真题的模拟题。题干如下：

某社区图书馆要建设一套图书借阅管理系统，主要需求描述： （a）读者通过自助终端提交借阅申请，系统先向读者档案库查询该读者的借阅资格与当前在借数量，再向图书库查询该书是否可借。两项校验都通过则生成借阅记录，并更新图书库中的在馆状态。 （b）读者归还图书时，系统更新借阅记录的归还日期，并把图书状态改回在馆。 （c）馆员负责录入新书信息、注销破损图书，这些操作直接作用于图书库。 （d）系统每天闭馆后扫描借阅记录，对超过归还期限的记录生成逾期清单，交由馆员处理。

题目给出顶层图和 0 层图，挖掉以下几处：

1. 顶层图中的外部实体 E1、E2；
2. 0 层图中缺失的两条数据流；
3. 数据存储 D1、D2、D3 的名称；
4. 判断 0 层图与顶层图是否平衡，若不成立请指出。

3.2 三遍读题法：每一遍只看一件事

很多人读这种题是从头到尾读一遍，读完脑子里一团浆糊，然后开始对着图瞎猜。我的做法是固定读三遍，每遍只关注一件事。

第一遍只找人。把题干里所有"谁做了什么"的句子挑出来，圈出所有角色词。这段需求里出现了三个角色：读者、馆员、（系统自己）。系统自己不算外部实体，所以外部实体只有读者和馆员。答案就出来了：E1 是读者，E2 是馆员。两秒的事，但如果第一遍读的时候顺带思考数据流，反而会漏。

第二遍只找名词性的数据载体。扫一遍题干，把"库""记录""清单"这些词划出来：读者档案库、图书库、借阅记录、逾期清单。前三个是数据存储，逾期清单是输出到馆员的报表，不算存储。所以 D1 读者档案库、D2 图书库、D3 借阅记录，对应关系还要看图上的连接位置来确认——通常借阅处理加工会同时连接 D1 和 D2，归还处理连接 D3 和 D2。

第三遍才看数据流的缺口。这时候你已经知道图上有哪些实体、哪些存储、哪些加工，剩下要做的就是把悬空的地方接上。

注意：这三遍不是慢慢读三遍，而是在 5 到 7 分钟内完成的快速扫描。节奏感很重要，读太久会挤压后面答题的时间。

3.3 从悬空端反推缺失的数据流

判断缺失数据流最有效的办法是找悬空端点。一张画完整的数据流图，除了外部实体和数据存储之外，每个加工都应该有输入也有输出，每个数据存储都应该至少被读写一次。凡是出现"某个加工只有输出没有输入"或者"某个存储只有写入没有读取"的地方，就是缺口。

假设这道题的 0 层图里有三个加工：P1 借阅处理、P2 归还处理、P3 逾期处理。图上画出的数据流有：读者→P1（借阅申请）、P1→读者（借阅结果）、P1→D3（借阅记录写入）、P1↔D1（查询读者信息）、P1→D2（更新在馆状态）、P2→D3（更新归还日期）、P2→D2（更新在馆状态）、馆员→D2（录入新书）、P3→馆员（逾期清单）。

那么缺口就很明显了：

• P1 要校验"这本书是否可借"，必须从 D2 读取图书状态，但图上没有 D2→P1 这条流；
• P3 要扫描借阅记录，必须有 D3→P3 这条流，图上也没有。

完整答法应该是这样写的：

这个表格形式是我强烈建议的答法。它把三个采分点清楚地摆出来，阅卷人一眼就能看到，比写一段话高效得多。

3.4 命名规范：这些细节真的会扣分

数据流图题里有一类"软性"采分点，很多人不知道它存在，但它每年都在扣分。

加工的命名必须是动宾结构。"借阅处理""归还处理""逾期处理"是合格的，"借阅""处理数据""P1"是不合格的。你在补充加工名称时，写成"处理图书信息"比写成"图书处理"更规范。

数据流的命名必须是名词性短语，而且要能反映内容。"借阅申请""图书状态信息"是好名字，"数据""信息""请求"这种空泛的词会被判为命名不当。题干里如果有一段描述提到"系统需要获取该书是否可借的信息"，你就直接把"图书可借状态"搬过来用。

外部实体和数据存储的命名必须是名词，且要与题干用词一致。题干说"读者档案库"，你写"用户表"就不合适，虽然语义相近，但采分点对的是原词。

不能出现"存储到存储"的数据流。这是结构性错误，说明你漏了一个加工。

3.5 父子图平衡的检查清单

平衡性检查我总结成一张对照表，考场上照着走一遍就行。

这道模拟题的最后一问答案是：0 层图与顶层图不平衡，因为 0 层图缺少了从 D2 图书库到 P1 的数据流，而顶层图中该系统需要读取图书状态才能完成借阅校验。这种答法既有结论又有理由，是标准写法。

4. 算法填空的破题顺序：先定策略，再抠代码

4.1 三十秒内判断算法策略

算法题的题干里通常会有一句"该算法采用了（ ）设计策略"，就算不直接问，判断出策略也能帮你理解代码。判断的线索就藏在代码结构里。

看到函数自我调用两次以上，并且参数规模在缩小（比如f(left, mid)和f(mid+1, right)），基本就是分治。看到函数自我调用一次但循环里带着"选或不选"的分支，是回溯。看到声明了一个二维数组，且赋值语句形如dp[i][j] = max(dp[i-1][j], dp[i-1][j-w[i]] + v[i])，这是动态规划，而且大概率是 0-1 背包。

我个人的经验是：把最近五年出现过的算法题策略做成一张清单，考前一周每天默写一遍每类策略的代码骨架。这个方法比刷题有效得多，因为代码骨架是通用的，题目变了骨架不变。

4.2 变量含义追踪表

拿到代码之后，第一件事不是看空在哪，而是把每个变量标注成一句中文。以 0-1 背包的经典写法为例：

int knapsack(int w[], int v[], int n, int C) { int dp[n + 1][C + 1]; for (int j = 0; j <= C; j++) dp[0][j] = 0; /* 空 */ for (int i = 1; i <= n; i++) { for (int j = 0; j <= C; j++) { if (j < w[i]) dp[i][j] = dp[i - 1][j]; /* (1) */ else dp[i][j] = dp[i-1][j] > dp[i-1][j-w[i]] + v[i] ? dp[i-1][j] : dp[i-1][j-w[i]] + v[i]; /* (2) */ } } return dp[n][C]; /* (3) */ }

标注一遍：w[]物品重量、v[]物品价值、n物品个数、C背包容量、dp[i][j]表示"只考虑前 i 个物品、容量为 j 时的最大价值"。有了这句标注，空格 (1) 和 (2) 就不用推了——(1) 的意思是当前背包容量放不下第 i 个物品，所以只能沿用前 i-1 个物品的结果；(2) 就是经典的"放与不放取最大"。(3) 表示考虑全部 n 个物品、容量为 C 时的最优解。

做标注这一步绝对不能省。我在练习时试过跳过标注直接看空，正确率明显下降，因为人的短期记忆装不下六七个变量名，看到第三个空的时候前面的语义就模糊了。

4.3 时间复杂度怎么答才不丢分

时间复杂度这一问通常是送分的，但答法有讲究。这里有两个不同的问题会被问到，答案完全不同：

• "该算法的时间复杂度是？"问的是整个算法，0-1 背包这题要答 O(nC)，因为两层循环分别是 n 和 C；
• "该算法的时间复杂度属于？"问的是量级分类，要答"多项式时间"或"指数级"。

分治类要注意，归并排序和快速排序都是 O(n log n)，但快速排序在最坏情况下退化成 O(n²)，题目如果问"最坏情况"就必须答后者。动态规划类一般是"状态数 × 每个状态的转移代价"，0-1 背包状态数 nC、转移 O(1)，所以是 O(nC)。回溯类通常是指数级，比如 N 皇后是 O(n!)。

还有一类常考的是空间复杂度，尤其是动态规划的滚动数组优化。原版 0-1 背包空间是 O(nC)，如果改成只保留一维数组并从后往前更新，空间能降到 O(C)。题目如果给了优化后的代码问"空间复杂度"，答 O(C)；如果问"为什么内层循环要逆序"，答案是"保证每个物品只被使用一次"——这句话是标准采分词。

5. 六十天怎么排：把时间砸在提分最快的地方

5.1 三轮切分：打底、专项、整卷

我把六十天切成三轮，每轮的目的一点不一样。

第一轮十五天，解决"知道"的问题。这轮不看案例卷，只看知识点。数据流图的四种元素和平衡规则、E-R 图到关系模式的转换规则、UML 六种关系的符号、SQL 的常用语法、常用算法的时间和空间复杂度，这五块是硬骨头，必须一个个啃下来。做法是每块内容看完之后，立刻用一张白纸默写一遍符号或规则，写不出来的回头看，直到能一口气写完。

第二轮二十五天，解决"会写"的问题。按题型分类做历年真题——注意是分类做，不是整套做。今天只做数据流图，明天只做数据库设计，连续做五到八道同类题。这个方法的好处是你能很快发现这类题的出题惯性：数据流图挖空就那几个位置，数据库题问范式就那两种问法。分类做还有一个副产品，你会开始在同类题之间比较"这道比上道难在哪"，这个对比过程本身就是能力的提升。

第三轮二十天，解决"按时写完"的问题。这轮才开始整套掐表做，一周三套左右。掐表的意义不在于检验水平，而在于让你体验"时间不够被迫跳过一道题"的感觉，然后逼自己想清楚：到底该先做哪道、每道题的死线在哪、放弃了怎么办。

5.2 错题本记什么、不记什么

大部分人的错题本最后都变成抄题本，抄了三本，什么也没记住。我的用法是反过来的：不抄题，只记失分点，一句话一条。

比如做完一道数据流图题错了三个地方，我不抄原题，只写三行：

• 数据流端点写成了"读者→借阅记录"，实际应该是"借阅加工→借阅记录"，加工是必填项；
• 数据存储命名照抄题干里的"借阅记录表"而不是"借阅记录"，用词要跟题干完全一致；
• 平衡性检查漏看了一条输入流，下次先把父图该加工的流列清单再对子图。

这三行里的每一条都是可迁移的。下次做同类题，考前扫一眼这三行，同样的错基本不会再犯。而如果抄了一整道题，考前你大概率不会去重读那道题的过程，因为太长了。

错题本还要分成三类：知识盲区（某个规则压根不知道）、审题失误（知道规则但没看出题目在问什么）、书写规范（知道也看懂了但答案写得不对）。三类里提分最快的是第三类，因为它不需要学新东西，只需要改习惯，往往一两周就能见效。

5.3 模拟时的三个自我约束

第一是必须写全。模拟时不要因为"这道题我会"就只写关键词，必须按照考场标准把起点终点、名称、理由全部写出来。因为"会"和"写得出来"是两种能力，中间隔着一层组织语言的成本。

第二是必须按题号分区。答题纸是分区的，你平时练习就该用分区的纸，或者在空白纸上划块。养成"答案只写在指定区域"的习惯，能规避很多低级失分。

第三是必须留出检查时间。模拟时严格执行"100 分钟做完五题、20 分钟检查"的节奏。检查的时候重点看三件事：有没有漏填的空、单位或符号有没有写错、SQL 语句的关键字有没有拼错（SELCET、FORM、WEHRE这种拼写错误在紧张状态下真的会发生）。

6. 考场那两小时的具体操作

6.1 答题顺序：从稳到险，但别死守

我的建议顺序是：数据流图 → 数据库设计 → UML → Java/C++ → 算法。理由是前两类题的答案最"硬"，推出来就是推出来了，不会因为理解偏差全盘错；UML 次之；Java/C++ 只要框架读懂了，五个空能填三四个；算法题放在最后，因为它耗时最长且不确定性最大，万一卡住，前面已经拿到的分不会受影响。

但这个顺序不是死的。如果开考五分钟扫一遍六道题，发现今年的算法题特别眼熟（比如就是你练过的背包改版），那完全可以提前做。灵活的前提是你事先想清楚了各种情况的取舍，而不是临场慌乱。

6.2 时间切分与死线意识

关于"填上最可能的答案"，我要特别说一句：案例卷没有倒扣分，空着一定是零分。就算完全不会，也要根据上下文猜一个填上去。数据流图猜一个合理的名词、SQL 猜一个合理的字段名、算法填空猜一个看起来类型匹配的表达式——这个动作的期望收益是正的。

6.3 通检阶段真正该看的三件事

很多人通检的时候会重做一遍题，这是最浪费时间的做法。通检只做三件低风险高收益的事：

第一，数一遍空。题目挖了五个空，你只填了四个，这种情况每年都有。逐题对照题号数一遍。

第二，检查符号和术语。多重度有没有写成中文，UML 关系有没有题号对应错，SQL 关键字有没有拼错，关系模式有没有标出主键和外键。

第三，看答案的位置。确认每道题的答案都写在了对应的区域里，没有串行。

三件事做完差不多十分钟，剩下五分钟留给自己深呼吸。

6.4 我自己踩过的两个坑

第一个坑是在数据流图上耗太久。第一次做真题的时候，我为了让每条数据流都完美闭环，在那道题上花了将近四十分钟，后面三道题全赶，最后差五分过线。后来我给自己定了死规矩：任何一道题超过 25 分钟就强制收手。案例卷是五道题的总分游戏，不是单题的完美主义竞赛。

第二个坑是语言题选错。有一年 Java 题给的是一个我完全不熟的框架，我硬着头皮读了十二分钟没读懂，最后仓促换到 C++，两边都没做完。这个教训是：读语言题的时候先花两分钟扫一眼框架，如果两分钟内看不出类之间的关系，果断换另一道。两分钟的成本远小于十二分钟。

备考案例分析这件事，说到底就是把手上的知识翻译成采分点的过程。规则是明摆着的，题型是固定那几个，采分点翻来覆去也就那些。真正需要练的不是"再多学一点"，而是"把已经会的写对位置"。我在带人练这套东西的时候，反复强调的一句话是：写完答案之后回头读一遍，问自己"如果我是阅卷人，扫一眼能不能看到分在哪"——能看到，这道题就稳了。