Spike first

Spike First（先打靶再造枪）

这个 skill 解决什么

抓取/集成类任务最大的浪费，是先把确定的那 80-95%（解析、存储、调度、测试）建得漂漂亮亮，最后才发现最不确定的那一环——"到底能不能稳定拿到数据 / 拿到访问权"——根本做不成，于是全部推翻重来。

绿灯越多，假信心越足：6 个单测全过、两轮代码审查通过，全都建立在"我能拿到数据"这个没验证过的假设上。

这个 skill 做一件事：把"会不会白干"的判断，从几小时后提前到开工前几分钟。

何时触发

任务里只要有一个"我控制不了的外部环节"，就触发：

• 抓取/爬取任何网站（尤其有反爬、登录态、JS 渲染的）
• 对接第三方 API / 服务 / webhook（尤其文档不全、需鉴权、有配额的）
• 自动化操作别人的系统（浏览器自动化、RPA、跨系统集成）
• 任何"这事到底做不做得成"还是开放问题的任务

如果任务全在你自己可控的代码内（纯本地逻辑、纯算法、纯重构），不触发——那是 TDD/brainstorming 的场景，不是这个。

强制流程（探针通过前，不准建任何生产代码）

第 1 步：点名最大未知点

点名之前先问一句：目标有没有官方通道（开放 API、导出功能、现成数据源）？有官方通道就优先走它——最大未知点会直接消失或换位（从"能不能抓到"变成"配额/权限够不够"）。别在有正门的时候研究爬窗户。

然后问自己：哪一个假设，如果是错的，整个方案就得推翻？

通常是"我能否从这个真实目标，稳定拿到要的东西"。把它一句话写出来，明确告诉用户。这一步逼你诚实面对风险，而不是回避它去做简单的部分。

第 2 步：对真实目标写一次性探针

写一个丢弃式脚本，对真实目标（真实 URL、真实 API、真实账号）验证第 1 步那个未知点。

禁止用编造的样本。 对自己捏造的 fixture 测出来的绿灯是假信心——真实页面/接口的结构、字段、反爬行为，你猜不准。先拿到一份真实数据/真实响应，再谈解析。

探针只为回答一个问题："这条路走得通吗？"——丑没关系、临时没关系，能扔。

探针工位纪律：

• 探针放在项目的 .tmp/spike/ 里（确认 .tmp/ 已进 .gitignore），或干脆放系统临时目录——绝不混进主项目树。
• 闸门过后，探针默认删除。唯一例外：探针拿回的真实样本可以留下当 parser 的测试 fixture——这是 fixture 唯一合法的来源。

第 3 步：外部依赖类——连跑 3-5 次测成功率

抓取、反爬、第三方接口这类，生产要的是稳定，不是"成功过一次"。

一次成功往往是运气。 必须连跑 3-5 次，看成功率和数据完整度。如果 5 次里只成 1 次，那就是"不稳定"，等于不通过——别自欺"它能成"。

第 4 步：闸门判定

• ✅ 通过 → 放行到 brainstorming / writing-plans / 建码，并说清你验证了什么（"3/3 都稳定拿到完整数据，可以建系统了"）。
• 🚪 不通过 → 当场喊停，把真正的风险摆给用户，给出选项（换方案 / 降级需求 / 上报阻塞）。绝不在探针没过时，往下建任何生产代码。

话术模板

对用户开口只说未知点和行动——"先打靶再造枪"、闸门规则这些是给你自己的纪律，不是说给用户听的台词，复述它们只会稀释信息。

触发时（开口第一句）：

最大未知点：[一句话写出那个"错了就推翻"的假设]。 我先写个一次性探针对真实目标验证[抓取类补一句：连跑 3 次看成功率]，通过了再设计建码，给我几分钟。

闸门通过：

探针结果：[N/N 次稳定拿到完整数据]。最大风险已排除，现在开始正经设计/建码。

闸门不通过：

🚪 闸门判定：不通过。[N 次里只成 M 次 / 数据拿不全 / 被拦]。 在建任何代码前先跟你对齐：这个任务的真正风险是 [X]，不解决它别的都白搭。 你看是 [换方案 A] / [降级到 B] / [我先排查 C]？

实际案例

❌ 没有 spike-first（真实踩过的坑）

用户：抓 Coupang 这链接的评价数量，每天写飞书。 助手：好，设计流程 →（写计划、建全套代码、6 个测试全过、两轮审查）→ 几小时后发现抓取根本不稳，推翻重来。 病根：先把确定的 95% 建完，把最大风险（能否稳定抓到）留到最后。

✅ 有 spike-first

用户：抓 Coupang 这链接的评价数量，每天写飞书。 助手：抓取任务，先打靶再造枪。最大未知点：能否从这真实页面稳定拿到 5 档评价数字？（Coupang 有 Akamai 反爬，这条不成立整个方案推翻）。我写探针抓 3 次看成功率，给我 5 分钟。 （跑探针） 结果：3 次里 0 次稳定——数据藏在点击浮层、Akamai 还拦。 🚪 不通过。真正的风险是"抓取本身"，建别的都白搭。你看是换抓取方案，还是降级到只抓总评数？ ——5 分钟暴露真问题，而不是几小时后。

反模式（这些念头一冒出来就是警报）

念头	真相
"先把代码框架搭起来"	框架建在没验证的假设上 = 可能全废。先验证。
"用个 fixture 把 parser 测通"	编造的 fixture 给假绿灯。先拿真实样本。
"刚才成功了一次，能用"	抓取看的是成功率，不是单次。连跑 3-5 次。
"这个简单，不用验证"	最容易藏雷的就是没人验证的"简单"假设。
"测试全过了"	要问测的是什么输入——绿灯建在假设上等于没测。
"先建起来，不行再说"	不行的时候已经几小时过去了。闸门就是为了提前。

和其它 skill 的关系

这是一道前置闸门，插在 brainstorming / writing-plans 之前：

需求 → 🚪spike-first(先打靶) → 过了才 → brainstorming/writing-plans → 建码
                  ↓ 不过
            当场喊停换方案

探针通过后，正常交给设计/计划/TDD 流程。它不替代那些，只是确保它们不建在流沙上。