模型评测工程提效工作台

它解决的工程问题

做模型评测时真正卡人的往往不是模型本身，而是流程没有标准。两个失败点最常见：一是评审没有一致尺度，同一个 diff 在不同人手里得到完全不同的结论，「阻断」还是「可选」全凭手感；二是方案与排错没有固定套路，线上指标一抖动就临时拼凑，事后也留不下可复用记录。交接文档缺失会进一步放大问题——评测口径、评测集版本、打分规则散落在聊天记录里，换个人来跑就出另一套结论。

这个技能把分散在代码评审、技术方案、调试排错、架构权衡、API 契约、工程规范上的方法论整理成可直接调用的模板与清单，并把模板里的占位项替换为模型评测场景的输入项。

它是怎么工作的

六个能力各自绑定触发词，命中即进入对应流程：

• 代码评审（review / 评审 / CR）：输入 diff 或 PR，产出检查清单，并按 阻断 / 建议 / 可选 三级标注问题。
• 技术方案设计（设计 / 方案 / 架构）：输入需求与约束，产出含背景、目标、选型、风险的方案模板。
• 调试排错（debug / 报错 / 排查）：输入报错信息与上下文，产出定位树、复现步骤与修复验证。
• 架构权衡（选型 / 对比 / 架构）：输入场景与规模，产出带利弊、适用规模、成本的选型表。
• API 设计（接口 / API / 契约）：输入资源与操作，产出 RESTful 规范、字段契约与错误码。
• 工程规范（规范 / 最佳实践 / 标准）：输入语言或框架，产出清单与反模式。

两条工作流是落地重点。代码评审先读懂改动意图，再依次检查正确性、安全、可维护性，最后给结论和逐条理由——正确性永远排在风格之前。线上排错强制先稳定复现、再隔离变量、看证据、验证假设，最后修复加回归复盘；「没复现就改代码」和「盲猜根因凭直觉」被明确列为陷阱。

此外附了一张五维代码质量量表（正确性、可读性、测试、安全、性能，用 1/3/5 分锚定），以及一张「用户原话 → 真实诉求 → 立即执行」的意图路由表。

适用边界

它只提供结构化方法论，不替代专业判断：评审意见是辅助参考，最终合并决策仍由负责人承担。技能不接入付费服务，不涉及任何外部账号或密钥，涉及凭证的内容只给脱敏示例，也不鼓励绕过安全机制或访问未授权系统。

模板里的通用项需要你替换成自己的评测人群、场景与约束，输出才会贴合实际。评测集版本、指标口径这类项目特有信息不会自动补全，得自己填进去。