棕榈大道1. 项目起底：Easy Vibe Task3 到底在做什么
1.1 一个“easy”但又不简单的挑战
先说说这个项目是怎么来的。我一直在做一个系列化的个人项目练习，前两关分别做了静态页面和交互原型，等到了第三关的时候，题目只给了一个非常宽泛的方向：要做一个“简单、好用、有氛围感”的小工具，而且明确要求时间不能拖太长，三五天之内要出东西。
“Easy Vibe Task3”这个名字，其实是我自己起的代号。Easy 指的是技术方案和交互逻辑不能绕弯子，要让一个完全没有技术背景的人也能上手；Vibe 指的是整个产品用起来要有“氛围感”，不是冷冰冰的功能罗列，而是打开之后让人愿意多停留一会儿、用起来顺手顺心；Task3 则是系列任务的第三关，意味着前面积累的经验可以沉淀下来。
这个项目最终做出来的，是一个“个人任务看板”网页工具。它可以用来管理每天要做的几件事、标记优先级、记录完成状态，并且支持简单的数据保存。听起来挺普通的对吧？但真正难的地方不在功能多强大，而在于“Easy”和“Vibe”这两个词背后的隐性要求：界面不能花里胡哨，操作不能有学习成本，打开浏览器就能用，关掉再打开数据还在。
我这篇文章就把这个项目从构思到落地、从踩坑到优化的完整过程拆开来讲。如果你也想做一个轻量级的小工具，或者手里正好有一个“第三关”类型的任务不知道从哪下手，这篇文章应该能给你几条可以直接用的思路。
1.2 为什么叫“vibe”——体验感是如何被量化的
“氛围感”这个词听起来很虚，但落到产品里其实是能被拆解的。我做这个项目的时候，把 Vibe 拆成了三个可衡量的指标：
第一个是启动成本。从用户打开页面到完成第一次操作，中间最多只能有一次点击。如果用户要研究半天才知道按钮在哪，氛围感就没了。第二个是视觉噪音。页面上同时出现的元素不能超过七个，颜色不能超过三种，字体最多两个字号，超过这个数值，眼睛就会觉得累。第三个是反馈延迟。每个操作之后，无论是按钮按下的效果、状态切换的动画，还是数据保存的提示，都必须在 300 毫秒内给出反馈，否则用户会觉得“卡”。
这三条标准听起来简单，实际做的时候会发现它们之间是有冲突的。比如为了减少视觉噪音，就不能放一堆功能按钮；但功能少了又怕不实用。为了解决这个矛盾，我最后采用了一个方案：默认界面上只放最核心的“输入”和“展示”两个区域，其余功能通过右键菜单或者快捷键调出，随时出现、用完即走。
这样就把“氛围感”从玄学变成了工程问题，每做一步都能对照标准检查，而不是靠感觉瞎调。这也是我特别想分享的一个点：任何看起来主观的设计目标，只要愿意拆，都能变成可以执行、可以验证的具体规则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型：如何在简单与体验之间找到平衡点
2.1 我为什么没有一上来就上重型框架
拿到这个任务的时候，我的第一反应是：既然要做任务管理，那直接用 React 或者 Vue 加一套 UI 组件库，两天就能拼出来。但冷静下来一想，这个选择有问题。
问题的核心在于“Easy”这个前提。重型框架意味着需要 Node.js 环境、依赖安装、构建步骤，甚至部署的时候还要考虑路由配置和静态资源路径。如果这个工具最终只是给自己用，或者分享给朋友打开即用，那么任何需要“先安装再运行”的步骤都是额外的负担。
所以我把技术栈直接砍到了最底层：纯 HTML、CSS