第1章 当你让 AI 帮你写代码时，你还需要懂算法吗？
一个真实的故事
2024年，某互联网公司的工程师小李接到了一个任务：优化推荐系统的响应时间。系统在高峰期响应变慢，用户投诉增多。
小李打开 Cursor，输入提示词：
"帮我优化这个推荐函数，现在太慢了"
Cursor 很快给出了一个"优化版"。代码看起来更现代了，用了更 Pythonic 的写法，加了一些类型注解。小李运行了测试用例，全部通过，于是提交了代码。
一周后，高峰期来了。系统比以前更慢了。
问题出在哪里？Cursor 给的代码只是"看起来更现代"，但算法复杂度从 O(n log n) 变成了 O(n²)。小李没有发现，因为他不知道如何判断一个算法的复杂度。他只知道"代码能跑"。
这个故事不是个案。当 coding agent 成为标配，"能写代码"不再是核心竞争力，"能判断代码对不对"才是。
如果小李懂算法，他会怎么做？
让我们看看同一个任务，如果小李掌握了算法判断能力，会发生什么。
第一步：他先回答"我在解决什么问题"
小李没有立刻把模糊需求丢给 Cursor。他先问自己：
- 系统慢，是在什么场景下？（高峰期，用户量约 10 倍正常）
- "推荐函数"到底在做什么？（从候选商品中筛选匹配项，按评分排序）
- 现在的实现是什么复杂度？（他打开原代码，发现是快速排序，期望 O(n log n)）
- 数据规模有多大？（平时 1 万候选，高峰期 10 万）
他把这些信息写在一张问题规格卡里：
问题：筛选并排序推荐商品
输入：candidates 列表（约 10 万），用户偏好条件
输出：Top-20 匹配商品，按评分降序
约束：响应时间 < 100ms（高峰期）
当前实现：QuickSort，期望 O(n log n)
怀疑：某些数据分布可能导致退化第二步：他建立了自己的预测基线
在碰 AI 之前，小李先写下自己的判断：
- 最简单基线：直接遍历，O(n) 筛选 + O(n log n) 排序
- 如果数据接近有序，QuickSort 可能退化到 O(n²)
- 他担心的高峰场景：热销商品集中，评分分布不均匀
第三步：他给 Cursor 一个带约束的提示词
小李没有说"帮我优化"，而是说：
现有推荐函数使用 QuickSort，候选商品约 10 万，高峰期要求 < 100ms。请先分析：这个实现在什么数据分布下会退化？给出一个最小反例证明退化可能性。然后提出一个不退化的方案，并说明复杂度。
Cursor 回答：
当数据接近有序或存在大量重复评分时，QuickSort 可能退化到 O(n²)。反例：候选商品评分全为 5 分，每次划分几乎不减少问题规模。建议改用 HeapSort（总是 O(n log n)）或只排序 Top-20（用堆维护，O(n log k)）。
第四步：他审查了 Cursor 的建议
小李没有立刻接受。他做了三件事：
验证反例：他构造了一个测试数据，评分全相同，用原代码跑 10 万条，耗时从 10ms 变成 3000ms——反例成立。
复杂度对比：他判断 Top-20 堆方案是 O(n + k log n) ≈ O(n)，比 O(n log n) 更优，因为 k=20 很小。
边界测试：他问 Cursor："如果候选少于 20，这个堆方案是否正确？"Cursor 立刻给出边界处理建议。
第五步：他留下了一份推理收据
小李在提交代码时，附带了一张判断记录：
问题规格：10 万候选，Top-20，< 100ms
原方案风险：QuickSort 在评分重复时退化到 O(n²)
反例验证：10 万相同评分 → 3000ms（原）vs 15ms（新）
新方案复杂度：O(n log 20) ≈ O(n)
接受理由：反例证明风险存在，新方案有数学保证
剩余风险：需测试内存占用变化结果
一周后高峰期来了。系统稳定运行，响应时间从原来的 50ms 变成了 12ms。
小李没有被报警叫醒。他知道代码是对的，因为他先建立了自己的判断，再用 AI 辅助检查，而不是反过来。
两种路径的对比
| 小李不懂算法 | 小李懂算法 |
|---|---|
| 输入模糊需求"帮我优化" | 先写问题规格卡 |
| AI 给代码，直接采纳 | 先写预测锁，再让 AI 建议 |
| 只跑几个测试用例 | 构造反例验证风险假设 |
| 不知道复杂度变了 | 对比复杂度，判断是否满足约束 |
| 出问题后不知道原因 | 留下推理收据，可追溯决策 |
| 结果：高峰期崩溃 | 结果：稳定运行，响应更快 |
这正是本书要教你的能力：不是写代码，而是判断代码对不对。
为什么你还需要学算法
也许你会想：既然 AI 能写代码，为什么我还要学算法？
答案是：你需要学的不是"怎么写"，而是"怎么判断"。
判断什么？
判断问题的结构是什么。判断该用什么方法。判断 agent 给出的实现是否正确。判断复杂度是否合理。判断边界情况有没有被遗漏。
这些判断能力，agent 可以辅助你训练和检查，但不能替你承担最终责任。它主要根据你给出的描述工作；如果问题描述错了，它给出的代码再漂亮也可能解决错问题。
这本书要教给你的，就是这些判断能力——以及用这些能力与 AI 协作的方法。
本章核心洞察
算法不是教你怎么写代码，而是教你如何判断代码对不对。
在 AI 时代，判断能力比编码能力更重要。
这一章会学到什么
这一章要建立的是一种思维方式。
我们会从最基本的问题开始：当你拿到一个任务，不管是自己写还是让 agent 写，你首先要回答什么问题？
然后我们会学习一套系统化的分析方法——六问诊断法。这不是教你写代码，而是教你如何思考一个问题。我们会用一个完整的问题"判断图是否有环"贯穿六问法，让你看到整套方法的实际应用。
我们会学习如何验证一个算法是否正确——用循环不变式证明正确，用反例证明错误。这两件武器在 agent 时代更重要，因为你要检验 agent 给你的代码。
我们会学习复杂度分析——判断一个算法是否满足你的时间和空间约束。agent 给你的代码可能是 O(n²) 的；如果你没有提供数据规模和时间要求，它很可能无法判断这个方案是否够用。
最后，我们会学习建模——把现实问题翻译成算法语言。这通常需要人理解真实目标、隐含约束和取舍，再让 agent 辅助实现或检查。
如何阅读这一章
这一章的内容不需要你有任何编程基础。如果你已经熟悉算法，可以快速浏览，重点关注"agent 时代"的视角和六问法的完整示例。
每个小节后面都有练习。这些练习不是让你"实现一个算法"，而是让你"检验一个实现"、"分析一个问题"、"做出一个判断"。这才是 agent 时代你需要的能力。
章节末尾有一张六问法思考骨架图，可以作为日常工作的快速参考。
让我们开始吧。
本章各节：