使用 GPT 作为代码审计员（而非代码生成器）

Source: Dev.to

为什么 “GPT 代码审查” 往往让人不满意

你可能也做过这种事：

“这是我的代码。能帮我审查一下吗？”

得到的反馈通常是合理的：

• 重构思路
• 边界情况
• 风格改进

但缺少了一件事：决定。
实现是可以接受的——还是不可接受的？

一个最小实验

我构建了一个刻意保持简洁的项目来进行探索。

• FastAPI
• JWT
• 单一端点
• 多租户数据访问

并且我冻结了唯一的工程决策：

tenant_id 必须来自 JWT 负载——不能来自其他任何地方。
没有配置开关。要么代码强制执行此决策，要么就会失败。

为什么这是审计问题，而不是设计争论

当 tenant_id 可以来自查询参数、请求头、请求体或 JWT 时：

• 跨租户访问难以彻底排除
• 安全性依赖约定而非强制执行
• 审查会变成讨论而不是判断

审计的意义在于：在这些冻结的需求下，能够说实现 通过 还是 不通过。

将 GPT 变成审计员

这里使用 GPT 并不是为了创意或巧思。它的角色被严格限制为：

1. 将实现与冻结的需求进行对比
2. 识别违规或歧义
3. 给出可复现的判定结果
4. 解释原因

一旦决策面冻结，GPT 就停止给出建议，转而进行判断。

仓库里有什么

该仓库刻意保持极简：

• 冻结的需求（requirements.md）
• 最小实现代码
• 展示失败案例的测试
• 结构化审计轨迹
• 最终判定

这 不是 一个框架或教程。

仓库

你可以在这里找到完整示例：
👉

如果只阅读一个文件，请从 requirements.md 开始。

最后思考

大多数代码审查的痛点并非来自糟糕的代码。
只有在这些决策被明确之后，GPT 才能在审计中发挥作用。