写代码前先做 GitHub 调研
这条工作流的目标很简单：在真正开始写代码之前，先回答“有没有成熟轮子”“哪些项目值得参考”“我应该 fork、借鉴，还是从零实现”。很多独立开发项目最后不是败在执行力，而是起点判断偏了。
把 GitHub 调研做成固定前置动作，可以让后续编码、产品决策和工具选择更稳。DevDetective 的价值也在这里，它不是代替你做最后判断，而是让调研和筛选过程更快、更有结构。
更新时间：2026-06-18适用阶段：立项前 / 编码前
完整正文
一句话结论
不要从"我要开发什么"直接跳到写代码。先把需求拆成能力模块，分别搜索可复用的开源项目，再从维护状态、许可证、技术适配、代码质量和二次开发成本进行评估。Star 只能代表关注度，不能单独证明项目适合二次开发。
第一步：把产品需求拆成能力
示例：目标为"开发本地文章转播客工具"
能力拆解：文章导入 → 文本清洗 → 内容改写 → TTS → 自定义音色 → 音频合成 → 本地归档 → GUI
不要只搜索完整产品名称，应分别搜索：
- article to podcast
- local TTS
- voice cloning
- text normalization
- audio pipeline
- desktop podcast generator
第二步：建立搜索词矩阵
| 类型 | 示例 |
|---|---|
| 产品词 | article to podcast |
| 功能词 | text to speech pipeline |
| 技术词 | whisper TTS electron |
| 替代词 | audio narration generator |
| 框架词 | Next.js TTS app |
| Topics | text-to-speech, podcast, voice-cloning |
第三步：初步筛选
先记录每个候选项目的以下信息：
- 最近提交时间
- 最近 Release 时间
- Star / Fork 数量
- Issue 数量和活跃度
- PR 活跃度
- 许可证类型
- 技术栈
- 文档质量
- 是否有 Demo
- 是否仍在维护
Star 只能代表关注度，不能单独证明项目适合二次开发。
第四步：维护状态判断
重点看：
- 最近 90 天是否有提交
- 最近一年是否有 Release
- 重要 Issue 是否有人回应
- PR 是否长期无人处理
- 核心维护者是否仍活跃
- 依赖是否明显过时
第五步：许可证判断
重点区分：MIT / Apache-2.0 / BSD / GPL / AGPL / 自定义许可证 / 无许可证
无许可证不代表可以自由使用。涉及商用或分发时，应阅读完整许可证，必要时寻求专业法律意见。
第六步：技术适配
评估：
- 是否匹配现有语言和框架
- 是否必须部署复杂基础设施
- 是否依赖昂贵 API
- 是否支持目标操作系统
- 是否容易拆出单个模块
- 是否有测试
- 是否有 Docker
- 是否有清晰的配置示例
第七步：计算二次开发成本
| 维度 | 权重 |
|---|---|
| 需求匹配 | 25 |
| 维护状态 | 15 |
| 技术适配 | 15 |
| 代码质量 | 10 |
| 文档质量 | 10 |
| 许可证 | 10 |
| 部署成本 | 10 |
| 社区与风险 | 5 |
第八步：输出给 Codex
调研结果应包含：目标需求、候选项目、推荐基座、可直接复用模块、需要重写模块、许可证风险、部署成本和 P0 实施建议。
最终决策
根据调研结果选择以下路径之一：
- 直接复用
- Fork 后修改
- 只借鉴架构
- 提取单个模块
- 放弃并从零开发
不要因为某个项目 Star 高，就直接把它作为开发基座。
FAQ
- Q：这条流程只适合开源项目吗？
A：不只适合开源项目。即便最后做闭源产品，前置调研也能减少重复造轮子。 - Q：如果找不到很像的项目怎么办？
A：那也是有价值的结论，说明你要么在做更细分的需求，要么需要从相邻方向拼出自己的方案。 - Q：什么时候可以缩短调研步骤？
A：只有在需求已被反复验证、实现路径也足够熟悉时，才适合减少调研时间。