Timi-Fish Prior Art
动手写代码前，先查生态里有没有现成的，给出唯一有价值的收敛结论：你真正需要自己写的是哪部分。
对 PM 还有一层用法：拿着"业界有开源实现、license 允许抄"的证据去和研发对 Effort—— 「有现成的可抄」和「全部从零写」是两个量级的排期，这直接改变 requirement-eval 里 RICE 的 Effort 取值， 也是需求评审时最硬的说服材料之一。
边界（先读，不符合就一句话退出）
管：库、工具、开源实现、代码片段、算法参考。问题是「能不能不自己写」「能不能抄」。
不管：
- 产品竞品分析——成熟商业产品怎么做的、用户路径、他们为什么做这个功能、解决哪类人什么问题
- 当前产品的能力盘点与用户认知差
- 解法发散 → 推荐上游 addyosmani/agent-skills 的 idea-refine
- 需求值不值得做 → requirement-eval（本套件内，本 skill 的产出可作其 Effort 依据）
用户问的是"XX 产品这个功能怎么设计的"而不是"这段代码有没有现成的"时，说明走错了，直说并退出。
流程
1. 把要造的东西说成一句话
必须先明确，否则搜出来的全是噪音：
- 要解决的具体技术问题（不是产品目标）
- 语言 / 运行环境 / 目标平台
- 是要直接依赖，还是要抄一段改，还是只要看别人怎么实现的
- 分发方式：自己用 / 开源 / 商业闭源 —— 这一条直接决定 license 闸门松紧
缺第一条和最后一条就问，别猜。
2. 按阶梯从近到远查，找到就停
- 当前项目里已经有了吗（
Grep/Glob，先看本地） - 已装依赖能做吗（读
package.json/pyproject.toml/ lockfile） - 标准库 / 平台原生 API 能做吗
- 生态里的主流库
- 开源实现（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"）。
## 结论
<一句话：用 X，或者 X + 自己写 Y，或者没有现成的、得自己写>
## 你真正需要自己写的
- <具体到模块/函数级，不是"剩下的部分">
## 发现
| 名称 | 类型 | 来源 | 版本/commit | License | 能解决哪部分 | 局限 |
|---|---|---|---|---|---|---|
## 需要你决定的
<只在真有分歧时才有这节>
- 为什么现在必须定：
- 选项 A / B：
- 推荐 + 依据：
- 影响（体积、维护、经常性成本、隐私、分发限制）：
决策边界
可以直接给推荐，但不替用户拍板：引入新的外部依赖、产生经常性成本、带来隐私暴露、 或 license 会限制未来分发方式的，都要摆出后果让用户选。
不要为了"显得调研充分"而推荐一个比自己写还麻烦的依赖——"没有现成的，自己写 30 行"是完全合格的结论。
反模式
- 列一堆 star 数高但跟问题不沾边的库
- 标了"可复用资产"却没查 license
- 明明标准库就能做，还推荐第三方包
- 只报名字不报"能解决哪部分"——读的人还得自己去试
- 把结论写成"以下几个方案各有优劣"，不给推荐
- 混进产品竞品分析