很多程序员都会用 GPT 改代码。
但真正敢把 GPT 当“代码审计员”用的，其实不多。
原因很简单：
大多数时候，GPT 只是帮你“写得更像样”，而不是告诉你“这段代码能不能过”。
一个很现实的问题：
程序员不用任何方法论，直接把代码丢给 GPT，能不能完成代码审计？
答案是：改代码可以，审计不行。
因为代码审计至少要回答一个问题：
在明确需求约束下，这个实现是 PASS 还是 FAIL？
而不是“还能不能优化一下”。
我做了一个最小代码审计样例，只验证一个工程决策
技术栈非常普通：
FastAPI
JWT
单接口、多租户
我只问一个问题：
tenant_id 的唯一可信来源是什么？
最终工程裁决是：
tenant_id 只能来自 JWT payload。
所有请求参数、Header、Path 中的 tenant_id 一律判定为违规。
这是一个冻结决策，没有配置项，没有兜底逻辑。
为什么这是一个“代码审计”问题，而不是“业务设计”问题？
因为一旦 tenant_id 来源不唯一，就会产生三类不可审计风险：
跨租户越权无法被彻底证明不存在
安全问题只能靠“约定”，而不是代码结构
Review 时每个人的理解都不一样
换句话说：
系统是否安全，变成了一个“靠人记得住”的问题。
这个项目不是教学，也不是完整系统
仓库里刻意只保留了五类文件：
requirements.md
冻结需求，禁止解释、禁止扩展implementation/
最小可运行实现，只为验证裁决tests
用失败来证明边界audit/
完整审计输入、拒绝点、差异说明verdict.md
最终裁决：PASS / FAIL（带原因）
这不是“最佳实践”，而是“可复现裁决”。
GPT 在这里扮演的不是“助手”，而是“审计执行者”
关键不在模型多聪明，而在你是否给了它：
明确、冻结、不可协商的需求
明确的违规判定标准
明确的裁决输出格式
当这些条件满足后：
一个 GPT 客户端，就足以承担一次完整的代码审计流程。
为什么我把完整过程放进仓库？
因为如果：
审计结论不能复现
审计标准不能被第三方查看
裁决过程只能“信我说的”
那它就不叫审计。
仓库地址
完整示例在这里（包含实现 + 审计 + 最终裁决）：
👉 https://github.com/yuer-dsl/lsr-method
不需要读完。
你只要看一眼requirements.md和verdict.md，就会明白我在做什么。
结语
大多数安全事故，不是因为代码不会写，
而是因为工程决策从一开始就没有被“冻结”。
当你开始用 GPT 去执行“裁决”，而不是“帮忙想想”，
它的价值会完全不一样。
