Codex 读到的是模型文件还是 LFS 指针：大文件工作区自查

让 Codex 阅读模型或数据文件前，应先确认工作区里的内容是实际字节还是 Git LFS 指针。LFS 把小型文本指针放进 Git，把大内容单独存储；工具读到几行指针，不能据此分析权重或数据内容。本文只检查输入是否就绪，不解释模型权重结构，也不重复大文件推送教程。

指针长什么样

以下是格式演示，摘要和尺寸均为合成值，不对应真实对象：

version https://git-lfs.github.com/spec/v1
oid sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
size 1048576

指针中的 size 描述目标对象长度，不是当前这份小文本自身长度。文件后缀即使是 .bin 或 .safetensors，也不能保证实际内容已经拉取。相反，文件体积很大也不能单独证明它正确，仍要核对摘要、应用能否读取以及是否确实属于预期版本。

拉取前后做同一张记录表

先确认当前仓库与工作树位置，检查 .gitattributes 对目标路径的属性，并查看 LFS 管理清单。对大文件只读前少量字节或用专门工具检查，避免把整个文件打印进终端或模型上下文。

git check-attr filter -- models/demo.bin
git lfs ls-files
git lfs status

如果本机没有 LFS 命令，记录“未安装”并按项目安装要求处理，不把命令不存在当成仓库文件损坏。对受限环境，还要确认对象服务器访问权限和磁盘预算；凭据不写进问题报告。

阶段	实际路径	磁盘字节数	首部是否像指针	SHA-256	能否由应用打开
拉取前	models/demo.bin	待填	待填	待填	未验证
拉取后	同一路径	待填	待填	待填	待验证

拉取操作使用仓库文档认可的命令，例如在确认远端与路径后执行针对该对象的 LFS 拉取。拉取可能访问网络并下载大对象；先列清目标，不盲目下载整个历史。若过程中报错，保存错误原文与对象标识，不把失败后仍在磁盘上的指针当成成功产物。

摘要核验比“看起来大了”更可靠

可以用 PowerShell 的 Get-FileHash -Algorithm SHA256 计算目标文件摘要，用文件属性取实际长度。将结果与指针的 oid、size 对照。为了记录拉取前指针，可先复制那份小文本到单独的证据目录，别覆盖目标文件来回试。真实对象摘要匹配后，再用项目自己的读取器做最小加载检查。

如果对象足够大，完整摘要计算也会花时间，但它读取本地字节，不等于把内容发送给模型。日志只需保存摘要和长度。数据若涉及访问许可，验证对象正确并不自动赋予向外部服务上传的权限。

给 Codex 的输入应是明确任务材料

确认就绪后告诉工具目标路径、文件类型、允许使用的检查程序和期望摘要，不要求它把二进制全文读入对话。若实际文件尚未取得，让工具仅检查指针与环境，不得根据指针虚构模型架构、张量数量或运行结果。任务报告把“对象已核验”和“模型已实测”分开写，前者不能推导后者。

常见问题

克隆成功是否等于所有 LFS 对象到齐？ 不一定，下载策略、权限与网络都可能影响工作区内容。

看到指针就该删除文件重来吗？ 不需要先删，保留证据并按 LFS 流程确认对象获取情况。

摘要相同能证明模型好用吗？ 只能支持字节一致，功能与质量仍需单独测试。

继续处理相关问题

相关入口：Codex 会话管理。

官方依据与核对日期

核对日：2026-10-23。Git LFS 指针规范：指针记录 version、oid 与目标对象 size；Git LFS 官方说明：Git 内保存指针，大文件内容由单独存储管理。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。