从想法到上线
一个人做产品，最难的不是写代码，是 没有同事帮你对齐、拆任务、记决策。
「一个人的产品工坊」是我给自己搭的工作台：把零散想法收成一条能走完的线——从「要不要做」到「怎么发布、怎么复盘」。
它不是卖给别人的 SaaS，也没有炫酷的控制台截图。更像一套固定动作 + 文档结构 + 工具习惯，让我少在「这事上次想过没有」上浪费时间。
一条想法通常怎么走
灵感 / 用户抱怨
↓
记一笔（值不值得继续想）
↓
写清问题（给谁、解决什么、不解决什么）
↓
拆版本（先能用的最小范围）
↓
任务列表（开发、文案、测试、上架）
↓
做出来 → 给人用 → 收反馈
↓
复盘（留下什么、丢掉什么）以前这些步骤散落在备忘录、Issue、聊天记录里。现在尽量让 同一个产品从始至终待在同一个「篮子」里，换项目时复制结构，而不是重新发明流程。
工坊里具体有什么
需求与判断
- 用户原话、自己的痛点、竞品扫一眼——先记下来，不急着做
- 简单清单：有没有更多人同样烦？我愿不愿意维护半年？
- 明确 不做清单，避免功能越长越大
PRD 与范围
- 用自己能看懂的篇幅写清：场景、边界、成功标准
- 第一版只保留「没有它就谈不上能用」的部分
- 和设计稿、接口草稿放在同一处，减少来回找
任务拆解
- 按「能独立验收」的小块拆，适合一个人晚间或周末推进
- 区分：必须人做的判断 vs 可以脚本化的重复步骤（交给自动化后台）
开发与自测
- 分支、构建、关键路径手测——一个人也要留检查清单
- 错误日志、配置说明写给自己三个月后的版本
发布与对外说明
- 更新日志、截图、订阅/联系入口是否一致
- 网站、文档、通知渠道对齐，避免用户看到两套说法
反馈与复盘
- 用户邮件、评论、使用中的卡顿——统一归档，定期看趋势
- 每次发布后记：猜对了什么、错了什么、下次默认规则改不改
为什么值得单独整理
做过几个 side project 之后会发现：代码可以复用，流程和教训往往复用不了，因为没写下来。
整理工坊的目的：
- 少从零开始——新项目套用同一套文件夹和模板
- 决策可追溯——三个月后还记得为什么砍掉某个功能
- 和自动化分工——固定格式的文档、changelog、任务拆分尽量交给脚本
适合谁参考
- 独立开发者、一人公司、副业做产品的人
- 小团队里兼产品兼开发、没有专职 PM 的角色
- 不需要大而全的「敏捷框架」，只需要 能持续交付 的简单纪律
如果你在大团队里已有完整研发流程，这套东西可能太轻；如果你经常卡在「想法很多、上线很少」，也许能借走一两个习惯。
和其他项目的关系
| 方向 | 关系 |
|---|---|
| FinderBoost | 工坊里正在推进的前台产品之一 |
| 一人公司手册 | 工坊里沉淀下来的判断与经验，偏「为什么」 |
| 自动化后台 | 工坊里重复环节的执行层，偏「怎么省时间」 |
工坊是 过程；手册是 记忆；自动化是 杠杆；FinderBoost 是 结果里看得见的那一个。