不知道你有没有刷到过这种带着 day 编号的系列标题。day1、day30、day100看起来像某种自律宣誓但真正坚持下来的人少得可怜。我这个“day45”不太一样它不是自我感动式的打卡而是把一件具体的、能落地的事一点一点磨出来。这 45 天我做了个决定利用每天下班后的 90 分钟从零开始做一款名为“今日回响”的每日计划与复盘 Web 小工具。今天正好是第 45 天核心功能完成、部署上线、并且拿到了第一批真实用户的反馈。这篇记录适合三类人一直想用业余时间做点独立开发但迟迟没动手的想坚持做一件事却总是中断的以及自己也写过小工具、踩过不少部署和需求坑的人。这个系列我从 day1 开始就没把它当成“坚持打卡”而是当成一个可交付的迷你项目来推进。45 天过去项目从一个空仓库变成了一个能注册、能记录、能生成周报的在线应用。这篇文章会把我在这个节点上的完整复盘写出来包括方案怎么定的、技术选型怎么做的、核心链路怎么拆、上线时踩过的坑以及连续 45 天的工作节奏是怎么维持下来的。每一部分都来自实际操作不是概念科普你可以直接拿来当参考。1. day45 这个节点从热血到平淡再到真正做出东西1.1 为什么选在第 45 天做复盘选第 45 天做复盘不是因为 45 这个数字有什么特殊含义而是它恰好卡在了一个非常微妙的节点上。大部分半途而废的项目倒在第 7 天到第 21 天之间新鲜感消退正反馈还没有出现现实中的工作一忙就断更。能撑到第 45 天说明项目已经度过了最危险的“热情存活期”但又远没到可以松懈的稳定期。另一个原因更实际。第 45 天正好是小步快跑的“第一个验收点”前面 30 天把主体功能做完第 31 到 44 天做测试、修 bug、部署、邀请朋友试用。到了第 45 天我手里有了真实的数据和反馈而不是停留在“我觉得这个功能很有用”的自嗨阶段。这时候复盘能看到的东西比 day30 时多得多。所以我特别建议所有做长期打卡类项目的人把复盘节点设在第 45 天附近而不是非要等到 100 天。原因是45 天足够完成一个最小闭环产品而 100 天容易拖成“三个半途而废的 30 天”。1.2 第 1 天到第 45 天的心态变化曲线如果把心态画成一条曲线大概是这样的第 1 天到第 5 天是打了鸡血的兴奋期每天恨不得写三个小时脑子里全是功能灵感第 6 天到第 14 天进入疲软期那天下班特别累打开编辑器坐了一会儿一行代码也没写出来差点想放弃第 15 天到第 30 天是进入状态的平稳期我开始接受“今天写烂代码也没关系明天再优化”的节奏第 31 天到第 45 天则是产出期因为核心功能已经在跑更多精力放在真实问题修复上成就感开始自然回升。这条曲线和做一个中型功能开发的心路几乎是重合的。前期最需要对抗的不是技术难度而是“没有正反馈”带来的空洞感。我自己的解决办法是一旦觉得没意思就先把项目里最无聊的小任务做掉比如整理数据库索引、补错误提示文案。这些小任务能快速带来“完成了一件事”的感觉帮我把心态拽回正轨。在这个过程中我意识到一直接 fed 着项目推进的不是意志力而是“每日可完成的小目标”。把“做一个每日计划工具”拆成“今天完成任务表的数据验证逻辑”之后坚持就变得容易很多。1.3 第 45 天结束时手里有了什么你可能会好奇45 天业余时间到底能产出多少东西。我给这 45 天做了个量化记录维度数据累计投入约 67.5 小时日均 1.5 小时代码提交146 次核心功能4 个模块任务管理、复盘记录、周报生成、趋势统计修复 bug23 个用户测试6 位朋友参与试用收集 22 条反馈主要技术栈Next.js、Supabase、Tailwind CSS、Vercel这组数字的意义在于它证明了业余时间做项目不需要每天投入 5 小时也不需要一上来就做出一个“改变行业”的东西。只要稳定保持平均每天一个半小时45 天就可以完成一个可用的、结构完整的小应用。技术难度不高但完整走完了从想法到上线的全流程这比单纯写一堆炫技代码更有参考价值。“做完一个完整的小东西”的收获和“跟着教程敲了一个 demo”完全不在一个层级。前者逼你面对数据库设计、错误处理、部署环境、用户反馈这些真实问题后者只需要你在稳定的开发环境里按部就班执行。如果你正犹豫要不要开启自己的项目我的建议是不用等状态不用等课程先花 45 天把一个小东西做得完整再评估下一步。2. 项目方案怎么定的就做一个小而完整的闭环2.1 为什么选“每日计划 复盘”这个方向回到 day1 的时候摆在我面前的无非是几条路做一个 AI 套壳应用、写一个爬虫脚本库、做一整套博客系统。这些方向要么太依赖外部 API要么只是“看起来有技术含量”要么做的过程中很容易跑偏。我最后选了“每日计划 复盘”这个在技术层面并不复杂的方向纯粹是因为它符合一个业余项目最重要的标准自己能持续用。我自己原本就有手写日志的习惯但纸质记录没法搜索、没法统计、也没法回溯周计划。做一个数字版的“计划 复盘”工具首先解决的是我自己的需求。需求真实并且足够小意味着不会出现“做完了却不知道给谁用”的尴尬。另外这个方向的功能边界很清晰计划、执行、记录、统计四步闭环不用为了凑功能而硬加模块。更重要的是这个方向的技术栈覆盖很全面有前端交互任务勾选、富文本输入、有后端数据操作增删改查、用户体系、有存储设计任务表、复盘表、还有定时逻辑周报聚合。麻雀虽小五脏俱全。对于业余项目来说在 45 天内完整做一遍“用户能注册、能写数据、能看统计”的流程远比把一个 AI 应用叠出花更有长期价值。2.2 技术选型逻辑Next.js Supabase Vercel技术选型这件事我在 day2 就拍板了后面再没有大改过。核心逻辑只有一个选那些能让我在最短时间内完成闭环、且维护成本低的方案。当时我列的候选组合有三个方案优势劣势Next.js Supabase Vercel前后端一体、免费额度够用、部署无感不适合超大流量场景Vue Flask 云服务器国内资料多、可控性强需要自己维护服务器、部署繁琐纯前端 localStorage最简单、零成本无用户体系、数据易丢、无法多端同步我选了第一套。Next.js 提供了文件路由和 API Route让我可以用一个项目搞定前端页面和后端接口Supabase 自带 Postgres 数据库和简单的用户认证省去了单独写 auth 系统的几乎所有工作量Vercel 负责托管git push 后自动完成部署。这个组合把“从代码到线上可用”的链路压缩到最短。选型时很多人容易犯一个错误为了所谓的技术先进性或者简历好看选择更复杂、更小众的框架组合。我劝你克制。对于 day45 这种业余项目选型的唯一标准是“让功能尽早跑起来”。等技术成了瓶颈再说升级的事一开始就把技术栈搞复杂往往是 day7 就弃坑的元凶。2.3 范围控制怎么把需求砍到能 45 天内完成边界梳理是项目上线前的生死线。第 45 天能按时上线全靠我在 day5 的时候砍掉了三个需求习惯打卡日历、每日一句心情语录、数据导出 Excel。前两个属于“锦上添花型”功能没有它们不影响核心闭环第三个属于低频需求一周用不到一次。把它们从计划里划掉之后核心功能变得非常清楚首页创建今日任务勾选完成状态复盘页写下当天文字复盘保存后不可随意删除周报页按周聚合任务完成率和复盘记录趋势页展示最近 30 天任务完成率折线图这四条主链路对应的是用户数据流的四个环节录入、存储、聚合、展示。每个环节都能在 3 到 5 天内完成加起来正好落在 45 天的时间窗口里。砍需求要遵循一个标准看它是否直接服务于“计划 — 执行 — 复盘”这个核心闭环。凡是可用手动方式临时替代的都不值得在第一版里开发。比如数据导出早期用户如果需要完全可以把页面截图保存习惯打卡日历也可以后续用“任务完成率折线图”先顶上。把需求砍到最少是我能稳定推进的最大保障也是所有长时间项目必须学会的一课。3. 核心链路实现与实操细节拆解3.1 数据模型怎么设计三张表解决 90% 的需求数据模型是整个应用的地基一开始没设计好后面返工成本极高。我最后用的是三张表每一张都指向一个明确的使用场景。第一张表是 tasks记录所有创建的任务。核心字段包括id、user_id、content任务内容、date目标日期、is_completed完成状态、completed_at完成时间。这里特别注意is_completed 和 completed_at 为什么要分开因为用户可能补勾昨天的任务如果没有 completed_at统计完成率时会出现时间归属混乱。第二张表是 reviews记录每天的文字复盘。字段更简单id、user_id、review_date、content复盘内容、mood心情指数。mood 是后来应测试用户要求加的只用 1 到 5 的数字避免主观描述导致语义解析的负担。第三张表是 users直接用了 Supabase 内置的 auth.users 表没有额外设计。这样省掉了密码加密、会话管理这些最容易被写错的部分。这三张表之间通过 user_id 关联查询模式非常固定按日期查任务按日期查复盘按用户聚合统计。正因为表结构足够简单day10 之后几乎没有因为数据问题修改过后端逻辑。对于想要复刻这个项目的人我的建议是不要一开始就设计十几张表三到五张表能跑通流程就先把流程跑通表结构等真实需求出现再迭代升级。3.2 核心链路写任务、勾完成、写复盘整个应用最重要的链路我从 day8 开始实现day12 基本跑通。它分为三个环节第一步用户在首页顶部输入框写下今天的计划任务按回车保存。这里有一个容易忽略的细节任务的“日期”不能直接存服务器当天时间而要取用户浏览器端的时间。否则西半球用户在晚上使用时任务会被归到“昨天”。这个时间归属问题看似很小实际在统计周报时很容易糊成一团。第二步用户完成任务后点击任务项前面的圆圈进行勾选。完成状态立刻写入数据库同时用一次 API 请求记录 completed_at。这个交互想让体验顺畅必须做乐观更新在前端先改变勾选状态、请求失败再回滚而不是等服务器响应了再变状态。第三步晚上在复盘页写当天的文字内容保存后聚合到当天的复盘记录里。这一步我故意做得很轻不加字数校验、不要求必填。原因是我希望用户能无压力地写两句话而不是把复盘当成一个沉重的任务。从我自己的使用体验和测试反馈来看“轻量输入”是高频使用的前提门槛一旦提高使用频率会立刻下降。这条链路走到 day40 左右基本稳定之后的 API 调用次数很少出错说明最初的设计足够健壮。核心思路也很简单每条用户操作都对应一个明确的 API 端点前端做好状态同步后端做好数据校验剩下的交给框架处理。3.3 上线与部署免费额度下的稳定发布部署环节最大的诉求是“省心”。我选了 Vercel因为它和 Next.js 是同一生态git push 到 main 分支后平台自动完成构建和发布。整个过程不需要自己配置 Nginx、不需要买域名默认自带和子域名、也不需要担心 HTTPS 证书。对于技术背景一般的独立开发者来说这种“无感部署”体验的最大价值是把精力留给了产品本身而不是运维。Supabase 的免费套餐提供了 500MB 数据库存储和每月 5 万次 API 调用对一个日活不超过 50 人的小工具来说完全够用。我在 day35 写好了数据库索引包括 tasks 表上 user_id date 的联合索引、reviews 表上 user_id review_date 的联合索引。这一项优化让页面查询时间从约 200ms 降到了 80ms 左右体感上变化非常明显。部署当天我还做了一件事手动检查了三个环境变量是否正确注入到 Vercel 和 Supabase 两端。很多新手部署失败十有八九是环境变量对不上。如果你也打算复刻这个项目请务必在上线前专门抽 10 分钟检查 key 是否从服务端正确传递到前端避免上线后出现数据读写全部 401 的错误。4. 45 天踩坑实录与问题排查技巧4.1 时区问题任务日期和实际日期差了 8 小时这是我在整个项目里踩到的第一个比较隐蔽的 bug。现象是北京时间凌晨 1 点创建的任务日期却显示成了前一天。排查过程大概花了我一个晚上。查到最后发现问题出在 Supabase 后端默认以 UTC 时间存储而前端传给它的 date 是标准的 yyyy-MM-dd 字符串后端在解析时把字符串当成 UTC 日期处理导致和北京时间的本地日期错位了 8 小时。解决方式其实不复杂前端在创建任务时不传和字符串而是把经过本地时区校正后的 date 字符串传过去。也就是说我先用 JavaScript 的 Date 对象获取用户本地年份、月份、日期再拼成 yyyy-MM-dd 格式传给后端。后端只负责原样存储不参与任何时区转换。这样无论用户在哪个时区任务的日期归属都是正确的。这个 bug 给到我的教训是永远不要假设后端默认时区和用户时区一致。尤其做面向普通用户的应用只要涉及“日期归属”或“按天统计”最好在前端统一完成时区计算后端只负责存储和查询。类似的坑我后来在周报模块又踩了一次好在有了第一次的经验第二次排查只花了 20 分钟。4.2 需求蔓延第 20 天差点把项目做崩第 20 天左右我的心态发生了微妙的变化核心功能跑通了开始觉得“不如加一个番茄钟吧”“再做一个目标拆分功能也不错”。这个阶段非常危险因为新增需求会带来连锁反应数据表要加字段、页面要加交互、统计逻辑要重写。一旦开始膨胀45 天计划几乎注定延期。当时我采取了一个很硬核的动作把“新增功能”全部写到一个名为“v2 想法池”的文档里只记录不实现。这个做法看起来很原始但特别管用。把想法从脑子里拿出来放到文档里大脑就不再惦记着它们可以安心回到主链路的优化上。后续我统计了一下这个想法池里最终只有两条被真正做进了第一版其余都被自然淘汰了。如果你也容易在项目中途进行需求蔓延建议你给自己立两条规矩第一第一版只做当初定义好的核心闭环除此之外任何新需求都进想法池第二每次想加功能之前先去回答一个问题“不加它用户最核心的任务能不能完成”如果不能才值得在当前阶段考虑。这两条规矩帮我守住了节奏也是我能在第 45 天顺利收口的关键。4.3 反馈循环同事的一句话改变了功能优先级上线后我开始让朋友和内测用户参与试用第一次真正收到外部反馈是在第 38 天。有位同事在试用了几天后跟我说“任务勾选前的页面很清晰但勾完之后我也想看看过去一周到底完成了多少事。”这句话让我重新审视了周报页的优先级。此前我的计划里周报页排在较后位置甚至一度考虑跳过只做趋势页。但用户的需求提醒我任务的完成率统计是“坚持使用”的关键驱动力。看到每天、每周的完成率变化用户才能体会到复盘的价值。于是我把周报页提前实现并把“周完成率”和“按天的柱状图”放到页面最显眼的位置。这轮反馈循环带来的变化是产品从一个“给用户记事的工具”变成了“给用户反馈进展的工具”。功能只是载体能够持续给用户带来“变化感”和“进展感”才是留存的关键。这也提醒了我一个人闷头开发时很容易凭直觉判断优先级但真实用户的声音往往更能暴露产品价值的核心所以尽早把半成品拿给别人试用永远好过自己闭门觉得“已经很好”。4.4 问题排查速查表每次踩坑我基本都按“现象确认 → 初步定位 → 边界测试 → 修复验证”的顺序处理。下面是我在这 45 天里高频遇到的五类问题及对应的排查要点可以直接收藏备用现象可能原因排查方法页面数据加载不出来环境变量缺失或错误检查前后端环境变量 KEY 是否一致任务日期错乱时区处理不一致统一在前端生成日期字符串勾选状态刷新后丢失乐观更新未回滚检查 API 请求失败时 UI 状态是否恢复注册后无法登录Supabase 回调 URL 配置错误在 Supabase 后台添加正确域名到允许列表统计数字不准任务带旧日期补勾按实际完成时间而非任务日期统计这五类问题几乎覆盖了独立开发小型 Web 应用时 80% 的日常故障。把它们整理成速查表还有一个额外好处下次再遇到类似问题不用重新回忆整个排查过程直接对照清单处理就行省下来的时间又能投入到迭代里。5. 让 day45 走到底的工作方法与习惯管理5.1 每天只有 90 分钟时间怎么安排这个项目日均投入 1.5 小时不是因为我自律而是因为我把“可执行时间”压缩到了极限。工作日下班到家吃完饭差不多 20:30我会定一个 21:00 的闹钟从 21:00 到 22:30 之间的 90 分钟雷打不动只做项目相关的事。到了 22:30 立刻收手不管代码写到一半还是思路正顺都强制关电脑。这 90 分钟的时间结构我做了固定分区前 10 分钟只做“接续”——看昨天的进度、理出今天的下一步中间 60 分钟只做“核心任务”不刷论坛、不回消息最后 20 分钟做“提交与记录”整理本次改动写好 commit message 和第二天的待办。这套时间分配的核心是不要每天从头想今天做什么而是前一天晚上或者当日开工前 5 分钟就把计划确定避免“不知道干嘛”造成的拖延。我以前也试过“有空就做”的模式结果是一周只动了两天。自从定了固定 90 分钟之后项目开始稳定推进。你可能会担心时间不够但从结果上看平均每天 90 分钟已经足够支撑我完成这个项目。对大多数人而言差的不是时间而是把特定时段固定下来的确定性。5.2 中断、摆烂与恢复第 9 天我差点弃坑中途我有几天状态非常差第 9 天尤其典型。那天加完班回家已经晚上十点多坐在电脑前真的一个字都不想写。但我没有直接断更而是做了一件很小的事只打开代码把某个组件的注释补全然后提交。这个提交只有一行注释但保住了“连续记录”的链子。保住链条的价值在于一旦断了一天中断第二天就会变得毫无心理负担项目大概率就地终止。降低单次执行标准的策略就是防中断的最佳防线。那天之后我给自己立了个规矩状态好的时候多做一点没关系状态差的时候哪怕只写一个注释、改一个变量名也要在项目仓库里留下痕迹。后来我复盘过这 45 天的数据发现真正高产的只有大约 25 天剩下 20 天里有不少是“低强度维持”。但正是这 20 天的低强度维持让整个项目没有崩盘反而在积少成多中完成了大量补充性工作。坚持的本质不是每天全力以赴而是每天都不要完全离场。5.3 第 45 天之后项目接下来怎么走到了第 45 天“今日回响”已经是能正常使用的小工具了。因为我一开始就笃定“要完整交付”所以没有让它停留在本地 demo 的阶段而是真实上线、有用户、有数据。接下来的一两个月我计划做三件事先把测试用户的反馈逐条打分挑出真正值得做的 2 到 3 个需求再优化移动端体验目前手机浏览器上的排版还不够顺手最后加一个“连续打卡天数”的小徽章给自己和用户一点额外的正向激励。从长远来看这个项目大概率不会成为什么爆款产品但它的价值已经完整拿到了验证了一个人能独立完成从想法到上线的整个流程、积累了一批可复用的代码和部署操作经验、也真实感受到了“一个产品从无到有”的完整心路。第 45 天只是这个项目长跑里的节点后面可以根据自己的节奏继续往前冲也可以暂时放一放做点别的新尝试。我个人在这 45 天里最大的体会是这类带 day 编号的连载真正的价值不在于向别人证明“我很自律”而在于给自己制造一个持续交付的容器。只要你把“day45”定义成一个具体可交付的节点那前面的每一天都会自动找到存在的意义。如果你也想开启自己的 day1我更建议你先别想什么长期规划而是先定下一个具体的、45 天后能验收的小成果然后从今晚开始动第一行代码。