夜雨聆风
前两天，开发者 Jun Song 在 X 上转发一组社区测试结果：DeepSeek V4 Pro 0813 搭载开源插件 J-Space Cognition Suite V3.6 后，在多项关键基准测试中全面超越 Fable 5，速度和 Token 效率也能提高两倍以上。
帖子迅速走红，浏览量超过 25 万。
没想到今天就彻底翻车：社区复测的结果完全相反，非但没提高成绩，还花了更多 token。
面对网友质疑，作者不仅没有公开完整的评测记录或者运行日志，还被曝删除质疑 issue。
根据J-Space Cognition Suite V3.6的项目介绍，这是一套模型无关的推理时控制方案。它不修改模型权重，也不要求微调，而是以 Skill 的形式加入 Agent 运行环境。
《DeepSeek V4 × J-Space 能力释放报告》：https://github.com/Tiger3807861189/DeepSeek-V4-J-Space-Capability-Realization-Report
它通过工作空间加载、选择性路由、功能性第一人称、稠密轨、持久账本、checkpoint、经验验证和恢复闭环，减少模型从“具备能力”到“稳定完成任务”之间的损失。
其核心目标不是“把弱模型变强”，而是帮助强模型更可靠地调用、维持、协调和验证自身已有能力。
简单来说，J-Space 希望阻止模型在工作过程中忘记自己到底在做什么。
issues #6 中有开发者反馈，在 DSH Minimal + J-Space Skill 条件下，无法复现报告中的 Terminal Bench 2.1 高分。
随后更多的社区复现发现：分数根本拉不起来。
最早的负面结果来自来自 J-Space 仓库的 Issue #10，随后的实锤的结果 Issue #26 也出现了。
Issue #10：开发者用 V4 Flash 进行了两轮 A/B 测试，结果发现 J-Space 组却消耗了更多资源。 Issue #26：开发者使用 8 张 NVIDIA H20 部署 V4 Flash，并通过 DeepSeek Harness Standard 模式加载 J-Space，结果发现测试成绩77.5% VS 报告成绩87.1%，质疑项目数据的真实性。
更加糟糕的是开发者在 Issue #23 中称，自己此前发布的质疑 Issue 遭到作者删除。
Issue #28 的开发者对这个插件的命名本身也提出了很强的质疑，要求仓库作者明确区分“受到 J-space 的启发”和“这就是 J-space”。
J-Space 恰好踩中了 V4 Pro 最受关注的问题：对外部运行环境过于敏感。
今天，仓库作者修改了报告README.md的引言部分，删掉了J-Space是一个插件，已通过 benchmark 验证了它对于Deepseek 的提升巨大，flash基本持平GLM5.3，pro超越Fable 5。
加上了一些免责信息：本页记录外部项目已经公开的工程观察、J-Space 使用的操作性术语、项目级 Benchmark 分数及其适用边界。它不是研究论文，非学术性质，不提供模型内部机制证明、形式化判定方法、消融设计或因果贡献分解。