2026年8月30日
把完成改成可以放心交付
今天重新理解了“做完”这两个字。代码能够运行，只说明最明显的一段路走通了。真正可以放心交付，还要检查空数据、旧数据、异常退出和不同屏幕尺寸。以前我常把这些当作收尾，现在更愿意把它们看成开发本身。
把检查清单写下来以后，心里反而轻松。记忆会遗漏，流程不会。一个稳定的小习惯，比临时的认真更可靠。
2026年8月27日
页面应该先回答一个问题
做页面时很容易不断添加信息，觉得越丰富越有价值。今天尝试反过来问：用户来到这里，最先想知道什么？如果第一眼没有答案，再漂亮的装饰也只是噪声。
我删掉了几处重复说明，留下更明确的标题和操作。空白变多以后，页面没有显得单薄，反而更容易理解。
2026年8月24日
为错误写一句人能看懂的话
系统内部的错误信息通常很准确，却不一定适合直接展示。用户真正需要知道的是发生了什么、数据是否安全、下一步能做什么。今天把几段生硬的提示重新写了一遍，也补上了成功后的明确反馈。
好的提示不应该责怪使用者。它像路标一样，安静地告诉人下一步往哪里走。
2026年8月21日
浅色界面并不等于一片白
我曾经以为浅色模式只要亮度足够就可以。实际调整时才发现，纯白太多会让层级消失，也容易疲劳。暖灰、纸白和很轻的边线，能在不抢注意力的情况下分开内容。
颜色的价值不只是好看。它还承担顺序、状态和距离感。越克制的界面，越需要认真处理这些细微差别。
2026年8月18日
动效只为解释变化
今天删掉了一个看起来很顺滑的动画。它虽然吸引目光，却让一次简单切换显得拖沓。保留下来的动效只负责解释内容从哪里来、到哪里去，不再为了证明页面会动。
当动效结束后，使用者应该更明白当前状态，而不是只记得刚才闪过了什么。
2026年8月15日
给按钮留出犹豫的时间
删除、覆盖和清空数据都不应该显得太轻巧。今天重新整理了几个危险操作，把结果说明放在确认之前，并让默认选择更保守。确认框不是越多越安全，关键是出现在真正不可逆的地方。
设计不仅帮助人快速完成事情，也应该在必要时让人慢半步。
2026年8月12日
旧设备提醒我保持节制
同一个页面在性能较弱的设备上运行，暴露出不少问题。模糊效果、阴影和同时出现的动画累积起来，会让滚动变得迟钝。逐项减少以后，视觉变化不大，操作却明显轻快。
性能优化常常不是增加复杂技巧，而是诚实地判断哪些东西其实不需要。
2026年8月9日
先画数据流再写代码
遇到同步问题时，我过去习惯立刻去改某个函数。今天先用纸画出数据从输入、保存、上传到恢复的完整路线，才发现真正遗漏的是中间一个状态，而不是最后显示的页面。
图画得很简单，却减少了许多猜测。复杂问题如果不能用几句话说清，往往说明我还没有真正理解它。
2026年8月6日
默认值也是一种承诺
新建记录时自动出现的每一个数字，都会悄悄影响后续使用。今天检查默认值，发现有些只是开发阶段为了方便测试留下的。它们一旦进入真实数据，就会变成难以解释的历史。
默认值应该代表最常见且最安全的选择，而不是编写代码时最省事的选择。
2026年8月3日
数据迁移不能只看数量
一次导入显示记录数量相同，并不代表内容完全正确。日期可能偏移，关联关系可能断开，空字段也可能被替换成错误的默认值。今天逐层核对了读取、转换、写入和再次读取的结果。
迁移最重要的不是让程序说成功，而是让旧数据在新环境里仍然表达原来的含义。
2026年7月31日
日历不是一排整齐的格子
日历页面最难处理的不是画出日期，而是让月份切换、今天、选中日期和已有记录同时清楚。今天试了几种强调方式，最后只保留一个主色，其余状态用字重和明暗区分。
当所有信息都在争夺注意力时，没有任何信息真正突出。层级来自取舍。
2026年7月28日
空页面也应该有方向
没有记录时，页面不能只留下大片空白，也不必堆很多解释。我尝试用一句简短说明配合一个明确入口，让人知道这里未来会出现什么，以及现在可以做什么。
空状态不是错误，它是许多人第一次打开页面时的正常状态。
2026年7月25日
一次只改一个变量
调整间距时，我一口气改了字号、卡片宽度和行高，结果无法判断哪一项真正改善了阅读。恢复后重新一次只改一处，过程虽然慢一些，结论却更可靠。
这也适用于排查错误。控制变量是一种朴素但有效的耐心。
2026年7月22日
测试最容易忽略熟悉的路径
每天都在使用的入口，我反而默认它不会出错。今天从第一次安装开始重新走了一遍，发现一个只在无历史数据时出现的问题。熟悉会让人自动补全缺失的信息，也会遮住真实体验。
偶尔把自己当成第一次使用的人，是很困难也很有价值的练习。
2026年7月19日
修复之后再寻找残留
移除一个旧功能，不只是把按钮藏起来。相关字段、保存逻辑、备份结构和提示文字都可能仍然存在。今天用全局搜索列出所有入口，再沿着数据路径逐一确认。
真正的删除需要完整，也需要保留必要的恢复能力。两者并不矛盾。
2026年7月16日
命名是在替未来的自己写说明
一个变量在编写时当然很清楚，几周以后却未必。今天整理了一组含义模糊的名字，尽量让它们描述事实，而不是描述当时采用的实现方式。
好名字不能替代文档，但能减少误解。代码被阅读的次数，通常远多于被编写的次数。
2026年7月13日
先保存，再尝试大胆修改
视觉调整常需要反复尝试，但生产环境不适合凭感觉覆盖。今天养成了先保存当前版本、记录修改时间，再部署新内容的步骤。这样即使结果不理想，也能迅速回到稳定状态。
备份不是因为缺乏信心，而是为探索留出余地。
2026年7月10日
文字也是界面的一部分
同一个功能，用词不同会让人的判断完全不同。“确定”过于含糊，“保存修改”则清楚得多。今天检查按钮和提示语，尽量使用具体动作，避免让人猜测点击后的结果。
界面文字越短，越要准确。少一个字不一定更简洁，有时只是少了一条必要的信息。
2026年7月7日
把大任务拆成可验证的小步
面对一整页重做时，很容易在许多细节之间来回跳。今天先完成最小的结构，再逐步补充内容、交互和异常状态。每一步都有可以观察的结果，也更容易发现偏离目标的地方。
拆分不是把目标变小，而是让前进的方向始终可见。
2026年7月4日
从记录问题开始
这是第一篇开发手记。我想把那些没有写进正式说明里的过程留下来：一个页面为什么重做，一次错误怎样被发现，以及哪些看似漂亮的想法最后被放弃。
开发并不是持续得到正确答案。更多时候，是逐渐学会提出更具体的问题，并愿意回头修正昨天的判断。