spike-firstlisted

# 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 都稳定拿到完整数据，可以建系统了"）。 - **🚪 不通过** → **当场喊停**，把真正的风险摆给用户，给出选项（换方案 / 降级需求 / 上报阻塞）。**绝不在探针没过时，往下建任何生产代码。** ## 话术模板 对用户开口只说**未知点和行动**——"