很多人第一次做产品，都会不自觉把项目做大。原本只是想解决一个小问题，写着写着就想加登录、会员、后台、团队协作、模板市场、数据分析、邀请返佣、AI 助手、自动化工作流。每个功能看起来都有道理，但放在一起，项目就从一个能验证的小工具，变成了一个很难完成的平台。
第一个项目做太大，通常不是因为野心太大，而是因为不安全感太强。你会担心功能少了用户不买账，页面简单了不像产品，范围小了市场不够大。于是不断加功能，试图用"完整"来换安全感。可早期产品真正需要的不是完整，而是闭环。
所谓闭环，就是用户能在一个具体场景里，用你的产品完成一个明确结果，并愿意再次使用或进一步付费。第一个项目应该多大？答案不是越小越好，也不是越完整越好，而是刚好大到能完成一个付费或留存闭环，小到你能在短时间内做出来、推给用户、收反馈、继续迭代。
小项目不是小功能，而是小闭环
很多人误解了 MVP，以为小项目就是少做几个功能、页面粗糙一点、能点就行。结果做出来的东西虽然小，但没有价值。用户打开以后，不知道能完成什么，也没有理由回来。这样的"小"，只是半成品，不是 MVP。
真正的小项目，应该围绕一个完整任务。比如"批量生成 App Store 截图尺寸"就是一个小闭环：用户上传截图，选择设备尺寸，导出可用图片。它不需要设计平台、团队协作、素材库，但它完成了一个明确结果。
再比如"每周给小站长发 SEO 页面异常提醒"也是小闭环：连接站点或提交链接，系统检查标题、收录、流量变化，发出提醒和建议。它不需要做完整 Ahrefs，但用户每周能得到一个有价值的结果。
所以，不要问"我能少做哪些功能"，要问"用户完成这个任务最少需要哪些步骤"。只要这些步骤能让用户从问题走到结果，项目就可以很小；如果缺了关键步骤，哪怕功能很多，也不是闭环。
用一句话限制项目边界
第一个项目最需要边界。没有边界，任何功能都能被说成"以后有用"。你要先写一句边界句：
css
这个项目只帮助 [目标用户] 在 [具体场景] 完成 [一个结果]。比如："这个项目只帮助独立开发者在上架 App 前批量生成商店截图尺寸。"这句话一写出来，你就知道很多功能暂时不该做：不做社交发布，不做设计社区，不做素材交易，不做团队权限。它们也许以后有用，但不属于第一个闭环。
再比如："这个项目只帮助 Shopify 卖家发现商品描述里的低转化问题。"那你就不需要一开始做完整店铺运营平台，不需要做库存管理，也不需要做广告投放。你先把"发现并改进描述"这个结果做扎实。
边界句不是限制想象力，而是保护执行力。一个人做项目，最怕边界不断扩张。每多一个功能，不只是多写几行代码，还多了设计、测试、文案、客服、异常处理和维护成本。第一个项目应该先赢一场小仗。
判断范围的四个问题
第一个问题：用户能不能在 5 分钟内理解它？如果你需要解释半小时，说明项目可能太大或定位太模糊。早期产品最好一眼能看懂：输入什么、得到什么、为什么有用。
第二个问题：用户能不能在第一次使用中得到结果？如果用户要先配置很多东西、导入大量数据、学习复杂流程，早期转化会很难。第一个项目最好让用户尽快看到一次结果，哪怕这个结果还不完美。
第三个问题：你能不能在 2 到 4 周内做出可用版本？不是做出完美版本，而是做出能给真实用户试用的版本。如果一个项目第一版就要做三个月，很容易在没有反馈的情况下跑偏。
第四个问题：结果能不能带来下一次使用或付费理由？一次性小工具可以做，但如果你想做长期产品，就要看它是否有复用场景。比如每周提醒、每次发布、每次上架、每次写内容、每次获客，这些重复场景更容易形成产品价值。
如果一个项目同时满足"看得懂、用得上、做得出、能复用"，它就适合作为第一个项目。如果其中两项都不满足，就应该继续缩小范围。
不要一开始做平台
第一次做产品，最危险的词之一是"平台"。平台意味着多角色、多流程、多模块、多规则、多网络效应。你以为平台更有想象空间，但平台最难冷启动。没有供给，需求方不来；没有需求，供给方不留；没有规模，每个模块都显得空。
很多平台型想法都可以先切成工具。不要一开始做"AI 工具交易平台"，先做"帮电商卖家筛选可用 AI 图片工具的目录和教程"。不要一开始做"自由职业者撮合平台"，先做"帮设计师生成报价单和项目范围模板"。不要一开始做"创业资源社区"，先做"独立开发者产品发布清单工具"。
工具比平台更适合第一步，因为工具不需要双方同时存在。一个用户来了，只要能完成自己的任务，就能获得价值。平台必须有生态，工具只需要一个任务闭环。等工具有用户、有数据、有高频场景，再考虑是否扩展成平台。
第一个项目要避免"未来很大，现在很空"。你需要的是现在就能让一个用户得到结果，而不是画一个未来生态蓝图。
先做服务，再做系统
如果你不确定第一个版本该做多大，可以先用服务方式跑一遍。用户提交资料，你手工处理；用户填写需求，你人工生成结果；用户想要报告，你先每周手动发。服务能跑通的流程，再考虑系统化。
服务方式有两个好处。第一，它迫使你面对真实需求。用户会告诉你哪里不清楚、哪里最在意、哪里愿意付费。第二，它帮你发现哪些环节值得自动化。你以为最重要的是生成，可能实际最耗时的是数据清洗；你以为用户要完整报告，可能他只要三条建议。
很多人一开始就做系统，是因为觉得服务不够酷。但早期最重要的不是酷，而是学得快。一个手工交付的结果，只要用户愿意要，就比一个没人用的系统更有价值。
等你手工交付 5 到 10 次，流程开始重复，用户问题开始相似，你就知道第一版产品应该包含哪些步骤。那时写代码，范围会自然变小，也更接近真实需求。
第一版应该砍掉什么
第一版通常可以砍掉账户体系，除非用户需要保存历史记录或付费权限。可以先用邮箱、一次性链接、表单或人工发放结果来替代。登录不是产品价值，它只是管理价值的方式。
第一版通常可以砍掉复杂后台。你可以先用 Airtable、Notion、Google Sheets、数据库管理界面甚至手工脚本处理运营。后台是给你用的，不是给用户买单的。用户不在乎你后台优不优雅，只在乎结果是否有用。
第一版通常可以砍掉团队协作、权限系统、邀请体系、复杂设置、多语言、多主题、积分等级、完整数据看板。它们不是永远不做，而是等核心任务被验证后再做。早期每加一个"看起来以后会需要"的功能，都会拖慢你验证需求的速度。
你要保留的是核心路径：用户进入、提交输入、得到结果、知道下一步。只要这条路径成立，第一版就有价值。其他功能都应该为这条路径服务，不能抢它的注意力。
总结
第一个项目应该做多大？大到能让用户完成一个真实结果，小到你能快速做出来并推给真实用户。不要追求完整，不要一开始做平台，也不要用功能数量换安全感。早期产品最重要的是闭环，而不是规模。
对独立开发者来说，第一个项目的目标不是证明你能做一个大产品，而是证明你能发现一个具体需求，交付一个具体结果，并从真实用户那里拿到反馈。只要这个闭环跑通，小项目就有继续长大的资格。
作业
- 用一句话写出你的项目边界：只帮助谁，在什么场景，完成什么结果。
- 列出用户完成这个结果必须经历的 3 到 5 个步骤，其他功能先全部放到以后。
- 检查第一版是否能在 2 到 4 周内做出可用版本；如果不能，继续缩小范围。
- 砍掉至少 5 个"以后可能有用"的功能，只保留核心路径。
下一节课
为什么不要一开始做平台：平台看起来更大，但冷启动成本也最大。