title: " AI代码Review | 上线前风险审查" category: 人工智能 tags:

AI 做代码 Review，很容易跑偏。

它可能输出一堆：

命名可以更清晰。
建议加注释。
这里可以提取函数。

这些不一定错。

但上线前最重要的不是风格。

而是：

会不会出事故。

Fable 5 这类高级模型很适合做上线前风险审查。

前提是 Prompt 写清楚：

只看真实风险，不看审美建议。

1. AI Review 要分层

类型 模型
PR 摘要 低成本模型
风格建议 中低成本模型
上线风险 Fable 5
安全/权限 Fable 5
回滚方案 Fable 5

不要让 Fable 5 去写普通 PR 摘要。

把它用在关键审查。

2. 给 AI 的 Review 包

【目标】
- 本次变更要解决什么：
- 上线范围：
- 是否生产：

【材料】
- git diff：
- 相关测试结果：
- 迁移文件：
- 配置变更：
- 4SAPI 调用变更：

【重点检查】
- 权限
- 数据库
- 日志
- 回滚
- 成本
- 并发
- 错误处理
- 兼容性

【边界】
- 不评价纯风格
- 只输出 P0/P1/P2 风险
- 没证据不输出

3. 重点一：数据库迁移

AI 要检查：

是否破坏性迁移。
是否有默认值。
是否会锁表。
是否兼容旧代码。
是否有回滚。

尤其是：

删除字段。
改字段类型。
加非空字段。
大表加索引。

这些都要标高风险。

4. 重点二：4SAPI 调用和成本

如果代码改了模型调用，要看：

模型是否从低成本换成 Fable 5。
是否增加上下文。
是否增加重试。
是否新增循环。
是否记录 task_id。
是否处理 401/429/504。

很多 AI 功能上线事故不是代码崩。

是账单崩。

5. 重点三：权限和密钥

AI Review 必须检查：

API Key 是否进前端。
日志是否打印密钥。
用户是否能越权查数据。
后台接口是否缺鉴权。
Webhook secret 是否暴露。

这些比命名重要一万倍。

6. 重点四：测试证据

AI Review 不能只看 diff。

还要看测试证据。

给 Fable 5：

测试命令。
测试结果。
失败日志。
覆盖了哪些路径。
哪些路径没有覆盖。

让它判断：

当前测试是否覆盖本次风险。
是否只有 happy path。
是否缺少权限、失败、重试、超时、预算边界。

对于 4SAPI 接入相关代码，测试至少要覆盖：

401。
429。
504。
fallback。
预算超限。
Key 无权限。
模型返回格式错误。

7. Review 报告模板

# 上线前风险审查

结论：可以上线 / 阻塞上线 / 需要补充验证

P0 风险：
P1 风险：
P2 风险：

测试证据：
未覆盖风险：
需要人工确认：
上线观察项：
回滚建议：

这份报告比普通代码点评更适合发给团队。

8. Prompt

你是上线前代码风险审查员。

请审查当前 diff。
只输出可能导致生产事故、数据错误、安全问题、成本异常或无法回滚的问题。

不要输出命名、风格、注释、重构建议，除非它们会导致真实事故。

每条问题必须包含：
- 风险等级 P0/P1/P2
- 证据位置
- 触发条件
- 影响
- 修复建议
- 是否阻塞上线

9. 4SAPI 治理

建议把代码 Review 也纳入 4SAPI：

review_key
review_model
pr_id
repo
risk_count
cost
human_reviewed

低风险 PR 用中等模型。

高风险 PR 升级 Fable 5。

10. 示例：模型调用代码 Review

假设 PR 改了：

把客服摘要从低成本模型切到 Fable 5。
把 max_tokens 从 800 改到 4000。
失败后最多重试 5 次。
没有记录 task_id。

普通 Review 可能只看代码能不能跑。

Fable 5 应该指出：

P1：低价值高频任务切到 Fable 5，可能导致成本暴涨。
P1：max_tokens 增加 5 倍，没有预算说明。
P1：重试 5 次可能在 429 时放大成本。
P2：没有记录 task_id，后续无法按用户和项目追踪成本。

这就是上线前 AI Review 的价值。

它不只看代码。

它看运行后的后果。

11. Review 前置材料清单

PR diff。
变更目的。
测试结果。
相关配置。
数据库迁移。
模型调用变化。
预算影响。
回滚方案。

材料越完整，AI Review 越像审查。

材料越少，它越像猜测。

12. 风险分级要写清楚

AI Review 最怕输出一堆“建议”。

上线前更应该输出风险等级。

可以这样定义：

P0：可能导致数据丢失、越权、资金损失、全站不可用。
P1：可能影响核心流程、明显增加成本、导致部分用户不可用。
P2：可修可不修，但会增加维护成本或排查难度。

对应处理规则：

等级 处理方式
P0 阻塞上线，必须修
P1 默认阻塞，除非负责人签字接受风险
P2 可排期，但要记录

这能防止 AI Review 变成“意见很多但没有决策力”。

让 Fable 5 输出时可以加一句：

每条风险必须说明是否阻塞上线，不允许只写建议。

13. 和 CI/CD 结合

AI Review 不一定只在人工发起时跑。

可以接到 CI/CD：

PR 创建时：低成本模型生成摘要。
PR 改了模型调用代码：自动触发 Fable 5 风险审查。
PR 改了数据库迁移：触发迁移审查。
PR 改了权限或 Key 逻辑：触发安全审查。
上线前：生成风险报告。

4SAPI 可以记录：

pr_id
commit_sha
review_type
model
risk_count
cost
human_decision

这样你能复盘：

哪些 PR 经常触发成本风险。
Fable 5 找出的 P1 最后有没有真的被修。
AI Review 花的钱有没有减少事故。

这才是高级模型的正确用法。

不是每个 PR 都豪华审一遍。

而是让它出现在最可能出事故的地方。

14. 上线后的观察项

AI Review 不是合并前结束。

真正稳的做法是让它顺手生成上线观察项：

上线后 30 分钟看什么。
上线后 2 小时看什么。
上线后 1 天看什么。
哪些指标异常要回滚。
哪些日志能证明新逻辑生效。

比如改了 4SAPI 模型调用逻辑，观察项可以是：

新模型调用量是否符合预期。
Fable 5 调用是否只出现在高价值 task_type。
401/403/429/504 是否上升。
平均 input_tokens 是否异常变大。
重试次数是否增加。
fallback 是否正常生效。
成本是否超过预算阈值。

这部分特别适合低成本模型先生成，再让 Fable 5 审一遍高风险项。

上线观察项的价值是：

把“上线后看一下”变成具体指标。

很多事故不是上线时立刻爆炸。

而是几个小时后成本、队列、失败率慢慢爬上来。

如果 Review 阶段就把观察项写进发布单，值班同学会轻松很多。

15. 总结

AI Review 不是让模型点评代码漂亮不漂亮。

而是让它帮你找：

上线事故。
数据风险。
安全风险。
成本风险。
回滚风险。

一句话：

上线前的 AI Review，要像事故预演，不像作文批改。