小真的开发日记，记录的是一个小型任务管理工具从想法落地到持续迭代的过程。我把它叫作“轻记”：用户可以快速记下一件待办、设置截止时间、标记完成，也能按状态筛选任务。项目不追求功能铺满，而是围绕“打开后能不能马上记、之后能不能找回来”展开。开发中的取舍、踩过的坑和每天的复盘，都比单纯贴出代码更能说明一个项目是怎样逐步成形的。
从一个真实麻烦开始
最初的需求来自我自己的日常：临时想到的事情散落在聊天窗口、便签和脑子里，忙起来就忘了处理。我先观察自己一天中什么时候会记录、什么时候会回看，再把需求缩成三个动作：新增任务、调整任务状态、查找未完成任务。提醒、标签、统计图表暂时不做。把边界划小之后，项目从“做一个什么都有的应用”变成了一个可以完成、可以验证的工具。
我把需求写成具体场景，而不是只列抽象功能。比如，用户在首页输入“给客户回邮件”，按下回车后，任务立即出现在待办列表；用户点选完成状态，条目从未完成视图消失，但仍能在已完成列表中找到。每个场景都对应一次操作和一个可观察结果。这样拆解后，设计界面时不容易陷入“这个按钮看起来不错，要不要也加上”的随意扩张。
先定数据，再搭界面
轻记的任务记录包含标题、状态、创建时间、截止时间和更新时间。标题不能为空，状态只允许“待办”与“完成”两种，截止时间可以留空。字段不多，却足以支撑首版流程。我用SQLite保存数据，让本地开发和测试都能围绕同一套结构进行；前端以Vue和TypeScript组织页面及状态，服务端提供创建、查询、更新和删除任务的接口。
接口设计时，我先让每个动作的输入和结果保持清楚。创建任务只接收标题与可选截止时间，服务端补上初始状态和时间字段；更新状态时只修改状态与更新时间，不把整条记录重新写一遍。列表查询支持按状态筛选，并按照截止时间和创建时间排序。看似细小的约定，后来帮助我避免了前端和数据库对字段含义各自理解的情况。
界面第一版只保留输入框、任务列表和状态切换。新增任务成功后，输入框清空并把焦点留在原处，方便连续记录；没有任务时显示简短提示，而不是留下大片空白；保存失败时保留用户刚输入的文字，并给出可读的错误说明。这些细节没有增加复杂功能，却让核心操作连贯许多。
开发过程里的卡点
第一次串起前后端时，我遇到的不是复杂算法，而是任务状态更新后列表没有同步。接口返回成功，数据库里的值也改变了，屏幕上的旧条目却还留在原位。排查时我先确认请求地址和响应字段，再检查前端是否使用了正确的任务标识，最后发现列表更新逻辑比较的是标题，而标题并不唯一。把稳定的记录标识用于更新后，问题才真正消失。
这次排错让我意识到，界面显示正确不等于数据关系正确。后来我给任务记录建立独立标识，并让新增、修改和删除操作都围绕它进行。测试时，我专门创建了标题相同的多条任务，确认切换其中一条不会误改其他记录。这个案例也进入了我的复盘：遇到“数据看起来差不多”的问题时，先检查对象身份和关联条件，不要急着在界面上补临时判断。
另一个问题出现在空标题处理上。前端禁用了空白输入的提交按钮，但直接调用接口仍能创建无效记录。于是我把校验放在两端：界面即时提示，服务端再次拒绝空标题，并返回明确错误。前端负责让操作顺手，服务端负责守住数据规则，两者不能互相替代。补上这层约束后，异常输入不再污染任务列表。
重构让变化更容易
功能增加后，首页组件开始同时负责输入校验、接口请求、列表筛选和状态展示，改一个小地方也要反复检查整段逻辑。我把任务表单、列表项和筛选栏拆开，再把请求调用集中到单独模块。拆分不是为了追求文件数量，而是让每个部分有清楚职责：表单处理输入，列表项呈现单条任务，数据模块负责与服务端通信。
重构过程中我没有一次性改完所有代码，而是先移动逻辑，再运行新增、修改、筛选等核心流程。每完成一处，就确认行为没有变化。对独立开发的小项目来说，重构也要服务于实际迭代：当新增需求总要同时修改多处重复代码，或者一个组件承担了太多工作时，再寻找合适的边界，比为了“看起来规范”提前搭出复杂架构更稳妥。
让项目经得起日常使用
主要功能完成后，我用不同顺序反复操作：先新增再完成，先筛选再修改，删除后刷新页面，再创建标题相同的任务。我还检查了列表为空、标题很长、截止时间缺失以及服务端暂时不可用等情况。测试不只是确认正常路径能走通，也要观察出错后用户能否理解发生了什么，已输入的内容是否还在，下一步是否明确。
我把轻记放进自己的日常安排里使用一段时间。实际使用很快暴露出几处设计问题：已完成任务太多时，待办列表容易被挤开；截止时间只显示日期，临近任务不够醒目；提交后缺少反馈时，我会误以为按钮没有生效。于是我调整列表默认筛选，为即将到期的任务增加视觉提示，并在保存成功后显示轻量反馈。每项改动都来自真实操作，而不是为了让功能表看起来更多。
小真的每日复盘
每天收工前，我会在小真的开发日记里留下几句记录：今天完成了什么，在哪一步卡住，问题最终因为什么解决，明天最值得先做的事情是什么。复盘尽量写成可复用的结论，例如“状态更新必须使用任务标识”，而不是只写“今天改了列表”。前者能帮助未来的自己少走弯路，后者通常只是一份流水账。
我也会把未完成的工作拆成清晰动作。与其记“优化筛选”，不如记“让已完成筛选保留截止时间排序，并补测空列表状态”。任务越具体，第二天越容易重新进入上下文。若当天遇到绕路，我会记录尝试过的办法及其结果，这样下次碰到相似故障，可以先避开已经证明无效的方向。
回看整个过程，轻记并不是靠一次完整规划直接做出来的。它先从一个具体麻烦起步，再经过需求取舍、数据建模、交互实现、排错、重构和实际使用，一点点变得可靠。小真的开发日记想留下的，正是这些能解释“为什么这样做”的过程：功能可以继续增长，代码也会继续变化，但每次迭代都应该让真实任务更容易完成。
