周四的代码审视时刻
周一写代码，周二修bug，周三赶进度。到了周四，功能基本成型，正是回头看代码的好时机。
但大多数人这时候的选择是：继续往前冲，或者干脆不看了。
结果呢？代码越堆越多，问题越藏越深。三个月后，一个简单的改动能拆出八个bug。
周四下午，用10分钟让AI帮你扫一遍代码，比三个月后花三天debug划算得多。
这个模板帮你把AI变成技术债审计师——不吹毛求疵，但能找出真正有风险的点。
核心模板：代码质量审查
把下面这段复制到 ChatGPT 或 Claude，然后粘贴你的代码：
你是一位有10年以上经验的资深工程师，擅长代码审查和技术债评估。你的风格是：直接、务实、不吹毛求疵。
【项目背景】
- 项目类型：[比如：Web后端API / 前端SPA / 数据处理脚本 / 移动端App]
- 技术栈：[语言 + 主要框架/库]
- 当前阶段：[刚起步 / 开发中 / 即将上线 / 维护期]
- 团队规模：[X人]
【待审查的代码】
[粘贴你的代码，可以用多个代码块]
【你最关心的点】（可多选）
- [ ] 有没有明显的bug或逻辑错误
- [ ] 有没有安全隐患
- [ ] 可维护性如何（别人能不能看懂）
- [ ] 性能方面有没有大问题
- [ ] 架构设计是否合理
- [ ] 代码重复度
请帮我做以下分析：
第一部分：严重问题（必须修复）
- 列出所有会导致运行时错误、数据丢失、安全漏洞的问题
- 每条：问题在哪行/哪个函数，为什么严重，怎么修
第二部分：中等风险（建议修复）
- 可维护性问题、潜在的性能瓶颈、不够优雅的写法
- 每条：问题是什么，修复的成本和收益
第三部分：小优化（可选）
- 命名建议、代码风格、可以简化的地方
- 用列表形式，不展开
第四部分：技术债评分
- 给这段代码一个技术债评分（1-10，10最干净）
- 一句话总结：这段代码最大的优点和最大的风险各是什么
第五部分：重构建议（如果有值得重构的地方）
- 最值得重构的部分是哪一段
- 重构后能带来什么具体收益
- 分几步重构风险最小
三种场景变体
变体一：新写模块的自检
刚写完一个功能，不确定写得怎么样？用这个版本快速自检：
我刚写了一段代码，帮我做快速自检：
【功能描述】
[用一句话描述这段代码做什么]
【代码】
[粘贴代码]
请重点检查：
1. 边界条件——用户输入极端值时会崩吗？
2. 错误处理——出错时不会静默失败吧？
3. 可读性——六个月后的我还能看懂吗？
4. 有没有"明显不对"的地方？
只告诉我需要修改的地方，没问题的不要说。
变体二：遗留代码摸底
接手别人的烂代码，想知道有多烂？用这个版本：
我接手了一段遗留代码，想先摸清状况：
【项目背景】
- 这段代码是什么时候写的：[大概时间]
- 原来的作者还在不在：[在/不在]
- 有没有文档：[有/基本没有]
【代码】
[粘贴你打算修改的那部分代码]
请帮我：
1. 先给这段代码打个总分（1-10）
2. 列出"不动它也会爆雷"的风险点（按紧急程度排序）
3. 如果要改，建议从哪一段开始，为什么
4. 改造时需要特别小心哪几个地方
语气务实一点，不用客气。
变体三：上线前的最后一道检查
功能做完了，上线前让AI帮你再过一遍：
代码已经review过、测试也过了，上线前做最后一道检查：
【功能描述】
[做什么的]
【已知的测试覆盖情况】
[比如：核心逻辑有单测，边界条件没测]
【部署环境】
[比如：生产环境是K8s集群，有监控告警]
【代码】
[粘贴核心逻辑部分]
请重点帮我找：
1. 可能导致线上事故的问题（数据不一致、并发问题、资源泄漏）
2. 监控盲区——出了问题我们能不能及时发现？
3. 有没有"正常情况OK、异常情况炸"的场景？
4. 如果必须上线，最应该加什么保护措施？
快速版（3分钟搞定）
赶时间，快速扫一眼：
帮我审查这段代码，只说问题，不说好话：
[粘贴代码]
检查：bug、安全风险、明显反模式。按严重程度排序。
使用技巧
一次只审查一个函数或模块。 把整个项目扔给AI，它只会给你泛泛而谈。聚焦在一个具体问题上，输出才有用。
告诉AI你的项目阶段。 “即将上线"和"刚起步"的审查标准完全不同。前者要关注风险，后者要关注方向。
让AI用你的语境说话。 如果是Java项目就别让它拿Python的风格来挑刺。在提示词里写明技术栈和团队规范。
把AI的审查结果和你自己的判断对比。 AI能发现你看不到的盲点，但也会误报。关键是学会区分"真正的问题"和"风格偏好”。
审查完立刻记录。 把AI发现的严重问题记到TODO列表或issue里。否则三天后就忘了。
效果示例
输入：
【项目背景】
- 项目类型：Node.js后端API
- 技术栈：Express + MongoDB
- 当前阶段：开发中，即将进入测试
【待审查的代码】
const getUserOrders = async (userId) => {
const user = await User.findById(userId);
const orders = await Order.find({ user: userId });
return orders.map(o => {
return {
id: o._id,
total: o.items.reduce((sum, item) => sum + item.price * item.qty, 0),
user: user.name
};
});
};
app.get('/api/orders', async (req, res) => {
const orders = await getUserOrders(req.query.userId);
res.json(orders);
});
AI 输出：
第一部分：严重问题
N+1查询问题：先查User，再查Order，但Order查询用了
userId而不是user._id。如果Model定义不一致，可能查不到数据或返回错误数据。修复：统一用user._id查询。缺少错误处理：
User.findById如果返回null（用户不存在），后续user.name会直接崩溃（Cannot read properties of null）。修复：加null检查。SQL注入风险（概念上）：虽然用的是MongoDB，但
req.query.userId没有做任何验证。如果注入恶意值，可能查询到不属于自己的订单。修复：验证userId格式，加权限检查。
第二部分：中等风险
性能：
orders.map里每次都要遍历o.items计算总价，如果items数组很大，应该在数据库层面聚合。建议用MongoDB的$lookup+$group聚合管道。无分页：订单列表没有分页，数据量大时会拖垮接口。
第三部分：小优化
total计算可以抽成函数- 响应格式统一用
{ data: ..., total: ... } - 加上请求日志
第四部分：技术债评分 — 5/10
核心逻辑有，但缺少防御性编程。短期能跑，长期是雷。
第五部分：重构建议
优先修复错误处理和权限校验，然后把查询改成聚合管道。两步搞定，风险最小。
---
## 代码审查 vs 普通Review的区别
| 维度 | 普通Code Review | AI辅助审查 |
|------|---------------|-----------|
| 速度 | 需要人花时间 | 10秒出结果 |
| 视角 | reviewer的主观判断 | 覆盖更多边缘场景 |
| 情绪 | 容易带个人偏好 | 客观、不针对人 |
| 深度 | 受reviewer经验限制 | 能指出你可能不知道的模式 |
| 局限 | 人疲劳时会漏 | 可能误报风格问题 |
| 最佳用法 | 看逻辑和设计 | 快速扫错、补盲点 |
---
## 什么时候不该用
- **代码还没写完。** 半成品审查意义不大，等你写完一个完整模块再丢进去。
- **你完全不了解这段代码。** AI给你指出了3个问题，但你看不懂哪行是问题所在——这种情况下，先补基础知识，或者找同事一起看。
- **安全敏感代码。** 涉及到密码、密钥、支付逻辑的代码，AI审查不能替代专业安全审计。AI只能做第一道筛子。
---
## 组合使用技巧
**代码审查 + 周一任务拆解。** 周一用`monday-task-triage`规划本周要改的代码，周四用这个模板做质量审查，周末前收尾。形成"规划-执行-检查"的闭环。
**代码审查 + 周五知识沉淀。** 审查过程中发现的经典模式（比如某个反复出现的bug），写一条笔记到`saturday-personal-knowledge-base`。长期积累就是你的避坑手册。
**代码审查 + 周四决策框架。** 如果审查后发现需要重构一个大模块，用`thursday-decision-framework`评估：重构还是重写，投入多少，风险在哪。
---
## 写在最后
周四下午，代码基本稳定了。与其急着推进下一个功能，不如花10分钟让AI帮你照照镜子。
它会告诉你：这里有个雷，那里有个坑，这个写法会让半年后的你骂现在的你。
代码写得再好，也不是写出来就完事了。**能回头看看的人，代码才越写越稳。**
把这段代码丢进去，看看AI会说些什么。