教程 · AI 工具
GitHub 仓库尽调：从 star 到许可证/维护/退出成本
用 30 分钟评估一个 GitHub 仓库能否接进项目：许可证、维护、依赖、最小 demo、替代方案。
前置：有一个候选仓库和明确用途；能在本地/测试环境跑 demo。
材料：候选仓库链接、需求/运行环境说明、GitHub 仓库索引、本地测试环境
材料：候选仓库链接、需求/运行环境说明、GitHub 仓库索引、本地测试环境
步骤
1. 先写用途和边界
用一句话写清要解决什么问题、运行在浏览器/服务端/CLI、是否商用/闭源分发；边界不清就先别装，避免“看着不错”接进主线。
2. 读 LICENSE 和 README
在仓库根目录找 LICENSE；MIT/Apache-2.0 与 GPL/AGPL 义务不同。README 只看安装/限制/已知问题，不把宣传语当证据。
3. 看维护信号
看最近 6 个月提交、release、issue/PR 响应和关闭率；长期不更新不等于不能用，但要有 fork/替代方案和版本锁定策略。
4. 跑最小 demo
只装最小依赖，记录体积、启动时间、与现有版本冲突；不要直接改主线，先在独立分支/临时目录验证。
5. 写退出成本
至少留 1 个替代库或自写最小实现；写清替换要改哪些接口、数据/配置能否迁移，避免被单一仓库锁死。
做完检查
- LICENSE 已读，商用/分发义务写进选型记录。
- 最近维护有提交/release/issue 证据，不只看 star。
- 最小 demo 跑通，版本/体积/启动成本有记录。
- 至少有 1 个替代方案或退出路径。
常见错误
- 把 star 数当维护质量。
- 忽略 AGPL/GPL 的分发义务。
- 直接在主线上装，版本冲突后难回退。
相关工具
配套模板
同类教程
提示词写了五百字还是答偏：先给角色、读者和禁区
用角色、读者、任务、结构和禁区五个槽位重写提示词，让输出稳定落在预期范围内。
查看 →AI 说得头头是道却找不到原文：要求带位置引用再回查
让模型在回答里标出原文位置和不确定项，再逐条回查，避免把模型复述当成原文依据。
查看 →长文档塞不进上下文：先分段摘要再汇总，别硬塞
把超长文档按章节拆开分段摘要，再用统一模板汇总，保证关键信息不丢且可回溯。
查看 →更新时间：2026-10-29 · 平台规则/软件版本会变；操作前保留原件，以实际页面为准。
跨库学习路径
按共同关键词匹配，不是随机推荐；从任务到提示词/教程/项目继续走。