隔一段时间回头看当初让 Bobby AI 给的判断，想不起原始问法，也想不起它当时依据的是哪条配置、哪段日志或哪句话，这种记录基本等于没记。可行的做法是把每次提问压成一条短记录，只留四栏：提问时间、原始问法、回答要点、依据来源；再固定一个存放位置和命名规则，让回查靠时间顺序就能翻到，而不是靠记忆去聊天窗口里翻。
留痕的目的是让判断可回查，不是把对话抄一遍。四栏够用：时间、原始问法、回答要点、依据来源；来源写不清时宁可标“未提供”，也不要用事后回想的内容回填。适用于自己或小团队反复问同一类问题的场景，动作是提问后固定补一条，验证方式是隔几周拿旧记录重跑一次依据，风险边界在于来源可能是外部页面或一段对话，记录只能说明当时依据的是什么，不能替代现在重新确认。
设计四栏留痕模板：提问时间、原始问法、回答要点、依据来源
模板要短到愿意每次填，所以字段不做扩展。提问时间写到天即可；原始问法尽量照抄，带上版本号、报错原文和上下文关键词，因为回看时最容易丢的就是“我当时到底怎么问的”；回答要点只留判断和动作，两三行封顶；依据来源指向一个能再次打开的对象，可以是本机文件路径、某条命令的输出、某个页面标题，或者对话里出现的原文片段。
日期: YYYY-MM-DD
原始问法: <照抄提问，含版本/命令/报错原文>
回答要点:
1. <判断>
2. <要执行的动作>
依据来源: <文件路径 / 命令 / 页面标题 / 对话中的原文；没有就写 未提供>下面是一条填写示例，内容按实际环境替换。示例里的“未提供”是有意保留的：Bobby AI 引用了本机配置文件，但没给出外部出处，这一栏就如实写清楚。
日期: YYYY-MM-DD
原始问法: nginx 转发到后端偶发 502，error_log 里有 upstream prematurely closed，先查哪一层？
回答要点:
1. 先看 upstream 超时相关配置与 error_log 时间点是否集中
2. keepalive 相关参数需结合当前版本确认，不能照抄他处配置
依据来源: 对话中引用了本机 /etc/nginx/nginx.conf 的 proxy_read_timeout 行；未给出外部出处，标 未提供填完后做一次自检：只读这四栏，能不能回答“当时为什么这么判断”。如果不能，说明回答要点写得太抽象，需要补一条更具体的动作。风险边界是别把要点扩写成完整分析，字段一长，下一次就不会填了。
选固定存放位置并写清命名规则
存放位置的选择理由很实际：它要能被搜索、能按时间排序、不依赖某个聊天客户端的收藏功能。常见做法是放在随代码或配置一起管理的目录里，例如 notes/ask/，也可以放团队 wiki 的一个固定目录，但不要分散在便签、聊天收藏和截图中，否则回看时先要花时间找记录本身。
命名格式建议把日期放最前，后面跟主题关键词，同一天同主题再加序号。这样 ls 一下就是时间顺序，不需要额外索引。
notes/ask/YYYY-MM-DD-主题关键词.md
notes/ask/YYYY-MM-DD-主题关键词-02.md
# 例
notes/ask/YYYY-MM-DD-nginx-upstream-502.md
notes/ask/YYYY-MM-DD-keepalive-超时-02.md验证方式：执行 ls -1 notes/ask | sort，确认输出顺序与提问时间一致，并且文件名一眼能看出主题。风险边界是主题关键词别用“问题”“请教”“记录”这类词，否则日后靠文件名筛不出来。
拿一条旧记录做核对：来源是否还在、结论是否还成立
核对的价值在于检验留痕是否真的可用于回查，而不是证明当初记得多好。挑一条时间较早、且当时真的照着执行过的记录，按来源类型逐项检查。
- 来源是文件路径：现在打开该文件，确认对应行还在不在，用
grep -n定位行号，必要时用git log -p -- <file>看这一行有没有被改过。 - 来源是命令输出：重新执行同一条命令，比对当前输出与记录的描述是否一致。
- 来源是外部页面或一段对话：打开看是否还能访问；打不开就标“已失效”，不要凭印象补写。
- 判断是否仍成立：如果当前版本、配置或拓扑发生过变化，即使来源还在，原判断也建议重新确认，不能直接沿用。
核对过程本身就写成一小段附在记录末尾，格式如下。状态只允许在“有效 / 依据已变更 / 依据已失效 / 待重新确认”里选，避免写成模糊描述。
核对: YYYY-MM-DD
核对动作: grep -n "proxy_read_timeout" /etc/nginx/nginx.conf
核对结果: 该行仍存在，但取值与记录时不同
状态: 依据已变更，待重新确认这一步的作用是把“当时依据什么”和“现在依据还对不对”分开保存，前者是历史事实，后者是当前判断。核对完把状态写回文件，下次再翻到时不必重做一遍。
标出当时没有写下来源的回答并补记或标记为不可核对
历史记录里一定有一部分来源栏是空的。先把它们找出来，再决定补记还是标记，不要让它们混在可核对记录里。
# 列出有“依据来源”字样但来源为空的行
grep -rn "依据来源" notes/ask/ | grep -E "依据来源: *$"
# 列出主动标为未提供的记录
grep -rn "依据来源: 未提供" notes/ask/
# 列出完全没写这一栏的文件
grep -rLn "依据来源" notes/ask/补记规则要克制：只补现在还能找到、还能验证的东西，例如翻回对话里 AI 引用的原文、当时贴过的配置片段。找不到原始对象的，不要用现在的理解补写，那等于给旧判断编一个新依据。补不了的在文件顶部加一行标记，并在来源栏保留说明。
[不可核对] 来源未记录，补记截止 YYYY-MM-DD
依据来源: 未提供标记方式建议统一用文件首行的方括号前缀，这样用 grep -rn "^\[不可核对\]" notes/ask/ 就能拉出全部不可核对条目。风险边界是：标记为不可核对不等于判断是错的，只是说明这条记录不能用来追溯来路，需要时应重新问一次或重新查一遍。
把留痕动作挂在提问后的固定节点上
靠事后补记录的方案通常撑不过两周，所以触发节点要选在提问流程内部。可用的节点有三个：拿到回答并准备照做时、把回答复制进笔记或工单之前、关闭对话窗口之前。建议把第一个作为主节点，因为那时最关心依据；另外两个作为兜底，用来捡漏。
执行规则写成一句话挂在顺手的位置，例如放在笔记目录的 README 或工单模板顶部：
回答要用之前，先补一行依据来源；写不出来，就标未提供。再配一个轻量巡检，每天收尾或每周固定时间跑一次，只看有没有漏记来源的记录，不去重读内容：
grep -rLn "依据来源" notes/ask/
grep -rn "依据来源: *$" notes/ask/验证方式很简单：连续记一周后，随手抽一条旧记录，能否在十几秒内说出当时的原始问法和依据对象。风险边界是巡检只能发现缺字段，发现不了来源写错或来源本身失效，后者仍然要靠前一节的核对动作来兜。