你正在排查一个偶发的登录问题。手里有一张截图、一条测试反馈，还有几个可能的原因。这时，可以先创建一个任务：“排查长时间离开后出现的登录失败”。这个问题，已经足够让相关记录有一个明确的去处。
从任务开始记笔记，就是把观察、尝试和决定，留在它们帮助推进的工作里。下面使用一个虚构的排查案例，展示同一份笔记如何逐渐形成。案例中的现象和修复方案均为演示，不是 TodoNote 的实际故障记录。
先写问题，再写怎样才算完成
第一份记录只需要说明正在调查什么，以及什么结果能让工作结束。原因、任务拆分和长期分类，都可以随着调查逐渐明确。
排查长时间离开后出现的登录失败
反馈：测试人员第二天回到一直打开的标签页，第一次请求失败，重新登录后恢复。
还不清楚：是否与浏览器、离开时间或账号有关？
完成条件：能复现问题、说明原因，并用失败场景验证修复。
下一步：询问大约离开了多久，以及标签页是否一直打开。
完成条件为调查划出了边界。每看到一份资料，都可以问：它能否帮助回答这个问题，或决定下一次要验证什么？没有关系的材料可以暂时放下。
先记发生了什么，再判断原因
第二天，你已经试了几个条件。此时要区分观察和解释：“标签页放置一夜后失败”是观察；“浏览器缓存坏了”只是猜测。如果两者都被记成事实，后续排查就容易沿着错误方向继续。
排查长时间离开后出现的登录失败
- 刚登录：第一次请求成功。
- 标签页放置一夜：在测试环境中，第一次请求失败。
- 当前猜测：页面可能仍在使用过期的会话状态，尚未确认。
- 下一次验证：检查失败请求与会话的时间记录。链接到受限的诊断记录，不把登录凭证复制进笔记。
能够排除某种解释的失败尝试，也值得留下。把结果写在尝试旁边，下次就能知道为什么没有继续沿这条路查，而不用重新做一遍。
把缺失的答案变成下一步
现在，“检查会话过期后的处理”已经是一项明确的工作。在 TodoNote 中，可以为它创建子任务，把调查背景继续留在父任务的笔记里。子任务的完成条件是：复现会话过期后的失败，并记录应用如何处理。
需要单独安排时间、跟踪进展的验证，适合拆成任务。一条简单观察则可以继续留在正文里。这样既能看见未完成的工作，也不会让任务列表膨胀成每个细节的清单。
排查长时间离开后出现的登录失败
发现：在这个例子里，页面重复使用过期会话状态，请求失败后没有恢复。
修改：遇到该响应时清理失效状态，并返回登录流程。
验证：重跑过期会话场景，再检查有效会话仍能正常使用。记录测试版本，并链接测试结果。
尚未完成：还要在另一种浏览器验证同一路径，目前不能写成已经覆盖。
结果有了价值，再决定放进哪个主题
此时，笔记里已经有了可复用的解释，可以添加“身份认证”之类的标签。调查刚开始时，还不确定它属于账号、浏览器还是会话问题；延后分类，让整理建立在已经验证的结果上。
保留结论时，也保留原始观察。关于如何选择值得长期留下的内容，可以继续读任务完成后，哪些记录值得整理。
从一件尚不确定的工作试起
这种方法适合调查、提案、研究和写作：理解会随着工作推进而改变。日常提醒可能只需要标题和日期；已经完整成形的参考手册，可以继续放在文档库里。
问题：我想解决什么？
完成条件：得到什么结果，就可以结束？
已经知道：观察及其来源。
还要确认：假设和未解决的问题。
下一步：哪一步能减少当前的不确定性？