WeekToDo 是一款极简的周计划工具，界面干净、本地存储、注重隐私。特别改造版，增加了数据同步和AI总结功能（详见https://alberf.cn/archives/AI-weektodo.html），但用久了会发现几个不够顺手或不习惯的地方：
- 待办事项只有「完成 / 未完成」，看不到一项任务到底耗了多久
- 上周没做完的任务自动来到本周，用户却不知道它是「新任务」还是「遗留任务」
- 一天的任务混在一起，上午要做的事和下午要做的事没有区分
- 内置的打印功能会打印整个页面，而不是用户真正关心的「当前这一周」
于是我决定在原有代码基础上做一轮个性化改造，保留它极简的气质，同时补齐这些细节。
让时间「可被看见」
初衷
待办工具最核心的价值不是「记住要做什么」，而是「知道做了多久」。一个任务从开始到完成，中间隔了多长时间，这件事本身是有意义的——它能帮你判断一项任务是不是拖得太久，是不是该拆解，是不是该放弃。
思路
我给每个任务增加了三个时间概念：
起点日期：任务是从哪一天开始算的
起点时刻：这一天从几点开始算
完成时刻：任务是什么时候完成的
有了这三个点，「用时」就自然浮现出来了——从起点到「现在」或「完成时刻」的间隔。
呈现方式
鼠标悬浮任务时，轻量地显示「已耗时 X 小时 / X 天」
打开任务详情，可以看到具体的开始日期、开始时刻、完成时间和总用时
新增一个统计页面，把所有任务汇总起来，支持按日期范围、完成状态、所属列表筛选，也可以按周或按月聚合查看
统计结果可以导出成表格文件，方便进一步分析
取舍
时间显示有「小时」和「天」两种粒度。48 小时以内用小时，超出后自动换成天——因为对于一项长任务来说，「3.2 天」比「77 小时」更容易理解。
区分「拖动」和「迁移」
问题
WeekToDo 有一个很贴心的功能：上周没完成的任务，会自动出现在本周，提醒你「这件事还没做完」。
但问题是，用户手动把一个任务拖到另一天，和系统自动把任务挪到新一天，在程序看来是同一件事——都只是改了「任务属于哪一天」。
两者其实不同
拖动：用户觉得这个任务排期不合理，想换个日子。这时「计时起点」应该跟着改。
迁移：任务一直没完成，继续往后拖。这时「计时起点」不应该改——否则用户永远看不到这项任务真正拖了多久。
解决方式
我引入了一个「起点锚定」的概念：不管任务被挪到哪一天，它的用时起点可以独立保留。
系统迁移时，起点不动
用户拖动时，弹一个小窗询问：「是否把开始日期也改成新日期？」
这样既尊重了用户的意图，又保住了长任务的「真实年龄」。
让「遗留任务」被看见
初衷
一个任务被迁移了好几次，用户其实很难察觉。列表里它和别的任务长得一模一样，只有用心看日期才会发现「咦，这不是上周的吗？」
思路
给每个被迁移过的任务打一个来源标记：它最初是从哪一天来的。
这个标记一旦写下，就不再改变——即使任务又被迁移了好几次，用户看到的还是「它最初来自哪一天」，而不是「它昨天从哪来」。
呈现方式
列表里显示一个小小的紫色箭头图标，鼠标移上去能看到来源日期
统计页增加「迁移来源」列和「迁移筛选」，一眼能看出哪些是遗留任务
生成周总结时，AI 会单独用一段来分析这些遗留任务，给出拆解、放弃或委托的建议
上午和下午的划分
初衷
一天的任务全堆在一起，上午该干什么、下午该干什么，没有视觉上的区分。但很多人的工作节奏天然是分段的：上午处理需要专注的事，下午处理沟通协调类的事。
思路
以中午 13:00 为界，把每天的任务分成「上午」和「下午」两组：
上午标签用琥珀色，下午标签用靛蓝色，中间用横线分隔
分组仅对「日期列表」生效，自定义列表（如购物清单、想法清单）保持原样
如果某个时段没有任务，那一组的标签也不会显示，避免视觉噪音
新建任务时自动归类
用户新建任务时，系统会根据「当前时间」自动判断该分到上午还是下午：
上午创建 → 归入上午
下午创建 → 归入下午
同时，如果用户给任务设置了具体的计划时间（比如下午 4 点），用时起点会自动采用这个时间，保证语义一致。
打印体验的优化
问题
原来的打印功能会打印整个页面——侧边栏、自定义列表、周总结，全部都会印出来。但用户真正想打印的，往往只是「这一周要做的事」。
思路
与其用样式隐藏页面上不想打印的部分，不如在打印那一刻，临时生成一份只包含当前周的简洁清单，打印完再销毁。
这样打印的内容是独立的、干净的，不受当前页面布局的影响。
呈现方式
按 A4 横版排版
一周 7 天，每天一列
每一天的标题用大字写「周几」，下面用很小的灰字写「几月几日」
已完成的任务带删除线，未完成的保持原样
有任务时间的话，用小标签标出来
数据同步与部署
同步
WeekToDo 本身支持把数据同步到 S3 兼容的云存储。我在几个数据变化的节点上（编辑用时起点、拖动、完成任务等）接入了自动推送，让改动能及时上传。同时设置页里也保留了一个「立即同步」按钮，方便用户手动触发。
部署
原本项目提供了 Docker 配置，但 docker-compose.yml 只引用了一个远程镜像，不会根据本地代码重新构建。所以正确的更新方式是：
改完代码后，手动用 Dockerfile 构建本地镜像
在 docker-compose.yml 里把镜像地址指向本地构建的版本
重启容器
如果想快速看到效果，用项目自带的开发服务器 yarn run serve 更合适——它支持热重载，改完代码浏览器会自动刷新，省去每次构建镜像的时间。
一些设计上的取舍
这次改造里有几个决定，值得单独说一下：
- 为什么废弃了「创建时间」这个字段？
因为它和「起点日期」「起点时刻」的语义重叠了。与其维护三个含义模糊的时间字段，不如只保留两个含义清晰的——一个管日期，一个管时刻。 - 为什么迁移来源只记第一次？
因为它回答的是「这项任务最初是哪天的」，而不是「它昨天从哪来」。用户关心的是它拖了多久，而不是它被拖过几次。 - 为什么上午/下午不做成可配置？
配置项越多，用户越容易迷失。13:00 是一个符合大多数人工作习惯的分界点，先用这个默认值，如果将来真的有需求，再考虑做成选项。 - 为什么打印不用 CSS 隐藏？
因为页面结构复杂，很难保证「只打印当前周」的样式在所有浏览器下都一致。动态生成内容更可控，也更容易维护。
写在最后
WeekToDo 的原始设计已经非常克制和优雅。这次改造的目标不是让它变得「功能更多」，而是让它更贴合个人的使用习惯——看见时间、看见遗留、看见节奏。
如果你也在用 WeekToDo，希望这些思路对你有启发。改造后的代码仍然保持开源精神，所有改动都在原有架构内完成，没有引入额外的依赖。
工具最终是为了服务于人，而不是相反。
Comments | NOTHING