晚上十一点半，宿舍灯还亮着。你盯着屏幕上那道动态规划的课后题，已经三个小时没动了。题目要求用最少硬币凑出目标金额，可你的代码总在某个测试点上超时。这不是第一次被算法作业卡住，但这次你决定不抄答案，也不直接搜解析。
习题不是任务，是训练场
很多人把课后习题当成必须完成的任务，做完就扔。其实这些题目是设计好的思维台阶。比如分治法那一章的“最近点对”问题，表面上让你写个算法，实则是引导你理解如何拆解空间复杂度。第一次做可能暴力枚举，第二次你会想到排序剪枝，第三次才真正体会到分治中“合并阶段”的精妙。
有同学在做贪心策略的调度问题时，总想一步写出最优解。结果反复提交都被驳回。后来他试着先写个暴力版本，再观察数据规律，发现任务按截止时间排序后局部最优能推导全局。这个“试错-观察-修正”的过程，比直接记住结论有用得多。
代码实现前，先画张草图
拿到“0-1背包”这类经典题，别急着敲键盘。拿张纸，画出状态转移的过程。比如容量为5，物品重量分别是2、3、4，价值为3、4、5。一步步标出dp数组的变化，你会发现第三件物品加入时，只有容量≥4的位置才可能更新。
这种可视化练习能避免盲目编码。有个学生总在递归边界出错，后来他改用表格填值法手动模拟，才发现自己漏掉了重量恰好等于当前物品的情况。
调试时学会“缩小战场”
当你的Dijkstra算法输出错误路径，别从头读代码。构造一个最小可复现的例子：四个节点，五条边，手动算出最短路径。用这个小例子单步调试，往往五分钟就能定位问题。曾经有人卡在优先队列的更新逻辑，就是因为测试数据太大，根本看不出哪个节点被重复加入。
def knapsack(weights, values, W):
n = len(weights)
dp = [[0 for _ in range(W+1)] for _ in range(n+1)]
for i in range(1, n+1):
for w in range(1, W+1):
if weights[i-1] <= w:
dp[i][w] = max(
dp[i-1][w],
dp[i-1][w - weights[i-1]] + values[i-1]
)
else:
dp[i][w] = dp[i-1][w]
return dp[n][W]和同学讨论，但别只听答案
小组讨论时，有人一上来就说“这题用回溯加剪枝”。这时候别急着记代码，问他怎么想到要剪枝的？是在哪一步发现重复计算的？有个团队在做N皇后时，最初每个人都独立实现，结果发现八个人用了七种不同的剪枝条件。对比之后才明白，约束条件的判断顺序直接影响效率。
真正的收获不在答案本身，而在别人思考的转折点。你可能会意识到，自己一直忽略输入规模的提示——题目给的n≤15，其实就是在暗示搜索可行。
回头看看旧题
两周后重做上周卡壳的归并排序逆序对问题。你会发现之前绕不开的边界处理，现在自然地分成左右两段统计。这不是因为你变聪明了，而是新做的快速排序随机化 pivot 给了你启发。知识的连接往往发生在回顾时，而不是学习当下。
有位同学整理了一个“错题本”，每道题只记两行：错误类型（如边界遗漏）、触发场景（如数组长度为1时）。期末复习时翻出来，比刷十套模拟题都管用。