大家好，我是 DOM哥。
转眼毕业已经北漂十年了，过得真快啊。
刚工作两年的时候我就萌生了做一个任务管理器的想法。
刚开始做出来的时候它是这样式的：
你别看它丑，但它真能用啊，CRUD不在话下，符合第一性原理🤪
后来在实际工作中，十年间兜兜转转呆过不少团队，每个团队用的任务管理工具迥异。有
基本上换个团队就要适应一个新的任务管理系统。
实际体验下来，没有一个让我有长期使用的欲望。原因主要有：
最近入职了新公司，我又翻出了自己的这个老项目。这一次，我想不如用我自己的吧。用了一段时间越用越香，我想何不做成一款产品呢。如果放在以前，这几乎不可能实现，但现在有了 AI 加持，开搞！
先上一张产品效果图吧：
线上 demo 链接 https://task-manager.dombro.site?demo=1
想到即将到来的35岁危机，产品代号就叫 age35
以前只有自己一个人用时，功能就是边用边开发，想到哪写到哪，怎么用怎么写，怎么实用怎么来。但当我开始考虑做成一款对外产品时，就得重新规划整个架构。
这几周忙活下来，我发现真正花时间的并不是技术实现，反而是想清楚"这个产品到底要解决什么问题"。下面就是这几周下来沉淀出的几个核心理念。
所有和这个任务相关的文档都记到这个小卡片上，点开这个小卡片，就是任务的全部上下文。
实际上，实际开发中上面的文档如果组织合理的话，vibe coding 直接给 AI，你将得到一个非常惊喜的结果。
去伪存真，从模型上来讲，状态是任务最最重要的属性，没有之一。
在团队协作中，leader和项目经理最关心的也是任务状态。
当我想通了这一点后，围绕状态如何全链路打通认真设计了一番。最终确定使用全局状态流管理，其他视图的状态流可以自由组装，而不是随心所欲的造状态。最终实现一份任务数据，处处同步。绝不能容忍去维护重复的任务。
最终实现的效果如下：
时间轴
日历
当我改动自己的任务时，可以实时同步进度到leader和项目视角。
妈妈再也不用担心我为了对进度赶地铁去开早会了
除了状态，任务另一个最重要的属性就是排期了。一个实用好用的排期组件能让人在繁杂忙乱的工作中有条不紊，有理有据，游刃有余。
直接上成品：
功能特色：
可以说，这个组件我自己完成的非常满意。
这是一个全栈项目，而我又不想去运维一个服务器（压力太大了🥲），那么不如让用户本地跑吧。
怎么让用户跑起来呢，如果让用户先搭建 pnpm，bun，mongodb 环境恐怕直接劝退，最后 AI 给出了不错的方案：docker一键部署。用户只需要装个 docker 环境就行啦。
✅ 数据完全自主
个人用户数据全在自己电脑的 mongodb 里，团队用户数据全在内网服务器上，一个 bit 也跑不出去。
✅ 快到没朋友
本地起的服务，零延迟
拒绝过度设计，回归任务本质，最终我只为任务模型留下了 5 个字段
实际体验下来，这5个字段足够用了。
优先保证个人用户体验，从一开始就是为个人提效而生的。
虽然我也在努力寻求转化，但我会一直把这个系统对个人用户永久免费，可以任意使用上面的所有功能。
典型场景如
可以说这个功能是我开发这个系统的最初动力。
现在有了 AI，搬砖的能力变得次要，指挥搬砖的能力变得很重要。心中有了蓝图，我开始指挥AI大刀阔斧的重构和实现我的产品逻辑。
我的重构思路是这样地：
好了，现在开始聊天，哦不对，是开始干活！💪
前端从 webpack/vue-cli 全面切到 Vite + Vue 3 + Pinia 的vue最新生态，dev 和 build 的体感都倍儿快倍儿爽。
技术栈升级
------------------ 🧠 prompt ----------------
8年前启动的老项目，当时还是vue-cli + vue2 的时代。
给我把项目的前端技术栈整体重构成最新的vue技术栈，都要 @latest
vue-cli -> vite
vue2 -> vue3
vuex -> pinia
-------------------- Enter -----------------
monorepo改造
通过 monorepo 我要保证两件事：
------------------ 🧠 prompt ----------------
这是个全栈项目，刚开始前端代码和后端代码混在一块，共用 package.json 一大锅依赖，这很不科学
给我重构成合理的全栈项目架构
使用 pnpm workspaces 将项目重新组织为 monorepo 结构，前后端要共享数据结构类型
-------------------- Enter -----------------
服务器老栈是 Node + Koa + Mongoose，这在2018年也是非常时髦的组合了。但现在看来，Koa 的中间件链 + Mongoose 的 schema 维护成本，对一个我业余维护的项目来说太重，ODM 抽象的收益已经被它的心智负担抹平了。
DB 层我要放弃 Mongoose，直接用 mongodb 官方驱动，类型走 db/types.ts，避免 ODM 反复维护 schema 的成本。
技术栈升级和选择
调研了一圈，最终确定用 bun，bun 在我这个项目上有几个实实在在的好处：
package.json 的 devDependencies 直接掉了一半，docker 镜像也跟着瘦了一圈。省省省太省心了！------------------ 🧠 prompt ----------------
给我把后端用以下技术栈重写：
node -> bun
koa -> hono
去掉 mongoose
-------------------- Enter -----------------
在我敲完这几个 Enter 之后，20刀的token额度已用尽😂
我在railway部署了一个线上demo，去看看吧，由于是免费服务器，页面打不打得开看缘分咯
https://task-manager.dombro.site?demo=1
或者
快在本地部署一个吧，享受快如闪电的任务管理⚡️
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。