提示词 · 编程
GitHub 选型尽调：许可证/维护/替代方案
把候选 GitHub 仓库做成一张可评审的尽调表，而不是只报 star 数。
完整提示词
你是技术选型评审。输入：【需求】=____；【候选仓库列表】=____；【运行环境】=____；【合规/商用要求】=____。请为每个仓库输出：1.用途匹配度；2.LICENSE 与商用/分发义务；3.最近维护证据（提交/release/issue 响应）；4.依赖/体积/版本冲突风险；5.替代方案；6.结论（推荐/观察/否决）。每项必须写证据，无法核实的写“待确认”。最后给一个最小验证 demo 的步骤，不要用 star 数代替维护判断，不承诺安全合规。
先把变量换掉
[需求][候选仓库列表][运行环境][合规/商用要求]输入示例
需求：浏览器内 PDF 拆分；候选：pdf-lib、pdf.js、Stirling-PDF；环境：纯前端；合规：MIT/Apache 可用，AGPL 需确认。
输出应该长什么样
候选对比表（6 列）+ 推荐结论 + 最小验证 demo + 待确认清单。
常见误用
- 只列 star 数，不看许可证。
- 把“能跑 demo”当“可上生产”。
- 忽略 AGPL/GPL 的分发义务。
交付前检查
- 输出包含：候选对比表（6 列）+ 推荐结论 + 最小验证 demo + 待确认清单。
- 没有出现：只列 star 数，不看许可证。
- 没有出现：把“能跑 demo”当“可上生产”。
- 所有 [变量] 已替换成真实信息；不确定的写“待确认”。
相关工具
配套模板
同类提示词
代码审查：按风险优先级列问题与补丁
按正确性、安全、性能和维护性排序代码问题，并给出可验证的修改补丁
查看 →报错排查：从日志复现到最小修复
从日志与复现步骤定位最可能根因，给出可回滚的最小修复与验证方案
查看 →接口设计：把业务需求落成REST契约
把业务需求落成含资源、错误码、幂等与权限的REST接口契约，方便前后端评审
查看 →把 [变量] 替换成你的真实信息；不确定的内容标“待确认”，不要让 AI 编造数据、评价或资质。
跨库学习路径
按共同关键词匹配，不是随机推荐；从任务到提示词/教程/项目继续走。