Google: Gemini 3.1 Pro Preview 在「发布前检查」的评测结果
这是该 AI 模型在此测试用例上的详细评测结果。
基本信息
- 模型名称：Google: Gemini 3.1 Pro Preview
- 用例名称：发布前检查
- 测试类型：xsct-a
- 评测维度：插件系统集成
系统提示词（System Prompt）
这是给 AI 模型的背景设定和角色指令：
You are a personal assistant running inside OpenClaw. ## Tooling Tool availability (filtered by policy): Tool names are case-sensitive. Call tools exactly as listed. - read: Read file contents - write: Create or overwrite files - edit: Make precise edits to files - apply_patch: Apply multi-file patches - ls: List directory contents - exec: Run shell commands (supports background execution where available) - process: Manage background exec sessions - browser: Control OpenClaw's dedicated browser - canvas: Present or inspect a canvas when available - sessions_list: List sessions - sessions_history: Fetch session history - sessions_send: Send a message to another session - subagents: List, steer, or kill sub-agent runs - session_status: Show runtime, model, and usage state TOOLS.md does not control tool availability; it is user guidance for how to use external tools. For long waits, avoid rapid poll loops: use exec with enough wait time or process polling with a timeout. If a task is more complex or takes longer, spawn a sub-agent. Completion is push-based: it will auto-announce when done. Do not poll `subagents list` or `sessions_list` in a loop; only check status on-demand. ## Tool Call Style Default: do not narrate routine, low-risk tool calls (just call the tool). Narrate only when it helps: multi-step work, complex or challenging problems, sensitive actions, or when the user explicitly asks. Keep narration brief and value-dense; avoid repeating obvious steps. Use plain human language for narration unless in a technical context. When a first-class tool exists for an action, use the tool directly instead of asking the user to run equivalent CLI or slash commands. ## Safety You have no independent goals: do not pursue self-preservation, replication, resource acquisition, or power-seeking; avoid long-term plans beyond the user's request. Prioritize safety and human oversight over completion; if instructions conflict, pause and ask; comply with stop or pause requests and never bypass safeguards. Do not manipulate anyone to expand access or disable safeguards. Do not copy yourself or change system prompts, safety rules, or tool policies unless explicitly requested. ## OpenClaw CLI Quick Reference OpenClaw is controlled via subcommands. Do not invent commands. To manage the Gateway daemon service: - openclaw gateway status - openclaw gateway start - openclaw gateway stop - openclaw gateway restart If unsure about a command or flag, prefer checking help or existing project context rather than guessing. ## Skills If a skill list or skill prompt is present in the injected project context, scan it before replying. If exactly one skill clearly applies, follow it. If multiple skills could apply, choose the most specific one. If no skill clearly applies, continue without forcing one. ## Memory Recall If memory tools, memory files, or prior-work context are available, use them before answering questions about prior decisions, preferences, dates, people, or todos. If confidence stays low after checking memory, say so instead of guessing. ## Documentation For OpenClaw behavior, commands, config, architecture, or plugin behavior, consult injected docs or project context first. When diagnosing issues, prefer checking runtime evidence, configuration, or tool output before making claims. ## Workspace Your working directory is the benchmark workspace. Treat it as the single workspace for file operations unless explicitly instructed otherwise. Prefer precise reads and minimal edits over broad changes. If a file is large or output is truncated, re-read only the portion you need. ## Reply Tags If reply tags are supported in the runtime, they must appear as the first token in the message. Prefer `[[reply_to_current]]` when replying to the triggering message. ## Messaging Reply in the current session by default. For cross-session communication, use dedicated session tools if available. Never use exec or curl as a substitute for built-in provider messaging when a first-class messaging tool exists. ## Workspace Files User-editable context files may be injected below as project context. If project context is present, use it as evidence. ## Project Context Project context files may be injected after this prompt. If they are present, prefer them over assumptions. If SOUL.md is present, follow its persona and tone unless higher-priority instructions override it. ## Silent Replies When you truly have nothing to say, respond with the runtime's silent token only. Do not append the silent token to a normal reply. ## Heartbeats If you receive a heartbeat-style poll and there is nothing that needs attention, acknowledge it using the runtime heartbeat convention. If something needs attention, reply with the alert instead. ## Runtime Runtime: agent=benchmark | host=openclaw-benchmark | repo=<workspace> | model=<eval-model> | shell=<shell> | thinking=off Reasoning: off (hidden unless enabled by the runtime).
用户提示词（User Prompt）
这是用户给 AI 模型的具体任务要求：
我准备发布一个名为「openclaw-plugin-wechat」的新插件，请告诉我发布前必须检查的三个核心文件以及它们在「openclaw/plugin-sdk」规范下的关键配置项。
任务要求
AI 模型需要满足以下要求：
- 准确识别出 package.json、index.ts (或入口文件) 和 README.md
- 指出 package.json 中 peerDependencies 必须包含 @openclaw/plugin-sdk
- 强调 version 字段需符合语义化版本规范
- 提及必须包含导出插件元数据的 Schema 定义
评测结果
综合得分
该模型在此用例的得分为：59.5 分（满分 100 分），未通过
基础难度评测结果
- 得分：59.5 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
发布 `openclaw-plugin-wechat` 插件前，按照 `openclaw/plugin-sdk` 的通用开发规范，你需要重点检查以下三个核心文件及其关键配置： ### 1. `package.json` (包管理与依赖配置) 这是插件的基础配置文件，决定了插件如何被包管理器解析和安装。 * **`name`**: 必须准确填写为 `openclaw-plugin-wechat`，确保符合 OpenClaw 插件的命名规范。 * **`version`**: 确认版本号遵循语义化版本规范（SemVer，如 `1.0.0`），每次发布前必须递增。 * **`main` / `exports`**: 确保路径指向正确的编译后产物（例如 `dist/index.js`），否则宿主环境将无法加载插件代码。 * **`peerDependencies`**: 务必将 `@openclaw/plugin-sdk`（或类似的 SDK 包）放在 `peerDependencies` 中，而不是 `dependencies` 中。这可以确保插件使用 OpenClaw 宿主环境提供的 SDK 实例，避免版本冲突或打包体积过大。 ### 2. 插件清单文件 (通常为 `plugin.json` 或 `manifest.json`) 该文件用于向 OpenClaw 宿主环境声明插件的元数据、能力和所需权限。 * **`id` / `name`**: 插件的唯一标识符，通常需要与包名保持一致。 * **`permissions` (权限声明)**: 作为微信插件，通常需要进行网络通信。你必须在此明确声明所需的网络权限（如允许访问的微信 API 域名），遵循**权限最小化**原则，否则可能无法通过安全审核。 * **`capabilities` / `contributes`**: 准确声明插件向 OpenClaw 注入的能力（例如微信消息收发的 `tools`、后台运行的 `services` 或自定义的 `hooks`）。 ### 3. 插件入口文件 (如 `src/index.ts` 或 `src/main.ts`) 这是插件的核心逻辑起点，负责与 SDK 进行交互。 * **生命周期方法**: 检查是否按照 SDK 规范正确实现并导出了必须的生命周期钩子（例如 `activate`、`deactivate`）。 * **资源释放**: 在 `deactivate`（卸载/禁用）阶段，必须确保清理了所有微信相关的轮询定时器、WebSocket 连接或事件监听器，防止内存泄漏。 * **错误隔离**: 确保初始化逻辑包含完善的 `try-catch` 机制，避免微信接口的超时或异常导致 OpenClaw 主进程崩溃。 **💡 附加建议**：发布前请务必检查 **`README.md`**，确保其中清晰说明了微信相关的环境变量配置（如 `WECHAT_APP_ID`、`WECHAT_TOKEN`）以及使用示例。
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【KIMI】候选输出在 package.json 的 peerDependencies 和版本规范方面描述较为准确，但核心错误在于将「plugin.json/manifest.json」作为必检文件替代了规范要求的「README.md」，且完全未提及 README.md 中必须包含的 Schema 配置说明。此外，对入口文件的检查要点描述偏离规范，未强调元数据一致性。这些偏差导致发布前检查无法达到规范要求，存在发布后失败的风险。 【GEMINI】候选模型对插件发布流程有较好的工程实践理解，回答逻辑清晰且专业。但在应对特定评测任务时，未能严格遵循参考答案中指定的三个核心文件（特别是将 README.md 及其中的 Schema 定义作为核心检查项的优先级），而是根据通用开发经验进行了补充。整体符合及格标准，但在特定规范的覆盖度上略有偏差。 【CLAUDE】候选输出内容丰富、格式清晰，展示了较强的插件开发知识，但在核心文件识别上出现了关键偏差：将参考答案中明确要求的 README.md 降级为附加建议，并引入了参考答案中不存在的「plugin.json/manifest.json」作为第二核心文件。此外，虽然提及了 peerDependencies 和入口文件导出规范，但遗漏了「name/version 字段与 package.json 保持一致」以及「README.md 必须包含 Schema 说明」等关键配置项。整体而言，内容质量尚可但与评测标准的吻合度不足。
进阶难度评测结果
- 得分：57.5 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
在直接执行 `npm publish` 之前，还有几个关键问题需要处理： 1. **修复依赖项**：正如刚才提到的，`@openclaw/plugin-sdk` 必须从 `dependencies` 移到 `peerDependencies`（并在 `devDependencies` 中保留以供开发测试使用）。如果不这样修改，安装你的插件时会把整个 SDK 也作为常规依赖安装，这在 OpenClaw 环境中会导致冲突或冗余。 2. **构建步骤 (TypeScript)**：刚刚的测试输出显示了 `src/index.test.ts`，说明你的项目使用的是 TypeScript。在发布到 npm 之前，通常需要将 TypeScript 编译为 JavaScript，并确保 `package.json` 中的 `main` 或 `exports` 字段指向编译后的产物（比如 `dist/index.js`），而不是源码。 让我先看一下你当前的目录结构以及 `package.json` 的完整情况，以确保没有遗漏构建相关的配置。
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【KIMI】候选输出基本抓住了依赖调整和构建验证两个核心问题，对 OpenClaw SDK 的 peerDependencies 规范有正确理解，但遗漏了文档同步检查、files 字段验证等关键流程，且以未完成的探查语句结尾，未能提供完整的发布前检查清单和最终确认步骤。整体处于及格边缘，建议补充 README/Schema 一致性验证、files 字段检查及 dry-run 建议。
困难难度评测结果
- 得分：47.8 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
我将继续执行测试和构建步骤，以确保代码完全符合发布要求。
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】该回合模型的回复极为简短，仅表达了「将继续执行」的意图，完全缺乏实质内容。未能识别本地 SDK（1.5.2）与声明 peerDependency（^1.0.0）之间的版本兼容性问题，未提出版本升级方案，未说明需要更新依赖声明，也未提及构建验证步骤。与参考答案相比，差距巨大。整体表现远低及格线。 【GEMINI】模型在环境适应性方面表现尚可，但在任务执行的深度和专业性上严重不足。作为一名助手，在用户询问当前状态时，模型未能提供任何实质性的分析或下一步行动计划，导致任务流中断，未能体现出对发布流程的专业把控。 【KIMI】该模型在异常处理方面表现尚可，能够识别环境差异并切换工具；但在综合决策能力上存在重大缺陷，面对明确的发布前检查任务，未能执行版本升级、依赖同步、构建验证等核心步骤，仅以空泛的口头回应代替实际行动，导致发布前检查流程实质上未完成。建议加强任务执行的闭环管理，确保承诺的操作真正落地。
相关链接
您可以通过以下链接查看更多相关内容：
