AllenShi100 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 流程。它不替代那些，只是确保它们不建在流沙上。