# 有正职，怎么把 side project 做成：时间、精力与边界

> 写给已经有全职工作、想用业余时间做出一个能赚钱的 side project 的中文程序员。
> 不讲鸡汤，讲约束条件下怎么做出选择。

**状态**：v1.0 | 日期：2026-07-12

---

## 0. 结论先行（TL;DR）

| 项 | 结论 |
|---|---|
| 最大敌人 | 不是技术能力，是"三分钟热度 + 精力耗尽"导致的中途放弃 |
| 现实时间预算 | 工作日 45-90 分钟，周末半天到一天，一周合计 6-12 小时是常态，不是 20+ 小时 |
| 核心策略 | 用"最小可持续投入"（每天固定时段、固定时长）代替"周末爆肝"，前者才能撑过 6-12 个月 |
| 精力管理 | 把 side project 排在正职之前而非之后；降低启动摩擦比延长时长更重要 |
| 选项目标准 | 4-8 周内能上线第一个能用的版本；能拆成周维度的增量交付；早期就能看到真实反馈 |
| 法律边界 | 竞业协议、职务发明、公司资源使用是三个必须提前搞清楚的问题，具体以劳动合同和当地法律为准 |
| 持续性系统 | 公开承诺 + 找搭子 + 里程碑驱动，比"靠意志力硬撑"可靠得多 |

---

## 1. 最大的敌人不是能力，是持续性

先说一个反直觉的判断：**大多数有全职工作的程序员，技术能力早就够用了。** 做一个能上线、能收第一笔钱的产品，需要的技术复杂度通常远低于工作中处理的系统。真正让 side project 死掉的，几乎从不是"这个技术我不会"，而是下面这条曲线：

```
热情
 │╲
 │ ╲___
 │     ╲___________
 │                  ╲______________________
 └──────────────────────────────────────────→ 时间
   第1周   第2周   第3-4周      第2个月起
   疯狂投入 略有下降  开始找借口   彻底停摆
```

**为什么会这样，讲三个真实机制，不是意志力问题：**

**机制一：新鲜感衰减，但项目的"体力活"部分不会衰减。** 一个新点子在头两周最有意思——搭架子、选技术栈、做出第一个能跑的 demo，这段体验本身就是奖励。但过了这个阶段，接下来是处理边界情况、写没意思的表单校验、调支付、写文档——这些活正职工作里天天做，业余时间还要再做一遍，边际吸引力骤降。

**机制二：正职会持续消耗同一种资源。** 写代码需要的专注力和正职写代码需要的专注力，用的是同一个"认知油箱"。不是两个独立的水池。下班后这个油箱往往已经见底，这不是懒，是真实的认知资源耗竭（ego depletion 这类概念在学术上有争议，但"晚上决策质量和专注力下降"这个现象本身是大多数人的真实体验）。

**机制三：没有外部截止日期，也没有同事监督。** 正职有产品经理催、有 sprint、有同事看着。Side project 只有你自己。人类在"重要但不紧急 + 无人监督"的任务上拖延，是最稳定的行为模式之一，不需要意志力薄弱来解释。

**结论：不要设计一个依赖"高热情持续 6 个月"的计划。** 要设计一个"热情归零也能靠系统撑下去"的计划。后面第 2-4、6 节就是在解决这一件事。

---

## 2. 时间：先算清楚，再谈计划

### 2.1 现实地算一算，业余到底有多少时间

大多数人高估自己一周能投入的时间，这是计划失败的第一个根源。做一次诚实的时间审计，而不是拍脑袋：

```
一周总时长：168 小时
- 工作（含通勤）：      45-55 小时
- 睡眠（7小时/天）：     49 小时
- 吃饭、洗漱、家务：     14 小时
- 家庭/伴侣/社交时间：   10-20 小时（因人而异，不能砍到 0）
- 已有的运动/爱好：      3-7 小时（不建议全部让位给 side project）
─────────────────────────────
剩余可自由支配：        约 15-30 小时
```

这 15-30 小时里，还要扣掉刷手机、发呆、纯休息这些"必要的摆烂"——完全不摆烂的计划注定失败。**实际能稳定、可持续投入到 side project 上的时间，工作日每天 45-90 分钟、周末 3-6 小时，一周合计 6-12 小时，是大多数人诚实审计后的真实数字。** 如果你算出来是 20+ 小时/周还能长期维持，要么你单身且没什么其他爱好，要么这个数字撑不过一个月。

建议动作：用手机自带的屏幕时间统计或简单记录，跟踪一周实际的空闲时间分布，而不是凭感觉估算。多数人第一次做这个审计都会被"晚上其实主要在刷手机"这个事实打脸——这也是好消息，说明真正可挤出来的时间比想象中稳定。

### 2.2 碎片时间 vs 整块时间：分开用，别混着用

两种时间的认知负荷完全不同，硬塞同一种任务会两头都做不好：

| 时间类型 | 典型场景 | 适合做的事 | 不适合做的事 |
|---|---|---|---|
| 碎片时间（10-30分钟） | 通勤、午休、排队、睡前 | 写文档/需求梳理、看竞品、回用户消息、写小 bug fix、设计评审、录一段语音想法 | 架构设计、写核心业务逻辑、需要深度专注的调试 |
| 整块时间（1.5小时+） | 早起后、请假的半天、周末上午 | 写新功能、重构、攻克难题、做技术选型决策 | — |

**常见错误：把宝贵的整块时间用来做琐事**（比如周末唯一的 3 小时用来调环境变量），把有限的碎片时间硬塞进需要深度专注的活（比如地铁上想写核心算法，结果一晃神代码全错）。养成习惯：碎片时间前先花 10 秒想清楚"这段时间适合干什么"，而不是打开电脑就随手开始。

一个实用技巧：**把"下一步该干什么"提前写好**，放在 TODO 里，让碎片时间可以直接拿起来就做，而不是先花 10 分钟想"我上次做到哪了"——这一点在第 3 节会展开，是对抗启动摩擦最有效的单一技巧。

### 2.3 用"最小可持续投入"代替"周末爆肝"

两种模式对比：

**模式 A：周末爆肝**（周六周日各投入 6-10 小时，工作日几乎不碰）
- 短期效果好，两天能出不少东西
- 但极其依赖"周末状态好、没有别的事"，只要连续两个周末被打断（加班、家事、生病），项目就中断超过 2 周
- 心理成本高：平时不摸项目，重新捡起来的"冷启动成本"很大，容易演变成彻底放弃

**模式 B：最小可持续投入**（比如工作日固定 45 分钟，周末不强制）
- 单次产出少，但极难中断——45 分钟几乎总能挤出来
- 关键在于"固定"：同一个时间段（比如早起后、午休后半小时），养成条件反射，减少每次决策"今天做不做"的心理成本
- 6 个月后回头看，累计投入时间不比模式 A 少，但项目存活率高得多

**这不是说周末不能多做，而是把"每天的最小量"设为地板，而不是把"周末的理想状态"设为唯一供给源。** 具体建议：

- 定一个"哪怕状态再差也能完成"的下限动作，比如"打开项目、看一眼 TODO、做一件事，哪怕只是改一个文案"。下限要低到你几乎不会为它找借口。
- 周末的额外时间当作"奖励时段"，用来做需要整块专注的事，但不依赖它。
- 允许自己有"仅完成下限"的一天，不要求每天都高产出——持续性比单日产出重要。

---

## 3. 精力管理：正职已经掏空了你，怎么办

时间只是必要条件，很多人时间够但项目还是黄了，因为**下班后没状态**。这一节讲怎么在有限精力下还能维持产出。

### 3.1 把 side project 放在正职"之前"，而不是"之后"

如果条件允许，**早起做 side project 比下班后做成功率高得多。** 原因很直接：早上的认知资源是一天中最充沛的，而下班后是一天中被消耗得最严重的时候。把最需要专注力的事放在精力最好的窗口，是最基础也最容易被忽视的一条。

如果实在不是早起型人格，退而求其次：

- **午休后的 20-30 分钟**，此时精力有一定恢复，且还没有经历下班后的彻底疲惫。
- **下班到晚饭之间的一小段窗口**（如果通勤时间允许），赶在"晚饭后瘫在沙发"的状态之前完成当天的最小动作。
- 明确识别自己一天中"废掉"的时间段（很多人是晚上 9 点后），不要在那个时段安排需要专注的开发任务，可以留给碎片型的轻量事务（第 2.2 节）。

### 3.2 降低启动摩擦：让"开始"这件事本身不消耗意志力

大多数放弃发生在"要不要打开电脑"这一步，而不是"打开电脑后写不下去"。降低启动成本的具体技巧：

1. **收工时留一个"钩子"。** 每次结束当天的工作前，花 2 分钟写下"下次打开项目第一件事做什么"，具体到函数名或页面名。下次坐下来不用回忆上下文，直接开工。
2. **物理环境固定化。** 固定的电脑、固定的位置、开发环境常驻不关（哪怕多占内存），减少"重新搭环境"这个隐性成本。
3. **给启动动作设一个极低的门槛版本。** 比如告诉自己"只写 10 分钟，写不下去就停"——真实经验是大多数时候开始了就会继续，但这个约定本身能消除"必须一次投入 2 小时"带来的心理阻力。
4. **物理隔离干扰源。** 开发时段手机开飞行模式或放另一个房间，社交软件通知关掉。启动后的第一个 10 分钟最脆弱，一条消息就可能把状态打断到当天无法恢复。

### 3.3 用"下一步永远清晰"对抗拖延

拖延很少是因为"懒"，更多是因为**不知道具体下一步是什么**，大脑本能地回避模糊任务。解决方法不是靠自律，是靠减少任务的模糊度：

- 维护一个**只包含"下一步可执行动作"的列表**（不是"完成用户系统"这种模糊大任务，而是"给 User 表加 email_verified 字段并写迁移脚本"这种可以直接动手的粒度）。
- 每次收工前，保证列表里至少有一条明确的下一步，不要留着"想清楚了再写"的空白状态。
- 如果发现某一项拖了超过 3 次都没做，大概率是拆得不够细，或者其实不重要——重新拆解或者干脆删掉，不要让它一直躺在列表里制造愧疚感。

---

## 4. 选对项目：业余时间只能撑起"小"

业余项目和全职创业最大的区别不是野心大小，是**容错的时间窗口**。全职创业者可以扛 6 个月看不到收入，业余开发者如果 3 个月看不到任何反馈，大概率会放弃——不是因为不坚定，是因为第 1 节讲的曲线是真实存在的生理和心理机制。所以选项目本身就是一个降低失败率的关键决策，标准如下：

### 4.1 能做完的项目要满足的条件

| 条件 | 说明 |
|---|---|
| **足够小** | 第一个能上线、能被真实用户使用的版本，应该在 4-8 周的业余时间内能做完（按第 2.1 节的 6-12 小时/周计算，也就是 30-70 个有效小时）。超出这个量级，大概率撑不到上线就放弃了 |
| **能增量交付** | 项目要能拆成"周维度"的可见进展，每周都有东西可以演示或使用，而不是憋 3 个月出一个大版本。增量交付本身就是对抗第 1 节"热情衰减"的解药——持续看到进展，本身会补充动力 |
| **能快速看到真实反馈** | 上线第一版后，最好在 1-2 周内能收到真实用户的使用数据或反馈（哪怕只有 5 个人用）。反馈是持续投入最强的燃料，比自己脑补"这个有意义"管用得多 |
| **单人可完成的技术栈** | 不需要团队配合、不依赖对接大厂需要漫长审批的 API（参考同目录 `mvp-playbook.md` 中提到的 App Store Connect API vs Google Business Profile API 审批周期对比）、不需要罕见的基础设施 |

### 4.2 避开的坑：注定做不完的项目类型

- **需要先囤积大量数据或内容才能验证价值的项目**（比如"先爬 10 万条数据才能看效果"）——业余时间做数据准备工作枯燥且看不到反馈，极易半途而废。
- **依赖平台审批周期长的集成**（企业级 API 申请、需要人工审核数周的资质）——审批周期本身就会消耗掉你最宝贵的早期热情窗口。
- **本质是"重新发明一个大型现有产品"**（比如个人业余时间做一个功能对标 Notion 的笔记软件）——范围失控是业余项目最常见的死法，"再加一个功能就完善了"的心态会不断推迟上线。
- **依赖你目前不掌握、需要长期学习曲线的新技术栈**——业余时间不适合"边学边做"两件事一起攻克，先用熟悉的技术把 MVP 做出来，验证方向后再考虑重写。
- **没有明确第一批用户来源的项目**——如果想不出"上线后第一周去哪里找到 10 个愿意试用的人"，这个项目大概率会做完之后无人问津，第 4.1 节的"快速反馈"条件就无法满足，进而拖垮持续性。

### 4.3 一个简单的自检问题

在正式开始前问自己：**"如果我只有 6 周、每周 8 小时，这个东西能上线到什么程度？"** 如果答案是"完全做不完可用的版本"，说明范围要继续砍，而不是寄希望于"到时候多加把劲"。

---

## 5. 法律与职业边界（重要，务必提前搞清楚）

这是最容易被技术人忽视、但一旦出问题代价最大的部分。**以下内容是通用性提示和法律概念的通俗解释，不构成法律意见，具体以你签署的劳动合同、员工手册、以及所在地当地法律为准，涉及金额较大或已产生纠纷苗头时，请咨询执业律师。**

### 5.1 竞业限制协议（Non-Compete）

**通俗理解：** 竞业限制约定的是"你不能去做和公司有竞争关系的事"，既包括在职期间，也可能包括离职后一段时间。

在中国，根据《劳动合同法》，竞业限制条款有几个关键点值得知道（细节以官方文件和你的合同为准）：

- 竞业限制**理论上只能约束特定人员**：高级管理人员、高级技术人员和其他负有保密义务的人员，不是所有员工都可以被合法约束（[人社部《企业实施竞业限制合规指引》](https://www.gov.cn/zhengce/zhengceku/202509/content_7040571.htm)、[上海市人社局解读](https://rsj.sh.gov.cn/tmsztc_17502/20250708/t0035_1433951.html)）。但实践中很多公司会在合同里对更广泛的岗位约定竞业条款，是否真的有效需结合具体情况判断，不要想当然认为自己"岗位不重要就不受约束"。
- **离职后的竞业限制最长不超过 2 年**，且公司需要按月支付经济补偿（一般不低于离职前 12 个月平均工资的 30%，超过 1 年的部分不宜低于 50%），公司不给补偿的竞业限制条款在实践中可能被认定无效或员工可以不遵守——但这类判断存在争议空间，出现纠纷务必找律师而非自行判断（[中伦律师事务所相关分析](https://www.zhonglun.com/research/articles/53066.html)）。
- 关键在于**"竞争关系"如何界定**：你的 side project 如果和公司主营业务完全不沾边（比如你在做电商后端，业余做一个宠物记账 App），通常风险很低；但如果哪怕有一点业务重叠或者未来可能重叠，风险会显著上升。

**其他国家/地区的一般性提示：** 美国各州差异极大（加州基本不承认员工竞业限制，纽约等州则相对认可，且 2024 年 FTC 曾推动全国性禁止竞业协议但受到法律挑战，具体以最新立法和判例为准）；欧盟、日本、新加坡等地也各有不同的认可尺度和补偿要求。**不要用一个国家的规则去套另一个国家，务必以你实际工作所在地的法律和你签署的合同文本为准。**

**实操建议：** 找出你签的劳动合同和员工手册里关于竞业限制、兼职、副业的条款，逐字读一遍。不确定"我的 side project 算不算竞业"时，这不是能靠自己猜测拍板的问题。

### 5.2 职务发明 / 知识产权归属

**通俗理解：** 你业余时间做的东西，著作权/专利权到底是你的还是公司的，取决于是否符合"职务成果"的认定标准，不是"我用自己的电脑在家做的"就自动等于归自己。

中国《专利法》第六条对"职务发明创造"的界定，核心是两个判断标准（[国家知识产权局官方解读](https://www.cnipa.gov.cn/art/2020/6/8/art_1750_107424.html)）：

1. **是否在执行本单位的任务**（比如公司分配给你的项目，或者和你的本职工作直接相关）；
2. **是否主要利用了本单位的物质技术条件**（公司的电脑、服务器、内部代码库、专有数据、专有工具等）。

只要满足其中之一，就可能被认定为职务发明创造，权利归属公司，即使是业余时间做的。**"业余时间做的"这一点本身，在法律认定上没有你想象中那么关键——关键是有没有用公司资源、内容上是否和本职工作重叠。**

此外要特别注意：**离职后一年内，与原单位本职工作或分配任务相关的发明创造，仍可能被认定为原单位的职务发明**（[最高法知产法庭相关案例解读](https://ipc.court.gov.cn/zh-cn/news/view-1289.html)）。如果你打算做的 side project 未来可能发展成主业并考虑离职专心做，这一条尤其要提前了解清楚。

需要强调：**中国的《著作权法》对职务作品的规定和《专利法》对职务发明的规定并不完全相同，代码的著作权归属和专利权归属可能适用不同规则**，且很多公司会在劳动合同或员工手册里对"利用公司资源完成的一切成果"做出比法律最低要求更宽泛的约定（是否有效需个案判断）。这部分建议直接咨询律师，本文不做展开，避免给出似是而非的结论。

**美国等其他地区的一般性提示：** 美国不少州有专门保护员工"完全用自己的时间、自己的设备、和公司业务无关"的发明创造的法律（如加州劳动法典 2870 条一类的条款），但前提条件同样很具体，且各州不同。**同样以当地法律和你的合同为准，不要套用道听途说的"国外都保护员工副业"的印象。**

### 5.3 使用公司设备/时间的风险

这是最容易在无意中踩到的红线，也是最容易避免的：

- **不要用公司电脑、公司账号（GitHub、云服务、AI 工具订阅等）开发 side project**，哪怕只是"顺手用一下"。一旦发生纠纷，"是否使用了公司物质技术条件"是关键认定标准（见 5.2），公司电脑上的一切活动记录都可能成为证据。
- **不要在上班时间做 side project**，即使自认为"反正手头没活"。这既可能违反劳动纪律（构成公司解除合同的理由），也会让"是否属于工作时间完成"这一争议点对你不利。
- **避免使用工作中获得的非公开信息、专有算法、内部数据结构做 side project**，哪怕只是"借鉴思路"而非直接抄代码。这类边界很模糊，出问题时"我只是参考了设计思路"这种解释在纠纷中往往站不住脚。
- **物理和数字环境彻底隔离**：单独的电脑或至少单独的账号体系、单独的代码仓库、单独的云服务账号、单独的 AI 工具订阅。这不仅是合规需要，也是在纠纷发生时最有力的自证清白的证据。

### 5.4 如何避免和雇主产生纠纷：提前问清楚的问题清单

与其等做大了再担心，不如在开始前花 30 分钟做这几件事：

1. **重新读一遍劳动合同和员工手册**，搜索关键词"竞业""兼职""副业""知识产权""发明""保密"，逐条理解。
2. **判断 side project 和公司主营业务的距离**：完全不相关（风险低）、相关但不直接竞争（风险中，建议主动确认）、有竞争关系或使用了同类技术/数据（风险高，强烈建议先咨询法务或律师，甚至考虑更换方向）。
3. **不确定时，很多公司允许员工书面申请"业余项目披露"或"兼职许可"**，部分公司有专门流程。如果公司文化允许，主动申报比事后被发现更安全，虽然这在很多公司文化里显得"多此一举"，但对于可能做大或涉及资金的项目，这是成本最低的保险。
4. **涉及金额变大、开始考虑全职投入之前，务必重新评估一遍以上所有问题**——side project 从"业余练手"变成"认真的生意"这个阶段，恰恰是法律风险从"理论上存在"变成"值得认真对待"的转折点。
5. **有实际纠纷苗头（比如收到公司询问、警告邮件）时，第一时间咨询劳动法或知识产权律师，不要自己揣测法条应对。**

---

## 6. 持续性系统：用系统代替意志力

第 1 节讲了为什么"靠热情坚持"不可靠。这一节讲具体能搭建的外部系统，把"我今天要不要做"这个每天都要重新做一次的决策，变成不需要临时决策的习惯和结构。

### 6.1 Build in Public（公开构建）

把开发过程在 X（Twitter）、即刻、小红书、少数派等平台上公开记录（每周或每完成一个里程碑发一次进展），核心作用不是营销（虽然确实有冷启动获客的附加价值），而是：

- **制造轻量的社会监督。** 公开说过"这周要上线 XX 功能"之后不做，会有真实的心理成本，这比"只有自己知道"的内在承诺更有约束力。
- **提前积累种子用户。** 等产品做完再找用户，比边做边攒关注者慢得多；关注你过程的人，很多会成为第一批真实反馈来源，直接对接第 4.1 节的"快速反馈"需求。
- **注意边界：不要泄露公司相关的任何信息**，包括截图里意外带出的公司内部工具、代码风格、同事对话等，第 5.3 节的边界同样适用于公开分享内容。

### 6.2 公开承诺（Public Commitment）

比 build in public 更进一步：给自己设一个有真实代价的截止日期，并告诉至少一个会追问你的人。心理学上"承诺一致性"效应是真实存在的——公开说出的目标比只在心里想的目标更容易被执行，因为放弃会带来社交层面的不适感，而不只是自我失望。

具体做法：找一个朋友、社群或者干脆在社交平台上说"8 月 15 日前上线第一个能用的版本"，并且真的允许别人在那天来问你结果。

### 6.3 找搭子 / 加入社群

单人硬撑最容易在第 1 节讲的曲线第 3-4 周崩掉。找到能互相监督的伙伴或社群，是最有效的外部支撑之一：

- **搭子模式**：找 1-2 个同样在做 side project 的朋友，约定固定频率（比如每周日）互相汇报进展，哪怕只是文字汇报，不做视频通话也有效。核心机制和公开承诺相同——有人会问，就更容易做到。
- **社群模式**：加入 Indie Hackers、X 上的独立开发者圈子、即刻的"折腾"或"独立开发"相关圈子、少数派社区等。价值不只在获客，更在于"看到别人也在同样的节奏里挣扎和坚持"，能显著降低"是不是只有我这么难"的自我怀疑。
- 定期（比如每月）做一次"回顾式发言"（哪怕只是自己写在笔记里，公开发出去效果更好）：这个月做了什么、卡在哪、下个月打算做什么。回顾本身会强化"这是一个持续的事情"的心理框架，对抗"三分钟热度"式的三天打鱼两天晒网。

### 6.4 用里程碑而非完美驱动

**完美主义是持续性的隐形杀手。** "这个功能还不够好，等打磨完再发"是最常见的自我拖延借口，而且往往打着"高标准"的旗号,不容易被自己识破。解药是彻底转换驱动方式:

- **用"里程碑清单"代替"完美度评分"作为进度衡量标准。** 里程碑是二元的（做完了/没做完），不是"这个功能打磨到什么程度算够好"这种主观连续量表——后者永远没有终点。
- **给每个里程碑设定"够用"的具体标准，写在纸面上，达到就发布，不追加。** 比如"用户能注册、创建一条记录、看到列表"就是一个完整里程碑，不因为"UI 还丑"而拖延发布。
- **允许早期版本丑、允许早期版本功能少，不允许早期版本延期发布。** 时间上的纪律性此时比产品完成度更重要——第 4.1 节讲过，快速反馈是持续投入的燃料，完美主义直接掐断这条燃料线。

---

## 7. 一周投入模板示例（工作日 + 周末）

以下是一个现实的、按第 2-6 节原则设计的样例，供参考调整,不是必须照搬的模板：

```
【工作日模板】（周一至周五，每天固定 45-60 分钟 + 零散碎片时间）

  早起后 30-45 分钟（精力最好的窗口，优先用于需要专注的开发）
    → 写一个明确的下一步任务（第 3.3 节的"下一步清单"里取一项）
    → 只做一件事，做完就停，不追加范围

  通勤 / 午休（10-20 分钟碎片时间，可选）
    → 回看用户反馈、记录想法、写下明天的下一步任务（第 3.2 节的"钩子"）
    → 不做需要深度专注的开发

  收工前 2 分钟
    → 写下"明天打开项目第一件事做什么"，具体到函数/页面级别


【周末模板】（周六或周日，选一天投入 3-5 小时；另一天完全留给生活）

  周六或周日上午（整块时间，用于第 4 节标准下"一周一个可见进展"的核心工作）
    → 完成本周里程碑（发布一个小增量、修复一个关键 bug、接一个新功能）
    → 结束后花 15 分钟写 build in public 的进展帖（第 6.1 节）

  另一天
    → 不碰项目，用于生活、社交、运动、纯休息
    → 这不是"浪费"，是维持长期节奏的必要部分（回看第 1 节的曲线）


【每周合计】
  工作日：5 × 45-60 分钟 ≈ 4-5 小时
  周末：1 天 × 3-5 小时
  合计：约 7-10 小时/周，落在第 2.1 节测算的可持续区间内

【每月一次】
  月末花 30 分钟做回顾（第 6.3 节）：
    → 这个月完成了哪些里程碑
    → 用户反馈是什么（如果已上线）
    → 下个月的 1-3 个里程碑是什么
    → 如果连续 2 个月毫无进展或毫无反馈，认真考虑是否要换方向或暂停
      （诚实止损也是这个系统的一部分，不是失败）
```

**关于这个模板的诚实提醒：** 这个节奏做出一个能用的 MVP，大概率需要 2-4 个月，而不是很多"周末创业"叙事里暗示的"几周暴富"。这是用可持续性换来的代价——但它比"爆肝 3 周然后放弃"的路径，实际完成产品的概率要高得多。选哪条路，取决于你对第 1 节那条曲线的信任程度。

---

## 小结：三句话

1. 打不过精力和时间的物理约束，就设计一个在约束内也能跑完全程的系统——"最小可持续投入 + 清晰的下一步 + 里程碑驱动"就是这个系统的核心。
2. 选项目本质是在选一个"你大概率能坚持到看到反馈"的范围，范围越小、反馈越快，存活率越高。
3. 法律边界不是扫兴的顾虑，是这件事能不能长久做下去的地基——提前花 30 分钟读合同，比事后花几万块请律师便宜得多。

---

## 参考来源

- [人力资源社会保障部办公厅《企业实施竞业限制合规指引》](https://www.gov.cn/zhengce/zhengceku/202509/content_7040571.htm)
- [上海市人社局：劳动者必须签订竞业限制和培训服务期协议吗？](https://rsj.sh.gov.cn/tmsztc_17502/20250708/t0035_1433951.html)
- [中伦律师事务所：竞业限制若干法律问题初探](https://www.zhonglun.com/research/articles/53066.html)
- [国家知识产权局：职务发明与非职务发明是怎样界定的？](https://www.cnipa.gov.cn/art/2020/6/8/art_1750_107424.html)
- [最高人民法院知识产权法庭：离开原单位一年内职务发明创造的权利归属](https://ipc.court.gov.cn/zh-cn/news/view-1289.html)

> 以上法律相关内容仅为通俗解释和信息整理，不构成法律意见。实际权利义务以你签署的合同文本、公司规章制度、以及你所在司法管辖区的现行有效法律为准，重大决策前请咨询执业律师。