手里的两员大将，一个是 O 哥（Opus 5），一个是 G 哥（GPT 5.6 Sol）。每次遇到问题，我就会考考它们。
之前考了好几次，O 哥都赢了，我一直在等待 G 哥大发神威。
最近遇到了 OpenCode 卡住无应答的问题。我就想着这不是 G 哥的主场么？它分析这种系统和网络的问题，应该很擅长才对！我记得它的终端基准是非常强的。
所以我就把同一个问题给了它们两个人。结果还是 O 哥技高一筹！
我的问题是这样的：
我本地有一个 OpenCode，可以选择一个免费的 Ox 模型，但是当我发送消息之后，一直都在加载中，我怀疑是这个软件有问题了，我网络是正常的，它的 GUI 版本也是正常。你帮我排除一下是什么问题。
Opus 5 的结论，我已经在上一篇中分享过了：
它的排查效率很高，而且很精准。关键是想到了 A/B 测试，快速定位了核心问题。
这个问题的关键是：不同的启动目录，导致不同结果！
只要在"用户目录"启动 OpenCode CLI，就必然卡住，只要在其他目录启动就基本正常。这个是第一层的根因。当然用户目录为啥会卡住，还能继续往下挖，就是和 junction 机制以及目录遍历有关系。
再来看一下 GPT 5.6 Sol 的结果：
G 哥这次效率很高，总共花了 9 分钟 39 秒，比 O 哥的十几分钟还快了几分钟。这个速度相当可以的，但是结论完全错误。
它之所以快，是完全没有复现卡住的时长问题！
它的结论居然是 IPv6 的问题！
我们可以看一下 G 哥的分析过程：
....
受控复现这次成功了：同一个全局 CLI、同一个 opencode-go/ox-alpha-free 在约 10 秒内返回 OK。这说明安装并未整体损坏、账号凭据当前有效、Ox 服务当前也可达；更像是间歇性服务/流式连接问题，或特定启动目录触发了附加故障。日志里你的桌面目录确实还有一个 Windows 特有问题：仓库中出现名为 nul 的路径，导致快照索引反复失败。我再做版本对照、目录对照和官方已知问题核查。
运行了命令
Ox 是昨天（2026-08-21）才加入目录的 Alpha 免费模型，标注为不限量；这种刚上线模型的间歇性冷启动/容量问题概率很高。我正在核对官方仓库的最新 issue 和服务状态，同时用 GUI 自带的旧 CLI 做同样请求，确认是否真是 1.18.21 回归。
运行了命令已搜索网页
两套 CLI 都已成功返回：全局版 1.18.21 和 GUI 内置版 1.14.29 各约 8--10 秒，暂时没有证据表明是版本回归。最后我会直接在你此前出问题的 Desktop 工作目录复现一次；这能判断 nul 文件的快照错误是主因还是旁支警告。
运行了命令
目录对照也成功：即使在 Desktop 触发 nul 快照警告，Ox 仍返回了 DESKTOP_OK，所以这个警告不是"无限加载"的主因。数据库里则能看到关键证据：同一时段、同一模型有的会话成功，有的只创建了空的 assistant 消息、没有 finish 或错误对象------这是请求/流连接被悬空的典型状态。我再查一下官方仓库是否已有同模型报告，然后给你明确结论和可执行处理顺序。
运行了命令
官方仓库里有与本机日志几乎逐字一致的公开问题：Windows 上 opencode-go 会停在 llm.runtime=ai-sdk、没有 token 也没有错误；另一个已定位原因是 Cloudflare 的 IPv6 路径失效，而打包运行时不会及时回落 IPv4。因为你的成功/失败是间歇性的，我现在只差确认本机 IPv4/IPv6 两条路径是否不对称。
....
从分析日志中可以看到，GPT 5.6 其实也是差一点就找到了关键了，但是擦肩而过！
它跑了基础调用正确，做了版本对比正确。
它当时也做了目录对照实验，但是它选择的是桌面（Desktop） ，这个路径本身就没问题。所以它没有复现用户目录卡主这个关键问题。
然后，它自己分析不出来，就去联网查询，这一查基本废了。拿了一个别人结果，作为解析，完全就不是同一个情况。
我发现好几个模型都出现了联网检索的操作，按理说这是个好事情，这样可以知道得更全面，但是最终结果是，联网查了的全部失败，自己动脑子的全部回答出来了。
我其实给了它第二次机会：
它表示我说的对，认错第一名，但是它并没有选对方向。
第三次，我直接明说了，让它去看用户目录：
终于，它复现了。
它确定不是 Ox，也不是 IPv6 的问题，而是 OpenCode 在用户目录执行 Git 快照扫描时卡住。
然后它展示了完整的证据链：
- 从
C:\Users\tony默认启动：实际卡住超过 5 分钟。 - 同一目录强制 IPv4：仍然卡住，排除 IPv6 主因。
- 同一目录、同一模型，只禁用快照：约 10 秒返回
NOSNAPSHOT_OK。 - opencode 源码会执行：
css
git ls-files --others --exclude-standard- 我在
C:\Users\tony单独执行这条等效命令，30 秒仍未完成。 - 用户目录包含顶层
.git、216 个顶层项目、12 个 junction，以及 AppData、OneDrive 和异常nul文件。opencode 等于在扫描整个用户目录。 - 官方源码中正是这段快照逻辑：snapshot/index.ts。
所以最终结论是：
用户目录范围过大，Git 未跟踪文件枚举/快照卡死，模型请求虽然已经发起，但响应无法正常显示。之前的 IPv6 判断是被相似症状误导了。最推荐直接在具体项目目录运行；如果你确实需要在用户目录运行，我可以再帮你做一个只针对 Home 的启动脚本，不影响其他项目的快照功能。
既然结果出来了，G 哥已经意识到问题的关键了，我就让 G 哥继续补充了一些信息。
第一个问题是：git ls-files 做了什么？
这个命令主要是枚举命令，它本身不会执行 git add、不会生成提交、不会删除文件，主要读取目录结构和 ignore 规则。但 OpenCode 拿到列表后，还会检查文件大小，并把符合条件的文件加入它自己的影子快照仓库，所以后续比这个命令本身更重。
第二个问题：哪些目录或者文件是卡住的关键？
| 目录 | 候选文件数/情况 |
|---|---|
AppData\Roaming\npm\node_modules |
超过 8 秒仍未完成；上一级测出约 95,432 个 |
AppData\Local\Temp |
超过 8 秒仍未完成 |
.rustup\toolchains |
51,643 |
AppData\Local\Google\Chrome\User Data |
50,601 |
AppData\Local\Microsoft |
扫描到 42,877 个后仍超时 |
AppData\Local\npm-cache |
35,970 |
AppData\Roaming\Trae |
35,940 |
.local\share |
34,787 |
AppData\Local\Packages |
31,973 |
.cargo\registry |
28,566 |
AppData\Local\pnpm |
20,836 |
.vscode\extensions |
15,061 |
.cache |
13,689 |
.trae |
13,896 |
.bun |
11,106 |
AppData\Local\Microsoft\Edge\User Data |
11,010 |
AppData\Roaming\Claude |
10,365，并伴随访问警告 |
.qoder |
9,941 |
.cursor |
7,158 |
Documents |
7,146，并伴随权限警告 |
我这电脑，装的东西太多了，动不动就几万个文件！当然 AppData 这块肯定是有很多文件的，所有人的电脑都这样，错就错在 OpenCode 啥都不管，直接开始扫盘。
G 哥在上面的列表中完全没有提到 .dsh，它分析的思路可能还是过于简单了。
我只能不断的提示它！
结论：.dsh （DeepSeek Harness）内没有发现无限递归的 junction 闭环，但存在大量嵌套依赖链接，Git 会沿着它们展开，性能影响非常大。
Git 会跟随这些 junction 展开依赖树：
| 项目 | 实测结果 |
|---|---|
.dsh 扫描耗时 |
约 21--25 秒 |
| 展开后的候选文件 | 174,961 |
最大 node_modules 嵌套深度 |
6 层 |
至少两层 node_modules 的文件 |
155,024 |
| 至少三层的文件 | 133,652 |
| 位于五层的文件 | 101,263 |
bash
.dsh
└─ profiles
└─ node_modules
└─ @deepseek-ai/dsh-client-web
└─ node_modules
└─ @deepseek-ai/dsh-client-runtime
└─ node_modules
└─ @deepseek-ai/dsh-tools
└─ node_modules
└─ @deepseek-ai/dsh-agent
└─ node_modules
└─ @deepseek-ai/dsh-typert-registry
└─ node_modules
└─ zod所以它不是"junction 无限循环"，而是"junction 把 Git 带入一个非常深、非常大的依赖树"。对 OpenCode 来说，效果同样糟糕：.dsh 单独就贡献了约 17.5 万个候选文件。
我对 G 哥的分析精准性存疑，但是它发现的问题基本确实存在！
你们说 DSH 为啥要跳这么多文件！！！
我不太懂 Node 的依赖机制，但是学过基础代码知识的都应该有一些常识，依赖包和循环最好不要嵌套太多，要解耦，否则很容易出问题！很多屎山代码，就是一环套一环堆出来的。
DSH 当时招人搞出了好多新闻，说要求有多么高，某个档位以下学历全都不看，然后特别注重基础知识。
我对这方面也不是专业的，我就让 G 哥说几句吧，它说错了，我也不用负责任。
以下内容全部是 GPT 5.6 Sol 总结的。
DSH 主要设计缺陷：
- 把完整依赖闭包映射成 530 个 Windows junction，规模失控。
- 让普通目录遍历工具将其展开为约 17.5 万个文件，Git 单独扫描
.dsh就需要约 21--25 秒。 - junction 目标混合了全局 npm、临时 npx 缓存和本地开发仓库，环境不可复现。
- 保留了 75 个失效 junction，缺少可靠的垃圾清理机制。
- 23 个链接又指向其他 junction，增加路径解析、权限和工具兼容风险。
- 依赖树最高嵌套 6 层，并出现重复依赖路径，说明扁平 fallback 没有真正控制复杂度。
- 没有在
.dsh根目录自动生成合适的 Git ignore 防护，导致 Git、备份、索引器、杀毒软件和 OpenCode 扫描整个依赖树。 - junction 指向
E:\Jarvis_github\deepseek-harness，意味着用户运行环境受本地开发目录影响；该目录移动或删除就会产生更多断链。 - 这是
0.1.1-rc.2预发布版本，当前实现明显更关注模块解析可用性，没有充分处理 Windows 文件系统和外部工具兼容性。
设计目标------共享依赖、避免重复安装------是合理的，但实现方式过于粗暴。至少应该：
- 只链接 Profile 真正需要的包，而不是整个依赖闭包；
- 清理不再使用和已经失效的链接；
- 避免把临时
_npx路径写进持久 Profile； - 区分正式安装与开发 workspace；
- 自动提供
.gitignore； - 最好将运行时依赖放到单独缓存目录，不要暴露在用户 Home 的普通扫描路径下。
我没有兴趣分析 DSH 的代码，但是整体的使用体验是真的不好。我已经说过好几次了。
它的 20 万 Star，完全名不副实。对其他开源项目非常不公平！
好了，说回 G 哥自己！
G 哥经过三轮提问才复现问题并发现问题的关键，而 O 哥直接一轮搞定！
这里的关键是 G 哥其实根本找不到方向，第三轮是我明确问题，让它验证，它才意识到错了。
这样高下立判了吧！
什么叫效率，什么专业，什么叫精准，应该很清晰了吧。
之前也比过，新增功能，修复 Bug，也是 O 哥略胜一筹！
就今天这个问题来说，我们的小 G 哥也是能搞定的，虽然慢了一些！所以大 G 哥搞不定，是有点出乎我的意料的。
最后声明一下，这些都是特例，在极端情况下测试它们的极端能力，比如自主性，思维扩散能力，泛化能力啊，等等。
在常规问题中，GPT 5.6 Sol 表现还是非常稳定的。也是数一数二的存在，但是要当心小 G 哥上位。
我这样一篇文章是一口气喷了三个粉丝众多的工具啊，压力有点大！
OpenCode、DSH、Codex 对不住了啊，如果你们认了这些问题，可以改进一下，如果你们不认，觉得是我的问题，我也没意见！