# Prior Art

> 动手写代码前，查外面有没有现成的：是不是重复造轮子、有没有能直接抄的开源实现、license 允不允许抄。 触发词：有人做过吗、有现成的吗、是不是重复造轮子、有没有能抄的、有开源实现吗、 查查有没有库、prior-art、别自己写了先看看、这个轮子造过没。 只管代码复用，不做产品竞品分析（用户路径、需求动机、人群价值那些不归这里）。

- Skill: `timi-fish/prior-art` (Agent Skill)
- Install (CLI): `npx skillmds@latest add timi-fish/prior-art`
- Raw SKILL.md: https://api.skillmd.com/api/skills/timi-fish/prior-art/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Timi-Fish (https://skillmd.com/u/timi-fish)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/timi-fish/prior-art

---


# Prior Art

动手写代码前，先查生态里有没有现成的，给出唯一有价值的收敛结论：**你真正需要自己写的是哪部分。**

对 PM 还有一层用法：拿着"业界有开源实现、license 允许抄"的证据去和研发对 Effort——
「有现成的可抄」和「全部从零写」是两个量级的排期，这直接改变 requirement-eval 里 RICE 的 Effort 取值，
也是需求评审时最硬的说服材料之一。

## 边界（先读，不符合就一句话退出）

**管**：库、工具、开源实现、代码片段、算法参考。问题是「能不能不自己写」「能不能抄」。

**不管**：

- 产品竞品分析——成熟商业产品怎么做的、用户路径、他们为什么做这个功能、解决哪类人什么问题
- 当前产品的能力盘点与用户认知差
- 解法发散 → 推荐上游 [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills) 的 idea-refine
- 需求值不值得做 → [requirement-eval](../requirement-eval/SKILL.md)（本套件内，本 skill 的产出可作其 Effort 依据）

用户问的是"XX 产品这个功能怎么设计的"而不是"这段代码有没有现成的"时，说明走错了，直说并退出。

## 流程

### 1. 把要造的东西说成一句话

必须先明确，否则搜出来的全是噪音：

- 要解决的具体技术问题（不是产品目标）
- 语言 / 运行环境 / 目标平台
- 是要**直接依赖**，还是要**抄一段改**，还是只要**看别人怎么实现的**
- 分发方式：自己用 / 开源 / 商业闭源 —— 这一条直接决定 license 闸门松紧

缺第一条和最后一条就问，别猜。

### 2. 按阶梯从近到远查，找到就停

1. 当前项目里已经有了吗（`Grep` / `Glob`，先看本地）
2. 已装依赖能做吗（读 `package.json` / `pyproject.toml` / lockfile）
3. 标准库 / 平台原生 API 能做吗
4. 生态里的主流库
5. 开源实现（GitHub / 具体项目源码）

**在第 3 步就能解决的，不要往下报第 5 步的方案。** 这个顺序本身就是结论的一部分。

### 3. 每个发现必须三选一标类型

| 类型 | 含义 | 要不要查 license |
|---|---|---|
| 产品灵感 | 只是"哦原来可以这么做"，不碰它的代码 | 否 |
| 实现证据 | 证明这条技术路线可行/不可行，读但不抄 | 否 |
| 可复用资产 | 打算直接依赖或抄代码进来 | **是，且必须** |

不标类型的发现等于没发现——读的人分不清哪个能用。

### 4. license 闸门（只对「可复用资产」）

结合第 1 步的分发方式判断：

- MIT / BSD / ISC —— 随便用，保留版权声明
- Apache-2.0 —— 可用，保留 NOTICE，注意专利条款
- GPL / AGPL —— 传染。自己用没事；**要开源或分发就得同源**，AGPL 连 SaaS 部署都算分发
- CC BY-NC —— 非商业。个人项目可以，公司项目不行
- **没有 LICENSE 文件 = 默认保留所有权利，不能抄**。这条最容易漏

license 有疑问就标出来让用户判断，不要替他确认"应该没问题"。

### 5. 输出

证据表 + 一句话收敛。**不写调研过程，不列否掉的候选**（除非否掉的理由本身是结论，比如"看着像但其实不支持 X"）。

```markdown
## 结论

<一句话：用 X，或者 X + 自己写 Y，或者没有现成的、得自己写>

## 你真正需要自己写的

- <具体到模块/函数级，不是"剩下的部分">

## 发现

| 名称 | 类型 | 来源 | 版本/commit | License | 能解决哪部分 | 局限 |
|---|---|---|---|---|---|---|

## 需要你决定的

<只在真有分歧时才有这节>
- 为什么现在必须定：
- 选项 A / B：
- 推荐 + 依据：
- 影响（体积、维护、经常性成本、隐私、分发限制）：
```

## 决策边界

可以直接给推荐，但**不替用户拍板**：引入新的外部依赖、产生经常性成本、带来隐私暴露、
或 license 会限制未来分发方式的，都要摆出后果让用户选。

不要为了"显得调研充分"而推荐一个比自己写还麻烦的依赖——**"没有现成的，自己写 30 行"是完全合格的结论。**

## 反模式

- 列一堆 star 数高但跟问题不沾边的库
- 标了"可复用资产"却没查 license
- 明明标准库就能做，还推荐第三方包
- 只报名字不报"能解决哪部分"——读的人还得自己去试
- 把结论写成"以下几个方案各有优劣"，不给推荐
- 混进产品竞品分析