写代码前先做 GitHub 调研
这条工作流的目标很简单：在真正开始写代码之前，先回答“有没有成熟轮子”“哪些项目值得参考”“我应该 fork、借鉴，还是从零实现”。很多独立开发项目最后不是败在执行力，而是起点判断偏了。
把 GitHub 调研做成固定前置动作，可以让后续编码、产品决策和工具选择更稳。DevDetective 的价值也在这里，它不是代替你做最后判断，而是让调研和筛选过程更快、更有结构。
更新时间：2026-06-18适用阶段：立项前 / 编码前
完整正文
1. 先把需求写成可搜索的问题
调研失败最常见的原因不是没搜到，而是一开始的描述太模糊。更有效的做法是先写出目标用户、核心功能、数据来源、技术边界和不需要的能力。
2. 同时准备中文和英文关键词
很多项目在 GitHub 上不会用中文表达，所以只搜中文容易漏掉高质量候选。建议至少准备功能词、用户场景词和技术栈词三组关键词。
3. 把候选项目分成三类
一类是可以直接借鉴的成熟项目，一类是方向相关但实现不同的参考项目，一类是流量高但并不适合当前需求的项目。分开之后，判断会清楚很多。
4. 不要只看 star
更值得看的维度包括：最近是否还在维护、issue 是否有人回应、文档是否完整、许可证是否可用、部署复杂度是否可接受。
5. 调研必须输出可执行结论
调研的终点不是收集几十个仓库，而是产出结论：适合 fork、适合借鉴部分模块，还是更值得从零开发。只有结论清楚，后续编码才会真正受益。
6. 把结论回接到 Prompt 和开发任务
调研结果最好直接进入下一轮 Prompt、教程或工程说明书里，让 GitHub 调研不再是孤立动作，而是编码前的标准步骤。
FAQ
- Q：这条流程只适合开源项目吗？
A：不只适合开源项目。即便最后做闭源产品，前置调研也能减少重复造轮子。 - Q：如果找不到很像的项目怎么办？
A：那也是有价值的结论，说明你要么在做更细分的需求，要么需要从相邻方向拼出自己的方案。 - Q：什么时候可以缩短调研步骤？
A：只有在需求已被反复验证、实现路径也足够熟悉时，才适合减少调研时间。