引言：选题不是灵感，而是一种工程能力
绝大多数独立开发项目失败，并不是因为“做得不够好”，而是因为 一开始就不该被做出来。
在社区中，你会经常看到这样的描述：
- “我有一个想法”
- “这个点子挺酷的”
- “如果做出来应该会有人用”
这些表述的共同特征是：
它们都没有经过现实世界的验证。
本篇文章试图建立一套可复用、可执行、可止损的选题池与验证方法，
让“是否值得做”这个问题，从感性判断变成理性决策。
第一部分：个人工具 / SaaS 的真实选题来源
一、选题的第一原则：问题必须真实存在
独立开发者最危险的选题来源只有一个：
“我觉得别人可能会需要。”
所有可持续的工具或 SaaS，选题几乎都来自以下四类真实来源。
二、选题来源一：你自己正在忍受的问题（最高优先级）
1. 判断标准
一个问题，只有在满足以下条件时，才值得进入选题池：
- 你正在被它困扰（不是曾经）
- 你已经尝试过解决
- 现有方案让你不满意
- 你愿意为更好的方案付费
2. 典型特征
- 高频（每天 / 每周）
- 与工作流强绑定
- 不解决会持续消耗精力
3. 为什么这是成功率最高的来源
- 你不需要市场调研
- 你天然理解使用场景
- 你能持续验证和优化
大量成功的开发者工具，本质上都是“作者给自己用的工具”。
三、选题来源二：你正在提供的服务（被低估的金矿）
1. 服务即信号
如果你正在做以下事情：
- 外包
- 咨询
- 技术支持
- 私有化部署
那么你每天都在接触真实付费问题。
2. 可提炼的选题形态
- 重复出现的需求
- 每个客户都要解释的点
- 手工步骤多、容易出错的流程
- 客户愿意为“省事”额外付钱的环节
3. 经典路径
服务 → 内部工具 → 通用工具 → 产品化
这是现实世界中风险最低的产品起源路径之一。
四、选题来源三：成熟产品的“负空间”
1. 什么是负空间
负空间指的是：
- 主流产品不愿意做
- 或者做得很糟
- 但用户又不得不用的部分
2. 常见负空间类型
- 复杂产品的“简化版”
- 企业级产品的“个人版”
- 国际产品的“本地化版”
- 通用产品的“垂直版”
3. 关键判断
如果一个需求被长期吐槽，却始终存在，
说明它不是“无需求”，而是未被好好服务。
五、选题来源四：新技术 + 老问题（谨慎使用）
1. 风险提示
“新技术 + 新需求”是独立开发者的死亡组合。
但：
“新技术 + 老问题”
有时能带来成本或体验上的质变。
2. 可行前提
- 老问题本身已被验证
- 你清楚新技术带来的实际改进
- 不依赖用户学习新概念
第二部分：个人工具 / SaaS 选题池构建方法
六、建立你的“长期选题池”
1. 选题池不是一次性的
选题池应当是一个持续维护的资产。
建议形式：
- 一个文档
- 或一个 Notion / Markdown 文件
- 持续记录、更新、淘汰
七、选题池的基础结构模板
每一个选题，至少包含以下字段：
* 问题描述
* 目标用户
* 发生场景
* 当前解决方案
* 不满点
* 付费可能性（主观）
* 验证状态
未填写完整的选题，不允许进入下一阶段。
八、选题的第一轮筛选（快速淘汰）
对选题池中的每一个想法，问自己四个问题：
- 我是否真的理解这个问题？
- 是否已有用户为类似方案付费？
- 我能否在 2–4 周内做出 MVP？
- 失败的时间成本是否可控？
任意一项为否，直接淘汰。
九、选题优先级排序模型（独立开发者适用）
推荐一个简单但有效的排序维度：
| 维度 | 权重 |
|---|---|
| 问题真实度 | 高 |
| 你对问题的理解深度 | 高 |
| 实现复杂度 | 中 |
| 潜在付费能力 | 中 |
| 长期维护意愿 | 高 |
永远优先选择“你愿意维护三年的项目”。
第三部分：低成本验证方法（核心）
十、验证的本质：不是证明你对，而是尽快发现你错了
独立开发者最危险的心理是：
“我已经投入这么多了，不能放弃。”
验证存在的唯一意义是：
在投入太多之前，尽早止损。
十一、验证阶段划分（由轻到重）
- 文字验证
- 人工验证
- 原型验证
- MVP 验证
- 收费验证
不要跳级。
十二、文字级验证（最低成本）
1. 验证方式
- 写一段问题描述
- 写一个假想解决方案
- 发给目标用户
2. 判断信号
- 对方是否立即理解？
- 是否主动补充痛点？
- 是否询问“什么时候能用”？
冷漠 ≈ 无需求。
十三、人工验证（最容易被忽视）
1. 什么是人工验证
不用写代码，
用人工方式“假装产品已经存在”。
例如：
- 手工生成结果
- 人工对接流程
- 半自动脚本
2. 判断标准
如果用户愿意忍受低效的人工流程，
说明问题本身足够重要。
十四、原型验证（只验证理解）
1. 原型的目标
- 不是测试技术
- 而是测试认知是否一致
2. 可接受形态
- 低保真原型
- CLI 示例
- API 文档草稿
- 伪代码流程图
十五、MVP 验证（第一道生死线）
1. MVP 必须验证什么
- 是否有人持续使用
- 是否融入工作流
- 是否产生依赖
2. 不验证什么
- 增长速度
- 完整体验
- 边缘功能
十六、收费验证（最真实的信号）
1. 为什么必须尽早收费
- 付费是最高强度反馈
- 可以过滤“口头支持者”
- 能校准产品价值
2. 常见低风险方式
- 预售
- 内测付费
- 一次性买断
- 高价、少用户
第四部分：失败止损与方向调整机制
十七、什么是“健康的失败”
- 快
- 可复盘
- 不伤根本
失败不是问题，
拖延失败才是。
十八、必须设定的止损条件
在项目开始前，就写下：
- 使用人数低于多少放弃
- 多久未出现积极信号放弃
- 无付费意愿多久放弃
不要在情绪高峰期做决定。
十九、转向（Pivot）的正确方式
转向不是：
- 换个名字
- 改个 UI
而是：
- 更换目标用户
- 更换使用场景
- 或更换交付形式
第五部分：长期选题能力的养成
二十、把“选题”当成一种长期训练
优秀的独立开发者，
不是更会写代码，而是：
更会判断什么不值得写。
二十一、持续优化选题池的实践建议
- 每月淘汰一批想法
- 每季度复盘失败选题
- 记录错误判断原因
- 不断修正自己的“直觉模型”
结语：选题不是起点，而是护城河
代码可以重写，
产品可以重构，
商业模式可以调整。
但：一个清醒、理性的选题能力，会在每一个项目中持续复利。
如果你已经开始系统性地：
- 记录想法
- 验证假设
- 快速止损
那么你已经走在一条极少数独立开发者才能走通的路上。
建议将本文与《独立项目模板》《12 个月生存路线图》一同使用。
选题，是所有独立项目中最值得投入时间的“第一工程”。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。