让工具成为习惯

本周要回答： 一个工具是否好用，最终要看下一次任务发生时，你是否会自然地再次打开它。

进入本周前： P1 已有最小流程和明确范围；能导出、保留和恢复本地数据。

学习内容与理解目标

本周关注日常可用性，而不是继续添加技术层。学习日期、时区、持续时间、全天事件和重复事件的区别；若实现 ICS，选读 iCalendar 的 VEVENT、UID、DTSTART、DTEND 与文本字段规则。先支持一次性事件，再考虑重复规则和时区变化。

格式符合标准与具体客户端的导入体验是两件事。稳定标识并不保证所有日历软件重复导入都会自动更新；需要使用测试日历记录实际行为。不要把本地导出误称为双向同步，也不要为了“无缝”而掩盖删除、更新和重复导入的限制。标准入口见 R33 · IETF RFC 5545：iCalendar。

学习链接与选读范围

实战拆解

1. 完成一周真实但不含敏感名称的个人计划；观察输入、复制、修改、冲突提示和导出是否顺畅。优先修复阻止完成任务的问题，不先做复杂动画。

2. 准备跨天、空标题、非 ASCII 文本、同一时段冲突等合成例子。需要时区时明确日期与时区的来源；无法支持的情况应拒绝或提示，不能静默改时间。

3. 导出一份 ICS 到独立测试日历，检查事件时间、时长、文本以及再次导入后的行为。试完清理测试事件，不直接用主要日历试更新和删除。

4. 加入可控的本地保存、导出和清除入口；明确哪些数据保留在浏览器，哪些是用户主动下载。用网络面板核对是否有不必要上传。

5. 只做一次核心可用性检查：键盘完成新增与导出，窄屏可读，错误不依赖颜色识别。把剩余限制写进说明。

交付与验收

不用代码生成器的练习： 自己修改一条与时间有关的边界规则，先画出时间轴再写测试。解释跨天事件为什么不能只比较小时数字。

隐私与安全检查： 日历标题、地点、参与者与备注可能组合出敏感生活信息。公开样例只用合成事件；本地存储、浏览器同步、系统备份和共享设备也需要考虑。不能仅凭“没有后端”宣称绝无数据痕迹。

落到日常生活： 至少用工具安排一次真实计划，并在下一次修改计划时继续使用。记录阻止复用的首要摩擦；如果现成日历更好，就让自制工具只承担它真正更擅长的输入或导出环节。

过关或补课判断： 实际重复使用且导出边界清楚即可完成 P1 试点。达不到时先删功能与修主流程，不把增加 AI 聊天作为补救。

本周可复制的协作提示

请优先修复本地周计划的实际使用摩擦。需要 ICS 时按标准实现最小字段，并在独立测试日历记录行为。不宣称未测客户端兼容，不把导出称为同步。最后让我独立解释一项时间边界。

本周来源与核对范围

来源编号与核对说明沿用课程原文，基线为 2026-09-27。未逐一登录完成外部实验；实施前请核对最新版本与访问条件。

1. R33
   IETF RFC 5545：iCalendar ↗

   只选事件、时间和标识字段；客户端导入行为另做测试。

2. R35
   W3C WAI：Web Accessibility Tutorials ↗

   选表单标签、页面结构、键盘与反馈。

3. R75
   GOV.UK Service Manual：Moderated usability testing ↗

   选任务观察与记录方法。