免费在 GitHub 公开中文介绍

spike

在正式开发前制作并运行小型原型，验证想法是否可行或比较不同方案。通过执行结果形成依据，给出采用、调整或放弃方案的判断及后续建议。

原文查看原文说明

Run throwaway prototypes to validate feasibility, compare approaches, and report a verdict.

openclaw/openclaw

AI 评分100分/ 100 查看安装方法

适用场景

验证想法是否可行
在相同条件下比较两种方案
正式开发前测试边界条件
整理采用或放弃方案的依据

中文介绍

功能

制作并运行小型原型，验证想法是否可行。先明确要验证的问题，查阅资料或代码，再编写最小实现。还会测试一种意外输入或失败条件，以执行命令、输出和测量值为依据，给出VALIDATED、PARTIAL或INVALIDATED的判断，并整理下一步建议。

适用场景

适合在正式开发前确认难点能否实现，也可用相同输入和评价指标比较两种方案，或为决定放弃某个方案保留依据。

使用示例

“用最小原型验证这个想法是否可行。”
“在相同条件下比较方案A和B，整理结果并推荐方案。”

注意事项

如果阅读资料或代码就能回答问题，或任务要求的是生产实现，则不使用此技能。原型原则上放在.tmp/openclaw-spikes/<slug>，纳入生产代码时应按常规实现重新编写。评估外部依赖时，还会检查维护更新情况、文档、许可证和安装成本。

本介绍由 AI（OpenAI Codex）根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

客观评估

AI 仅根据 SKILL.md 的内容，从 4 个方面进行了评估。星标数和热度不计入评估。

指令清晰度能否看出何时使用、做什么: A良好明确用于正式开发前的可行性验证，并排除仅靠阅读即可回答的问题。
步骤具体性步骤、输入输出和示例是否具体: A良好列出提问、调研、实现、失败条件测试和判断步骤，并规定含证据的输出格式。
安全性发送数据、删除文件、执行命令等是否有说明: A良好明确原型存放位置、禁止直接纳入生产，并要求在超出小型原型范围的多方案实现前询问。
安装难易度所需工具和 API 密钥是否少且有说明: A良好未要求固定工具或密钥，并指示避免Docker、环境文件等配置。

总分按每项 A=25 分、B=15 分、C=5 分相加。由 AI（OpenAI Codex）于 2026年10月19日评估。仅供参考，安装前请同时查看原文。

如果您认为评估有误，请申请复核

包含的文件（1）

SKILL.md1.8 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

Spike

Use when the user wants to test an idea before committing to a real build: "spike this", "quick prototype", "is this possible", "compare A/B", "before we build".

Do not use when reading docs/code can answer the question, or when the user clearly asked for production implementation.

Loop

Question: state the concrete feasibility question.
Research: read enough docs/source to choose credible approach.
Build: create the smallest runnable artifact that validates or invalidates the idea.
Stress: try one edge case or failure mode.
Verdict: VALIDATED, PARTIAL, or INVALIDATED.

Output shape

Default workspace: .tmp/openclaw-spikes/<slug> unless user asks for a tracked repo-local path.
Repo-local option: spikes/<NNN-slug>/ with README.md and minimal code.
Prefer runnable CLI, tiny HTML, one endpoint, or focused test.
Avoid package sprawl, Docker, env files, app frameworks, and production cleanup.

Multi-spike ideas

Split into 2-5 independent questions.
Run the riskiest question first.
For A/B comparisons, keep inputs equal and measure the same dimensions.
Ask before building all variants if the work is more than a small prototype.

Verdict format

## Verdict: VALIDATED | PARTIAL | INVALIDATED

Question: ...
Evidence: exact command/output/measurement.
What worked: ...
What failed or surprised us: ...
Recommendation: ship / adjust / avoid, with the next production step.

Rules

An invalidated spike is useful when it rules out a path with evidence.
Do not merge spike code into production without rewriting it normally.
If external dependencies are evaluated, check health: recent release/commit, docs, license, install friction.