Prior Art

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

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

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

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

不管：

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

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

流程

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 输出

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

## 结论

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

## 你真正需要自己写的

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

## 发现

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

## 需要你决定的

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

决策边界

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

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

反模式

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