识别AI模型伪升级：六维技术校验法拆解话术陷阱

1. 这不是“检测AI模型真伪”，而是识别营销话术的技术拆解现场

最近刷到不少标题党内容：“Claude Opus 4.7 正式开源！”“GPT-5 已上线，支持多模态推理！”“国内可直连 Opus 超强版本！”——点进去一看，要么是 GitHub 上一个空仓库配了张 MidJourney 生成的“控制台截图”，要么是某 Discord 频道里几行 curl 命令加一句“已验证可用”，再配上带感叹号的结论。我连续两周蹲守主流 AI 社区、技术论坛和开源托管平台，把近三个月内所有标称含 “Opus 4.7” 或 “GPT-5” 的项目、仓库、PR、issue、Discord 消息、Telegram 群公告都做了归档比对，发现一个高度一致的现象：92.3% 的所谓“Opus 4.7/GPT-5 开源实现”，其技术实质既不涉及 Anthropic 官方模型权重，也不包含 OpenAI 的任何闭源架构逻辑，甚至连基础的模型加载流程都缺失；它们真正复用的，是公开可查的旧版模型接口封装、前端渲染层魔改、以及一套高度模板化的“高阶能力话术生成器”。

这根本不是模型能力升级，而是一场围绕“命名权”与“认知差”的工程化话术投喂。你不需要懂 Transformer 的 attention mask 实现，但必须能一眼识破“伪 Opus”在六个技术维度上的结构性破绽。这不是教你怎么“信”，而是给你一套可验证、可复现、可写进 CI/CD 流水线的反话术工具链。它适用于三类人：一线算法工程师要快速过滤无效技术信息，开源项目维护者需甄别 PR 中混入的虚假能力声明，以及所有正在评估大模型技术栈落地可行性的技术决策者。核心关键词就六个：模型标识一致性、API 协议兼容性、响应结构可溯性、推理时序真实性、token 分布合理性、依赖图谱透明性——它们共同构成一张“非真即假”的硬性校验网，没有模糊地带。

我试过用这套方法筛掉 17 个“GPT-5 接口封装库”，其中 12 个在第二步（API 协议兼容性）就暴露问题：它们声称支持gpt-5-turbo模型名，但实际请求发往的 endpoint 是https://api.openai.com/v1/chat/completions，而 OpenAI 官方文档明确列出当前支持的模型列表中，最高版本为gpt-4o，且gpt-5从未出现在任何正式 API 文档、OpenAPI Schema 或 SDK 源码中。更讽刺的是，有 3 个项目在 README 里写了“基于 GPT-5 架构重训”，但其训练脚本train.py里调用的transformers.AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B")—— 这是 Llama 3 的权重路径，跟 GPT 系列毫无关系。这种错位不是疏忽，是刻意设计的认知迷雾。接下来，我会带你逐层撕开这层迷雾，每一步都附带可直接运行的验证命令、原始日志片段、以及我在真实排查中踩出的坑。

2. 维度一：模型标识一致性 —— 从 model 字段开始做“户籍核查”

所有声称接入“Opus 4.7”或“GPT-5”的服务，第一个必须校验的字段，就是 API 响应体中的"model"键值。这不是一个可选配置项，而是模型身份的法定身份证。Anthropic 和 OpenAI 的官方 API 均强制要求该字段精确匹配其发布的模型代号，且该代号在每次请求响应中必须与请求头、请求体、服务端日志三者完全一致。伪项目最常在此处露馅，因为开发者往往只改了前端显示文字，忘了后端返回的 JSON 里还藏着真相。

我们以一个典型“伪 Opus 4.7”项目为例（GitHub 仓库名：claude-opus-47-pro，star 数 2.4k）。它的 README 写着：“支持全量 Opus 4.7 功能，包括长上下文、代码解释、多轮推理”。我们先不做任何假设，直接发起一次标准请求：

curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-opus-4.7", "messages": [{"role": "user", "content": "你是谁？"}], "max_tokens": 100 }'

得到响应如下（已脱敏）：

{ "id": "chatcmpl-abc123", "object": "chat.completion", "created": 1718923456, "model": "claude-3-opus-20240229", "choices": [{ "index": 0, "message": { "role": "assistant", "content": "我是 Claude，由 Anthropic 开发的 AI 助手。" }, "finish_reason": "stop" }] }

注意看"model"字段：它返回的是claude-3-opus-20240229，这是 Anthropic 官方发布的 Opus 3 版本（发布于 2024 年 2 月 29 日），而非项目宣称的 “4.7”。这个字段不是前端 JS 渲染出来的，它是服务端直接写入响应体的硬编码字符串。为什么会出现这种错位？我翻看了该项目的后端源码（app/routers/chat.py），发现关键逻辑：

# app/routers/chat.py 行 47-52 if request.model == "claude-opus-4.7": # 降级路由：映射到官方 Opus 3 actual_model = "claude-3-opus-20240229" else: actual_model = request.model response = await anthropic_client.messages.create( model=actual_model, ... )

这里暴露了第一个结构性破绽：它没有“实现”Opus 4.7，只是把用户输入的 model 名字做了字符串替换，然后转发给真正的 Anthropic API。这种做法本身不违法，但项目方在宣传中刻意模糊了“代理”与“实现”的边界，用“支持 Opus 4.7”替代“代理请求至 Opus 3”，这就是话术陷阱的起点。

提示：真正的模型标识一致性，必须满足“请求 model 名 = 响应 model 名 = 服务端实际加载的权重文件名 = 模型卡（model card）中声明的版本号”。四者缺一不可。任何一项不一致，即判定为标识欺诈。

更隐蔽的坑在于模型卡（model card）伪造。有些项目会提供一个MODEL_CARD.md，里面写着“本模型基于 Opus 4.7 架构微调，参数量 120B，训练数据截止 2025Q1”。但只要你执行ls -la models/，就会发现目录下只有pytorch_model.bin和config.json两个文件，且config.json中的architectures字段是"LlamaForCausalLM"，_name_or_path字段是"meta-llama/Meta-Llama-3-70B"。这说明它根本不是 Anthropic 的 Constitutional AI 架构，而是 Llama 3 的权重。模型卡写的“Opus 4.7”纯属虚构。

我在实测中总结出三条快速核查路径：

1. 响应体校验：用jq '.model'提取所有响应中的 model 字段，批量比对是否统一；
2. 权重文件溯源：检查models/目录是否存在，config.json中的architectures和_name_or_path是否指向 Anthropic 或 OpenAI 官方模型；
3. 模型卡交叉验证：将模型卡中声明的“训练数据截止时间”与 Hugging Face 或 Model Zoo 中同名模型的实际上传时间做比对——如果模型卡写“2025Q1”，但 HF 上最新上传是 2024Q2，那它连数据都没更新，何谈新模型？

这三个动作加起来不超过 90 秒，却能筛掉 70% 的伪项目。记住：模型标识是技术事实的锚点，不是营销文案的装饰词。

3. 维度二：API 协议兼容性 —— 用 OpenAPI Schema 做“协议体检”

光看 model 字段还不够。真正的 Opus 4.7 或 GPT-5，必然带来 API 协议层面的扩展：新的请求参数、新的响应字段、新的错误码、新的流式传输格式。伪项目为了“看起来像”，往往会照搬旧版 OpenAPI Schema，但又不敢完全照抄（怕被说抄袭），于是搞出一堆半吊子兼容。这就给了我们第二个精准打击点：用官方 OpenAPI Schema 做协议级体检。

Anthropic 官方在 2024 年 6 月发布了claude-3-opus-20240229的完整 OpenAPI 3.0 Schema（URL：https://docs.anthropic.com/en/api/openapi.yaml），其中明确定义了该模型支持的所有参数。我们重点看三个关键字段：

• max_tokens：Opus 3 支持最大 4096；
• temperature：范围 0.0–1.0；
• system：支持 system message，类型为 string。

而所谓“Opus 4.7”的宣传材料中，常出现“支持max_tokens: 16384”、“temperature: 2.0”、“system: {role: 'system', content: [...]}（数组格式）”等描述。这些在官方 Schema 中根本不存在。如果你看到一个项目文档里写了这些参数，立刻执行两步验证：

第一步：抓包看真实请求。启动mitmproxy或浏览器开发者工具，捕获前端向后端发送的请求体。你会发现，尽管文档写着max_tokens: 16384，但实际发出的请求里，max_tokens字段压根没传，或者传的是4096。为什么？因为后端根本没实现这个参数解析逻辑，只是前端 JS 画了个饼。

第二步：用 Swagger UI 加载其自述 Schema。大多数伪项目会在/openapi.json或/docs提供自己的 OpenAPI 文档。我们把它下载下来，用在线 Swagger Editor（https://editor.swagger.io）加载，然后手动测试：

1. 在POST /v1/chat/completions的 Try it out 中，填入max_tokens: 16384；
2. 发送请求；
3. 查看返回的 HTTP 状态码和响应体。

实测结果：90% 的项目返回422 Unprocessable Entity，错误信息是"max_tokens must be less than or equal to 4096"。这说明后端校验逻辑还是按 Opus 3 的规则走的，只是文档里写了假参数。

更致命的是响应结构篡改。官方 Opus 3 的响应中，choices[0].message.content是 string 类型。但有个“GPT-5 开源库”（gpt5-local-server）的响应体长这样：

{ "choices": [{ "message": { "content": [ {"type": "text", "text": "你好"}, {"type": "code", "language": "python", "text": "print('hello')"} ] } }] }

这明显是模仿了 OpenAI 的gpt-4-turbo的content数组格式（用于多模态输出），但 OpenAI 官方从未在任何 GPT-5 相关文档中定义过此结构。我反编译了它的响应生成函数（src/core/response_builder.py），发现它硬编码了这段 JSON 结构，不管后端模型实际输出什么，都强行包装成数组。这种“格式先行、内容后补”的做法，暴露了其本质：不是模型能力升级，而是响应体格式的 cosmetic patch。

注意：API 协议兼容性不是“能不能跑通”，而是“协议定义是否与官方一致”。一个项目可以完全不兼容 OpenAI，但它若自称“GPT-5 兼容”，就必须 100% 实现 GPT-5 的 OpenAPI Schema。目前，没有任何一个开源项目做到了这一点，因为 GPT-5 的 Schema 根本不存在——OpenAI 还没发布。

我在排查中发现一个高频误判点：有人把anthropic_version请求头当成模型标识。比如请求头里写了anthropic-version: 2024-08-01，就以为这是“Opus 4.7 的新协议”。错。anthropic-version是 API 网关的版本号，用于控制请求解析逻辑（如是否支持system字段），它与模型版本无关。Opus 3 在2024-08-01版本下依然返回claude-3-opus-20240229。混淆这两者，是伪项目最喜欢利用的认知漏洞。

4. 维度三：响应结构可溯性 —— 从 token 流到 AST 的全链路追踪

前两个维度解决的是“名不副实”的问题，第三个维度则直击核心：它返回的内容，到底是谁生成的？伪项目常用手法是“内容搬运”——前端展示一段精心准备的、看起来很“Opus 4.7 风格”的回答，但背后根本没有调用任何大模型，而是从本地 JSON 文件里读取预设答案。这种做法在 demo 场景下很难被发现，但只要我们开启流式响应（streaming），立刻原形毕露。

真正的 LLM 推理是 token-by-token 生成的，每个 token 的生成都有其计算路径：embedding → attention → FFN → logits → sampling。这个过程会产生可观测的中间态：token 流的时间戳、每个 token 的 logprob、attention map 的热力图（如果开放）。伪项目无法伪造这个物理过程，只能伪造最终结果。

我们以一个“GPT-5 本地推理引擎”（gpt5-offline）为例。它声称“无需联网，100% 本地运行 GPT-5”。我们发起流式请求：

curl -X POST "http://localhost:3000/v1/chat/completions" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-5-offline", "messages": [{"role": "user", "content": "用 Python 写一个快速排序"}], "stream": true }' | jq -r 'select(.choices[].delta.content) | .choices[].delta.content'

正常 LLM 的流式响应应该是：

def quick_sort (arr):

每个 token 间隔几十到几百毫秒，且 token 序列严格遵循语法树（AST）构建顺序：先def，再空格，再函数名，再括号……

但gpt5-offline的响应是：

def quick_sort(arr): if len(arr) <= 1: return arr pivot = arr[len(arr)//2] left = [x for x in arr if x < pivot] middle = [x for x in arr if x == pivot] right = [x for x in arr if x > pivot] return quick_sort(left) + middle + quick_sort(right)

整段代码一次性吐出，无任何分隔符，无 token 间隔，无流式标记（data:）。这说明它根本没走流式生成逻辑，而是把整个字符串当做一个 chunk 返回了。再看它的源码（src/server/stream_handler.py）：

# 伪流式处理：实际是同步读取 def generate_stream(): with open("prompts/sort_code.json", "r") as f: data = json.load(f) yield f"data: {json.dumps({'choices': [{'delta': {'content': data['answer']}}]})}\n\n"

它只是把sort_code.json里的预设答案读出来，包装成 SSE 格式。真正的流式生成需要yield每个 token，并伴随created时间戳和logprobs（如果启用）。这个项目连logprobs参数都不支持，因为它的“生成”根本不需要采样。

更深层的可溯性，在于 AST（抽象语法树）一致性。我写了一个小脚本，对流式返回的每个 token 做实时 AST 解析：

import ast import astor # 用于反编译 AST def validate_ast_stream(token_stream): code_so_far = "" for token in token_stream: code_so_far += token try: tree = ast.parse(code_so_far) # 检查是否形成合法 AST 节点 if isinstance(tree.body[-1], ast.FunctionDef): print(f"[✓] AST formed at token {len(code_so_far)}: {astor.to_source(tree.body[-1]).strip()[:30]}...") except SyntaxError: continue # 未完成语法，继续等待

对真实 Llama 3 模型跑这个脚本，你会看到 AST 节点逐步构建：先有def（Module 节点），再有函数名（FunctionDef），再有参数（arguments），再有 body……这是一个渐进式、符合编译器原理的构建过程。而对gpt5-offline，脚本全程无输出，因为它的“代码”是一次性拼接的字符串，中间态全是语法错误，AST 根本无法构建。

提示：响应结构可溯性，本质是验证“生成过程是否可被观测”。如果一个项目无法提供 token 级别的生成时间戳、logprob、attention 权重（至少是模拟的），那它大概率没有真实的推理过程。真正的开源模型（如 Llama 3、Phi-3）在transformers库中都支持return_dict_in_generate=True和output_scores=True，你可以拿到每个 step 的 logits 和 past_key_values。

我在排查中遇到一个经典案例：某“Opus 4.7 代码解释器”项目，其流式响应中每个 token 都带有一个timestamp字段，看起来很专业。但仔细看时间戳序列：1718923456123,1718923456124,1718923456125……间隔恒为 1ms。真实 GPU 推理的 token 间隔是波动的（受显存带宽、batch size、KV cache 命中率影响），不可能如此精准。这是用time.time_ns()硬编码生成的假时间戳，目的就是制造“真流式”幻觉。

5. 维度四：推理时序真实性 —— 用 GPU 利用率和延迟分布做“心跳监测”

如果说前三个维度是“静态审查”，那么第四个维度就是“动态心电图”。真正的 LLM 推理，其硬件资源消耗模式具有鲜明的生理特征：GPU 显存占用呈阶梯式上升（加载权重 → KV cache 扩展 → 输出缓存），GPU 利用率呈脉冲式波动（attention 计算高峰 → FFN 计算高峰 → I/O 等待），端到端延迟服从特定的概率分布（非正态，有长尾）。伪项目无法模拟这种硬件级生理信号，它们的“心跳”是平滑、稳定、反物理的。

我们用nvidia-smi dmon -s uvm实时监控一个“GPT-5 本地服务”的 GPU 使用情况。真实 Llama 3-70B 在生成 1000 token 时，GPU 利用率曲线是这样的：

Time(s) Util(%) 0 0 # 初始化 1 85 # 权重加载 & 第一个 token 2 42 # I/O 等待 & KV cache 扩展 3 91 # attention 计算高峰 4 38 # FFN 计算 & memory copy ...

利用率在 30%–95% 之间剧烈跳变，且每次跳变都对应一个 token 的生成周期。而gpt5-offline的曲线是：

Time(s) Util(%) 0 0 1 0 2 0 3 0 4 0 ... 0

全程 GPU 利用率为 0。因为它根本没调用 CUDA，所有“推理”都在 CPU 上用json.load()完成。这已经不是“慢”，而是“没发生”。

更精细的监测，是看延迟分布。我们用wrk对同一服务压测 1000 次，统计 P50/P90/P99 延迟：

真实模型的长尾延迟（P99-P50）高达 4400ms，这是 KV cache 未命中、显存带宽瓶颈、PCIe 传输抖动造成的。而伪项目的长尾只有 7ms，说明它完全是内存操作，没有硬件瓶颈。这个差距，就像听一个人说话的呼吸声——真人在思考时会有停顿、气息变化、语速波动；而录音机播放则是绝对匀速。

我还开发了一个轻量级“心跳监测”脚本（gpu_heartbeat.py），它不依赖nvidia-smi，而是直接读取/proc/driver/nvidia/gpus/0000:01:00.0/information和/sys/class/drm/card0/device/gpu_busy_percent（Linux），每 100ms 采样一次，生成一个 10 秒的 utilization time series。然后用 FFT（快速傅里叶变换）分析其频谱特征：

• 真实 LLM 推理：频谱在 1–5Hz 区间有显著能量峰（对应 token 生成节奏）；
• 伪项目：频谱能量集中在 0Hz（直流分量），无周期性波动。

这个方法甚至能在模型刚启动、还没收到请求时就预警：如果 GPU 忙碌度频谱是平的，那它大概率是个“纸老虎”。

注意：有些项目会用torch.cuda.memory_allocated()做障眼法，在启动时假装加载了权重。但memory_allocated()只是分配了显存地址，没触发实际的数据拷贝（cudaMemcpy）。真正的权重加载，会伴随nvidia-smi中FB Memory Usage的突增和Util%的尖峰。只看memory_allocated()是无效的。

我在实测中发现一个反直觉现象：某些“伪 Opus”项目为了显得更“真”，会故意在响应里加入随机延迟（time.sleep(random.uniform(0.1, 0.5))）。但这反而暴露了问题——真实 GPU 推理的延迟是硬件决定的，不是软件 sleep 控制的。而且，sleep 的延迟是均匀分布，而真实延迟是偏态分布（有长尾）。用 Kolmogorov-Smirnov 检验（KS-test）就能轻松区分。

6. 维度五：token 分布合理性 —— 用困惑度（Perplexity）和熵值做“语言指纹”

前四个维度解决的是“有没有真推理”，第五个维度则深入到“推理质量是否可信”。即使一个项目真的调用了某个开源模型，它也可能通过 prompt engineering、post-processing、甚至人工润色，让输出看起来“像 Opus 4.7”。这时，我们需要一个客观的、可量化的语言学指标：困惑度（Perplexity）和 token 熵值（Token Entropy）。它们构成了模型输出的“语言指纹”，无法被简单话术伪造。

困惑度衡量的是模型对一段文本的预测难度。公式为：
$$ PP(W) = \exp\left(-\frac{1}{N} \sum_{i=1}^{N} \log P(w_i | w_{<i})\right) $$
其中 $P(w_i | w_{<i})$ 是模型预测第 $i$ 个 token 的概率。真实 LLM 的困惑度在不同领域有稳定区间：代码生成通常在 15–25，数学推理在 10–18，创意写作在 20–30。如果一个“GPT-5”项目对同一段 Python 代码的困惑度是 5.2，那它要么是过拟合的玩具模型，要么是人工写的答案（因为人工答案没有概率分布，困惑度计算会崩）。

我们用 Hugging Face 的evaluate库实测：

from evaluate import load import torch from transformers import AutoModelForCausalLM, AutoTokenizer perplexity = load("perplexity", module_type="metric") model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B") tokenizer = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3-8B") # 测试文本：一段标准快速排序实现 test_text = "def quick_sort(arr):\n if len(arr) <= 1:\n return arr\n pivot = arr[len(arr)//2]\n left = [x for x in arr if x < pivot]\n middle = [x for x in arr if x == pivot]\n right = [x for x in arr if x > pivot]\n return quick_sort(left) + middle + quick_sort(right)" results = perplexity.compute( model_id="meta-llama/Meta-Llama-3-8B", add_start_token=False, predictions=[test_text] ) print(f"Llama 3-8B Perplexity: {results['mean_perplexity']:.2f}") # 输出：18.42

现在，我们对同一个test_text，测试那个“GPT-5 本地服务”的输出。我们让它生成 10 次，取平均困惑度：

# 用 curl 循环 10 次，保存每次输出到 files/output_*.txt for i in $(seq 1 10); do curl -s "http://localhost:3000/v1/chat/completions" \ -H "Content-Type: application/json" \ -d '{"model":"gpt-5-offline","messages":[{"role":"user","content":"用 Python 写一个快速排序"}]}' \ | jq -r '.choices[0].message.content' > "files/output_$i.txt" done

然后计算这 10 个文件的平均困惑度。实测结果：2.87。这低得离谱。为什么？因为它的输出是固定字符串，没有概率分布。当我们用transformers的model.generate()计算困惑度时，它会尝试对每个 token 计算log P(w_i)，但对于一个确定性字符串，模型会给出极高的置信度（log P ≈ 0），导致指数项趋近于 1，困惑度爆低。

另一个指标是 token 熵值。真实 LLM 在生成时，每个 token 的预测概率分布是有熵的（不确定性）。我们提取生成过程中的scores（logits），计算 softmax 后的熵：

def calculate_token_entropy(logits): probs = torch.nn.functional.softmax(logits, dim=-1) entropy = -torch.sum(probs * torch.log(probs + 1e-12), dim=-1) return entropy.mean().item() # 在 model.generate() 中启用 output_scores=True outputs = model.generate( input_ids=input_ids, max_new_tokens=100, output_scores=True, return_dict_in_generate=True ) entropies = [calculate_token_entropy(score) for score in outputs.scores] print(f"Mean token entropy: {np.mean(entropies):.3f}") # Llama 3-8B: ~4.2

真实模型的平均 token 熵在 3.5–4.5 之间（单位：nat）。而gpt5-offline的熵值是0.001，因为它的“生成”没有 logits，没有概率分布，熵为零。

提示：token 分布合理性，是唯一能穿透 prompt engineering 和 post-processing 的维度。无论你用多精妙的 system prompt，真实模型的困惑度和熵值都会落在其架构决定的合理区间内。伪项目要么太低（确定性输出），要么太高（胡言乱语），绝不会“恰到好处”。

我在排查中发现一个高级伪装：某“Opus 4.7”项目在响应中嵌入了logprobs字段，看起来很专业。但它的logprobs是用random.uniform(-10, -1)硬编码生成的，不是从模型 logits 计算来的。我写了一个小脚本，对logprobs做 Kolmogorov-Smirnov 检验，对比它与真实 Llama 3 的logprobs分布，p-value < 0.001，拒绝原假设——分布完全不同。

7. 维度六：依赖图谱透明性 —— 从 requirements.txt 到 Dockerfile 的供应链审计

最后一个维度，也是最容易被忽视的维度：整个技术栈的依赖图谱是否透明、可追溯、无黑盒？真正的开源项目，其技术实现必须像洋葱一样层层可剥。从最外层的Dockerfile，到中间的requirements.txt，再到最内层的模型权重文件哈希值，每一层都应公开、可验证、无隐藏依赖。伪项目往往在这里埋下最深的雷：用私有 pip 源、未公开的 binary blob、或混淆的 shell 脚本，切断可追溯链。

我们以一个“Claude Opus 4.7 企业版”项目（opus-enterprise）为例。它的Dockerfile看起来很规范：

FROM python:3.11-slim COPY requirements.txt . RUN pip install -r requirements.txt COPY . /app CMD ["uvicorn", "main:app"]

但requirements.txt里有一行：

opus-engine @ https://private-repo.example.com/opus-engine-4.7.0-py3-none-any.whl#sha256=abc123...

这个private-repo.example.com是个不存在的域名，opus-engine-4.7.0-py3-none-any.whl是个未公开的 wheel 包。这意味着，整个项目的核心“Opus 引擎”是一个黑盒 binary，你无法审计其源码，无法确认它是否真的调用了 Anthropic API，还是只是个 HTTP 代理，甚至是个 mock server。

真正的开源精神，是“可审计即安全”。我们要求：

• 所有依赖必须来自 PyPI、conda-forge、Hugging Face Hub 等公共源；
• 如果必须用私有包，必须在仓库中提供其完整源码，并附上构建脚本；
• 模型权重文件必须提供 SHA256 哈希值，并与 Hugging Face 或官方 Model Zoo 中的哈希值一致。

我开发了一个自动化审计脚本audit_deps.py，它会：

1. 解析requirements.txt，对每个包执行pip show <pkg>，检查Location是否在/usr/local/lib/python3.11/site-packages/（即系统安装）；
2. 对 wheel 包，用wheel unpack解包，检查setup.py和核心模块源码；
3. 对Dockerfile，递归解析FROM基础镜像，检查其是否来自docker.io/library/python等官方源；
4. 对models/目录，计算每个文件的sha256sum，并与 HF 上同名模型的README.md中声明的哈希值比对。

对opus-enterprise运行此脚本，结果如下：

[ERROR] Dependency 'opus-engine' is from private source: https://private-repo.example.com/ [ERROR] Wheel 'opus-engine-4.7.0-py3-none-any.whl' has no public source code [ERROR] Model file 'models/pytorch_model.bin' SHA256 mismatch: expected 'def456...', got 'abc123...' [WARN] Docker base image 'python:3.11-slim' is official, but version '3.11' is EOL in 2027-10

三个 ERROR，直接判定为不可信项目。

更隐蔽的黑盒，是entrypoint.sh里的混淆脚本。有些项目在Dockerfile里写：

COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"]

而entrypoint.sh是一个 base64 编码的字符串，解码后是：

#!/bin/bash # 这是一个真实的混淆案例 eval "$(echo 'ZWNobyAiTWFraW5nIGEgY29ubmVjdGlvbiIgPiAvZGV2L251bGwKcHl0aG9uIG1haW4ucHk=' | base64 -d)" exec "$@"

它只是打印一行日志，然后执行python main.py。但你无法知道main.py里是否藏有连接私有 API 的密钥。真正的透明，是entrypoint.sh必须是明文、可读、无加密。

注意：依赖图谱透明性，不是“有没有开源”，而是“开源的深度”。一个项目可以开源前端代码，但把核心推理引擎做成闭源 binary，这叫“开源皮，闭源骨”。我们必须穿透到最底层的二进制依赖，才能确认它是否真的“全开源”。

我在实测中总结出供应链审计的黄金三原则：

1. 可重现性（Reproducibility）：任何人用相同的Dockerfile和requirements.txt，必须能构建出