先调研再编码：让 AI 研究开源项目的提示词

背景

常见的 Vibe Coding 请求是“帮我写一个 App”，AI 很容易立即生成代码，却没有先验证需求、技术选型和已有实现。对于陌生或中大型项目，可以要求 AI 先研究 GitHub 上的类似开源项目，再比较方案并等待确认。

原始思路：

我想做一个 XXX 项目。先别急着写代码，去 GitHub 找几个类似的开源项目，比较它们的功能、架构、技术栈和优缺点，再给我一份实现方案。等我确认后再动手。

结论

这个提示词有用，但真正有价值的是它规定了“先调研、再比较、再定方案、最后开发”的流程，而不是某一句固定表达。它可以降低盲目选型、重复造轮子和遗漏常见风险的概率，但不能自动保证方案正确。

适合使用：

• 开发陌生领域的中大型功能。
• 市面上已经存在相似产品或开源实现。
• 架构、数据结构或技术选型确定后，修改成本较高。
• 希望了解已有方案的优缺点和踩坑经验。

不必使用：

• 添加按钮、调整样式等简单改动。
• 已经有明确实现方案的常规需求。
• 调研成本明显高于开发成本的小型功能。

原提示词的局限

1. 项目范围不明确：缺少目标用户、核心功能、平台和技术约束，找到的项目可能表面相似但场景不同。
2. 没有筛选标准：Star 数量不能代表代码质量，很多高 Star 项目可能已经停止维护。
3. 可能出现伪调研：AI 没有网络或 GitHub 访问能力时，可能根据记忆生成不准确的信息。
4. 忽略许可证和维护状态：找到代码不代表可以直接使用，需要检查 License、最近更新时间、Issue 和依赖版本。
5. 方案容易空泛：只要求“实现方案”，可能得不到模块划分、数据流、测试策略和实施顺序。

改进原则

• 先说明目标、用户、核心功能和技术约束。
• 限定调研数量，例如 3～5 个真正相关的项目。
• 要求提供仓库链接、许可证和最近更新时间。
• 明确区分仓库中的事实和 AI 的推测。
• 比较可以借鉴与不应该照搬的内容。
• 要求输出 MVP、模块划分、实施步骤、测试和风险。
• 调研阶段禁止修改文件、安装依赖和编写业务代码。
• 方案确认后再进入实现阶段。

Android 项目提示词模板

我想开发一个 Android 项目：

目标：
[解决什么问题]

目标用户：
[谁会使用、在什么场景使用]

核心功能：
1. [...]
2. [...]
3. [...]

技术约束：
- Kotlin
- Jetpack Compose + Material 3
- minSdk [...]
- 架构倾向：[没有要求 / MVVM / MVI]
- 数据存储：[本地 / 云端 / 暂未确定]
- 其他限制：[...]

当前阶段只做调研和方案设计，不修改项目文件、不安装依赖、不写业务代码。

请在 GitHub 查找 3～5 个真正相关的开源项目，并提供每个项目的链接。优先选择：
- 最近 12～18 个月仍有维护
- 有明确开源许可证
- 使用较新的 Kotlin、Compose 和 Android 架构
- 核心功能与我的需求接近
- 有一定测试或文档

请比较：
1. 核心功能和目标用户
2. 技术栈及主要依赖
3. 模块划分和架构
4. 状态管理和数据流
5. 数据存储及网络方案
6. 测试情况
7. 最近更新时间和许可证
8. 可以借鉴的部分
9. 不应该照搬的部分
10. 主要优缺点

所有事实都要附仓库来源；不能确认的内容标记为“推测”，不要编造。

调研完成后，请回答：
- 应该从零开发、参考实现，还是基于某个项目二次开发
- 推荐的技术方案及理由
- MVP 功能边界
- 模块和目录结构
- 分阶段实施计划
- 主要技术风险与验证方式
- 哪些决策需要我确认

等我确认方案后，再开始修改代码。

使用注意

• 确认 AI 当前确实具有网络或 GitHub 访问能力。
• 对关键结论打开原仓库复核，不只阅读 AI 摘要。
• Android 项目重点检查 Kotlin、AGP、Compose、依赖版本和目标 SDK 是否过时。
• 参考架构和思路时也要遵守开源许可证，不应直接复制来源不明的代码。
• “等待确认”适合高影响决策；如果目标已经明确，可以让 AI 直接调研并实施，减少不必要的停顿。