想做独立开发的人，通常不缺点子。
真正缺的是判断：这个问题有没有人反复遇到？他们现在怎么解决？现有方案到底损失了什么？我能不能在写代码之前，用七天证明它值得继续？
GitHub 上的 1c7/chinese-independent-developer 已经积累了大量中国独立开发者项目。它很适合发现“别人正在做什么”，但如果只是从头往下翻，很容易出现另一种收藏焦虑：
- 看见一个产品，觉得自己也能做；
- 看见一个功能，马上准备复刻；
- 收藏了几十个案例，仍然不知道先验证什么；
- 写完第一版，才发现没有明确用户。
所以我把它做成了一个新的入行365开源项目：
它不是把原始清单换个名字再发布，而是补上从“发现项目”到“验证机会”的中间层。
这次原创的，不是那份项目名单
先把归属说清楚。
原始项目名称、链接、开发者和状态来自 1c7 与社区贡献者维护的公开仓库。上游当前没有声明许可证，因此入行365没有复制它的整份 README，也没有把上游项目介绍纳入自己的 MIT License。
入行365原创并开源的是：
- 把公开事实转成 JSON 的同步与解析代码；
- 项目分类、能力标签和风险提示规则；
- 来源提交 SHA、行位置和指纹；
- 新增、移除和状态变化报告；
- 七天机会验证卡；
- 从三个候选到一个验证任务的工作流。
这不是文字游戏。它决定了这个项目能不能长期维护，也决定了使用者能否随时回到原始来源核对。
当前雷达里有什么
首个快照从上游主版、程序员版和游戏版解析出 2,124 个去重候选项目。
每条候选只保留事实和原创衍生字段：
{
"name": "项目名称",
"url": "真实产品链接",
"status": "live",
"developer_name": "开发者",
"source_file": "README.md",
"source_line": 42,
"source_sha": "上游提交 SHA",
"category": "productivity",
"risk_flags": [],
"review_status": "candidate"
}
candidate 只表示“被数据源发现”，不表示入行365推荐、质量认证，更不表示它一定适合你。
这也是机会雷达和推荐榜单最重要的区别：它帮你缩小搜索范围，但不替你做商业判断。
什么时候用它
最适合的节点不是“我已经准备开发”，而是更早一步：
我想做一个独立产品，但还没有确定值得验证的问题。
如果你已经有订单、真实用户或稳定交付，不需要回来翻两千个项目。继续服务当前用户更重要。
如果你只是想复制一个现成产品，也不适合用这套方法。因为它会不断追问用户问题、替代方案和证据，而不是直接给你功能清单。
30 分钟，先从 2,124 个缩到 3 个
打开结构化候选数据，不要从第一条读到最后一条。
先选一个你熟悉的分类，例如：
- AI 内容；
- 效率工具；
- 开发者工具；
- 创作者工具；
- 教育；
- 商业服务；
- 生活方式。
然后只保留满足下面三个条件的项目：
- 你能说出它服务的具体用户，而不是“所有人”。
- 你能在 48 小时内找到至少 5 位类似用户。
- 你对这个场景有经验、渠道或专业理解。
不满足其中任何一条，先放弃。
这一步的完成产物是一张三行对照表，不是“最值得做的项目排行榜”。
三个候选机会对照 Prompt
把三个项目的真实链接和你观察到的事实填进去，再复制这段 Prompt：
你是我的独立开发机会研究助手。
我会提供 3 个真实项目。你的任务不是推荐我抄哪一个，也不是根据功能多少打分，
而是帮我识别其中值得进一步验证的用户问题。
我的背景：
- 熟悉行业：
- 可接触用户：
- 可投入时间：
- 已有技能或渠道：
候选 A：
- 项目链接：
- 我观察到的事实：
候选 B：
- 项目链接：
- 我观察到的事实：
候选 C：
- 项目链接：
- 我观察到的事实：
请按表格输出：
1. 目标用户；
2. 问题发生的具体节点；
3. 当前替代方案；
4. 替代方案造成的具体损失；
5. 目前已有的证据；
6. 仍然缺少的证据；
7. 我在 48 小时内找到 5 位用户的可行性；
8. 需要额外核对的隐私、授权、平台或商业风险。
最后只给出“最值得先访谈的一个问题”，不要建议直接开发产品。
如果证据不足，请明确写证据不足，不要补造数据、用户反馈或收入。
AI 的作用是帮你组织问题，不是替你证明需求。
它输出之后，你还要打开产品、阅读公开说明、试用真实流程，并找到目标用户。
填写完成的示例：从 PDF 工具转成一个需求假设
假设你在雷达中看到一个“把 PDF 转成 Markdown”的工具。
错误动作是：
这个功能不难，我也做一个。
正确的验证卡应该更像这样：
- 目标用户：需要把大量报告交给 AI 分析的研究、咨询或内容从业者。
- 问题节点：拿到扫描版或复杂排版 PDF，普通复制会丢掉标题、表格和图片关系。
- 当前替代方案：在线转换、手工整理、让实习生重排。
- 待验证损失：上传敏感文件的风险、整理耗时、输出结构无法直接进入知识库。
- 关键假设：用户真正重视的可能不是“转换速度”，而是“离线处理 + 结构可用 + 可以直接交给 Agent”。
- 七天动作：找 5 位经常处理 PDF 的用户，请他们展示最近一次真实文件和现有流程。
- 停止条件：五次访谈都没有出现高频文件、明显耗时或隐私顾虑，就停止这个方向。
注意，这些仍然是假设，不是事实。
只有真实访谈和实际工作流，才能把它们变成证据。
为什么要看“变化”，不只看总榜单
总榜单会让人误以为项目越多，机会越多。
真正值得关注的是变化：
- 最近新增了哪些用户问题；
- 哪些品类连续出现；
- 哪些产品从开发中变成上线；
- 哪些项目关闭或长期没有维护；
- 同一类产品是否开始拥挤。
雷达每天记录上游提交 SHA，并生成最新变化报告。
但“新增多”也不等于市场大。它可能意味着需求旺盛，也可能意味着开发门槛降低、同质化严重。变化只负责提醒你去研究，不负责给出结论。
七天内，不写完整产品
选定一个问题后，复制七天机会验证卡。
前七天只完成四件事：
- 找到 5 位目标用户。
- 让他们讲最近一次真实发生，不问“你会不会用”。
- 记录当前替代方案和实际损失。
- 明确继续、调整或停止。
你可以做一张流程图、一份交互草图或一个可点击演示，但不要先写完整账户系统、支付、后台和十几个功能。
验证的目标不是证明自己对，而是尽快发现自己哪里错。
完成检查表
- [ ] 三个候选都已打开真实产品链接。
- [ ] 榜单状态已通过产品页面或仓库再次核对。
- [ ] 最终选择的是一个用户问题，不是一个功能。
- [ ] 已写清问题发生节点和当前替代方案。
- [ ] 至少完成 5 次真实访谈。
- [ ] 访谈记录包含最近一次真实经历和用户原话。
- [ ] 没有把 AI 推测写成用户事实。
- [ ] 已明确继续、调整或停止及其依据。
- [ ] 涉及密钥、金融、健康、成人内容或隐私时已额外复核风险。
做到这些，你得到的不是一个“看起来能做”的点子，而是一份可以继续决策的验证结果。
如何持续更新
这个开源项目有自己的同步测试和每日更新 Action。入行之路同时把它登记进统一的 External Source Sync：
- 开源仓库负责跟踪上游事实并生成结构化数据；
- 入行之路负责同步 README 中的可执行资产和更新入口；
- 文章和场景负责把数据转成用户可以完成的任务。
三层各自负责一件事，不会把“数据更新”误当成“文章观点自动正确”。
从独立开发机会筛选实战开始。今天不要选一个产品去做，先选一个问题去验证。
来源与授权
- 上游清单：1c7/chinese-independent-developer
- 入行365开源项目：ruhang365/ruhang365-indie-developer-radar
- 入行365原创代码、Schema、分类规则、报告结构和模板：MIT License
- 上游仓库当前未声明许可证，上游清单及第三方项目资料不包含在入行365 MIT 授权中