不知道干吗的这个项目名字是我在某天下午敲下的占位符。当时我手上有五六个想法每个看起来都有价值但每个都回答不了一个最基本的问题第一个版本到底要解决谁的什么困扰。我在编辑器前坐了两个小时最后只留下这一行字。这种状态估计不少做产品、做项目的人都熟想法倒是一堆落到地上就发虚动手写了两百行代码又推翻因为连自己都说服不了这个功能存在的意义。这篇文章会把我从不知道干吗的走到一个能真实运行、有人每天在用的个人时间记录工具的全部过程拆给你看重点不是炫技术而是那套把模糊想法一步一步收敛成可执行方案的方法。适合手上握着模糊点子不知道怎么推进、或者被困在反复改需求里出不来的朋友。1. 项目背景先承认自己不知道干吗的1.1 这个状态到底是怎么来的我复盘过自己为什么会进入这种不知道干吗的状态原因没那么玄其实就是三个东西叠在一起信息过载、标准不清、反馈缺失。信息过载指的是那段时间我关注了很多效率工具、独立开发案例和技术社群的话题每天都能看到别人做出很有意思的东西于是大脑里积累了大量的可能性但没有形成判断依据。标准不清说的是我没有给值得做这件事定一个可量化的门槛于是任何想法都可以被万一有人需要呢这个理由支撑住。反馈缺失就更简单那些想法没有接触过任何一个真实用户甚至连我自己都没认真使用超过三天。这三个原因里最要命的是标准不清。信息还可以慢慢消化反馈可以后面再补但没有判断标准你对所有想法的评价就完全靠情绪——兴趣来了觉得是金矿兴趣走了立刻觉得不值钱。我后来用一个很土的办法解决把每一个候选想法都写到一张卡片上然后在卡片背面强制回答五个问题回答不出来的直接淘汰。这五个问题是谁会在什么情况下用这个工具、他现在的替代方案是什么、这个方案比替代方案强在哪里、我要花多久做出第一版、做出第一版后我怎么验证它有没有价值。写完之后我承认五个问题里我能答上来的几乎没有唯一让我有思路的是其中一个关于时间记录的想法。1.2 把模糊想法先写下来别急着否定很多人到了这一步会慌觉得我想不清楚是不是说明我不适合干这件事。恰恰相反想不清楚才是正常起点。我自己处理的方法是先不讨论做不做而是把想法用最原始的方式描述一遍一句话版本和一段话版本都要。一句话版本是给陌生人看的比如一个用快捷键记录时间花费的小工具一段话版本是给自己看的要把使用场景写成一个具体的故事我每天在项目之间切换经常到晚上想不起来今天到底处理了哪几件事如果能在切换任务时花三秒钟记录一下晚上就能自动生成一天的时间轴。这个练习的价值在于它把你从抽象的情绪判断拉到具体的行为推演。你会发现只要把场景说清楚你马上能知道这个想法会不会在真实生活里被使用。我当时写完这段描述后第一反应竟然是这工具我自己一定需要这个直觉后面成了整个项目最核心的驱动力。我在纸上又补了一句话就算别人都不用我自己也得用它三个月。把模糊想法写下来的另一个好处是它会自动暴露你忽略的边界问题。比如记录时间花费听上去简单但你马上会遇到忘记记录怎么办分类太多会不会增加负担数据存在本地还是云端这些边界问题不需要当时全部解决但把它们记录下来后面做功能范围界定时就是现成的素材。2. 需求澄清从不知道干什么到为谁解决什么事2.1 先服务那个最挑剔的自己项目从不知道干吗的往下走的第一步不是去外面找用户做访谈而是先把自己变成第一个用户。我当时给自己定了一个规则如果这个工具连我自己都用不满一周那它就不配给别人用。这个规则帮我挡掉了大量外围工作。我花了一个周末把自己每天的时间花费情况用纸笔手动记录了一遍颗粒度细到半小时。记录过程比想象中痛苦因为纸笔的流程太慢中间有几次差点放弃。但正是这份手动记录给了我信心——我做了一张简单的统计表发现我一天里真正花在核心任务上的时间往往不到三小时大量时间被群聊、新闻阅读、来回切换页面给切碎了。这个结果很反直觉因为我在回顾一天时主观感受是我一直很忙。这个用户研究没有用任何高级方法就是记录、统计、结合自身体感做判断。它给我明确了第一版必须解决的一件事降低记录动作的成本。只要记录这个动作超过五秒钟我大概率不会坚持用下去。所有设计都该围绕这个核心展开分类要少、输入要快、界面要直接。2.2 用五问法把场景揉碎按照我的习惯从模糊走向清晰会用一个五问法它就是前面提到的五张卡片问题的正式版。针对时间记录这个方向我当时写下来的答案是第一个问题谁会在什么情况下用这个工具。答案是我自己在一天里多个任务来回穿插、或者整天坐在电脑前忙个不停的时候。第二个问题我现在的替代方案是什么。答案是用纸笔记录但常常忘了写而且晚上整理统计非常痛苦。第三个问题这个方案比替代方案强在哪。答案是记录动作只要三秒能自动生成统计视图减少人工整理。第四个问题多久能做出第一版。我给的预估是一到两周因为核心链路不复杂。第五个问题做出第一版后怎么验证价值。标准是连续使用两周并且每天都会回看统计结果。这五个问题答完之后项目不再不知道干吗的了它至少有了一个可以被否定的形状。你注意这个过程里没有引入任何复杂工具就是一张纸一支笔。但它的作用比很多花哨的需求文档都大因为每个答案都必须来自你真实的体验或调研不能靠拍脑袋写。2.3 砍掉 80% 的功能保住一条主链路需求收敛的最后一步是砍功能。我见过太多项目死在功能堆叠上因为做的人不敢做减法总觉得功能少了就显得不完整。但事实上第一版需要的不是完整而是完整地走通一条主链路。对时间记录工具来说主链路是唤起记录、快速选择分类、保存记录、晚上查看统计、发现时间被哪些事情吃掉。这个链路里的每个环节都有最小实现方案比如唤起记录可以用系统级快捷键分类选择只需要一个下拉框保存记录无非是往数据库里插一行统计则画一个简单的柱状图。除此之外的一切功能包括多设备同步、标签系统、团队协作、自动生成周报全部砍掉或者说放到后续版本的池子里。砍功能时我有一个很有效的判断公式如果这个功能缺失会导致主链路断掉就必须保留如果缺失只是让体验更好那就先不做。按照这个公式自动分类这种看起来很酷的能力也被我砍了因为第一版里我可以接受手动分类。事实证明砍掉那些外围功能让开发心态变得非常轻松我不需要想着这个逻辑以后会不会要重构只需要专注把一条路走通。3. 技术选型与核心实现把想法跑起来3.1 为什么选一个小气的技术栈很多项目死在选型上不是因为技术不够先进而是因为选择了维护成本高、启动成本高的重型方案。我的原则是一个人开发、一个人使用的工具技术栈怎么轻怎么来。所以第一版我选了 Python 3 Flask SQLite前端只有两个页面图表部分用 ECharts 的 CDN 引入。这个组合在开发圈子里算是老掉牙了但正好匹配当前阶段的需求不需要复杂的构建步骤、不需要容器化、不需要单独部署数据库服务。选 Python 是因为我写它最熟练不用查文档就能写出可运行的代码这是降低启动成本的隐性因素。Flask 则负责提供几个简单的页面和 JSON 接口路由不超过十个。SQLite 是单文件数据库备份就是复制文件对于个人工具来说没有任何运维压力。ECharts 负责画时间分布图它内置的时间轴、饼图、柱状图组件足够用。我要特别说明如果你自己的技术栈是 Node、Go 或者纯前端完全可以用你熟悉的那一套不需要照搬。选型的核心不是哪个最好而是哪个让我在两周内产出第一版。这套选择还有一个隐藏收益部署极其简单。因为不依赖外部服务我把它跑在一台低配的迷你主机上局域网内任何设备都能打开页面访问。后来给几位朋友试用时我直接复制了一个 SQLite 文件过去他们本地跑起来就是完整应用省掉了所有环境配置问题。3.2 数据表设计与记录链路核心数据结构其实只有两张表。第一张是分类表字段包括 id、名称、颜色、是否启用第二张是记录表字段包括 id、分类 id、开始时间、结束时间、备注、补录标记。很多自带计时功能的工具会要求你一直开着计时器我第一版就放弃了这种设计因为我知道自己百分之百会忘。所以记录链路被设计成两种模式一种是临时记录点一下开始再点一下结束系统自动记录间隔另一种是手动补录如果你忘了开就点一下添加记录手动选择时间段和分类。这样设计的好处是容错性强。真实使用场景里必然会有忘记开始计时、中途被打断、回来已经发现过了两个小时这些情况。补录模式让数据不会因为操作失误就缺失这是我觉得整个设计里最有价值的一点。记录接口设计得也很简单一个 POST 请求JSON 里带分类 id 和起止时间后端直接插入数据库返回最新记录的 id前端借助这个 id 做本地缓存方便撤销操作。自动分类这个功能我在正式版里还是做了因为手动分类用久之后的痛点很明确每三秒钟一次记录还好但每天十几条记录逐条选分类很烦。实现方式一点也不高级就是做一个关键词规则库存到本地 JSON 文件里每条规则包括关键词和分类 id记录保存时先根据备注内容自动预填分类如果不匹配再走手动选择。我后来给它加了两个改进一是分类可以配置相近的多个关键词二是用户手动修正过的分类和备注输入会被记录成一条新的规则建议我会定期审核。这个逻辑让我在用一个多月后自动预填的准确率大概到了七成剩下一成手动修正还有两成是因为我偷懒没写备注自动区分不了。3.3 可视化与复盘闭环如果说记录是输入那可视化就是输出。我见过不少时间管理工具的界面设计得很花哨但真正能让人坚持看下去的其实就两个视图今天的时间轴和这一周的趋势图。时间轴用色块展示每个时间段去了哪个分类一眼就能看出早上那段集中时间是被哪个任务占掉的趋势图统计每一天里核心工作沟通消遣这三类时间的总时长折线变化非常直观。为了促进复盘闭环我还在页面底部放了一行今日提示逻辑很简单如果核心工作时间小于四小时就显示那句今天核心时间只有xx建议明天上午优先安排最重要的事如果某天的碎片时间占比超过百分之五十就显示碎片时间占比过半是不是应该关掉几个通知。这行字不复杂但它是把数据转化成行动的关键。很多工具只负责记录和展示没有给出下一步建议所以使用者看着数据也不知道该怎么办。哪怕只是这么一句规则化的提示也比什么都没给强。整个核心实现部分的周期大概是一周。前三天做数据表、接口、记录页面中间两天做统计页面和图表最后两天补手动补录功能和自动分类规则。这个速度主要受益于提前砍功能而不是因为我写的速度快。4. 真实测试与迭代优化4.1 第一批使用者从哪里来第一版跑通后我并没有马上发布到公开社区而是找了四个不同背景的人做小范围测试一个忙于多项目切换的设计师、一个每天大量会议的产品经理、一个还在读书的研究生、加上我自己。我不是让他们随便看看而是给了每人一个简单任务他们自己在真实工作里记录两天有强烈的感受时记录下来不舒服的地方也记录下来。这个方式比开放式问卷调查有效得多。作为数据收集者,我每天会看他们的使用记录这里有个细节我会重点关注他们有没有在某个环节停顿超过十秒停顿往往意味着界面不清楚或者操作路径太长。比如设计师朋友第一次使用时在分类选择页面停了好几秒后来他告诉我他看到分类列表里有些词他完全不理解不知道发散这个分类是干什么的。这说明我预设的分类体系有问题每个人的心智模型是不一样的后来我把分类改成他自己的叫法构思、执行、讨论、杂事。4.2 反馈收集表怎么设计不跑偏给早期用户收集反馈时我建议不要用那种大而全的满意度问卷而是用一张非常简单的记录表主题只有三个问题。第一你在这个工具里做得最多的一个动作是什么第二你因为找不到某个功能而放弃使用的瞬间是什么第三如果只允许加一个功能你加什么。这三个问题分别对应行为习惯、阻断点和真实需求比问你喜不喜欢靠谱很多。我把收集到的反馈按频率和影响程度整理成一个四象限表格横坐标是出现频率纵坐标是影响程度。右上角是高频且影响大的必须立刻处理左上角低频但影响大也不能忽略右下角高频但影响小可以低成本优化左下角直接放弃。这个表格帮我把好几个看起来都不错的需求排出了先后顺序。比如有人提出要做手机端推送出现频率不高且影响不大我直接搁置但忘记记录后补录流程太深这个反馈出现了三次且每次都会让人烦躁我就优先优化。事实证明这比凭感觉做功能靠谱得多因为感觉会偏向你觉得有趣的技术问题而表格会强迫你看用户真正遇到的事情。4.3 三轮迭代的真实记录基于反馈我在之后一个月做了三轮比较关键的迭代。第一轮是把分类选择从浏览列表改成输入即搜索。原来十来个分类已经不算多但用键盘操作时还是要在列表里找半天改成输入首字母或者关键词直接筛选之后单次记录时间缩短到五秒以内这个改动来自我自己的高频操作也来自产品经理朋友的一句话我打字比你列表还快。第二轮是针对补录流程的优化。原来的补录要打开一个专门页面依次选日期、时间、分类、备注操作路径太长。后来我在首页加了一个随手记区域默认显示当前时间如果你想补录只需要把结束时间改成实际结束时间即可。很多人会把时间想当然地填现在的时刻所以我加了时间合理性提示如果结束时间距离现在超过四小时就弹一个二次确认框避免大量误录。这个细节来自我自己多次误录后的教训也来自研究生朋友反馈我以为我补了结果时间全堆在晚上十点。第三轮是增加了周报功能。周报不是那种做得很复杂的 PDF 导出而是每周日晚九点在本地生成一个 HTML 页面汇总这一周每天的核心工作时间、被打断次数和高频分类。生成逻辑用了最朴素的方式js 在页面端读数据模板插值直接展示在网页里。当页面打开时如果你有任何一个分类的数据就会显示这一周你有五天核心工作时间低于三小时周二例外因为那天的会议被取消了。周报的价值在于它把零散的数据整合成一段可理解的故事不然我很难说服自己去看一周前那些拥挤的时间轴。这个功能做出来后我自己的回访频率从每周一次变成了每天一次因为看到趋势数据之后人会本能地希望明天那个曲线能好看一点这种自我驱动的反馈闭环才是工具最值钱的部分。5. 常见问题与避坑手册5.1 最想劝你别踩的五个坑第一个坑是陷入无休止的功能加码。我在第一版开始后大概两周时突然冒出一个想法觉得可以做一个AI 自动生成每日总结的功能当时觉得特别酷马上去查资料准备动工。结果一个做产品的朋友拦住了我他问了我一句话你现在核心链路稳定了吗每天都有数据进来吗如果没有AI 总结出来的东西给谁看。我冷静下来想了想当时连续记录了大约十一天其中有三天因为出差中断数据量根本不够支撑任何有意义的总结。于是我把这个想法写进了 backlog上面标注至少累计 90 天数据后再启动评估。这个坑的本质是太容易被新想法驱动解决办法是给所有后补功能设一个数据门槛或时间门槛到点了再考虑没到点就让它安静待在清单里。第二个坑是在分类体系上过度设计。我第一版预设了十几个分类什么深度工作、创意发散、沟通协调、日常维护、学习充电、健康管理看上去很严谨但实际使用时发现大部分人根本不会记得去精确归类反而会因为分类太复杂而放弃记录。后来我直接砍到五六个大类甚至允许用户只用一个干活和杂事的二分法起步。分类的价值在于方便统计不在于见鬼的合理性越简单越好。第三个坑是忘了设计遗忘容错。第一次做记录工具时我总是假设用户会老老实实看到每个弹窗、每个按钮。但如果你记录过自己三天的实际使用你会发现有大量的误操作和遗忘。所以后来每个可能产生严重后果的操作比如删除一条记录、修改一个时间我都做了一步撤销机制。这个机制不复杂前端缓存上一个状态后端留 recovery 接口但它在实际使用中救了我不下十次。第四个坑是复盘的路径太长。很多工具的统计页面藏在三级菜单层级里你需要打开应用、点进数据、再选日期范围才能看到昨日情况。这完全是反人性的。如果统计不能在你打开应用的第一屏就看到它就不会被回看。我把统计页直接放在默认主页打开应用就是昨天和今天的时间分布一周趋势图挂在下面需要滚动才能看到但至少不用点任何按钮。回看率立刻不一样了。第五个坑是不敢给自己下一个结论。项目做到后面遇到最多的问题不是技术而是我怎么确认我的工具真的有用。这个需要给自己设定一个非常非常傻的指标。我的指标就是连续使用天数。最初目标 7 天后来 14 天再到 30 天。当你在第 32 天打开应用时统计页告诉你过去的 31 天里你平均每天记录 8.2 条那一刻你不需要问任何人这东西已经证明了自己的存在意义。5.2 适合随身携带的一页纸决策清单我可以分享一张总结好的决策清单它其实是一页纸但比很多超过十页的需求文档都更有效。我每次启动项目前都会照着它走一遍。这张清单长这样第一行是我最相信什么写你的核心信念或判断第二行是我要服务的最小人群是谁写一个人名即可第三行是他要解决的事用一句话怎么讲必须是一句话不能是两句话第四行是现在是什么替代方案第五行是我和替代方案最大的差异点在哪第六行是第一版最小闭环是什么第七行是我能用多久验证它第八行是做出来后我拿什么指标判断成没成。这八个问题每一个都必须写到你能在别人面前大声说出来而不心虚的程度做不到就把想法放回备忘录再说。这张清单的最大作用是逼你在动手前做一次完整的理性推演。做时间记录工具时我的第一行写的是人们严重低估自己一天中的碎片时间最后一行写的是连续使用三十天且每天打开至少一次。正是因为有了第 30 天的那个指标我在做到第 20 天想放弃时还能撑下来。很多时候项目不再不知道干吗的不是因为想通了什么高深道理而是因为那些不明确的部分在你写决策清单的过程中被你一个个消灭了。6. 从不知道干吗的到我舍不得删掉的日常工具现在回头讲这个项目我必须承认它最后的样子和最初的想象差了不少。最初我满脑子想的是做一些很复杂的事情比如自动分析所有应用的使用情况、自动判断你是在深度工作还是摸鱼甚至做一个能语音记录的版本。但最终活下来的就是一个足够简单、足够快、把数据留在本地的记录工具。我现在每天早上打开它看一眼昨天的数据顺手把今天要重点做的事在备注里写一句晚上看一眼时间轴然后关掉页面。这个动作已经变成了习惯比之前没有任何记录、全靠脑子回忆的状态要从容很多。我做内容总结时经常会对朋友说那些看上去不知道干吗的想法里往往藏着一个最真实的日常需求。问题只是你愿不愿意沉淀下来问自己那八个问题愿不愿意砍掉那个看起来很酷却搭不上主链路的功能愿不愿意老老实实连续使用两周看真实数据。你自己用过、坚持过、踩过坑之后本质上就不会再有不知道干吗的了。