04 - 代码优化¶

在 AI 编程时代，优化不再只是“把代码写快一点”。更真实的优化目标是：更快、更稳、更省、更容易维护。这一章会把优化从零散技巧，升级成可落地的工程决策。

这章解决什么问题¶

很多人做优化时有两个问题：

• 没有测量，只凭感觉
• 只优化运行时，不优化复杂度、成本和维护性

AI 介入后，还多了一个常见问题：

• 模型会产出“看起来更高级”的代码，但不一定更适合当前仓库

所以本章的核心不是“多学几个优化技巧”，而是学会一套 定位 -> 选择 -> 验证 -> 回滚 的优化流程。

学习目标¶

• 学会区分性能优化、结构优化、成本优化、认知复杂度优化
• 学会先测量再优化，而不是先改再解释
• 学会用 AI 帮你找候选优化点，但自己做最后决策
• 把优化过程沉淀成项目证据链和面试表达

优化不是一个维度¶

建议把“代码优化”拆成下面 4 类。

2028 的 AI4SE 项目里，最后一类尤其重要。

优化前先问 4 个问题¶

1. 现在真正的瓶颈在哪里
2. 优化目标是延迟、成本还是可维护性
3. 这个问题值不值得现在动
4. 如果改坏了，怎么验证和回滚

这 4 个问题能避免大量“伪优化”。

一套实用的优化流程¶

测量现状
→ 定位瓶颈
→ 形成候选方案
→ 选择最小可行改动
→ 跑 benchmark / test
→ 观察收益和副作用
→ 决定合并、继续优化或回滚

AI 最适合帮你做的是中间三步：

• 找候选点
• 提方案
• 产出 patch

但第一步和最后两步，必须由你主导。

4 类最常见的优化任务¶

先分清任务类型，才能避免把完全不同的优化问题混成一锅。

1. 热点路径性能优化¶

常见场景：

• 慢接口
• 慢查询
• 排序/检索耗时过高
• 重复计算

处理顺序¶

1. 先加指标或日志
2. 找到最慢点
3. 看是算法、I/O、网络还是序列化问题
4. 再让 AI 提方案

如果没有测量，AI 很容易“优化错地方”。

2. 代码结构和模块优化¶

常见场景：

• controller 太胖
• service 混业务和基础设施
• 工具函数散落
• 重复逻辑过多

这种优化的收益通常体现在：

• 更容易 review
• 更容易补测试
• 更容易继续迭代

3. 复杂度优化¶

常见信号：

• 多层嵌套
• 过长函数
• 分支过多
• case 越补越难懂

这种优化看起来不如性能优化“酷”，但对真实团队价值很高。

4. AI 时代特有的成本优化¶

这是现在非常值得单独看的部分。

典型对象：

• prompt 太长
• context 太乱
• 同样的检索和总结被重复做
• 大模型调用太频繁
• 没有缓存和路由策略

你可以把这类优化理解成“让 AI 系统更便宜、更可控”。

AI 在优化中的正确角色¶

AI 适合：

• 找重复代码
• 找复杂分支
• 识别低效实现
• 提供重构草案
• 生成 benchmark 或测试

AI 不适合直接替你决定：

• 哪个 trade-off 更值得
• 哪个性能收益足以抵消复杂度增加
• 哪个模块当前最值得动

换句话说，AI 擅长候选方案，人负责决策优先级。

一个适合复用的优化模板¶

任务：优化订单列表接口的响应时间

现状：
- P95 延迟约 780ms
- 主要出现在带筛选条件的请求

范围：
- `src/orders/service.ts`
- `src/orders/repository.ts`
- 对应测试和 benchmark

约束：
- 不改变 API 返回格式
- 不新增运行时依赖
- 不改数据库 schema

请先输出：
1. 可能瓶颈点
2. 建议的测量方式
3. 最小优化方案
4. 风险点

确认后再执行：

按确认方案修改代码，并补充：
- benchmark 或性能测试
- 回归测试
- 改动收益说明

优化时最值得做的 5 件事¶

这 5 件事看起来基础，但恰好决定了优化是不是可验证、可复盘、可持续。

1. 先做基线¶

至少记录：

• 当前延迟 / 吞吐 / 内存
• 当前测试结果
• 当前成本

没有 before，就没有真正的 after。

2. 优先做最小收益比高的改动¶

例如：

• 去掉重复查询
• 增加缓存
• 把重复逻辑抽出来
• 减少不必要模型调用

这些通常比大重构更划算。

3. 每次只优化一个主目标¶

例如这一轮只追：

• 延迟
• 或成本
• 或可维护性

不要一次同时追三件事，否则很难判断效果来源。

4. 补验证和 benchmark¶

优化不是“改完觉得更好”，而是“改完有证据更好”。

5. 写清副作用¶

例如：

• 代码可读性下降
• 缓存一致性更复杂
• 测试成本上升

这是面试里非常加分的一点。

4 个高价值优化方向¶

如果时间和资源有限，优先做下面这 4 个方向，通常收益最高也最容易证明。

方向 1：算法和数据结构¶

最典型，也最容易量化。

例如：

• 列表查找改哈希表
• 双重循环改索引
• 全量扫描改分页或增量

方向 2：I/O 和外部调用¶

真实系统里很多慢，不是因为算法，而是因为：

• 数据库
• 网络
• 文件
• RPC
• 模型调用

这类问题往往收益更高。

方向 3：缓存与复用¶

很适合 AI 系统和 RAG 系统。

例如：

• prefix cache
• 语义缓存
• 检索结果缓存
• 热点 query 缓存

方向 4：结构性重构¶

例如：

• 把复杂判断拆成策略
• 提取 service
• 拆 controller
• 统一错误处理

这类优化更容易转化成“可维护性提升”的面试表述。

一个优化 checklist¶

每次优化前后，你都可以用这一版：

• 是否明确了主目标
• 是否有基线数据
• 是否限定了修改范围
• 是否跑了 benchmark / test
• 是否说明了副作用
• 是否有回滚方案

2028 面试里怎么讲优化¶

不要说：

我用 AI 优化了代码性能。

更好的表达是：

我先通过日志和基准测试定位到热点路径，再让 AI 给出候选优化方案。
最终选择了改动最小的一版，配合 benchmark 和回归测试验证收益，同时保留回滚方案，避免为了追求性能引入过高复杂度。

这段话体现的不是“会优化”，而是“会做工程取舍”。

简历怎么写更有效¶

差的写法：

优化了系统性能。

好的写法：

定位并优化订单查询热点路径，减少重复数据库访问并补充基准测试，使核心接口 P95 延迟从 780ms 降至 320ms，同时保持返回协议兼容。

如果是 AI 系统：

为 RAG 链路增加检索缓存和模型路由，降低重复大模型调用频率，在保持回答质量的前提下降低单请求成本。

最容易犯的 5 个错误¶

1. 不测量直接改¶

2. 把“看起来高级”当成优化¶

3. 优化收益很小，却引入大量复杂度¶

4. 没有补测试和 benchmark¶

5. 没想过回滚¶

本章小结¶

• 优化不是单点技巧，而是工程决策
• AI 适合提供候选方案，但不适合替你做最终 trade-off
• 2028 真正值钱的优化能力，是 能测量、能证明、能解释、能回滚

下一步¶

• 继续看 05-测试生成
• 再看 06-文档生成
• 配合 07-实战项目 把优化过程沉淀成项目资产