# DS4F vs Grok 4.5：本地禁联网对比

gistfile1.md

DS4F vs Grok 4.5：本地禁联网对比

两者均使用：

• Pi 0.83.0、thinking=high
• 同一 serde_json #979 代码与任务
• 无效率优化提示
• 工具禁止联网、宿主源码隔离
• 回归测试及完整测试独立验证

指标	DS4F	Grok 4.5	Grok 相对 DS4F
执行时间	174.3s	224.3s	慢 28.6%
Assistant 轮次	21	33	多 57.1%
工具轮次	20	32	多 60.0%
实际工具调用	28	58	多 107.1%
首次源码编辑	第18轮	第19轮	基本相同
首次编辑前工具轮次	17	18	基本相同
源码编辑次数	1	3	多 2 次
Cargo 测试调用	2	9	多 7 次
输入 token	54,225	48,966	少 9.7%
输出 token	11,396	10,354	少 9.1%
reasoning token	8,739	4,994	少 42.9%
标准 PR #1324 补丁	否	否	持平
回归及完整测试	PASS	PASS	持平

关键差异

两者在首次编辑前的表现几乎相同：

• DS4F：第18轮编辑；
• Grok：第19轮编辑。

主要差异发生在首次编辑以后：

• DS4F 一次编辑成功，随后运行两次测试并结束；
• Grok 首版之后继续诊断、修改和验证，共编辑三次、调用九次 Cargo 测试，额外消耗约14个工具轮次。

所以这次并不是 DS4F 探索更少，而是：

DS4F 首次补丁更稳定；Grok 在补丁后的返工和验证明显更多。

需要注意：DS4F 是五组并发运行中的一组，Grok 是单独运行；并发资源竞争理论上对 DS4F 更不利，但它仍快约50秒。不过两者都只有一次样本，不能据此断言模型的稳定排名。

原始产物

• DS4F：/tmp/pi-ds4-prompt-ab/artifacts/generic-round1-clean-A/
• Grok 4.5：/tmp/pi-ds4-prompt-ab/artifacts/grok-cli-no-network/

补充：两者的修复是否合格

“标准 PR #1324 补丁：否”只表示实现没有与上游补丁完全一致，不能直接等同于修复不合格。

判断	DS4F	Grok 4.5
非字符串键被拒绝	是	是
错误包含 key must be a string	是	是
正常字符串键可用	是	是
回归测试通过	是	是
完整测试通过	是	是
与上游补丁完全一致	否	否
EOF 行为与上游一致	是	否

补充差分验证发现：

• DS4F 对输入 { 返回 EOF while parsing an object，与上游 PR #1324 一致。
• Grok 返回 EOF while parsing a value，与上游不同。
• 两者对空对象、非字符串键和正常字符串键的已验证行为均正确。

因此更准确的结论是：

• DS4F：合格的替代实现，在已验证行为上与上游一致。
• Grok：核心 bug 已修复，官方回归测试和完整测试均通过；但没有完全达到上游行为等价，EOF 错误语义存在一处差异。
• “非标准补丁”本身不能作为不合格的判据。

进一步代码质量评估：上游语义差分（修正）

按最终代码而非执行速度评价：

• DS4F：7.5/10
• Grok 4.5：6.5/10
• 上游 PR #1324：明显优于两者

两者都修复了核心 bug，但都没有完整复用 serde_json 已有的 MapKey 语义。DS4F 更接近上游；Grok 还多一个 EOF 错误语义差异。

验证结果

项目	DS4F	Grok 4.5
cargo fmt --check	PASS	PASS
默认完整测试	PASS	PASS
cargo test --all-features	PASS	PASS
拒绝 {[true]: null}	正确	正确
错误为 key must be a string	正确	正确
正常字符串键	正确	正确
空对象错误	与上游一致	与上游一致
EOF 错误	与上游一致	与上游不同
使用已有 MapKey	否	否
自定义数字/布尔 key seed	与上游不同	与上游不同

两者共同遗漏的 MapKey 语义

上游实现不仅检查下一个字符是不是 "，还会：

1. 预检查 JSON key 必须以字符串开始；
2. 使用 MapKey 反序列化 key；
3. 使用 fix_position 补齐错误位置。

这使合法 JSON 字符串键能够按照 Serde map-key 规则转换成其他 Rust 类型。补充差分测试如下：

输入与 seed	上游 PR	DS4F	Grok 4.5
{"x":null} → String	Ok("x")	Ok("x")	Ok("x")
{"123":null} → u64	Ok(123)	invalid type	invalid type
{"-7":null} → i64	Ok(-7)	invalid type	invalid type
{"true":null} → bool	Ok(true)	invalid type	invalid type
{"[true]":null} → Vec<bool>	拒绝	拒绝	拒绝

普通派生 enum 通常使用字符串 variant，因此该差异不会影响常见路径；但 EnumAccess::variant_seed 是泛型 API，上游实现对自定义 seed 的兼容性更完整。

DS4F 代码质量

优点：

• 核心安全条件正确，非字符串 key 无法进入 seed；
• }、非法 key 和 EOF 分支处理明确；
• EOF 使用 EofWhileParsingObject，与上游一致；
• 改动小，无无关文件，一次编辑通过测试。

不足：

• 未复用 MapKey，遗漏泛型 key seed 行为；
• 正常路径整体嵌套在 Some(b'"') 分支中，happy path 比上游更深；
• 属于有效的局部修复，但不是 serde_json 对象 key 语义的完整实现。

Grok 代码质量

优点：

• 使用 early return，正常路径保持平直；
• 注释清楚说明为什么必须先检查字符串起始符；
• 核心 bug 得到修复。

不足：

• 同样未使用 MapKey，存在相同的泛型 seed 兼容性缺口；
• EOF 返回 EofWhileParsingValue，而上游和 DS4F 返回 EofWhileParsingObject；
• 注释提到 MapAccess 语义，却没有复用对应的 MapKey 机制；
• 三次编辑、九次 Cargo 测试才稳定下来。

修正后的合格性判断

标准	DS4F	Grok 4.5
当前 benchmark/回归测试	合格	合格
核心 bug 是否修好	是	是
与上游完整行为等价	否	否
两者谁更接近上游	DS4F	次之

因此需要修正前一节“DS4F 在已验证行为上与上游一致”的表述：扩展到自定义 key seed 后，DS4F 也不是完整的上游等价实现，只是比 Grok 更接近。