prior-artlisted

# 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. 输出