狠狠夸Grok build

背景

当前 AI 编码助手市场竞争激烈，各大模型厂商纷纷推出专属的 coding plan 和 CLI 工具。用户在实际使用中面临模型选择、成本控制、意图理解、中文表达等多重挑战。Claude Code 曾因其强大的 harness 能力被广泛采用，但近期被发现安插后门，导致用户对其本地运行产生安全顾虑。与此同时，GLM、GPT 等模型在中文场景下的表现各有短板，而讯飞等国内厂商的 coding plan 又存在高 busy 率、抢不到资源等问题。在此背景下，用户开始探索新的替代方案，Grok Build 这一产品进入了视野。

核心内容

原文作者分享了自己在 AI coding 工作流中的模型切换经历与最终对 Grok Build 的使用心得。

• 此前工作流：作者主要使用 Claude Code，以 Opus 模型作为主控（后来尝试 Fable 但没有明显提升），将一些重复性、审查类的“笨活”通过 Codex Exec 交接给 GPT 去执行。
• 遭遇问题：Claude Code 被爆出安插后门后，作者很久不敢再在本地使用它。尝试使用 Codex CLI，但感觉 harness 工具链不够完善，需要高超技巧才能调教好；加之 GPT 模型在理解意图和中文表达上仍有差距，因此需要搭配其他模型。
• 尝试其他模型：将 Opus 换成了 GLM，但使用 opencode go 的 200k 上下文时体验不理想，且需要频繁换账号。各大厂商的 coding plan 要么抢不到，要么无法使用（例如讯飞的 busy 率达到了 90%）。
• 发现 Grok Build：作者今天在 Grok Build 中试用 Grok 4.5 模型，感觉非常惊艳。Grok 4.5 运行速度快，表达能力好，产品设计用心。当作者询问如何从 Claude 迁移 harness 时，Grok Build 回复说默认已经兼容 Claude 的 harness 体系。甚至还内置了一个 resume-claude 的 skill，虽然技术门槛不高，但体现了产品的细心。
• 额外功能：Grok Build 本身可以外接其他模型，并且支持同时使用多个模型。但站内反馈显示，如果将 Grok 反代出去，消耗额度会快很多。
• 最终规划：作者认为团队依然需要一款高效准确理解意图的“秘书模型”，而 Grok Build 中的 Grok 4.5 在这方面表现不错。
• 隐藏档位提示：用户可以通过 /effort xxx 输入一个不存在的值来发现 Grok Build 实际上存在 7 个档位选项，而默认的 /model 只展示前三档。输入 max 也会自动变成 xhigh。

关键要点

• Claude Code 曾因安插后门导致用户流失，安全性成为选择模型的重要考量。
• GPT 模型在中文理解和意图捕捉上存在不足，需搭配其他模型使用。
• GLM 在使用 opencode go 的 200k 上下文时体验不佳，且账号切换频繁。
• 讯飞等厂商的 coding plan 高 busy 率（90%）严重影响可用性。
• Grok 4.5 在 Grok Build 中表现优异：速度快、表达好、产品细心。
• Grok Build 默认兼容 Claude 的 harness 体系，甚至内置了 resume-claude skill，降低了迁移成本。
• Grok Build 支持外接其他模型并协同使用，但反代可能加速额度消耗。
• Grok Build 实际上有 7 个档位（包括 xhigh/max），默认只显示前三档，可通过 /effort 参数调试发现。

意义与影响

Grok Build 凭借其对 Claude harness 的兼容性、内置迁移 skill、出色的模型表现（Grok 4.5）以及灵活的档位设计，为当前混乱的 AI coding 工具市场提供了一个值得关注的替代方案。它降低了用户从 Claude 生态切换的成本，同时解决了多种模型混用时的意图理解与效率问题。对于依赖编码助手的开发者团队而言，Grok 4.5 作为“秘书模型”的角色定位有助于提升整体开发流程的顺畅度。此外，隐藏档位的设计也体现了产品在精细化控制上的用心——用户可以通过探索获得更高性能，但也需注意额度消耗。这一案例表明，AI 编码工具的竞争已从单纯的模型能力扩展到产品体验、生态兼容性和细节设计，未来用户将更倾向于选择那些能无缝迁移、开箱即用且理解力强的解决方案。