grok-build / xai-grok-shell 0.2.10 变更解读/check-work命令迁移与小于 8×8 像素图片的拒绝策略【免费下载链接】grok-buildSpaceXAIs coding agent harness and TUI. Fullscreen, mouse interactive, extensible.项目地址: https://gitcode.com/gh_mirrors/gr/grok-build本篇基于开源仓库 grok-build 中xai-grok-shell的 0.2.10 版本变更记录 展开围绕该版本的两项核心变更——/check重命名为/check-work旧命令保留过渡期兼容以及小于 8×8 像素的图片改为直接拒绝并给出清晰提示——结合xai-grok-shell的源码、常量定义与测试用例做纵深解读。读完本文你将理解 grok-build 命令行技能skill的命名管理与清理机制、会话中图片归一化管线的尺寸下限与上限约束以及为什么有图不如无图的超小图片会被拒之门外。版本背景一份按版本维护的结构化变更记录在仓库的 changelogs 目录 下每个发布版本都维护一份0.2.x.md变更说明及其机器可读的0.2.x.json对偶文件并统一汇总进 CHANGELOG.md。以本版本为例0.2.10.md面向读者的变更说明按Features与Bug Fixes两类组织0.2.10.json结构化条目每条包含categoryfeatures/fixes与breaking_change标记两项变更均标记为breaking_change: false即非破坏性变更用户升级无需迁移动作。0.2.10 是典型的小幅打磨版本一项命令更名带过渡兼容一项图片输入校验修复。下文分别拆解其设计与实现。变更一/check重命名为/check-work变更内容与兼容策略/check已重命名为/check-work过渡期内旧命令继续可用。这是 grok-build 对内置斜杠命令slash command / skill的命名整理。原文档明确给出兼容性承诺过渡期内/check与/check-work两个名字同时有效用户可以逐步迁移习惯不必立即改动脚本或肌肉记忆breaking_change: false也从数据层面确认了这一点。源码证据新旧名称在技能表中并存在 src/builtin.rs 中FORMER_PLATFORM_SKILL_HASHES静态表第 93-115 行附近同时收录了check-work与check两个技能名及其 SHA-256 哈希值例如(check-work, 1d9044a4f02c3abcb4153783d451611731f669643ba371bb6069a1e1c2d3e95d)(check, 5ddcd2f42eaeb6efc27dc1a651ad36be71e331e58da8ed16ec7a28b2f8bb0d4e)从源码结构看该表服务于purge_stale_extracted_skills第 134-168 行预发布的二进制会把平台技能解压到$GROK_HOME/skills/其中旧版平台技能会遮蔽bundled/skills/中的内置版本因此启动时需要对能被证明是官方发布体的目录做清理check与check-work同时列入表中正说明新老名称在过渡期内被同等对待。清理逻辑是保守的只有目录下SKILL.md的字节内容含对~/.grok/主目录改写做逆操作后的版本能匹配已知哈希才删除用户自建技能与任何编辑过的文件一律保留fail-closed 设计。对应的单元测试src/builtin.rs中shipped_hash_table_is_well_formed断言哈希表中的技能名集合恰好包含best-of-n、check、check-work、code-review、create-skill、create-workflow、docx、help、imagine、pptx、xlsx等并逐一校验哈希为 64 位十六进制串防止表单损坏导致误删用户文件。迁移要点新写法/check-work旧写法/check在过渡期内仍然有效无需紧急迁移从0.2.10.json的breaking_change: false可以确认本次更名不涉及配置格式或行为破坏。变更二小于 8×8 像素的图片直接拒绝变更内容小于 8×8 像素的图片现在会被拒绝并给出清晰提示而不是产生马赛克式的块状结果。在此之前超小图片会进入归一化管线并被放大处理最终得到无意义的块状blocky画面既浪费请求字节又污染多模态上下文。0.2.10 起这类输入在入站阶段即被拦截并携带明确的原因说明。尺寸下限8×8 每边下限与 512 总像素下限在 src/session/image_normalize.rs 中定义了两级地板常量第 54-59 行常量取值含义MIN_VISION_SIDE_PX8任一像素边长不得小于 8对应后端 API 的每边下限MIN_VISION_TOTAL_PX512像素总数宽×高不得小于 512对应后端MIN_IMAGE_PIXELSMAX_VISION_TOTAL_PX178_956_970后端像素上限MAX_IMAGE_PIXELS超过则拒绝解码注意8×8 恰好满足每边下限64 像素但仍低于 512 总像素下限因此同样会被拒绝——这是8×8 拒绝背后的完整规则。源码注释还解释了为什么必须在前端拦截16×16 的图标只有 256 像素若放行会在后端触发 400且毒化之后每一轮对话。拒绝时的提示消息第 442、448 行附近包含明确原因每边过小too small ({orig_w}×{orig_h}); images must be at least 8×8 pixels总像素不足too small ({orig_w}×{orig_h} {px} px); images must have at least 512 total pixels拒绝发生在哪几个入口从源码看尺寸下限在两条路径上同时生效消息发送前的批量归一化normalize_images/normalize_images_in对每个ImageContent解码、校验结构完整性与尺寸输出四类结果——Unchanged原样通过、Compressed压缩/降采样、Failed失败、ReEncodingOversized超大但保留原样并回注提示失败与过小的图片会进入dropped列表并通过image_dropped_notice系统提醒反馈给模型指明是第几张图、原尺寸多少。read_file工具的内联附图门控src/session/acp_session_impl/tool_calls.rs 第 2478-2499 行inline_attach_verdict对 base64 数据进行解码与头部探测返回三态InlineAttachVerdictTooSmall改为注入文本[Image from {path} was not attached: too small for vision models]Unreadable注入[Image from {path} was not attached: invalid or unreadable image data]fail-closed不可验证即不放行Attach正常构造data:{mime};base64,...内联附图。配合persisted_image_reject_reasonimage_normalize.rs第 285-307 行在会话加载历史图片时也会校验截断的 JPEG/PNG 报structurally incompleteGIF/BMP/TIFF 报API-rejected format低于下限报below dimension floor高于上限报above pixel ceiling。测试用例如何锁定边界行为src/session/image_normalize_tests.rs 用一组边界用例把这些规则钉死sub_8x8_image_is_rejected第 1000-1017 行4×3 图片被丢弃丢弃备注必须同时包含4×3、8×8与too small而 30×30 正常放行exactly_8x8_is_rejected_by_total_pixel_floor第 1020-1032 行8×864 像素虽然过了每边下限但总像素低于 512 仍被拒绝备注含total pixelsseven_by_eight_is_rejected第 1034-1042 行单边 7 像素即触发拒绝备注含7×8below_total_pixel_floor_is_dropped第 572-590 行16×16256 像素被拒、32×16恰好 512 像素原样通过inline_attach_verdict_gates_floors_and_fails_closed第 713-741 行16×16 →TooSmall32×16 →Attach非 base64 与伪图片 →Unreadable。这些测试直接服务于 0.2.10 的修复目标宁可明确拒绝也不要产出块状垃圾图。与整体图片归一化管线的衔接尺寸下限只是该管线的一环。image_normalize.rs同时定义了发送侧的上限约束第 30-49 行MAX_ENCODE_SIDE_PX 2000任意边长超 2000px 即降采样模型无关的侧边钳制图片在摄入时归一化一次会话中途可换模型MAX_ENCODE_PIXELS 2_408_448总像素预算与 v9 tokenizer 的image_filter_max_pixels对齐超过即降采样外部 harness 的严格路径STRICT_MAX_ENCODE_SIDE_PX 1024JPEG 质量阶梯[88, 80, 72, 64, 56, 48, 40, 32]、CatmullRom降采样滤波、64MB 的NormalizeCache归一化缓存等。理解 8×8 拒绝实际上是理解整条图片从附件到请求管线的第一步8×8 地板 → 512 总像素地板 → 2000px/2.4Mpx 压缩钳制 → 178.9Mpx 解码上限每一层都对应一个明确的前置校验避免把不合规的 payload 推到后端换来 400 响应。升级与使用注意事项0.2.10 的两项变更均为非破坏性breaking_change: false可安全升级斜杠命令建议使用新名/check-work但旧名/check在过渡期内依旧可用若$GROK_HOME/skills/下存在旧平台解压的技能目录启动时会按哈希比对自动清理用户自建技能不受影响向会话附加或通过read_file内联读取图片时请确保边长 ≥ 8px 且总像素 ≥ 512否则会收到明确的拒绝提示消息侧为too small (...×...)备注工具侧为[Image ... was not attached: too small for vision models]正常尺寸但结构损坏截断、CRC 错误的图片同样会被 fail-closed 拦截不要依赖宽容解码器的侥幸通过。相关文件索引变更记录crates/codegen/xai-grok-shell/changelogs/0.2.10.md 与结构化条目 crates/codegen/xai-grok-shell/changelogs/0.2.10.json汇总见 crates/codegen/xai-grok-shell/CHANGELOG.md技能名/哈希表与旧技能清理crates/codegen/xai-grok-shell/src/builtin.rs图片归一化与尺寸常量crates/codegen/xai-grok-shell/src/session/image_normalize.rs边界测试crates/codegen/xai-grok-shell/src/session/image_normalize_tests.rsread_file内联附图门控crates/codegen/xai-grok-shell/src/session/acp_session_impl/tool_calls.rs。【免费下载链接】grok-buildSpaceXAIs coding agent harness and TUI. Fullscreen, mouse interactive, extensible.项目地址: https://gitcode.com/gh_mirrors/gr/grok-build创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考