很多程序员都会用 GPT 改代码。

但真正敢把 GPT 当“代码审计员”用的，其实不多。

原因很简单：
大多数时候，GPT 只是帮你“写得更像样”，而不是告诉你“这段代码能不能过”。

---

一个很现实的问题：

程序员不用任何方法论，直接把代码丢给 GPT，能不能完成代码审计？

答案是：改代码可以，审计不行。

因为代码审计至少要回答一个问题：

在明确需求约束下，这个实现是 PASS 还是 FAIL？

而不是“还能不能优化一下”。

---

我做了一个最小代码审计样例，只验证一个工程决策

技术栈非常普通：

• FastAPI

• JWT

• 单接口、多租户

我只问一个问题：

tenant_id 的唯一可信来源是什么？

最终工程裁决是：

tenant_id 只能来自 JWT payload。
所有请求参数、Header、Path 中的 tenant_id 一律判定为违规。

这是一个冻结决策，没有配置项，没有兜底逻辑。

---

为什么这是一个“代码审计”问题，而不是“业务设计”问题？

因为一旦 tenant_id 来源不唯一，就会产生三类不可审计风险：

1. 跨租户越权无法被彻底证明不存在

2. 安全问题只能靠“约定”，而不是代码结构

3. Review 时每个人的理解都不一样

换句话说：

系统是否安全，变成了一个“靠人记得住”的问题。

---

这个项目不是教学，也不是完整系统

仓库里刻意只保留了五类文件：

• requirements.md
  冻结需求，禁止解释、禁止扩展

• implementation/
  最小可运行实现，只为验证裁决

• tests
  用失败来证明边界

• audit/
  完整审计输入、拒绝点、差异说明

• verdict.md
  最终裁决：PASS / FAIL（带原因）

这不是“最佳实践”，而是“可复现裁决”。

---

GPT 在这里扮演的不是“助手”，而是“审计执行者”

关键不在模型多聪明，而在你是否给了它：

• 明确、冻结、不可协商的需求

• 明确的违规判定标准

• 明确的裁决输出格式

当这些条件满足后：

一个 GPT 客户端，就足以承担一次完整的代码审计流程。

---

为什么我把完整过程放进仓库？

因为如果：

• 审计结论不能复现

• 审计标准不能被第三方查看

• 裁决过程只能“信我说的”

那它就不叫审计。

---

仓库地址

完整示例在这里（包含实现 + 审计 + 最终裁决）：

👉 https://github.com/yuer-dsl/lsr-method

不需要读完。
你只要看一眼 requirements.md 和 verdict.md，就会明白我在做什么。

---

结语

大多数安全事故，不是因为代码不会写，
而是因为工程决策从一开始就没有被“冻结”。

当你开始用 GPT 去执行“裁决”，而不是“帮忙想想”，
它的价值会完全不一样。