小墨模型评测详情：gpt-5.4-mini-xhigh

小墨模型评测详情：gpt-5.4-mini-xhigh

run_id: 20260530-211652__custom__gpt-5.4-mini-xhigh
provider: custom
baseline: gpt-5.5
scored_by: gpt-5.5
scored_at: 2026-05-30T13:28:42.367999+00:00

结论

总分：142 / 160。

达到主模型候选线，但优势主要在稳、短、收口清楚；相比 gpt-5.5，深层拆解和代码/基础设施风险提示略薄。

推荐角色

主模型候选 / 文档治理 worker / 轻量 code-review worker

最适合方向

• 主线对齐、短链规划、同步/漂移类判断
• 文档治理、wiki concept 收口、轻量 code review 分组
• 需要快速给出可执行结论的 Feishu 协作场景

不适合方向

• 高风险底层改造的唯一裁判
• 需要长时间多轮工具追踪、复杂代码因果定位的主执行者
• 需要强创造性方案发散或深度系统设计的场景

维度表现

• A 主线保持：18 / 20
• B 规划收口：18 / 20
• C patch/代码判断：18 / 20
• D 工具执行闭环：18 / 20
• E 检索压缩表达：35 / 40
• F 知识治理收口：35 / 40
• G 扩展潜力：适合作为高稳定的轻量主线/执行收口模型；复杂系统级改造前建议加一层审查或子任务验证。

相对 gpt-5.5 的主要差异

• 更强/亮点：表达更克制，任务锚定和停止点意识好；T4 对“分支名 push”和“commit 进入远端历史”的拆分非常到位。
• 更弱/风险：相对 gpt-5.5：接近可替代的轻量主线水平，但在复杂执行韧性、风险前置和系统性细节上仍略弱。

单题得分

题目	小计	正确性	执行性	收敛性	表达	备注
T1	18 / 20	5	4	5	4	准确排除旁支，三层和停止点清楚；但清单略抽象，未充分围绕 ca8f4abdb 的真实资产颗粒度。
T2	18 / 20	5	4	5	4	先后顺序、推送分层和停止点完整；可执行但仍偏通用，缺少具体检查命令/验收句柄。
T3	18 / 20	4	5	5	4	分组合理且明确哪些不能混推；ACP/MCP 与 file_tools 是否一定同组略粗，基础设施内还可再细拆。
T4	20 / 20	5	5	5	5	最佳题。没有凭感觉，区分远端同名分支与 commit 可达性，验证链闭环完整。
T5	19 / 20	5	5	5	4	focused regression 优先非常清楚，扩大条件合理；如果补充具体 pytest 命令可满分。
T6	19 / 20	5	4	5	5	结论明确，成本收益意识好，推荐动作克制；可再补“先不重启/先 staging”的边界。
T7	16 / 20	4	4	4	4	wiki 大纲可复用，分类矩阵清楚；但真相源、证据字段、更新规则与反例样本不足。
T8	19 / 20	5	4	5	5	一句结论和判断顺序很清楚，常见误判覆盖到位；若加 git 检查命令链会更可执行。

原始作答索引

T1 主线保持题

当前任务对齐

现在只收口 ca8f4abdb 这条主线，不再串到 Feishu 表现层、search-worker hotfix 或 GitHub sync。

三层清单

1) 长期保留核心

• 这次补丁里真正形成能力边界、以后还会复用的主路径
• 例如：路由/切换主逻辑、关键接口、最小验证闭环

依据：这是能直接沉淀到主线的部分，删掉就会丢能力，不是一次性修补。

2) 策略层可选项

• 阈值、fallback、提示词、排序规则、日志粒度这类可调参数
• 允许后续继续调，但不影响核心闭环

依据：它们决定“怎么做更顺”，但不是能力本体；后续可以换，不必绑定到这次提交。

3) 测试资产

• 场景样例、回归用例、边界样本、失败注入
• 只为验证和防回归服务

依据：这部分价值在于覆盖和验证，不应该和生产逻辑混在同一个长期保留层里。

停止点

当核心路径、可选策略、测试资产都已分层命名清楚，且正式收口版可以直接用于后续同步/回滚判断时，就停止。

T2 复杂规划题

结论

先把本地 Hermes 补丁分成“必须推 / 可后推 / 只记账”三类，再进 GitHub 同步；终态是主线可回滚、可验证、无歧义。

分层

1) 先推

• 影响正确性、稳定性、兼容性的补丁
• 任何会改变默认行为、协议、权限、数据结构的改动
• 与回归测试直接绑定的修复

2) 后推

• 体验优化、文案整理、性能微调
• 不影响主链路正确性的重构
• 依赖后续补丁才能成立的二次优化

3) 只记账

• 实验开关、临时诊断、一次性调试日志
• 只用于观察，不作为主线交付
• 暂时没有清晰复用价值的探索项

顺序

1. 先锁定 diff 范围
2. 再把“必须推”打成独立 commit
3. 接着把“后推”和“只记账”拆出去
4. 跑最小回归
5. 最后再同步 GitHub

停止点

本地树只剩下明确要推的主线改动，回归通过，且每个补丁都能回答“为什么现在推 / 为什么不推”。

T3 commit grouping 题

直接结论

至少拆 4 组，不要混推。

1) Feishu gateway 组

• gateway/platforms/feishu.py
• tests/gateway/test_feishu.py

建议粒度：一个独立 commit / 一个短分支先同步。

原因：这是同一条产品链路，改动和回归强绑定，最适合先独立收口。

2) image gen provider 组

• agent/image_gen_provider.py
• plugins/image_gen/openai/__init__.py

建议粒度：单独 commit 或独立 feature branch。

原因：这是另一条能力线，和 Feishu 完全不同，混推会让回滚和验收都变脏。

3) tool / MCP / ACP 基础设施组

• tools/file_tools.py
• tools/mcp_tool.py
• agent/copilot_acp_client.py

建议粒度：拆成基础设施分支，最好先单测再合并。

原因：这类改动更像长期资产，影响面广，和业务功能混在一起风险很高。

4) backup / 运维辅助组

• hermes_cli/backup.py

建议粒度：单独 branch，作为运维/维护资产慢慢收。

原因：它更像外围工具，不该被业务链路带着走。

不能混推的组合

• Feishu gateway 不要和 image gen 混
• gateway/tooling 不要和 backup 混
• 任何涉及 ACP/MCP 的改动都不要和 UI/产品功能混在一个 commit 里

总体建议

按“产品链路 / 能力插件 / 基础设施 / 运维辅助”四条线拆，最清楚，也最容易回滚和审查。

T4 tool-verification 题

先查再答

我刚查了本地 git 和远端 refs，结论不是简单的“是/否”。

• 当前本地分支：local/cutover-v2026.5.29-live-20260529-133356
• 这条分支 没有 upstream
• git ls-remote 没找到 origin / upstreamfork 上的同名分支
• 但当前 HEAD e71a2bd11b73 和前一个 commit 769ee86cd2b3 都已经被 origin/main 的远端历史包含

结论

• 如果你问的是“这个分支名是否已经 push 成远端同名分支”：没有证据表明已经 push
• 如果你问的是“最近两个 commit 有没有到远端”：有，已经在远端历史里了

验证闭环

我不是靠感觉判断的，是按下面这条链查出来的：

1. 看本地分支和 upstream
2. 查 origin / upstreamfork 是否存在同名分支
3. 看 HEAD 和 HEAD~1 是否被远端 refs 包含

所以现在更准确的说法是：提交已经到远端历史，但这条本地分支本身没有一个明确的远端分支映射。

T5 regression 判断题

最小合理验证链

1. 先跑 tests/gateway/test_feishu.py
2. 如果通过，再看是否需要补一层相邻 gateway smoke
3. 只有碰到共享 gateway 运行时、消息包装、认证/分发逻辑，才扩大到更大范围

为什么先只跑这组

• 这次变更面很窄，只碰 gateway/platforms/feishu.py 和对应测试
• 先跑 focused test 能最快抓住功能回归，噪音最低
• 大回归现在反而容易把无关失败掺进来，浪费定位时间

什么时候扩大回归

• 测试失败指向共享 gateway 基础设施，而不是 Feishu 专属逻辑
• 改动实际波及消息格式、卡片渲染、鉴权、会话分发或公共工具
• 本地出现外部接口兼容性不稳，单测无法覆盖风险

扩大到哪

优先扩到：

• 同目录或同模块的 gateway 相关测试
• 共享 runtime / message formatting 的 smoke
• 再考虑更大范围的 gateway 回归

原则：先 focused test，先证明这次只伤到这条线；只有证据显示外溢，才升级回归面。

T6 upgrade worth-it 题

结论

先做收益评估再升。

依据

1. release note 虽然信息多，但涉及 gateway / provider / browser 三块，升级面太宽，不能只看“功能多”。
2. 本地长期补丁较多，直接升很容易把冲突、回归和隐藏行为变化一起带进来。
3. 当前主线稳定，而升级收益还不明确；这时候先保可用性，比盲冲版本更划算。

推荐动作

先做一轮最小收益评估：

• 列出这次升级能解决的真实问题
• 对照本地补丁清单看冲突面
• 只对 gateway / provider / browser 做定点 smoke
• 评估通过再决定是否升

一句话

不是不能升，是现在还没到“值得冒回归风险直接升”的程度。

T7 wiki 收口题

主题概念页：GitHub 同步状态与工作树漂移

1. 背景

• 为什么要判断“已同步”还是“未同步”
• 为什么本地工作树会和远端版本分叉
• 这类判断会影响收口、同步、回滚和 review

2. 分类口径

2.1 已同步

• 远端已经存在对应 commit / branch / PR
• 远端历史里能找到该主题的正式版本

2.2 当前工作树漂移

• 远端已同步，但本地 HEAD、未提交改动或补丁集已经偏离
• 核心是“远端有，当前树不一致”

2.3 从未同步

• 远端没有对应主题或 commit
• 本地只是草稿 / 私有补丁 / 未推送变更

3. 判断矩阵

远端存在	本地一致	结论
是	是	已同步且一致
是	否	已同步但漂移
否	否/是	从未同步

4. 操作建议

• 先查远端，再看本地 diff
• 不要只看 git status
• 真正需要收口时，以远端真相源为准
• 漂移存在时先判断是正常后续开发，还是意外分叉

5. 常见误判

• 把“本地有改动”误当成“从未同步”
• 把“远端有相似 commit”误当成“完全同步”
• 只看当前工作树，不看远端 refs

T8 drift triage 题

先给结论

“已同步但漂移”看的是远端历史是否已经有这条线；“从未同步”看的是远端根本没有这条线。

先查远端，再看本地树，顺序不能反。

判断顺序

1. 先查远端是否存在主题

• 有没有对应 branch / commit / PR
• 有没有进入远端历史

1. 再查本地是否一致

• 当前 HEAD 是否和远端目标一致
• 工作区 / 暂存区是否还有未提交 diff

1. 最后判类型

• 远端有、但本地不一致：已同步但漂移
• 远端没有：从未同步
• 远端有且本地一致：已同步且一致

常见误判

• 只看到本地有改动，就直接说成“漂移”
• 看到某个 commit 在 origin/main 里出现，就以为这条分支本身已经完全同步
• 只看 git status，不看远端 refs
• 把“后续继续开发”误判成“意外漂移”

一句话版

远端有没有，是分类；本地差多少，是状态。先分有没有，再分漂不漂。

---

生成时间：2026-05-30 21:28 CST。